Service Granularity in Broadband Subscriber Management: Problem Statement and Gap Analysis

Introduction The broadband subscriber management framework has been stable for two decades. A residential gateway (RG) or optical network terminal (ONT) establishes a session with a broadband network gateway (BNG), using PPPoE or IPoE. The BNG queries a RADIUS server for an authorization profile that contains addressing and rate parameters, installs shapers and policers in the forwarding plane, and produces accounting records . The session is therefore the smallest unit of authentication, policy enforcement, and metering. The network is blind to the terminals and applications inside the home, and cannot distinguish the traffic of different services that share one session. An architecture designed for selling bandwidth makes it difficult to sell anything else. Demand has since diverged. AI agents need large upstream capacity and coordination with compute; live streaming needs a stable upstream rate; cloud gaming needs low latency and low jitter. A single session-level rate and a single session-level policy cannot serve all of them at once. Classic deep packet inspection (DPI) can identify plaintext flows, but it lags application churn, degrades on end-to-end encrypted traffic, and produces false positives and false negatives at rates that are hard to operate. Operators are therefore adding intelligence at the access edge along two lines: external AI gateway appliances, or reuse of the compute boards already fitted to intelligent BNGs (iBNGs). The latter is cheaper in deployed networks and is the mainstream form today. Two capabilities are available on iBNG compute boards. An AI gateway interprets inference requests and schedules them across model instances; AI-based traffic classification identifies encrypted live streaming and places it on a dedicated path. Both solve the problem of not knowing what a flow is. Neither is matched by the standardized AAA, QoS, and accounting framework, which remains at session granularity: there are no primitives to express, authorize, enforce, and meter a policy for a single service flow inside a session. The identify, authorize, enforce, and meter loop therefore cannot be closed with standard mechanisms. Today every such capability is vendor private, does not interoperate in multi-vendor deployments, and does not scale as a commercial product. This document is an informational problem statement. It does not define new protocol behavior, and it does not propose attribute encodings. It describes the operational background, defines two use cases, and analyzes the gaps in the existing standards. The work is intended to be discussed in OPSAWG, where subscriber management and access network operations are chartered.

Terminology iBNG (Intelligent Broadband Network Gateway): a BNG that, in addition to conventional forwarding and control functions, carries a compute board able to host AI analysis and service orchestration functions. AI Gateway: a function hosted on the iBNG compute board that interprets request semantics, selects model instances, and steers traffic toward the most suitable compute path, providing combined compute and network scheduling for AI inference services. AI-based Traffic Classification: a function hosted on the iBNG compute board that classifies flows under encryption, using traffic features, packet timing, and flow statistics. Service Flow: the set of packets within a single subscriber session that share the same service identity and the same service level requirements. It is the smallest unit of fine-grained subscriber management discussed in this document. A service flow is not an IPFIX flow as defined in , and it is not a service data flow as defined for 3GPP networks; it is a construct that lives inside one subscriber session and is visible to the BNG, the AAA server, and the accounting system.

Use Cases This section describes two operational scenarios that correspond to the two capabilities available on iBNG compute boards. Both reuse existing iBNG hardware and add no network element. Both also expose the same shortcoming of session-granular subscriber management.

AI Gateway: Semantic Routing and Compute Coordination This section describes how an AI gateway is deployed on an iBNG compute board, and what operators expect from it.

Scenario Large language model based services are appearing in the home: personal assistants, home automation agents, health management assistants. These agents continuously reach cloud-hosted models to complete inference tasks. The resulting experience depends not only on the model service itself but also on the quality of the path between the home and the compute node. An operator can combine its network resources with a distributed compute footprint to offer combined compute and network assurance, steering each request toward the best model instance and the best path.

Deployment on the iBNG Compute Board The AI gateway runs on the compute board already present in the iBNG, which sits at the boundary between the home network and the operator network. When an agent issues an inference request, the AI gateway interprets the request, combines the network context that the BNG already has (link latency, path congestion, available bandwidth) with the load of model instances across data centers, and performs semantic routing: the request is steered to the most suitable model instance and data center, trading off inference quality, network latency, and overall utilization. The same deployment can also offer compliance functions such as content blocking and data masking.

Operational Pain Points The operator has identification and steering, but the existing management framework prevents this from becoming a product.

No differentiated assurance can be provisioned for the AI service alone. The operator cannot give the AI traffic in a session a dedicated rate and scheduling priority according to the subscriber profile, so the differentiated experience cannot be delivered in a standard way.
No separate charge can be raised for the AI service. Existing accounting counts bytes and time for the whole session, so the combined compute and network service cannot be metered on its own, which blocks the commercial packaging.

These pain points correspond to systematic gaps in the subscriber management protocol framework, analyzed in Section 4.

AI-based Classification: Upstream Differentiation This section describes the upstream assurance that live streaming needs, and the constraints that deployed networks impose on it.

Scenario Upstream is the structurally scarce direction in broadband access. PON shares the upstream medium by TDMA, and the upstream capacity available to one subscriber is bounded by DBA scheduling and optical budget, so the two directions are asymmetric. Live streamers need stable upstream bandwidth and low jitter: the encoder runs at a constant rate, and any contention causes rate adaptation, stutter, and visible degradation. DPI-based classification identifies encrypted streaming poorly and cannot reliably separate streaming from backup or software updates, so it cannot support fine-grained upstream assurance. Two independent limits exist in deployed networks.

On the optical path, the OLT grants upstream bandwidth per T-CONT through DBA. Lifting this limit requires the OLT to cooperate.
At the BRAS, each subscriber session is configured with a committed access rate (CAR) and burst parameters for both directions, and upstream packets are shaped or policed at the BRAS ingress. For a live streamer this is usually the limit that binds first: even when the optical path still has headroom, traffic above the session CAR is dropped or queued.

What the operator needs is narrower than a rate increase: raise the upstream limit for the streaming flow only, and leave backup, software updates, and other upstream traffic in the same session under the original limit.

Deployment on the iBNG Compute Board The operator deploys AI-based traffic classification on the iBNG compute board as part of the BNG's intelligence. Using traffic features, packet timing, and flow statistics, the classifier identifies encrypted streaming and other upstream flows. Once a flow is identified, the BRAS can give it a separate queue and a separate upstream rate limit (CIR) that is not subject to the session CAR, while the rest of the session keeps its existing scheduling so the two do not contend. Lifting the limit at the BRAS removes only the BRAS constraint. If the optical path is already saturated, the OLT and ONT must cooperate in upstream scheduling and marking. The service flow identifier and its policy therefore have to reach not only the BRAS but also the access node, and the existing standards provide no path for that, as discussed in Section 4.1.

Operational Pain Points Classification solves the encrypted-identification problem, but the operational loop is still missing.

The upstream rate cannot be opened per service flow. The session CAR is delivered once at authentication as part of the authorization profile, and a classification result cannot be written back into authorization. Because CoA can only modify the whole session, the operator has exactly two options in a deployed network: open the session, which lets backup traffic take the headroom and defeats the purpose, or leave it closed, which leaves the streamer unaffected but also unimproved. There is no middle option.
Upstream acceleration cannot be metered or charged separately. The operator cannot count the traffic and time on the dedicated upstream path, nor charge by accelerated time or volume, which blocks on-demand upstream products.

As in the AI gateway case, the bottleneck is the session granularity of the protocol framework.

Gap Analysis The two use cases differ in scenario and capability, but they meet the same standard obstacle. The core problem is not forwarding capability: BNGs already classify, queue, shape, and police traffic per flow. The gap is in the RADIUS-based subscriber management framework, which uses the subscriber session as its smallest unit and offers no standardized definition of, or interaction primitive for, a service flow inside a session. Three gaps follow, in order of dependency: identification, authorization, and accounting.

Service Flow Identification and Cross-Node Mapping A BNG can classify traffic today, with ACLs, five-tuple matching, and DSCP mapping. Those rules are local configuration, effective on one node only. What does not exist is a service flow identifier that is standardized across the BNG, the AAA system, and the accounting system. Three limitations follow.

No standard protocol carrier for a service flow identifier. The closest standard attribute in RADIUS is Service-Type, but it is a single session-level value whose enumerations (Framed, Login, Voice) describe access service kinds, not the services that coexist in one session. Filter-Id can reference a named filter, but its name is defined entirely by the local device and cannot be interpreted by another vendor. No standard attribute can carry an identifier for "AI inference" or "live streaming" as a service dimension, so classification rules are defined per vendor and per deployment, cannot interoperate, and cannot serve as trustworthy input to authorization.
Existing markings cannot support operational authorization. DSCP and 802.1p can be set by the terminal, trust boundaries and remarking differ between vendors, and the marking is bound to no authorization, so it cannot serve as the basis for differentiated service or charging. A five-tuple is not known at authorization time, one service usually maps to several connections, and the mapping changes on reconnection, so a five-tuple cannot stably denote a class of service.
The identifier cannot reach the access node. Upstream enforcement does not happen only at the BRAS. To take effect on the optical path, a service flow identifier must reach the OLT and ONT and drive upstream scheduling and marking. The existing access node control mechanisms, which address line rate and multicast (for example ANCP), do not carry per-service-flow policy, and the standards define no path to deliver an identifier and its policy to an access node.

This is the base gap. Without a standardized flow identifier, every subsequent step depends on vendor-private schemes, industry-wide interoperability is impossible, and the identification results in Section 3 cannot be carried across systems.

In-Session Per-Flow QoS and Rate Authorization Every core policy attribute in the RADIUS authorization framework applies to the whole subscriber session. None addresses a single flow inside it.

The rate attributes are session-level. The standard RADIUS attribute set has no attribute for provisioning a committed rate; in deployed networks the per-subscriber CAR is provisioned with vendor-specific attributes, which is itself evidence that the standard is silent at this layer. Those attributes describe one rate for the whole session, cannot be scoped to a class of flow, and carry no queue or scheduling parameters. Filter-Id can reference a policy group by local name, with no cross-vendor meaning. Even with perfect classification, there is no standard RADIUS interface for delivering bandwidth assurance, scheduling priority, or queue parameters for one class of traffic.
Dynamic change covers only the session. CoA, as defined in , can modify the authorization parameters of a whole session. It cannot create, modify, or release the policy of a single flow inside a session, which is exactly what short-lived, on-demand services such as AI acceleration or streaming acceleration need.
The syntax exists, the semantics do not. provides extended attribute types and long extended attributes, enough to carry structured parameters in principle. No standardized set of service flow identity plus policy parameters has been defined, so industry-wide interoperability is not possible.

This is the core gap. It is why an operator cannot use standard AAA to give AI inference or live streaming an on-demand, dynamic, dedicated treatment.

In-Session Per-Flow Accounting RADIUS accounting reports at session granularity and carries nothing at flow granularity, which blocks commercialization.

There is no per-flow counter. Standard accounting records carry input and output octets, packets, and session time for the whole session. Available extensions (Gigawords counters, Interim-Update reporting) report the same aggregates more often. No standard attribute can carry separate counters for several service flows in one session. An individual submission that proposed per-service accounting for RADIUS () was never adopted and expired.
There is no per-flow lifecycle event. Differentiated services are typically short-lived and on demand, so the corresponding creation, modification, and termination events must be reportable. Existing accounting is designed around the start and stop of a session and cannot express a per-flow lifecycle.
There is no correlation identifier. An accounting record cannot carry the combination of parent session identifier, service flow identifier, and service instance identifier together, so the charging system cannot reconcile, settle, or bill.

This gap determines whether a differentiated service can become a saleable product, and it is the operator's most immediate commercial concern in both use cases.

Summary The three gaps form a chain: identification is the foundation, authorization is the core, accounting closes the commercial loop. All three are control-plane gaps. The BNG forwarding plane can already classify, queue, shape, and police per flow; what is missing are the protocol primitives that bind those capabilities to which flow, under what authority, and counted how. Closing a control-plane gap is considerably cheaper than closing a forwarding-plane gap. The existing framework is not without extension points: the extended attribute syntax of and the dynamic authorization of can both be reused. What is needed is agreement on a single set of service flow identifiers with matching authorization and accounting attributes, so that differentiated service can move from private implementation to standardized interoperation.

Next Steps This document stops at problem statement, use cases, and gap analysis. It proposes no protocol extension. Further work will address the three gaps: a standardized service flow identifier, per-flow authorization, and per-flow accounting, together with the corresponding RADIUS extensions. Operators, equipment vendors, and research institutions are invited to discuss this on the OPSAWG mailing list (opsawg@ietf.org), with the goal of standardizing service-aware subscriber management for home broadband.

Security Considerations A service flow identifier is a claim, and claims from the terminal or the access side cannot be trusted. A deployment must validate a declared flow against the subscriber's authorization before applying any per-flow treatment, and must define what happens when validation fails; the safe default is to fall back to the session-level profile rather than to grant the requested treatment. Per-flow authorization increases the attack surface of dynamic authorization. Every per-flow grant and revocation is a CoA exchange, so the protection that prescribes for CoA, including authentication, integrity, and replay protection, applies with more urgency, together with rate limiting on the server side. Per-flow policy must remain bounded by the session. If a per-flow policy can exceed the aggregate limits of its session, a misconfigured or compromised policy becomes a way to bypass subscriber policing. The relationship between per-flow and session-level limits should therefore be defined explicitly, and enforcement points should reject per-flow policies that violate it.

Privacy Considerations Identification as described here works on metadata, such as flow statistics and packet timing, rather than content. Functions that inspect payload, including the semantic interpretation performed by an AI gateway, are outside the scope of this document; where such functions are deployed, they require a separate legal basis, user notice, and data handling rules. Per-flow accounting produces finer-grained records of subscriber behavior than session accounting does, and such records can be personal data in some jurisdictions. Minimization applies: a flow identifier should encode no more than authorization and charging need, retention should be bounded by the billing cycle, and aggregates should be preferred over per-flow records where the purpose allows.

IANA Considerations This document requests no IANA actions. If future work defines RADIUS attributes for service flow identity, authorization, or accounting, the corresponding allocations would come from the "RADIUS Attribute Types" registry, including the extended attribute types defined in , and would require an IANA Considerations section in that document.