Energy-saving SIB1 stays locked to the standard frequency raster
Off-raster beams were rejected four times; a 1-bit flag to target single beams split Ericsson and Samsung against Nokia, ZTE, Huawei and Apple without resolution.
Source meetings for this article (9)
Meetings in this article’s source material. Inclusion does not mean that every meeting approved every decision.
- RAN#1089 Jun 2025 – 13 Jun 2025 · Prague · 3GPP ↗
- RAN1#120-bis7 Apr 2025 – 11 Apr 2025 · Wuhan · 3GPP ↗
- RAN1#12119 May 2025 – 23 May 2025 · Malta · 3GPP ↗
- RAN4#114-bis7 Apr 2025 – 11 Apr 2025 · Wuhan · 3GPP ↗
- RAN4#11519 May 2025 – 23 May 2025 · Malta · 3GPP ↗
- RAN3#127-bis7 Apr 2025 – 11 Apr 2025 · Wuhan · 3GPP ↗
- RAN3#12819 May 2025 – 23 May 2025 · Malta · 3GPP ↗
- RAN2#129bis7 Apr 2025 – 11 Apr 2025 · Wuhan · 3GPP ↗
- RAN2#13019 May 2025 – 23 May 2025 · Malta · 3GPP ↗
Network energy savings for NR hinges on letting a base station skip broadcasting SIB1 and send it only when a phone asks for it via an uplink wake-up signal. The catch is which beam carries the reply: Ericsson, Samsung, LG and Fujitsu wanted a 1-bit flag letting the network answer only on the beam the phone used, cutting transmissions elsewhere. ZTE, Huawei, Apple, Google and OPPO opposed it three separate times across RAN1#120-bis and RAN1#121, arguing it could leave other phones in the area unable to hear SIB1 at all. The flag eventually made it into the specification as an optional behavior, but only after the moderator, MediaTek, reworked the proposal twice.
Companies did agree to keep the SSB itself on the standard synchronization raster — the fixed frequency grid phones already scan for 5G cells. A push to let energy-saving cells sit off-raster was voted down four times, with only CATT dissenting each time; Nokia, Google, Samsung and Apple all backed the status quo. That keeps idle and inactive phones from needing extra power-hungry frequency searches, which matters directly for standby battery life on every device using the feature.
Timing got two firm rules. The MIB, refreshed every 80 ms, can't change the K_SSB parameter faster than that period, so a network can't flip a cell between broadcast and on-demand SIB1 mode more often — proposed by Nokia and backed by CMCC, Google and Qualcomm. Separately, RAN1 fixed the K_SSB field itself at 5 bits for sub-7 GHz spectrum and 4 bits for millimeter wave, with no changes to the existing broadcast channel structure, and confirmed the SIB1 reception window can start at the reference point or later, never earlier.
Google tried to force phones to always pick the beam with the lowest index number when sending their wake-up signal, arguing it would cut both network and device power use. CMCC, vivo, Fujitsu, Qualcomm, Sharp, Sony, LG, NEC, Ofinno and Tejas rejected it twice, preferring to keep the legacy 5G rule that lets a phone pick any beam above the signal threshold — one of the clearer defeats of the quarter, ten companies against one.
Two questions stayed open without even a proposal reaching a vote: whether a phone should listen for an existing SIB1 broadcast before bothering to send a wake-up signal (LG, Ericsson and MediaTek want it to check; Apple doesn't), and whether the feature should be tested against RedCap devices and unlicensed-spectrum operation, where Google, Qualcomm and Futurewei argue the work is out of scope. Both return to RAN1's next meeting, and until the wake-up-signal question is settled, chipset vendors can't finalize how much standby power the feature actually saves.
The decisions behind this
Proposal for 1-bit SSB indication in on-demand SIB1 procedure fails to gain support
This issue deals with how a user equipment (UE) requesting SIB1 on-demand knows which network beams (SSBs) to monitor for the scheduling command (PDCCH). The core question was whether the network should be able to tell the UE, via a 1-bit flag in the Wake-Up Signal (WUS) configuration, to monitor only the beam used for its request or to monitor all beams as in legacy 5G.
The moderator, noting divided company views, proposed a compromise (FL Proposal 1-1). It suggested adding a 1-bit indication in the UL WUS configuration. If set to TRUE, the UE would assume the PDCCH is transmitted on at least the SSB associated with its request and monitor that one, with monitoring of other beams being implementation-specific. If the bit is not set, the UE would fall back to the legacy 5G behavior, assuming transmission on all beams.
This proposal did not achieve consensus. Key objections included ZTE and OPPO arguing it was unnecessary and could prevent other UEs from receiving the SIB1. Google, Futurewei, Huawei, China Telecom, Ofinno, and CATT also did not support it, citing a lack of clear need or preference for the simpler legacy behavior. While companies like Ericsson, Qualcomm, LG, and Fujitsu were fine with the proposal, the opposition was sufficient. The discussion was closed without agreement, and the topic will return to a future meeting.
| Support 1-bit indication proposal | Do not support 1-bit indication proposal |
|---|---|
| Ericsson · Qualcomm · LG · Fujitsu · Samsung · vivo6 companies | ZTE · OPPO · Google · Futurewei · Huawei/HiSilicon · China Telecom · Ofinno · CATT · Nokia · Apple · ETRI · Panasonic12 companies |
The lack of agreement means the detailed mechanism for beam indication in the on-demand SIB1 procedure remains unresolved. The fallback is the existing agreement from the prior RAN1#120 meeting, which leaves two specific items as 'FFS' (For Further Study). This delays a potential network energy-saving optimization where the gNB could signal a UE to monitor fewer beams.
On-demand SIB1 transmission beams: No consensus on a 1-bit indicator, debate continues
The topic concerns how a base station (gNB) transmits the essential System Information Block 1 (SIB1) after a user device (UE) requests it via an uplink wake-up signal (UL-WUS). Specifically, it addresses whether the SIB1 is sent only on the beam the UE used for its request or on multiple beams, and if the network can tell the UE which beams to expect. A group of companies, led by the meeting moderator (MediaTek), proposed a compromise: a 1-bit indicator in the UL-WUS configuration. If set to TRUE, the UE would assume SIB1 is transmitted on at least the beam associated with its UL-WUS and monitor only that beam. If not TRUE or not present, the UE would assume the legacy 5G behavior where SIB1 is transmitted on all active beams. This proposal was not adopted. The meeting only noted the document containing the proposal and the collected company views. The reason for not adopting the proposal is not recorded in the materials.
| Supported the moderator's 1-bit indicator proposal | Opposed the moderator's 1-bit indicator proposal |
|---|---|
| CMCC · vivo · Spreadtrum · Fujitsu · Ericsson · Samsung · Qualcomm · LG8 companies | Nokia · ZTE · Google · OPPO · Xiaomi · Futurewei · Huawei · Apple · ETRI · Panasonic · China Telecom11 companies |
The core question of beam-level transmission for on-demand SIB1 remains unresolved. Without a new agreement, the existing agreement from the prior RAN1#120 meeting stands, which already contains two 'FFS' (For Further Study) points on this exact topic. This means the standard has not yet defined whether UEs should expect SIB1 on other beams or if the gNB can indicate the beams, leaving these aspects open for future discussion.
- DeferredNo consensus to support on-demand SIB1 on SSBs off the sync rasterR1-2503006
- DeferredProposal for a 1-bit SSB indication for on-demand SIB1 fails to gain consensusR1-2503007
- DeferredNo agreement reached on how to indicate which beams carry on-demand SIB1R1-2503005
- DeferredPhone behavior before sending a wake-up signal remains undecidedR1-2503005
- DroppedProposal to change UE beam selection rule for on-demand SIB1 request rejectedR1-2503006
- DeferredProposal to mandate specific SSB selection rule for wake-up signal rejectedR1-2503007