3GPP Release 17 introduced a new feature called AKMA (Authentication and Key Management for Applications), the goal of which is to enable the authentication and generation of application keys based on 3GPP credentials for all UE types in the 5G System, especially IoT devices, ensuring to bootstrap the security between the UE and the applications in the 5G system.
3GPP TR 21.917 has an excellent summary as follows:
Authentication and key management for applications based on 3GPP credential in 5G (AKMA) is a cellular-network-based delegated authentication system specified for the 5G system, helping establish a secure tunnel between the end user and the application server. Using AKMA, a user can log in to an application service only based on the 3GPP credential which is the permanent key stored in the user’s tamper-resistant smart card UICC. The application service provider can also delegate the task of user authentication to the mobile network operator by using AKMA.
The AKMA architecture and procedures are specified by SA3 in TS 33.535, with the related study showing how its general principles are derived documented in TR 33.835. The AKMA feature introduces a new Network Function into the 5G system, which is the AKMA Anchor Function (AAnF). Its detailed services and API definitions are specified by CT3 in TS 29.535. Earlier generations of cellular networks include two similar standards specified by SA3, which are generic bootstrapping architecture (GBA) and battery-efficient security for very low throughput machine type communication devices (BEST). Since the AKMA feature is deemed as a successor of these systems, the work is launched by SA3 without the involvement of stage 1.
In the latest issue of 3GPP Highlights Magazine, Suresh Nair, 3GPP Working Group SA3 Chair, Saurabh Khare & Jing Ping (Nokia) has explained the AKMA procedure. The article is also available on 3GPP website here. The article lists the following as AKMA advantages:
Since the AKMA framework uses authentication and authorization of the UE leveraging the PLMN credentials stored on the USIM, this becomes as strong as the network primary authentication and subsequent keys derived further to UE and Application Function (AF) interface.
The Application Functions can leverage the authentication service provided by the AKMA Anchor Function (AAnF) without additional CAPEX and OPEX.
The architecture provides a direct interface between the UE and the AF where a customized application-specific interface can be built, including the key management, key lifetime extension, etc.
The Journal of ICT Standardization has a paper on Authentication Mechanisms in the 5G System. It details AKMA and much more. It's a great place to start for anyone new looking to understand different 5G Authentication Mechanisms.
An updated (looks final) version of 3GPP TR 21.917: Release 17 Description; Summary of Rel-17 Work Items was added to the archive earlier this month. It is a fantastic summary of all the Rel-17 features. Quoting the executive summary from the specs:
Release 17 is dedicated to consolidate and enhance the concepts and functionalities introduced in the previous Releases, while introducing a small number of brand new Features.
The improvements relate to all the key areas of the previous Releases: services to the industry (the "verticals"), including positioning, private network, etc.; improvements for several aspects of 5G supporting Internet of Things (IoT), both in the Core Network and in the Access Network, of proximity (direct) communications between mobiles, in particular in the context of autonomous driving (V2X), in several media aspects of the user plane related to the entertainment industry (codec, streaming, broadcasting) and also of the support of Mission Critical communications. Furthermore, a number of network functionalities have been improved, e.g. for slicing, traffic steering and Edge-computing.
The Radio interface and the Access Network have been significantly improved too (MIMO, Repeaters, 1024QAM modulation for downlink, etc.). While most of the improvements target 5G/NR radio access (or are access-agnostic), some improvements are dedicated to 4G/LTE access. Such improvements are clearly identified in the title and in the chapters where they appear.
Note: To avoid terminology such as "even further improvements of…", the successive enhancements are now referred to as "Phase n": "phase 2" refers to the first series of enhancements, "Phase 3" to the enhancements of the enhancements, etc. In this transition Release, the "Phase n" way of referring to successive enhancements has not always been used consistently nor enforced.
As for the new Features, the main new Feature of this Release is the support of satellite access, and a dedicated chapter covers this topic.
Note that the classifications, groupings and order of appearance of the Features in this document reflect a number of choices by the editor as there is no "3GPP endorsement" for classification/order. This Executive Summary has also been written by the editor and represents his view.
The following list is from the table of contents to provide you an idea and if it interests you, download the technical report here.
5Integration of satellite components in the 5G architecture
5.1General traffic (non-IoT) 5.1.1SA and CT aspects 5.1.2RAN aspects 5.2NB-IoT/eMTC support for Non-Terrestrial Networks
6Services to "verticals" 6.1Introduction 6.2Generic functionalities, to all verticals 6.2.1Network and application enablement for verticals 6.2.1.1Enhanced Service Enabler Architecture Layer for Verticals 6.2.1.2Enhancements for Cyber-physical control Applications in Vertical domains (eCAV) 6.2.1.3Enhancements of 3GPP Northbound Interfaces and APIs 6.2.2Location and positioning 6.2.2.1RAN aspects of NR positioning enhancements 6.2.2.2Enhancement to the 5GC LoCation Services-Phase 2 6.2.3Support of Non-Public and Private Networks 6.2.3.1Enhanced support of Non-Public Networks 6.2.3.2Enhancement of Private Network support for NG-RAN 6.3Specific verticals support 6.3.1Railways 6.3.1.1Enhancements to Application Architecture for the Mobile Communication System for Railways Phase 2 6.3.1.2Enhanced NR support for high speed train scenario (NR_HST) 6.3.1.2.1NR_HST for FR1 6.3.1.2.2NR_HST for FR2 6.3.1.3NR Frequency bands for Railways 6.3.1.3.1Introduction of 900MHz NR band for Europe for Rail Mobile Radio (RMR) 6.3.1.3.2Introduction of 1900MHz NR TDD band for Europe for Rail Mobile Radio (RMR) 6.3.2Mission Critical (MC) and priority service 6.3.2.1Mission Critical Push-to-talk Phase 3 6.3.2.2Mission Critical Data Phase 3 6.3.2.3Mission Critical security Phase 2 6.3.2.4Mission Critical Services over 5GS 6.3.2.5Enhanced Mission Critical Communication Interworking with Land Mobile Radio Systems (CT aspects) 6.3.2.6Mission Critical system migration and interconnection (CT aspects) 6.2.3.7MC services support on IOPS mode of operation 6.3.2.8MCPTT in Railways 6.3.2.9Multimedia Priority Service (MPS) Phase 2 6.3.3Drone/UAS/UAV/EAV 6.3.3.1Introduction 6.3.3.2General aspects 6.3.3.2.15G Enhancement for UAVs 6.3.3.2.2Application layer support for UAS 6.3.3.3Remote Identification of UAS 6.3.4Media production, professional video and Multicast-Broadcast 6.3.4.1Communication for Critical Medical Applications 6.3.4.2Audio-Visual Service Production 6.3.4.3Multicast-Broadcast Services (MBS) 6.3.4.3.1Multicast-broadcast services in 5G 6.3.4.3.2NR multicast and broadcast services 6.3.4.3.35G multicast and broadcast services 6.3.4.3.4Security Aspects of Enhancements for 5G MBS 6.3.4.4Study on Multicast Architecture Enhancements for 5G Media Streaming 6.3.4.55G Multicast-Broadcast User Service Architecture and related 5GMS Extensions 6.3.4.6Other media and broadcast aspects 6.4Other "verticals" aspects
7IoT, Industrial IoT, REDuced CAPacity UEs and URLLC 7.1NR small data transmissions in INACTIVE state 7.2Additional enhancements for NB-IoT and LTE-MTC 7.3Enhanced Industrial IoT and URLLC support for NR 7.4Support of Enhanced Industrial IoT (IIoT) 7.5Support of reduced capability NR devices 7.6IoT and 5G access via Satellite/Non-Terrestrial (NTN) link 7.7Charging enhancement for URLLC and CIoT 7.8Messaging in 5G
8Proximity/D2D/Sidelink related and V2X 8.1Enhanced Relays for Energy eFficiency and Extensive Coverage 8.2Proximity-based Services in 5GS 8.3Sidelink/Device-to-Device (D2D) 8.3.1NR Sidelink enhancement 8.3.2NR Sidelink Relay 8.4Vehicle-to-Everything (V2X) 8.4.1Support of advanced V2X services - Phase 2 8.4.2Enhanced application layer support for V2X services
9System optimisations 9.1Edge computing 9.1.1Enhancement of support for Edge Computing in 5G Core network 9.1.2Enabling Edge Applications 9.1.3Edge Computing Management 9.2Slicing 9.2.1Network Slicing Phase 2 (CN and AN aspects) 9.2.2Network Slice charging based on 5G Data Connectivity 9.3Access Traffic Steering, Switch and Splitting support in the 5G system architecture; Phase 2 9.4Self-Organizing (SON)/Autonomous Network 9.4.1Enhancement of data collection for SON/MDT in NR and EN-DC 9.4.2Autonomous network levels 9.4.3Enhancements of Self-Organizing Networks (SON) 9.5Minimization of service Interruption 9.6Policy and Charging Control enhancement 9.7Multi-(U)SIM 9.7.1Support for Multi-USIM Devices (System and CN aspects) 9.7.2Support for Multi-SIM Devices for LTE/NR
10Energy efficiency, power saving 10.1UE power saving enhancements for NR 10.2Enhancements on EE for 5G networks 10.3Other energy efficiency aspects
11New Radio (NR) physical layer enhancements 11.1Further enhancements on MIMO for NR 11.2MIMO Over-the-Air requirements for NR UEs 11.3Enhancements to Integrated Access and Backhaul for NR 11.4NR coverage enhancements 11.5RF requirements for NR Repeaters 11.6Introduction of DL 1024QAM for NR FR1 11.7NR Carrier Aggregation 11.7.1NR intra band Carrier Aggregation 11.7.2NR inter band Carrier Aggregation 11.8NR Dynamic Spectrum Sharing 11.9Increasing UE power high limit for CA and DC 11.10RF requirements enhancement for NR FR1 11.11RF requirements further enhancements for NR FR2 11.12NR measurement gap enhancements 11.13UE RF requirements for Transparent Tx Diversity for NR 11.14NR RRM further enhancement 11.15Further enhancement on NR demodulation performance 11.16Bandwidth combination set 4 (BCS4) for NR 11.17Other NR related activities 11.18NR new/modified bands 11.18.1Introduction of 6GHz NR licensed bands 11.18.2Extending current NR operation to 71 GHz 11.18.3Other NR new/modified bands
12.New Radio (NR) enhancements other than layer 1 12.1NR Uplink Data Compression (UDC) 12.2NR QoE management and optimizations for diverse services
13NR and LTE enhancements 13.1NR and LTE layer 1 enhancements 13.1.1High-power UE operation for fixed-wireless/vehicle-mounted use cases in LTE bands and NR bands 13.1.2UE TRP and TRS requirements and test methodologies for FR1 (NR SA and EN-DC) 13.1.3Other Dual Connectivity and Multi-RAT enhancements 13.2NR and LTE enhancements other than layer 1 13.2.1Enhanced eNB(s) architecture evolution for E-UTRAN and NG-RAN 13.2.2Further Multi-RAT Dual-Connectivity enhancements 13.2.3Further Multi-RAT Dual-Connectivity enhancements
14LTE-only enhancements 14.1LTE inter-band Carrier Aggregation 14.2LTE new/modified bands 14.2.1New bands and bandwidth allocation for 5G terrestrial broadcast - part 1 14.3Other LTE bands-related aspects
15User plane improvements 15.1Immersive Teleconferencing and Telepresence for Remote Terminals 15.28K Television over 5G 15.35G Video Codec Characteristics 15.4Handsets Featuring Non-Traditional Earpieces 15.5Extension for headset interface tests of UE 15.6Media Streaming AF Event Exposure 15.7Restoration of PDN Connections in PGW-C/SMF Set 15.8Other media and user plane aspects
16Standalone Security aspects 16.1Introduction 16.2 Authentication and key management for applications based on 3GPP credential in 5G (AKMA) 16.3AKMA TLS protocol profiles 16.4User Plane Integrity Protection for LTE 16.5Non-Seamless WLAN offload authentication in 5GS 16.6Generic Bootstrapping Architecture (GBA) into 5GC 16.7Security Assurance Specification for 5G 16.8Adapting BEST for use in 5G networks 16.9Other security aspects
17Signalling optimisations 17.1Enhancement for the 5G Control Plane Steering of Roaming for UE in Connected mode 17.2Same PCF selection for AMF and SMF 17.3Enhancement of Inter-PLMN Roaming 17.4Enhancement on the GTP-U entity restart 17.5Packet Flow Description management enhancement 17.6PAP/CHAP protocols usage in 5GS 17.7Start of Pause of Charging via User Plane 17.8Enhancement of Handover Optimization 17.9Restoration of Profiles related to UDR 17.10 IP address pool information from UDM 17.11 Dynamic management of group-based event monitoring 17.12 Dynamically Changing AM Policies in the 5GC 17.13 Other aspects
18Standalone Management Features 18.1Introduction 18.2Enhanced Closed loop SLS Assurance 18.3Enhancement of QoE Measurement Collection 18.4Plug and connect support for management of Network Functions 18.5Management of MDT enhancement in 5G 18.6Management Aspects of 5G Network Sharing 18.7Discovery of management services in 5G 18.8Management of the enhanced tenant concept 18.9Intent driven management service for mobile network 18.10 Improved support for NSA in the service-based management architecture 18.11 Additional Network Resource Model features 18.12 Charging for Local breakout roaming of data connectivity 18.13 File Management 18.14 Management data collection control and discovery 18.15 Other charging and management aspects
If you find them useful then please get the latest document from here.
One way all operators in a country/region/geographic area differentiate amongst themselves is by the reach of their network. It's not in their interest to allow national roaming. Occasionally a regulator may force them to allow this, especially in rural or remote areas. Another reason why operators may choose to allow roaming is to reduce their network deployment costs.
In case of disasters or emergencies, if an operator's infrastructure goes down, the subscribers of that network can still access other networks for emergencies but not for normal services. This can cause issues as some people may not be able to communicate with friends/family/work.
A recent example of this kind of outage was in Japan, when the KDDI network failed. Some 39 million users were affected and many of them couldn't even do emergency calls. If Disaster Roaming was enabled, this kind of situation wouldn't occur.
South Korea already has a proprietary disaster roaming system in operation since 2020, as can be seen in the video above. This automatic disaster roaming is only available for 4G and 5G.
In 3GPP Release-17, Disaster Roaming has been specified for LTE and 5G NR. In case of LTE, the information is sent in SIB Type 30 while in 5G it is in SIB Type 15.
3GPP TS 23.501 section 5.40 provides summary of all the other information needed for disaster roaming. Quoting from that:
Subject to operator policy and national/regional regulations, 5GS provides Disaster Roaming service (e.g. voice call and data service) for the UEs from PLMN(s) with Disaster Condition. The UE shall attempt Disaster Roaming only if:
there is no available PLMN which is allowable (see TS 23.122 [17]);
the UE is not in RM-REGISTERED and CM-CONNECTED state over non-3GPP access connected to 5GCN;
the UE cannot get service over non-3GPP access through ePDG;
the UE supports Disaster Roaming service;
the UE has been configured by the HPLMN with an indication of whether Disaster roaming is enabled in the UE set to "disaster roaming is enabled in the UE" as specified in clause 5.40.2; and
a PLMN without Disaster Condition is able to accept Disaster Inbound Roamers from the PLMN with Disaster Condition.
In this Release of the specification, the Disaster Condition only applies to NG-RAN nodes, which means the rest of the network functions except one or more NG-RAN nodes of the PLMN with Disaster Condition can be assumed to be operational.
A UE supporting Disaster Roaming is configured with the following information:
Optionally, indication of whether disaster roaming is enabled in the UE;
Optionally, indication of 'applicability of "lists of PLMN(s) to be used in disaster condition" provided by a VPLMN';
Optionally, list of PLMN(s) to be used in Disaster Condition.
The Activation of Disaster Roaming is performed by the HPLMN by setting the indication of whether Disaster roaming is enabled in the UE to "disaster roaming is enabled in the UE" using the UE Parameters Update Procedure as defined in TS 23.502 [3]. The UE shall only perform disaster roaming if the HPLMN has configured the UE with the indication of whether disaster roaming is enabled in the UE and set the indication to "disaster roaming is enabled in the UE". The UE, registered for Disaster Roaming service, shall deregister from the PLMN providing Disaster Roaming service if the received indication of whether disaster roaming is enabled in the UE is set to "disaster roaming is disabled in the UE".
Check the specs out for complete details.
From my point of view, it makes complete sense to have this enabled for the case when disaster strikes. Earlier this year, local governments in Queensland, Australia were urging the Federal Government to immediately commit to a trial of domestic mobile roaming during emergencies based on the recommendation by the Regional Telecommunications Independent Review Committee. Other countries and regions would be demanding this sooner or later as well. It is in everyone's interest that the operators enable this as soon as possible.
Metaverse means different things for different people. If you explain Metaverse with an example, many people understand but they are generally looking at things from a different point of view. A bit like blind men and an elephant. Similarly when we talk about Metaverse-ready networks, it can mean different things to different people, depending on their background.
Back in Oct 2021, Facebook changed its name to Meta with a vision to bring the metaverse to life and help people connect, find communities and grow businesses. This was followed by a blog post by Dan Rabinovitsj, Vice President, Meta Connectivity, highlighting the high-level requirements for these metaverse-ready networks.
At Fyuz 2022, the Telecom Infra Project (TIP) announced the launch of Metaverse-Ready Networks Project Group primary whose objective is to accelerate the development of solutions and architectures that enhance network readiness to support metaverse experiences. Meta Platforms, Microsoft, Sparkle, T-Mobile and Telefónica are the initial co-chairs of this Project Group.
A blast from the past - I'm listening to a Nokia CTO, Alessandro Bovone, setting out Nokia's view of the future #CWIC2022pic.twitter.com/DSN96eK2qh
Cambridge Wireless' CWIC 2022 discussed 'The Hyperconnected Human'. One of the sessions focussed on 'Living in the Metaverse' which I think was just brilliant. The slides are available from the event page and the video is embedded below:
Coming back to metaverse-ready networks, the final day of Fyuz 2022 conference featured 'The Meta Connectivity Summit' produced by Meta.
The main stage featured a lot of interesting panel sessions looking at metaverse use cases and applications, technology ecosystem, operator perspectives as well as a talk by CIO of Softbank. The sessions are embedded below. The breakout sessions were not shared.
Metaverse is also being used as a catch-all for use cases and applications in 6G. While many of the requirements of Metaverse will be met by 5G and beyond applications, 6G will bring in even more extreme requirements which would justify the investments in the Metaverse-Ready Networks.
Ralf Kreher explained EPS Fallback mechanism in his post earlier, which is still quite popular. This post contains couple of videos that also explain this procedure.
The first is a very short and simple tutorial from Mpirical, embedded below:
The second is a slightly technical presentation explaining how 5G system can redirect the 5G VoNR capable device to the 4G system to continue for IMS based VoLTE voice call.
Over the last few months I have discussed the role of 5G in different industries as part of various projects. Some of these discussions are part of my blog posts while others aren’t.
5G is often promoted as a panacea for all industries including healthcare. This presentation and video looks not only at 5G but other connectivity options that can be used to provide solutions for healthcare. In addition, this presentation looks at different components of the mobile network and explore the role of devices in healthcare.
We have looked at different approaches in this blog and the 3G4G website on reducing the power consumption (see related posts below). In a blog post some months back, Huawei highlighted how 5G can improve the battery life of UE. The blog post mentioned four approaches, we have looked at three of them on various blogs.
A UE can access network services only if it establishes a radio resource control (RRC) connection with the base station. In legacy RATs, a UE is either in the RRC_CONNECTED state (it has an RRC connection) or the RRC_IDLE state (it does not have an RRC connection). However, transitioning from the RRC_IDLE state to the RRC_CONNECTED state takes a long time, so it cannot meet the low latency requirement of some 5G services. But a UE cannot just stay in the RRC_CONNECTED state because this will consume much more UE power.
To solve this problem, 5G introduces the RRC_INACTIVE state, where the RRC connection is released but the UE context is retained (called RRC Release with Suspend), so an RRC connection can be quickly resumed when needed. This way, a UE in the RRC_INACTIVE state can access low-latency services whenever needed but consume the same amount of power as it does in the RRC_IDLE state.
DRX + WUS
Discontinuous reception (DRX) enables a UE in the RRC_CONNECTED state to periodically, instead of constantly, monitor the physical downlink control channel (PDCCH) to save power. To meet the requirements of different UE services, both short and long DRX cycles can be configured for a UE. However, when to wake up is determined by the predefined cycle, so the UE might wake up unnecessarily when there is no data scheduled.
Is there a way for a UE to wake up only when it needs to? Wake-up Signal (WUS) proposed in Release 16 is the answer. This signal can be sent before the next On Duration period (during which the UE monitors the PDCCH) so that the UE wakes up only when it receives this signal from the network. Because the length of a WUS is shorter than the On Duration Timer, using WUS to wake up a UE saves more power than using only DRX.
BWP Adaptation
In theory, working on a larger bandwidth consumes more UE power. 5G provides large bandwidths, but it is unnecessary for a UE to always work on large bandwidth. For example, if you play online mobile games on a UE, only 10 MHz of bandwidth is needed for 87% of the data transmission time. As such, Bandwidth Part (BWP) is proposed in 5G to enable UEs to work on narrower bandwidths without sacrificing user experience.
BWP adaptation enables the base station to dynamically switch between BWPs based on the UE’s traffic volume. When the traffic volume is large, a UE can work on a wide BWP, and when the traffic volume is small, the UE can work on a narrow one. BWP switching can be performed based on the downlink control information (DCI) and RRC reconfiguration messages. This ensures that a UE always works on a bandwidth that supports the traffic volume but does not consume too much power.
Maximum MIMO Layers Reduction
According to 3GPP specifications, the number of receive and transmit antennas used by a UE cannot be fewer than the maximum number of MIMO layers in the downlink and uplink, respectively. For example, when a maximum of four downlink MIMO layers are configured for a UE, the UE must enable at least four receive antennas to receive data. Therefore, if the maximum number of MIMO layers can be reduced, the UE does not have to activate as many antennas, reducing power consumption.
This can be achieved in 5G because the number of MIMO layers can be re-configured based on assistance information from UEs. After receiving a request to reduce the number of MIMO layers from a UE, the base station configures fewer MIMO layers for the UE through an RRC reconfiguration message. In this way, the UE can deactivate some antennas to save power.
T-Mobile added more cell sleep profiles (or this is just the first time i noticed it). L2100 is now turned off at night when the cell load is low. After 6am it's back on everywhere. When you load the cell it will also come back online.
Power consumption in the networks and the devices is a real challenge. While the battery capacity and charging speeds are increasing, it is also important to find ways to optimise the signalling parameters, etc. One such approach can be seen in the tweet above regarding regarding T-Mobile in The Netherlands, selectively switching off a carrier in the night and switching it back when the cell starts loading or in the morning.
We will see lot more innovations and optimisations to dynamically update the technologies, parameters, optimisations to ensure power savings wherever possible.
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.
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.”
I recently published IDC's first forecast on 5G network slicing services opportunity. Slicing should be an important tool for telcos to create new services, but it still remains many years away in most markets. A very complicated undertakinghttps://t.co/GNY4xiLFBV
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:
In another new whitepaper on 5G-Advanced, Nokia has detailed DCCA (DC + CA) features and enhancements from Rel-15 until Rel-18. The following is an extract from the paper:
Mobility is one of the essential components of 5G-Advanced. 3GPP has already defined a set of functionalities and features that will be a part of the 5G-Advanced Release 18 package. These functionalities can be grouped into four areas: providing new levels of experience, network extension into new areas, mobile network expansion beyond connectivity, and providing operational support excellence. Mobility enhancements in Release 18 will be an important part of the ‘Experience enhancements” block of features, with the goal of reducing interruption time and improving mobility robustness.
Fig. 2 shows a high-level schematic of mobility and dual connectivity (DC)/Carrier Aggregation (CA) related mechanisms that are introduced in the different 5G legacy releases towards 5G-Advanced in Release 18. Innovations such as Conditional Handover (CHO) and dual active protocol stack (DAPS) are introduced in Release 16. More efficient operation of carrier aggregation (CA), dual connectivity (DC), and the combination of those denoted as DCCA, as well as Multi-Radio Access Technology DC (MR-DC) are introduced through Releases 16 and 17.
For harvesting the full benefits of CA/DC techniques, it is important to have an agile framework where secondary cell(s) are timely identified and configured to the UE when needed. This is of importance for non-standalone (NSA) deployments where a carrier on NR should be quickly configured and activated to take advantage of 5G. Similarly, it is of importance for standalone (SA) cases where e.g. a UE with its Primary Cell (PCell) on NR Frequency Range 1 (FR1) wants to take additional carriers, either on FR1 and/or FR2 bands, into use. Thus, there is a need to support cases where the aggregated carriers are either from the same or difference sites. The management of such additional carriers for a UE shall be highly agile in line with the user traffic and QoS demands; quickly enabling usage of additional carriers when needed and again quickly released when no longer demanded to avoid unnecessary processing at the UE and to reduce its energy consumption. This is of particular importance for users with time-varying traffic demands (aka burst traffic conditions).
In the following, we describe how such carrier management is gradually improved by introducing enhancements for cell identification, RRM measurements and reduced reporting delays from UEs. As well as innovations related to Conditional PSCell Addition and Change (CPAC) and deactivation of secondary cell groups are outlined.
The paper goes on to discuss the following scenarios in detail for DCCA enhancements:
Early measurement reporting
Secondary cell (SCell) activation time improvements
Direct SCell activation
Temporary RS (TRS)-based SCell Activation
Conditional Secondary Node (SN) addition and change for fast access
Activation of secondary cell group
The table below summarizes the DCCA features in 5G NR
When we made our 5G Service Based Architecture (SBA) tutorial some four years back, it was based on Release-15 of the 3GPP standards. All Network Functions (NFs) simply sent discovery requests to the Network Repository Function (NRF). While this works great for trials and small scale deployments it can also lead to issues as can be seen in the slide above.
In 3GPP Release-16 the Service Communication Proxy (SCP) has now been introduced to allow the Control Plane network to handle and prioritize massive numbers of requests in real time. The SCP becomes the control point that mediates all Signalling and Control Plane messages in the network core.
SCP routing directs the flow of millions of simultaneous 5G function requests and responses for network slicing, microservice instantiation or edge compute access. It also plays a critical role in optimizing floods of discovery requests to the NRF and in overall Control Plane load balancing, traffic prioritization and message management.
A detailed whitepaper on '5G Signaling and Control Plane Traffic Depends on Service Communications Proxy (SCP)' by Strategy Analytics is available on Huawei's website here. This report was a follow on from the 'Signaling — The Critical Nerve Center of 5G Networks' webinar here.
Artificial Intelligence (AI) and Machine Learning (ML) has been touted to automate the network and simplify the identification and debug of issues that will arise with increasing network complexity. For this reason 3GPP has many different features that are already present in Release-17 but are expected to evolve further in Release-18.
I have already covered some of this topics in earlier posts. Ericsson's recent whitepaper '5G Advanced: Evolution towards 6G' also has a good summary on this topic. Here is an extract from that:
Intelligent network automation
With increasing complexity in network design, for example, many different deployment and usage options, conventional approaches will not be able to provide swift solutions in many cases. It is well understood that manually reconfiguring cellular communications systems could be inefficient and costly.
Artificial intelligence (AI) and machine learning (ML) have the capability to solve complex and unstructured network problems by using a large amount of data collected from wireless networks. Thus, there has been a lot of attention lately on utilizing AI/ML-based solutions to improve network performance and hence providing avenues for inserting intelligence in network operations.
AI model design, optimization, and life-cycle management rely heavily on data. A wireless network can collect a large amount of data as part of its normal operations. This provides a good base for designing intelligent network solutions. 5G Advanced addresses how to optimize the standardized interfaces for data collection while leaving the automation functionality, for example, training and inference up to the proprietary implementation to support full flexibility in the automation of the network.
AI/ML for RAN enhancements
Three use cases have been identified in the Release 17 study item related to RAN performance enhancement by using AI/ML techniques. Selected use cases from the Release 17 technical report will be taken into the normative phase in the next releases. The selected use cases are: 1) network energy saving; 2) load balancing; and 3) mobility optimization.
The selected use cases can be supported by enhancements to current NR interfaces, targeting performance improvements using AI/ML functionality in the RAN while maintaining the 5G NR architecture. One of the goals is to ensure vendor incentives in terms of innovation and competitiveness by keeping the AI model implementation specific. As shown in Fig.2 (on the top) an intent-based management approach can be adopted for use cases involving RAN-OAM interactions. The intent will be received by the RAN. The RAN will need to understand the intent and trigger certain functionalities as a result.
It is generally expected that AI/ML functionality can be used to improve the radio performance and/or reduced the complexity/overhead of the radio interface. 3GPP TSG RAN has selected three use cases to study the potential air interface performance improvements through AI/ML techniques, such as beam management, channel state information feedback enhancement, and positioning accuracy enhancements for different scenarios. The AI/ML-based methods may provide benefits compared to traditional methods in the radio interface. The challenge will be to define a unified AI/ML framework for the air interface by adequate AI/ML model characterization using various levels of collaboration between gNB and UE.
AI/ML in 5G core
5G Advanced will provide further enhancements of the architecture for analytics and on ML model life-cycle management, for example, to improve correctness of the models. The advancements in the architecture for analytics and data collection serve as a good foundation for AI/ML-based use cases within the different network functions (NFs). Additional use cases will be studied where NFs make use of analytics with the target to support in their decision making, for example, network data analytics functions (NWDAF)- assisted generation of UE policy for network slicing.
If you are interested in studying this topic further, check out 3GPP TR 37.817: Study on enhancement for data collection for NR and ENDC. Download the latest version from here.
I recently participated in a webinar, discussing one of my favourite topics, 5G Standalone (5G SA). If you do not know about 5G SA, you may want to quickly watch my short and simple video on the topic here.
Last year I blogged about GSA's 5G Standalone webinar here. That time we were discussing why 5G SA is taking time to deliver, it was sort of a similar story this time. Things are changing though and you will see a lot more of these standalone networks later this year and even early next year.
The slides of the webinar are available here and the video is embedded below:
Here are some of my thoughts on why 5G SA is taking much longer than most people anticipated:
5G SA will force operators to move to 5G core which is a completely new architecture. The transition to this is taking much longer than expected, especially if there are a lot of legacy services that needs to be supported.
Many operators are moving towards converged core with 4G & 5G support to simply the core. This transition is taking long.
For taking complete advantage of 5G architecture, cloud native implementation is required. Some operators have already started the transition to cloud native but others are lagging.
5G SA speeds will be lower than NSA speeds hence some operators who don't have a lot of mid-band spectrum are delaying their 5G SA rollouts.
Many operators have managed to reduce their latency as they start to move to edge datacentres, hence the urgency for 5G standalone has reduced.
Most operators do not see any new revenue opportunities because of 5G SA, hence they want to be completely ready before rolling out 5G SA
Finally, you may hear a lot about not enough devices supporting 5G SA but that's not the device manufacturers views. See this tweet from GSA 👇
With 5G SA networks now being launched, GSA is already aware of 842 announced devices with claimed support for 5G SA, up 202% from 278 at the end of 2020.
