Page 1445 - 5G Basics - Core Network Aspects

Signalling aspects 3

There have been a variety of protocols between the controller and the network device, such as NETCONF,
Openflow, SNMP, etc. The BNG device could be managed, configured and controlled by the controller
through such protocols. The details of those existing protocols are beyond the scope of this recommendation.

8.2 Signalling for the notification of BNG status/information
The BNG is recommended to notify its own status to the controller, which may include the load situation, the
fault information (e.g. link/port/card failure), etc. The controller is recommended to be aware of the detailed
status of each member of the BNG pool. Based on the BNG real-time status, it is possible to perform fault
protection and load balancing. The BNG is recommended to also report some key information to the
controller, such as the topology information.

As depicted in Figure 8-1, each BNG reports real-time load situation to the controller during the running
phase. After receiving user access requests, the controller will decide which BNG in the BNG pool can provide
service. If the real-time load of one BNG reaches the maximum threshold, the controller will dispatch the
traffic from new users or a part of online users of this BNG to other BNGs. This load balancing procedure will
be illustrated at Section 8.5 in this document.

Each BNG also reports the topology information to the controller in the initial phase or in the running phase
when the network topology changes, as depicted in Figure 8-1. The topology information is recommended
to include (not limited):
– BNG identification;
– Board/Line card;
– Link;

– Interface.

8.3 Signalling for fault monitoring and notification
To realize the high reliability, signalling for the fault monitoring and notification is required between the
controller and the member of the BNG pool, thus the failure can be detected as soon as possible.
In active mode, each BNG member will notify fault information to the controller when a failure occurs in the
running phase as depicted in Figure 8-1. Then the controller will choose another BNG in the BNG pool to take
over the services carried by the fault BNG.
In passive mode, the controller monitors the real-time status of each member of the BNG pool. When a BNG
is out of service, the controller can detect the failure quickly through the monitoring mechanism. Then it will
decide which BNG in the BNG pool can take over the service carried by the fault BNG.
Fault protection procedure will be illustrated at Section 8.5 in this document.

8.4 Signalling for synchronization of user session information among BNGs

To realize hot-standby protection for a link/port/card/device failure and a user seamless migration, users'
session information (including user IP/MAC, accounting information, etc.) of one BNG is recommended to be
synchronized to its backup BNG. Optionally, such information can be transferred via the controller.
The controller is in charge of maintaining the relationship between the primary and hot-standby BNG, and
assigning it to BNGs. Each BNG synchronizes its user session information to its backup BNG in a real-time
manner. These synchronization information is recommended to include (not limited):
– User session, such as IP/MAC, a PPPoE session ID;
– Account information;
– IP address sections;
– user group, such as a physical interface, a logical sub-interface, VLAN and MAC.

1435