5G: How many Slices? Few or many … that is the question

[MP_odini]

Network Slicing: the most promising 5G use case for digital infrastructure

Part #3 – 5G: How many Slices? Few or many … that is the question !!

This blog is a series of blog on network slicing and slice management

We talked about 5G Network Slicing in the previous Blog #1 [4] and #2 [5] , mainly about Architecture. Now let’s look into use case architecture options.

As mentioned before, 3GPP [1] has defined a slice identifier that the device would know, NSSAI. This identifier is composed of 2 parts: SST (Slice Type) and SD (Slice Differentiator). And 3GPP has standardized in Release 15 three types of slices: SST 1 for eMBB, SST2 for uRRLC and SST3 for mMTC (IoT). Now remain all the other settings, either to be standardized in Release 16 or follow up release or to be customized by the industry. So how many different slices could we have??

Up to 1 Million Potential Slices ...

If we stick to these SST and SD, we end up with over … 1 Million slices with different SST-SD possible NSSAI. Which leaves room for creativity in terms of use cases!!

Then let’s look at the slice composition at the macro level: Access network, transport, core network and potentially services like IMS. Each of these components can be a subnet, served by one or multiple operators, in a dedicated or shared mode. If we only consider this example, we have 384 options !

Network Slices versus Customer Services

Then comes the question about selling those slices … and mapping network slices as defined by 3GPP and GSMA with customer services that can be put in a catalog with an SLA and a price.

Defining Slice type parameters

Today the GSMA [2] GST and NEST template for network slicing provide a number of parameters that definitely help to define a network slice. These include downlink throughput, energy efficiency, isolation level, maximum supported packet size, availability, radio spectrum, etc.

Slice parameter
Deterministic communication	Positioning support
Downlink throughput per network slice	Radio spectrum
Downlink throughput per UE	Reliability
Maximum Downlink Throughput	Root cause investigation
Energy Efficiency	Session and service continuity support
Group communication support	Simultaneous use of the network slices
Isolation level	Slice quality of service parameters
Location based message delivery	Support for non IP traffic
Maximum supported packet size	Supported access technologies
Mission critical support	Supported device velocity
MMTel support	Synchronicity
Network slice customer network functions	Terminal density
Number of connections	Uplink monitoring per network slice
Number of terminals	Uplink throughput per UE
Performance monitoring	User data access
Performance prediction	V2X communication model

However some of these are not necessary useful for the customers, especially some enterprise customers or verticals that are not so familiar with telecom networks. Of course it is different with MVNO for instance. Consequently it is quite important for Communication Service Providers (CSP) to define what kind of services they would like to offer with proper parameters as required by the service and customer requirements, and map those services to certain slice types or categories with certain parameters to actually deploy the slice. GSMA GST & NEST can be leveraged to define those slice types and parameters.

eMBB, mMTC and uRRLC - 3 slice types - not sufficient ??

ATIS has recently issued a report [3] looking into IoT applications and slice type they would map to, starting with the classical eMBB, mMTC and uRRLC types. They quickly found out that those types were too generic and that other types could be defined, for instance for applications that require eMBB but with low latency (ie VR headsets) or uRRLC but with high bandwidth (ie High Resolution Video cameras) , but also very specific set of slices like V2X. they suggested typically a new category that they call  HMTC for “High-Performance Machine-Type Communications”.

This report is particularly interesting because it expands on the concept defined by 3GPP that they could be many different types of slices, beyond the eMBB, mMTC and uRRLC, some of those being standardized to enable cross operator E2E services and interoperability or roaming – but this allow also slice types to be defined by Service Providers as part of their service catalog. 

This also re-inforce the need to define some standard parameters to describe those slice types that Service Providers can use but also that customers can request, update or monitor – as defined by GSMA GST.

Marie-Paule Odini
Hewlett Packard Enterprise

twitter.com/HPE_Telco
linkedin.com/company/hewlett-packard-enterprise
hpe.com/solutions

References:

[1]         3GPP TS 29.571 – 5G Systems; Common Data Types for Service Based Interfaces

[2]         GSMA Network Slice Template – Version 1.0 – May 2019

[3]         ATIS - IOT Categorization: Exploring the Need for Standardizing Additional Network Slices – September 2019

[4]         Blog #1 - 5G Network Slicing: the most promising 5G use case for digital infrastructure

[5]         Blog #2 - 5G Network Slice Management and Orchestration