3GPP Quarterly — March 2025

Ambient IoT devices can use multiple time slots for their initial access message

Ambient IoT (Internet of Things) refers to ultra-low-power devices, like sensors or tags, that harvest energy from radio waves and communicate by backscattering a signal from a reader. A key part of their operation is the initial random access message, called Msg1, sent from the device to the reader. The working group RAN1, responsible for the physical layer, discussed whether a single reader trigger could schedule a device to send its Msg1 in one of multiple consecutive time slots (TDMA with X>1), rather than just one slot (X=1). A coalition of companies including FUTUREWEI, Qualcomm, Samsung, Nokia, and vivo proposed supporting both X=1 and X>1, with the maximum value of X to be chosen later between 2 and 4. Companies like Ericsson and ZTE opposed this, preferring only X=1, citing added complexity and a lack of clear latency benefits. The meeting did not adopt the proposal. The document states, 'RAN1 targets to decide on the support of X>1 at RAN1#120bis'.

Group defers decision on how to handle padding in Ambient IoT downlink signals

When an R2D transmission does not perfectly fill the last OFDM symbol, 'padding' extra chips is needed to align with the symbol boundary. A coalition of companies proposed different ways to handle this padding.

The feature lead summary contains an open proposal: "As per TR 38.769, for the OFDM-based OOK-4 waveform, from the reader perspective, when the generated number of chips for the R2D transmission does not fully occupy the last OFDM symbol, padding is used to align with the boundary of the last NR OFDM symbol for in-band operation. Further to the TR, Padding is to be down-selected between the following alternatives: Alt 1: The content of padding is up to reader implementation and transparent to A-IoT device. Alt 2: Specify the detail content of padding." The document shows companies are split, with some (like Spreadtrum, CMCC, Nokia) preferring Alt 1 and others (like LG Electronics, Samsung) preferring Alt 2. No agreement was reached at this meeting.

No decision on per-slice performance measurement, clarification needed from SA5

This topic concerns how a 5G base station (gNB) can measure and report the performance of a single user device (UE) for each specific network slice it uses. A network slice is a virtual network tailored for a specific service type, like enhanced mobile broadband or massive IoT. The performance metrics in question are uplink/downlink throughput, packet delay, and packet loss. The core disagreement is whether the specifications from SA5 (network management and charging) already define how to calculate performance per user per slice, or if the definition is unclear and needs enhancement.

A group of companies led by Lenovo proposed a way forward. They noted that at the last RAN3 meeting, it was agreed that a source base station can request performance feedback with per-user, per-slice granularity. However, there is no consensus on whether this performance can actually be measured and reported by the target base station. The proposal states: 'RAN3 is suggested to firstly clarify if per UE per S-NSSAI throughput/delay/packet loss measurement is already specified e.g., in TS 28.558. Consult SA5 if needed.'

Companies are split. Ericsson, Huawei, and ZTE argue that 'SA5 has defined and supported the per slice per UE performance. RAN3 does not need to further discuss.' Nokia and CATT counter that 'it is unclear from SA5 spec, how per slice per UE performance is calculated. What’s supported in SA5 spec now is per slice, but not per slice per UE.'

A secondary issue is whether reporting performance at the slice level is sufficient for a source gNB to judge if performance improved after a handover. Some proponents suggest measuring at the per-QoS-flow level instead, but opponents either don't see this as a major issue or doubt the proposed solution would work. The meeting took note of the document but did not approve the proposals.

Companies propose diverse methods for AI beam monitoring, no consensus reached

This topic concerns the detailed mechanisms for how a phone reports the performance of its AI beam prediction model to the network. While it was previously decided that a 'UE-assisted' method would be supported, many specifics remain open. A coalition of companies including Huawei, HiSilicon, Intel, Kyocera, CMCC, and Apple put forward numerous competing proposals at RAN1#120. Their proposals covered how to define the beam accuracy metric, how to trigger reports based on performance events (e.g., accuracy falling below a threshold), whether to monitor all possible beams or just a subset to save power, and how to link the monitoring report to the original AI inference report in the signaling. For example, Huawei/HiSilicon's Proposal 26 suggested a new definition for an accurate prediction, while Intel argued for supporting multiple metric types beyond simple accuracy. Apple proposed an event-driven scheme similar to existing Radio Link Monitoring. The meeting noted these contributions but did not make a decision on any of the specific proposals. The reason for the decision is not recorded in the documents.

Proposals on environment objects and calibration scope remain under discussion

Several detailed proposals from companies were noted but not decided upon at this meeting. A coalition of companies including Vivo, ZTE, AT&T, Huawei, and Nokia (14 in total) supported a 'High' priority proposal that 'Large Scale calibrations are considered,' while a group including OPPO, Ericsson, MediaTek, and Samsung (4 in total) supported an alternative that 'Large Scale calibrations are not considered.' Another proposal suggested that 'Inclusion of EO type 1 and/or EO type 2 in CM calibrations is optional,' where EOs (Environment Objects) are elements like buildings. The meeting did not adopt these specific proposals; they are carried forward for further discussion. The moderator's summary states that inclusion of Environment Objects in ISAC channel model calibrations can be considered case by case for different scenarios.

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

Integrated Sensing and Communication (ISAC) is a technology that allows a 5G or future 6G network to detect and locate objects using the same radio signals used for communication. This requires accurate mathematical models (channel models) to simulate how these sensing signals behave. RAN1, the working group responsible for the physical layer, agreed on the framework for calibrating these models. The group decided that for ISAC channel modelling calibration, RAN1 considers both large-scale and full-scale calibration. Large-scale calibration includes parameters where fast fading is not included, and full-scale calibration includes fast fading. It was noted that one part of the calibration work does not include additional components and does not include spatial consistency, but additional calibrations including spatial consistency can be considered case by case for different scenarios.

Proposal for flexible DMRS port allocation remains under discussion

A coalition of companies including Tejas Networks and several Indian academic institutes proposed a Technical Enhancement and Improvement (TEI) titled 'Flexible DMRS port allocation'. Demodulation reference signals (DMRS) are pilot signals used to estimate the radio channel. The proposal argues that current rules for assigning DMRS 'ports' to users are restrictive. It suggests new allocation strategies in the antenna port tables of the physical layer specification (TS 38.212) and corresponding co-scheduling rules in TS 38.214. The proponents claim this provides a 'mean square error (MSE) advantage in channel estimation' by allowing ports to be distributed across Code Domain Multiplexing (CDM) groups more flexibly. It also includes a proposal for a new UE capability parameter (DMRS-PartialPortEnh-DL) so a phone can indicate it supports this enhancement. The meeting took note of the proposal but did not make a decision on it. The reason for the decision is not recorded in the provided materials.

Clarification on rules for simultaneous carrier switching and uplink transmission

RAN1 reached an agreement to resolve ambiguities when a phone is configured for two advanced features simultaneously: SRS carrier switching (where a sounding reference signal is transmitted on a different carrier) and uplink transmitter switching (where the phone's transmit chain switches between carriers for data). The agreement confirms that existing prioritization rules in the standard apply between the target carrier of the SRS switch and another uplink carrier, regardless of the antenna port configuration for the SRS, if the phone has indicated which bands are affected. It also clarifies timing: the required switching time before the SRS transmission depends on whether all transmit chains are available at the source carrier. Furthermore, an SRS carrier switch counts towards a restriction of a maximum of one switch per slot. The agreement states that 'No spec change is needed' for the core prioritization rules, but details on a new UE capability for switching time will be discussed separately.

The RAN1#120 meeting record records this as agreed: "Confirm that the prioritization rules in 38.214 Sec. 6.2.1.3 are applied between target and CC1, regardless of SRS-AS antenna port configuration on target CC, if UE indicates based on srs-SwitchingAffectedBandsListNR-r17 that SRS-CS on target impacts CC1, where CC1 is one of the CC(s) which may share Tx chains with source CC. No spec change is needed."

Proposal to handle overlapping measurement gaps is deferred, pending RAN4 decisions

A group of companies raised the issue of how the gap-skipping instruction should work when a phone is configured with multiple, overlapping measurement gap patterns. The moderator noted that RAN4, the working group responsible for RF requirements, has not yet finalized agreements on supporting such concurrent multiple gaps. Companies were split on whether to pre-emptively decide on rules in RAN1 or wait for RAN4. The moderator proposed to wait, stating: 'it is recommended to put this discussion to hold at least until RAN4 has made agreements.' No decision was made on the handling rules, and the discussion was closed for this meeting with the intent to revisit it later.

RAN1 confirms dynamic DCI-based skipping of measurement gaps for XR in Release 19

The topic is about enabling uninterrupted Extended Reality (XR) traffic during periods when a phone would normally pause communication to perform Radio Resource Management (RRM) measurements on other frequencies or cells. In 5G, these pauses are called measurement gaps or scheduling restrictions. RAN1, the working group responsible for the physical layer, confirmed a working assumption from its previous meeting. The group agreed to specify a dynamic, network-controlled method where the base station sends a one-bit instruction in a Downlink Control Information (DCI) message to tell the phone to 'skip' the next upcoming measurement gap. This allows the phone to continue transmitting or receiving XR data during that gap. The agreement states: 'For solutions based on triggering/enabling by network signaling to enable Tx/Rx in gaps/restrictions that are caused by RRM measurements select the following option: Alt. 1: Dynamic indication to enable Tx/Rx in particular gap/restriction that are caused by RRM measurements. Alt 1-1: Explicit indication by DCI to skip a particular gap/restriction;' It also records the RAN1 understanding that 'if measurement gap/restriction is indicated to be skipped by explicit indication by DCI, the TX/RX is enabled on all the serving cells in the applicable range of the skipped measurement gap/restriction.'

Study confirms bursty nature of real-time traffic, proposes signaling enhancements

This document is part of the 'Study of 5G Real-time Transport Protocol Configurations, Phase 2' (FS_5G_RTP_Ph2). It analyzes experimental data on how real-time video and audio applications send data in bursts over the network. The study focuses on metrics like burst duration and the time between bursts (Time To Next Burst, or TTNB).

The document, a CR (a proposed change to a published standard) to Technical Report 26.822, was submitted by Huawei, Hisilicon, and Nokia. Its status is 'revised', meaning it was sent back for further work and no final decision was made at this SA4 (the working group responsible for codecs and media delivery) meeting.

The proposed change adds an evaluation of experimental data. Key observations from the data include: burst durations are under 1 millisecond; the average time between bursts (TTNB) varies from 3 ms to 423 ms; and in typical real-time communication, up to 99% of data bytes are carried in bursts. The document states, 'a large percentage of the traffic and packets are part of a burst, highlighting the relevance of burst handling'.

Based on these observations, the document proposes principles for future normative work (the scope of normative work that produces a standard). These include: doing normative work for signaling burst size and time to next burst (when known by the application); revisiting the definition of a 'data burst'; and enabling applications to provide a 'data boosting indication' to the 5G network. It notes that 'RAN2 (protocols — the messages between handset and network) has indicated that TTNB may be useful if provided in time and is reliable. SA4 needs further evaluation before proceeding with normative work.'

5G Real-time Transport Protocol study proposes signaling for burst size and timing

This topic concerns optimizing 5G networks for real-time video and audio traffic, which often arrives in short, intense bursts of data packets rather than a steady stream. The 3GPP study '5G Real-time Transport Protocol Configurations, Phase 2' (5G_RTP_Ph2) analyzes traffic patterns to see if networks can be told about upcoming bursts to improve efficiency.

A coalition led by Huawei, Hisilicon, and Nokia submitted a proposed change (CR) to the study's technical report (TR 26.822). The proposal adds an evaluation of experimental data on 'Time To Next Burst' (TTNB) and other burst characteristics. The document's status is 'revised', meaning it was sent back for further work and no final decision was made at this meeting.

The proposed text summarizes findings from lab tests with applications like WebRTC and GStreamer. It states: 'Average inter-burst time observed in experiments is between 3 ms and 500 ms (423 ms rounded up). Burst durations (Bd) are under 1 millisecond.' It also notes that 'up to 99% of bytes is carried in bursts' in typical real-time communication.

Based on these observations, the proposal concludes with principles for future standardization work, including: 'Do normative work for signaling burst size, when deterministically known, from RTP senders... Do normative work for signaling time to next burst, when deterministically known, and dynamically changing...' It adds a note that 'SA4 needs further evaluation before proceeding with normative work.'

SA5 proposes feedback mechanism for automated network control loops

A pCR (a proposed change to a draft study) for the Closed Control Loop Management (CCLM) work item was revised at SA5#159. SA5 is the working group responsible for network management and charging. The proposal, from Nokia and Samsung, adds a use case, requirements, and a solution description for 'Conditional control of CCLs' to TS 28.567.

The proposal addresses a challenge in fully automated control loops (CCLs), where a network function reconfigures itself to meet goals without human input. It notes that the actions taken by a CCL have 'different levels of satisfaction for the different consumers' (like other network functions or management systems), and without feedback, the CCL cannot optimize its performance.

The proposed solution introduces a mechanism for 'CCL-impact assessment and resolution'. When a CCL takes an action whose impact on other parts of the network is not fully known beforehand, it would notify potentially affected entities. These entities would then evaluate the action's effect on their own performance and report back with an 'Action Quality Indicator (AQI)'—an integer score from 0 (completely unacceptable) to 10 (very good outcomes). The acting CCL would aggregate these scores to decide on a remediation, such as reversing the action.

Key proposed requirements include enabling a consumer to provide feedback on CCL actions (REQ-FED-FUN-01), to request revocation of an action (REQ-FED-FUN-02), and to receive information about what the CCL did (REQ-FED-FUN-03). Other requirements focus on capabilities for reporting impacts and notifying other CCLs of actions that may affect them.

The document's status is 'revised', indicating it was reworked during the meeting. No record of a decision to approve or reject the proposed change is contained in the provided materials.