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: , , , , , ,

Thursday, 17 September 2026

Post-Quantum Cryptography in 3GPP

Quantum computing often appears in discussions about 6G, but one area where its impact is already influencing 3GPP work is security.

Many of the public-key cryptographic algorithms used today rely on mathematical problems that are extremely difficult for conventional computers but could be solved much more efficiently by a sufficiently powerful quantum computer. RSA, Diffie-Hellman and elliptic-curve cryptography are the main examples. This does not mean that a future quantum computer suddenly breaks all 5G security.

The most immediate concern is public-key cryptography. Symmetric mechanisms such as those used for 5G authentication, NAS security and PDCP protection are affected differently and remain considerably more resistant. The main quantum threat to symmetric cryptography comes from Grover's algorithm, which provides a theoretical quadratic speed-up rather than the much more dramatic impact that Shor's algorithm has on RSA and elliptic-curve cryptography.

For 3GPP, the issue is therefore not simply "make 5G quantum safe". The first task is to identify where vulnerable public-key cryptography appears across the system and determine which standards organisation is responsible for replacing it. This work is now well underway in 3GPP SA3.

The main study is 3GPP TR 33.703, Study on Transitioning to Post Quantum Cryptography (PQC) in 3GPP. The latest published version at the time of writing is V20.0.1, Release 20.

Importantly, the study is generation agnostic. PQC should therefore not be thought of as a 6G-only feature. It affects existing 5G systems, 5G-Advanced evolution and future 6G networks.

3GPP had already prepared for this work through TR 33.938, 3GPP Cryptographic Inventory, which identifies where cryptography is used across the 5G System. The inventory includes mechanisms such as TLS, IKEv2, PKI certificates, JOSE, COSE, ECIES, EAP-TLS, EAP-AKA', 5G-AKA, NAS security, PDCP security and MIKEY-SAKKE.

At a simplified level:

3GPP area Typical mechanism Quantum relevance
Subscriber identity privacy SUCI / ECIES Directly affected by elliptic-curve cryptography
Primary authentication 5G-AKA / EAP-AKA' Primarily symmetric cryptography
NAS / PDCP protection Symmetric encryption and integrity Different quantum-security considerations
5G Core interfaces TLS Public-key key establishment and signatures
IPsec interfaces IKEv2 / IPsec Public-key or DH key establishment
Certificates PKI / X.509 Public-key signatures
API and application security JOSE / COSE Signatures and key establishment
Mission Critical Services MIKEY-SAKKE Existing asymmetric key-management mechanism

This distinction is important because much of the cryptography used by 3GPP is actually defined elsewhere. TLS, IKEv2, JOSE, COSE and PKI are mainly developed in the IETF and related standards bodies. 3GPP therefore does not need to invent new post-quantum versions of those protocols. Instead, SA3 can adopt and profile PQC-capable versions as they mature.

TR 33.703 consequently separates protocols largely dependent on other standards organisations from mechanisms that are more directly controlled by 3GPP.

The most important 3GPP-specific case is SUCI, the Subscription Concealed Identifier. 5G introduced SUCI to avoid routinely transmitting a subscriber's permanent identity, the SUPI, over the air. For an IMSI-based subscription, the part identifying the subscriber is concealed using a home-network public key. The home operator provisions the relevant public-key information into the USIM, and the home network later recovers the subscriber identity using the corresponding private key.

The currently standardised public-key SUCI protection schemes use ECIES, the Elliptic Curve Integrated Encryption Scheme.

TS 33.501 defines:

Scheme Identifier Public-key mechanism
Null scheme 0x0 No concealment
Profile A 0x1 X25519 / Curve25519
Profile B 0x2 secp256r1
Future standardised schemes 0x3–0xB Reserved
Proprietary schemes 0xC–0xF Home-operator specific

A simplified existing SUCI procedure is:

UE / USIM                                  Home Network

HN public key
      │
      ▼
Generate ephemeral EC key pair
      │
      ▼
Perform ECDH
      │
      ▼
Shared secret
      │
      ▼
KDF
      │
      ├── Encryption key
      ├── Initial counter
      └── MAC key
      │
      ▼
Protect subscriber-specific identity
(e.g. MSIN for an IMSI-based SUPI)
      │
      ▼
Create SUCI
      │
      └──────────────────────────────────► SIDF
                                             │
                                             ▼
                                    Use HN private key
                                             │
                                             ▼
                               Verify protection and
                                  reconstruct SUPI

The symmetric AES encryption inside this procedure is not the main quantum problem. The vulnerable component is the elliptic-curve key agreement used to establish the shared secret. That makes SUCI particularly interesting from a 3GPP perspective because it cannot simply wait for TLS or IKEv2 to be updated elsewhere. 3GPP needs new SUCI protection mechanisms of its own.

This is one reason a large part of TR 33.703 is devoted to possible future SUCI constructions. The obvious candidate from the post-quantum world is ML-KEM, the Module-Lattice-Based Key Encapsulation Mechanism standardised by NIST in FIPS 203. ML-KEM is a Key Encapsulation Mechanism rather than a conventional public-key encryption algorithm.

The basic idea is:

Home Network creates:
  Public key
  Private key

UE receives HN public key
          │
          ▼
     ML-KEM Encaps
       /       \
      /         \
     ▼           ▼
Shared secret   KEM ciphertext
     │               │
     │               └────────────► Home Network
     │                                  │
     ▼                                  ▼
Derive keys                       ML-KEM Decaps
     │                                  │
     ▼                                  ▼
Conceal SUPI                     Same shared secret

The UE and home network end up with the same shared secret, which can then be used to derive keys for protecting the subscriber identity.

TR 33.703 studies both standalone PQC and hybrid approaches. With standalone PQC, a mechanism such as ML-KEM could replace the elliptic-curve key agreement completely. With a hybrid approach, the new post-quantum mechanism operates alongside the traditional one:

X25519 shared secret ────┐
                         ├──► Combiner ───► Shared secret
ML-KEM shared secret ────┘

The attraction of a hybrid is that security does not depend entirely on one new algorithm during the migration period. If elliptic-curve cryptography eventually becomes vulnerable to quantum attack but ML-KEM remains secure, the post-quantum component protects the result. If a weakness were instead discovered in the newer PQC algorithm before large quantum computers became practical, the traditional component could still provide protection against conventional attackers. The trade-off is increased complexity, larger messages and more demanding interoperability.

TR 33.703 therefore places considerable importance on cryptographic agility, meaning that algorithms need to be replaceable without redesigning the surrounding system every time cryptographic recommendations change. The SUCI study contains many possible approaches rather than a single selected solution. These include standalone PQC, hybrid PQC, nested hybrid schemes, symmetric-key approaches and mechanisms concerned with protection-profile selection. The presence of a proposal in TR 33.703 should therefore not be interpreted as meaning that 3GPP has standardised it.

One particularly useful proposal for understanding the direction of travel considers ML-KEM-768, either on its own or in combination with X25519. In the standalone case, ML-KEM replaces the ECDH operation used by today's ECIES-based profiles. In a hybrid case, the result from ML-KEM is combined with a conventional X25519 shared secret before deriving the keys used for SUCI protection.

There is, however, a major engineering problem. Post-quantum cryptography is much less compact than the elliptic-curve cryptography currently used for SUCI. For Profile A, the ephemeral X25519 public key is only 32 bytes. The transmitted MAC adds another 8 bytes, with the concealed subscriber identifier adding only a small amount more.

ML-KEM is very different:

Parameter set Public key Ciphertext
ML-KEM-512 800 bytes 768 bytes
ML-KEM-768 1,184 bytes 1,088 bytes
ML-KEM-1024 1,568 bytes 1,568 bytes

The ML-KEM-768 ciphertext alone is therefore more than thirty times larger than the ephemeral X25519 public key currently carried in SUCI Profile A. This creates a very practical 3GPP problem. A future PQC-protected SUCI could become larger than the limits assumed by protocols carrying the identity.

3GPP SA3 highlighted this to the IETF in 2026, noting that a PQC SUCI could exceed the 1020-byte EAP MTU and, depending on the selected algorithm and construction, potentially even exceed the size normally associated with a 1500-byte Ethernet MTU. This affects EAP-AKA' because EAP currently does not provide a suitable way to fragment the identity involved in this exchange.

The apparently simple migration:

X25519 → ML-KEM

can therefore turn into:

Larger PQC ciphertext
        ↓
Larger SUCI
        ↓
Larger EAP identity
        ↓
Existing MTU exceeded
        ↓
Fragmentation required
        ↓
EAP-AKA' changes
        ↓
IETF and 3GPP coordination

This is one of the most useful examples in TR 33.703 because it shows that PQC migration is not merely an algorithm substitution problem. It is a protocol and system-design problem. There is a similar issue inside the UE and USIM. The home-network public key used for SUCI protection has to be provisioned and stored somewhere accessible to the SUCI calculation function.

For X25519 this is only 32 bytes.

For ML-KEM-768 it is 1,184 bytes.

If SUCI calculation takes place inside the USIM, the USIM may also need to support the relevant post-quantum computation. If it takes place in the ME, both the ME and USIM still need to understand the new protection profile and associated provisioning.

This raises practical migration questions for 5G devices already in the field:

  • Can existing USIMs support the new profile?
  • Can the HN public key be updated remotely?
  • Can existing devices execute ML-KEM?
  • Does SUCI calculation happen in the ME or USIM?
  • How is algorithm capability indicated?
  • How are HN keys rotated?
  • How do old and new devices coexist?
  • What happens during roaming?

These issues are particularly important because mobile devices, IoT devices and SIMs can remain deployed for many years. SUCI is not the only part of the 5G security architecture that needs to evolve. TLS is extensively used within the 5G Service-Based Architecture. Post-quantum migration affects both TLS key establishment and, eventually, certificate signatures. IKEv2 and IPsec also need quantum-resistant key-establishment options. PKI migration affects CAs, certificates, trust stores, HSMs and network functions. JOSE and COSE also rely on public-key mechanisms that need to evolve.

In these areas, 3GPP is largely dependent on the work of the IETF and other standards organisations:

NIST
  │
  │ standardises PQ algorithms
  ▼
IETF and other SDOs
  │
  │ integrate them into protocols
  ▼
3GPP
  │
  │ profiles them for mobile systems
  ▼
Vendors and operators

This dependency explains why PQC transition work has to begin years before the cryptographic threat becomes immediate. It is also worth being precise about 5G-AKA. 5G-AKA does not simply need to be replaced by ML-KEM. The long-term subscription credential used by 5G-AKA is symmetric, and the resulting authentication and key hierarchy are based largely on symmetric cryptographic mechanisms. The same applies to NAS and PDCP encryption and integrity protection. The quantum-security question for these mechanisms is therefore different from the public-key problem affecting SUCI, TLS, certificates and IKEv2.

A useful simplified distinction is:

SUCI
 │
 └── ECIES / ECDH
       │
       ▼
  Public-key PQC problem


5G-AKA / NAS / PDCP
       │
       ▼
 Symmetric cryptography
       │
       ▼
Different quantum-security problem

This is why statements that "quantum computers will break 5G security" are too simplistic.

The second specifically 3GPP-related mechanism considered in TR 33.703 is MIKEY-SAKKE, which is used within Mission Critical Services. The current study identifies the post-quantum issue but does not provide the final migration solution. This is another reminder that TR 33.703 is a transition study, not the final quantum-safe security architecture. The work has already started moving beyond the study phase. 3GPP now has a Release 20 normative work item called Post-quantum Cryptography Migration Phase 1, or PQCMigration_Ph1-SEC.

The overall progression can therefore be seen as:

TR 33.938
Cryptographic Inventory
        │
        ▼
Where is cryptography used?
        │
        ▼
TR 33.703
PQC Transition Study
        │
        ▼
What needs to change?
        │
        ▼
Rel-20 PQC Migration Phase 1
        │
        ▼
Normative specification changes
        │
        ▼
Further migration phases

This is particularly relevant when looking towards 6G. Release 20 is the main 6G study release, but PQC is deliberately not being treated as something that starts only with a new 6G air interface or 6G Core. The migration needs to begin across existing 5G security mechanisms so that 5G, 5G-Advanced and 6G systems can coexist during what is likely to be a long cryptographic transition.

For mobile networks, the challenge is not just choosing a post-quantum algorithm. It is supporting old and new devices, existing and future SIMs, roaming partners, new certificate chains, larger protocol messages, multiple algorithm generations and potentially hybrid cryptography at the same time. That is why crypto-agility is likely to be one of the most important outcomes of the work.

The industry does not know exactly when a Cryptographically Relevant Quantum Computer will become available. It also cannot assume that today's preferred post-quantum algorithms will remain unchanged for the lifetime of a mobile-network generation. The network therefore needs to be designed so that cryptographic algorithms and profiles can evolve without requiring another fundamental redesign. Perhaps the most useful lesson from TR 33.703 is that the cryptographic mathematics may turn out to be the easy part.

Changing a 32-byte elliptic-curve value into a more than 1-kilobyte post-quantum ciphertext can affect SUCI, USIM provisioning, device implementations, EAP, MTUs, fragmentation, roaming and interoperability. And that is just one security procedure.

PQC in 3GPP is therefore not really a future 6G feature. It is an ongoing migration of the security foundations that 5G, 5G-Advanced and 6G will all depend on.

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: , , , , , , , , , , ,

Friday, 21 August 2026

Multi-Panel UE (MPUE) in 5G and 5G-Advanced

With the introduction of millimetre-wave spectrum in 5G NR, antenna design at the UE became significantly more complicated. At these higher frequencies, increased propagation and penetration losses mean that directional antenna arrays and beamforming are important not only at the base station but also at the device. A single directional antenna array on a smartphone, however, would provide good performance over only part of the surrounding space. Rotate the device, change the direction of the serving cell, or block the antenna with a hand, and the radio link could deteriorate rapidly.

One solution is to place several antenna panels around different parts of the device. This gives rise to the concept of the Multi-Panel User Equipment, or MPUE.

A useful definition appears in a patent on cell reselection for MPUEs. It describes a mobile UE using two or more differently oriented antenna panels, with each providing different angular coverage. Each panel can itself contain multiple closely spaced antenna elements forming an antenna array or antenna module.

In its simplest form, imagine three directional antenna panels positioned around different edges of a smartphone.

Depending on the orientation of the phone, location of the base station and blockage from the user's hand or body, one antenna panel may provide a significantly better radio path than the others.

This type of architecture is particularly interesting for 5G FR2, where directional antenna gain helps compensate for higher path and diffraction losses. Research into MPUE mobility has considered devices with several spatially distinct antenna panels, allowing the UE to exploit antenna directivity while potentially reducing interference arriving from other directions.

An important point is that MPUE should not be thought of simply as a separate type of UE defined by 3GPP.

The antenna-panel implementation has traditionally been largely hidden from the network. In Release 16, for example, antenna panel selection, activation, deactivation and switching were largely left to the UE implementation. Different MPUE hardware architectures can consequently have quite different capabilities and power-consumption characteristics.

Three MPUE assumptions have commonly been used in 3GPP-related work to represent these different hardware capabilities.

  • MPUE-Assumption 1 (MPUE-A1): multiple panels are present, but only one panel can be active at a time. Switching between panels therefore introduces some activation or switching delay.
  • MPUE-Assumption 2 (MPUE-A2): multiple panels can be active simultaneously, and one or more panels can be used for transmission.
  • MPUE-Assumption 3 (MPUE-A3): multiple panels can be active simultaneously for reception and measurements, but only one panel is used for transmission.

These assumptions are useful because having several physical antenna panels does not automatically mean that all of them can measure, receive or transmit simultaneously. The result depends on the RF and baseband architecture inside the device.

This leads to an interesting problem for mobility. If a UE has several antenna panels pointing in different directions, which panel should be used to measure the serving and neighbouring cells?

Research from Nokia and the Vodafone Chair at TU Dresden has looked at this question in multi-beam FR2 networks, particularly comparing MPUE-A1 and MPUE-A3.

With MPUE-A1, only one panel makes measurements at a time. Measurements are therefore effectively obtained sequentially as the UE moves between its available antenna panels.

With MPUE-A3, multiple panels can make measurements simultaneously.

The difference sounds subtle, but it can have an important impact on mobility. Consider a three-panel UE moving through a network. Under MPUE-A3, measurements obtained through all three panels can remain relatively current.

Under MPUE-A1, while Panel 1 is measuring the radio environment, measurements previously obtained through Panels 2 and 3 are getting older. By the time one of those panels is used again, the UE may have moved and the surrounding radio conditions may have changed.

A handover decision can therefore potentially be based on outdated measurements.

The 2022 study Analysis and Performance Evaluation of Mobility for Multi-Panel User Equipment in 5G Networks found that the two MPUE schemes could provide significant mobility-performance gains compared with the reference traditional UE architecture used in the study. It also found that the different MPUE architectures required different mobility-parameter settings to achieve their best performance.

This is an important observation because simply adding more antenna panels does not automatically solve mobility problems. The network procedures and mobility parameters have to take account of how the particular UE actually performs its measurements.

The issue becomes even more interesting when UE-side receive beamforming is added.

Instead of merely selecting one directional antenna panel, the UE can potentially form or steer receive beams within the angular coverage of a panel.

A later study investigated three different UE-side receive-beamforming approaches for an MPUE equipped with three directional panels in a multi-beam FR2 network. In the system-level simulations used in the study, the proposed techniques reduced radio link failures by up to 53% and handover failures by up to 90%. These figures are specific to the assumptions and scenarios used in that research, but they illustrate the potential mobility benefits of combining multiple panels with UE-side beamforming.

There are also interesting implications for interference.

If the serving cell is received strongly through one UE panel while an interfering neighbouring cell lies in a substantially different direction, the directional response of the selected antenna panel can provide some spatial isolation between them.

Research into Fast Conditional Handover has similarly noted that if an MPUE can communicate using panels oriented towards its serving cell, inter-cell interference from neighbouring cells may be significantly suppressed.

A patent from Nokia takes this idea in another direction by proposing the use of spatial separation when performing cell reselection in a network supporting network slicing.

The proposed mechanism considers candidate cells and performs communication-quality measurements using one or more of the UE's antenna panels. It can then consider whether a candidate cell supporting a required network slice is sufficiently spatially separated, or orthogonal, from other candidate cells before selecting it.

It is important to stress that this is a patent proposal rather than functionality defined by current 3GPP cell-reselection procedures.

Cell reselection normally applies when the UE is in RRC_IDLE or RRC_INACTIVE, whereas most of the MPUE mobility research discussed above focuses on connected-mode handover. The patent is interesting precisely because it proposes extending the usefulness of directional MPUE measurements into the cell-reselection problem, particularly where slice availability and intra-frequency interference need to be considered.

The underlying point remains the same: for an MPUE, the radio environment seen by the device can depend not only on where the UE is located, but also on which antenna panel is observing the network and in which direction that panel is looking.

5G-Advanced takes the multi-panel concept another important step forward.

As part of the Release 18 MIMO enhancements, 3GPP introduced support for Simultaneous Transmission with Multi-Panel, or STxMP, for multi-TRP uplink operation.

This allows a capable UE to transmit simultaneously using different antenna panels towards two Transmission/Reception Points, or TRPs.

There are several possibilities.

For single-DCI STxMP Spatial Division Multiplexing (SDM) PUSCH transmission, different spatial layers of one PUSCH are separately transmitted towards the two TRPs.

For single-DCI STxMP Single Frequency Network (SFN) PUSCH transmission, the same layers of one PUSCH are transmitted towards the two TRPs. This provides transmission diversity and can improve robustness.

For multi-DCI STxMP PUSCH+PUSCH transmission, two PUSCH transmissions are transmitted towards the two TRPs.

This distinction is worth making carefully. Separate PUSCH transmissions belong to the multi-DCI PUSCH+PUSCH case; the single-DCI SDM case divides different layers of one PUSCH between the two TRPs.

Release 18 therefore represents an interesting evolution of the MPUE concept.

Initially, multiple antenna panels were largely about giving a highly directional UE better angular coverage and allowing it to select an appropriate panel as its orientation and radio environment changed.

The evolution can roughly be thought of as:

Multiple antenna panels
→ Broader angular coverage
→ Panel selection and switching
→ Panel-aware measurements
→ UE-side beamforming
→ Improved mobility and spatial interference isolation
→ Simultaneous multi-panel transmission

There are, of course, trade-offs.

Supporting several simultaneously active antenna panels may require additional RF chains and baseband processing, increasing hardware complexity and power consumption. MPUE-A1 avoids some of this complexity by using one panel at a time, but sequential measurements can become outdated and panel switching can introduce delay.

More capable architectures can provide fresher measurements and support simultaneous panel operation, but potentially at a higher implementation and energy cost.

The network and UE therefore need to balance radio performance, mobility robustness, measurement freshness, hardware capability and power consumption.

MPUE is consequently much more interesting than simply saying that a 5G smartphone contains several antenna arrays.

At FR2 in particular, the physical orientation and capabilities of those antenna panels can influence how the UE sees the network, how reliably it moves between cells and how effectively it exploits directional beamforming.

With 5G-Advanced Release 18 STxMP, multiple UE panels can now also become part of the simultaneous uplink transmission strategy towards multiple TRPs.

As mobile networks make greater use of beamforming, multi-TRP operation and increasingly sophisticated MIMO techniques, understanding the antennas and RF capabilities inside the UE becomes an increasingly important part of understanding how the overall radio network performs.

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: , , , , , , , , , , , , , ,

Tuesday, 28 July 2026

Why Connectivity on Trains Is Still So Poor

Anyone who travels regularly by train will recognise the experience. The phone shows a mobile signal, sometimes even 5G, but webpages refuse to load, video calls freeze and messages remain stuck sending. Switching to the train’s Wi-Fi may not help either. The device connects to the access point, but there is little or no usable internet behind it.

Providing reliable connectivity on a moving train is much harder than providing coverage to a home, office or even a vehicle on a road. A railway combines weak and inconsistent outdoor coverage, a radio-unfriendly metal carriage, high-speed mobility, frequent handovers, difficult terrain and hundreds of passengers competing for limited capacity.

Recent measurement studies confirm how serious the problem remains.

An Ofcom-commissioned study measured mobile and on-board Wi-Fi performance across 50 journeys on 24 railway lines in Great Britain during February and March 2026. Its “Good Performance” threshold required at least 5 Mbit/s download, 1.5 Mbit/s upload and latency of no more than 50 milliseconds in the same test cycle.

The best-performing mobile network met that threshold only 42% of the time. The other three networks achieved between 17% and 21%. On-board Wi-Fi met the threshold just 1% of the time. Ofcom also found that latency was often the factor that caused a test to fail, even when download and upload speeds appeared adequate.

While this is a UK study, the problem is by no means unique to the UK. Ookla’s Q2 2025 comparison of train Wi-Fi across Europe and Asia found enormous differences between countries. Sweden achieved a median download speed of 64.58 Mbit/s, followed by Switzerland at 29.79 Mbit/s. At the other end of the scale, the UK achieved 1.09 Mbit/s and the Netherlands just 0.41 Mbit/s. The gap between the strongest and weakest markets was as much as 158 times.

The variation is important because it demonstrates that poor connectivity is not an unavoidable consequence of travelling by train. The engineering challenges are common, but the results depend heavily on how rail connectivity is planned, funded and operated.

Mobile networks are normally designed around where people live, work and spend most of their time. Sites are positioned and optimised to serve towns, cities, business areas and roads. Railway lines frequently pass through rural areas, cuttings, forests, valleys and other places where there may be little commercial demand beyond the passengers moving through.

A train may therefore spend much of its journey travelling along the edge of several mobile cells rather than through a strong, continuous coverage layer designed for the railway. A conventional mobile coverage map may show service in the surrounding area without accurately representing the signal available inside a carriage moving along the track.

Even where the outdoor signal is usable, it still needs to enter the train.

Modern rolling stock contains metal bodywork, foil-backed insulation and energy-efficient glazing. Low-emissivity windows often contain thin metallic coatings that reduce heat transfer but also reflect or absorb radio signals. The signal available outside the train can consequently be far stronger than the one reaching a passenger’s phone.

The uplink can be even more difficult. A mobile base station has relatively high transmit power, large antennas and sophisticated radio processing. A smartphone has limited power and a very small internal antenna. The phone must transmit back through the same coated windows and carriage structure that weakened the incoming signal.

This can explain why a passenger appears to have a reasonable signal or acceptable download speed but still struggles with video calls, file uploads, cloud applications and voice over IP.

Speed adds another layer of complexity. A phone or on-board communications gateway must continually measure nearby cells and hand the connection from one to another. At high speed, the device remains within each cell for less time and radio conditions can change significantly between a measurement and the handover itself.

Short interruptions may be almost invisible to a background download, but they can freeze a video call, interrupt a conversation or cause an application session to time out. Tunnels, deep cuttings, hills, buildings and vegetation can create additional sudden changes in signal quality.

Capacity is also shared. A single train can bring hundreds of connected devices into a mobile cell at almost the same moment. That cell may also serve a station, surrounding homes, businesses, road users and another train travelling in the opposite direction. During busy periods, this concentrated demand can increase latency, reduce throughput and create packet loss.

On-board Wi-Fi does not bypass all these challenges.

The passenger’s device connects to an access point inside the train, but the traffic must then pass through an on-board gateway and roof-mounted antennas before reaching an external network. Most train Wi-Fi therefore depends on the same public mobile coverage that passengers may already be struggling to use directly.

A strong Wi-Fi icon only confirms that the passenger has a good connection to the access point. It says nothing about the quality or capacity of the train-to-ground backhaul.

Legacy on-board equipment can make the problem worse. Ookla found that nearly two in five train Wi-Fi connections across the European markets studied still used Wi-Fi 4, while around 22% used the lower-capacity and more interference-prone 2.4 GHz band. Newer Wi-Fi generations and 5 GHz can improve performance within the carriage, but Ookla concluded that the external backhaul is generally the dominant bottleneck.

Simply adding 5G is not a complete answer either. 5G can provide more spectrum, greater capacity, improved latency and better radio efficiency. Ofcom found that 5G Standalone produced a substantial improvement where it was available, but its availability along the measured routes was inconsistent.

The railway still needs continuous outdoor coverage. The signal still needs to enter the train, capacity is still shared, handovers still need to work and the on-board equipment and backhaul must support the service. A 5G icon does not guarantee that every link in this chain is performing well.

There are several possible solutions, but none solves the whole problem independently.

The conventional mobile network can be improved by adding sites near railway coverage gaps, aiming antenna sectors along the track, using lower-frequency spectrum for reach and penetration, and adding capacity around busy stations and corridors.

Where conventional macro coverage is insufficient, dedicated trackside networks can provide closely spaced sites, directional antennas, engineered tunnel coverage and high-capacity fibre or microwave backhaul. This changes the planning objective from serving nearby towns and roads to serving the railway itself.

Trains can use high-performance roof-mounted antennas connected to intelligent on-board gateways. These systems can combine connections from multiple mobile operators and dynamically switch or bond links as conditions change. Genuine diversity is greatest where the operators use independent infrastructure rather than sharing the same underlying radio network.

Laser-treated, RF-permeable windows provide another approach. Fine patterns are removed from the metallic window coating, allowing more of the outdoor mobile signal to enter while retaining much of the window’s thermal performance. Tests cited by Ookla reported losses of approximately 20 to 30 dB from conventional coated windows, and Deutsche Bahn has announced a large-scale programme to treat tens of thousands of windows.

This is a passive solution that can benefit passengers using different networks and frequency bands. However, it only improves signal entry. It cannot create outdoor coverage or additional network capacity.

Active systems such as repeaters, distributed antenna systems and on-board small cells can bring mobile service directly into the carriage. These systems must be carefully engineered and coordinated with the mobile operators.

There is also an interesting interaction between repeaters and RF-permeable windows. A repeater requires sufficient isolation between its external donor antenna and the service antennas inside the train. If more of the amplified indoor signal escapes through treated windows and reaches the donor antenna, it can reduce isolation and create feedback, gain reduction or oscillation. Repeaters and treated windows can coexist, but they need to be designed and tested as one RF system.

For passenger Wi-Fi, the likely long-term architecture is a hybrid one. Modern Wi-Fi 6 or Wi-Fi 7 access points inside the carriage can connect to an intelligent gateway combining multiple cellular operators, dedicated trackside networks, station connectivity and low Earth orbit satellite backhaul.

LEO satellite systems such as Starlink and OneWeb are increasingly being considered as complementary links, particularly on rural and lightly served routes. They are not replacements for terrestrial connectivity because tunnels, deep cuttings, buildings and vegetation can obstruct the view of the sky. Rail-certified terminals must also meet demanding requirements for vibration, weather protection, power and electromagnetic compatibility. The most resilient approach is therefore to combine satellite and terrestrial links rather than depend entirely on either one.

Ultimately, there is no single fix for poor connectivity on trains. Reliable service requires the complete chain to work together: Railway-specific outdoor coverage + signal entry into the carriage + on-board distribution + sufficient backhaul + reliable mobility + capacity management + commercial coordination

Improving only one layer can leave another layer as the bottleneck. The train operator, rail infrastructure owner, mobile operators, rolling-stock manufacturer, connectivity provider, regulator and government all control different parts of the solution.

The video below explores these challenges and possible solutions in more detail.

Finally, for anyone working on passenger connectivity, train-to-ground communications or trackside infrastructure, TrainComms 2026 takes place in London on 18 and 19 November. The conference brings together train operators, rail infrastructure organisations, mobile and satellite connectivity providers, equipment vendors and other specialists to discuss on-board Wi-Fi, trackside wireless networks and emerging LEO satellite solutions. I will be attending again this year, so please do say hello if you are there. 

Related Posts: 

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