3GPP Quarterly — March 2026

AI/ML CSI compression: pairing ID and performance targets extended to model-parameter exchange

This topic concerns AI/ML-based Channel State Information (CSI) compression, where a phone (UE) uses a neural network to compress detailed channel measurements into a smaller feedback report. For 'inter-vendor training collaboration,' different manufacturers' phones and networks must be able to exchange training data or AI model parameters. The meeting discussed extending rules agreed for one method (Option 4-1, dataset exchange) to another method (Option 3a-1, model-parameter exchange).

A coalition led by Apple, as moderator, proposed extending three previous agreements to Option 3a-1. The first agreement states that a single 'pairing ID' should be exchanged along with a dataset or a model parameter set, with one ID assigned to each. The second agreement states that if the quantization codebook for CSI feedback is not fixed by the standard, it should be exchanged along with the dataset or model parameters. The third agreement states that both average SGCS and average NMSE should be supported as performance targets in the exchanged dataset or model parameter set.

Multiple companies (vivo, Lenovo, NTT DOCOMO, OPPO, Spreadtrum, China Telecom, CMCC, ZTE, CATT, NEC, Fujitsu, TCL, Panasonic, Xiaomi, InterDigital, Sharp) expressed support or conditional support for extending some or all agreements. However, Huawei and HiSilicon did not support the extension, arguing that decisions on associating model parameters with a pairing ID and on quantization codebooks are up to RAN4, and that a performance target is unnecessary if no dataset is exchanged. Ericsson and Toyota also stated it was premature to incorporate Option 3a-1 into existing agreements, citing unresolved questions that require RAN4 input.

The meeting did not reach a decision on this proposal. The document's status is 'noted,' meaning it was taken for information only.

The RAN1#124 meeting record records a partial agreement on this point: "For Direction A Option 3a-1, support exchange of single pairing ID along with model parameter exchange corresponding to the standardized reference encoder model structure."

RAN1 to decide between scalar and vector quantization for AI-based CSI compression

The working group RAN1, responsible for the physical layer, is defining how AI/ML models will compress and report Channel State Information (CSI) in 5G-Advanced. A key technical choice is the quantization method: Scalar Quantization (SQ) processes each value in the AI model's latent output independently, while Vector Quantization (VQ) processes groups of values together, which can be more efficient but more complex. The meeting noted proposals from multiple companies but did not reach a final decision.

Companies are divided on the preferred method. Samsung, Spreadtrum, Ofinno, China Telecom, Lenovo, and Nokia propose supporting only SQ, citing its lower complexity and arguing VQ offers limited gain. Apple and ETRI propose supporting only VQ, with Apple specifying parameters like a segment length (L) of 4 and 8 bits per segment (Q). A large group, including Huawei, Fujitsu, NEC, Fraunhofer, and MediaTek, proposes supporting both SQ and VQ to give implementers flexibility. Futurewei presented simulation data showing VQ outperforming SQ by an average of ~4.05% in a metric called SGCS, and a VQ method using a lookup table (VQ-LUT) could save ~84% overhead while matching SQ/VQ performance.

Regarding the standardized codebook for quantization, there is also no agreement. Proposals range from using only a network-defined codebook (OPPO, Xiaomi), only a 3GPP-standardized codebook (Spreadtrum, ZTE, Samsung, Lenovo), to supporting both (Huawei, Fujitsu, CMCC). Samsung provided example codebooks for 2-bit uniform quantization over ranges [-1,1] and [0,1]. The reason for the lack of decision is not recorded in the meeting materials.

Ambient IoT Phase 2 scope for outdoor active devices remains under discussion

The meeting discussed the scope for the Release 20 work item (WI) on Ambient IoT, a 3GPP technology for ultra-low complexity, energy-harvesting devices. The key debate centered on which types of 'active' devices (which transmit using harvested energy) and what maximum transmit power should be standardized for outdoor scenarios, to ensure clear differentiation from existing Low-Power Wide-Area (LPWA) technologies like NB-IoT.

A coalition led by Huawei, Samsung, ZTE, LG, and others proposed supporting 'Device C' with a maximum transmit power of 5 dBm for outdoor scenarios (topology D4T1). They argued this power level is necessary for coverage when devices are co-sited with existing macro base stations and that differentiation from NB-IoT is clear due to fundamental differences in operation, complexity, and hardware. Ericsson and Nokia argued that 5 dBm is too high and risks overlapping with LPWA, proposing 0 dBm instead or leaving the final value for RAN4, the working group responsible for radio performance and conformance testing, to decide.

A second debate concerned whether to also standardize a lower-power 'Device 2b' (with -10 dBm max power) for indoor smartphone-based reading scenarios (topology D2T2). Proponents like OPPO argued it is necessary for practical indoor use. Multiple companies, including Huawei, ZTE, LG, and CMCC, preferred 'Option 2' if Device 2b is supported: using the same air interface design as Device C, differing only in maximum power, to minimize specification workload. OPPO and others preferred 'Option 1', which would allow for minimized design differences to account for different hardware capabilities.

The moderator's summary document, which had a status of 'revised', presented competing proposals (1v1 and 1v2) encapsulating these options. The meeting did not reach a final decision on these device and power scope issues.

Ambient IoT study confirms two open-loop power control methods are feasible, but no consensus on which to prefer

The study on Ambient IoT for outdoor active devices is examining how devices (Device 2b and Device C) should control their transmit power when sending data to a reader (D2R). Two open-loop methods were studied. Option 1: The device calculates its transmit power based on measured pathloss, using a formula and parameters from the reader. Option 2: The device measures the signal strength (RSRP) from the reader and selects a corresponding transmit power from a configured range.

The document summarizes company views. For Option 1, FUTUREWEI, Xiaomi, LGE, DOCOMO, TCL, and vivo reported it is feasible. For Option 2, the same companies reported it is feasible, while Samsung reported it is not feasible. On preference, a group of companies including Xiaomi, ZTE, LGE, ETRI, ASUSTeK, Quectel, TCL, and vivo prefer Option 1. Another group including Panasonic, Apple, Qualcomm, KT, and Fraunhofer prefer Option 2.

The document contains a proposal (Proposal 3.3.2a-1) to capture these feasibility findings and company observations in the technical report TR 38.769. The meeting did not adopt this proposal; the document's status is 'noted', meaning the proposal was presented but no decision was made.

The RAN1#124 meeting record records a partial agreement on this point: "On the two open‑loop Tx power control methods for D2R, capture the following in TR 38.769."

Debate continues on validation rules for random access during on-demand SIB1

A random access occasion (RO) is the specific time-frequency resource a phone uses to send its initial access request. For the on-demand SIB1 feature, the standard needs to define how the phone validates that an RO is usable on the target cell. Sharp proposed adding validation rules specifically for 'neighbour cells' configured for on-demand SIB1, following the same logic used for another feature called LTM. However, Huawei, Qualcomm, Apple, Ofinno, and DENSO argued the text should be written for a generic 'cell' and include the on-demand SIB1 configuration among other possible sources. The two conflicting proposals were presented, but no agreement was reached during this session.

The reason for the disagreement is not recorded in the documents. The moderator noted both versions would be checked during the online session to see if a compromise could be found.

Clarification on control channel configuration for on-demand SIB1 deferred

After a UE successfully requests SIB1 on-demand and receives it, it needs to know which control channel configuration to use for subsequent procedures like receiving paging or other system information. The source of the parameters 'searchSpaceZero' and 'controlResourceSetZero' in this scenario was unclear.

Samsung proposed text to clarify that if these parameters are not provided in the regular SIB1 and certain conditions are met, the UE should use the values provided in the on-demand SIB1 configuration. Huawei disagreed with part of the proposal, arguing that once the UE receives the on-demand SIB1, it should not revert to checking other configurations. A modified proposal (FL Proposal 4-1-2) was drafted but there was not enough time to discuss it during the online session. The moderator noted that the proponents should discuss further offline and revisit the issue at the next meeting if needed.

Proposal to address lawful interception gaps for IMS Data Channels

The IP Multimedia Subsystem (IMS) Data Channel is a feature that allows devices to exchange application data (like file transfers or gaming data) directly within a voice or video call setup. Its security is based on DTLS, the same protocol that secures web traffic. A group of companies, led by Ericsson, raised a concern that current specifications have a gap for Lawful Interception (LI), which is the legally mandated capability for networks to provide access to communications for authorities.

The problem occurs when a user under surveillance (the 'target') is in a network that does not fully support IMS Data Channels, or where the target's subscription does not trigger the necessary network functions. In these cases, the target can still use Data Channel services provided by the other party's network, but the target's own network has no node that can decrypt the media content for interception, as required by law.

Ericsson's document, S3-260612, analyzes specific deployment cases. It identifies networks with different support levels: Level 0 (no support), Level 1 (core network supports it but lacks the dedicated Data Channel Signalling Function and Media Function), and Level 2 (full support with all functions deployed). The LI gap is prominent for targets in Level 1 networks or in Level 2 networks where their subscription does not invoke the intercept-capable functions.

To solve this, Ericsson proposed modifying the standards. The solution is to enable 'split DTLS proxy mode' in existing IMS nodes—specifically the IMS Access Gateway (IMS-AGW) or Transition Gateway (TrGW). This would allow these nodes to intercept and decrypt the Data Channel media traffic within the target's home network, fulfilling LI requirements for the identified problematic cases.

The document explicitly states: 'It is proposed to discuss the topic...' and 'It is proposed to agree the CR in [6].' The meeting took note of the document but did not make a decision on the proposal. Therefore, the matter was deferred for future discussion.

Post-quantum cryptography proposal for 5G authentication gets technical evaluation

The 3GPP SA3 security working group is studying how to protect 5G and future networks against attacks from quantum computers, which could break today's encryption. This work is called the 'Study on Transitioning to Post Quantum Cryptography' (FS_CryptoPQC).

A group of companies led by Thales and Orange submitted an evaluation of one proposed solution, labeled 'Solution #16'. This solution aims to secure the initial connection between a phone (UE) and the home network (HN) during authentication.

The evaluation states: 'New PQC algorithms and related profiles need to be supported by the UE and Network.' It describes a method where both the phone and the network generate temporary encryption keys. A key part of the proposal is using a 'freshness parameter i.e., timestamp' to prevent replay attacks, where an attacker re-sends old, intercepted messages.

However, the evaluators note critical gaps: 'The freshness parameter aims at addressing a problem (replay attacks) which is not properly identified nor included in the scope of the present document. Additionally, the solution does not describe the behavior of the HN regarding the verification of the freshness parameter, and the procedure in case that the HN considers that the value of the freshness parameter is too old.'

The document contains editor's notes stating that how the freshness parameter protects against certain advanced attacks 'is FFS' (For Further Study) and that 'Further evaluation to be added.' The document was 'not treated' at this meeting, meaning no decision was made on it.

5G hardware inventory management will reuse existing 4G models

This topic concerns how network operators can manage and track the physical hardware (like base station units and cards) in their 5G networks using a service-based architecture. A study within SA5 (network management and charging) evaluated a proposal for this 'inventory management'.

The meeting approved a proposed change (pCR) to a technical report, concluding that the existing information models for hardware inventory from 4G/LTE standards are suitable for reuse in 5G. The models, originally defined for communication between an IRPAgent and IRPManager, describe hardware components like 'InventoryUnit' and 'InventoryUnitHw' in a generic way that is not tied to a specific radio technology.

The evaluation stated: 'The solution aims to address REQSBMAIM1 and REQSBMAIM2... by enabling MnS based inventory management for 5G systems.' It further concluded that 'the proposed solution is technically feasible, aligns with SBMA architectural principles, and minimizes specification effort by reusing existing models.'

Study on unified management for 4G and 5G nodes concludes with a proposed solution

The study on Unified Management interface for Multi-RAT support (FS_UMMR_OAM) aims to define a common way to manage both 4G and 5G base stations from a single interface, simplifying network operations. A pCR (a proposed change to a draft study) from Vodafone evaluated four potential technical solutions for achieving this.

The document states all solutions meet the core requirements by introducing the missing SBMA-based management support. SBMA (Service-Based Management Architecture) is the modern framework for managing 5G networks. The main differences were in how they organized the technical specifications and reused existing SBMA definitions.

Vodafone's analysis found that solutions extending existing 5G specifications would increase complexity and reduce long-term maintainability. Solutions creating a completely new specification risked duplicating concepts. The proposed preferred solution (Solution #4) was to create a 'delta specification' that reuses the core SBMA definitions from the existing 5G management standard (3GPP TS 28.541) and adds only the new elements needed for 4G support. This was argued to minimize duplication and preserve architectural clarity.

The document's status is 'not pursued', and the meeting did not record a reason for this. No decision was made on this proposal at SA5#165.

Study on application user consent identifies gaps in current 5G mechanisms

This topic concerns how mobile applications obtain and verify user consent when accessing personal data through the 5G network. The 3GPP study, called FS_APCOT, examines whether current 5G standards adequately handle this consent, especially for new types of applications.

A document from Ericsson, which is a pCR (a proposed change to a draft study), evaluates one of the proposed solutions (Solution #2) for a key issue (KI#2) about end-to-end user consent. The document states: 'Solution#2 addresses KI#2 on the E2E clarifications on user consent for applications.'

The evaluation concludes that Solution #2 'identifies overlaps and gaps in an E2E solution for application user consent. It identifies issues with the existing solutions for application user consent which do not address current application consent requirements.'

For network specifications managed by SA6 (the working group for application enablement), the proposed impacts are on 3GPP TS 23.558 and TS 23.222. The evaluation also states: 'the solution has identified that there is no need for an additional consent checks in the CN (Core Network) for purposes of verifying the application user consent given for the user data sharing with the application.' Impacts on other specifications, like those under SA3 (security) and CT4 (core network protocols), would require coordination between working groups.

The document's status is 'revised', meaning it was sent back for further work. No record of a vote or final decision on this specific proposal is included in the provided materials.

Work plan for evaluating QUIC-based video streaming in 5G networks finalized

The 3GPP SA4 working group, responsible for codecs and media delivery, has agreed on a detailed work plan for a study on evaluating QUIC-based protocols for video services. The study, called FS_QStream_MED, will examine how newer transport protocols like QUIC (the basis for HTTP/3) perform for on-demand and live video streaming compared to current 5G media streaming standards.

The work plan outlines six main objectives. First, it will identify specific video streaming scenarios and their traffic patterns. Second, it will catalog existing and emerging streaming technologies, such as DASH over HTTP/3 and MoQ. Third, it will define an evaluation framework, selecting key Quality of Experience (QoE) metrics like startup time and rebuffering, and study the potential impact of QUIC on current 5G media delivery architecture and content delivery networks (CDNs). Fourth, it will design a test framework and run simulations using mobile network traces to evaluate the selected technologies. Fifth, if benefits are found, the study will explore how to integrate these technologies into 5G standards and identify any gaps. Sixth, it will communicate progress with other standards bodies like the IETF.

The detailed timeline schedules work to begin immediately on selecting use cases and designing the test framework. The final study report, Technical Report (TR) 26.835, is planned for approval in March 2027.