You are reading a past issue. Read the current issue →
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.
Nokia, Ericsson, Samsung, InterDigital, OPPO and Apple got DFT-s-OFDM deprioritized for general downlink use; LG, CATT, Google and ZTE keep it alive only for satellite scenarios.
Aperiodic tracking signals and explicit SCell activation won broad backing; a 1/8 reference-signal density and who schedules the uplink report are still fought over.
3GPP kept only two orthogonal cover code options for satellite uplinks and finalized power ramping for IoT devices, while a fight over timing-advance rules stalled.
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.
Standardizing cross-vendor AI training for CSI compression narrowed to a data-format fight: 18 companies including Apple, Huawei and Nokia beat 10 including Ericsson and Samsung, picking pre-quantization floating-point vectors over bit sequences. Meanwhile RAN dropped normative work on phone-side AI data collection entirely, pushing it to 6G.
Meetings in this article’s source material. Inclusion does not mean that every meeting approved every decision.
This topic concerns how a phone (UE) should collect and send training data to a server to improve AI models that run on the device. The main debate was between a Control Plane (CP) solution, which uses signaling messages, and a User Plane (UP) solution, which uses the regular data channel. A CP-based solution (Option 3) was already studied in the previous release.
Company opinions were split on how to handle the checkpoint for this work. Vivo and Xiaomi proposed removing the checkpoint. Spreadtrum/UNISOC and KT Corp. proposed postponing it to the next plenary (RAN#111).
There was also a split on the preferred technical solution. Samsung, CATT/CBN/China Broadnet, and Huawei (as an alternative) supported specifying the CP-based Option 3. Nokia supported the UP-based Option 2. Huawei's primary preference was for no standardization (Option 1a). ZTE explicitly did not support Option 2. OPPO proposed no normative work from RAN.
Offline discussions revealed deeper disagreements. Companies like MediaTek, Qualcomm, Nokia, TIM, and Docomo argued for continuing with or moving to the UP solution (Option 2). Others, like Apple and Vodafone, were concerned about parallel work in 5G and 6G or scalability issues with the CP solution.
The document concludes with a 'way forward agreement' proposal from the discussion moderator: 'To avoid parallel work in 5G and 6G, no normative work in Rel-20 for UE side data collection. Focus data collection framework work on 6G, and use the lesson learned across all the WGs to design something for 6G.' The document's status is 'noted', meaning this proposal was presented but not formally approved as a decision by the plenary meeting.
| No normative work in Rel-20, push framework to 6G | Support normative work for CP or UP solution in Rel-20 |
|---|---|
| OPPO · Apple · Vodafone · vivo · Xiaomi · KT Corp.6 companies | Samsung · Nokia · CATT, CBN, China Broadnet · MediaTek · Qualcomm · TIM · Docomo7 companies |
The RAN plenary did not make a final decision. The strong proposal from the moderator indicates a significant shift: instead of standardizing a method for phones to report AI training data in 5G-Advanced (Release 20), the work would be deferred entirely to the 6G timeframe. The rationale is to avoid duplicative effort and to design a more holistic framework for 6G, learning from the ongoing studies in the system architecture groups. This means 5G-Advanced will likely rely on non-standardized, implementation-specific methods for this function.
This topic defines the format of the 'CSI feedback' within the training dataset for AI-based compression. The choice is between exchanging the latent message (a high-dimensional vector of floating-point numbers) before it is quantized into bits, or exchanging the final binary bit sequence after quantization.
The meeting decided to support 'Option 1: The exchanged CSI feedback is the latent message before quantization represented using floating format, e.g., float 32.' This decision was based on a summary of support from 18 companies (including Apple, Huawei, Nokia, Qualcomm, Xiaomi) versus 10 companies supporting Option 2 (including Ericsson, Samsung, ZTE, OPPO). The summary cited a 5G Advanced study (TR 38.843) which showed that sharing the latent message before quantization generally resulted in less performance degradation for the AI model, especially when the network and phone use different AI model architectures. It was noted that the binary sequence can still be generated from the latent message if needed.
| Support for latent message before quantization (Option 1) | Support for binary bit sequence after quantization (Option 2) |
|---|---|
| Apple · Huawei · Nokia · Qualcomm · Xiaomi · CATT · Lenovo · MediaTek8 companies | Ericsson · Samsung · ZTE · OPPO · CMCC5 companies |
Networks will provide more detailed, high-precision data (floating-point vectors) for phones to train their AI compression models. This is expected to lead to better-performing AI models compared to training on the quantized bits, potentially improving the accuracy of the compressed channel information the phone sends back. It increases dataset size compared to bits but optimizes for performance, as overhead is less critical for non-over-the-air dataset delivery.
Ambient IoT's outdoor design is still being argued over, not settled: device frequency search, reader identification and broadcast timing all stayed as proposals rather than agreements. Separately, the architecture study is running out of time, with Huawei and OPPO pushing conclusions on five open issues before features get dropped entirely.
Meetings in this article’s source material. Inclusion does not mean that every meeting approved every decision.
For allocating resources for a device's first 'Data-Only Autonomous' (DO-A) transmission, the feature lead moderator assessed that a majority view from company submissions supports periodic allocation. The proposal states: 'For resource allocation method for the first D2R transmission for DO-A for Device 2b and for Device C, Option 1 (Periodic D2R resource allocation) is feasible and necessary.' An alternative proposal is also noted, suggesting both periodic and aperiodic allocation are feasible and that down-selection should not happen in the current study phase. The document's status is 'noted', meaning no final decision was made at this meeting.
| For periodic resource allocation (Option 1) | For studying both periodic and aperiodic allocation |
|---|---|
| Companies forming the majority view (not individually named)1 company | Companies supporting the alternative proposal (not individually named)1 company |
This reflects a push to pre-allocate regular time/frequency slots for Ambient IoT devices to transmit, which simplifies device operation and saves power. The alternative view suggests keeping options open for event-driven, on-demand resource allocation. The conflict means the final standard could support one or both methods.
A group of companies, led by the feature lead moderator, proposed that 'Periodic transmission of broadcast information is necessary for Device 2b and for Device C for outdoor scenarios.' Broadcast information carries essential network configuration details for devices. The proposal includes a note 'FFS (in SI or WI): whether the transmission of broadcast information is strictly periodic at reader', meaning 'For Further Study' to decide if the periodicity must be rigid or can have some flexibility. The document's status is 'noted', indicating the meeting took note of the proposal but did not make a final agreement.
| For periodic broadcast transmission | Specific concerns not captured in document |
|---|---|
| Moderator (LG Electronics) as feature lead, presenting a consolidated view1 company | Companies with concerns about 'strict' periodicity (not named in document)1 company |
If adopted in future work, this would mean outdoor Ambient IoT devices can rely on regularly scheduled broadcasts to receive network information, simplifying their design and saving power compared to needing to trigger an aperiodic transmission. The unresolved question about 'strictly' periodic transmission leaves room for implementation flexibility.
Huawei and HiSilicon studied how 5G networks should treat unmarked packets — like RTCP control traffic using up to 5% of bandwidth, or audio taking 10-20% in a video call — that share a data flow with QoS-marked PDU Sets. Both proposals were sent back for further work, leaving the QoS rules undecided.
Meetings in this article’s source material. Inclusion does not mean that every meeting approved every decision.
This document is part of a study on 5G Real-time Transport Protocol configurations. It analyzes scenarios where 'unmarked' or 'lone' Protocol Data Units (PDUs) — individual data packets not belonging to a marked group called a PDU Set — are mixed with marked PDU Sets within the same service data flow. In 5G, PDU Sets allow the network to apply specific Quality of Service (QoS) parameters (like delay and error rate) to a group of packets that belong together, such as a video frame. The analysis examines what happens when unmarked packets, like audio packets or control messages, share the same data flow.
The document, a proposed change (CR) to technical report TR 26.822, was submitted by Huawei and Hisilicon. It was revised during the meeting, meaning it was sent back for further work; no final decision was made on its content.
The analysis identifies several use cases where unmarked PDUs coexist with marked PDU Sets: 1) RTP and RTCP control packets multiplexed, where RTCP uses up to 5% of bandwidth and is critical; 2) multiplexed RTP video and audio in a call, where audio uses 10-20% of bandwidth and is important for quality; 3) unmarked video streams; 4) STUN packets for network address traversal; 5) retransmission streams; and 6) AL-FEC repair streams.
It concludes: 'QoS requirements for lone PDUs and marked PDU Sets could be the same and applying the PDU Set QoS parameters to a single PDU could be no problem.' However, 'In case the QoS requirements for the lone PDUs and the marked PDU Sets are different, this could be an issue. Such use cases still need further study.'
The analysis further states: 'In the identified media related use cases, the unmarked PDU’s are sparser compared to the marked PDU’s but relatively important for the service/application. This points in the direction that differentiated treatment of unmarked PDU’s compared to marked PDU’s might be useful... Since unmarked PDU’s are mostly sparse and critical for the services, it is not clear if differentiated treatment between different unmarked PDU’s will bring additional advantages.'
The analysis suggests that while unmarked packets (like audio or control signals) often have high importance for service quality, they typically consume little bandwidth. This could justify giving them different QoS treatment than marked PDU Sets (like video frames) in future 5G standards, but more study is needed. For now, the question of how to handle their QoS requirements is deferred, pending further work and coordination with the SA2 working group (overall system architecture).
This document is a CR (a proposed change to a published standard) for the technical report TR 26.822, part of the work on 5G Real-time Transport Protocol Configurations, Phase 2. It addresses a gap in analyzing the Quality of Service (QoS) requirements for 'unmarked' or 'lone' Protocol Data Units (PDUs) when they are mixed with marked PDUs in the same data flow. In 5G, PDU Sets are groups of packets (like a video frame) that can be marked for special QoS handling. The issue arises when some packets in the same flow are not part of a marked set.
The analysis, led by Huawei and HiSilicon, identifies scenarios where unmarked PDUs appear. These include: multiplexed audio and video RTP streams where only video uses PDU Set marking; RTP and RTCP control traffic on the same port; and other cases like STUN packets or retransmission streams. The document concludes that in these media-related use cases, unmarked PDUs are typically sparse in bandwidth but critical for the service. It states: 'QoS requirements for lone PDUs and marked PDU Sets could be the same and applying the PDU Set QoS parameters to a single PDU could be no problem.' However, it also notes that if their requirements differ, it 'could be an issue. Such use cases still need further study.'
The document proposes adding this analysis to the report's gap analysis section. It suggests that differentiated treatment for unmarked PDUs might be useful but is not clearly needed between different types of unmarked PDUs. It notes that future work in SA2 (overall system architecture) on detecting multiplexed streams could avoid this issue. The document's status is 'revised', indicating it was sent back for rework. The meeting did not make a decision to adopt the proposed change.
The core question of how the 5G network should handle the QoS for individual, unmarked packets when they share a data flow with grouped, marked packets remains open. The analysis suggests the problem might be minor for many real-time media services, as the unmarked packets are few but important. However, without a decision, no normative rules are added to the standard. This leaves implementation choices to vendors and operators for now, potentially relying on future SA2 enhancements for stream differentiation to resolve the underlying multiplexing issue.
Orange and Thales flagged a critical flaw in 'Solution #11', a leading candidate for protecting 5G/6G signaling against quantum computers: its sequential encryption fails standard IND-CCA2 security if the outer layer is broken. The proposal has been deferred rather than adopted.
The 3GPP study 'FS_CryptoPQC' is exploring how to protect mobile network signaling (like the initial connection message a phone sends) from future quantum computers. This document evaluates one specific proposal, labeled 'Solution #11'.
A group of companies led by Orange and Thales submitted an analysis stating that 'Solution #11' has a critical security weakness. They explain that the solution 'sequentially encrypts the data' in a way that is 'reminiscent of the hybrid approach'. Their analysis concludes: 'This sequential approach has been thoroughly studied in cryptography and is known to be incompatible with IND-CCA2 (Indistinguishability under adaptive Chosen-Ciphertext Attack) security in the case where the outer encryption layer would be broken (a reasonable assumption in the context of hybrid cryptography). Indeed, in such a case, an adversary can strip off this layer and then re-encrypt the resulting inner ciphertext, thereby producing a new valid SUCI.'
They also note that the solution's integrity protection 'relies on the security of the MAC scheme that uses a key that is solely derived from the PQC ephemeral key. This means that security does not rely on both cryptographic components, as is usually expected from a hybrid scheme, but only from the one of the PQC scheme.' Finally, they state the approach 'increases complexity as two symmetric encryptions and MAC generations are necessary.'
The document's status is 'not treated', and the meeting did not make a decision based on this specific contribution. The document includes an editor's note stating 'Further evaluation is FFS (For Further Study).'
| Solution #11 has a critical security flaw and should be rejected |
|---|
| Orange · Thales2 companies |
A major candidate design for securing 5G/6G subscriber privacy against quantum attacks has been flagged as fundamentally insecure by key industry players. If this flaw is confirmed, 'Solution #11' will not become part of the standard, narrowing the options for the final post-quantum cryptography solution. This pushes the working group to focus evaluation efforts on other, more robust proposals.
XR standardization moved just one step forward this quarter: SA6 added a single evaluation covering how a phone manages connected headsets and controllers over SEALDD, out of 269 contributions across 16 work areas.
Meetings in this article’s source material. Inclusion does not mean that every meeting approved every decision.
This document concerns the ongoing study on application enablers for Extended Reality (XR) services. The study looks at how the network can better support demanding XR applications, which often involve multiple connected devices like headsets and controllers.
At its meeting #70, SA6, the working group responsible for service requirements and system architecture for applications, approved the addition of a solution evaluation for 'sol#8' to the technical report TR 23.700-51. The approved text states that this solution addresses how to enhance support for SEALDD connection management between a tethering device (like a phone) and multiple tethered devices, potentially using mechanisms like PINAPP or device identifiers. It also addresses how the application enabling layer could support Quality of Service (QoS) differentiation when multiple tethered devices are connected to the same 3GPP device. The evaluation notes that the solution enables a SEALDD client to manage tethered devices based on a device identifier and states it has no architecture impact.
Formally including this evaluation in the technical report documents a candidate method for handling complex multi-device XR setups. By stating there is no architecture impact, it suggests this solution could be implemented without major changes to the core network, potentially making it a simpler option for future standardization. The focus on QoS differentiation for tethered devices indicates an effort to ensure consistent performance for XR applications even when traffic is split across multiple accessories.
Lenovo proposed a security evaluation for one authentication method covering how sensing requests get verified between an application function and the network exposure function, but the 57-contribution study left it unfinished, pushing the decision to a future meeting.
Meetings in this article’s source material. Inclusion does not mean that every meeting approved every decision.
This document concerns the security of Integrated Sensing and Communication (ISAC), a technology that allows a mobile network to sense its environment (like detecting objects or motion) while simultaneously carrying communication traffic. The topic is part of a broader study on ISAC security (TS 33.777). The document, submitted by Lenovo, proposes adding a security evaluation for a specific technical solution labeled 'Solution #1.6'. The proposal states: 'This solution fullfills the potential security requirements of key issue #1: Sensing Service Consumer (AF) authentication and auhtorization at the NEF as well as integrity protection, confidentiality protection and replay protection for the communication between sensing service consumer and NEF is performed according to TS 33.501. The sensing service request from a sensing service consumer is authorized by the Sensing Function according to TS 23.700-14.' The document's status is 'revised', indicating the proposal was not finalized and will be reworked for a future meeting. No reason for this outcome is recorded in the provided materials.
Cloud management for virtualized network functions got a small extensibility hook: 3GPP approved an optional attribute, mnsAdditionalInfo, letting 3GPP management data carry extra key-value parameters for external orchestration systems.
Meetings in this article’s source material. Inclusion does not mean that every meeting approved every decision.
The document is a pCR (a proposed change to a draft study) for the technical report TR 28.869, which is part of the 'Study on Cloud Aspects of Management and Orchestration (FS_Cloud_OAM)'. This study examines how to manage virtualized network functions (VNFs) in cloud environments. The pCR, submitted by NTT Docomo, was approved for merging into the report.
The approved change adds an 'Evaluation of solutions' section for several use cases defined in clause 5.1 of the report. The evaluation covers solutions for configuring, applying policies to, managing traffic for, and upgrading Network Function (NF) Deployments using VNF generic OAM (Operations, Administration and Maintenance) functions.
For solutions that rely on interfaces defined by the external standards body ETSI (specifically ETSI GS NFV-IFA 049), the pCR states the interaction is out of 3GPP's scope. However, it proposes a general improvement: introducing an optional attribute called 'mnsAdditionalInfo' within the 'MnSInfo' data structure defined in 3GPP TS 28.622. This attribute would carry additional parameters as key-value pairs. The report states: 'The solutions presented in clauses 5.1.1.3.4 and 5.1.1.3.6 relies on the use of existing SA5 specifications to support configuration of NF Deployments. These solutions do not require any further enhancements to support the use case requirement REQ-CVNF_CM-1.'
For policy, traffic, and upgrade management use cases, the evaluation notes that solutions using existing 3GPP SA5 (the working group responsible for network management and charging) specifications already satisfy the requirements and need no further enhancements. For solutions using the external ETSI interfaces, any required information from the 3GPP management system could be conveyed using the proposed optional 'mnsAdditionalInfo' attribute.
The approval integrates an evaluation framework into the ongoing cloud management study, formally assessing different technical approaches. The key technical proposal is for an optional, extensible attribute (mnsAdditionalInfo) in 3GPP's management data models. This would allow 3GPP management systems to pass necessary configuration or context data to external cloud orchestration systems (like those from ETSI) without requiring changes to core 3GPP interfaces. It's a pragmatic step towards interoperability between 3GPP's management world and broader cloud-native toolchains, acknowledging that full management may involve systems outside 3GPP's direct specification.
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 |
|---|---|---|---|
| Deferred | 6G downlink waveform study focuses on CP-OFDM enhancements, deprioritizes DFT-s-OFDM for general use | 6G | R1-2508564 |
| Deferred | 6G to support multiple duplexing modes and flexible uplink/downlink pairing | 6G | RP-253779 |
| Deferred | 6G coverage targets to be defined using Maximum Coupling Loss (MaxCL) | 6G | RP-253778 |
| Deferred | 3GPP to study how to ensure mandatory 6G features are actually deployed | 6G | RP-253874 |
| Deferred | Three technical options proposed for 400 MHz bandwidth support around 7 GHz | 6G | R1-2509482 |
| Deferred | Maximum 6G carrier bandwidths proposed for sub-6 GHz spectrum | 6G | R1-2509482 |
| Decided | Macro and micro cell definitions retained for 6G scenarios | 6G | RP-253777 |
| Deferred | Multi-TRP operation not introduced as a specific 6G deployment scenario | 6G | RP-253777 |
| Deferred | 6G will study three ways for phones to handle 400 MHz channels around 7 GHz | 6G | R1-2509481 |
| Deferred | SA2 group proposes a broad study scope for 6G computing, deferring key decisions | 6G | S2-2510146 |
| Deferred | First set of 5G features confirmed for 6G, others deferred or dropped | 6G | S2-2510762 |
| Deferred | Ericsson outlines six essential requirements for integrating non-terrestrial networks into 6G | 6G | R2-2508703 |