How is the mobile network standard evolving? What are the companies negotiating, and what have they agreed on?
13 3GPP meetings, from the plenaries to the working groups. What was settled, what was pushed to the next plenary, and which proposals quietly died — with the arguments that decided them.
This issue also draws on working-group meetings leading into the plenaries.
A 3 ms clock and a dedicated MAC-CE slot field for early channel reports are agreed; Huawei, ZTE, NTT DOCOMO and Sony lost on retransmissions.
A 14-company coalition led by Samsung, Qualcomm and NTT DOCOMO wants a 6G-anchored link to 5G; Nokia and Ericsson want none; CMCC, Orange and satellite operators want dual registration.
Per-beam reference points are agreed and the two-sequence PRACH design is narrowed over lone objections from ZTE and OPPO; other variants and signaling details stay open.
An email when the next report is out, plus an occasional update around the 3GPP plenaries and major events — new specifications, briefings and articles. No marketing.
At most eight emails a year. Unsubscribe in one click.
Datasets shared to train AI-based CSI compression will carry rank metadata and use a 32-bit float format for performance targets, which Huawei called excessive but did not block. Huawei and ZTE stopped Xiaomi and MediaTek on model-scaling disclosure, and Nokia's port-mapping request remains open.
Meetings in this article’s source material. Inclusion does not mean that every meeting approved every decision.
The topic concerns the specification of network-side data collection for AI/ML in beam management. This function allows the network to configure a device (UE) to log detailed Channel State Information (CSI) measurements, which can later be uploaded for training AI models to improve beam selection. A key part of this is defining the rules for the physical layer signals (CSI-RS) used for these measurements.
At the previous meeting (RAN1#125), companies agreed with the intention of a change proposal (TP) for network-side data collection but ran out of time for detailed discussion. At this meeting, the moderator (Samsung) put the same text forward again as 'Proposal 1'. It aims to add descriptions and constraints for CSI-RS measurements configured for L3 (higher layer) reporting via the new 'CSI-LoggedMeasurementConfig' into the physical layer specification (TS 38.214). The reason given is that similar rules already exist for L1 (physical layer) reporting configured by 'CSI-ReportConfig' and are also needed for consistency with the new L3 method.
Huawei and HiSilicon supported the proposal, arguing that because the new configuration refers to physical-layer resource settings, it requires corresponding RAN1 specification updates, unlike legacy Minimization of Drive Tests (MDT) which used higher-layer indexes. Google called three of the four changes unnecessary, including the requirement for the same number of ports, noting that only periodic and semi-persistent resources are allowed for data collection and the network cannot configure more than 64 of them. LG Electronics (LGE) was open to discussion but questioned if the change was essential.
The moderator drafted two versions of the proposal (original and a shortened one). According to the RAN1#126 chair's notes, the text proposal for TS 38.214 clause 5.1.6.1.2 was agreed and the corresponding Rel-19 CR (R1-2606879) was endorsed.
| Support the specification update | Question the necessity or scope of the changes |
|---|---|
| Huawei · HiSilicon2 companies | Google · LG Electronics2 companies |
The physical-layer specification now describes the constraints for CSI-RS measurements that the network configures for logged (L3) data collection, closing a gap between the new RRC configuration and TS 38.214.
For 'Option 3a-1', a different AI/ML method where the network sends a pre-trained AI model to the phone (not a raw dataset), there was a debate on whether to also send performance targets like NMSE or SGCS. Companies including vivo and ZTE supported it, arguing it would guide the phone's fine-tuning and prevent overfitting.
Companies including Huawei, Nokia, and OPPO objected. They argued that without a shared dataset, any performance target is meaningless because the phone cannot calculate the metric against a common reference. They stated performance depends on the data used for testing, which would differ between network and device.
The meeting moderator proposed to conclude that there is no consensus to provide performance targets for this option. The proposal to exclude them was endorsed.
| Support providing performance targets with pre-trained models | Oppose providing performance targets |
|---|---|
| vivo · ZTE · NTT DOCOMO · MediaTek · China Telecom5 companies | Huawei · Nokia · OPPO · LG Electronics · Xiaomi5 companies |
When networks send pre-trained AI models for CSI compression, they will not accompany them with performance guarantees. Phones receiving these models will have to validate their performance using their own locally collected data, which may lead to variability in how well the models work across different devices and environments.
Ambient IoT sensors will get their own timing index instead of borrowing 5G's frame numbering, and readers gained room for 1,008 unique IDs — Samsung, Apple and Qualcomm wanted a smaller range of 63 or 503 but lost to a twelve-company bloc led by Huawei and Xiaomi.
Meetings in this article’s source material. Inclusion does not mean that every meeting approved every decision.
For 'Data-Only Ambient' (DO-A) traffic, an A-IoT device must send a first uplink (Device-to-Reader or D2R) transmission to initiate communication. RAN1 has agreed to support two different methods for this first transmission.
The agreement down-selects 'Alt.2) Support both Option 1 (Msg1-like content) and Option 3 (DO-A scheduling request).' Option 1 uses a random access message similar to the 'Msg1' in 5G, containing a random ID. Option 3 uses a simpler scheduling request consisting of only a D2R preamble. The necessary information for both options is provided by the reader's periodic broadcast.
This was recorded as an agreement in the RAN1#126 chair's notes.
| Support both Option 1 and Option 3 | Support Option 1 only |
|---|---|
| Tejas · NEC · CATT · LGE · InterDigital · Lenovo · Qualcomm · CMCC · China Telecom · CEWiT10 companies | FUTUREWEI · Huawei & HiSilicon · Spreadtrum & UNISOC · vivo · Ericsson · Apple · Xiaomi · OPPO · Samsung · Fraunhofer · Quectel · ETRI12 companies |
Supporting both methods provides flexibility for different use cases and device complexities. Option 1 aligns with existing 5G random access procedures, while Option 3 offers a potentially simpler, lower-overhead alternative suitable for the most constrained A-IoT devices.
In A-IoT networks, a 'reader' is a network node that communicates with simple devices. To tell readers apart, each has a physical layer identifier. RAN1 has decided on the range for this 'reader ID'.
The agreement states: 'Regarding the physical layer ID as the reader ID-related information for reader identification/differentiation, the value range of the physical layer reader ID is 0~1007 (Option 3).' This was chosen over smaller options of 63 or 503 IDs.
This was recorded as an agreement in the RAN1#126 chair's notes.
| For 0-1007 range | For smaller ranges (63 or 503) |
|---|---|
| Futurewei · Huawei & HiSilicon · vivo · Xiaomi · Panasonic · ZTE & Sanechips · NEC · OPPO · China Telecom · LGE · DOCOMO · SPRD12 companies | Samsung · Apple · CMCC · Qualcomm4 companies |
A range of 1008 unique IDs (0-1007) provides significant scalability for dense A-IoT deployments, such as in large warehouses or smart cities, where many readers might be deployed in close proximity. This is a larger address space than what was initially proposed by some companies.
Future encryption with keys of 256 bits will sort 5G signaling and user data into five traffic categories, each tied to a standalone or combined protection mode applied Encrypt-then-MAC, and a concrete method for encrypting a phone's first registration messages was approved into the study report.
Meetings in this article’s source material. Inclusion does not mean that every meeting approved every decision.
The 3GPP study on supporting 256-bit encryption algorithms (FS_AEAD) is evaluating how to integrate stronger, 'quantum-resistant' cryptography into future mobile networks. A key part of this is determining which security mode—encryption only, integrity protection only, or a combined mode—should be used for different types of data flowing over the air interface.
At SA3#129, the working group responsible for security (SA3) approved an evaluation document that defines five categories of network traffic, each with its required protection scheme. The categories are: (A) NAS/AS messages needing integrity protection only, (B) NAS/AS (RRC) messages needing both encryption and integrity, (C) user plane data needing encryption only, (D) user plane data needing both encryption and integrity, and (E) user plane data needing integrity protection only.
The document explains that for traffic requiring only one type of protection (encryption-only or integrity-only), a 'standalone' mode of the 256-bit algorithm can be used. For traffic requiring both, a 'combined' mode (Authenticated Encryption with Associated Data, or AEAD) would be used. It states that 'the 256-bit support is always in the order Encrypt-then-MAC (EtM) to mitigate cryptographic vulnerabilities and ensure the interwork of two network nodes.'
The evaluation concludes that 'this grouping provides full coverage of security and reduces significantly the implementation and testing efforts.' An editor's note within the document states 'Evaluation is FFS' (For Further Study).
This categorization is a foundational step for introducing 256-bit algorithms. It maps existing 5G security requirements (like protecting NAS signaling or user data) to the new cryptographic modes, aiming to reuse the current 5G PDCP architecture where possible. This approach seeks to minimize changes for network and device vendors while upgrading security strength.
This topic is about securing the very first messages a phone sends to a 5G network, known as Non-Access Stratum (NAS) messages, which handle tasks like registration and service requests. The SA3 working group, responsible for security, approved the addition of an evaluation for a specific technical solution (labeled #23) to its study report.
The approved text describes 'Solution #23: Protection of initial NAS messages'. It addresses a key security issue by using 'combined mode algorithms'—which perform both encryption and integrity protection in one step—to protect these initial messages. The method works when the User Equipment (UE or phone) already has a valid 5G NAS security context from a previous interaction.
The technical description states: 'The entire NAS message is used as the IBS input parameter of the combined mode algorithms. All cleartext IEs in the NAS message are extracted and combined in sequence as the AAD input parameter of the combined mode algorithms’ input.' In simpler terms, it defines precisely which parts of the message are to be encrypted and which parts are to be used for authentication, ensuring the message's origin and integrity can be verified.
The evaluation section concludes: 'The solution addresses the key issue #2. The solution provides an option for protection of initial NAS messages using combined mode algorithms. How to set the IEs in the NAS message as AAD and IBS input for combined mode algorithms was given.'
This approval formally documents a complete technical method for securing initial network signaling in 5G. It provides a clear blueprint for how phone chipsets and network equipment should implement this security feature using combined algorithms, moving the specification closer to a final, standardized state. This adds a robust option for protecting sensitive registration and connection setup data from interception or tampering.
Ericsson and Samsung proposed that mobile networks skip a second consent check when apps request user data, arguing application-layer verification is enough — the study group deferred a decision on adopting this approach.
Meetings in this article’s source material. Inclusion does not mean that every meeting approved every decision.
A study within SA6, the working group responsible for application enablement, is examining how mobile networks should handle user consent when third-party applications request user data. The study, called FS_APCOT, aims to ensure the network respects user permissions before sharing data like location. A group of companies led by Ericsson and Samsung proposed adding an evaluation of one candidate solution, labeled 'solution #2', to the technical report.
The proposed text states that 'solution #2' identifies that 'there is no need for additional consent checks in the Core Network for the purposes of verifying the application user consent given for the user data sharing with the 3rd party applications.' It argues that consent checks performed at the application layer, as defined by this solution, are sufficient to meet regulatory requirements. The proposal clarifies that 'multiple consent checks' would mean two or more network entities, like the User Data Management (UDM) function, performing sequential checks for the single goal of sharing a user's public land mobile network (PLMN) data with an app.
The document also notes exceptions where application user consent is not required, such as when data must be shared by law (e.g., for life protection) or under a general subscription agreement for network optimization apps. The proposal states the solution has no major architecture impacts, except for a potential integration where the Common API Framework (CAPIF) Core Function would consume interfaces from the Application Consent Management Function.
If this proposal is eventually adopted, it would mean the core network (specifically the UDM) would not perform a separate, redundant consent verification when an application requests user data. This could simplify data-sharing procedures and reduce signaling, as consent validation would be handled once at the application layer. Operators would need to ensure their application-layer consent mechanisms are robust enough to satisfy all regulatory requirements on their own.
Vodafone pushed to manage 4G base stations entirely through the newer SBMA interface, covering both basic settings and bulk configuration changes. The broader approach was dropped, leaving 4G bulk configuration on the older IRP-based method.
Meetings in this article’s source material. Inclusion does not mean that every meeting approved every decision.
This document is part of the Study on Unified Management interface for Multi-RAT support (FS_UMMR_OAM), which explores how to manage 4G and 5G network equipment using a common, modern interface called SBMA (Service-Based Management Architecture). The study compares two approaches for handling configuration management (CM) of 4G base stations through these new interfaces.
Vodafone submitted a pseudo-CR (a proposed change to a draft study) evaluating two potential solutions for a specific use case. Solution #1 proposes a 'Limited SBMA-based CM scope,' supporting only basic configuration tasks for 4G nodes via SBMA interfaces, while relying on older, IRP-based methods for bulk configuration changes. Solution #2 proposes an 'Extended SBMA-based CM scope,' aiming to support both basic and bulk configuration management for 4G nodes entirely through SBMA interfaces, using a combination of services like Generic Provisioning and Plan Management.
The document states that 'Solution #2 is considered preferable, as it provides broader SBMA-based CM support for 4G nodes and provides a basis for a consistent SBMA-based representation.' It concludes that further study is needed to finalize the scope and assess the implications. The document's status is 'not pursued,' meaning the proposal was not adopted and work on it has stopped. The reason for this outcome is not stated in the source materials.
3GPP closes its post-quantum study and starts rewriting 5G security profilesRel-20
5G femtocells finally get a real specificationRel-19
Mobile networks are getting an energy label — and a knob to act on itRel-20
All briefings →| Status | Decision | Topic | Source |
|---|---|---|---|
| Decided | Phones can report support for multiple early-SRS configurations during random access | Radio: Bands, RF & NR Evolution | R1-2606465 |
| Decided | Early CSI reporting slot offset for idle phones will be set by a dedicated MAC-CE field | Radio: Bands, RF & NR Evolution | R1-2606467 |
| Deferred | No consensus on handling retransmissions for early MIMO triggers | Radio: Bands, RF & NR Evolution | R1-2606464 |
| Decided | Timeline for early CSI computation defined relative to slot boundary | Radio: Bands, RF & NR Evolution | R1-2606465 |
| Deferred | No agreement to enhance handling of MSG4 retransmissions for early triggering | Radio: Bands, RF & NR Evolution | R1-2606465 |
| Deferred | No consensus to enhance handling of MSG4 retransmissions for early triggering | Radio: Bands, RF & NR Evolution | R1-2606466 |
| Decided | Slot offset for early-CSI report PUSCH will be indicated directly in MAC-CE | Radio: Bands, RF & NR Evolution | R1-2606465 |
| Deferred | No extra handling for retransmissions when triggering early CSI from idle mode | Radio: Bands, RF & NR Evolution | R1-2606467 |
| Decided | Power-boosting feature for phones delayed to 6G, not part of 5G Advanced | Radio: Bands, RF & NR Evolution | RP-262213 |
| Deferred | Closed-loop power control proposed for early SRS and PUSCH after random access | Radio: Bands, RF & NR Evolution | R1-2606467 |
| Decided | Slot offset for early CSI reporting will be signaled in a dedicated MAC-CE field | Radio: Bands, RF & NR Evolution | R1-2606464 |
| Decided | No normative work on transmitter EVM relaxation for 5G-Advanced | Radio: Bands, RF & NR Evolution | RP-262172 |