Friday 30 December 2022

Top Blog Posts of 2022

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.

  1. Network Slicing using User Equipment Route Selection Policy (URSP), Nov 2021
  2. 5G & AI Powered Smart Hospitals, Dec 2021
  3. Four Ways 5G Can Improve the Battery Life of User Equipment (UE), Sep 2022
  4. 3GPP Release-18 Work Moves Into Focus as Release-17 Reaches Maturity, Jan 2022
  5. What is RF Front-End (RFFE) and why is it so Important?, Jan 2022
  6. How Multiband-Cells are used for MORAN RAN Sharing, Aug 2022
  7. Key enablers for mass IoT adoption, Oct 2022
  8. Positioning Techniques for 5G NR in 3GPP Release-16, Oct 2020
  9. Impact of 5G on Lawful Interception and Law Enforcement, Dec 2021
  10. 3GPP 5G Non Terrestrial Networks (NTN) Standardization Update, Jan 2022

Related Posts

Saturday 24 December 2022

3GPP Release 17 Description and Summary of Work Items

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

5 Integration of satellite components in the 5G architecture
5.1 General traffic (non-IoT)
5.1.1 SA and CT aspects
5.1.2 RAN aspects
5.2 NB-IoT/eMTC support for Non-Terrestrial Networks

6 Services to "verticals"
6.1 Introduction
6.2 Generic functionalities, to all verticals
6.2.1 Network and application enablement for verticals
6.2.1.1 Enhanced Service Enabler Architecture Layer for Verticals
6.2.1.2 Enhancements for Cyber-physical control Applications in Vertical domains (eCAV)
6.2.1.3 Enhancements of 3GPP Northbound Interfaces and APIs
6.2.2 Location and positioning
6.2.2.1 RAN aspects of NR positioning enhancements
6.2.2.2 Enhancement to the 5GC LoCation Services-Phase 2
6.2.3 Support of Non-Public and Private Networks
6.2.3.1 Enhanced support of Non-Public Networks
6.2.3.2 Enhancement of Private Network support for NG-RAN
6.3 Specific verticals support
6.3.1 Railways
6.3.1.1 Enhancements to Application Architecture for the Mobile Communication System for Railways Phase 2
6.3.1.2 Enhanced NR support for high speed train scenario (NR_HST)
6.3.1.2.1 NR_HST for FR1
6.3.1.2.2 NR_HST for FR2
6.3.1.3 NR Frequency bands for Railways
6.3.1.3.1 Introduction of 900MHz NR band for Europe for Rail Mobile Radio (RMR)
6.3.1.3.2 Introduction of 1900MHz NR TDD band for Europe for Rail Mobile Radio (RMR)
6.3.2 Mission Critical (MC) and priority service
6.3.2.1 Mission Critical Push-to-talk Phase 3
6.3.2.2 Mission Critical Data Phase 3
6.3.2.3 Mission Critical security Phase 2
6.3.2.4 Mission Critical Services over 5GS
6.3.2.5 Enhanced Mission Critical Communication Interworking with Land Mobile Radio Systems (CT aspects)
6.3.2.6 Mission Critical system migration and interconnection (CT aspects)
6.2.3.7 MC services support on IOPS mode of operation
6.3.2.8 MCPTT in Railways
6.3.2.9 Multimedia Priority Service (MPS) Phase 2
6.3.3 Drone/UAS/UAV/EAV
6.3.3.1 Introduction
6.3.3.2 General aspects
6.3.3.2.1 5G Enhancement for UAVs
6.3.3.2.2 Application layer support for UAS
6.3.3.3 Remote Identification of UAS
6.3.4 Media production, professional video and Multicast-Broadcast
6.3.4.1 Communication for Critical Medical Applications
6.3.4.2 Audio-Visual Service Production
6.3.4.3 Multicast-Broadcast Services (MBS)
6.3.4.3.1 Multicast-broadcast services in 5G
6.3.4.3.2 NR multicast and broadcast services
6.3.4.3.3 5G multicast and broadcast services
6.3.4.3.4 Security Aspects of Enhancements for 5G MBS
6.3.4.4 Study on Multicast Architecture Enhancements for 5G Media Streaming
6.3.4.5 5G Multicast-Broadcast User Service Architecture and related 5GMS Extensions
6.3.4.6 Other media and broadcast aspects
6.4 Other "verticals" aspects

7 IoT, Industrial IoT, REDuced CAPacity UEs and URLLC
7.1 NR small data transmissions in INACTIVE state
7.2 Additional enhancements for NB-IoT and LTE-MTC
7.3 Enhanced Industrial IoT and URLLC support for NR
7.4 Support of Enhanced Industrial IoT (IIoT)
7.5 Support of reduced capability NR devices
7.6 IoT and 5G access via Satellite/Non-Terrestrial (NTN) link
7.7 Charging enhancement for URLLC and CIoT
7.8 Messaging in 5G

8 Proximity/D2D/Sidelink related and V2X
8.1 Enhanced Relays for Energy eFficiency and Extensive Coverage
8.2 Proximity-based Services in 5GS
8.3 Sidelink/Device-to-Device (D2D)
8.3.1 NR Sidelink enhancement
8.3.2 NR Sidelink Relay
8.4 Vehicle-to-Everything (V2X)
8.4.1 Support of advanced V2X services - Phase 2
8.4.2 Enhanced application layer support for V2X services

9 System optimisations
9.1 Edge computing
9.1.1 Enhancement of support for Edge Computing in 5G Core network
9.1.2 Enabling Edge Applications
9.1.3 Edge Computing Management
9.2 Slicing
9.2.1 Network Slicing Phase 2 (CN and AN aspects)
9.2.2 Network Slice charging based on 5G Data Connectivity
9.3 Access Traffic Steering, Switch and Splitting support in the 5G system architecture; Phase 2
9.4 Self-Organizing (SON)/Autonomous Network
9.4.1 Enhancement of data collection for SON/MDT in NR and EN-DC
9.4.2 Autonomous network levels
9.4.3 Enhancements of Self-Organizing Networks (SON)
9.5 Minimization of service Interruption
9.6 Policy and Charging Control enhancement
9.7 Multi-(U)SIM
9.7.1 Support for Multi-USIM Devices (System and CN aspects)
9.7.2 Support for Multi-SIM Devices for LTE/NR

10 Energy efficiency, power saving
10.1 UE power saving enhancements for NR
10.2 Enhancements on EE for 5G networks
10.3 Other energy efficiency aspects

11 New Radio (NR) physical layer enhancements
11.1 Further enhancements on MIMO for NR
11.2 MIMO Over-the-Air requirements for NR UEs
11.3 Enhancements to Integrated Access and Backhaul for NR
11.4 NR coverage enhancements
11.5 RF requirements for NR Repeaters
11.6 Introduction of DL 1024QAM for NR FR1
11.7 NR Carrier Aggregation
11.7.1 NR intra band Carrier Aggregation
11.7.2 NR inter band Carrier Aggregation
11.8 NR Dynamic Spectrum Sharing
11.9 Increasing UE power high limit for CA and DC
11.10 RF requirements enhancement for NR FR1
11.11 RF requirements further enhancements for NR FR2
11.12 NR measurement gap enhancements
11.13 UE RF requirements for Transparent Tx Diversity for NR
11.14 NR RRM further enhancement
11.15 Further enhancement on NR demodulation performance
11.16 Bandwidth combination set 4 (BCS4) for NR
11.17 Other NR related activities
11.18 NR new/modified bands
11.18.1 Introduction of 6GHz NR licensed bands
11.18.2 Extending current NR operation to 71 GHz
11.18.3 Other NR new/modified bands

12. New Radio (NR) enhancements other than layer 1
12.1 NR Uplink Data Compression (UDC)
12.2 NR QoE management and optimizations for diverse services

13 NR and LTE enhancements
13.1 NR and LTE layer 1 enhancements
13.1.1 High-power UE operation for fixed-wireless/vehicle-mounted use cases in LTE bands and NR bands
13.1.2 UE TRP and TRS requirements and test methodologies for FR1 (NR SA and EN-DC)
13.1.3 Other Dual Connectivity and Multi-RAT enhancements
13.2 NR and LTE enhancements other than layer 1
13.2.1 Enhanced eNB(s) architecture evolution for E-UTRAN and NG-RAN
13.2.2 Further Multi-RAT Dual-Connectivity enhancements
13.2.3 Further Multi-RAT Dual-Connectivity enhancements

14 LTE-only enhancements
14.1 LTE  inter-band Carrier Aggregation
14.2 LTE new/modified bands
14.2.1 New bands and bandwidth allocation for 5G terrestrial broadcast - part 1
14.3 Other LTE bands-related aspects

15 User plane improvements
15.1 Immersive Teleconferencing and Telepresence for Remote Terminals
15.2 8K Television over 5G
15.3 5G Video Codec Characteristics
15.4 Handsets Featuring Non-Traditional Earpieces
15.5 Extension for headset interface tests of UE
15.6 Media Streaming AF Event Exposure
15.7 Restoration of PDN Connections in PGW-C/SMF Set
15.8 Other media and user plane aspects

16 Standalone Security aspects
16.1 Introduction
16.2 Authentication and key management for applications based on 3GPP credential in 5G (AKMA)
16.3 AKMA TLS protocol profiles
16.4 User Plane Integrity Protection for LTE
16.5 Non-Seamless WLAN offload authentication in 5GS
16.6 Generic Bootstrapping Architecture (GBA) into 5GC
16.7 Security Assurance Specification for 5G
16.8 Adapting BEST for use in 5G networks
16.9 Other security aspects

17 Signalling optimisations
17.1 Enhancement for the 5G Control Plane Steering of Roaming for UE in Connected mode
17.2 Same PCF selection for AMF and SMF
17.3 Enhancement of Inter-PLMN Roaming
17.4 Enhancement on the GTP-U entity restart
17.5 Packet Flow Description management enhancement
17.6 PAP/CHAP protocols usage in 5GS
17.7 Start of Pause of Charging via User Plane
17.8 Enhancement of Handover Optimization
17.9 Restoration 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

18 Standalone Management Features
18.1 Introduction
18.2 Enhanced Closed loop SLS Assurance
18.3 Enhancement of QoE Measurement Collection
18.4 Plug and connect support for management of Network Functions
18.5 Management of MDT enhancement in 5G
18.6 Management Aspects of 5G Network Sharing
18.7 Discovery of management services in 5G
18.8 Management of the enhanced tenant concept
18.9 Intent 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.

Related Posts

Wednesday 30 November 2022

Disaster Roaming in 3GPP Release-17

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.

Related Posts:

Tuesday 22 November 2022

Preparing for Metaverse-Ready Networks

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.

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.

Related Posts

Thursday 20 October 2022

EPS Fallback Mechanism in 5G Standalone 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.

Related Posts:

Tuesday 11 October 2022

The Role of Connectivity and Devices in Healthcare


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.

Presentation and video below

You can download the slides here.

Related Posts

Thursday 6 October 2022

Key enablers for mass IoT adoption

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.

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.

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:

Related Posts

Thursday 29 September 2022

Four Ways 5G Can Improve the Battery Life of User Equipment (UE)

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. 

The following is from the blog post:

RRC_INACTIVE State

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.

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.

Related Posts

Monday 19 September 2022

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

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

Last month ABI Research said in a press release:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Related Posts

Saturday 10 September 2022

CUPS for Flexible U-Plane Processing Based on Traffic Characteristics

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.

The article is available here.

Related Posts