The Evolution of 3GPP 5G Network Slice and Service Types (SSTs)

The concept of network slicing has been one of the standout features in 5G (no pun intended). It allows operators to offer logically isolated networks over shared infrastructure, each tailored for specific applications or services. These slices are identified using a combination of the Slice/Service Type (SST) and an optional Slice Differentiator (SD), together forming what is called a Single Network Slice Selection Assistance Information (S-NSSAI).

To ensure global interoperability and support for roaming scenarios, 3GPP standardises a set of SST values. These are intended to provide common ground across public land mobile networks for the most prevalent slice types. Over the course of different 3GPP releases, the list of standardised SST values has grown to reflect emerging use cases and evolving requirements.

The foundation was laid in Release 15, where the first three SST values were introduced. SST 1 represents enhanced Mobile Broadband (eMBB), suitable for high throughput services like video streaming, large file downloads and augmented reality. SST 2 refers to Ultra-Reliable and Low-Latency Communications (URLLC), designed for time-sensitive applications such as factory automation, remote surgery and smart grids. SST 3 is for Massive Internet of Things (mIoT - earlier referred to as mMTC), tailored for large-scale deployments of low-power sensors in use cases such as smart metering and logistics.

The first major extension came with Release 16, which introduced SST 4 for Vehicle-to-Everything (V2X) services. This slice type addresses the requirements of connected vehicles, particularly in terms of ultra low latency, high reliability and localised communication. It was the first time a vertical-specific slice type was defined.

With Release 17, the slicing framework was extended further to include SST 5, defined for High-Performance Machine-Type Communications (HMTC). This slice is aimed at industrial automation and use cases that require highly deterministic and reliable communication patterns between machines. It enhances the original URLLC profile by refining it for industrial-grade requirements.

Recognising the growing importance of immersive services, Release 18 added SST 6, defined for High Data Rate and Low Latency Communications (HDLLC). This slice targets extended reality, cloud gaming and other applications that simultaneously demand low delay and high bandwidth. It goes beyond what enhanced Mobile Broadband or URLLC individually offer by addressing the combination of both extremes. The documentation refers to this as being suitable for extended reality and media services, underlining the increasing focus on immersive technologies and their networking needs.

Finally, Release 19 introduced SST 7 for Guaranteed Bit Rate Streaming Services (GBRSS). This new slice supports services where continuous, guaranteed throughput is essential. It is particularly relevant for live broadcasting, high-definition streaming, or virtual presence applications where quality cannot degrade over time.

This gradual and deliberate expansion of standardised SSTs highlights how 5G is not a one-size-fits-all solution. Instead, it is a dynamic platform that adapts to the needs of different industries. As use cases grow more sophisticated and diverse, having standardised slice types helps ensure compatibility, simplify device and network configuration, and promote innovation.

It is also worth noting that these SST values are not mandatory for every operator to implement. A network can choose to support a subset based on its service strategy. For example, a public network may prioritise SSTs 1 and 3, while a private industrial deployment might focus on SST 5 or 7.

With slicing increasingly central to how 5G will be "monetised" and deployed, expect this list to keep growing in future releases. Each new SST tells a story about where the telecoms ecosystem is heading.

Related Posts: 

• The 3G4G Blog: Is there a compelling Business Case for 5G Network Slicing in Public Networks?
• The 3G4G Blog: Network Slicing using User Equipment Route Selection Policy (URSP)
• The 3G4G Blog: QoS Flow Establishments in 5G Standalone RAN and Core
• The 3G4G Blog: How to Identify Network Slices in NG RAN
• The 3G4G Blog: Network Slicing in NG RAN
• The 3G4G Blog: Network Slicing Tutorials and Other Resources
• The 3G4G Blog: 5G Slicing Templates
• The 3G4G Blog: End-to-end Network Slicing in 5G 

Introduction to 5G Reduced Capability (RedCap) Devices

Back in 2019, we wrote about Release-17 study item called NR-Lite (a.k.a. NR-Light). After the study started, it was renamed as RedCap or Reduced Capability.

5G NR-RedCap (New Radio Reduced Capability Device) is now the official name of NR-Light (or NR-Lite before that). Assuming this was also being discussed in 3GPP as NR-RedCom (New Radio Reduced Complexity Device) earlier. Can anyone confirm 🤔 pic.twitter.com/WZUaJSgQ8s

— 3G4G (@3g4gUK) December 20, 2020

We have now made a video tutorial on RedCap to not only explain what it is but also discuss some of the enhancements being discussed for 3GPP Release-18 (5G-Advanced). For anyone wanting to find out the differences between the baseline 5G devices with RedCap, without wanting to go too much in detail, can see the Tweet image for comparison.

What is 5G reduced capability (RedCap) NR and what will it achieve? - https://t.co/NwWE9bpzVy via @EricssonNetwork @EricssonLabs #Free5Gtraining #3G4G5G #Ericsson #3GPP #5G #5GNR #eMBB #mMTC #URLLC #NRRedCap #RedCap #IoT #NRLight #NRLite #WearableTech #SmartIoT pic.twitter.com/5FbGx9lt5s

— Free 5G Training (@5Gtraining) April 25, 2021

The video and the slides of the tutorial are embedded below:

Beginners: Introduction to 5G Reduced Capability (RedCap) Devices from 3G4G

Related Posts:

• The 3G4G Blog: Challenges and Future Perspectives of Industrial 5G
• The 3G4G Blog: 5G and Industry 4.0
• The 3G4G Blog: What is Industrial IoT (IIoT) and how is it different from IoT?
• Free 6G Training: 6G Localization and Sensing – Technologies, Opportunities and Challenges
• The 3G4G Blog - Ultra Reliability: 5x9s (99.999%) in 3GPP Release-15 vs 6x9s (99.9999%) in 3GPP Release-16
• The 3G4G Blog: 5G Private and Non-Public Network (NPN)
• The 3G4G Blog: Real-life 5G Use Cases for Verticals from China
• The 3G4G Blog: Positioning Techniques for 5G NR in 3GPP Release-16 

Business Role Models for Network Slicing and iRAT Mobility for Cellular Internet of Things (CIoT) in Release 16

 3GPP Release 16 describes business role models for network slicing and in TR 21.916 I found the figures below that I have pimped a little bit to illustrate an asset tracking use case for goods transported with a truck from Factory A to Factory B. 

Factory B is equipped with a 5G Non-Public Network (NPN) that broadcasts an NPN-ID or - if the network infrastructure is deployed by an operator - a Cell Access Group ID (CAG ID).

I would like to assume that in case of the scenario shown in 3GPP Figure 2-2 the asset tracking CIoT devices are able to access any necessary PLMN, Network Slice and NPN. This can be achieved e.g. by using an eSIM. 

So while the truck is at the location of Factory A the asset tracking "things" will connect to the private slice of Factory A provided by the operator of PLMN 1. Factory A is a tenant of this operator. This means: Factory A rented a virtual part of PLMN1 for private use and technically this rented virtual network part is realized by a NW slice. 

When the truck leaves Factory A and drives on the road (maybe a long distance) to Factory B the asset tracking data must be transmitted over public mobile network infrastructure. Depending on rural coverage this service can be offered by PLMN 2 (as in case of 3GPP figure 2-2) or by PLMN 1 (as in case of 3GPP figure 2-3).

In case of 3GPP figure 2-4 the operator of PLMN 1 is even able to provide the private slice along the road, which allows Factory A to stretch the coverage of their virtual private network (slice) over a very long distance.

Looking further into the Cellular IoT enhancements defined by 3GPP in Release 16 it turns out that actually there is no need for a nation-wide 5G coverage to realize at least the role models shown in the 3GPP figures 2-2 and 2-3.

Because Release 16 also defines co-existence and inter-RAT mobility between 5G CIoT traffic and 4G NB-IoT the operators of PLMN 1 and PLMN 2 may offer NB-IoT coverage along the road while the factories are covered with 5G NR frequency cells - as shown in my second figure below.  

It illustrates the great improved flexibility that Release 16 standards are offering for customized business solutions and monitoring the service quality is not a trivial task under these circumstances.  

Related Posts:

• The 3G4G Blog: 5G Private and Non-Public Network (NPN)
• The 3G4G Blog: Network Slicing Tutorials and Other Resources