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

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 for 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

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 this blog series, 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

Deploy-5G-in-a-brownfield-environment

Neglected Factors in 5G:  Network Slicing

Neglected Factors in 5G: Network Slicing

It may seem odd to long-time networkers that “slicing” is discussed extensively in relation to 5G deployment. After all haven’t we been using VLAN, VPNs, VRFs and a whole host of ways to slice and dice networks for many years? Keep in mind that for established 4G networks, there has been no easy way to create logical segments or divide the network into granular slices, even in cases where the equipment may be capable of it. While legacy services hosted MBB, voice, SMS and even MVNOs on the same infrastructure, it was built in a way that was either physically discrete, channelized or rigid – not the way a packet network, and thus 5G, would do things. This approach is monolithic and will need to be updated for successful 5G deployments.

With packet networking, software-defined networking and network function virtualization coming into the network buildouts for 5G, network slicing is becoming an important part of service agility. The power of 5G is not just in higher-data rates, higher subscriber capacity and lower latencies – it is in the fact that services and logical networks can be orchestrated together. This is critical for deployment of connected car, IOT (Internet of Things), big data and sensor networks, emergency broadcast networks and all the amazing things that 5G will be able to support.

But there’s an often-overlooked element of the 5G rollout, slicing deployment over existing equipment, is something that Lumina Networks is uniquely equipped to enable.

Most presentations that you will see on 5G (especially from the vendors) just assume that the provider will be buying all-new hardware and software for the 5G buildout. In reality, a lot of existing equipment will need to be used, especially components that are physically distributed and expensive or impossible to access. How will the new network slices traverse these legacy devices?

Network slicing will traverse from the mobile edge, continue through the mobile transport, including fronthaul (FH) and backhaul (BH) segments, and the slices will terminate within the packet core, probably within a data center.  Naturally, this will involve transport and packet networking equipment in both the backhaul and fronthaul network. The packet core will also likely involve existing equipment. These systems will rely on the BGP protocol at the L3 transport networking layer, even when they are newer platforms.

The 3GPP organization’s definition of a slice is “a composition of adequately configured network functions, network applications, and the underlying cloud infrastructure (physical, virtual or even emulated resources, RAN resources etc.), that are bundled together to meet the requirements of a specific use case, e.g., bandwidth, latency, processing, and resiliency, coupled with a business purpose”

Given the number of elements involved in a slice, sophisticated cloud-based orchestration tools will be required. It’s noteworthy that many of the optical transport vendors have acquired orchestration tools companies to build these functions for their platforms. However, since the start of the Open Network Automation Project (ONAP) at the Linux Foundation, it is clear that the service providers will demand open-source based platforms for their orchestration tools. Rightfully so, an open solution to this problem reinforces operators’ desire to end vendor lock-in and enable more flexible, service-creation enabled networks.

The creation of a “slice” in a 5G network will often involve the instantiation of relevant and dedicated virtual network functions (VNFs) for the slices and this is a key aspect of the work going on in the ONAP project. VNFs, in addition to participating as connectivity elements within the slice, will provide important functions such as security, policies, analytics and many other capabilities.

5G-Network-Slicing

The good news here is that established open source projects such as OpenDaylight have the control protocols that will be used for legacy equipment, such as NETCONF, CLI-CONF, BGP-LS and PCEP, as well as the newer protocols that will be used for virtual L3 slicing such as COE and OVSDB.

Some of the network slicing capabilities that these protocols enable are:

  • Supporting end-to-end QoS, including latency and throughput guarantees
  • Isolation from both the data plane and orchestration/management plane
  • Policies to assure service intent
  • Failure detection and remediation
  • Autonomic slice management and operation

ONAP utilizes the OpenDaylight controller as it’s “SDN-C”. And, more recently ONAP has a new project to develop an OpenDaylight SDN-R to configure radio transport services.

This blog series, “Neglected 5G Factors” will address  SDN-R more our next blog. For now, be sure you’ve read the first of the series “How SDN will Enable Brownfield Deployments.”

Deploy-5G-in-a-brownfield-environment

Neglected 5G Factors: How SDN will Enable Brownfield Deployments

Neglected 5G Factors: How SDN will Enable Brownfield Deployments

There’s a lot to consider in 5G service roll-out, but there are a few key areas that are often overlooked. Lumina Networks feels a responsibility to the community to illuminate the truth behind 5G transformation, to highlight these overlooked “secrets” which can make-or-break your 5G strategy. The factors you’ll read about in this blog series have a drastic impact on a service providers digital transformation – they are the software-defined networking components that play a critical role in making 5G services possible and accelerating deployments.

5G DeploymentAs an industry, we’ve all agreed long ago the agility needed to run 5G services will come from a more software-based network. While virtualized components and functions are powerful tools in enable flexibility, we need to deploy 5G in brownfields, not green.

It’s with this in mind that the first factor which requires more consideration is the role legacy, purpose-built infrastructure needs to play in performing the functions necessary for 5G services. We call this use case SDN Adaption. Adaption involves providing a common control plane for different types of networks. In network services prior to 5G it would be acceptable to provision and configure each part of the network separately, taking days or even weeks. You can understand why this area is often overlooked in the market conversation as large vendors with a lot at stake, and substantial marketing budgets, prefer to keep it that way.

By necessity, 5G networks will be “intent-based” networks where the end-to-end service will be defined in a high-level language such as TOSCA (Topology and Orchestration Specification for Cloud Applications). The instantiation or configuration of the network functions beneath that, whether virtual or physical, will be automated. Closed-loop operational monitoring will help assure that the service meets the pre-defined SLA.

The common control plane needed to configure and monitor the network elements works in two different ways.

Container orchestration for virtualized applications

 

The services behind 5G will be “cloud-ready”, that is they will be container-based and leverage microservices.  They will also need to be orchestrated (see our blog on what it means to be cloud ready). OpenDaylight’s Container Orchestration Engine (COE) project is a vital tool in orchestrating the network components for container-based applications. The COE project, led by Lumina’s own Prem Sankar Gopannan is designed to provide L2 and L3 networking between containers or between containers and virtual machines for Kubernetes-managed environments. COE includes interfaces to KVM and Containers and OpenStack (via Kuryr). A northbound CNI is available for bare-metal based containers.  This is important for micro-datacenters where compute resources are scarce. As such, COE can support a variety of use cases where cloud-based networking is required such as in 5G services networks.

Tying Existing Routers to 5G Services

While COE takes care of the future, what about the past?  That is, what about equipment that is already installed or VNFs that are based on legacy network OS’s? There’s good news on this front as OpenDaylight and now COE specifically will support the NETCONF control interface that is common on today’s hardware and software routers. NETCONF is a stateful control interface that was designed to allow an external controller to manage the configuration of routers. NETCONF is optimized for routers that publish YANG information models and is a commonly supported interface for Cisco, Juniper and other types of switches common in 5G front haul and backhaul networks.

Putting the above two capabilities together, it is possible to orchestrate both the virtual and physical network elements to create the network slices and intent-based services necessary for 5G. OpenDaylight is a particularly well-suited controller to implement for 5G networks because it has both COE and NETCONF support, as well as a variety of other common control interfaces. This type of multi-cloud and multi-protocol support is absolutely essential for being able to leverage the existing network for 5G services.

Realizing this type of virtualized network architecture is the future, our major tier-1 CSP partners are already aligning to the new network architecture. In fact, AT&T has already been working on this for several years.  

In my next blog, we will delve into a common 5G use case that depends upon this type of converged network architecture.

Deploy-5G-in-a-brownfield-environment

 

Pin It on Pinterest