3GPP Quarterly — June 2026

Ambient IoT devices will reuse LTE's interleaving method for better coverage

Ambient IoT refers to low-cost, battery-free devices that communicate by backscattering ambient radio signals. For the Device-to-Reader (D2R) uplink, a key question was how to interleave and collect bits after channel coding to improve robustness. Two alternatives were considered: Alt 1 reuses both the LTE sub-block interleaver and the LTE bit collection scheme; Alt 2 reuses only the LTE bit collection scheme, omitting the sub-block interleaver. RAN1, the working group responsible for the physical layer, agreed at its May meeting (RAN1#125) that 'For D2R interleaving and bit-collection, Alt 1 is supported.' The decision was based on contributions showing Alt 1 provides performance gains, especially for larger payloads, and allows reuse of existing LTE/NR infrastructure. The group noted that 'no further discussion is expected unless new issues are raised.'

No consensus on estimated broadcast size, only maximum limit provided to other groups

While the maximum payload size is fixed, companies disagreed on providing an estimated typical size for the broadcast information in their official reply to other working groups. Some companies, like Qualcomm and NTT Docomo, argued that stating only the 1000-bit maximum would mislead RAN2 and SA2 into thinking the entire capacity could be used. They pushed for wording indicating the actual broadcast information is 'expected to be much smaller than hundreds of bits'.

Other companies, including ZTE and Sanechips, wanted to provide a concrete example number like 'around 200 bits'. Vivo opposed using the vague term 'much smaller' as unclear and potentially misleading. The meeting moderator noted the controversial part was on the estimated size and that 'we can only provide the current state of affairs'.

The final, clean version of the reply that was agreed upon and sent to RAN2 does not contain any specific example number or the phrase 'much smaller'. It only confirms the 1000-bit maximum TBS and states that the design and size are under discussion. Therefore, no specific estimate was decided.

A group of companies proposed a reply on variable TBS for uplink SPS, but no decision was made

This topic addresses whether a phone can autonomously choose a smaller Transport Block Size (TBS) for its scheduled uplink transmission if the voice packet is small, similar to a mechanism in 4G LTE called EDT. This could save battery by transmitting for a shorter duration.

RAN2 (the working group responsible for protocols) asked RAN1 if such a mechanism is useful and feasible. The document summarizes company views: 7 companies (including Huawei, OPPO, Nokia, Apple) argued it is useful for power saving and feasible, while 6 companies (including ZTE, Ericsson, CATT) argued gains are marginal and it increases network blind decoding complexity.

The document states a 'Proposed conclusion 3.1-1b' from the meeting moderator: 'Introducing a multiple-TB-size mechanism... could only be beneficial for UE power saving... While it may be technically feasible... it implies blind decoding at the network side, and RAN1 is not able to finalize the design due to the lack of necessary information and... no available RAN1 TUs.' This was a proposal, not a decision. The document's status is 'noted', meaning it was taken note of but not approved as a group agreement. The reason for not finalizing the design is stated as a lack of information from other groups (SA4 on codec details) and no remaining time in the release schedule.

No decision on a single 'Solution 1A' variant for initial access, multiple options remain

A key technical challenge is the initial random access procedure (PRACH) when GNSS is unavailable. 'Solution 1A' proposes sending multiple PRACH preambles. Companies evaluated several sub-variants, but no single one was selected. The moderator's summary document, which compiles company views, was 'noted' by the meeting, meaning no final decision was made.

The document lists extensive and often conflicting observations from companies like Huawei, Ericsson, Samsung, and ZTE on the variants. For example, on 'Variant 1A-1' (two sequences with different roots), Huawei observed 'significant standardization effort is required' and that none align with the goal to avoid physical layer changes, while Ericsson observed 'Specification impact: Small' for one alternative. On 'Variant 1A-2' (using different PRACH formats), Thales and Tejas argued it demonstrates 'strong performance' and has 'minimal additional processing', while Huawei, ZTE, and others cited high complexity and specification impact.

The meeting did not adopt any company proposal to prioritize or drop a specific variant. The final recommendation to use 'Multiple PRACH transmissions' and 'Two PRACH sequences... with different roots' is a high-level direction, leaving the detailed implementation for the next phase.

SA5 evaluates multiple solutions for charging reliability in 5G roaming

This document reports on the evaluation of several proposed solutions for a key issue (Key issue #1.2) in 5G roaming charging reliability. The issue concerns how to handle charging sessions when a failure is detected between the visited network's charging function (V-CHF) and the home network's charging function (H-CHF) in an 'inter CHFs' scenario, which is a Local Breakout roaming setup.

The document, a proposed change request (pCR) to a study, lists eight solutions that address the issue. Solution #1.4 provides a method for the V-CHF to synchronously release or maintain its charging session with both the consumer network function (CTF) and the H-CHF to avoid long-term resource consumption. Solution #1.5 proposes that the V-CHF suspends quota management and stores charging information with a special marker to increase service continuity and avoid data loss, though it notes a lack of clarity on protocol layer cooperation.

Solution #1.6 states that the H-CHF should handle abnormal messages in roaming the same way as defined for non-roaming scenarios in the core charging specification (TS 32.290), which provides clear definition and eliminates ambiguity. Solution #1.7 covers handling charging data requests from an alternative V-CHF as valid, adding failure handling for scenarios not in the current specification, but also lacks clarity on protocol layer cooperation.

Solution #1.8 describes a method for handling charging information stored on the V-CHF to ensure data integrity and avoid loss from local storage overflow. Solutions #1.13 and #1.14 describe Service-Based Architecture (SBA) protocol-level failure handling for when either the H-CHF or V-CHF detects a failure in the other, identifying connection recovery methods but lacking clarity on subsequent application actions. An editor's note states that further evaluation is needed.

Study on roaming charging reliability evaluates multiple failure-handling methods

This document is part of a study on enhancing the reliability of charging for 5G roaming (FS_RoamRE_CH). The study examines how to handle failures in the charging system when a user is roaming, specifically in scenarios involving multiple Charging Function (CHF) nodes. A pCR (a proposed change to a draft study) from Huawei updates the evaluation of several proposed solutions for a specific problem (Key issue #1.2). This issue deals with how a visited network's CHF (V-CHF) should act when it detects a failure in its charging session with the home network's CHF (H-CHF).

The proposed update describes eight different technical solutions (numbered 1.4, 1.5, 1.6, 1.7, 1.8, 1.13, 1.14, and 1.18) that each address the same core problem. For each solution, it lists a benefit and a drawback. For example, Solution #1.4 proposes that the V-CHF releases or maintains its session with both the Charging Trigger Function (CTF) and the H-CHF upon failure; its benefit is session control, but its drawback is requiring a new notification to the CTF. Solution #1.5 proposes suspending quota management and marking data; its benefit is session continuity, but its drawback is that the visited operator's decision to continue may lead to unchargeable usage. Solution #1.6 proposes handling abnormal messages as per an existing standard clause; its benefit is no new handling logic, but its drawback is potential inconsistency between CHFs. The document was revised at this meeting, meaning the proposal was reworked and will continue to be discussed.

Decision on control channel parameters for on-demand SIB1 deferred pending RAN2 reply

A second issue regarding the on-demand SIB1 feature was discussed but not resolved. It concerns the configuration of 'controlResourceSetZero' and 'searchSpaceZero'—parameters that tell the phone where and when to listen for the control channel carrying the requested system information—after the phone receives the on-demand SIB1.

Samsung, citing an agreement from RAN2 (the working group responsible for protocols), stated that RAN2 had decided these fields are "always absent in SIB1" whether it is broadcast or provided on-demand. Based on this, Samsung proposed corresponding text for the physical layer specification (TS 38.213). However, the RAN1 chair guided that this topic would be discussed at the next RAN1 meeting. The meeting did not adopt Samsung's proposal, and the discussion was closed with the note 'this topic would be discussed in next RAN1 meeting.'

RAN1 awaits RAN2 decision on control channel configuration for on-demand SIB1

A second issue involves which configuration a phone should use for monitoring the control channel (PDCCH) after it successfully receives an on-demand SIB1. Specifically, it's unclear whether the phone should use the 'controlResourceSetZero' and 'searchSpaceZero' parameters from the received SIB1 or continue using the ones provided in a separate 'OD-SIB1-Config' message. This depends on whether those fields are present in the on-demand SIB1 itself, a decision that falls under RAN2 (protocols — the messages between handset and network).

Samsung, referencing an agreement already made in RAN2, proposed a text change for TS 38.213. The proposal states that if a specific condition related to beam timing (kSSB) is met, the phone should apply the parameters from 'OD-SIB1-Config' even after receiving the SIB1. The moderator's summary document notes this proposal but states that no agreement was reached on it in this RAN1 meeting. The topic is pending a formal reply from RAN2 to a prior inquiry.

Message bus recommended for streaming network management data

The study on Service Based Management Architecture (SBMA) phase 4 evaluated using a message bus for streaming network management data, like performance measurements. A message bus is a communication system that allows applications (producers) to publish data to categorized channels (topics), from which other applications (consumers) can retrieve it. The evaluation concluded three proposed solutions are technically feasible and align with SBMA architectural principles.

Solution #1, for the data transmission aspect, proposes introducing new 'message bus data reporting' and 'message bus data retrieval' management services (MnS). These would support reporting and retrieval using pre-known topic names and broker endpoints, and would work with the Kafka protocol and other industry message bus solutions.

Solution #2, for data discovery, proposes enhancing an existing standard (TS 28.622) by adding two new allowed values to a parameter. This would let a management data consumer discover that a producer supports reporting data via a message bus stream.

Solution #3, for the data request aspect, proposes enhancing the 'reportingCtrl' structure in TS 28.622 by adding a new choice element for message bus location. This would support using the message bus as a reporting method in requests, ensuring both producer and consumer get the necessary location information like topic name and broker endpoint.

The document states: "The use case, requirements and solutions are recommended for normative work."

SA5 approves a delta specification as the preferred solution for managing 4G nodes in the 5G service-based architecture

The study focuses on enabling unified management of 4G and 5G network elements under the Service-Based Management Architecture (SBMA), which is the modern framework for 5G network management. Currently, 5G Network Resource Models (NRMs) are defined using YANG and OpenAPI for SBMA, while 4G NRMs are only defined in the older XML-based IRP framework, creating a gap that prevents consistent multi-generation management.

The approved document evaluates four potential solutions to bridge this gap. Solution #1 proposes a new standalone specification for SBMA-based management of 4G nodes. Solution #2 suggests extending existing 5G management specifications to include 4G support. Solution #3 involves extending the legacy IRP specifications themselves with SBMA representations. Solution #4 recommends creating a new 'delta' specification that references and builds upon the existing 5G SBMA framework (specifically 3GPP TS 28.541) to add only the missing elements for 4G.

The evaluation states: 'solutions based on extending existing specifications (Solutions #2 and #3) raise significant concerns... In contrast, solutions based on introducing a new specification (Solutions #1 and #4) provide a clearer separation of concerns... Among these options, the introduction of a delta specification aligned with the existing SBMA framework (Solution #4) offers a more modular and maintainable approach.'

Enhanced Management Services Exposure study adds authorization solution

The study on Enhanced Exposure of Management Services (FS_EnExpo) is defining how mobile network management functions can be safely opened to external applications and systems. This involves creating secure APIs (Application Programming Interfaces) that allow authorized external consumers to request network data or actions, similar to how cloud platforms expose services. At SA5#166, a proposed change (pCR) to the technical report TR 28.888 was approved, adding a detailed solution for a key authorization use case.

The approved addition describes 'Use case #1: Authorization of the service API invocation request from the external MnS (Management Service) consumer using CAPIF'. CAPIF (Common API Framework) is the 3GPP framework for securely exposing northbound APIs. The solution details the step-by-step procedure for an external consumer to invoke a management service API. It starts with the consumer authenticating and obtaining an OAuth 2.0 access token from a central function (CCF). The consumer then sends the service request along with this token to the exposure function (AEF). The AEF validates the token's signature and checks that the requested action is within the granted permissions ('scope').

The document further details one potential implementation where the AEF itself acts as an internal consumer within the operator's management system. To fulfill the external request, the AEF must map the external API call to an internal management service call, authenticate itself to the internal system, obtain its own internal access token, and forward the request to the appropriate management service producer. The evaluation notes this solution requires no extensions to the existing 3GPP management system, as the AEF would use the same procedures as any other internal component.

Study on application user consent finds core network checks redundant for some data sharing

This document is part of a study on Application User Consent (FS_APCOT), which explores how to manage a user's permission for mobile apps to access their network data. A group of companies, led by Ericsson and Samsung, proposed adding an evaluation of one specific technical solution (labeled 'solution #2') to the study report. The proposal states that solution #2 addresses a key issue about clarifying the end-to-end process for user consent.

The proposed text for the study report evaluates solution #2. It concludes that for certain types of data sharing with applications—specifically for network capability exposure ('NW_CAP_EXPOSURE') and location services to edge applications ('EDGEAPP_UE_LOCATION')—no additional consent checks are needed in the core network (like in the UDM, the Unified Data Management function). The reasoning is that the consent checks performed by the application-focused solution are sufficient, and requiring duplicate checks in the core network would be inefficient. The proposal notes this recommendation needs coordination with SA3, the working group responsible for security and privacy. It also states the solution has no major architecture impacts, except for a potential optional integration where a CAPIF Core Function would use the new consent management interfaces.

Post-quantum SUCI decryption performance measured, symmetric scheme fastest but complex

This document provides performance figures for different methods of decrypting a SUCI (Subscription Concealed Identifier), a protected version of a user's permanent identifier sent during initial network attachment. The figures are intended for inclusion in an annex of the technical report TR 33.703, 'Study on Transitioning to Post-Quantum Cryptography in 3GPP'.

The evaluation compares the current standard method, called Profile-A (ECIES), against four new groups of post-quantum cryptography (PQC) proposals. Measurements were taken on the network side (Home Network) using the ML-KEM-768 algorithm, which corresponds to NIST security level 3. The results show:

Group-A (Pure PQC) performs nearly identically to the current ECIES method, with decrypt-only latency even slightly lower (72 µs vs. 150 µs).

Group-B (Hybrid PQC) combines classical and post-quantum cryptography, providing security if either remains unbroken, but doubles de-conceal latency (~210 µs vs. 154 µs) and halves throughput.

Group-C (Nested Hybrid) performs operations sequentially, resulting in the highest latency (~321 µs) and lowest throughput (~3100 ops/s) among the asymmetric schemes.

Group-D (Symmetric Scheme) uses only symmetric cryptography (like AES), resulting in the best performance: ~30 µs latency, ~264,000 operations per second throughput, and a payload size similar to the current method. However, the document notes this approach 'introduces key management complexity, requiring secure storage and synchronization of subscriber-specific master keys between the UE (USIM) and HN.'

The document, a proposed change (pCR) from Nokia, was 'noted' by the meeting. This means the proposal was presented for information but not formally approved or rejected at this session.

Study on protecting initial NAS messages with combined-mode algorithms moves forward

This document, presented by Huawei and HiSilicon, proposes to evaluate a specific technical solution (labeled #23) within the broader 'Study on supporting AEAD algorithms' (FS_AEAD). The study explores using Authenticated Encryption with Associated Data (AEAD) algorithms, also called combined-mode algorithms, which perform encryption and integrity protection in a single step. Solution #23 specifically addresses the protection of initial Non-Access Stratum (NAS) messages—the first signaling messages a phone sends to the core network when connecting or registering—using these combined-mode algorithms.

The proposed technical details describe how the entire NAS message would be used as input for encryption (IBS), while its plaintext information elements (IEs) would be used as the associated data (AAD) for integrity. The output would be a protected NAS message container containing the ciphertext and a Message Authentication Code (MAC). The document states, 'The solution addresses the key issue #2. The solution provides an option for protection of initial NAS messages using combined mode algorithms.'

The document's status is 'not treated', meaning the proposal was not discussed or voted on at this SA3#128 meeting. No reason for this is recorded in the provided materials.

Work plan for evaluating QUIC-based video streaming in 5G gets revised schedule

The study 'Evaluation of QUIC-based protocols for on-demand and live video services' (FS_QStream_MED) aims to assess new streaming technologies like DASH over HTTP/3 and MoQ against the current 5G Media Streaming baseline (DASH over HTTP/1.1). Its goal is to see if these QUIC-based protocols offer better Quality of Experience (QoE) in terms of startup time, rebuffering, and streaming quality under real 5G network conditions, and to identify any changes needed to the 5G media architecture.

A document from Xiaomi proposed a detailed work plan for this study. The plan schedules tasks across multiple 3GPP meetings through early 2027, including defining use cases, selecting metrics, designing a test framework, running network simulations, and finally analyzing results to decide if normative work is needed. The document's status is 'revised', indicating it was reworked during the meeting. The meeting did not record a reason for the revision.