 |
|||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||
|
Global Standardization Activities Vol. 16, No. 7, pp. 44–49, July 2018. https://doi.org/10.53829/ntr201807gls Standardization Trends of Virtualized Access Systems by the Broadband ForumAbstractVarious organizations are studying the introduction of virtualization technologies to access systems in order to achieve flexible, agile, and cost-effective adaptation of access networks to a diverse range of services. This article reports on the standardization trends of virtualized access systems by the Broadband Forum (BBF) and explains related activities happening at the NTT laboratories. Keywords: BBF, optical access, virtualization  1. Requirements of future access systemsStandardization of the 10-Gbit/s-capable passive optical network (PON) was carried out in order to meet the large demand for high capacity transmission in future optical access systems [1, 2]. In addition, 40-Gbit/s-capable PON, known as Next-Generation Passive Optical Network Stage 2 (NG-PON2), has also been standardized and can support up to 80 Gbit/s [3]. With conventional optical access systems, focus was placed on enhancing transmission capacity to accommodate the rapidly growing traffic. However, NG-PON2 was specified in order to accommodate various services (e.g., enterprise and mobile services) in addition to the fiber-to-the-home (FTTH) service. In light of this background, future access networks are expected to flexibly address further diverse emerging services such as those related to the Internet of Things and edge computing. Future access systems should therefore be flexibly and quickly provided at a low cost to meet various service requirements (bandwidth, latency, reliability, etc.), which might be different for each service. The use of virtualization technology rather than conventional purpose-built access equipment to achieve such a future access system is attracting a lot of attention from the broadband access industry. Such technology would enable access functions by using commodity hardware (servers and switches) and software components [4, 5]. To establish a virtualized access system, it is important that consolidated access functions inside the equipment are disaggregated to each functional module based on the standardized architecture and interfaces in order to achieve practical future deployment and assured interoperability. 2. Broadband Forum (BBF)BBF is a nonprofit industry consortium established in the United States in 1994. It was formerly known as the ADSL (Asymmetric Digital Subscriber Line) Forum. In 2008, the organization widened its scope to include optical access networks and changed its name to Broadband Forum accordingly [6]. Since then, BBF has contributed to broadband access industries and earned a 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). BBF is composed of more than 150 companies/organizations, which include telecom carriers, multiple service operators, system vendors, ASIC (application specific integrated circuit) vendors, interoperability test labs, and others from around the world. The organization chart of BBF is shown in Fig. 1. The Service Provider Action Council discusses various technical topics and directions that are driving BBF. Each Work Area (WA) in the Technical Committee discusses corresponding technical specifications based on the topics and provides TRs as their deliverables, which are disclosed on the BBF homepage [7]. As shown in the figure, three WAs focusing on Common YANG (Yet Another Next Generation), SDN and NFV (Software Defined Networking and Network Functions Virtualization), and Fiber Access Networks (FAN) are working intensively on the development of specifications related to virtualized access systems.
3. Standardization trends of virtualized access systems by BBFThe deliverables and documents being developed by BBF that are related to virtualized access systems are summarized in Table 1. In the leftmost column (document number) in Table 1, WT stands for Working Text, which is a draft for a future TR that is disclosed only to BBF members. As indicated in the table, BBF is actively developing various documents such as those concerning NETCONF (Network Configuration Protocol), YANG models (modules), and Cloud CO (Central Office) specifications. These are explained in more detail in the following subsections.
3.1 Standardization of NETCONF/YANG model (module)NETCONF is a configuration protocol of network equipment and was developed to remotely conduct configuration and management functions in distributed equipment from a centralized SDN controller. The YANG model is a common data-modeling language that abstracts a structure and the configuration values of each piece of network equipment. Using NETCONF and a YANG model makes it possible to achieve interoperability between network equipment and a controller from various system vendors. In July 2016, BBF launched the first specifications of a YANG module for a fiber-to-the-distribution point (FTTdp)*1 system as TR-355 (Table 1). Since then, BBF has been developing several YANG models (Note: each model consists of several modules) for PON systems, optical network units, access nodes, and home networks, as indicated in Table 1. 3.2 Cloud COCloud CO is a project that was proposed and agreed to at the BBF meeting in July 2016. The objective of the project is to develop specifications for next-generation COs (telecom carrier central offices that contain network equipment) that use SDN/NFV and cloud technologies. Similarly to Central Office Re-architected as a Datacenter (CORD)*2 developed at the Open Networking Foundation (ONF), Cloud CO will lead to the re-architecting of COs through the use of commodity hardware, softwarized CO functions, and controllers. Furthermore, inter-CO configuration and management can be achieved by using an orchestrator located in a cloud layer. This innovative architecture is expected to lead not only to a reduction in capital expenditures and operating expenses (CAPEX/OPEX) but also to flexibly and agilely provide emerging services. A reference architecture of Cloud CO is shown in Fig. 2. This architecture was created based on the authors’ understanding of some figures and corresponding content of BBF TR-384 (Table 1). In Fig. 2, the CO and the network between the CO and the customer’s premises are called the Cloud CO Macro-Node. They are composed of network input/output (NW I/O), (network functions virtualization infrastructure (NFVI), access nodes (e.g., optical line terminal (OLT) hardware), CPE (customer premises equipment), and a hardware abstraction layer (HAL). The NW I/O is an interface between Cloud CO Macro-Node and a metro network. Similarly to CORD, the NFVI consists of white box switch (SW) fabric (leaf/spine SWs in Fig. 2) and compute nodes based on commodity servers where virtual network functions (VNFs) are implemented. Using the NFVI approach makes it possible to simplify network equipment by operating some network functions as VNFs on commodity servers. HAL is an abstraction layer that enables vendor-agnostic interoperability between SDN Management & Control (M&C) and the access node. SDN M&C controls flow and FCAPS (fault, configuration, accounting, performance, and security) functions located in physical network functions (PNFs) in the access node and in VNFs in the NFVI. Furthermore, it controls the SW fabric in NFVI.
In Fig. 2, SDN M&C is depicted above Cloud CO Macro-Node for the sake of simplicity, although TR-384 does not specify its location. In the upper layer, the Cloud CO architecture has MANO (management and orchestration), which manages NFVIs, and Cloud CO Domain Orchestrator, which achieves inter-CO orchestration. As indicated in Table 1, the Cloud CO project will release several deliverables related to TR-384 as an umbrella document. These deliverables include interface specifications of functional modules (WT-411), test cases for Cloud CO applications (WT-412), and migration to SDN-enabled management and control (WT-413). In addition, the project is drawing considerable attention from the broadband access industry and will cover reference software/hardware implementation documents.
4. NTT’s activities in BBFIn February 2016, the NTT laboratories introduced the Flexible Access System Architecture (FASA) concept for technology development on future access networks in order to enable a more diverse range of services provided quickly and at low cost [8]. Rather than using conventional purpose-built access equipment, FASA will modularize the various individual functions of access equipment as much as possible to enable the free combination of these individual software components on commodity hardware. This will allow for software-based functions to be built into the commodity hardware flexibly and quickly as required for services, while still maintaining the same service quality. To achieve FASA, it is necessary to introduce an application programming interface (API) between each software component and the commodity hardware. Since APIs should be commonly usable by various players (system vendors, carriers, etc.), the NTT laboratories released an API set in a FASA White Paper [9]. In addition to flexible control & management functions for future access systems as in CORD and Cloud CO, FASA is intended to achieve the modularization (disaggregation) of time-critical functions in order to achieve updates and/or replacement of those functions. In October 2016, at the meeting of FAN WA of BBF, members of the NTT laboratories proposed a new project called “PON abstraction interface for time-critical applications (TC Apps)” and agreed to start it with support from several carriers and vendors. The disaggregation policy of time-critical PON functions discussed in the project is shown in Fig. 3. As shown in the figure, TC Apps will disaggregate time-critical functions (e.g., dynamic bandwidth allocation (DBA)), which remain as PNFs in Cloud CO (TR-384). According to the policy depicted in Fig. 3, the time-critical function will be disaggregated to a differentiation part, which leads to software replacement based on service requirements, and a common behavior part as an engine. Furthermore, APIs between the two parts are under discussion to be specified as standards. The relevant documents of TC Apps are WT-402 and WT-403 in Table 1.
Using the modularization technology even in time-critical functions that require wire-rate processing will make it possible to achieve a flexible and agile adaptation to emerging services on access networks by replacing software components according to service requirements. An attractive use case of TC Apps is mobile fronthaul (MFH) for fifth-generation (5G) or beyond 5G mobile service over a time-division multiplexing (TDM)-PON system. In future mobile systems, dense small cells could be accommodated by the use of the PON architecture, which has an advantage in terms of low CAPEX of physical infrastructure [10]. In this case, by replacing the DBA software from FTTH-DBA to low-latency DBA in the OLT, TDM-PON-based MFH can be achieved without rebuilding the OLT from scratch. This would result in flexible and agile adaptation of an optical access system to mobile services by replacing softwarized time-critical PON functions. At the BBF meeting in Osaka held in June 2018 as shown in Fig. 4, members of the NTT laboratories successfully demonstrated their prototype mobile PON system, which implements DBA-API specifications being developed in WT-402 and 403 [11].
5. Future prospectsThis article reviewed the standardization trends of virtualized access systems by BBF. As a result of the active technical discussions that have taken place, BBF will publish several specifications as TRs in the near future. In line with the progress of virtualization technology, open source software (OSS) is also being intensively developed for VNFs that are necessary in virtualized access systems. The NTT laboratories will continue to contribute to international standardization efforts by leading our project at BBF, and to OSS development at ONF as well. References
|
|||||||||||||||||||||||||||
