The 3G4G Blog is our most popular blog, running for over 15 years with nearly 15 million views. With 2022 coming to an end, here are the top 10 most viewed posts from 2022. These posts were not necessarily posted this year, so I have added the month and year each of them was posted.
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.
At 'The Things Conference' in Amsterdam in September, Roman Nemish, Co-Founder & President of TEKTELIC presented a critical view of different IoT technologies and argued that LoRaWAN is the only technology that will eventually make mass IoT possible.
The following is the intro to the talk from the conference:
IoT technology has progressed from home to city-scale applications, making it a crucial part of any operational process. IoT sensors are becoming more affordable, reliable, and easy to deploy.
The Internet of Things has already brought advancement to healthcare, retail, city infrastructure, and manufacturing with many other opportunities still open.
We are ready to explain why IoT deployment has transformed from privilege to necessity, what benefits it can bring to your business, and how you win the competition using IoT.
2 of 2: "The IoT game... is better served by smaller-sized providers without regional licenses offering broadly-equivalent technologies in unlicensed bands" - https://t.co/9QcqoiIRh0
Enterprise IoT Insights have a good take on the talk here. The following is an extract:
Nemish, president at TEKTELIC, argued that new-wave cellular IoT – in the form of NB-IoT and LTE-M, primarily – is “too expensive” for consumers and too small-margin for mobile operators; that “most IoT opportunities are 10-25 times smaller [than the kinds of deals that would] attract operator attention”. Cellular IoT has “vast potential”, he concluded, but requires a “different approach”.
In other words, there is not enough profit in (low-power) cellular IoT for mobile operators to give it proper focus – and the deals are not big enough to make them really care. The IoT game – based on finely-calculated returns on volume-deals not going much higher than 100,000 units at a time – is better served by smaller-sized providers, without regional spectrum licences, offering broadly-equivalent technologies in unlicensed bands, he implied.
But experiences with Sigfox and LoRaWAN (in some formats) – the French-born IoT twin-tech that started the whole low-power wide-area (LPWA) movement, and forced the cellular community to come up with their own alternatives – have not been much better, necessarily, the story goes. Sigfox pumped $350 million over 10 years into its technology and network, only to go into receivership at the start of 2022 with fewer than 20 million devices under management.
The problem, said Nemish, is with the business model, and not the tech. (As an aside, a takeaway from The Things Conference last week, as from the LoRaWAN World Expo in Paris in the summer, and from any number of private discussions in between, is the IoT market is mature enough to let go of its closely-held tech differences, and acknowledge that customers don’t really care so long as it works – and so the blame switches to the business model, instead.)
Nemish blamed Sigfox’s ‘failure’ on exclusive single-market contracts and cripping licensing fees; these “killed most operator business plans”, he suggested. Of course, Sigfox lives to see another day – and, it might be noted, Taiwan-based IoT house Unabiz, its new owners, have just hosted the 0GUN Alliance of Sigfox operators in France to bash-out a new operator model, and a collaborative approach to a “unified LPWAN world”.
And LoRaWAN is not exempt in the analysis, either. In Amsterdam, Nemish held up the madly-hyped Helium model for crypto-led community network building as another failed IoT business model. Again – and of course, with a critical appraisal of a LoRaWAN network by a LoRaWAN provider – the tech is not the problem, just the way it is being offered. Because Helium, he said, with $1 billion of public community funding, has “no use” after three years.
As per the slide, parent Nova Labs has “failed to sign customers, implement SLA(s), or plan network evolution”, he suggested. The community behind it, originally bedsit enthusiasts on to a good thing, are not motivated by “IoT adoption but [by] crypto-mania”, said Nemish. Just look on eBay, where 10,000 secondhand Helium miners (gateways) are being flogged, to see how its star has fallen, he said – along with its stock, with HNT trading up 12 percent at around $5 at writing, on the back of a deal for decentralised 5G with T-Mobile in the US, but down from a high of nearly $30 a few months ago.
Here's a belated apology from seasoned tech reporter @gigastacey, an early believer and promoter of @Helium.
Stacey has made $20,000 from a hotspot that served... $0.05 of IoT data.
The article highlights some heated discussions on the presentation and slides. You can read the whole article here.
The closing slide nicely summarises that IoT deployment is a marathon, not a sprint. End users are interested in solving real-world problems. Partner to develop complete IoT solutions that can be integrated simply with any IoT platform and with clearly defined API. Also have a strong engineering team to support customer integration and early deployment.
Here is the video of the talk for anyone interested:
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:
I looked at Control and User Plane Separation (CUPS) in a tutorial, nearly five years back here. Since then most focus has been on 5G, not just on my blogs but also from the industry.
Earlier this year, NTT Docomo's Technical Journal looked at CUPS for Flexible U-Plane Processing Based on Traffic Characteristics. The following is an extract from the article:
At the initial deployment phase of 5th Generation mobile communication systems (5G), the 5G Non-Stand-Alone (NSA) architecture was widely adopted to realize 5G services by connecting 5G base stations to the existing Evolved Packet Core (EPC). As applications based on 5G become more widespread, the need for EPC to achieve higher speed and capacity communications, lower latency communications and simultaneous connection of many terminals than ever has become urgent. Specifically, it is necessary to increase the number of high-capacity gateway devices capable of processing hundreds of Gbps to several Tbps to achieve high-speed, high-capacity communications, to distribute gateway devices near base station facilities to achieve even lower latency communications, and to improve session processing performance for connecting massive numbers of terminals simultaneously.
Conventional single gateway devices have both Control Plane (C-Plane) functions to manage communication sessions and control communications, and User Plane (U-Plane) functions to handle communications traffic. Therefore, if the previously assumed balance between the number of sessions and communications capacity is disrupted, either the C-Plane or the U-Plane will have excess processing capacity. In high-speed, high-capacity communications, the C-Plane has excess processing power, and in multiple terminal simultaneous connections, the U-Plane has excess processing power because the volume of communications is small compared to the number of sessions. If the C-Plane and U-Plane can be scaled independently, these issues can be resolved, and efficient facility design can be expected. In addition, low-latency communications require distributed deployment of the U-Plane function near the base station facilities to reduce propagation delay. However, in the distributed deployment of conventional devices with integrated C-Plane and U-Plane functions, the number of sessions and communication volume are unevenly distributed among the gateway devices, resulting in a decrease in the efficiency of facility utilization. Since there is no need for distributed deployment of C-Plane functions, if the C-Plane and U-Plane functions can be separated and the way they are deployed changed according to their characteristics, the loss of facility utilization efficiency related to C-Plane processing capacity could be greatly reduced.
CUPS is an architecture defined in 3GPP TS 23.214 that separates the Serving GateWay (SGW)/Packet data network GateWay (PGW) configuration of the EPC into the C-Plane and U-Plane. The CUPS architecture is designed so that there is no difference in the interface between the existing architecture and the CUPS architecture - even with CUPS architecture deployed in SGW/PGW, opposing devices such as a Mobility Management Entity (MME), Policy and Charging Rules Function (PCRF), evolved NodeB (eNB)/ next generation NodeB (gNB), and SGWs/PGWs of other networks such as Mobile Virtual Network Operator (MVNO) and roaming are not affected. For C-Plane, SGW Control plane function (SGW-C)/PGW Control plane function (PGW-C), and for U-Plane, SGW User plane function (SGW- U)/PGW User plane function (PGW-U) are equipped with call processing functions. By introducing CUPS, C-Plane/U-Plane capacities can be expanded individually as needed. Combined SGW-C/PGW-C and Combined SGW-U/PGW-U can handle the functions of SGW and PGW in common devices. In the standard specification, in addition to SGW/PGW, the Traffic Detection Function (TDF) can also be separated into TDF-C and TDF-U, but the details are omitted in this article.
From above background, NTT DOCOMO has been planning to deploy Control and User Plane Separation (CUPS) architecture to realize the separation of C-Plane and U-Plane functions as specified in 3rd Generation Partnership Project Technical Specification (3GPP TS) 23.214. Separating the C-Plane and U-Plane functions of gateway devices with CUPS architecture makes it possible to scale the C-Plane and U-Plane independently and balance the centralized deployment of C-Plane functions with the distributed deployment of U- Plane functions, thereby enabling the deployment and development of a flexible and efficient core network. In addition to solving the aforementioned issues, CUPS will also enable independent equipment upgrades for C-Plane and U-Plane functions, and the adoption of U-Plane devices specialized for specific traffic characteristics.
In the user perspective, the introduction of CUPS can be expected to dramatically improve the user experience through the operation of facilities specializing in various requirements, and enable further increases in facilities and lower charges to pursue user benefits by improving the efficiency of core network facilities.
Regarding the CUPS architecture, a source of value for both operators and users, this article includes an overview of the architecture, additional control protocols, U-Plane control schemes based on traffic characteristics, and future developments toward a 5G Stand-Alone (5G SA) architecture.
In the previous blog post I have explained the concept of multi-band cells in LTE networks and promised to explain a bit deeper how such cells can be used in Multi-Operator RAN (MORAN) scenarios.
MORAN is characterized by the fact that all network resources except the radio carriers and the Home Subscriber Server (HSS) are shared between two or more operators.
What this means in detail can be see in Step 1 of the figure below.
The yellow Band #1 spectrum of the multi-band cell is owned by Network Operator 1 while the blue spectrum of Band #2 and Band #3 belongs to Network Operator 2.
Band #1 is the default band. This means if a UE enters the cell is always has to establish the initial RRC signaling connection on Band #1 as shown in step 1.
The spectrum owned by Network Operator 2 comes into the game as soon as a dedicated radio bearer (DRB), in the core network known as E-RAB, is established in this RRC connection.
Then we see intra-frequency (intra-cell) handover to Band #2 where the RRC signaling connection is continued. Band #3 is added for user plane transport as a secondary "cell" (the term refers to the 3GPP 36.331 RRC specification).
The reason for this behavior can be explained when looking a frequency bandwidths.
The default Band #1 is a low frequency band with a quite small bandwidth, e.g. 5 MHz. as it is typically used for providing good coverage in rural areas. Band #2 is also a lower frequency band, but Band #3 is a high frequency band with maximum bandwidth of 20 MHz. So Band #3 brings the highest capacity for user plane transport and that is the reason for the handover to the spectrum owned by Network Operator 2 and the carrier aggregation used on these frequency bands.
However, due to the higher frequency the footprint of Band #3 is lower compared to the other two frequency bands.
For UEs at the cell edge (or located in buildings while being served from the outdoor cell) this leads quite often to situations where the radio coverage of Band #3 becomes insufficient. In such cases the UE typically sends a RRC measurement event A2 (means: "The RSRP of the cell is below a certain threshold.").
If such A2 event is received by the eNB it stops the carrier aggregation transport and releases the Band #3 resources so that all user plane transport continues to run on the limited Band #2 resources as shown in step 3.
And now in the particular eNB I observed a nice algorithm starts that could be seen as a kind of zero-touch network operation although it does not need big data nor artificial intelligence.
10 seconds after the secondary frequency resources of Band #3 have been deleted they are added again to the connection, but if the UE is still at the same location the next A2 will be reported soon and carrier aggregation will be stopped again for 10 seconds and then the next cycle starts.
This automation loop is carried out endlessly until the UE changes its location or the RRC connection is terminated.
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
