Showing posts with label Network Slicing. Show all posts
Showing posts with label Network Slicing. Show all posts

Wednesday, 14 August 2024

3GPP Release 18 Description and Summary of Work Items

The first official release of 3GPP TR 21.918: "Release 18 Description; Summary of Rel-18 Work Items" has been published. It's the first official version of 5G-Advanced. Quoting from the report: 

Release 18 specifies further improvements of the 5G-Avanced system. 

These improvements consist both in enhancements of concepts/Features introduced in the previous Releases and in the introduction of new topics.

Some of the key improvements are:

  • a further integration of the Satellite (NTN) access (introduced in Rel-17) in the 5G System (5GS), 
  • a more efficient support of Internet of Things (IoT), Machine-Type Communication (MTC), including by satellite coverage
  • and also several aspects of proximity communication and location (Sidelink, Proximity, Location and Positioning, better support of the industrial needs (Verticals, Industries, Factories, Northbound API), Multicast and Broadcast Services (MBS), Network Slicing or Uncrewed Aerial Vehicles (UAV).

As for the new topics, some of the key aspects are:

  • Energy Efficiency (EE)
  • Artificial Intelligence (AI)/Machine Learning (ML)
  • eXtended, Augmented and Virtual Reality (XR, AR, VR), immersive communications

The following list is from the v1.0.0 table of contents to make it easier to find the list of topics. If it interests you, download the latest version technical report from the directory here.

5 Satellite / Non-Terrestrial Network (NTN)
5.1 General aspects
5.1.1 User plane: “5G system with satellite backhaul”
5.1.2 Discontinuous coverage: “Satellite access Phase 2”
5.1.3 Radio: "NR NTN enhancements"
5.1.4 Charging and Management aspects of Satelite
5.2 Specific aspects
5.2.1 IoT (Internet of Things) NTN enhancements
5.2.2 Guidelines for Extra-territorial 5G Systems
5.2.3 5G system with satellite access to Support Control and/or Video Surveillance
5.2.4 Introduction of the satellite L-/S-band for NR
5.2.5 Other band-related aspects of satellite

6 Internet of Things (IoT), Machine-Type Communication (MTC)
6.1 Personal IoT and Residential networks
6.2 Enhanced support of Reduced Capability (RedCap) NR devices
6.3 NR RedCap UE with long eDRX for RRC_INACTIVE State
6.4 Application layer support for Personal IoT Network
6.5 5G Timing Resiliency System
6.6 Mobile Terminated-Small Data Transmission (MT-SDT) for NR
6.7 Adding new NR FDD bands for RedCap in Rel-18
6.8 Signal level Enhanced Network Selection
6.9 IoT NTN enhancements

7 Energy Efficiency (EE)
7.1 Enhancements of EE for 5G Phase 2
7.2 Network energy savings for NR
7.3 Smart Energy and Infrastructure

8 Uncrewed Aerial Vehicles (UAV), UAS, UAM
8.1 Architecture for UAV and UAM Phase 2
8.2 Architecture for UAS Applications, Phase 2
8.3 NR support for UAV
8.4 Enhanced LTE Support for UAV

9 Sidelink, Proximity, Location and Positioning
9.1 5GC LoCation Services - Phase 3
9.2 Expanded and improved NR positioning
9.3 NR sidelink evolution
9.4 NR sidelink relay enhancements
9.5 Proximity-based Services in 5GS Phase 2
9.6 Ranging-based Service and sidelink positioning
9.7 Mobile Terminated-Small Data Transmission (MT-SDT) for NR
9.8 5G-enabled fused location service capability exposure

10 Verticals, Industries, Factories, Northbound API
10.1 Low Power High Accuracy Positioning for industrial IoT scenarios
10.2 Application enablement aspects for subscriber-aware northbound API access
10.3 Smart Energy and Infrastructure
10.4 Generic group management, exposure and communication enhancements
10.5 Service Enabler Architecture Layer for Verticals Phase 3
10.6 SEAL data delivery enabler for vertical applications
10.7 Rel-18 Enhancements of 3GPP Northbound and Application Layer interfaces and APIs
10.8 Charging Aspects of B2B
10.9 NRF API enhancements to avoid signalling and storing of redundant data
10.10 GBA_U Based APIs
10.11 Other aspects

11 Artificial Intelligence (AI)/Machine Learning (ML)
11.1 AI/ML model transfer in 5GS
11.2 AI/ML for NG-RAN
11.3 AI/ML management & charging
11.4 NEF Charging enhancement to support AI/ML in 5GS

12 Multicast and Broadcast Services (MBS)
12.1 5G MBS Phase 2
12.2 Enhancements of NR MBS
12.3 UE pre-configuration for 5MBS
12.4 Other MBS aspects

13 Network Slicing
13.1 Network Slicing Phase 3
13.2 Enhancement of NSAC for maximum number of UEs with at least one PDU session/PDN connection
13.3 Enhancement of Network Slicing UICC application for network slice-specific authentication and authorization
13.4 Charging Aspects of Network Slicing Phase 2
13.5 Charging Aspects for NSSAA
13.6 Charging enhancement for Network Slice based wholesale in roaming
13.7 Network Slice Capability Exposure for Application Layer Enablement
13.8 Other slice aspects

14 eXtended, Augmented and Virtual Reality (XR, AR, VR), immersive
14.1 XR (eXtended Reality) enhancements for NR
14.2 Media Capabilities for Augmented Reality
14.3 Real-time Transport Protocol Configurations
14.4 Immersive Audio for Split Rendering Scenarios  (ISAR)
14.5 Immersive Real-time Communication for WebRTC
14.6 IMS-based AR Conversational Services
14.7 Split Rendering Media Service Enabler
14.8 Extended Reality and Media service (XRM)
14.9 Other XR/AR/VR items

15 Mission Critical and emergencies
15.1 Enhanced Mission Critical Push-to-talk architecture phase 4
15.2 Gateway UE function for Mission Critical Communication
15.3 Mission Critical Services over 5MBS
15.4 Mission Critical Services over 5GProSe
15.5 Mission Critical ad hoc group Communications
15.6 Other Mission Critical aspects

16 Transportations (Railways, V2X, aerial)
16.1 MBS support for V2X services
16.2 Air-to-ground network for NR
16.4 Interconnection and Migration Aspects for Railways
16.5 Application layer support for V2X services; Phase 3
16.6 Enhanced NR support for high speed train scenario in frequency range 2 (FR2)

17 User Plane traffic and services
17.1 Enhanced Multiparty RTT
17.2 5G-Advanced media profiles for messaging services
17.3 Charging Aspects of IMS Data Channel
17.4 Evolution of IMS Multimedia Telephony Service
17.5 Access Traffic Steering, Switch and Splitting support in the 5G system architecture; Phase 3
17.6 UPF enhancement for Exposure and SBA
17.7 Tactile and multi-modality communication services
17.8 UE Testing Phase 2
17.9 5G Media Streaming Protocols Phase 2
17.10 EVS Codec Extension for Immersive Voice and Audio Services
17.11 Other User Plane traffic and services items

18 Edge computing
18.1 Edge Computing Phase 2
18.2 Architecture for enabling Edge Applications Phase 2
18.3 Edge Application Standards in 3GPP and alignment with External Organizations

19 Non-Public Networks
19.1 Non-Public Networks Phase 2
19.2 5G Networks Providing Access to Localized Services
19.3 Non-Public Networks Phase 2

20 AM and UE Policy
20.1 5G AM Policy
20.2 Enhancement of 5G UE Policy
20.3 Dynamically Changing AM Policies in the 5GC Phase 2
20.4 Spending Limits for AM and UE Policies in the 5GC
20.5 Rel-18 Enhancements of UE Policy

21 Service-based items
21.1 Enhancements on Service-based support for SMS in 5GC
21.2 Service based management architecture
21.3 Automated certificate management in SBA
21.4 Security Aspects of the 5G Service Based Architecture Phase 2
21.5 Service Based Interface Protocol Improvements Release 18

22 Security-centric aspects
22.1 IETF DTLS protocol profile for AKMA and GBA
22.2 IETF OSCORE protocol profiles for GBA and AKMA
22.3 Home network triggered primary authentication
22.4 AKMA phase 2
22.5 5G Security Assurance Specification (SCAS) for the Policy Control Function (PCF)
22.6 Security aspects on User Consent for 3GPP services Phase 2
22.7 SCAS for split-gNB product classes
22.8 Security Assurance Specification for AKMA Anchor Function Function (AAnF)
22.9 Other security-centric items

23 NR-only items
23.1 Not band-centric
23.1.1 NR network-controlled repeaters
23.1.2 Enhancement of MIMO OTA requirement for NR UEs
23.1.3 NR MIMO evolution for downlink and uplink
23.1.4 Further NR mobility enhancements
23.1.5 In-Device Co-existence (IDC) enhancements for NR and MR-DC
23.1.6 Even Further RRM enhancement for NR and MR-DC
23.1.7 Dual Transmission Reception (TxRx) Multi-SIM for NR
23.1.8 NR support for dedicated spectrum less than 5MHz for FR1
23.1.9 Enhancement of NR Dynamic Spectrum Sharing (DSS)
23.1.10 Multi-carrier enhancements for NR
23.1.11 NR RF requirements enhancement for frequency range 2 (FR2), Phase 3
23.1.12 Requirement for NR frequency range 2 (FR2) multi-Rx chain DL reception
23.1.13 Support of intra-band non-collocated EN-DC/NR-CA deployment
23.1.14 Further enhancements on NR and MR-DC measurement gaps and measurements without gaps
23.1.15 Further RF requirements enhancement for NR and EN-DC in frequency range 1 (FR1)
23.1.16 Other non-band related items
23.2 Band-centric
23.2.1 Enhancements of NR shared spectrum bands
23.2.2 Addition of FDD NR bands using the uplink from n28 and the downlink of n75 and n76
23.2.3 Complete the specification support for BandWidth Part operation without restriction in NR
23.2.4 Other NR band related topics

24 LTE-only items
24.1 High Power UE (Power Class 2) for LTE FDD Band 14
24.2 Other LTE-only items

25 NR and LTE items
25.1 4Rx handheld UE for low NR bands (<1GHz) and/or 3Tx for NR inter-band UL Carrier Aggregation (CA) and EN-DC
25.2 Enhancement of UE TRP and TRS requirements and test methodologies for FR1 (NR SA and EN-DC)
25.3 Other items

26 Network automation
26.1 Enablers for Network Automation for 5G phase 3
26.2 Enhancement of Network Automation Enablers

27 Other aspects
27.1 Support for Wireless and Wireline Convergence Phase 2
27.2 Secondary DN Authentication and authorization in EPC IWK cases
27.3 Mobile IAB (Integrated Access and Backhaul) for NR
27.4 Further NR coverage enhancements
27.5 NR demodulation performance evolution
27.6 NR channel raster enhancement
27.7 BS/UE EMC enhancements for NR and LTE
27.8 Enhancement on NR QoE management and optimizations for diverse services
27.9 Additional NRM features phase 2
27.10 Further enhancement of data collection for SON (Self-Organising Networks)/MDT (Minimization of Drive Tests) in NR and EN-DC
27.11 Self-Configuration of RAN Network Entities
27.12 Enhancement of Shared Data ID and Handling
27.13 Message Service within the 5G system Phase 2
27.14 Security Assurance Specification (SCAS) Phase 2
27.15 Vehicle-Mounted Relays
27.16 SECAM and SCAS for 3GPP virtualized network products
27.17 SECAM and SCAS for 3GPP virtualized network products
27.18 MPS for Supplementary Services
27.19 Rel-18 enhancements of session management policy control
27.20 Seamless UE context recovery
27.21 Extensions to the TSC Framework to support DetNet
27.22 Multiple location report for MT-LR Immediate Location Request for regulatory services
27.23 Enhancement of Application Detection Event Exposure
27.24 General Support of IPv6 Prefix Delegation in 5GS
27.25 5G Timing Resiliency System
27.26 MPS when access to EPC/5GC is WLAN
27.27 Data Integrity in 5GS
27.28 Security Enhancement on RRCResumeRequest Message Protection

28 Administration, Operation, Maintenance and Charging-centric Features
28.1 Introduction
28.2 Intent driven Management Service for Mobile Network phase 2
28.3 Management of cloud-native Virtualized Network Functions
28.4 Management of Trace/MDT phase 2
28.5 Security Assurance Specification for Management Function (MnF)
28.6 5G performance measurements and KPIs phase 3
28.7 Access control for management service
28.8 Management Aspects related to NWDAF
28.9 Management Aspect of 5GLAN
28.10 Charging Aspects of TSN
28.11 CHF Distributed Availability
28.12 Management Data Analytics phase 2
28.12 5G System Enabler for Service Function Chaining
28.13 Other Management-centric items

29 Other Rel-18 Topics

If you find them useful then please get the latest document from here.

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , , , , , , , , ,

Monday, 19 September 2022

Is there a compelling Business Case for 5G Network Slicing in Public Networks?

Since the industry realised how the 5G Network Architecture will look like, Network Slicing has been touted as the killer business case that will allow the mobile operators to generate revenue from new sources.

Last month ABI Research said in a press release:

According to global technology intelligence firm ABI Research, 5G slicing revenue is expected to grow from US$309 million in 2022 to approximately US$24 billion in 2028, at a Compound Annual Growth Rate (CAGR) of 106%. 

“5G slicing adoption falls into two main categories. One, there is no connectivity available. Two, there is connectivity, but there is not sufficient capacity, coverage, performance, or security. For the former, both private and public organizations are deploying private network slices on a permanent and ad hoc basis,” highlights Don Alusha, 5G Core and Edge Networks Senior Analyst at ABI Research. The second scenario is mostly catered by private networks today, a market that ABI Research expects to grow from US$3.6 billion to US$109 billion by 2023, at a CAGR of 45.8%. Alusha continues, “A sizable part of this market can be converted to 5G slicing. But first, the industry should address challenges associated with technology and commercial models. On the latter, consumers’ and enterprises’ appetite to pay premium connectivity prices for deterministic and tailored connectivity services remains to be determined. Furthermore, there are ongoing industry discussions on whether the value that comes from 5G slicing can exceed the cost required to put together the underlying slicing ecosystem.”

Earlier this year, Daryl Schoolar - Research Director at IDC tackled this topic in his blog post:

5G network slicing, part of the 3GPP standards developed for 5G, allows for the creation of multiple virtual networks across a single network infrastructure, allowing enterprises to connect with guaranteed low latency. Using principles behind software-defined network and network virtualization, slicing allows the mobile operator to provide differentiated network experience for different sets of end users. For example, one network slice could be configured to support low latency, while another slice is configured for high download speeds. Both slices would run across the same underlying network infrastructure, including base stations, transport network, and core network.

Network slicing differs from private mobile networks, in that network slicing runs on the public wide area network. Private mobile networks, even when offered by the mobile operator, use infrastructure and spectrum dedicated to the end user to isolate the customer’s traffic from other users.

5G network slicing is a perfect candidate for future business connectivity needs. Slicing provides a differentiated network experience that can better match the customers performance requirements than traditional mobile broadband. Until now, there has been limited mobile network performance customization outside of speeds. 5G network slicing is a good example of telco service offerings that meet future of connectivity requirements. However, 5G network slicing also highlights the challenges mobile operators face with transformation in their pursuit of remaining relevant.

For 5G slicing to have broad commercial availability, and to provide a variety of performance options, several things need to happen first.

  • Operators need to deploy 5G Standalone (SA) using the new 5G mobile core network. Currently most operators use the 5G non-standalone (NSA) architecture that relies on the LTE mobile core. It might be the end of 2023 before the majority of commercial 5G networks are using the SA mode.
  • Spectrum is another hurdle that must be overcome. Operators still make most of their revenue from consumers, and do not want to compromise the consumer experience when they start offering network slicing. This means operators need more spectrum. In the U.S., among the three major mobile operators, only T-Mobile currently has a nationwide 5G mid-band spectrum deployment. AT&T and Verizon are currently deploying in mid-band, but that will not be completed until 2023.
  • 5G slicing also requires changes to the operator’s business and operational support systems (BSS/OSS). Current BSS/OSS solutions were not designed to support the increased parameters those systems were designed to support.
  • And finally, mobile operators still need to create the business propositions around commercial slicing services. Mobile operators need to educate businesses on the benefits of slicing and how slicing supports their different connectivity requirements. This could involve mobile operators developing industry specific partnerships to reach different business segments. All these things take time to be put into place.

Because of the enormity of the tasks needed to make 5G network slicing a commercial success, IDC currently has a very conservative outlook for this service through 2026. IDC believes it will be 2023 until there is general commercial availability of 5G network slicing. The exception is China, which is expected to have some commercial offerings in 2022 as it has the most mature 5G market. Even then, it will take until 2025 before global revenues from slicing exceeds a billion U.S. dollars. In 2026 IDC forecasts slicing revenues will be approximately $3.2 billion. However, over 80% of those revenues will come out of China.

The 'Outspoken Industry Analyst' Dean Bubley believes that Network Slicing is one of the worst strategic errors made by the mobile industry, since the catastrophic choice of IMS for communications applications. In a LinkedIn post he explains:

At best, slicing is an internal toolset that might allow telco operations or product teams (or their vendors) to manage their network resources. For instance, it could be used to separate part of a cell's capacity for FWA, and dynamically adjust that according to demand. It might be used as an "ingredient" to create a higher class of service for enterprise customers, for instance for trucks on a highway, or as part of an "IoT service" sold by MNOs. Public safety users might have an expensive, artisanal "hand-carved" slice which is almost a separate network. Maybe next-gen MVNOs.

(I'm talking proper 3GPP slicing here - not rebranded QoS QCI classes, private APNs, or something that looks like a VLAN, which will probably get marketed as "slices")

But the idea that slicing is itself a *product*, or that application developers or enterprises will "buy a slice" is delusional.

Firstly, slices will be dependent on [good] coverage and network control. A URLLC slice likely won't work reliably indoors, underground, in remote areas, on a train, on a neutral-host network, or while roaming. This has been a basic failure of every differentiated-QoS monetisation concept for many years, and 5G's often-higher frequencies make it worse, not better.

Secondly, there is no mature machinery for buying, selling, testing, supporting. price, monitoring slices. No, the 5G Network Exposure Function won't do it all. I haven't met a Slice salesperson yet, or a Slice-procurement team.

Thirdly, a "local slice" of a national 5G network will run headlong into a battle with the desire for separate private/dedicated local 5G networks, which may well be cheaper and easier. It also won't work well with the enterprise's IT/OT/IP domains, out of the box.

Also there's many challenges getting multi-operator slices, device OS links to slice APIs, slice "boundary controllers" between operators, aligning RAN and core slices, regulatory questionmarks and much more.

There are lots of discussion in the comments section that may be of interest to you, here.

My belief is that we will see lots of interesting use cases with slicing in public networks but it will be difficult to monetise. The best networks will manage to do it to create some plans with guaranteed rates and low latency. It would remain to be see whether they can successfully monetise it well enough. 

For technical people and newbies, there are lots of Network Slicing resources on this blog (see related posts 👇). Here is another recent video from Mpirical:

Related Posts: 

Posted by Zahid Ghadialy at 09:35 Leave a comment...0 comments so far
Labels: , , , , , , , , , , ,

Tuesday, 15 March 2022

5G Network Slicing for Beginners

Network Slicing is a hot topic on our blogs and it looks like people can't get enough of it. So here is a short introductory tutorial from Wray Castle.

The video embedded below explores what Network Slicing is, how it is used, and how it is deployed in the 5G network, as well as (briefly) the role of MEC (Multi Access Edge Computing) in support of specific use cases and potential slice deployments.

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , ,

Thursday, 11 November 2021

Network Slicing using User Equipment Route Selection Policy (URSP)

Google announced that its latest smartphone OS will include support for 5G network slicing. Last week Telecom TV brought this news to my attention. The article explains:

It's a move designed to leverage its expertise in devices in order to give it the edge over its rival hyperscalers.

It comes in two flavours. The first is for enterprise-owned handsets, and routes all data sent and received by a device over the network slices provided by that company's mobile operator. Android 12 gives operators the ability to manage slices using a new dynamic policy control mechanism called User Equipment Route Selection Policy (URSP). URSP enables devices to automatically switch between different network slices according to which application they are using. For example, someone working for a financial institution might require a highly-secure network slice for sending and receiving sensitive corporate data, but will then require a reliable, high-throughput, low-latency slice so they can participate in a video meeting.

The second flavour is implemented in the work profile. For years, enterprises have had the option of creating work profiles on Android devices – irrespective of whether they are owned by the organisation or the individual – to use as a separate repository for enterprise apps and data. When Android 12 comes out next year, enterprises will be able to route data to and from that repository over a network slice.

Google said it has already carried out network slicing tests with both Ericsson and Nokia using test versions of its recently released Pixel 6 smartphone running on the as-yet-unreleased Android 12 OS.

Last week Taiwanese operator Far EasTone (FET) and Ericsson announced they have completed the world’s first proof of concept (PoC) for simultaneously connecting multiple network slices per device running on Android 12 commercial release. The press release said:

The trial, carried out on FET’s 5G standalone (SA) infrastructure built on Ericsson’s radio access network and cloud-native Core network, successfully demonstrated the 5G user equipment slicing policy feature (User Equipment Route Selection Policy, or URSP) on multiple Android devices. This marks a breakthrough in network slicing capabilities on a 5G standalone network and paves the way for further ecosystem development in this important area.

With more 5G networks evolving to standalone architecture around the globe, end-to-end network slicing, which includes Ericsson RAN Slicing to secure Quality of Service (QoS) differentiation, plays a key role in enabling new services for end users, with which multiple virtual 5G networks are created on top of one physical network. The 5G trial, in collaboration with FET, Ericsson and Android, went even further in network slicing capabilities by introducing and demonstrating 5G user equipment (UE) slicing policy (URSP) features that allow devices to simultaneously operate on dynamic policy control and selection between multiple 5G network slices. This enables the steering of applications and services with specific requirements to defined slices without switching devices.

Multiple slices allow devices to have multiple profiles to secure different levels of experience, security, and privacy requirements, based on the needs of the different applications and in correspondence with the user profile.  For instance, a device can have a personal profile with private data from apps or off-work entertainment, and a work profile with enterprises productivity apps. With URSP features, employers can customize the work profile with increased security and enable better use of RAN Slicing with QoS so that enterprise-related apps can work even during network congestion.

Some security-sensitive apps, such as mobile banking, can also benefit from different routing mechanisms of the traffic enabled by URSP. For instance, the banking app would not need to send its traffic to the internet and then to the app server as it does today. Instead, it could go straight to the app server and avoid the routing through internet. With the shortest route by connecting to a defined slice, users could reduce the risk of being attacked by hackers.

In their technical whitepaper on Network Slicing, Samsung explains: 

Along with the concept of network slicing and features in the RAN and Core network, UE Route Selection Policy (URSP) is introduced as a way to manage network slice information for the UE. URSP is a network slice feature enabled by the PCF which informs the network slice status to the UE via the AMF. In 4G network systems, it was near impossible to install new services in the network for a UE. But through the URSP feature, 5G network operators can easily configure new service for a UE. Figure 12 (top of this blog post) shows the difference in network slice selection in 4G and 5G Network. In 5G network, slice selection policy can be configured dynamically through URSP, while slice selection policy is pre-defined and cannot be changed dynamically in 4G network.

URSP contains OSId, AppId, IP descriptors to define the application and Single-Network Slice Selection Assistance Information (S-NSSAI), Data Network Name (DNN), Session and Service Continuity (SSC) mode information for the application and network slice mapping.

The S-NSSAI identifies each network slice service and provides information to properly assign network slice/functions. An S-NSSAI is comprised of:

  • A Slice/Service type (SST), which refers to the expected network slice behavior in terms of features and services;
  • A Slice Differentiator (SD), which is an optional information that complements the Slice/Service type(s) to differentiate amongst multiple network slices of the same Slice/Service type.

3GPP allows the use of the Slice Differentiator (SD) field that can build customized network slices. The SD field can be used to describe services, customer information and priority.

Here is a short video from Mpirical explaining 5G UE Route Selection.

It it worth reminding here that this feature, like many of the other 5G features, is dependent on 5G Core. We hope that the transition to 5G Standalone Networks happens as soon as possible.

Related Posts:

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , , , , , ,

Tuesday, 12 October 2021

QoS Flow Establishments in 5G Standalone RAN and Core

Today I launched a new video on my YouTube channel that explains how QoS Flows are established in 5G RAN and Core. It also highlights the main differences between 4G E-RAB handling and 5G QoS Flows.

Related Posts: 

Posted by Ralf Kreher at 12:53 Leave a comment...0 comments so far
Labels: , , , , , , , ,

Friday, 5 March 2021

How to Identify Network Slices in NG RAN

In my last post I described how NG RAN resources can be divided into network slices. 

Now I would like to show how these network slices and the traffic they carry can be identified. 

The key to this is a parameter from the NG Application Protocol (NGAP) called the Single Network Slice Selection Assistance Information (S-NSSAI). When configuring virtual network functions in NG RAN there are lists of S-NSSAI exchanged, e.g. between gNB-CU CP and AMF during NGAP Setup procedure, to negotiate which network slices have to be supported in general. 

When it comes to connection establishment starting with NGAP Initial Context Setup for each PDU session that is established its individual S-NSSAI is signaled. 

The S-NSSAI - as show in the figure below - consists of two parameters, the Slice/Service Type (SST - 8 bit) and the optional Slice Differentiator (SD - 24 bit). The exact format and numbering ranges are defined in 3GPP 23.003.

3GPP 23.501 defines a set of default values for SST as listed in the following table:

Slice/Service type

SST value

Characteristics

eMBB

 

1

Slice suitable for the handling of 5G enhanced Mobile Broadband.

URLLC

2

Slice suitable for the handling of ultra- reliable low latency communications.

MIoT

3

Slice suitable for the handling of massive IoT.

V2X

4

Slice suitable for the handling of V2X services.

So when looking back at the figure it emerges that for each subscriber represented by an IMSI the SST allows to identify which services are running. 

On the other hand allows to see if in which virtual network the subscriber is active. In my example I have defined that the resources are shared among a Public MNO that I consider the owner of the network hardware and two different private (campus) networks. While IMSI 1 and IMSI 2 are not allowed to use any other network slice the IMSI 3 is allowed to "roam" betweent the public slice and the two private network slices. This explains why a slice-specific authentication functionality as defined in Rel. 16 is necessary. 

Related Posts:

Posted by Ralf Kreher at 14:44 Leave a comment...0 comments so far
Labels: , , , , , ,

Friday, 26 February 2021

Network Slicing in NG RAN

I have been asked to explain in a nutshell how network slicing works in NG RAN. The most important facts you will find in the infographic below.

A network slice is virtual part of a network that offers full end-to-end connectivity for particular services and - optionally - for tenants. A tenant is a 3rd-party company that rents a virtual part of a public mobile operator's network. This allows the tenant to run its own private nation-wide mobile network without owning any hardware.

The network slicing is enabled by virtualization and all network functions can be divided into different slices as well. Thus, you can find in the figure the User Plane Function (UPF), gNB Central Unit for User Plane (gNB-CU UP) and gNB Distributed Unit (gNB-DU) all sliced.

It is also possible that a network function is dedicated for a particular network slice as in case of (gNB-) CU UP 2. 

In general - and this is the benefit of the cloudification - the NG RAN is a highly dynamic environment in which additional NW functions can be added (and later released) whenever this is necessary. Mostly this will be triggered by the load on CPU and memory resources. Here comes the automation into the games that deals in large parts with load balancing. Ideally automation enables a zero-touch network management. 

(click to enlarge)

However, the most precious of all RAN resources, the radio resources, cannot be administrated so flexibly and easily. Indeed, there are several automation instances that deal with radio resource management. Open RAN Alliance has defined the RAN Intelligent Controller (RIC) that is split into the Near-Realtime-RIC (RT RIC) that shall operate with a latency between 10 and 500 ms while the Non-Realtime RIC (NRT RIC) deals with non-time critical task, e.g. typical SON functions like Automatic Neighbor Reporting (ANR).

While the RIC can deal with a lot of problems there is one thing it cannot do: adding physical layer radio resources on demand. The physical resources are limited by the number of remote radio heads/antennas and as long as we have only static beamforming the physical resources covering a geographical sector are also limited by hardware and their distribution must be carefully planned. Thus, I think it is fair to say that the RIC (or a similar proprietary automation function) has to deal with the most complex situations in the RAN.

Radio resources can also be sliced in different ways. My figure illustrates a kind of slicing on the physical layer where different physical resource blocks (PRB) are allocated to different network slices. 

However, this is not the only way how the resources of a cell or a beam can be sliced. Beside a split of PRBs it is also possible to slice on the MAC layer where logical channels (slice-specific radio bearers) are mapped onto transport channels or on PDPC layer as it was described and demonstrated by the 5G NORMA project (Chapter 2.1, page 17 ff.).

What in the end will be implemented by the RAN equipment manufacturers is a question I that cannot answer today. 

Posted by Ralf Kreher at 11:49 Leave a comment...1 comments so far
Labels: , , ,

Friday, 20 November 2020

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:

Posted by Ralf Kreher at 10:51 Leave a comment...0 comments so far
Labels: , , , , ,

Tuesday, 10 November 2020

Network Slicing Tutorials and Other Resources

I have received quite a few requests to do a 5G Network Slicing tutorial but have still not got around to doing it. Luckily there are so many public resources available that I can get away with not doing one on this topic. 


This Award Solutions webinar by Paul Shepherd (embedded below) provides good insights into network slicing, what it is, how it efficiently enables different services in 5G networks, and the architectural changes in 5G required to support it.

Then there is also this myth about 3 slices in the network. The GSMA slice template is a good starting point for an operator looking to do network slicing in their 5G networks. The latest version is 3.0, available here.


As this picture (courtesy of Phil Kendall) shows, it's not a straightforward task.  

Alistair URIE from Nokia Bell Labs points out some common misconceptions people have with Network Slicing:

  1. Multiple slices may share the same cell and the same RU in each slice
  2. Single UE may have up to 8 active slices but must have a single CU-CP instance to terminate the common RRC 
  3. Slicing supports more than 3 slices 

Back in March, China Mobile, Huawei, Tencent, China Electric Power Research Institute, and Digital Domain have jointly released the Categories and Service Levels of Network Slice White Paper to introduce the industry’s first classification of network slice levels. The new white paper dives into the definitions, solutions, typical scenarios, and evolution that make up the five levels of network slices. It serves as an excellent reference to provide guidance in promoting and commercializing network slicing, and lays a theoretical foundation for the industry-wide application of network slicing.

The whitepaper describes the different phases as:

Phase 1 (ready): As mentioned above, the 5G transport network and 5G core network support different software-based and hardware-based isolation solutions. On the 5G NR side, 5QIs (QoS scheduling mechanism) are mainly used to achieve software-based isolation in WAN scenarios. Alternatively, campus-specific 5G NR (including micro base stations and indoor distributed base stations) is used to implement hardware-based isolation in LAN scenarios. In terms of service experience assurance, 5QIs are used to implement differentiated SLA assurance between slices. In terms of slice OAM capabilities, E2E KPIs can be managed in a visualized manner. This means that from 2020 on, Huawei is ready to deliver commercial use of E2E slicing for common customers and VIP customers of the public network and common customer of general industries (such as UHD live broadcast and AR advertisement).

Phase 2 (to be ready in 2021): In terms of isolation, the 5G NR side supports the wireless RB resource reservation technology (including the static reservation and dynamic reservation modes) to implement E2E network resource isolation and slicing in WAN scenarios. In terms of service experience assurance, features such as 5G LAN and 5G TSN are enhanced to implement differentiated and deterministic SLA assurance between different slices. In terms of slice OAM, on the basis of tenant-level KPI visualization, the limited self-service of the industry for rented slices can be further supported. In this phase, operators can serve VIP customers in common industries (such as AR/VR cloud games and drone inspection), dedicated industry customers (such as electric power management information region, medical hospital campus, and industrial campus), and dedicated industry customers (such as electric power production control region and public security).

Phase 3 (to be ready after 2022): In this phase, 5G network slicing supports real dynamic closed-loop SLAs based on AI and negative feedback mechanism, implementing network self-optimization and better serving industries (such as 5G V2X) with high requirements on mobility, roaming, and service continuity. In addition, industry-oriented comprehensive service capabilities will be further enhanced and evolved.

A more technical presentation from Nokia is available here. The video below shows how innovations in IP routing and SDN work together to implement network slicing in the transport domain.

If you know some other good resources and tutorials worth sharing, add them in the comments below.

Related Posts:

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , , , , ,

Saturday, 1 August 2020

Artificial Intelligence (AI) / Machine Learning (ML) in 5G Challenge by ITU


ITU is conducting a global ITU AI/ML 5G Challenge on the theme “How to apply ITU's ML architecture in 5G networks". If you don't know the difference between AI & ML, this picture from the old blog post may help.


The ITU website says:

Artificial Intelligence (AI) will be the dominant technology of the future and will impact every corner of society. In particular, AI / ML (machine learning) will shape how communication networks, a lifeline of our society, will be run. Many companies in the ICT sector are exploring how to make best use of AI/ML. ITU has been at the forefront of this endeavour exploring how to best apply AI/ML in future networks including 5G networks. The time is therefore right to bring together the technical community and stakeholders to brainstorm, innovate and solve relevant problems in 5G using AI/ML. Building on its standards work, ITU is conducting a global ITU AI/ML 5G Challenge on the theme “How to apply ITU's ML architecture in 5G networks". 

 Participants will be able to solve real world problems, based on standardized technologies developed for ML in 5G networks. Teams will be required to enable, create, train and deploy ML models (such that participants will acquire hands-on experience in AI/ML in areas relevant to 5G). Participation is open to ITU Member States, Sector Members, Associates and Aca​demic Institutions and to any individual from a country that is a member of ITU. ​ ​

There are also some cash prizes, etc. There are various topics with presentation slides & recordings freely available. 

I found the slides from ITU AI/ML in 5G Challenge —”Machine Learning for Wireless LANs + Japan Challenge Introduction” (link) very interesting. There are many other topics including AR / VR / XR, etc, as well.

Have a look at the ITU website here.


Related Posts:

Posted by Zahid Ghadialy at 08:45 Leave a comment...0 comments so far
Labels: , , , ,

Wednesday, 12 February 2020

AI your Slice to 5G Perfection


Back in November, The Enhanced Mobile Broadband Group in CW (Cambridge Wireless) held an event on 'Is automation essential in 5G?'. There were some thought provoking presentations and discussions but the one that stood out for me was by Dan Warren from Samsung


The slides are embedded below but I want to highlight these points:
  • Some Network Functions will be per slice whereas others will be multi-slice, the split may not be the same for every slice
  • Two slices that have the same 'per slice vs multi-slice' functional split may be different network hardware topologies
  • Enterprise customers will likely want a 'service' contract that has to be manifested as multiple slices of different types. 
  • Physical infrastructure is common to all slices
The last point is very important as people forget that there is a physical infrastructure that will generally be common across all slices.

Again, when you apply Artificial Intelligence (AI) to optimize the network functions, does it do it individually first and then end-to-end and if this is applied across all slices, each of which may have a different functionality, requirement, etc. How would it work in practice?




As Dan says in his tweet, "It is hard to implement AI to optimise a point solution without potentially degrading the things around it.  Constantly being pushed to a bigger picture view => more data => more complexity"

Let me know what you think.

Related Posts:
Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , ,
Subscribe to: Posts (Atom)