How 3GPP Release 19 Optimises UE-Satellite-UE Voice and Video Communications

One of the interesting developments in 3GPP Release 19 is the introduction of optimised UE-Satellite-UE communications, allowing voice and video traffic between two satellite-connected devices to be routed through satellites without unnecessarily passing through the terrestrial core network.

We briefly covered this feature in our earlier discussion of Release 19 NTN enhancements, but a recent article (in Japanese) from the NTT DOCOMO Technical Journal, published in October 2026, provides a much more detailed explanation of the underlying 5G Core (5GC) and IP Multimedia Subsystem (IMS) architecture, along with the procedures needed to establish and maintain these communications.

The article, titled 5GC Enhancement Technologies for Satellite Communication Networks in 3GPP Release 19, explains how satellite-based user-plane functions, IMS media gateways and terrestrial control-plane functions work together to enable more efficient voice and video services.

Connectivity Technology Blog: The Evolution of NTN in 3GPP from Release 17 to Release 19 - https://t.co/kli6czwOBy #3G4G5G #ConnectivityTechnology #3GPP #NTN #Release17 #Release18 #Release19 #Release20 #D2D #NRNTN #NTNNBIoT #SystemInformationBlocks #SIBs #Spectrum https://t.co/DrcTUpaBeK

— 3G4G (@3g4gUK) April 17, 2026

To understand the significance of this development, it is worth briefly revisiting the evolution of 5G Non-Terrestrial Networks (NTN). Release 17 introduced NTN support based primarily on transparent satellite payloads, where satellites act as radio repeaters while the gNB and core network functions remain on the ground. Release 18 introduced core network architectural enhancements for regenerative GEO satellites, where additional processing and network functions can be located onboard. Release 19 further develops regenerative NTN architectures and supports scenarios involving LEO satellites with onboard user-plane functionality.

One problem with conventional satellite communication architectures is that even when two devices communicate through satellites belonging to the same constellation, their user traffic may still need to travel down to a terrestrial gateway, through the ground network, and then back up to the satellite serving the receiving device.

As shown in the diagram above, traffic from the originating UE travels to its serving satellite and across an inter-satellite link (ISL), before being routed through an NTN gateway and terrestrial 5GC. It then returns through the satellite network to reach the destination UE.

This introduces unnecessary satellite-to-ground and ground-to-satellite transmissions, increasing propagation delay and consuming feeder-link capacity. Depending on the constellation and routing arrangement, the additional latency can become significant, particularly for delay-sensitive applications such as voice and video calls.

Release 19 addresses this by allowing the media traffic to be routed locally through the satellite network, provided that the necessary network functions and inter-satellite connectivity are available. In the optimised arrangement, voice or video packets travel from one UE to its serving satellite, pass through satellite-based network functions and, when required, use inter-satellite links to reach the satellite serving the other UE. The traffic can therefore avoid traversing terrestrial network elements.

Importantly, this does not mean that the entire 5G Core or IMS network has been moved into space. This is probably the most interesting aspect of the architecture. The Release 19 solution places selected user-plane functions onboard the regenerative satellites, including the IMS Access Gateway (IMS-AGW), Uplink Classifier (UL-CL) and Local PDU Session Anchor (L-PSA). The IMS-AGW handles the media path associated with an IMS session. The UL-CL provides traffic classification and steering, allowing relevant packets to be directed towards the local satellite-based processing functions. The L-PSA provides the local user-plane anchoring needed for the optimised media path.

However, the main PDU Session Anchor (PSA) UPF remains on the ground. This is important because it allows the UE's IMS PDU session IP address to remain unchanged as the serving satellite changes. Similarly, IMS control-plane functions such as the Proxy Call Session Control Function (P-CSCF) and Serving Call Session Control Function (S-CSCF) remain terrestrial.

In other words, the network separates the handling of voice and video packets from the signalling and control functions used to establish and manage the communication. The media can remain in space even though the session is still controlled through the terrestrial network. The architecture also relies on coordination between IMS and the 5GC. It is not sufficient simply to install a UPF on a satellite. The network must determine which satellites are serving the two devices, whether optimised routing is possible, and where the relevant media processing functions should be configured.

The call establishment procedure uses familiar IMS signalling, with additional mechanisms to support satellite identification and media path selection. When a UE initiates a voice or video call, it sends a SIP INVITE message. The originating P-CSCF obtains information from the terrestrial 5GC identifying the satellite currently serving the UE. Initially, a terrestrial IMS-AGW is selected, providing a conventional media path while the network determines whether satellite optimisation is possible.

The satellite identifier is conveyed towards the terminating side through the IMS signalling procedures. The terminating P-CSCF also obtains the identity of the satellite serving the receiving UE. Using this information, the network determines whether both sides can support optimised satellite media routing. If the required conditions are satisfied, the P-CSCFs select satellite-based IMS-AGWs, release the initially allocated terrestrial gateways where appropriate, and coordinate with the 5GC to configure the UL-CL and L-PSA functions onboard the satellites.

The 5GC policy and session management mechanisms, including interaction with the Policy Control Function (PCF) and Session Management Function (SMF), help establish the necessary traffic steering and Quality of Service (QoS) treatment. Once the procedure is complete, the IMS voice or video media can travel through the satellite network rather than being routed through terrestrial gateways.

It is worth emphasising that this is not a direct device-to-device radio connection. Each device still communicates with its serving satellite using the normal satellite access interface. The optimisation takes place inside the satellite network, with the appropriate onboard user-plane functions handling the media traffic.

Another important consideration is mobility. Unlike a conventional terrestrial mobile network, where the base station is generally stationary, LEO satellites move continuously relative to the Earth's surface. Even a stationary user may need to change serving satellites frequently as satellites enter and leave the visible coverage area.

This creates an additional challenge for optimised UE-Satellite-UE communication. A voice or video call may already be using satellite-based IMS-AGWs and local user-plane functions when one of the devices changes its serving satellite. Simply transferring the radio connection to another satellite is not enough. The media path must also be updated so that packets continue to reach the correct gateway and user-plane functions.

Release 19 defines procedures for maintaining the optimised media path when the serving satellite changes, as well as falling back to terrestrial routing when satellite-based optimisation can no longer be maintained.

When a UE changes its serving satellite, the 5GC can provide an early notification to the P-CSCF containing the identity of the target satellite. The P-CSCF then determines whether optimised routing can continue between the new serving satellite and the satellite serving the other UE. If it can, the network selects an IMS-AGW on the target satellite and coordinates the necessary user-plane configuration.

The SMF manages the appropriate UL-CL and L-PSA configuration, while updated media transport information is provided for the continuing session. This allows the media route to change without requiring the user to establish a completely new call. There will, however, be situations where the optimised route cannot be maintained. For example, the required inter-satellite connectivity may not be available, or the new satellite arrangement may not support the necessary media path.

Rather than allowing the communication to fail simply because the optimised path is unavailable, Release 19 also supports a terrestrial fallback procedure.

In this case, the P-CSCF arranges for the media to be routed through a terrestrial IMS-AGW instead of continuing through the optimised satellite path. The relevant media transport information is updated and provided through the 5GC. Both continued satellite optimisation and terrestrial fallback require the IMS session to be updated. This is achieved through the SIP RE-INVITE procedure.

The IMS Application Server (IMS-AS) plays a role in coordinating this update. Following the change of media gateway, the IMS-AS initiates SIP RE-INVITE signalling so that the two sides can renegotiate the media transport addresses associated with the ongoing session. Depending on whether the network is maintaining satellite-based routing or falling back to the ground, the relevant IMS-AGWs and media paths are updated accordingly.

This is particularly important for LEO satellite systems, where changes in the serving satellite are a normal part of operation rather than an occasional event. The ability to relocate media functions and update traffic paths is essential for maintaining service continuity, although actual interruption performance will depend on network implementation and operating conditions.

There are also some important limitations to the Release 19 functionality. The standardised UE-Satellite-UE optimisation discussed here is restricted to IMS-based voice and video services involving two devices belonging to the same Public Land Mobile Network (PLMN), without roaming. It does not provide a general-purpose mechanism for arbitrary data communication between any two satellite-connected devices.

The requirement for satellite-based processing also means that the feature is intended for appropriately equipped regenerative satellite networks. It should not be confused with conventional transparent-payload direct-to-device services. NTT DOCOMO identifies support for additional services, including mission-critical communications and non-IMS data exchange, as areas for further development. Communication between different PLMNs and roaming scenarios also remains an important area for future standardisation, with related work being considered in Release 20.

From a network architecture perspective, this development is particularly interesting because it demonstrates how 5G is evolving towards more distributed processing. Instead of forcing all traffic through a centralised terrestrial network, selected user-plane and media functions can operate closer to the devices being served, even when those functions are located on moving satellites.

There are, of course, practical challenges. Satellite resources, onboard processing capabilities, inter-satellite connectivity, transport topology and coordination between terrestrial and non-terrestrial network functions will influence how such systems can be deployed. Standardising the architecture does not necessarily mean that operators have already implemented these capabilities commercially.

Nevertheless, the Release 19 enhancements represent an important step towards more tightly integrated terrestrial and non-terrestrial mobile networks. While the immediate focus is on optimising IMS voice and video communication, the underlying principles of distributed user-plane processing, dynamic media routing and service continuity are likely to remain relevant as NTN architectures evolve towards 6G.

For those interested in the detailed procedures, the original NTT DOCOMO article is well worth reading, particularly its signalling diagrams. The relevant 3GPP specifications include TS 23.501, which covers the 5G System architecture for UE-Satellite-UE communication, and TS 23.228, whose Annex AE addresses the IMS architecture and media routing procedures.

Related Posts: 

• The 3G4G Blog: 3GPP Release 19 Description and Summary of Work Items
• The 3G4G Blog: Release 19 Takes Satellite, NTN and Aerial Connectivity Further
• Connectivity Technology Blog: The Evolution of NTN in 3GPP from Release 17 to Release 19
• The 3G4G Blog - Energy Efficiency Improvements in 3GPP Technologies: From LTE to 5G-Advanced
• The 3G4G Blog: AIoT and A-IoT
• The 3G4G Blog: The Evolution of 3GPP 5G Network Slice and Service Types (SSTs)
• The 3G4G Blog - 5G-Advanced Store and Forward (S&F): Enabling Resilient IoT Communications via Satellite 

Seamless UE Context Recovery (SUECR) in 3GPP Release 18

3GPP Release 18 introduces a wide range of enhancements across the 5G system, from energy efficiency and XR optimisation to AI-powered features. Among these developments is a practical but important addition known as Seamless User Equipment Context Recovery (SUECR), designed to handle situations where a device temporarily goes offline.

When a device such as a smartphone or IoT unit undergoes an operating system upgrade, a modem reset or a software update, it may become unavailable for a period of time. If this happens without informing the network, the operator’s core functions and connected application servers may continue to treat the device as available. This can result in wasted signalling, unnecessary retries and disruptions to critical operations that depend on the device’s availability.

SUECR provides a solution by allowing the device to notify the network of an unavailability period, which is a defined window of time during which it cannot communicate. Both the device and the core network retain important session and mobility information so that once the device returns, service can continue smoothly without unnecessary procedures.

The feature works in two ways depending on the device’s ability to store context information. If the device can preserve its mobility and session management contexts in non-volatile memory or on the SIM, it executes a registration procedure before going offline. The unavailability period is included in this request, and the Access and Mobility Management Function (AMF) records the duration and recognises the device as unreachable until it re-registers. If an application function has subscribed to receive updates on device availability, the AMF also forwards this information so that application servers can adapt accordingly. If the device cannot save its context, it instead executes a deregistration procedure to notify the AMF of its unavailability, with similar treatment by the network until the device performs its next registration.

Once the update or reset is complete, the device re-registers with the network and resumes normal service. If the planned downtime is delayed, cancelled or extended, the device repeats the procedure to keep the network and applications accurately informed. This ensures that network functions and application servers no longer waste resources attempting to reach devices that are temporarily offline.

By introducing SUECR, Release 18 strengthens service reliability and efficiency. It prevents unnecessary signalling and enables critical applications to maintain accurate awareness of device availability. The figure above, from NTT Docomo’s Technical Journal, illustrates how the unavailability period is managed depending on whether the registration or deregistration procedure is used.

Seamless User Equipment Context Recovery may appear as a small enhancement in the context of all the new Rel-18 features, but it addresses an important gap in 5G operations. As networks continue to evolve towards automation and support for mission-critical services, this function will play a key role in making device management more predictable and dependable.

Related Posts: 

• The 3G4G Blog: 3GPP Release 18 Description and Summary of Work Items
• The 3G4G Blog: Understanding L1/L2 Triggered Mobility (LTM) Procedure in 3GPP Release 18
• The 3G4G Blog: 3GPP Release 18 Signal level Enhanced Network Selection (SENSE) for Smarter Network Selection in Stationary IoT
• The 3G4G Blog: Low Latency Power Saving with Low Power-Wake Up Signal/Receiver (LP-WUS/LP-WUR)
• The 3G4G Blog: UE Assistance Information in LTE and 5G 

Understanding L1/L2 Triggered Mobility (LTM) Procedure in 3GPP Release 18

In an earlier post we looked at the 3GPP Release 18 Description and Summary of Work Items. One of the key areas was Further NR mobility enhancements, where a new feature called L1/L2-triggered mobility (LTM) has been introduced. This procedure aims to reduce mobility latency and improve handover performance in 5G-Advanced.

Mobility has always been one of the most important areas in cellular networks. The ability of a user equipment (UE) to move between cells without losing service is essential for reliability and performance. Traditional handover procedures in 4G and 5G rely on Layer 3 (L3) signalling, which is robust but can result in high signalling overhead and connection interruption times of 50 to 90 milliseconds. While most consumer services can tolerate this, advanced use cases with strict latency demands cannot.

3GPP Release 18 takes a significant step forward by introducing the L1/L2 Triggered Mobility (LTM) procedure. Instead of relying only on L3 signalling, LTM shifts much of the handover process down to Layer 1 (physical) and Layer 2 (MAC), making it both faster and more efficient. The goal is to reduce interruption to around 20 to 30 milliseconds, a level that can better support applications in ultra-reliable low latency communication, extended reality and mobility automation.

The principle behind LTM is straightforward. The UE is preconfigured with candidate target cells by the network. These configurations can be provided in two ways: either as a common reference with small delta updates for each candidate or as complete configurations. Keeping the configuration of multiple candidates allows the UE to switch more quickly without requiring another round of reconfiguration after each move.

Measurements are then performed at lower layers. The UE reports reference signal measurements and time and phase information to the network. Medium Access Control (MAC) control elements are used to activate or deactivate target cell states, including transmission configuration indicator (TCI) states. This ensures the UE is already aware of beam directions and reference signals in the target cells before the actual switch.

A particularly important innovation in LTM is the concept of pre-synchronisation. Both downlink and uplink pre-synchronisation can take place while the UE is still connected to the serving cell. For downlink, the network instructs the UE to align with a candidate cell’s beams. For uplink, the UE can transmit a random-access preamble towards a target cell, and the network calculates a timing advance (TA) value. This TA is stored and delivered only at the moment of execution, allowing the UE to avoid a new random access procedure. In cases where TA is already known or equal to the serving cell, the handover becomes RACH-less, eliminating a significant source of delay.

The final step is the LTM cell switch command. This MAC control element carries the chosen target configuration, TA value and TCI state indication. Since synchronisation has already been achieved, the UE can break the old connection and resume data transfer almost immediately in the new cell.

Compared to earlier attempts such as Dual Active Protocol Stack (DAPS) handover, which required maintaining two simultaneous connections and faced practical limitations, LTM offers a more scalable solution. It can be applied across frequency ranges, including higher bands above 7 GHz where beamforming is critical, and it works for both intra-DU and inter-DU mobility within a gNB.

The Release 18 specification restricts LTM to intra-gNB mobility, but work has already begun in Release 19 to expand it further. Future enhancements are expected to cover inter-gNB mobility and to refine measurement reporting for even greater efficiency.

Looking beyond 5G Advanced, new concepts are being explored for 6G. At the Brooklyn 6G Summit 2024, MediaTek introduced the idea of L1/L2 Triggered Predictive Mobility (LTPM), where predictive intelligence could play a role in mobility decisions. While this is still at an early research stage, it points to how mobility management will continue to evolve.

For now, the introduction of LTM marks a practical and important milestone. By reducing handover latency significantly, it brings the network closer to meeting the demanding requirements of next generation services while maintaining efficiency in signalling and resource use.

Related Posts: 

• The 3G4G Blog: 3GPP Release 18 Description and Summary of Work Items
• Free 6G Training: MediaTek’s View on Enabling a Healthy and User-Centric 6G Device Ecosystem
• The 3G4G Blog: Understanding the Dual Active Protocol Stack (DAPS) Handover in 5G
• The 3G4G Blog: DCCA Features and Enhancements in 5G New Radio 

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.

The Bridge Toward 6G: 5G-Advanced Evolution in 3GPP Release 19 by Xingqin Lin, @NVIDIA - https://t.co/O1d8jnB9MY#Free5Gtraining #3G4G5G #3GPP #5G #5GAdvanced #6G #AIML #NGRAN #XR #UAV #LPWUS #LPWUR #HighPerforming #LTM #SBFD #Femtocell #NTN #WAB #Relay pic.twitter.com/aSC9FuruC7

— Free 5G Training (@5Gtraining) January 2, 2024

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: 

• The 3G4G Blog: 3GPP TSG RAN and TSG SA Release-19 Workshop Summary
• The 3G4G Blog: ETSI's Summit on Sustainability: ICT Standards for a Greener World
• The 3G4G Blog: Four Ways 5G Can Improve the Battery Life of User Equipment (UE)
• The 3G4G Blog: Energy Consumption in Mobile Networks and RAN Power Saving Schemes
• The 3G4G Blog: Reducing 5G Device Power Consumption Using Connected-mode Discontinuous Reception (C-DRX)
• The 3G4G Blog: Mobile Initiated Connection Only (MICO) mode in 5G System 

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: 

• The 3G4G Blog: EPS Fallback Mechanism in 5G Standalone Networks
• The 3G4G Blog: Is there a compelling Business Case for 5G Network Slicing in Public Networks?
• The 3G4G Blog: IP Multimedia Subsystem (IMS) Support for Service Based Architecture (SBA)
• The 3G4G Blog: Network Slicing using User Equipment Route Selection Policy (URSP)
• The 3G4G Blog: 5G User Plane Redundancy
• The 3G4G Blog: 5G Non IP Data Delivery and Lightweight M2M (LwM2M) over NIDD
• The 3G4G Blog: 5G Enhanced URLLC (eURLLC)
• The 3G4G Blog: Two Types of SMS in 5G
• The 3G4G Blog: Four Ways 5G Can Improve the Battery Life of User Equipment (UE)
• The 3G4G Blog: CUPS for Flexible U-Plane Processing Based on Traffic Characteristics
• The 3G4G Blog: Tutorial on 4G/5G Mobile Network Uplink Working and Challenges
• The 3G4G Blog: Open RAN Terminology and Players
• 3G4G: Free 2G, 3G, 4G & 5G Training Videos 

Small Data Transmission (SDT) in LTE and 5G NR

One of the features that was introduced part of 5G NR 3GPP Release 17 is known as Small Data Transmission (SDT). When small amount of data, in case of an IoT device, needs to be sent, there is no need to establish data radio bearers. The information can be sent as part of signalling message. A similar approach is available in case of 4G LTE. 

Quoting from Ofinno whitepaper 'Small Data Transmission: PHY/MAC', 

The SDT in the 3GPP simply refers to data transmission in an inactive state. Specifically, the SDT is a transmission for a short data burst in a connectionless state where a device does not need to establish and teardown connections when small amounts of data need to be sent.

In the 3GPP standards, the inactive state had not supported data transmission until Release 15. The 3GPP standards basically allowed the data transmission when ciphering and integrity protection are achieved during the connection establishment procedure. Therefore, the data transmission can occur after the successful completion of the establishment procedure between the device and network.

The problem arises as a device stays in the connected state for a short period of time and subsequently releases the connection once the small size data is sent. Generally, the device needs to perform multiple transmissions and receptions of control signals to initiate and maintain the connection with a network. As a payload size of the data is relatively smaller compared with the amounts of the control signals, making a connection for the small data transmission becomes more of a concern for both the network and the device due to the control signaling overhead.

The 3GPP has developed the SDT procedure to enable data transmission in the inactive state over the existing LTE and NR standards. The device initiates the SDT procedure by transmitting an RRC request message (e.g., SDT request message) and data in parallel instead of transmitting the data after the RRC request message processed by a network. Additional transmission and/or reception are optional. The device performs this SDT procedure without transition to the connected state (i.e., without making a connection to the network).

The SDT enables for the network to accept data transmission without signaling intensive bearer establishment and authentication procedure required for the RRC connection establishment or resume procedure. For example, in the SDT procedure, the device needs only one immediate transmission of a transport block (TB) that contains data and RRC request message. Furthermore, the device does not need to perform procedures (e.g., radio link monitoring) defined in the connected state since the RRC state is kept as the inactive state. This results in improving the battery life of the device by avoiding control signaling unnecessary for transmission of small size data.

The principle of the SDT is very simple. The network configures radio resources beforehand for the data transmission in the inactive state. For example, if the conditions to use the configured radio resources satisfy, the device transmits data and the RRC request message together via the configured radio resources. In the 3GPP standards, there are two types of the SDT depending on the ways to configure the radio resources: (1) SDT using a random access (RA) and (2) SDT using preconfigured radio resources. 

Figure 2 (top) illustrates different types of the SDT referred in 3GPP LTE and NR standards. The SDT using the random access in LTE and NR standards is referred to as an EDT (early data transmission) and RA-SDT (Random Access based SDT), respectively. For both the EDT and the RA-SDT, the device performs data transmission using shared radio resources of the random access procedure. Thus, the contention with other devices can occur over the access to the shared radio resources. The shared radio resources for the SDT are broadcast by system information and are configured as isolated from the one for a nonSDT RA procedure, i.e., the legacy RA procedure. On the other hands, the CG-SDT uses the preconfigured radio resources dedicated to the device. The SDT using the preconfigured radio resource is referred to as transmission via PUR (Preconfigured Uplink Resource) in the LTE standards. The NR standards refers the SDT using the preconfigured radio resource as CG-SDT (Configured Grant based SDT). The network configures the configuration parameters of the preconfigured radio resources when transiting the device in the connected state to the inactive state. For example, an RRC release message transmitted from the network for a connection release contains the configuration parameters of PUR or CG-SDT. No contention is expected for the SDT using the preconfigured radio resource since the configuration parameters are dedicated to the device. 

You can continue reading the details in whitepaper here. Ofinno has another whitepaper on this topic, 'Small Data Transmission (SDT): Protocol Aspects' here.

3GPP also recently published an article on this topic here. Quoting from the article:

With SDT it is possible for the device to send small amounts of data while remaining in the inactive state. Note that this idea resembles the early GSM systems where SMS messages where sent via the control signalling; that is, transferring small amounts of data while the mobile did not have a (voice) connection.

SDT is a procedure which allows data and/or signalling transmission while the device remains in inactive state without transitioning to connected state. SDT is enabled on a radio bearer basis and is initiated by the UE only if less than a configured amount of UL data awaits transmission across all radio bearers for which SDT is enabled. Otherwise the normal data transmission scheme is used.

With SDT the data is transmitted quickly on the allocated resource. The IoT device initiates the SDT procedure by transmitting an RRC request message and payload data in parallel, instead of the usual procedure where the data is transmitted after the RRC request message is processed by a network.

It is not only the speed and the reduced size of the transmitted data which make SDT such a suitable process for IoT devices. Since the device stays in the inactive state, it does not have to perform many tasks associated with the active state. This further improves the battery life of the IoT device. Additional transmission and/or reception are optional.

There are two ways of performing SDT:

1. via random access (RA-SDT)
2. via preconfigured radio resources (CG-SDT)

Random Access SDT

With RA-SDT, the IoT device does not have a dedicated radio resource, and it is possible that the random access message clashes with similar RA-SDT random access messages from other IoT devices. The device gets to know the radio resources for the RA procedure from system information messages, in a similar way to non RA-SDT devices. However, the RA radio resources for SDT and non SDT devices are kept separate; that is, these device types do not interfere with each other in random access

The RA-SDT procedure can be a two-step or a four-step random access procedure. In two-step procedure the payload data is already sent with the initial random access message, whereas in four-step procedure the device first performs contention resolution with the random access request - random access response message pair, and then sends the UL payload with RRC Resume Request. The procedure may continue with further uplink and downlink small data transmissions, and then it is terminated with an RRC Release from the network.

Below are the signalling diagrams for both two-step and four-step RA-SDT procedures. Note that in both cases the UE stays in the RRC inactive state during the whole process.

Configured Grant SDT

For CG-SDT, the radio resources are allocated periodically based on the estimation of the UE’s traffic requirements. This uplink scheduling method is called Configured Grant (CG). With CG-SDT there will be no message clashes with other IoT devices since the radio resources are dedicated for each device. The resource allocation is signalled to the IoT device by the network when the device leaves the connected state.

If the amount of data in the UE's tx buffer is larger than a defined limit, then the data transmission is done using the normal non-SDT procedure.

For SDT process, the device selects the CG-SDT as the SDT type if the resources for the CG-SDT are configured on the selected uplink carrier. If the resources for the CG-SDT are unavailable or invalid, the RA-SDT or the non-SDT RA procedure will be chosen if those are configured. If no SDT type configuration is available then a normal non-SDT data transmission is performed.

With IoT devices proliferating, it makes sense to optimise data transfer and anything else that will reduce the power consumption and let the battery in the devices last for much longer.

Related Posts: 

• The 3G4G Blog: 3GPP Release 17 Description and Summary of Work Items
• The 3G4G Blog: A Technical Introduction to 5G NR RRC Inactive State
• The 3G4G Blog: Mobile Initiated Connection Only (MICO) mode in 5G System
• The 3G4G Blog: Four Ways 5G Can Improve the Battery Life of User Equipment (UE)
• The 3G4G Blog: Energy Consumption in Mobile Networks and RAN Power Saving Schemes
• The 3G4G Blog: Reducing 5G Device Power Consumption Using Connected-mode Discontinuous Reception (C-DRX)
• The 3G4G Blog: Are there 50 Billion IoT Devices yet?
• The 3G4G Blog: 5G Non IP Data Delivery and Lightweight M2M (LwM2M) over NIDD
• The 3G4G Blog: Introduction to 5G Reduced Capability (RedCap) Devices
• The 3G4G Blog: Embedded SIM (eSIM) and Integrated SIM (iSIM)
• Connectivity Technology Blog: Is LTE Cat 1bis Uniting the Fragmented Cellular IoT Market? 

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.

I've been waiting for this for many years. https://t.co/Wcl34M1aZy Disaster roaming, now part of 3gpp rel17. https://t.co/F4LAyIp7VE

— Silke Holtmanns (@SHoltmanns) October 2, 2022

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:

• The 3G4G Blog: 2G/3G Shutdown may Cost Lives as 4G/5G Voice Roaming is a Mess
• The 3G4G Blog: Transitioning from eCall to NG-eCall and the Legacy Problem
• The 3G4G Blog: Study of Use cases and Communications Involving IoT devices in Emergency Solutions
• The 3G4G Blog: enhanced Public Warning System (ePWS) in 3GPP Release-16
• The 3G4G Blog: ETWS detailed in LTE and UMTS 

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: 

• The 3G4G Blog: Control and User Plane Separation of EPC nodes (CUPS) in 3GPP Release-14
• The 3G4G Blog: IP Multimedia Subsystem (IMS) Support for Service Based Architecture (SBA)
• The 3G4G Blog: Different Types of RAN Architectures - Distributed, Centralized & Cloud
• The 3G4G Blog: 5G RAN Functional Splits
• Telecoms Infrastructure Blog: NTT Docomo's 5G Network is based on 'Open RAN' Principles
• Telecoms Infrastructure Blog: NTT Docomo's 5G RAN Infrastructure
• The 3G4G Blog: A look at 5G Applications, Application Functions & Application Servers
• The 3G4G Blog: Three New Standards to Accelerate 5G Wireless Wireline Convergence (WWC)
• Free 6G Training: NTT Docomo is Hoping to Repeat 5G Experimental Trials Success with 6G
• Free 6G Training: NTT Docomo's revised '5G Evolution and 6G' White Paper 

How Multiband-Cells are used for MORAN RAN Sharing

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. 

Related Posts:

• The 3G4G Blog: What is a Multi-Band Cell? 

Managing 5G Signalling Storms with Service Communication Proxy (SCP)

When we made our 5G Service Based Architecture (SBA) tutorial some four years back, it was based on Release-15 of the 3GPP standards. All Network Functions (NFs) simply sent discovery requests to the Network Repository Function (NRF). While this works great for trials and small scale deployments it can also lead to issues as can be seen in the slide above.

In 3GPP Release-16 the Service Communication Proxy (SCP) has now been introduced to allow the Control Plane network to handle and prioritize massive numbers of requests in real time. The SCP becomes the control point that mediates all Signalling and Control Plane messages in the network core.

SCP routing directs the flow of millions of simultaneous 5G function requests and responses for network slicing, microservice instantiation or edge compute access. It also plays a critical role in optimizing floods of discovery requests to the NRF and in overall Control Plane load balancing, traffic prioritization and message management.

A detailed whitepaper on '5G Signaling and Control Plane Traffic Depends on Service Communications Proxy (SCP)' by Strategy Analytics is available on Huawei's website here. This report was a follow on from the 'Signaling — The Critical Nerve Center of 5G Networks' webinar here.

Related Posts:

• 3G4G: 5G Service Based Architecture (SBA)
• The 3G4G Blog: Interfacing HSS and UDM in 5GS with UDICOM (a.k.a NU1 / Nhss)
• The 3G4G Blog: 5G Roaming with SEPP (Security Edge Protection Proxy)
• The 3G4G Blog: Everything you need to know about 5G Security
• 3G4G: 3GPP 5G Specifications

What is a Multi-Band Cell?

Multi-band cells became very popular in modern RAN environment and beside many benefits they also come with some challenges for performance measurement and radio network optimization.

A multi-band cell consists of a default band that shall be used by UEs for initial cell selection and a set of additional frequency band carriers that typically become involved as soon as a dedicated radio bearer (DRB) for payload transmission is established in the radio connection.

The exact configuration of a multi-band cell including all available frequency bands is broadcasted in SIB 1 as shown in the example below.

Different from legacy RAN deployments where – to take the example of a LTE cell – a pair of PCI/eARFCN (Physical Cell Identity/eUTRAN Absolute Radio Frequency Number) always matches a particular ECGI (eUTRAN Cell Global Identity) the multi-band cell has many different PCI/eARFCN combinations belonging to a single ECGI as you can see in the next figure.

Now performance measurement (PM) counters for e.g. call drops are typically counted on the cell ID (ECGI) and thus, in case of mulit-band cells do not reveal on which frequency a radio link failure occurred.

However, knowing the frequency is essential to optimize the radio network and minimize connectivity problems. More detailed information must be collected to find out which of the different frequency bands performs well and which need improvement.

This becomes even more interesting if multi-band cells are used in MORAN RAN sharing scenarios.

In my next blog post I will have a closer look at this special deployment.

Related Posts:

• The 3G4G Blog: How Multiband-Cells are used for MORAN RAN Sharing 

Voice over New Radio (VoNR) Establishment and Release between NG RAN and 5G Core

In this video I explain how QoS Flows for VoNR are established and released especially on N2 reference point between 5G Core and NG RAN.

The pervious video about generic aspects of "QoS Flow Establishments in 5G Standalone RAN and Core" you will find in the first link of the Related Posts listed below:

Related Posts: 

• The 3G4G Blog: QoS Flow Establishments in 5G Standalone RAN and Core
• The 3G4G Blog: Anomaly Detection and other AI Algorithms in RAN Optimization
• The 3G4G Blog: How to Identify Network Slices in NG RAN
• The 3G4G Blog: Network Slicing in NG RAN
• The 3G4G Blog: Network Slicing Tutorials and Other Resources
• The 3G4G Blog: Artificial Intelligence (AI) / Machine Learning (ML) in 5G Challenge by ITU
• The 3G4G Blog: Conditional Handover (Rel. 16) Explained
• The 3G4G Blog: UE Radio Capability Signaling Optimization (RACS) in Rel. 16 

QoS Flow Establishments in 5G Standalone RAN and Core

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

Related Posts: 

• The 3G4G Blog: Anomaly Detection and other AI Algorithms in RAN Optimization
• The 3G4G Blog: How to Identify Network Slices in NG RAN
• The 3G4G Blog: Network Slicing in NG RAN
• The 3G4G Blog: Network Slicing Tutorials and Other Resources
• The 3G4G Blog: Artificial Intelligence (AI) / Machine Learning (ML) in 5G Challenge by ITU
• The 3G4G Blog: Conditional Handover (Rel. 16) Explained
• The 3G4G Blog: UE Radio Capability Signaling Optimization (RACS) in Rel. 16 

How to Identify Network Slices in NG RAN

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

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

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

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

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

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

Slice/Service type	SST value	Characteristics
eMBB	1	Slice suitable for the handling of 5G enhanced Mobile Broadband.
URLLC	2	Slice suitable for the handling of ultra- reliable low latency communications.
MIoT	3	Slice suitable for the handling of massive IoT.
V2X	4	Slice suitable for the handling of V2X services.

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

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

Related Posts:

• The 3G4G Blog: Network Slicing in NG RAN