Tech Insights
Showing results for 
Search instead for 
Did you mean: 

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

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


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


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


[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

0 Kudos
About the Author


5G, IoT, NFV, big Data, blockchain

Starting June 23
HPE Discover Virtual Experience
Joins us for HPE Discover Virtual Experience live and on-demand
Read more
Online Expert Days - 2020
Visit this forum and get the schedules for online Expert Days where you can talk to HPE product experts, R&D and support team members and get answers...
Read more
View all