Subscriber Sessions, IPAM & CPE
Last updated 12 Oct 2026
At a glance
Fixed access is dominated by subscriber sessions that come and go. The orchestrator manages the profile that decides what a session gets; the BNG and AAA run the sessions. IPAM is the hardest integration, because its leases must stay in step with the BNG and RADIUS. The CPE, managed over TR-069 or TR-369, is where the customer experiences the service.
The picture
The orchestrator writes the profile once per order. The network uses it on every connection.
Order time · orchestrator writes · once per order or change
- AAA
Subscriber profile and credentials
- BNG
Service profile: speed tier, QoS
- IPAM
Pool assignment or static block
- ACS
CPE configuration (TR-069 / TR-369)
Session time · BNG and AAA own it · every connect, reboot and renewal
- CPE connects
IPoE (DHCP) or PPPoE
- BNG
Sees the subscriber, asks AAA
- AAA
Authenticates, returns profile
- IPAM / pool
IPv4 (often behind CGNAT), IPv6 prefix
- BNG
Applies policy; accounting starts
Where it breaks
IPAM, BNG and RADIUS each hold a view of which address belongs to which subscriber. When they disagree, traffic is black-holed or an address is handed out twice.
How it works
Profile and session
A session is created when the CPE connects, authenticated against AAA, given an address, granted policy by the BNG, and torn down on disconnect. The orchestrator does not manage sessions. It manages the subscriber profile: a contract that says what this subscriber gets when they connect. Making session creation an orchestration step turns every CPE reboot into an OSS event.
| IPoE | PPPoE | |
|---|---|---|
| Pattern | IP over Ethernet; modern | PPP over Ethernet; older |
| How it connects | BNG sees the CPE, authenticates via DHCP Option 82 and RADIUS, assigns address and policy | CPE sets up a PPP session with the BNG, authenticates, gets an address |
| Trade-off | No per-session tunnel or PPP overhead | More overhead, cleaner per-subscriber session isolation |
| Where used | Most modern FTTH | Many DSL and some FTTH deployments |
IPAM: the hardest integration
Every subscriber needs IP. At large scale that means millions of IPv4 addresses, mostly behind CGNAT, plus IPv6 prefixes. IPAM is the one access integration that has to be transactional, fast, and survive every BNG event without IPAM, BNG and RADIUS drifting apart.
- IPv4 with CGNAT: public pools shared through CGNAT. The inside address is allocated; the BNG or CGNAT function maps it to a public address at session time.
- IPv6 prefix delegation: each subscriber gets a prefix, typically a /56 or /64, allocated by IPAM and delegated through the BNG by DHCPv6-PD or RADIUS attributes.
- Dual stack: IPv4 and IPv6 at once, each from its own pool with its own lifetime and renewal cadence.
- Static allocation: business and BGP-peered customers need static addresses that are reserved, never recycled, and tied to the customer record across CPE replacements.
When the three stores disagree on who holds an address, traffic is black-holed, addresses are duplicated, or routing fails. The lease lifecycle should be a first-class service object with its own owner, separate from subscriber provisioning.
CPE management
The CPE is the only OSS-managed element inside the customer’s premises. Its management protocol has to survive NAT, intermittent connectivity and customers power-cycling their router.
| Aspect | TR-069 (CWMP) | TR-369 (USP) |
|---|---|---|
| Status | Production at scale; older design | Modern; rolling out on new CPE |
| Transport | HTTP/SOAP | WebSocket, MQTT, STOMP, CoAP |
| Control flow | CPE polls the ACS; ACS triggers a connection request | Event-driven, bidirectional, near real time |
| Data model | Device:2 (BBF) | Device:2 plus USP extensions |
| Typical use | Broadband, VoIP, IPTV | Smart home, mesh Wi-Fi, 5G FWA CPE |
Wi-Fi coverage, mesh reachability, connected devices and parental controls are all CPE-management territory. Network outages are visible to operations; CPE problems are visible to the customer.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Subscriber profile (speed tier, QoS, credentials) | AAA / RADIUS | SOM / ROM (provisioning) | BNG, Service Inventory | Written at order time; read by the BNG on every connection. |
| Subscriber session | BNG | — | AAA (accounting) | Runtime state. Never an orchestration object. |
| IP lease, pool and IPv6 prefix | IPAM | BNG / DHCP (dynamic assignment) | RADIUS, Resource Inventory | Must stay consistent across IPAM, BNG and RADIUS; static addresses tied to the customer record. |
| CPE configuration and firmware | ACS (TR-069 / TR-369 controller) | Customer care tools | Resource Inventory | The CPE itself can be changed by the customer; the ACS holds the intended state. |
In practice
Most estates run IPv4 and IPv6 in parallel, with CGNAT for IPv4 and prefix delegation for IPv6, and a mix of IPoE and PPPoE across technologies. TR-069 remains the installed base; TR-369 arrives with new CPE, so both run side by side for the life of the older devices.
Operators that treat CPE management as secondary to "real" orchestration end up with customer escalations about Wi-Fi and in-home devices that the OSS cannot see or resolve.
The trade-off
What it solves
Separating the profile (orchestrated once) from the session (run by the network) keeps the OSS out of every connection, while IPAM and the ACS give leases and CPE configuration an owner.
What it does not solve
- Address exhaustion; CGNAT and IPv6 manage scarcity without removing it.
- In-home problems the CPE cannot report, such as interference and customer devices.
- Drift between IPAM, BNG and RADIUS without reconciliation.
What it adds
- Lease lifecycle as its own service object, with reconciliation across three stores.
- Two CPE management protocols during the long overlap.
- Dual-stack pools with different lifetimes and renewal cadences.
Architecture decision
Which system should own IP allocation for fixed-access subscribers?
Central IPAM as system of record
Choose when static and business addresses must be tracked, scale is large, and the BNG and RADIUS can be fed from it reliably.
BNG-local pools, IPAM for planning only
Choose when nearly all subscribers are dynamic, and pool sizing is the only thing that needs central control.
Central IPAM for static and business, local pools for dynamic
Choose when the residential base is dynamic but business customers need fixed addresses tied to their record.
Breaks if allocation is a side effect of provisioning with no lease owner. IPAM, BNG and RADIUS drift, and the first sign is a customer with no traffic or two customers with one address.
Takeaways
Key Takeaways
- The orchestrator manages the subscriber profile; the BNG and AAA manage sessions.
- IPAM must stay in step with the BNG and RADIUS; treat the lease as a first-class service object.
- CGNAT, IPv6 prefix delegation, dual stack and static addresses each need their own allocation rules.
- TR-069 is the installed base and TR-369 the newer protocol; CPE management is where customers feel the service.
Check yourself
A design raises an OSS event every time a subscriber’s session starts. Why is that a problem?Show answerHide
Sessions are runtime state owned by the BNG and AAA, and they start on every reboot and renewal. Putting the OSS in that loop adds load and fragility. The OSS should manage the profile that sessions use.
A business customer replaces their router and loses their fixed IP. What went wrong?Show answerHide
The static address was tied to the device instead of the customer record, or was not reserved in IPAM. Static allocations must be reserved, never recycled, and survive CPE replacement.
Two customers on the same BNG report intermittent loss of service at the same times. What do you suspect?Show answerHide
A duplicated address: IPAM, BNG and RADIUS disagree about a lease. Reconcile the three stores and check whether the allocation was made outside IPAM.