Standardization Trends in the Disaggregation Technology of Access Systems at the Broadband Forum

1. Requirements of future access systems

The traffic of a broadband service over optical access systems, e.g., fiber to the home, has been rapidly increasing due to the expansion of remote work and education intended to prevent the novel coronavirus infection from spreading as well as wide dissemination of video streaming services [1]. Current standards of optical access systems have been developed as specifications with a transmission capacity of 40 or 50 Gbit/s to meet such a rapid and huge demand of traffic [2, 3]. Future access systems should provide a diverse range of services that have different system requirements (transmission capacity, latency, reliability, etc.) such as Internet of Things and edge computing, as well as accommodating a huge amount of traffic.

Given this background, the research and development of disaggregation technology has been progressing. Such technology can reconfigure the functions of an access system by combining general-purpose hardware components (i.e., server and switch) and open source software (OSS) that are loosely coupled via an open interface. However, a conventional system is achieved by using dedicated hardware equipment and software that are tightly coupled via a vendor’s proprietary interface [4]. To achieve a disaggregated access system, specifying an open architecture and interface and developing OSS that can be flexibly and quickly replaced in accordance with system requirements are necessary to ensure interoperability and promote widespread dissemination.

2. Brief summary of Broadband Forum

The Broadband Forum (BBF) is an industry forum and has contributed to broadband-access industries and earned its high reputation for its efforts, especially in developing control/management specifications and interoperability test specifications of access systems, which have been published in more than 200 Technical Reports (TRs) [5]. BBF is composed of more than 150 companies/organizations, which include service providers (telecom carriers and multiple service operators), system vendors, ASIC (application specific integrated circuit) vendors, and others from around the world. Telecom service providers take a leadership role in designating technical topics and directions that are driving BBF. Each Work Area in the Technical Committee discusses corresponding technical specifications on the basis of these topics. BBF has been intensively engaging in the development of various specifications of access systems with virtualization/disaggregation technologies, such as software-defined networking (SDN) and network functions virtualization (NFV), and it is recognized as the most active organization in these topics among access-systems-related standardization organizations and industry forums. In particular, BBF worked to provide a diverse range of specifications on the Network Configuration Protocol/Yet Another Next Generation (NETCONF/YANG)^*1 model, architecture and interface of Cloud Central Office (CO)^*2, disaggregated dynamic bandwidth-allocation function for optical access systems [6, 7], and a disaggregated broadband network gateway (DBNG). This article reports on the specifications on a DBNG, which was finalized in TR in June 2020. It also reports on the specifications on broadband access abstraction (BAA), which is one of the software components of Cloud CO and abstracts vendor’s proprietary hardware specifications, such as an optical line terminal (OLT), along with relevant OSS development trends at the Open Networking Foundation (ONF).

3. Specifications of a DBNG

BBF recently specified a DBNG in TR-459 “Control and User Plane Separation for a disaggregated BNG” [8]. Figure 1 shows the functional blocks and interfaces for a conventional BNG based on the information in TR-459. A BNG is an access point and connected to customer premises equipment at a subscriber’s residence for wireline broadband services. It aggregates various traffic from access networks and forwards it to designated routes for metro/core networks depending on the service type. In addition to such functions, a BNG plays an important role in other functions that support broadband services, i.e., authentication, authorization, and accounting (AAA) of subscriber sessions, Internet protocol (IP) address assignment, and quality of service (QoS) control. A BNG acts as a gateway between an access node and IP/multi-protocol label switching (MPLS). The interfaces between a BNG and each access node and IP/MPLS are defined as V-IF and A10-IF, respectively. Although the functional blocks inside a BNG are configured differently depending on the service to be provided by telecom carriers, it is composed of several functions. A typical example is shown in Fig. 1: subscriber session management, IP address assignment/management, AAA client, QoS function, routing and forwarding, and IPTV (television) multicast. These functions are managed/controlled by the policy decision point (PDP) and AAA controllers via the control/management interfaces inside the BNG. The interfaces between the BNG and each PDP and AAA are defined as R-IF and B-IF, respectively. Therefore, functions and external interfaces comprising a BNG are defined. However, software and hardware comprising a BNG are provided as integrated equipment, which has different implementation specifications from vendor to vendor. Therefore, operation of access networks is complicated because BNGs must be controlled/managed at each facility where BNG equipment is installed. There is also an apparent issue that usage efficiency of resources is low since telecom carriers are required to increase the number of BNGs on the basis of the unit of equipment to meet traffic demand.

Fig. 1. Functional blocks and interfaces for a conventional BNG.

To address these issues, BBF defined the DBNG in TR-459 to newly specify the functionally separated composition as well as interfaces, as shown in Fig. 2. This DBNG is achieved by separating various BNG functions by the functional groups of the DBNG-control plane (CP) and DBNG-user plane (UP), which are coupled via the newly created interface of the DBNG CP-UP. The DBNG-CP is specified for control-signal processing necessary for subscriber-session establishment while the DBNG-UP is designed for transmission/receipt processing of user data signals. By adopting such a control and user plane separation (CUPS) configuration, telecom carriers can expect much simpler operation of access networks. This is because they can remotely control/manage several DBNG-UPs independently located in multiple facilities from a DBNG-CP at another centralized facility. They can also expect higher usage efficiency of resources because increasing the number of DBNG-UPs at arbitrary facilities becomes possible, and the traffic steering function (SF), which enables traffic assignment to other facilities from the original one, is available as an optional specification. The interoperability between the DBNG-CP and DBNG-UP can be established among different vendors by specifying the DBNG CP-UP interface.

Fig. 2. Newly defined functional blocks and interfaces for the DBNG in TR-459.

Figure 3 shows a conceptual diagram of interfaces between the DBNG-CP and DBNG-UP defined in TR-459: (1) management interface (Mi), (2) state control interface (SCi), and (3) control packet redirection (CPR). The details of each interface are given in Table 1. (1) The Mi is an interface through which the DBNG-CP pushes configurations (i.e., a routing protocol setting) to the DBNG-UP. Retrieving the operation state and notification of alarm between the DBNG-CP and -UP can be achieved through the Mi, the protocol of which is specified as NETCONF/YANG. (2) The SCi is an interface through which the DBNG-CP provides traffic-forwarding rules to the DBNG-UP. The DBNG-CP also receives acknowledgement from the DBNG-UP via the interface. The protocol of the SCi is specified by extending the existing Packet Forwarding Control Protocol (PFCP), which had been globally deployed in mobile systems [9]. (3) CPR is an interface used for the control signals (Dynamic Host Configuration Protocol (DHCP), Point-to-Point Protocol (PPP), and others), which tunnel from V-IF (or A10-IF) to the DBNG-CP through the DBNG-UP. It provides a tunneling function when the DBNG-UP and DBNG-CP are connected via multi-hop networks due to CUPS.

Fig. 3. Conceptual diagram of interfaces between DBNG-CP and DBNG-UP.

Table 1. Details of the interfaces between DBNG-CP and DBNG-UP.

BBF is planning to focus on the promotion and marketing activities of TR-459 as well as the development of detailed specifications of SF.

4. Specifications of BAA

BAA was specified in TR-384 “Cloud Central Office Reference Architecture Framework” and TR-413 “SDN Management and Control Interfaces for Cloud CO Network Functions” [10, 11]. Figure 4 shows a conceptual diagram of BAA based on the information of TR-413. In conventional optical access systems, namely the passive optical network (PON), access equipment such as an OLT is implemented tightly coupled with a controller. Therefore, interoperability cannot be achieved, which results in complicated operations of access systems. To address this issue, BAA in Cloud CO was specified as an abstraction layer so that the SDN controller can control/manage various types of access-equipment hardware from a diverse range of vendors as an abstracted common logical switch through common commands. As shown in Fig. 4, BAA consists of a northbound (NB) layer, which functions as a protocol agent, BAA core layer, which has an abstraction function, and southbound (SB) layer, which works as a protocol library. The BAA core layer and each of the NB and SB layers are connected through NB and SB abstraction interfaces, respectively. BAA is also connected to an SDN controller via M-IF, and to the UP, such as OLTs, via device-specific interfaces. By introducing the above-mentioned configuration, BAA enables command conversion of control/management signals (commands) from the SDN controller to those for the abstracted logical switch. The converted commands are transformed to device-specific commands by a driver in the protocol library, then the commands reach the OLT equipment. Therefore, BAA enables the SDN controller to configure a flow setting of the UP and control FCAPS (fault, configuration, accounting, performance, and security) without having to take into account the difference in hardware-vendor specifications. This enables the establishment of interoperability among various vendors, which leads to simple operation of access systems.

Fig. 4. Conceptual diagram of BAA.

In addition to the development of BAA specifications, BBF is engaged in OSS development to promote it in the near future [12]. Regarding related trends, ONF, which is an OSS development organization, has been leading the access virtualization project of SEBA (SDN Enabled Broadband Access). In this project, an access-abstraction technology of virtual OLT hardware abstraction (VOLTHA) had been proposed and developed in advance of BAA [13]. Although VOLTHA has almost the same functions as those of BAA, it can be applicable to the OpenFlow Protocol and whitebox OLTs [14, 15]. VOLTHA was commercially deployed by Türk Telekom and Deutsch Telekom in 2019 and 2020, respectively, but it is still being developed at ONF for function enhancement.

5. Future prospects

As the latest topic in future access systems, this article reported on the standardization trends in the disaggregation technology of access systems at BBF along with relevant trends in OSS development at ONF. Improvement in the technical maturity and function enhancement of related standardizations and OSS can be expected by reflecting the feedback from future discussions at BBF and ONF as well as telecom carriers who have commercially deployed the disaggregated technology in access systems. NTT will continue joining the discussion at BBF and ONF and contributing to global standardization activities and OSS development by providing requirements from telecom carrier’s point of view.

References

[1]	Ministry of Internal Affairs and Communications (MIC), “Aggregate Results of Internet Traffic in Japan (May 2020),” 2020 (in Japanese). https://www.soumu.go.jp/main_content/000699741.pdf
[2]	ITU-T G.989.1: 40-Gigabit-capable passive optical networks (NG-PON2): General requirements, https://www.itu.int/rec/T-REC-G.989.1/en
[3]	IEEE 802.3ca-2020: IEEE Standard for Ethernet Amendment 9: Physical Layer Specifications and Management Parameters for 25 Gb/s and 50 Gb/s Passive Optical Networks, https://standards.ieee.org/standard/802_3ca-2020.html
[4]	J. Kani, J. Terada, T. Hatano, S. Y. Kim, K. Asaka, and T. Yamada, “Future Optical Access Network Enabled by Modularization and Softwarization of Access and Transmission Functions,” J. Opt. Commun. Netw., Vol. 12, No. 9, pp. D48–D56, 2020.
[5]	K. Asaka and H. Ujikawa, “Standardization Trends of Virtualized Access Systems by the Broadband Forum,” NTT Technical Review, Vol. 16, No. 7, pp. 44–49, 2018. https://www.ntt-review.jp/archive/ntttechnical.php?contents=ntr201807gls.html
[6]	BBF TR-402: Functional Model for PON Abstraction Interface, https://www.broadband-forum.org/download/TR-402.pdf
[7]	BBF-TR-403: PON Abstraction Interface for Time-Critical Applications, https://www.broadband-forum.org/download/TR-403.pdf
[8]	BBF TR-459: Control and User Plane Separation for a disaggregated BNG, https://www.broadband-forum.org/download/TR-459.pdf
[9]	3GPP TS 29.244: Interface between the Control Plane and the User Plane nodes, https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=3111
[10]	BBF TR-384: Cloud Central Office Reference Architecture Framework, https://www.broadband-forum.org/download/TR-384.pdf
[11]	TR-413: SDN Management and Control Interfaces for Cloud CO Network Functions, https://www.broadband-forum.org/download/TR-413.pdf
[12]	OB-BAA, GitHub, https://github.com/BroadbandForum/obbaa
[13]	VOLTHA, ONF, https://opennetworking.org/voltha/
[14]	Press release issued by BBF, “Broadband Forum and ONF ease the path to automated and open virtualized access networks,” Oct. 14, 2019. https://www.broadband-forum.org/2019-10-14-broadband-forum-and-onf-ease-the-path-to-automated-and-open-virtualized-access-networks
[15]	VOLTHA-EPON OLT adapter, GitHub, https://github.com/opencord/voltha-eponolt-adapter