The broadband industry has been steadily moving away from proprietary hardware appliances toward software-based networking. While purpose-built hardware still delivers impressive performance, virtualized Broadband Network Gateways (vBNGs) have reached a point where they can handle carrier-scale traffic while providing something traditional platforms struggle to match: flexibility.
At 5×9 Networks, our goal has never been to simply virtualize a traditional BNG. The objective has been to rethink how a BNG should be built in a cloud-native world. That journey has led us to a simple conclusion: Control and User Plane Separation (CUPS) is the architectural decision that makes everything else possible.
The Challenge
A Broadband Network Gateway sits at the heart of a fixed broadband network. It authenticates subscribers, establishes PPPoE or IPoE sessions, applies subscriber policies, enforces QoS, and provides Internet connectivity.
Historically, these responsibilities have been tightly coupled inside a single system. As subscriber counts and traffic volumes increase, scaling such architectures becomes increasingly complex. Every new requirement affects the same monolithic platform, making upgrades, maintenance, and scaling more difficult. Virtualization alone does not solve this problem – running the same monolithic architecture inside virtual machines simply moves the limitations into software.
Why CUPS Changes Everything
The real transformation comes from separating the control plane from the forwarding plane.
In a CUPS architecture, the control plane is responsible for subscriber management, authentication, IP address allocation, routing, orchestration, and automation. The user plane focuses exclusively on forwarding packets at line rate. This separation provides several important advantages.
First, each component can scale independently. If subscriber growth requires additional control capacity, more controllers can be deployed without touching packet forwarding. Likewise, if bandwidth demand increases, additional forwarding instances can be introduced without affecting subscriber management.
Second, failures become easier to isolate. Individual forwarding nodes can be upgraded, restarted, or replaced without requiring changes across the entire platform.
Finally, CUPS enables automation from the ground up. Because control functions are centralized, provisioning, orchestration, and operational workflows become significantly simpler than in traditional tightly coupled systems.
Rather than treating forwarding nodes as complete BNGs, they become highly optimized packet-processing engines managed by a centralized intelligence layer.
Building Around CUPS
This philosophy shaped the design of our virtual BNG.
Instead of building one large application, the platform consists of three independent components:
- a dashboard for configuration, APIs, and automation,
- a controller responsible for subscriber intelligence and network control,
- forwarders dedicated solely to high-speed packet processing.
Because each component has a clearly defined role, operators can deploy exactly the resources they need. Small edge deployments can use a lightweight footprint, while national broadband networks can scale horizontally by adding forwarding capacity where required.
The architecture naturally fits modern cloud environments, virtual machines, and containers, while remaining suitable for traditional data centre deployments.
Performance Is About Architecture, Not Just Hardware
Achieving terabit-class performance is often viewed as a hardware problem. Better CPUs, faster memory, and newer network adapters certainly help, but they are only part of the equation. Throughout our development, we found that architectural decisions consistently had a greater long-term impact than isolated optimizations.
As traffic volumes increased, it became clear that efficient separation of responsibilities, careful resource utilization, and minimizing duplicated state across forwarding instances were far more valuable than simply adding more compute power. This led to continuous refinement of the forwarding architecture, allowing significantly higher throughput while keeping operational complexity under control.
The result is a platform capable of delivering more than one terabit per second on commodity x86 servers while preserving the flexibility expected from cloud-native software.
Flexibility for Different Deployments
One important lesson is that there is no single deployment model for every operator.
Smaller edge locations benefit from lightweight forwarding instances that can be deployed quickly and consume fewer resources. Large aggregation sites benefit from larger forwarding instances that maximize hardware efficiency and reduce duplicated state. Because the control plane remains independent, both deployment models coexist naturally within the same architecture, operators can adapt their infrastructure without redesigning the entire platform.
Looking Beyond Raw Performance
Raw throughput is only one metric. Service providers increasingly need faster service rollout, simpler operations, better automation, and the ability to evolve their networks without forklift upgrades – this is where CUPS delivers its greatest value.
By decoupling network intelligence from packet forwarding, operators gain the flexibility to introduce new services, expand capacity, and modernize infrastructure without disrupting subscriber traffic.
Performance improvements will continue with every new generation of CPUs and networking hardware. Architectural flexibility, however, is something that must be designed from the beginning.
Conclusion
The industry often measures virtual networking platforms by packets per second or gigabits per second. Those numbers matter, but they are not the whole story. The real achievement is building an architecture that can continue to evolve as networks grow – Control and User Plane Separation provides that foundation. It allows independent scaling, simplifies operations, supports automation, and enables software to fully leverage advances in commodity hardware.
In the end, reaching terabit-class performance was not simply the result of faster processors or better optimization. It was the outcome of building the right architecture first—and letting CUPS become the cornerstone of everything that followed.
