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