3GPP Quarterly — June 2025

Ambient IoT's downlink modulation picks 24 as the maximum 'M' value

Ambient IoT is a 3GPP feature for connecting simple, battery-free sensors and tags via a 5G or 6G network. A key part is the 'R2D' (Reader-to-Device) link, where a network base station (the 'reader') sends data to a tag. This link uses a specific modulation called OOK-4, where each OFDM symbol is divided into 'M' chips. A higher M value means more chips per symbol, leading to a higher data rate but shorter chip duration, which can make the signal harder to detect reliably.

At the RAN1#120bis meeting, RAN1, the working group responsible for the physical layer, decided on the maximum M value for R2D transmission. The decision was: "For R2D, for the OOK-4 modulation for M-chip per OFDM symbol transmission, the maximum M value is 24." RAN1 will further determine the full set of M values up to this maximum. The agreement specifies that this maximum of 24 applies to the PRDCH (the main physical data channel).

The document notes that the maximum M value of 24 "has the majority of support" among the three candidate values of 32, 24, and 16. It states that M=32 "has the least support" with concerns about "severe performance degradation," while for M=16, the "concerns mainly [relate] to the competitiveness to non-3GPP technologies."

The RAN1#120-bis meeting record records this as agreed: "For R2D, for the OOK-4 modulation for M-chip per OFDM symbol transmission, the maximum M value is 24."

Companies split on how to signal FEC and repetition for scheduled Ambient IoT data channels

Ambient IoT is a 3GPP technology for ultra-low-power devices that communicate by backscattering an external carrier wave. For indicating the use of forward error correction (FEC) and the number of block-level repetitions for a scheduled data channel (PDRCH), two main proposals were on the table. A group of 15 companies including OPPO, Samsung, Huawei, and Ericsson supported Option 1: using separate indications for FEC and repetition count. A second group of 9 companies including Qualcomm, Nokia, and ZTE supported Option 2: a joint 2-bit indication that combines both parameters into a single field. The meeting noted the document containing these competing proposals but did not make a decision between them.

AI/ML beam prediction accuracy metric definition remains unresolved

In 5G and future 6G, AI/ML models in the phone (UE-side) can predict the best downlink transmit beams for the network. To check if these predictions are accurate, the network needs a performance monitoring method. One method, called 'UE-assisted performance monitoring' (Type 1, Option 2), has the phone calculate and report a prediction accuracy metric. The core debate is how to define this 'accuracy' metric.

A group of companies, including OPPO, Xiaomi, Spreadtrum, Huawei, ZTE, and Lenovo, proposed a definition (Proposal 1.1a). Under this proposal, a prediction is counted as correct if at least one of the Top M measured beams from a monitoring resource set is among the Top-K beams predicted by the AI model. The value of M (1, 2, 3, or 4) would be configured by the network.

Other companies, led by Qualcomm and Google, opposed this definition. They argued that accuracy should be based on a signal strength threshold (X dB) relative to the best measured beam, not just on ranking (Top M). Ericsson presented simulation data showing that in 20% of cases in an urban macro scenario, the 4th strongest beam could be more than 4 dB worse than the best beam, which a ranking-only metric would miss.

Huawei presented complementary data showing the gap between the best and the M-th best beam: for M=4, the gap is 4.94 dB at the 80th percentile. The meeting did not make a decision on the metric definition. The proposal was noted but not approved, meaning the discussion will continue at the next meeting.

The RAN1#120-bis meeting record records a partial agreement on this point: "At least one of the Top M beam(s) of the resource set(s) for monitoring is among Top-K predicted beam(s) of Set A (e.g., linked to at least one of the Top-K predicted beam(s) of Set A based on certain rule or signalling)"

Management Data Analytics phase 3 to get clearer implementation rules for analytics output

The work item Management Data Analytics phase 3 (eMDAS_Ph3) aims to standardize how network management systems collect and process data for analytics, helping operators optimize their networks. At SA5#161, the group endorsed a way forward to fix inconsistencies in the technical specification TS 28.104.

The document notes that TS 28.104 defines an information model for analytics output in its clause 8 at 'stage 2' (the architectural level), but lacks corresponding 'stage 3' definitions (the detailed protocol implementation). This creates a lack of guidance for implementers. Furthermore, the attribute definitions in clause 8 do not follow the required template from the base specification TS 32.160, missing properties like 'isReadable' and 'isWritable'.

Two proposals were presented. Proposal 1 recommended introducing a stage 3 solution set for clause 8 for Release 19 only, while keeping Releases 17 and 18 unchanged, and updating the attribute definitions to include the missing properties. Its stated pros were fixing the issue with minimal change and achieving consistency between stage 2 and 3. Its cons were requiring more effort and changes than the alternative, and that the data type definition would still not be fully aligned with TS 32.160.

Proposal 2 recommended making no changes to the stage 2 definitions and implementing the stage 3 part strictly as an 'AttributeValuePair', mandating that attributes must come from clause 8. Its stated pro was resolving the stage 3 issue at a semantic level. Its cons were that stage 2 and 3 would not be fully consistent, and that automatically generating production code from this stage 3 definition would be impossible.

The meeting endorsed 'Proposal 1' as the way forward.

Valid downlink slot definition for CSI reporting will not consider dynamic measurement gap cancellation

This topic concerns how a phone determines a 'valid downlink slot' for Channel State Information (CSI) reporting when the network can dynamically cancel a measurement gap. A valid downlink slot is a time interval where the phone can assume reference signals for measuring channel quality are present. In 5G, this definition is based on semi-statically configured measurement gap patterns. For Release 19's XR (eXtended Reality) enhancements, a new feature allows the network to send a dynamic indication (a Downlink Control Information, or DCI, field) to cancel a scheduled measurement gap, letting the phone transmit or receive XR data instead.

RAN1, the working group responsible for the physical layer, agreed that 'Valid downlink slot for CSI reference resource definition is only determined based the configured measurement gap pattern and not affected by dynamic measurement gap occasion cancellation.' This means that even if a measurement gap is dynamically cancelled to allow XR traffic, the phone will not consider the cancelled-gap slot as valid for CSI reference signals. The group concluded that 'No CR to TS38.214 Section 5.2.2.5 needed due to Rel-19 XR enhancements.'

The RAN1#121 meeting record records this as agreed: "Valid downlink slot for CSI reference resource definition is only determined based the configured measurement gap pattern and not affected by dynamic measurement gap occasion cancellation."

RAN1 defers handling of overlapping measurement gaps to RAN4

This topic deals with the scenario where a phone is configured with two or more measurement gap patterns that overlap in time. The question was how a dynamic DCI-based cancellation indication should apply: to the first gap, the highest priority gap, or both. Measurement gaps are periods when the phone tunes its radio away from the serving cell to measure neighboring cells on other frequencies.

RAN1 concluded that 'RAN1 does not discuss the measurement gap occasion cancellation for concurrent measurement gaps further unless triggered by RAN4.' The group noted that RAN4, the working group responsible for radio performance requirements, is already discussing which types of overlapping gaps can be cancelled and has defined prioritization rules. Therefore, RAN1 will wait for RAN4's conclusions before specifying any corresponding physical layer behavior.

ISAC channel model calibration will include both large-scale and full-scale parameters

Integrated Sensing and Communication (ISAC) is a feature that allows a mobile network to use its signals not only for communication but also to detect and track objects, like drones or vehicles. For the channel model—the mathematical description of how signals travel—to be accurate, it must be calibrated against real-world measurements. RAN1, the working group responsible for the physical layer, agreed that this calibration will cover two levels: large-scale parameters (like path loss and shadow fading, which do not include fast fading) and full-scale parameters (which do include fast fading). The group also agreed that the calibration will treat the 'target channel' (the signal path reflecting off the object being sensed) and the 'background channel' (the general environment) separately. The decision to include spatial consistency or environmental objects in the calibration will be made on a case-by-case basis for different scenarios.

Calibration parameters agreed for UAV sensing in an urban macro scenario with aerial vehicles

To calibrate the channel model for sensing Unmanned Aerial Vehicles (UAVs), specific simulation parameters are needed. RAN1 agreed on a detailed set of assumptions for 'large-scale calibration' in a UMa-AV (Urban Macro with Aerial Vehicles) scenario. Key parameters include using carrier frequencies of 6 GHz (FR1) and 30 GHz (FR2) with bandwidths of 100 MHz and 400 MHz respectively. Base station transmit power is set to 56 dBm for FR1 and 41 dBm for FR2. The simulation assumes a single, small UAV target (0.3m x 0.4m x 0.2m) at a fixed height of 200 meters. The primary metric for this calibration will be the 'coupling loss' for the target channel, which is based on line-of-sight path loss. The group also confirmed that all four fundamental sensing modes (TRP monostatic, TRP-TRP bistatic, TRP-UE bistatic, UE-UE bistatic) will be considered.

A group of companies pushed for dynamic scheduling request updates with beam changes, but no agreement was reached

This topic addresses a problem in 5G networks using beamforming, especially at high frequencies. When a phone's uplink beam changes, its scheduled request (SR) transmission might no longer align with the base station's receiving beam, potentially causing the request to be missed.

A coalition led by ZTE, China Telecom, China Unicom, NTT DOCOMO, Qualcomm, and Sanechips proposed a solution. They suggested that when a new beam (TCI state) is indicated to a phone, an associated time offset should also be applied to shift the phone's SR transmission occasion to a slot where the base station's beam is correctly aligned. The proposal involved introducing new RRC parameters for this time offset. Companies including Samsung, Huawei, and Spreadtrum opposed the proposal, arguing it doesn't fully solve the problem, could impact other uplink channels, and might have significant specification complexity. The moderator stated that RAN1 did not reach an agreement on this proposal during the meeting. The reason for not agreeing is not recorded in the provided materials. Proponents were encouraged to address concerns about potential RAN2 impacts and the necessity of adjusting frequency and code resources, not just timing.

Clarification agreed for handling SRS carrier switching alongside uplink transmission switching

This topic deals with complex phone behavior when it is configured for two simultaneous features: SRS Carrier Switching (jumping a sounding signal to another frequency) and Uplink Transmission Switching (changing which antenna chain is used for uplink data).

RAN1 agreed on rules to resolve ambiguities when these features are configured together. It confirmed that existing prioritization rules in the specification are applied. If a phone has indicated via an earlier capability which frequency bands are affected by SRS carrier switching, those rules are used. If it hasn't indicated that capability, the phone can only perform simultaneous transmissions if the total number of required transmitter chains does not exceed what the phone supports. The agreement also clarified scheduling restrictions and that required switching times are dictated by existing or new UE capabilities.

SA5 defines new monitoring and feedback capabilities for automated network control loops

Closed Control Loop Management (CCLM) refers to automated systems in mobile networks that monitor conditions and take actions without human intervention, such as adjusting power or load balancing. A pCR (a proposed change to a draft study) from Nokia proposes adding new use cases and requirements for assessing and resolving the impact of these automated loops, as agreed in an earlier study documented in TR28.867.

The proposal introduces a new 'CCL Performance Monitoring' capability. One use case, 'Performance Evaluation of a Closed Control Loop', states that operators need to evaluate a loop's own performance using metrics like the number of breached goals, time to meet a breached goal, and number of conflicts caused. This would allow operators to compare different loops and choose the best one for deployment.

Another use case, 'Consumers feedback on CCL actions', proposes that the management system should allow consumers (like network management functions) to provide feedback on the quality of a loop's automated actions, for example on a scale from 0 to 10. Consumers should also be able to receive information about the actions taken and request that changes be revoked, for instance, to prevent a specific network function from being updated in the future.

A third use case, 'Assessment and resolution of CCL Impact on unknown impact-scope', addresses situations where a loop's action (like changing transmit power) affects an unpredictable scope, such as neighboring cells. It proposes that affected loops should report their observed impact (positive or negative) to the acting loop. The acting loop would then derive an appropriate remediation, such as reconfiguring its own actions or undoing them.

The document lists corresponding requirements for the management system, including the ability to obtain a loop's performance metrics, enable consumer feedback and revocation requests, and support capabilities for receiving impact reports and proposing remediations. The document's status is 'revised', indicating it is being reworked and was not finalized at this meeting. The reason for revising the document is not stated in the provided materials.

RAN2 defers detailed RRC signaling for 5G beam sweeping optimization, awaits RAN4 input

The topic is optimizing the 'Beam Sweeping Factor' (BSF) for receivers (Rx) in 5G NR. This is a technique to reduce the power and time a phone spends searching for the best beam from a cell tower, which is especially relevant for high-frequency (mmWave/FR2) bands where beams are narrow and change frequently. The working group RAN2, responsible for the protocols between the handset and network, discussed how to define the signaling rules for a phone to activate this power-saving 'multi-Rx L3 measurement' mode.

A group of companies, led by CATT, proposed a way forward. The document states that RAN2 should wait for further progress from RAN4, the working group responsible for radio performance and physical layer requirements, on the Rx BSF optimization. It notes that RAN4 had not discussed the specific RRC (Radio Resource Control) signaling details for the activation condition in this meeting.

Based on proposals from ZTE, the document outlines four points for further discussion: 1) Not implementing 'TimeToTrigger and Hysteresis in activation condition' for now. 2) Introducing separate RSRP (Reference Signal Received Power) and RSRQ (Reference Signal Received Quality) thresholds, where the phone activates the mode only if both configured thresholds are met. 3) Limiting the optimization's applicability to a specific scenario: a phone using a single FR2-1 band carrier as its primary cell, without carrier aggregation or dual connectivity, and with only one SSB-based measurement object configured. 4) Adding the new threshold parameters within the 'MeasConfig' Information Element in the RRC specification.

The meeting noted the document but did not approve it as a final agreement. The reason for deferring the decision is not stated in the source materials.

SA6 proposes evaluation criteria for 5G/6G network APIs to ease developer use

This topic concerns the Service Enabler Architecture Layer (SEAL), a set of standardized network functions that expose 5G and future 6G network capabilities (like quality of service or location) to applications via Application Programming Interfaces (APIs). This makes it easier for app developers to use advanced network features.

A group of companies led by Huawei and HiSilicon proposed adding an evaluation section for 'Technical solution #2', which is a set of API design guidelines. The proposal states the guidelines are 'aligned with the widely accepted principle for easing the usage of API services by API invokers' (like app developers).

The proposed guidelines state that each SEAL service API should be self-contained, reusable, and minimize impact on the application's implementation. It also introduces a design approach called 'Application layer requirement oriented', where an API service is designed to optimize data transmission (e.g., reducing latency) or provide required information (e.g., network status) based on specific application needs. An editor's note in the proposal explicitly states: 'Whether the "Application layer requirement oriented" is accepted as SEAL service design guidelines needs to be further evaluated.'

The proposal argues that the complexity of implementing these guidelines is limited, as 'the maximum number of different combinations of QoS capabilities is limited to several cases (based on the 5GA typical applications usecase identified by SA1).' It concludes that the guidelines 'will only impact the newly added services... will not impact the existing architecture or API services.'

The document status is 'revised', indicating it was sent back for rework. No record of a decision to approve or reject the proposed text was found in the provided materials.

SA6 approves layered model for 5G network exposure system

The Service Enabler Architecture Layer (SEAL) study is defining how mobile networks can expose their capabilities (like location, quality of service, or network slicing) to applications in a standardized way. At its 66th meeting, SA6, the working group responsible for overall system architecture, approved a proposal to add an evaluation of a specific architectural model, called 'Adoption Solution#2', to its technical report.

The approved text describes a layered representation of the 3GPP network exposure system. It defines three layers: the '3GPP network connection layer', which provides fine-grained, fundamental network capabilities like connectivity and QoS; the '3GPP application enabler layer' (also called the service abstraction or value-added service layer), which contains SEAL servers and clients that aggregate network capabilities into larger, application-meaningful services; and the '3GPP exposure framework layer', which handles common functions like API discovery and authorization, based on the Common API Framework (CAPIF).

The solution evaluation states: 'This solution clarifies the role and responsibility of SEAL service layer from the whole 3GPP system perspective, which are missing from 3GPP official document. Such layered representation of whole 3GPP network exposure system in the network exposure language will be helpful for customers to understand SEAL services better.'