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

Thursday, 29 October 2026

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.

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: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , ,

Tuesday, 6 October 2026

How 5G SSSG Reduces UE Power by Cutting Unnecessary PDCCH Monitoring

Power saving has been an important part of the evolution of 5G NR. Some techniques, such as Discontinuous Reception (DRX), allow a device to switch parts of its receiver off for periods of time. Other mechanisms try to reduce the amount of work that the UE needs to perform while it remains connected to the network.

One such mechanism is Search Space Set Group Switching, or SSSG, which allows the network to dynamically adapt how frequently a UE needs to monitor the Physical Downlink Control Channel (PDCCH).

The feature recently received some attention after Rohde & Schwarz announced the initial verification of a 3GPP Release 17 NR conformance test case for SSSG (TC 7.1.1.12.5). While SSSG is not necessarily one of the better-known 5G power-saving features, it is a useful example of how relatively small changes to control-channel operation can help reduce UE power consumption.

To understand SSSG, it helps to first understand why PDCCH monitoring consumes power. The PDCCH carries Downlink Control Information, or DCI. Among other things, DCI tells a UE when and where downlink data is scheduled or provides information relating to uplink transmission. A connected UE therefore needs to wake up at configured times, monitor the appropriate PDCCH search spaces and determine whether any of the control information is intended for it.

Even when there is no user data waiting, the UE may still need to carry out this monitoring. That means parts of the RF and baseband processing chain have to be active simply to discover that there is nothing for the UE. A Search Space Set essentially defines where and when the UE should look for possible PDCCH transmissions. With SSSG, Search Space Sets can be organised into different Search Space Set Groups, allowing the network to change the monitoring behaviour of the UE.

For example, one group could result in relatively frequent PDCCH monitoring, while another group could result in much sparser monitoring. When traffic is arriving frequently, dense monitoring makes sense because the network may need to schedule the UE quickly. When traffic becomes sparse, repeatedly waking the UE to check the PDCCH provides little benefit. Switching the UE to a group with fewer monitoring occasions allows it to spend more time in a lower-power state during periods when it would otherwise be monitoring the PDCCH, including during C-DRX Active Time.

This is illustrated nicely in the Rohde & Schwarz presentation, where the network switches a UE from dense PDCCH monitoring to sparse monitoring when data is arriving less frequently. The same slide also shows a related Release 17 mechanism, PDCCH skipping, where the UE can stop monitoring the PDCCH altogether for a period when there is no data to be transmitted.

The terminology around SSSG can be slightly confusing because the basic concept predates Release 17. Search Space Set Group switching was originally introduced in Release 16 as part of NR-U, allowing a UE to switch between two groups of Search Space Sets with different PDCCH monitoring behaviour. Release 17 extended the concept under the dedicated UE Power Saving Enhancements work item, applying it more directly to connected-mode power saving and introducing enhanced SSSG switching together with PDCCH skipping.

In Release 17, scheduling DCI can carry a PDCCH monitoring adaptation indication as specified in 3GPP TS 38.212 and TS 38.213. Depending on how the UE has been configured via RRC (3GPP TS 38.331), this field can be used to switch between Search Space Set Groups or to instruct the UE to skip PDCCH monitoring.

The Release 17 mechanism can support up to three SSSGs. The Rohde & Schwarz presentation shows scheduling DCI formats 1-1, 0-1, 1-2 and 0-2 carrying a monitoring adaptation indication of up to two bits, which can be used for switching between the configured groups as well as controlling PDCCH skipping.

The network does not simply switch monitoring behaviour indefinitely. Additional configuration defined in 3GPP TS 38.331 controls how the mechanism operates, including how long the UE stays within a Search Space Set Group, the minimum delay before switching takes effect and the duration for which PDCCH monitoring may be skipped. Parameters highlighted in the R&S presentation include searchSpaceGroupIdList, searchSpaceSwitchTimer, searchSpaceSwitchDelay and PDCCHSkippingDurationList. Up to three skipping-duration values can be configured, with the appropriate duration selected dynamically using DCI.

It is worth distinguishing SSSG from DRX because both mechanisms ultimately try to reduce unnecessary PDCCH monitoring. Connected-mode DRX (C-DRX) creates periods during which a UE can sleep rather than continuously monitor the PDCCH. During its Active Time, however, the UE may still have a number of PDCCH monitoring occasions. SSSG adds another level of adaptation during periods when the UE would otherwise be monitoring the PDCCH, including C-DRX Active Time. Instead of treating all active periods in the same way, the network can change the density of PDCCH monitoring according to the expected traffic.

PDCCH skipping takes this one step further by allowing the UE to temporarily skip PDCCH monitoring for a configured duration, subject to conditions defined by 3GPP.

Mechanism Operating Scope Primary Power-Saving Action
Connected-Mode DRX (C-DRX) Active and sleep periods Reduces WHEN the UE needs to monitor PDCCH
SSSG Switching (Rel-16/17) PDCCH monitoring on the active DL BWP Reduces HOW OFTEN selected PDCCH search spaces are monitored
PDCCH Skipping (Rel-17) Temporary PDCCH monitoring suspension Temporarily SKIPS PDCCH monitoring for a configured duration

These mechanisms are therefore complementary rather than alternatives. This becomes particularly useful because mobile traffic is inherently bursty. A UE may remain in RRC_CONNECTED even though there are periods when very little data is being exchanged. Maintaining aggressive PDCCH monitoring throughout these quiet periods wastes energy.

With SSSG, the network can adapt the monitoring behaviour to the actual traffic situation. When activity increases, the UE can use denser monitoring to maintain responsiveness. When traffic falls, the network can move the UE to sparser monitoring. If nothing needs to be scheduled for a period, PDCCH skipping can provide an additional opportunity to save power.

The Rohde & Schwarz presentation places SSSG and PDCCH skipping alongside a wider set of Release 17 UE power-saving enhancements, including paging improvements, TRS occasions for idle and inactive UEs, and relaxation of Radio Link Monitoring and Beam Failure Detection measurements.

The recent conformance-test work is therefore significant not because SSSG has suddenly appeared as a new 5G feature, but because it shows the Release 17 enhancements moving further into practical implementation and verification. There is often a considerable gap between a feature appearing in a 3GPP specification and it becoming something that can be reliably implemented, tested and eventually used in commercial devices and networks. Conformance testing is an important part of closing that gap.

SSSG may sound like a fairly obscure control-channel optimisation, but the underlying idea is simple: if the UE does not need to look for scheduling information so frequently, do not make it do so. Combined with DRX and PDCCH skipping, it is another example of 5G becoming smarter about when a device really needs to be awake and processing control information, rather than simply trying to make individual radio operations more energy efficient.

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , ,

Tuesday, 1 September 2026

Energy Efficiency Improvements in 3GPP Technologies: From LTE to 5G-Advanced

Energy efficiency has become one of the most important topics in mobile networks. Operators need to support growing traffic, wider bandwidths, massive MIMO, better coverage and new services, while also reducing energy consumption, managing cost and meeting sustainability targets.

We have put together a five-part video series looking at Energy Efficiency Improvements in 3GPP Technologies, starting with LTE and then moving through 5G NR, 5G-Advanced Release 18 and 3GPP Release 19.

The aim of the series is to explain the topic in a structured way. Energy saving in mobile networks is not simply about switching equipment off. It requires careful coordination between radio design, traffic load, user experience, QoS, mobility, device behaviour, RAN hardware, network policies and service requirements.

The five videos in the playlist are:

  1. Energy Efficiency in Mobile Networks: The Basics - This introductory video explains why energy efficiency matters, why the RAN gets most attention, how energy saving differs from energy efficiency, and why measurements and KPIs are essential before optimisation.
  2. How LTE Networks Save Energy - This video looks at LTE energy-saving mechanisms including dormant mode, carrier switch-off, secondary antenna deactivation, common channel power control, Cell DTX, compensation cells, and OAM or signalling-based control.
  3. Why 5G NR Is More Energy Efficient by Design - This part explains the energy-efficiency improvements built into 5G NR, including lean carrier design, sleep opportunities, Bandwidth Parts, carrier aggregation, UE DRX, massive MIMO, beamforming and radio hardware evolution.
  4. 5G-Advanced Release 18 Network Energy Saving - This video looks at Release 18 Network Energy Saving features such as SSB-less SCells, Cell DTX/DRX, CSI enhancements, antenna adaptation, PDSCH power adaptation, Conditional Handover for NES cells and legacy UE handling.
  5. 3GPP Release 19 Energy Efficiency and Energy Saving - The final video looks at Release 19 enhancements including on-demand SSB operation for SCells, on-demand SIB1 for idle/inactive UEs, SSB periodicity adaptation, PRACH and paging adaptation, LP-WUS/WUR, Energy Information Function, OAM, slicing, charging and energy efficiency as a service criterion.

The overall message from the series is that mobile network energy efficiency has evolved from relatively simple resource switch-off mechanisms towards more intelligent, adaptive and service-aware optimisation. LTE introduced many of the early practical ideas. 5G NR provided a more flexible and energy-efficient foundation. 5G-Advanced Release 18 made RAN Network Energy Saving more explicit, and Release 19 expands the topic towards on-demand signalling, UE wake-up efficiency and system-wide energy awareness.

The complete playlist is embedded below.

The main references used for this series include 3GPP article, 3GPP TR 21.919, 3GPP TR 38.864, 3GPP TR 38.869, NGMN material on 5G energy efficiency best practices, and technical material from Nokia Bell Labs on 5G-Advanced Network Energy Saving.

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , , , , , ,

Tuesday, 11 August 2026

Next Generation eCall Finally Moves to 4G and 5G

Back in 2022, I wrote about the transition from the original eCall system to Next Generation eCall, or NG eCall. At the time, one of the big concerns was what would happen to millions of vehicles relying on 2G and 3G as mobile operators gradually switched off these legacy networks.

Four years later, the transition is no longer something happening in the distant future. 2026 is an important year for NG eCall in Europe.

For anyone unfamiliar with eCall, it is the European emergency calling system built into vehicles. Following a serious accident, the vehicle can automatically call the European emergency number 112, or the call can be triggered manually. Along with establishing a voice connection, the vehicle sends a Minimum Set of Data (MSD) containing information such as its location, direction of travel and other relevant vehicle information. eCall has been required for new M1 and N1 vehicle types in the EU since April 2018.

The problem is that the original eCall architecture was designed around circuit-switched 2G and 3G networks. The MSD is transferred using an in-band modem during the emergency voice call.

NG eCall takes a different approach. It uses packet-switched connectivity and IMS, allowing eCall to operate over 4G LTE and 5G. At the protocol level, it becomes an IMS emergency call, with SIP used for call signalling and the eCall MSD carried as emergency-call data within the SIP-based session.

This transition became much more significant on 1 January 2026. From that date, new M1 and N1 vehicle types in the EU have to support packet-switched eCall. Public Safety Answering Points (PSAPs) that were already deployed are also required to support eCall over packet-switched 4G/5G networks from the beginning of 2026.

The standards have continued to evolve as well. Commission Delegated Regulation (EU) 2025/1871 updated the regulatory references to the newer EN 17184:2024, covering eCall high-level application protocols using IMS over packet-switched networks, and EN 17240:2024, covering end-to-end conformance testing. There are transitional arrangements during 2026, with the newer EN standards becoming mandatory for new type approvals from 1 January 2027.

There is also evidence that the ecosystem is moving from specifications to actual interoperability testing. In June 2026, ETSI organised its latest NG eCall Plugtests in Ljubljana. Testing focused on interoperability between In-Vehicle Systems (IVS) and PSAPs over 4G LTE, and importantly included access to a real Telekom Slovenije mobile network rather than relying entirely on simulated infrastructure. Testing used ETSI TS 103 683, with EN 17240:2024 conformance testing also supported.

However, moving new vehicles to NG eCall does not make the legacy problem disappear.

The existing European vehicle fleet contains a very large number of cars whose eCall systems still depend on 2G/3G. EU rules therefore require PSAPs to continue supporting circuit-switched eCall while at least one circuit-switched mobile network remains operational in the relevant Member State.

A European Commission Joint Research Centre study published in May 2026 highlights the scale of the challenge. Its modelling estimates that there could still be around 66.8 million passenger vehicles equipped with circuit-switched eCall at the end of 2027. The study considers several possible mitigation approaches, including upgrading suitable existing eCall units to 4G, using 4G-capable third-party eCall systems and providing aftermarket solutions for vehicles that cannot otherwise be upgraded.

So, in some ways, we now have two parallel eCall transitions taking place. New vehicles and emergency infrastructure are moving towards IMS-based NG eCall over 4G and 5G, while the industry still has to work out how to keep tens of millions of older vehicles able to contact emergency services as 2G and 3G networks disappear.

The short Rohde & Schwarz video below provides a good overview of how eCall and NG eCall work, followed by an explanation of how the technology can be tested from the GNSS module and telematics control unit (TCU) through to complete vehicle-level testing.


Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , , , , , , , , ,

Thursday, 9 April 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: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , , ,

Tuesday, 26 November 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: 

Posted by Zahid Ghadialy at 17:35 Leave a comment...0 comments so far
Labels: , , , , , , , , , , , ,

Wednesday, 24 January 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: 

Posted by Zahid Ghadialy at 07:33 Leave a comment...2 comments so far
Labels: , , , , , , , , , , ,

Tuesday, 17 January 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: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...1 comments so far
Labels: , , , , , ,
Subscribe to: Posts (Atom)