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.
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.”