Need Solution?
Contact us if you need a solution.
Both names describe the same place in the network: where subscriber sessions terminate and per-subscriber policy is applied. The names come from different decades, and the vocabulary has not caught up evenly — which is why you still see both on datasheets, in tenders and in job adverts.
The short answer: a BRAS (Broadband Remote Access Server) terminated PPP sessions from DSL subscribers and handed them to the ISP core. A BNG (Broadband Network Gateway) does that and everything that was bolted on afterwards — IPoE as well as PPPoE, IPv6, per-subscriber hierarchical QoS, multicast for IPTV, carrier-grade NAT, lawful-intercept logging. Same position in the network, a much larger job.
In practice the two words are used interchangeably, and vendors pick whichever their customers say. If a document says BRAS and describes IPv6 and hQoS, it means BNG.
The term belongs to the ATM and DSL era. A DSLAM aggregated copper lines; the BRAS sat behind it and terminated the subscriber’s PPP session — PPPoA over ATM first, then PPPoE once the aggregation network moved to Ethernet. It authenticated the subscriber against RADIUS, handed out an IP address, applied whatever rate limit the plan called for, and routed the traffic into the core.
That was the whole job: remote access, in the literal sense the name describes. Everything about the subscriber — who they were, what they had paid for — lived in the PPP session and the RADIUS exchange that set it up.
Wholesale was handled with L2TP: the access provider’s box acted as an LAC (L2TP Access Concentrator) and tunnelled sessions to the retail ISP’s LNS (L2TP Network Server). That split is still in service today wherever the access network and the retail ISP are different companies.
Fibre and Ethernet aggregation broke the assumption that every subscriber arrives inside a PPP session. The Broadband Forum’s TR-101 moved aggregation to Ethernet, and TR-178 described the multi-service edge that followed. The box at the IP edge picked up jobs that had nothing to do with remote access:
Subscribers identified by DHCP option 82 and line-id rather than by a PPP username. No session to establish, so session state has to be built from the access circuit instead.
Prefix delegation, DHCPv6, and both stacks in the same forwarding path — plus the transition machinery (DS-Lite, NAT64, MAP-T) once IPv4 ran out.
Not one rate limit per subscriber but a scheduling tree: subscriber inside VLAN inside port, so an oversubscribed aggregate still delivers each plan rate.
IGMP and MLD snooping and replication at the edge, so one stream from the headend becomes many at the last aggregation point rather than at the source.
IPv4 exhaustion put NAT44 at the edge, with port-block allocation per subscriber and logging that can map a public IP:port back to a customer.
RADIUS CoA to change a subscriber’s rate, redirect them to a captive portal or quarantine them — without tearing the session down.
| BRAS, as the word was used | BNG, as the word is used now | |
|---|---|---|
| Access | ATM and DSL, later Ethernet | Ethernet, GPON, fixed wireless, satellite ground segment |
| Session | PPPoA, then PPPoE | PPPoE and IPoE side by side |
| Addressing | IPv4 from a pool | Dual-stack, prefix delegation, CGNAT, MAP-T / DS-Lite |
| QoS | A rate limit per session | Hierarchical scheduling with AQM and L4S |
| Video | Out of scope | Multicast replication at the edge |
| Policy | Set at session start | Changed mid-session by RADIUS CoA |
| Security | Upstream of the box | Anti-spoof, uRPF and DDoS containment at the subscriber port |
| Hardware | Purpose-built chassis | Chassis, or commodity x86 running a software data plane |
The left column is not obsolete — plenty of it is still running. It is a description of scope, not of age.
Not as a word. It matters as a checklist. Two boxes both labelled BNG can differ enormously in what is actually switched on, so the useful questions are about scope rather than naming:
The last two are where datasheets stop being useful and the answers start depending on who built the thing.
Tell us subscriber count and busy-hour throughput and we will size it against your numbers. A proof of concept runs on your own x86, against your own traffic.
Contact us if you need a solution.