Skip to main content
Energy Efficiency · 3GPP Quarterly June 2025

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.

25 decisions1 work areas679 contributions

Plenary cycle

SA#108 · RAN#108 · CT#108

Prague · 9 Jun 2025 – 13 Jun 2025

Source meetings for this article (9)

Meetings in this article’s source material. Inclusion does not mean that every meeting approved every decision.

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

Deferred
Enhancements of Network energy savings for NR
R1-2503006

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 proposalDo not support 1-bit indication proposal
Ericsson · Qualcomm · LG · Fujitsu · Samsung · vivo6 companiesZTE · OPPO · Google · Futurewei · Huawei/HiSilicon · China Telecom · Ofinno · CATT · Nokia · Apple · ETRI · Panasonic12 companies
Why it matters

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.

Deferred
Enhancements of Network energy savings for NR
R1-2503004

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 proposalOpposed the moderator's 1-bit indicator proposal
CMCC · vivo · Spreadtrum · Fujitsu · Ericsson · Samsung · Qualcomm · LG8 companiesNokia · ZTE · Google · OPPO · Xiaomi · Futurewei · Huawei · Apple · ETRI · Panasonic · China Telecom11 companies
Why it matters

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
Quotations are verbatim from moderator summaries in the 3GPP archive. Document numbers link to the original files. Back to the full report.