June 2019

By Sagar Nangare, Principle Executive – Digital Marketing, Calsoft Inc.

Network slicing is an innovative network architecture technology that’s also one of the most exciting promises of 5G telecom networks.

Imagine a single spectrum of the network that can be divided logically for different use cases with specific characteristics and network requirements like latency, high bandwidth, security, etc.

Plus, services in those different slices can be managed separately, enabling privacy and dedicated bandwidth to run critical operations. The technology also offers huge performance boosts for specific use cases, such as industrial internet of things, autonomous driving, and more.

There are various annotations about the standardization about NS from various vendors. However, currently, various proof-of-concepts are undergoing to test the operations, performance and basic and ready-to-run architectures for NS.

PoCs and analysis conducted in communities like OpenStack and ETSI OSM have come to some conclusions around network slicing and its readiness. Experts note that end-to-end virtualization, dynamic centralized orchestration and quality-of-service manageability are basic requirements for successful NS implementation.

Last year at the OpenStack Summit in Vancouver, architects Curtis Collicutt and Corey Erickson evaluated OpenStack networking projects for network slicing implementation. More recently at the Mobile World Congress 2019, Telefonica and Telenor collaborated to demonstrate orchestration of network services like enhanced mobile broadband (eMBB) and ultra-reliable low-latency communications (URLLC) in network slicing environments.

Let’s take a look at the capabilities of Open Source MANO (OSM) and OpenStack for network slicing.

Orchestrating 5G network slices with OSM

The latest release 5 of ETSI OSM came with major enhancements to support network slicing features. OSM has integrated slice manager and extended information model for network slicing template (NST) and network slice instance (NSI).

Having a common information model is a vital feature of OSM. Modelling across different entities like network function packages (VNF, PNF and hybrid NFs), network service packages and network slices packages help to overcome complex network operations for repetitive function and drastically simplify and automation daily operations. OSM network slice feature with its IM allows network services to stay self-contained and agnostic to technology infrastructure for completely different network characteristics in each service.

The proof-of-concept demo included the deployment of two network slices with some input parameters and operating them through day-2 operations at the network slice level.

Deployment

• Each slice is modeled as a set of network services connected by networks or VLDs
• Simple input parameters determine the type of slice to be created on demand
• The two slices share some network services (shared NS Subnets)
  • If the shared NS has already been deployed, it won’t be re-deployed
  • It will be reused, but the initial configuration for the second network slice can still be done in the shared NS to let it know that new elements are present.

Operation

Running day-two primitives at Network Slice level (handled as a single object)

• OSM, behind the scenes, maps them to a sequence of calls to NS primitives, which, in turn, are derived in calls to VNF primitives

Here’s a graphic of how it works. Slice one is dedicated to enhanced mobile broadband (eMBB) and slice two is for enhanced mobile broadband (eMBB) use cases.

OpenStack support for network slicing

In the last two years, OpenStack has focused on support to fulfill orchestration and infrastructure management requirements for telco cloud. The software contains various projects across networking and compute domains that can be utilized for various aspect required in network slicing.

As discussed in a session by Interdynamix architects, OpenStack can be focused to satisfy quality of service, isolation, segregation, sharing networks and automation/orchestration via Neutron APIs.  OpenStack, in this use case, is mainly highlighted for policy and scheduling features in its projects like Neutron for networking and Nova for compute. OpenStack’s group based policy (GBP) is suggested to be used for network slicing. It can be responsible for enabling self-service automation and application scaling, separation of policies for slices, managing security requirements, etc.

Complementary OSF projects like StarlingX and Zuul also have capabilities that align to support 5G network slicing.