Showing posts with label Technical Details. Show all posts
Showing posts with label Technical Details. Show all posts

Thursday, April 9, 2026

3GPP Release 19 Description and Summary of Work Items

As the journey towards 3GPP Release 20 and 6G (3GPP Rel-21) continues to gather pace, the recently concluded Release 19 comes with a clearer view of what the next phase of 5G evolution, often referred to as 5G-Advanced, will look like in practice. One of the most useful artefacts in this process is the recently published technical report 3GPP TR 21.919, which offers a consolidated snapshot of the features and work items currently shaping this release.

Rather than focusing on detailed specifications, this report takes a step back and provides accessible summaries of the agreed work items. Each summary is intended to answer two simple but important questions: what problem is being addressed, and what impact the feature will have on the overall system. This makes the document particularly valuable not only for specialists deeply involved in standardisation work, but also for a broader audience trying to keep track of where the industry is heading.

It is worth noting that this is still very much a work in progress (50% complete). At the time of publication, just over 60 summaries have been included, with many more expected in future updates. Even so, the current version already highlights the sheer breadth of activity in Release 19, spanning everything from energy efficiency and non-terrestrial networks to AI, immersive services, and advanced radio capabilities.

In this post, I will not attempt to reinterpret or condense the summaries themselves. Instead, I am sharing the full list of topics covered in the report below, which provides a useful index into the areas that 3GPP worked on as part of Release 19.

It should be noted that the technical report (TR) presents the "initial state" of the Features introduced in Release 19, i.e. as they are by the time of publication of this document. Each Feature is subject to be later modified or enhanced, over several years, by the means of Change Requests (CRs). To further outline a feature at a given time, it is recommended to retrieve all the CRs which relate to the given Feature, as explained in its Reference section. 

Below is the list of all topics covered in this report. Some of the topics may be missing a summary, which will be added later in the later updates.  

5 Rel-19 Energy Efficiency, Energy Saving
5.1   Enhancements of Network energy savings for NR
5.2   Low-power wake-up signal and receiver for NR (LP-WUS/WUR)
5.3   Energy Efficiency as Service Criteria

6   Rel-19 Satellite (5GSAT), NTN, UAS, Aerial
6.1   Satellite access Phase 3
6.1.1   Security Aspects of 5G Satellite Access Phase 3
6.1.2   Charging aspects of satellite access Phase 3
6.2   Non-Terrestrial Networks (NTN) for NR Phase 3
6.3   Enhancements for Air-to-ground network for NR
6.4   Inter-RAT mode mobility support from E-UTRAN TN to NR NTN
6.5   Non-Terrestrial Networks (NTN) for Internet of Things (IoT) Phase 3 (for LTE)
6.6   Introduction of IoT-NTN TDD mode
6.7   Enhanced requirements and test methodology for NR NTN and IoT NTN
6.8   On-demand broadcast of GNSS assistance data
6.9   Uncrewed Aerial System Phase 3
6.10   Support for PWS in Satellite E-UTRAN and Satellite NG-RAN
6.11   Introduction of BDS (BeiDou Navigation Satellite System) B2b Signal in A-GNSS for LTE and NR
6.12   Introduction of A-GNSS support for NavIC (Navigation with Indian Constellation) L1 SPS (Standard Positioning Service) in NR & LTE
6.13   Management Aspects of Rel-18's NTN Phase 2
6.14   Lower Selection-priority for PLMN Selection
6.15   New LTE band for 5G broadcast for region 3 utilizing a geosynchronous satellite
6.16   Satellite band-related items
6.16.1   Introduction of Ku bands for NR NTN
6.16.2   Introduction of additional operating NR bands for HAPS (High Altitude Platform Station)
6.16.3   Introduction of another NR NTN S-band (MSS band 2000-2020 MHz UL and 2180-2200 MHz DL)
6.16.4   New NR NTN bands to support Extended L-band and combined MSS L-band and Extended L-band ranges
6.16.5   Introduction of another IoT-NTN S-band (MSS band 2000-2020 MHz UL and 2180-2200 MHz DL)

7   Rel-19 Internet of Things (IoT) and Reduced Capability (RedCap) UE
7.1   NR power class 2 RedCap (Reduced Capability) UE in FR1
7.2   NAS layer overhead reduction for data transfer using CP CIoT
7.3   Management Aspects of RedCap features

8   Ambient power-enabled Internet of Things (IoT)
8.1   Ambient power-enabled Internet of Things (IoT) (SA and CT)
8.1.1   Charging for Ambient power-enabled Internet of Things
8.1.2   Security Aspects of Ambient IoT Services in 5G for Isolated Private Networks
8.2   Solutions for Ambient IoT (Internet of Things) in NR

9   Rel-19 Artificial Intelligence (AI)/Machine Learning (ML)
9.1   AI/ML Model Transfer Phase 2
9.2   Core Network Enhanced Support for Artificial Intelligence (AI)/Machine Learning (ML)
9.3   Application enablement for AI/ML services
9.4   Artificial Intelligence (AI)/Machine Learning (ML) for NR air interface
9.5   Artificial Intelligence (AI)/Machine Learning (ML) for NR air interface
9.6   Enhancements for Artificial Intelligence (AI)/Machine Learning (ML) for NG-RAN
9.7   AI/ML Management Phase 2
9.8   Protocol for AI Data Collection from UPF

10   Rel-19 Verticals and Non Public Network
10.1   Rel-19 Enhancements of 3GPP Northbound and Application Layer Interfaces and APIs
10.2   SEAL DD (Data Delivery) Phase 2
10.3   Common Application Programming Interface (API) Framework (CAPIF) Phase 3
10.4   Enhanced OAM for management service exposure to external consumers through CAPIF
10.5   Non-Public Network (NPN) security considerations
10.6   Security for PLMN hosting a NPN
10.7   Interconnect of SNPN
10.8   ProSe support in NPN

11   Rel-19 communications services
11.1   Media Messaging Enhancements
11.2   Terminal Audio quality performance and Test methods for Immersive Audio Services, Phase 2
11.3   EVS Codec Extension for Immersive Voice and Audio Services, Phase 2
11.4   5GMSG Service phase 3
11.5   Video Operating Points - Harmonization and Stereo MV-HEVC
11.6   Advanced Media Delivery
11.7   5G Real-time Transport Protocol Configurations, Phase 2
11.8   Next Generation Real time Communication services Phase 2
11.8.1   System architecture for Next Generation Real time Communication services Phase 2
11.8.2   Security support for the Next Generation Real Time Communication services Phase 2
11.8.3   Application enablement aspects for MMTel

12   Rel-19 XR (eXtended Reality), Augmented Reality (AR), Metaverse, Edge Computing
12.1   Localized Mobile Metaverse Services
12.2   Extended Reality and Media
12.3   XR (eXtended Reality) for NR Phase 3
12.4   Avatar Communications in AR Calls
12.5   Split rendering over IMS
12.6   Enhancement of support for Edge Computing in 5G Core network - Phase 3
12.7   Edge Computing for Industrial Scenarios
12.8   Edge Computing Considering the Operational Needs of Service Hosting Environment
12.9   Architecture for enabling Edge Applications Phase 3

13   Rel-19 High Power UEs (HPUE)
13.1   Rel-19 High power UE (power class 1.5 or 2) for NR intra-band CA or NR inter-band CA/DC band combinations with/without NR Supplementary Uplink (UL)
13.2   Rel-19 High power UE (power class 1.5 and 2) for NR FR1 TDD/FDD single band for handheld/FWA UEs, and high power UE operation (power class 1) for FWVM (fixed-wireless/vehicle-mounted) use cases in a single NR band
13.3   Introduction of Power Class 2 and UE 40MHz Channel Bandwidth in NR band n28
13.4   Rel-19 High power UE (power class 1.5 or 2) for DC combinations of LTE band(s) and NR band(s)
13.5   Rel-19 High power UE (power class 2) and high power operation (power class 1) for fixed-wireless/vehicle-mounted use cases in a single LTE band

14   Rel-19 RAN topology
14.1   5G NR Femto
14.2   Additional topological enhancements for NR
14.3   Vehicle Mounted Relays Phase 2

15   Rel-19 Sidelink, Proximity
15.1   NR sidelink multi-hop relay
15.2   UE-to-UE multi-hop relay
15.3   NR Sidelink: Intra-band Carrier Aggregation in ITS band
15.4   Charging Aspects of Ranging and Sidelink Positioning
15.5   Multi-path relay
15.6   Proximity-based Services in 5GS Phase 3

16   NR and LTE Dual Connectivity (DC)
16.1   UE RF enhancements for NR FR1/FR2 and EN-DC, Phase 4
16.2   Support of intra-band non-collocated EN-DC/NR-CA deployment Phase2: new receiver type(s)
16.3   Rel-19 downlink interruption for NR and EN-DC band combinations at dynamic Tx Switching in Uplink
16.4   Rel-19 DC of x LTE band(s), y NR band(s) (1<=x<6, 1<=y<6, x+y<=6) and single or two NR Supplementary Uplink (SUL) bands
16.5   Simultaneous Rx/Tx band combinations for NR CA/DC, NR SUL and LTE/NR DC in Rel-19
16.6   UE Conformance - Rel-19 NR CA and DC; and NR and LTE DC Configurations

17   Rel-19 Other NR and LTE Radio
17.1   Adding channel bandwidth(s) support to existing NR bands and CA/ENDC combinations in REL-19
17.2   Data collection for SON (Self-Organising Networks)/MDT (Minimization of Drive Tests) in NR standalone and MR-DC (Multi-Radio Dual Connectivity) Phase 4

18   Rel-19 NR Radio
18.1   NR mobility enhancements Phase 4
18.2   Evolution of NR duplex operation: Sub-band full duplex (SBFD)
18.3   NR Radio Resource Management (RRM) Phase 5
18.4   Multi-carrier enhancements for NR Phase 3
18.5   NR demodulation performance Phase 5
18.6   NR MIMO Phase 5
18.7   FR1 TRP, TRS and MIMO OTA testing enhancement Phase 3
18.8   Rel-19 NR CA/DC for x bands DL with y bands UL (x<7, y<3) and SUL/CA band combinations with a single SUL or two SUL cells
18.9   Low band carrier aggregation via switching
18.10  NR channel BW less than 5MHz for FR1 Phase 2
18.11  mmWave in NR: UE spurious emissions and EESS (Earth Exploration Satellite Service) protection
18.12  NR base station (BS) RF requirement evolution for FR1/FR2 and testing
18.13  UE Conformance - New Rel-19 NR licensed bands and extension of existing NR bands
18.14  Other band-related items
18.14.1   7MHz Channel Bandwidth for n26 and n5
18.14.2   Introduction of the NR FDD 1.4 GHz band
18.14.3   Introduction of NR bands n87 and n88
18.14.4   Introduction of NR band n68
18.14.5   Additional NR bands for NR features in Rel-19
18.15  Study on spatial channel model for demodulation performance requirements for NR

19   Rel-19 LTE Radio
19.1   LTE-based 5G Broadcast Phase 2
19.2   Rel-19 LTE-Advanced Carrier Aggregation for x bands (1<=x<= 6) DL with y bands (y=1, 2) UL
19.3   Band-related items
19.3.1   New bands for LTE based 5G terrestrial broadcast for early deployments
19.3.2   Introduction of LTE FDD band in 1800–1830 MHz for Canada

20   Rel-19 Mission Critical, eCall, Emergency
20.1   Enhanced Mission Critical Architecture
20.2   Enhanced Mission Critical Location Management
20.3   Alignment of eCall over IMS with CEN
20.4   UE Conformance - Alignment of eCall over IMS with CEN
20.5   Multiple Location Procedure for Emergency LCS Routing
20.6   Multimedia Priority Service (MPS) for Messaging services
20.7   Mission Critical (MC) services for generic support on Isolated Operation for Public Safety (IOPS) mode of operation
20.8   Sharing of administrative configuration between interconnected MC service systems
20.9   Future Railway Mobile Communication System (FRMCS) Phase 5
20.10   Mission critical security enhancements for release 19
20.11   Protocol enhancements for Mission Critical Services

21   Rel-19 Network Slicing
21.1   Network Controlled Network Slice Selection

22   Rel-19 Service-Based Architecture (SBA)
22.1   UPF enhancement for Exposure And SBA Phase 2
22.2   Automatic Certificate Management Environment (ACME) for the Service Based Architecture (SBA)
22.3   Reducing Information Exposure over SBI
22.4   Service Based Interface Protocol Improvements Release 19

23   Rel-19 QoS and Policy
23.1   Rel-19 Enhancements of UE Policy
23.2   Rel-19 Enhancements of Session Management (SM) Policy
23.3   Minimize the Number of Policy Associations
23.4   Spending Limits for UE Policies in Roaming scenario
23.5   Enhancing Parameter Provisioning with static UE IP address and UP security policy
23.6   Providing per-subscriber VLAN instructions from UDM and DN-AAA
23.7   QoS monitoring enhancement

24   Rel-19 multi-access
24.1   Upper layer traffic steering and switching over dual 3GPP access
24.2   Multi-Access (ATSSS_Ph4)
24.3   ATSSS Rule Provisioning via 3GPP access connected to EPC
24.4   Local traffic routing for multi-access UE

25   Other topics
25.1   Deferred 5GC-MT-LR Procedure for Periodic Location Events based NRPPa Periodic Measurement Reports
25.2   Subscription control for reference time distribution in EPS
25.3   Rel-19 IMS:
25.3.1   PS Data Off for IMS Data Channel Service
25.3.2   IMS Disaster Prevention and Restoration Enhancement
25.3.3   IMS Stage-3 IETF Protocol Alignment
25.4   Identifying non-3GPP Devices Connecting behind a UE or 5G-RG
25.5   Integrated Sensing and Communication
25.6   Rel-19 Application Data Analytics Enablement Service
25.7   Interworking of Non-3GPP Digital Terrestrial Broadcast Networks with 5GS Multicast Broadcast Services
25.8   Minimization of Service Interruption During Core Network Failure Phase 2
25.9   Measurement Data Collection
25.10  Enhanced application layer support for location services
25.11  NF discovery and selection by target PLMN
25.12  MSISDN verification operation support to Nnef_UEId Service
25.13  Rel-19 Enhancements of Network Automation Enablers
25.14  Enhancement of controlling RAT utilization
25.15  CT Aspects for IP Domain usage
25.16  Indirect Network Sharing
25.17  Management of Network Sharing Phase 3
25.18  Roaming Value-Added Services
25.19  Monitoring of signalling traffic in 5G
25.20  Roaming traffic offloading via session breakout in HPLMN
25.21  Stage-3 5GS NAS protocol development 18
25.22  Stage-3 SAE Protocol Development
25.23  Harmonization of test case definitions for cross-RAT usability
25.24  Data management regarding subscriptions and reporting
25.25  PRU Usage Extension supported by Core Network

26   Rel-19 miscellaneous Security
26.1   Security Assurance Specification for maintenance of 5G features
26.2   5G Security Assurance Specification (SCAS) for the Unified Data Repository (UDR)
26.3   5G Security Assurance Specification (SCAS) for the Short Message Service Function (SMSF)
26.4   Addition of 256-bit security Algorithms
26.5   Addition of Milenage-256 algorithm
26.6   Roaming and interconnect authorization aspects in indirect communication
26.7   Public key distribution and Issuer claim verification of the Access Token
26.8   3GPP profiles for cryptographic algorithms and security protocols
26.9   Mobility over non-3GPP access to avoid full primary authentication
26.10  LI Handling of Protected Services
26.11  Lawful Interception Rel-19
26.12  Lawful Interception Guidance Rel-19
26.13  Specification of example algorithm for alternative f5* (f5**) function

27   Rel-19 miscellaneous OAM&charging
27.1   Charging aspects for Multi-Operator Core Network (MOCN) Network Sharing
27.2   Service Based Management Architecture enhancement phase 3
27.3   Management Data Analytics phase 3
27.4   Intent driven management services for mobile network phase 3
27.5   Management of planned configurations
27.6   Management aspects of Network Digital Twins
27.7   Closed Control Loop Management
27.8   Data management phase 2
27.9   5G performance measurements and KPIs phase 4
27.10  5G Advanced NRM features phase 3
27.11  Subscriber and Equipment Trace and QoE collection management
27.12  Management of IAB nodes
27.13  Enhancement of Management Aspects Related of NWDAF Phase 2
27.14  CHF Segmentation
27.15  Subscriber Data Migration

You can download the latest version of the specs from here.

Related Post

Tuesday, November 26, 2024

Low Latency Power Saving with Low Power-Wake Up Signal/Receiver (LP-WUS/LP-WUR)

Power-saving methodologies have been integral to all generations of 3GPP technologies, aimed at reducing the power consumption of user equipment (UEs) and other battery-dependent devices. Some of the stringent requirements of 5G, such as achieving a 10-year battery life for certain IoT devices, have necessitated further optimisation of power consumption. To address this, 3GPP Release 16 introduced the Wake-Up Signal (WUS) power-saving mechanism, designed to significantly reduce energy usage in UEs. For a detailed technical explanation, ShareTechnote provides an excellent overview.

The concept of wake-up radios has been explored for over a decade. In a 2017 blog post, Ericsson highlighted how researchers had been working on designing wake-up radios and receivers, initially aimed at IEEE 802.11 (Wi-Fi) technologies. This idea later gained traction in 3GPP discussions, culminating in a study conducted during Release 18. The findings are comprehensively documented in 3GPP TR 38.869: Study on low-power wake-up signal and receiver for NR (Release 18).

Quoting from the introduction of 3GPP 38.869:

5G systems are designed and developed targeting for both mobile telephony and vertical use cases. Besides latency, reliability, and availability, UE energy efficiency is also critical to 5G. Currently, 5G devices may have to be recharged per week or day, depending on individual's usage time. In general, 5G devices consume tens of milliwatts in RRC idle/inactive state and hundreds of milliwatts in RRC connected state. Designs to prolong battery life is a necessity for improving energy efficiency as well as for better user experience. 

Energy efficiency is even more critical for UEs without a continuous energy source, e.g., UEs using small rechargeable and single coin cell batteries. Among vertical use cases, sensors and actuators are deployed extensively for monitoring, measuring, charging, etc. Generally, their batteries are not rechargeable and expected to last at least few years as described in TR 38.875. Wearables include smart watches, rings, eHealth related devices, and medical monitoring devices. With typical battery capacity, it is challenging to sustain up to 1-2 weeks as required. 

The power consumption depends on the configured length of wake-up periods, e.g., paging cycle. To meet the battery life requirements above, eDRX cycle with large value is expected to be used, resulting in high latency, which is not suitable for such services with requirements of both long battery life and low latency. For example, in fire detection and extinguishment use case, fire shutters shall be closed and fire sprinklers shall be turned on by the actuators within 1 to 2 seconds from the time the fire is detected by sensors, long eDRX cycle cannot meet the delay requirements. eDRX is apparently not suitable for latency-critical use cases. Thus, the intention is to study ultra-low power mechanism that can support low latency in Rel-18, e.g. lower than eDRX latency.

Currently, UEs need to periodically wake up once per DRX cycle, which dominates the power consumption in periods with no signalling or data traffic. If UEs are able to wake up only when they are triggered, e.g., paging, power consumption could be dramatically reduced. This can be achieved by using a wake-up signal to trigger the main radio and a separate receiver which has the ability to monitor wake-up signal with ultra-low power consumption. Main radio works for data transmission and reception, which can be turned off or set to deep sleep unless it is turned on.

The power consumption for monitoring wake-up signal depends on the wake-up signal design and the hardware module of the wake-up receiver used for signal detecting and processing. 

The study should primarily target low-power WUS/WUR for power-sensitive, small form-factor devices including IoT use cases (such as industrial sensors, controllers) and wearables. Other use cases are not precluded, e.g.XR/smart glasses, smart phones. 

As opposed to the work on UE power savings in previous releases, this study will not require existing signals to be used as WUS. All WUS solutions identified shall be able to operate in a cell supporting legacy UEs. Solutions should target substantial gains compared to the existing Rel-15/16/17 UE power saving mechanisms. Other aspects such as detection performance, coverage, UE complexity, should be covered by the evaluation.

Qualcomm's blog post looking at 'How will wireless innovations foster a greener, more sustainable future?' is also worth reading on this topic.

Related Posts

Wednesday, January 24, 2024

UE Assistance Information in LTE and 5G

I have been asked about the UE Assistance Information (UAI) RRC message a few times before. Generally I have always pointed people back to the LTE/5G specifications but here is a concise video that the telecoms technology training company Mpirical have shared recently:

If you want to dig further into details then please see the RRC specifications: 36.331 for LTE and 38.331 for 5G. 

Over the years I have added quite a few short tutorials from Mpirical on this blog, do check them out below.

Related Posts

Tuesday, January 17, 2023

Authentication and Key Management for Applications (AKMA) based on 3GPP credentials in the 5G System (5GS)

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. 

Related Posts

Thursday, September 29, 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

Saturday, September 10, 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

Monday, June 13, 2022

Tutorial on 4G/5G Mobile Network Uplink Working and Challenges

People involved with mobile technology know the challenges with uplink for any generation of mobile network. With increasing data rates in 4G and 5G, the issue has become important as most of the speeds are focused on download but upload speeds are quite poor.

People who follow us across our channels know of many of the presentations we share across them from various sources, not just ours. One such presentation by Peter Schmidt looked at the uplink in details. In fact we recommend following him on Twitter if you are interested in technical details and infrastructure.

The details of his talk as follows:

The lecture highlights the influences on the mysterious part of mobile communications - sources of interference in the uplink and their impact on mobile communication as well as practices for detecting sources of RF interference.

The field strength bar graph of a smartphone (the downlink reception field strength) is only half of the truth when assessing a mobile network coverage. The other half is the uplink, which is largely invisible but highly sensitive to interference, the direction from the end device to the base stations. In this lecture, sources of uplink interference, their effects and measurement and analysis options will be explained.

Cellular network uplink is essential for mobile communication, but nobody can really see it. The uplink can be disrupted by jammers, repeaters, and many other RF sources. When it is jammed, mobile communication is limited. I will show what types of interference sources can disrupt the uplink and what impact this has on cellular usage and how interference hunting can be done.

First I explain the necessary level symmetry of the downlink (from the mobile radio base station - eNodeB to the end device) and the uplink (from the end device back to the eNodeB). Since the transmission power of the end device and eNodeB are very different, I explain the technical background to achieving symmetry. In the following I will explain the problems and possibilities when measuring uplink signals on the eNodeB, it is difficult to look inside the receiver. In comparison, the downlink is very easy to measure, you can see the bars on your smartphone or you can use apps that provide detailed field strength information etc. However, the uplink remains largely invisible. However, if this is disturbed on the eNodeB, the field strength bars on the end device say nothing. I will present a way of observing which some end devices bring on board or can be read out of the chipset with APPs. The form in which the uplink can be disrupted, the effects on communication and the search for uplink sources of disruption will complete the presentation. I will also address the problem of 'passive intermodulation' (PIM), a (not) new source of interference in base station antenna systems, its assessment, measurement and avoidance.

The slides are available here. The original lecture was in German, a dubbed video is embedded below:

If you know of some other fantastic resources that we can share with our audience, please feel free to add them in the comments.

Related Posts

Monday, May 16, 2022

Lawful Intelligence and Interception in 5G World with Data and OTT Apps

Not long ago we looked at the 'Impact of 5G on Lawful Interception and Law Enforcement' by SS8. David Anstiss, Senior Solutions Architect at SS8 Networks gave another interesting talk on Evolving Location and Encryption Needs of LEAs in a 5G world at Telecoms Europe Telco to Techco virtual event in March.

In this talk, David provided an insight in​to how 5G is impacting lawful interception and the challenges Law Enforcement Agencies face as they work with Communication Service Providers to gather intelligence and safeguard society. While there is an overlap with the previous talk, in this video David looked at a real world example with WhatsApp. The talk also covered:

  • Real-world problems with 5GC encryption
  • 5G location capabilities and the impact on law enforcement investigations
  • Optimal solutions for both CSPs and LEAs

The video of the talk is embedded below:

Related Posts:

Tuesday, October 12, 2021

Tuesday, August 24, 2021

3GPP's 5G-Advanced Technology Evolution from a Network Perspective Whitepaper


China Mobile, along with a bunch of other organizations including China Unicom, China Telecom, CAICT, Huawei, Nokia, Ericsson, etc., produced a white paper on what technology evolutions will we see as part of 5G-Advanced. This comes not so long after the 3GPP 5G-Advanced Workshop which a blogged about here.

The abstract of the whitepaper says:

The commercialization of 5G networks is accelerating globally. From the perspective of industry development drivers, 5G communications are considered the key to personal consumption experience upgrades and digital industrial transformation. Major economies around the world require 5G to be an essential part of long-term industrial development. 5G will enter thousands of industries in terms of business, and technically, 5G needs to integrate DOICT (DT - Data Technology, OT - Operational Technology, IT - Information Technology and CT - Communication Technology) and other technologies further. Therefore, this white paper proposes that continuous research on the follow-up evolution of 5G networks—5G-Advanced is required, and full consideration of architecture evolution and function enhancement is needed.

This white paper first analyzes the network evolution architecture of 5G-Advanced and expounds on the technical development direction of 5G-Advanced from the three characteristics of Artificial Intelligence, Convergence, and Enablement. Artificial Intelligence represents network AI, including full use of machine learning, digital twins, recognition and intention network, which can enhance the capabilities of network's intelligent operation and maintenance. Convergence includes 5G and industry network convergence, home network convergence and space-air-ground network convergence, in order to realize the integration development. Enablement provides for the enhancement of 5G interactive communication and deterministic communication capabilities. It enhances existing technologies such as network slicing and positioning to better help the digital transformation of the industry.

The paper can be downloaded from China Mobile's website here or from Huawei's website here. A video of the paper launch is embedded below:

Nokia's Antti Toskala wrote a blog piece providing the first real glimpse of 5G-Advanced, here.

Related Posts

Monday, August 9, 2021

Qualcomm Demoes Sub-band Half Duplex (SBHD)


Qualcomm has been busy promoting its advanced 5G solutions these last few months in the run up to Mobile World Congress (MWC). You can find a detailed write-up on their website here as well as a feature which they did with RCR wireless here.

One of the innovations that caught my attention was Sub-band Half-Duplex (SBHD). In the first glance it looks like the Enhanced Interference Mitigation & Traffic Adaptation (eIMTA) solution we discussed long back here.

Their article talks about how their 5G multi-cell over-the-air (OTA) test network can now support subband half-duplex, allowing for more flexible service multiplexing as well as improved latency and coverage. 

While you can get an idea of what SBHD is from the diagram above, here is a video explaining it further.

Let us know what do you think about how important will this feature be in future 5G networks.

Related Posts:

Wednesday, June 30, 2021

Open RAN Terminology and Players


When we made our little Open RAN explainer, couple of years back, we never imagined this day when so many people in the industry will be talking about Open RAN. I have lost track of the virtual events taking place and Open RAN whitepapers that have been made available just in the last month.

One of the whitepapers just released was from NTT Docomo, just in time for MWC 2021. You can see the link in the Tweet

Even after so much information being available, many people still have basic questions about Open RAN and O-RAN. I helped make an Open RAN explainer series and blogged about it here. Just last week, I blogged about the O-RAN explainer series that I am currently working on, here.

There were some other topics that I couldn't cover elsewhere so made some short videos on them for the 3G4G YouTube channel. The first video/presentation explains Open RAN terminology that different people, companies and organizations use. It starts with open interfaces and then looks at radio hardware disaggregation and compute disaggregation. Moving from 2G/3G/4G to 5G, it also explains the Open RAN approach to a decomposed architecture with RAN functional splits.

If you look at the Telecom Infra Project (TIP) OpenRAN group or O-RAN Alliance, the organizations driving the Open RAN vision and mission, you will notice many new small RAN players are joining one or both of them. In addition, you hear about other Open RAN consortiums that again include small innovative vendors that may not be very well known. 

The second video is an opinion piece looking at what is driving these companies to invest in Open RAN and what can they expect as return in future.

As always, all 3G4G videos' slides are available on our SlideShare channel.

Related Posts: