Bandwidth-on-Demand Services: What Your Access Layer Needs to Support Them Copy link

Overview

• Bandwidth-on-demand (BoD) needs three things from the access layer that fixed-tier plans never did: real-time policy control at the Authentication, Authorization, and Accounting (AAA) layer, mid-session bandwidth changes via RADIUS (Remote Authentication Dial-In User Service) Change of Authorization (CoA), and convergent charging that can bill a timed event.
• It sells capacity a fiber network already has, in the unit subscribers want: an evening, a weekend, or working hours.
• The two launch-breakers are the revert (the boost has to end on schedule) and a router reboot mid-boost (the next login must still carry the boosted profile).
• Reserve credit before the CoA goes out, get both the start and the actual end time into charging, and check every broadband network gateway (BNG) for CoA support before you build the button.

The product idea fits on a button: a subscriber on a 300 Mbps fiber plan taps “Boost” in the app and gets 1 Gbps for the evening, billed per boost. Product teams like it because it turns headroom the network already has into revenue. Network teams hear it and ask the harder question: can we change the speed of a session that is already running, in seconds, and can billing charge for it correctly?

For both teams, the answer fits in one paragraph:

Bandwidth-on-demand services require three things from the access layer: real-time policy control at the AAA layer, mid-session bandwidth adjustment via RADIUS Change of Authorization (CoA), and integration with convergent charging so that dynamic usage is billed accurately. Fixed-tier plans never needed any of the three, which is why most access layers were not built for them.

The bandwidth-on-demand business opportunity

Fixed tiers were designed around what the access layer could do: set a rate at login and leave it alone. Under that model a subscriber who wanted more speed for one evening had to upgrade for the whole month, so most never did. Bandwidth-on-demand sells the extra capacity in the unit the subscriber actually wants, whether that is four hours, one weekend, or business hours only.

Fiber makes this mostly a policy decision rather than an engineering project. A Gigabit Passive Optical Network (GPON) or 10-Gigabit Symmetric PON (XGS-PON) line provisioned at 300 Mbps can carry far more. For most operators the cap lives in a rate-limit profile on the BNG, not in the glass, so changing the profile changes the product. The PON itself is still shared, which means capacity planning has to confirm the headroom exists on the busiest splitters before the button goes on sale. Operators tend to package the result as time-boxed boosts, event-based offers around big game or release nights, and scheduled tiers for small businesses. Whether any of them launches comes down to two questions: can the access layer honor the button without disconnecting anyone, and can charging bill the result.

Real-time policy control at the AAA layer

Everything else in this article depends on one capability: a policy decision that can happen at any moment in a session’s life, not only at the start. In a standard fixed-broadband flow the AAA server answers an Access-Request with an Access-Accept, and that Accept carries the bandwidth profile the BNG applies for the whole session. Bandwidth-on-demand needs the AAA server to make a new decision whenever a self-care app, a Business Support Systems (BSS) order, a schedule, or a quota threshold asks for one.

For that to work, three things have to be true of the AAA server. It must hold authoritative state for every live session: which BNG owns it, the session identifier, and the Framed-IP-Address. A policy change is useless if the server does not know where to send it. It must expose an API the BSS and self-care platform can call. And it must evaluate eligibility in milliseconds: is this subscriber allowed the boost, has it been paid for, does the line support the target rate.

The common mistake is to fake real-time policy control with a forced re-authentication. The BSS updates the profile, the AAA server drops the session, the subscriber’s router reconnects, and the new rate applies. In production that means a Point-to-Point Protocol over Ethernet (PPPoE) or IP over Ethernet (IPoE) session teardown and a possible new IP address. Every video call in the household drops at the moment the subscriber paid for a better experience. If the platform’s only way to change a live session is to end it, it is not ready for this service.

Mid-session bandwidth adjustment via RADIUS CoA

Change of Authorization is the mechanism that changes an active session without disconnecting it. It is defined in RFC 5176, the Dynamic Authorization Extensions to RADIUS, and it reverses the normal direction of the protocol. The AAA server sends a CoA-Request to the BNG, identifies the session (typically by Acct-Session-Id, User-Name, or Framed-IP-Address), and carries the new rate-limit profile.

The BNG applies the change and answers CoA-ACK, or refuses with CoA-NAK. The same extension defines Disconnect-Request, which is the message you are specifically trying not to send.

Three practical points decide whether CoA works in your estate rather than in the RFC. Every BNG in scope has to support it, and each vendor names its rate-limit attributes differently, so the AAA server needs one attribute mapping per network access server (NAS) vendor and model. An AAA server that ships with mappings for the common BNG vendors removes most of that work; Alepo AAA Server carries Cisco, Huawei, Nokia, and Juniper attributes out of the box. CoA travels from the server to the BNG, usually on UDP 3799, so the firewalls between them have to allow that direction too. Acceptance tests that only exercise logins will never catch a blocked return path. And if your design enforces the rate limit at the optical line terminal (OLT) rather than the BNG, CoA is not the lever at all. The change has to go through the OLT’s management interface instead.

The AAA server also has to handle a NAK sensibly: log it, tell the BSS the boost did not apply, and do not charge for it.

The part teams underestimate is the reverse. A boost that starts must also end, so the AAA server needs a scheduler that sends the revert CoA at expiry and confirms the ACK. Boost state also has to live outside the session. If the subscriber reboots the router an hour into a four-hour boost, the next Access-Accept must carry the boosted profile, because they have paid for three more hours whether or not the session survived. A platform that stores the boost only as a property of the live session will quietly revert on every reconnect.

Convergent charging integration

Getting the rate to change is half the service. Charging for it accurately is the other half, and it is where launches tend to stall. A convergent charging system rates prepaid, postpaid, and hybrid subscribers on one engine against a single balance. That matters here for a plain reason: a boost sold across a mixed base otherwise needs two implementations, two test plans, and two ways to get it wrong.

The sequence matters as much as the system. For a prepaid subscriber, credit has to be checked and reserved before the CoA is sent, or you will apply boosts the balance cannot cover. For a postpaid subscriber, the boost is an event charge with a start and an end. Charging needs both timestamps from the AAA server, including the case where the revert failed and the boost ran long.

If the boosted period is rated at a different price per gigabyte, the RADIUS Interim-Update records that carry usage also need a boundary at the moment the tier changed. Either the BNG emits an interim record on CoA, or charging rates usage by event time.

The failure modes are the familiar ones from how AAA reduces revenue leakage: a boost applied but never charged, or charged but never applied. The reservation and settlement mechanics are the same ones covered in real-time quota management for prepaid broadband. Bandwidth-on-demand simply exercises them on a fixed-broadband session.

Access layer requirements for bandwidth-on-demand

What this looks like end to end

Take a fiber subscriber on a 300 Mbps plan who taps “Boost to 1 Gbps for 4 hours” in the self-care app at 7:40 in the evening.

The app places an order with the BSS. Charging checks the balance or account status and reserves or records the boost charge. The BSS calls the AAA server’s policy API with the subscriber identity, the target profile, and the duration. The AAA server finds the live session in its session store, confirms the line and plan are eligible, and sends a CoA-Request to the BNG that owns the session.

The BNG applies the 1 Gbps profile and returns CoA-ACK. The AAA server records the boost with an 11:40 expiry, tells the BSS it is active, and the app shows the subscriber a confirmation. From the subscriber’s side it is one tap and a short wait.

At 9:00 the subscriber’s router reboots. The PPPoE session re-establishes and the BNG sends a fresh Access-Request. Because the AAA server holds the boost as subscriber state rather than session state, the Access-Accept already carries the 1 Gbps profile. At 11:40 the scheduler fires the revert CoA and the BNG confirms. An accounting boundary lands in the interim records, and charging closes the event with matching start and end times. Had the revert been NAKed, the AAA server would retry, alert operations, and pass the actual end time to charging rather than the planned one.

Every step in that sequence is something the fiber-to-the-home (FTTH) AAA layer already does for authentication and accounting. Bandwidth-on-demand asks it to do the same things on a running session, on request.

Building bandwidth-on-demand into your access layer

If BoD is on the roadmap, four checks will tell you how far the current access layer is from supporting it. Confirm every BNG supports CoA and document the rate-limit attribute per vendor. Confirm the AAA server holds live session state, exposes a policy API, sends and schedules CoA, and stores boost state independently of the session. Confirm charging can rate a timed event and a mid-session tier change for both prepaid and postpaid.

Then test the two paths that break launches: the revert, and a reconnect in the middle of a boost.

Alepo AAA Server supports bandwidth-on-demand through QoS-based authorization, real-time quota re-authorization, and RADIUS Dynamic Authorization (CoA) for live session control. The session store, REST provisioning APIs, and charging integration to the online charging system (OCS) over Diameter Gy sit on the same stack. It runs N+1 and N+N redundancy with real-time database replication, is engineered for 99.999% availability, and is rated at 36,000+ transactions per second (AAA Server datasheet). For the charging half, Alepo Digital BSS provides convergent charging and billing that rates prepaid, postpaid, and hybrid subscribers on one engine, with real-time balance updates for prepaid. Operators that want policy authored centrally across fixed and mobile can pair the AAA server with Alepo’s converged policy control layer.

See a boost applied to a live session. Book a demo and ask us to change a session’s bandwidth while you watch the BNG. Or start with the AAA Server datasheet and check the CoA and charging integration points against your own estate.

Frequently asked questions

Q1. What does the access layer need to support bandwidth-on-demand?

Three capabilities: real-time policy control at the AAA layer so a bandwidth decision can be made again during a session, RADIUS CoA so the change reaches the live session on the BNG without a disconnect, and convergent charging integration so the boost is billed correctly for prepaid and postpaid alike.

Q2. How does real-time policy control enable bandwidth-on-demand?

It lets the bandwidth allocation change on a trigger, such as a self-care request, a BSS order, a schedule, or a quota threshold, rather than only at session start. The AAA server has to know where the live session is, accept the request through an API, and decide eligibility in milliseconds.

Q3. Can bandwidth be changed mid-session without disconnecting the subscriber?

Yes. RADIUS Change of Authorization, defined in RFC 5176, lets the AAA server send the BNG a new rate-limit profile for an active session. The BNG applies it and confirms with a CoA-ACK; the session, its IP address, and any calls in progress all survive.

Q4. How does convergent charging integrate with bandwidth-on-demand?

Charging reserves or records the boost charge before the CoA is sent, receives the start and end events from the AAA server, and rates any usage in the boosted window at the right price. One convergent engine covers prepaid and postpaid without two separate implementations.

Q5. What is the business case for offering bandwidth-on-demand?

It sells capacity the fiber access network already has, in the unit subscribers want to buy: an evening, a weekend, or working hours. With fixed tiers, a subscriber who needs more speed for one evening has to upgrade for a month. A boost gives that subscriber a cheaper option and gives the operator a new line of revenue on the same infrastructure.

Q6. What role does RADIUS CoA play in bandwidth-on-demand?

CoA is the message that actually changes the live session’s authorized bandwidth. The AAA server sends it to apply the boost and again to revert at expiry. Without CoA support on both the AAA server and every BNG, the only way to change a running session’s speed is to end it.

Q7. How does bandwidth-on-demand differ from fixed-tier broadband plans?

A fixed tier sets the bandwidth once, in the Access-Accept at login, and it stays until the session ends. Bandwidth-on-demand changes the rate during the session, on request, and reverts it later, which is why it needs real-time policy control, CoA, and charging that can bill a timed event.