5G power-saving cells will keep broadcasting system info on every beam
Huawei, ZTE and Qualcomm beat Samsung, Ericsson and vivo's push to restrict on-demand SIB1 to a single beam; the wake-up timer now starts at the end of the access-response window.
Source meetings for this article (7)
Meetings in this article’s source material. Inclusion does not mean that every meeting approved every decision.
- SA#10712 Mar 2025 – 14 Mar 2025 · Incheon · 3GPP ↗
- RAN#10712 Mar 2025 – 14 Mar 2025 · Incheon · 3GPP ↗
- RAN1#12017 Feb 2025 – 21 Feb 2025 · Athens · 3GPP ↗
- RAN4#11417 Feb 2025 – 21 Feb 2025 · Athens · 3GPP ↗
- RAN3#12717 Feb 2025 – 21 Feb 2025 · Athens · 3GPP ↗
- SA4#13117 Feb 2025 – 21 Feb 2025 · Geneva · 3GPP ↗
- RAN2#12917 Feb 2025 – 21 Feb 2025 · Athens · 3GPP ↗
Samsung, Ericsson, LG and vivo wanted 5G energy-saving cells to send system information only toward the phone that asked for it, cutting radio transmissions to a single beam. Huawei, ZTE, Qualcomm and Xiaomi blocked that, warning it would hurt reception reliability for phones that had moved or hadn't yet requested anything. The legacy rule — broadcast on every beam the cell uses — won, which keeps access reliable but caps how much power a base station actually saves by making system information on-demand in the first place.
The bigger, quieter win was timing. When a phone wakes up a power-saving cell and asks for SIB1 (the block carrying basic cell-access rules), it needs to know when to start listening for the reply. Apple, Samsung, Qualcomm, Huawei and ZTE argued the countdown should start at the end of the Random Access Response window, calling it the simpler, more obvious reference point; Ericsson, Nokia, Lenovo, DOCOMO and Google wanted the earlier starting slot to shave off latency. The end-of-window camp won, meaning phones will wait marginally longer for SIB1 in exchange for a cleaner, less ambiguous specification.
A parallel fight over signaling method went the same direction: MediaTek, Lenovo, ZTE, DOCOMO and Google pushed to fix the SIB1 monitoring offset inside the uplink wake-up signal configuration, in slot units, rather than let the network signal it per-request in the Random Access Response, as Apple, Ericsson, InterDigital and Samsung had wanted. The static approach won, trading away per-phone network flexibility for lower signaling overhead — a pattern that repeated for control-channel parameters (CORESET0, SearchSpaceZero), which Huawei, Qualcomm, Lenovo and 20 other companies agreed will always come from the wake-up signal configuration rather than sometimes from the Master Information Block, closing a case that CMCC, NEC and vivo had wanted to keep for overhead reasons.
Two proposals died outright. A joint request letting a phone fetch SIB1 and other on-demand system information in one message was ruled out of scope for this release, with Google, Samsung, Apple and Xiaomi among 19 companies against it and only Sharp in favor. Separately, a plan by Apple, Samsung, Ericsson and Huawei to repurpose reserved bits in the MIB to help phones locate a neighboring normal cell was dropped after Spreadtrum, vivo, Fujitsu and CATT questioned its benefit; the reserved field stays unused.
Several pieces are still loose, including whether the wake-up signal configuration should grow to carry a shared RA-RNTI (backed by Google and Fujitsu), cell-barring flags (Nokia, Samsung), RedCap parameters (vivo, Tejas) or uplink bandwidth data (Huawei, MediaTek). None of these was decided this quarter, and they will determine how large and capable that configuration message ultimately becomes.
The decisions behind this
On-demand SIB1 configuration will come from wake-up signal, not MIB, for sync-raster cells
For a phone to receive on-demand SIB1, it needs configuration parameters called searchSpaceZero and controlResourceSetZero, which tell it where and how to listen for the control channel. In standard 5G, these can sometimes be derived from the Master Information Block (MIB). For network energy saving cells whose sync signal is on a standard frequency raster, there was a debate on the source of this configuration.
A coalition including Huawei, Qualcomm, Ericsson, and Samsung proposed that these parameters should always be provided in the uplink wake-up signal (UL WUS) configuration, regardless of another technical value (K_SSB). They argued this removes ambiguity. Some companies, like CMCC, NEC, and vivo, opposed this, preferring that for certain K_SSB values, the MIB could be used to reduce configuration overhead. The meeting moderator noted the proposal but did not record a final decision. The reason for the decision is not recorded in the materials.
| Provide parameters in UL WUS configuration for all sync-raster cases | Use MIB for certain cases to reduce overhead |
|---|---|
| Huawei/HiSilicon · Qualcomm · Ericsson · Samsung · Apple · ZTE · InterDigital · Sony · Sharp · Panasonic · Xiaomi · Nokia/NSB · Futurewei · Lenovo · MediaTek · DOCOMO · Spreadtrum/UNISOC · Tejas · China Telecom · Transsion · CEWiT · ETRI · Fujitsu · DCM24 companies | CMCC · NEC · vivo3 companies |
If adopted, consistently using the UL WUS configuration simplifies phone behavior and specification design, ensuring phones get the correct listening instructions directly related to the on-demand procedure, though it may slightly increase the size of the wake-up signal configuration message.
Debate continues on whether on-demand SIB1 should be transmitted on all cell beams
When a phone requests SIB1 on a network energy saving (NES) cell, a question is whether the cell should transmit the SIB1 on all its broadcast beams (SSBs) or just on the beam associated with the phone's request. Transmitting on all beams is the legacy method for on-demand system information and ensures reliability for any phone. Transmitting only on the requested beam saves more network energy.
A group of companies including ZTE, Xiaomi, and Huawei proposed sticking with the legacy method where the "UE assumes that PDCCH for an on-demand SIB1 is transmitted in at least one PDCCH monitoring occasion corresponding to each transmitted SSB." Opponents like Samsung, Ericsson, LG, and vivo argued this wastes energy and proposed restricting transmission to the beam linked to the wake-up signal. The meeting moderator noted the lack of consensus and that no decision was made. The reason for the decision is not recorded in the materials.
The RAN1#120 meeting record records a partial agreement on this point: "The UE assumes that, in the OD-SIB1 window, PDCCH for an OD-SIB1 message is transmitted in PDCCH monitoring occasions corresponding to at least the SSB associated with the PRACH for UL-WUS if this is indicated via UL WUS configuration"
| Transmit on all beams (legacy method) | Transmit only on beam associated with the request |
|---|---|
| ZTE · Xiaomi · Huawei/HiSilicon · Qualcomm · Sony · NEC · Fujitsu · CATT · China Telecom · InterDigital · Google · Spreadtrum · Tejas · OPPO · Transsion · CMCC16 companies | Samsung · Ericsson · LG · vivo · CEWiT · Nokia/NSB · Futurewei · ETRI · Fraunhofer · DCM · Sharp11 companies |
The decision balances network energy savings against the reliability and robustness of the SIB1 delivery. Using only the requested beam maximizes energy savings but could potentially lower reception success for phones under certain conditions.
- DeferredNo consensus on where to signal the on-demand SIB1 window start timeR1-2501381
- DeferredProposal for on-demand SIB1 to follow legacy beam assumption fails to gain consensusR1-2501378
- DeferredOn-demand SIB1 timing will be based on the end of the RAR windowR1-2501381
- DeferredOn-demand SIB1 reference time will be based on the end of the RAR windowR1-2501378
- DeferredNo consensus on where to signal the SIB1 monitoring window start timeR1-2501378
- DeferredSIB1 configuration to be provided in WUS settings regardless of K_SSB valueR1-2501378