Neglected Factors in 5G: SDN-R & Wireless Transport SDN

Software-Defined Networking (SDN) concepts are alive and well in the indomitable march to 5G. Control plane to data plane separation, network programmability, and closed-loop automation techniques are being defined, developed and tested in numerous PoCs and early trials. The specification bodies and open source organizations are cooperating to define the architectures and protocols required for next-generation wireless. One of the more prominent open source projects in the 5G space is ONAP (the Linux Foundation’s Open Network Automation Project) which is developing the SDN-C and APP-C controllers, based on OpenDaylight. More recently, ONAP is working to develop the OpenDaylight-based SDN-R controller, which is the focus of this article.

The SDN-R project is aimed specifically at wireless transport SDN. “Transport SDN” is the concept of multiplexing and carrying multiple services or network slices across the backhaul network, usually over a geographic distance, a fundamental concept in 5G networking. The “R” stands for radio. SDN-R is concerned specifically with coordinating the functionality needed to support services traversing Optical or Microwave networks. Although a new group in ONAP, SDN-R builds on several years of work and earlier trials within the ONF (Open Networking Foundation). This is welcomed cooperation between two different standardization groups, something we need to see more of in the orchestration space.

SDN-R Diagram SDN-R Diagram

The original proof of concept trial focused on the ONF’s OpenFlow interface as the controller protocol. However, more recent PoCs have also utilized NETCONF and have focused on the information models as well as YANG. The concept of a mediator has been introduced, recognizing the reality that there will be a wide variety of vendor equipment, both PNFs and VNFs, used with a variety of interfaces and APIs. Lumina’s SDN Controller architecture is ideally suited to create mediators and have them function as a model translator for OpenDaylight.

As the SDN-R project proposal explains very clearly, the objective is to port the models and controller of the ONF Wireless Transport project into the ONAP framework. Since starting in 2015, the Wireless Transport Project within the Open Transport group of the ONF has pursued the goals of defining a shared data model for wireless network elements and developing a Software-Defined Network (SDN) controller to manage a network made up of equipment from several manufacturers. The model is defined in the ONF Technical Reference TR-532, and the SDN controller is based on OpenDaylight. Because the controller is based on OpenDaylight, it is consistent with the ONAP architecture, and the majority of the software for the applications can be ported into ONAP with only minor modifications.

Lumina Networks looks forward to continuing our contributions to the SDN-R and to ONAP broadly. The development of 5G networking is complex, as it will involve a combination of new and old equipment, VNFs and PNFs, virtual machines and containers and vendor equipment based on new standards as well as equipment based on proprietary APIs. 5G services will need to be applied end-to-end consistently across all of these and with closed-loop automation to provide service assurance.

The SDN-R leverages Lumina’s development and deployment experience with NETCONF. NETCONF interfaces are the most commonly deployed for Lumina’s customers and we have experience dealing with voluminous YANG models in production, and as always, we have contributed our efforts back into the open source community. Specifically, for SDN-R, the NETCONF/YANG constructs give us the ability to manage the transport service end-to-end in addition to device-by-device. And, as regards to devices, we have developed the tools and software to extend control to non-NETCONF devices as well, so that legacy equipment can be used for SDN transport.

As we have established in our Neglected 5G series blogs (below), the only way to achieve this type of architecture is with an open source control plane, most often based on OpenDaylight. Therein lies the neglected factors in 5G – that is, while much of the 5G network will be new, the only way to achieve cost-effective deployment in a reasonable timeframe will be by using existing protocols and already-installed systems wherever possible. Building on what we already have and bringing to its open source-based control and orchestration software will be the formula that makes 5G possible for most service providers.

Learn more about the neglected 5G factors:

  1. Neglected Factors in 5G: Network Slicing
  2. Neglected 5G Factors: How SDN will Enable Brownfield Deployments