Technical Analysis of CloudCO Architecture

 

Background  

Telecom operators long for a network that is adaptive, flexible, scalable and dynamic. They need the network's ability to facilitate the development and launch of new services to help them reduce Capex and Opex. Cloud-based telecom network, a product of the convergence of IT and CT sectors, is expected to fulfill the operators’ objective and has attracted widespread industry attention.

The maturing of software-defined networking (SDN) and network functions virtualization (NFV) technologies in recent years lays the foundation for designing and deploying networks with a cloud architecture. As the main standards body for broadband access, the Broadband Forum (BBF) released the TR-384 Cloud Central Office Reference Architectural Framework in January 2018, which provided a standard for operators to re-architect their broadband networks.
The cloud central office (CloudCO) architecture aims to build a general-purpose cloud broadband platform that has open interfaces and serves both wireline and wireless networks. This can be achieved by leveraging generic data center (DC) style resources including computing, storage and switching equipment to re-architect the access and metropolitan area networks. To allow for the reuse, convergence and evolution of existing networks, the central office (CO) should be the best place where the cloud platform is deployed.
The CloudCO architectural framework fully considers the smooth evolution strategy as well as the  compatibility with existing networks to enable co-existence of traditional networks and CloudCO networks. Therefore, the CloudCO architecture is capable of providing operators with a feasible cloud network evolution solution. 

Technical Analysis  
The CloudCO reference architecture specified in BBF TR-384 is shown in Fig. 1. A CloudCO is deployed as a domain and can be viewed as a hybrid architecture combining physical infrastructure and network functions virtualization infrastructure (NFVI). In other words, virtual network functions (VNFs) residing in NFVI connect the access and network sides through physical network functions (PNFs) to provide external services. End-to-end services are scheduled and orchestrated by a CloudCO domain orchestrator or even by a service chain that may involve multiple CloudCO domains.
The CloudCO architecture has the following benefits:
● Granular control of system-level network and service design by decoupling the traditional network equipment into independent standard network functions
● Better flexibility and scalability by deploying virtual network functions
● Automatic and fast service deployment and go-live by orchestrating services.
The main functional modules of the CloudCO reference architecture are the CloudCO domain orchestrator, NVF orchestrator, PNF SDN manager & controller, VNF SDN manager & controller, DC SDN manager & controller, and broadband access abstraction (BAA) layer.
The CloudCO domain orchestrator is the core of the entire CloudCO domain. Externally, it provides services through northbound application programming interfaces (NB APIs). Internally, it centrally schedules the available resources in the CloudCO domain to satisfy service requests. For example, it selects and configures the needed PNF and VNF instances, or establishes the service chain forwarding path between the PNF and VNF instances. On top of individual CloudCO domain orchestrators usually exists an end-to-end (E2E) service orchestrator that provides operators with a view of the whole service chain and performs higher-level E2E service orchestration such as CloudCO domain selection, inter-CloudCO-domain connection and intra-CloudCO-domain service orchestration.
The main components of the CloudCO domain orchestrator are the NFV orchestrator (NFVO) and management control orchestration (MCO) engine. The NFVO is responsible for NFVI resource orchestration across virtualized infrastructure managers (VIMs) and for lifecycle management of network functions (NFs). The MCO engine oversees a continuum of tasks related to the CloudCO domain: resource/status orchestration, traffic flow management and control, and CloudCO state transition and supervision. The engine performs interaction between service level systems (such as E2E service orchestrator and OSS/BSS) and the CloudCO domain. It exposes upwards the topology and status of a hybrid network comprising PNFs and instantiated VNFs in the CloudCO domain via the NB API, and runs downwards the tasks delivered by the NB API through the southbound interfaces (SBIs) oriented to the PNF managers & controllers, VNF manager & controllers and DC SDN managers & controllers.
The PNF SDN manager & controller, VNF SDN manager & controller, and DC SDN manager & controller govern their respective resources in the CloudCO domain. The PNF SDN manager & controller is responsible for PNF devices, the VNF SDN manager & controller for VNFM-based VNF instances, and the DC SDN manager & controller for NFVI resources.
The BAA layer is a highlight of the CloudCO architecture. The layer exposes, via a standard NB API, a simplified functional view of access devices which is independent of vendors or even independent of specific access technology. The BAA layer helps those access PNFs not complying with the CloudCO interface standard such as the PNFs provided by traditional devices to be managed by the PNF SDN manager & controller, so that the evolution to CloudCO can be completed. The functional block diagram of the BAA layer defined in TR-384 is shown in Fig. 2.

The southbound layer of the BAA layer contains device driver plugins that support communication with the access device of multiple vendors and types in the network. In the northbound direction, the device drivers only have to comply with the southbound abstraction interface (SAI) which is the standards-based interface between the BAA core and the access devices. In the southbound direction, the device drivers can use private interfaces to interwork with specific devices. The northbound layer of the BAA layer communicates with one or several control and management elements which may include access network controllers, SDN controllers and orchestrators. The elements can communicate with the BAA core functions via different protocols.
The BAA layer can be implemented in several ways. It can reside in NFVI of the CloudCO domain as a software function instance, or in a physical access device as a means to upgrade the device. Wherever the BAA layer resides, it must meet the related CloudCO architecture requirements, such as those concerning go-live of virtual functions and the lifecycle orchestration.
 
Development Trends

Since the TR-384 CloudCO architectural framework was released in January 2018, BBF's CloudCO project team has forged ahead with the subsequent standardization work. The following CloudCO standards have been initiated and are being drafted by BBF:
● CloudCO migration and co-existence (WT-408); migration to SDN-enabled management and control (WT-413)          
● Definition of interfaces between CloudCO functional modules (WT-411)         
● Test cases for CloudCO applications (WT-412)     
● Use cases and scenarios for CloudCO (WT-416)    

The following CloudCO application notes are being discussed by BBF:
● Bootstrapping an NFVI to a cloud central office 
● Establishing high speed internet access (HSIA) service 
● Network enhanced residential gateway (NERG) service initialization with flat logical subscriber link (LSL) connectivity 
● Network enhanced residential gateway (NERG) service initialization with overlay logical subscriber link (LSL) connectivity
● Activation and initial provisioning of access devices 
● Virtual access node (vAN)-based FANS service
● SDN-based FANS service 
In addition, BBF has launched the Open Broadband-Broadband Access Abstraction (OB-BAA) initiative, an open source project that BBF hopes can provide a reference implementation of the BAA layer. The initiative is intended to incorporate different access network (AN) devices, including traditional AN equipment, into a single network management and control domain and expose them to the SDN manager & controller and EMS.

As an important member of BBF, ZTE has long been part of its discussions, proposals and reviews on broadband access standards. The CloudCO project, currently a priority for BBF, has also gained full support and participation of ZTE.