BISDN / BNGbox
Subscriber edge · broadband network gateway

A BNG that scales with you

BNGbox is an application that runs on a Kubernetes cluster of commodity servers: container network functions that together form a distributed broadband network gateway. Centralised in the PoP or distributed at the network edge, the same software, built from open source components.

Kubernetes · cloud-nativeCUPS · Separate control and data pathsVPP · DPDK data pathx86 today
Why cloud-native

Four capabilities a traditional BNG does not have.

A cloud-native platform offers a wealth of flexibility

Scaling

On demand

Kubernetes automatically matches capacity to the actual load, without manual provisioning. Balance capacity and efficiency on-demand.

Deployment

Central or at the network edge

The same software runs centrally in the PoP or distributed at the network edge: on x86 servers where many subscribers come together, and from Q4/2026 also on ARM where power and space are limited. Session termination moves closer to the customer if you want it to.

Energy

Reduce wasted energy

User planes are added and removed as traffic demands. Less load means less energy consumption, with further reductions from the ARM version available from Q4/2026.

Software management

In-service upgrades

Before a user plane is updated, its subscriber groups move to a server with spare capacity, keeping their sessions intact. The maintenance window at three in the morning disappears.

Control and User Plane Separation

One control plane, many migratable user planes

CUPS separates session state from packet processing. This gives BNGbox its defining capability: sessions can be moved during operation.

One control plane holds the state of all sessions for multiple user planes that handle forwarding.

Subscriber groups aggregate sessions into lightweight virtual BNGs.

Floating vBNGs: these groups move between user planes during operation without sessions dropping, provided the access network supports the move, as described by the Broadband Forum in WT-474. This is the basis for in-service upgrades and load balancing.

Built according to TR-459, connected differently: the separation into control and user planes follows the Broadband Forum architecture in TR-459. They communicate over NATS JetStream rather than PFCP, using the same message bus as the rest of the platform.

Cloud-native BNG: from session to OSS.

OSSSubscriber Session SteeringControl planeMicro user planeFloating BNG identitySubscriber session

Six layers, one architecture: the subscriber session at the core belongs to a floating BNG identity running on a micro user plane, managed by the control plane, directed to the right location through Subscriber Session Steering and integrated into the OSS.

The BNGbox model: from session to network segment.

What stacks up inside one node: sessions, groups, user planes and network attachment.

Sessions are grouped into subscriber groups. Each group belongs to exactly one micro user plane (SGUP), and one user plane carries several groups. User planes run as Kubernetes workloads on worker nodes.

Core and access interfaces connect the node to the Ethernet segment and aggregation domain. Addresses for new groups and user planes come from the pools of the associated network segments, without manual IP configuration for each endpoint.

The group is the scaling unit. Create as many groups as you need and size each one to suit its location. Growth means more groups and more worker nodes, rather than a larger chassis.

Build

Open components

BNGbox is built from established open source projects. Every component has a name and a source, providing the basis for auditability and evidence under the Cyber Resilience Act.

Control plane

Control

  • Accel-pppPPPoE/PPP sessions
  • ISC kea DHCPv4IPoE sessions
  • Free Range RoutingBGP for dynamic subscriber route announcement
User plane

Data path

  • FD.io VPPDHCP4 proxy · IPoE · PPPoE
  • DPDKHierarchical QoS
  • LIETSI-LI-X3 compliant mirror path
Management plane

Management

  • FreeRADIUSAAA
  • MariaDBConfiguration · interfaces, workers, prefixes, QoS profiles
  • RedisUser-plane session cache
The entire data path runs on VPP and DPDK, the same foundation hyperscalers use. Your architecture is not tied to a particular vendor's hardware implementation.
Capabilities

BNGbox supported features

The capabilities for subscriber termination, AAA, QoS, routing and operations, as they run in the lab today.

Subscriber & access
  • IPoE/DHCP & PPPoE
  • Dual-stack IPv4/IPv6
  • Per-subscriber VRF assignment
  • DHCP Option 82 & 125
  • IP pool management (address, prefix, delegation)
  • Dynamic and static IP
  • Lawful Intercept
AAA & policy
  • RADIUS & local AAA
  • Multi-RADIUS failover / load balancing
  • RADIUS-controlled QoS profiles (IP · MTU · bandwidth)
  • Change-of-Authorization
  • RADIUS accounting and analytics
QoS & traffic
  • Hierarchical QoS (HQoS)
  • Classification: TOS · DSCP · VLAN
  • Committed Access Rate (CAR)
  • CBWFQ & priority queuing
Routing & switching
  • BGP (per-VRF, IPv4 unicast)
  • Policy-based routing
  • VLAN 802.1q · QinQ 802.1ad · jumbo frames
Deployment & management
  • Cloud-native Kubernetes
  • SR-IOV · VirtIO · DPDK
  • REST API · CLI
  • IPFIX flow telemetry
  • Policy database (gRPC) · OSS/BSS integration
1–100 GbE
Interfaces (1/10/25/40/100)
50+ Mpps
packet throughput
~200/s
Subscriber connect rate
CGNAT: dynamic / PBA / deterministic, full-cone or symmetric, session logging for compliance, up to 12M NAT sessions. Standards: CUPS follows the BBF TR-459 architecture, Session Steering follows WT-474, and network architecture follows TR-178i2. Measured on a 1U server with an Intel Xeon D-2796NT (20 cores) and 2 × 25 GbE, comparable to the Supermicro SYS-110D-20C-FRAN8TP; other servers deliver different results.
AI assistance

Coming 2027: AI-assisted operations for BNGbox

BNGbox will get a Model Context Protocol (MCP) server through which AI assistants can access subscriber, session and configuration data, with explicit permissions and a clear interface. Your operations team can then diagnose session failures, bring together RADIUS and telemetry data, and prepare configuration changes in natural language. Every change continues to go through the existing GitOps workflow.

Operations

You run your network. We stand behind it.

A cloud-native BNG is only an advantage if your team can work with it in production. Your own team or the systems integrator who already looks after your network runs operations. BISDN provides the software, patches and level-2/3 support behind it, from Berlin, on business days from 9am to 5pm.

You

Subscribers and services

  • Tariffs, RADIUS profiles, customer circuits
  • First-level support in the BNGbox GUI
  • Your network and your data centre
Your team or your integrator

Running the platform

  • Kubernetes and the BNGbox components
  • Monitoring, alerting, upgrades
  • With our tools and runbooks
BISDN · Software & Care

Software and support

  • Licence and quarterly releases
  • Security patches, CVE handling
  • Level-2/3 support from Berlin, reply the same working day
Who is responsible for what, how an incident reaches us, and how remote access stays under your control: Software & Care in detail. For wholesale providers, the same page shows where the platform is heading.
Resilience

Limiting your blast radius

If a chassis fails, you lose everything. With distributed nodes, healthy workers can take over. Try the sandbox below to explore.

Failure sandbox · click a node

6nodes up
48,000sessions carried
0sessions lost
50 %load per node
Six user planes, 48,000 sessions. Click one to switch it off.

Sessions on the failed node are re-established; the others continue uninterrupted.

Next step

Are you still terminating sessions on a chassis?

Talk to the developers who built BNGbox about your scenario, centrally or at the network edge.