3GPP TSG RAN WG1 #120bis	R1-2501714
Wuhan, China, April 7th  – 11th , 2025
Agenda Item:	9.5.2
Source:	Futurewei
Title:	Discussion of on-demand SIB1 for idle/inactive mode UEs
Document for:	Discussion and decision 

Conclusions
In this contribution, we present our views on on-demand SIB1 for idle/inactive mode UEs. We have the following proposals.
Proposal 1: Leave to RAN2’s decision whether for NES cells always on SSB may be located off sync raster.
Proposal 2: The UE assumes that, in the OD-SIB1 window, PDCCH for an OD-SIB1 message is transmitted in one or more PDCCH monitoring occasions corresponding to the SSB associated with the PRACH for UL-WUS. No additional indication is necessary.
Proposal 3: After a UL WUS transmission is left for implementation whether UE monitors PDCCH on PDCCH monitoring occasion corresponding to SSB other than the SSB associated with the PRACH for UL-WUS.
Proposal 4: Support Alt.2: If a UE has SIB1 request configuration of a cell and before transmitting UL WUS, UE monitors Type 0 PDCCH for SIB1periodic transmission.

3GPP TSG RAN WG1 meeting #120-bis		                                   R1-2501765
Wuhan, China, Apr. 7th – Apr. 11th, 2025
Title: 	Discussion on on-demand SIB1 for NES
Source: 	ZTE Corporation, Sanechips
Agenda item:	9.5.2
Document for:	Discussion and decision

Conclusion
In this contribution, we have the following observations and proposals:
Observation 1:	Alt 3 and Alt 4 cannot guarantee that the UE will ascertain whether the SIB1 is currently being broadcasted or not. They are inconsistent with RAN2 agreements.
Observation 2:	Alt 2 may cause a large access delay and increase the UE power consumption.
Observation 3:	For Alt 1, using the value of K_SSB to indicate whether the SIB1 on the NES cell is currently broadcasting is beneficial for the UE power consumption with minimum specification impact.
Observation 4:	Repurposed parameters in MIB or PBCH is not the only solution for indicating whether on-demand SIB1 on NES cell is currently broadcasting
Observation 5:	Using UL WUS configuration indicate the SSB the UE can expect PDCCH transmission on may cause frequent WUS configuration updates.
Observation 6:	Periodic transmitted WUS configuration in the new SIB on the NES cell will prevent the gNB from achieving energy saving benefits.

Proposal 1:	Support Alt 1, i.e., Only if K_SSB=30 for FR1 and K_SSB=14 for FR2, UE monitors Type 0 PDCCH for SIB1 transmission; Otherwise, UE does not t monitor Type 0 PDCCH, for the behavior of a UE has SIB1 request configuration of a cell and before transmitting UL WUS.
Proposal 2:	Support the UE assumes PDCCH for OD-SIB1 is transmitted in at least one PDCCH monitoring occasion corresponding to each transmitted SSB.
Proposal 3:	Do not support indicating the SSB the UE can expect PDCCH transmission on in UL WUS configuration.
Proposal 4:	The selection of SSB for the reception of on-demand SIB1 is up to UE implementation.
Proposal 5:	The transmission of the updated SIB1 on the NES cell should be within a time window.
Proposal 6:	UE behavior on the overlapped resources between UL WUS in NES cell and paging occasions on cell A can be up to UE implementation.

3GPP TSG RAN WG1 Meeting #120bis	R1-2501773
Wuhan, China, April 7th – 11th, 2025

Agenda item:		9.5.2
Source:	Nokia, Nokia Shanghai Bell
Title:		On-demand SIB1 for Idle/Inactive mode UEs
Document for:		Discussion and Decision

Conclusions
In this contribution, we have the following observations and proposals:
Proposal-1: The time window for UE monitoring Type-0 PDCCH of OD-SIB1 can be either a newly specified OD-SIB1 monitoring window or the legacy RAR window.
Proposal-2: The value of the time offset between the reference time point and the starting time for the time window of UE monitoring Type-0 PDCCH of OD-SIB1 can be either 0, positive value, or negative value.
Proposal-3: For the case of the time offset value is 0, the UE monitoring window of Type-0 PDCCH of OD-SIB1 and RAR window can be either partially or fully overlapped.
Proposal-4: For the case of the time offset value is positive (>0), the UE monitoring window of Type-0 PDCCH of OD-SIB1 and RAR window can be either partially or no overlapped.
Proposal-5: For the case of the time offset value is negative (<0), the UE monitoring window of Type-0 PDCCH of OD-SIB1 and RAR window can be partially overlapped.
Proposal-6: RAN1 shall discuss the UE monitoring behavior when both RAR and Type-0 PDCCH of OD-SIB1 monitoring windows are applied.
Observation-1: It is not necessary for UE to always detect both RAR and Type-0 PDCCH of OD-SIB1, especially when both windows are overlapped.
Observation-2: In case when UE has successfully received the Type-0 PDCCH of OD-SIB1, the monitoring and reception of RAR by UE could simply be ignored, which also benefit for UE power saving.
Proposal-7: The monitoring and reception of RAR by UE could be ignored when UE has successfully received the Type-0 PDCCH of OD-SIB1.
Proposal-8: If configuration of SearchSpace#0 and CORESET#0 are fully overlapped for UE monitoring of RAR and Type-0 PDCCH of OD-SIB1, especially when both RAR and Type-0 PDCCH of OD-SIB1 windows are overlapped. RAN1 shall discuss the corresponding UE monitoring behavior.
Observation-3: The operation of UE requesting OD-SIB1 can base on a single window instead of two windows, where the legacy RAR window could be utilized for UE monitoring Type-0 PDCCH of OD-SIB1.
Observation-4: It simplifies the overall operation procedures as well as minimized the complexity of UE behavior of OD-SIB1 Type-0 PDCCH monitoring.  
Proposal-9: RAN1 to discuss the operation of UE requesting OD-SIB1 based on a single window, i.e. the monitoring occasions for UE monitoring of OD-SIB1 Type-0 PDCCH. 
Observation-5: It is understood that the PRACH preamble is common for all UEs with association to a SSB beam for the operation of OD-SIB1 requesting.
Observation-6: With the same configured PRACH resource occasion for requesting the OD-SIB1 in the UL WUS configuration for all UEs, the RA-RNTI is common for all the UEs as well.
Proposal-10: RAN1 confirms that the RNTI is common for all UEs for requesting of OD-SIB1 operation based on the common PRACH resource occasion configured in UL WUS configuration.
Observation-7: With the assumption of common preamble per SSB and common RNTI in mind, it allows a common RAR response to be interpreted/decoded by all UEs within a common RAR window, and different UEs may terminate its own RAR window after successfully received of one of the RARs transmitted within the common RAR window. 
Proposal-11: RAN1 to discuss the UE monitoring of OD-SIB1 that was earlier requested by other UEs before sending its own UL WUS for requesting SIB1.
Proposal-12: RAN1 to revise one of the agreements in RAN1#120 as following:
Agreement [RAN1#120]
If a UE has SIB1 request configuration of a cell and before transmitting UL WUS,
•	If the UE detects a SSB where K_SSB>=24 for FR1 or K_SSB>=1213 for FR2, down select from the following:
…..

…..

Proposal-13: Regarding the UE behavior for checking the NW status on OD-SIB1 transmission before transmitting UL WUS, we do not support Alt.1, Alt. 3 and Alt. 4.
Proposal-14: If a UE has SIB1 request configuration of a cell and before transmitting UL WUS, if the UE detects a SSB where K_SSB>23 for FR1 or K_SSB>11 for FR2, RAN1 to consider that NES UE monitors Type 0 PDCCH for SIB1 transmission.
Proposal-15: RAN1 to specify a UE monitoring window of Type 0 PDCCH (and/or RAR) before UL WUS transmission.
Proposal-16: RAN1 to discuss the applicable conditions for UE monitoring of Type 0 PDCCH (and/or RAR) before UL WUS transmission.
Proposal-17: If a UE has SIB1 request configuration of a cell and before transmitting UL WUS, if the UE detects a SSB where K_SSB>23 for FR1 or K_SSB>11 for FR2, RAN1 to discuss on how the NW indication to trigger NES UE to monitor Type 0 PDCCH for SIB1 transmission.
Observation-8: Practically, the SSB beam can be narrow, e.g. for UE with mobility and frequency range with FR2, where the UE can be very likely located at the beam-edge between two narrow SSB beams.
Proposal-18: To improve the reliability of UE reception of OD-SIB1, it is beneficial for gNB transmission of OD-SIB1 also in the neighbouring SSB beams of the SSB beam associated with the UL WUS transmission.
Proposal-19: gNB can indicate in the UL WUS configuration on which set of neighbouring SSB beams the OD-SIB1 are transmitted together with the SSB beam associated with the UL WUS transmission.
Proposal-20: RAN1 to discuss on how to indicate the set of neighbouring SSB beams with OD-SIB1 transmission.
Proposal-21: RAN1 discusses the time resources (slots, symbols) for Type 0 PDCCH monitoring occasions within the SIB1 transmission window, i.e. How UE to determine the slot number and symbols for OD-SIB1 monitoring occasions.
Proposal-22: RAN1 to consider that the monitoring occasions of Type0-PDCCH for OD-SIB1 shall be fully overlapped/aligned with monitoring occasions of Type0-PDCCH for broadcasting legacy/regular SIB1.
Proposal-23: In time domain location, there is no time offset between the OD-SIB1 and regular SIB1 transmission for better network energy saving.
Proposal-24: RAN1 to discuss OD-SIB1 repetition or periodicity indication from NW to UE within the OD-SIB1 monitoring window.
Observation-9: Based on TS38.212, UE is not expecting change of MIB payload within one MIB TTI of 80ms. 
Proposal-25: RAN1 to consider that the network switching between broadcasting SIB1 and on-demand SIB1 is at least 80ms via MIB indication, meaning that UE expects the same value of K_SSB within 80ms.

3GPP TSG-RAN WG1 Meeting #120bis                                                 R1-2501811
Wuhan, China, 07th – 11th April 2025
Source: 	vivo
Title:	On-demand SIB1 for idle/inactive mode UEs
Agenda Item:	9.5.2
Document for:	Discussion and Decision

Conclusion
In this contribution, on-demand SIB1 triggered by UL WUS is discussed in detailly and the following observations and proposals are summarized as follows:
Observation 1: In case1, i.e., SIB1 is not being broadcasted when UE meets cell reselection conditions, Alt 1 and Alt 5 have 10.5%~32% UE power saving gain and 80%~94.1% lower latency compared to Alt2.
Observation 2: In case2, i.e., SIB1 is being broadcasted when UE meets cell reselection conditions, Alt 1 and Alt 5 have 64.7% UE power saving gain and 61.7% NES gain compared to Alt4. 
Observation 3: Alt 1 and Alt 5 have the best UE power saving gain, NES gain and lowest latency compared to Alt2 and Alt4 considering all cases.
Observation 4: UE needs to distinguish whether the received WUS configuration applies to the serving cell or other NES cells.
Observation 5: For TDD system, offsetToPointA and kssb are present for DL point A and further derived UL point A. For FDD system, absoluteFrequencyPointA is present for UL transmission.
Observation 6: searchSpaceZero and controlResourceSetZero for on-demand SIB1 are provided from UL WUS configuration if SSB on NES cell is on sync raster.
Observation 7: The reference time point to determine the window starting time for on-demand SIB1 is based on the starting slot of the RAR window for UL WUS wherein UE successfully received a RAR.
Observation 8: If the starting time of Type 0 PDCCH monitoring is only determined by reference point rather than relevant to RAR for UL-WUS, it may lead UE to monitor SIB1 which possibly doesn’t exist at all.
Observation 9: The duration of the time window for on-demand SIB1 can be configured in WUS configuration.
Observation 10: Beam assumption may not change during OD-SIB1 procedure, which is different from OSI procedure.
Observation 11: If Redcap UE can know in advance whether the NES cell supports Redcap UE, it can avoid sending unnecessary UL-WUS as well as acquiring OD-SIB1, which is friendly to both network energy and UE power.
Observation 12: The LBT type can be configured in WUS configuration in advance for later LBT if NRU is supported for NES cell
Proposal 1: UE needs to check if SIB1 is currently being broadcasted or provided on demand before requesting SIB1 of that cell.
Proposal 2: Support Alt 1, i.e., only if KSSB =30 for FR1 and KSSB =14 for FR2, UE monitors Type 0 PDCCH for SIB1 transmission; Otherwise, UE doesn’t monitor Type 0 PDCCH.
Proposal 3: The design principle for WUS configuration is to minimize the size of mandatory parameters in WUS configuration as much as possible.
Proposal 4: If NES cell indicates a WUS configuration applying to NES cell itself, some parameters can follow the corresponding values in the SIB1 of NES cell itself to further reduce the payload of WUS configuration.
Proposal 5: Some parameters in WUS configuration can follow the value of the counterpart of cellA to further reduce the payload of WUS configuration.
Proposal 6: Add offsetToPointA into WUS configuration to avoid changing the legacy mechanism in deriving UL point A in TDD system.
Proposal 7: ra-PreambleStartIndex, od-sib1-duration, offsetToTimeWindow and ssb-SubcarrierOffset is mandatorily configured in WUS configuration from RAN1 perspective.
Proposal 8: Considering the time requirements for RAR reception, RAR decoding and preparation for monitoring, UE starts actual Type 0 PDCCH monitoring from the later one between X time units after RAR reception and offsetToTimeWindow slots after reference point.
Proposal 9: UE stops monitoring Type 0 PDCCH at the end of time window for on-demand SIB1, and the time window for on-demand SIB1 starts at offsetToTimeWindow slots after reference point.
Proposal 10：Further clarify the UE behaviours if OD-SIB1 is transmitted in PDCCH monitoring occasions corresponding to at least the SSB associated with the PRACH for UL-WUS is not indicated in WUS configuration.
Proposal 11：Not support the first FFS since beam assumption may not change for OD-SIB1 procedure. And network energy will be wasted if OD-SIB1 is transmitted in PDCCH monitoring occasion corresponding to each transmitted SSB.
Proposal 12：Not support the second FFS since the base station may not know under which SSBs the UE is located in.
Proposal 13: Whether some other features such as RedCap and NRU can be combined with OD-SIB1 needs discussion.

3GPP TSG RAN WG1 #120	bis                                            R1-2501873
Wuhan, China, 07th – 11th April 2025
Agenda Item:	9.5.2
Source:	Spreadtrum, UNISOC
Title: 	Discussion on on-demand SIB1 for idle/inactive mode UEs
Document for:	Discussion and decision

Conclusion
We have the following observations and proposals.
For SSB on sync raster case, support Alt 1 to indicate UE whether OD-SIB1 is broadcasting or not:
Alt. 1: Only if K_SSB=30 for FR1 and K_SSB=14 for FR2, UE monitors Type 0 PDCCH for SIB1 transmission; Otherwise, UE doesn’t monitor Type 0 PDCCH.
It is up to network implementation whether to transmit OD-SIB1 in one or more beams.
It is unnecessary for gNB to indicate the SSB the UE can expect PDCCH transmission on in UL-WUS configuration.
Don’t support additional contents in RAR for OD-SIB1 other than contents of RAR for SI request.

3GPP TSG RAN WG1 #120bis		R1-2501953
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.5.2
Source:	Google
Title:	On-demand SIB1 for idle/inactive mode UE
Document for:	Discussion/Decision

Conclusion
In this contribution, we provided discussion on on-demand SIB1. Based on the discussion, the following proposals are provided.
Proposal 1: Support to configure an initial downlink BWP by the UL-WUS configuration
The NW can transmit the RAR and on-demand SIB1 based on the bandwidth of the initial downlink BWP
Proposal 2: Support the UE to select the RO based on the SSB with lowest index among the SSBs that can meet the rsrp-ThresholdSSB requirement.
Proposal 3: If the UE cannot identify any SSB with RSRP higher than rsrp-ThresholdSSB, it should not transmit the PRACH for on-demand SIB1.
Proposal 4: Do not support additional content in the RAR for on-demand SIB1. 
Proposal 5: If UE detects a SSB where K_SSB>=24 for FR1 or K_SSB>=13 for FR2, support Alt1
Alt. 1: Only if K_SSB=30 for FR1 and K_SSB=14 for FR2, UE monitors Type 0 PDCCH for SIB1 transmission; Otherwise, UE doesn’t monitor Type 0 PDCCH
The monitoring time window of Type 0 PDCCH is configured by UL-WUS

3GPP TSG RAN WG1 #120bis                                           R1-2501997
Wuhan, China, April 7th – 11th, 2025

Source: 	CATT
Title:	Discussion on on-demand SIB1
Agenda Item:	9.5.2
Document for:	Discussion and Decision

Conclusion
In this contribution, the potential spec impacts for on-demand SIB1 are provided. The observations and proposals are summarized as follows:
Observation 1: If a Rel-19 UE with on-demand SIB1 capability does not receive UL WUS configuration before detecting the SSB of the NES cell, the UE cannot identify the NES cell by option 1, i.e. NES cell identification by UL WUS configuration.
Observation 2: Regardless of whether Rel-19 UE receives UL WUS configuration before detecting the SSB of NES cell, the UE can directly identify the NES cell based on the PBCH payload of the NES cell.
Observation 3: If NES cell transmits SSB and the SSB is with 23< kSSB <30 for FR1 and 11< kSSB <14 for FR2, legacy UEs will try to find a CD-SSB based on the pdcch-ConfigSIB1 indication.
Observation 4: In current on-demand OSI, UE assumes that the PDCCH for an SI message is transmitted in at least one PDCCH monitoring occasion corresponding to each transmitted SSB.
Proposal 1: For on-demand SIB1, at least option 2 (i.e. PBCH payload of NES cell) is supported for UE identification of NES cell.
Proposal 2: To comply with RAN2 agreement, NES cell needs to indicate whether SIB1 is currently being transmitted (due to UL WUS request or SIB1 update), or it is not currently being transmitted and thus should be requested by UL WUS.
Proposal 3: For on-demand SIB1, the kSSB in PBCH payload of NES cell should support identifying the SIB1 transmission states, i.e. SIB1 is being broadcasted or SIB1 is not being broadcasted thus it can be requested by UL WUS.
Proposal 4: If NES cell transmits SSB and the kSSB = 30 for FR1 or kSSB = 14 for FR2, on demand SIB1 is currently being broadcasted.
Proposal 5: Do not mandate gNB transmission of on-demand SIB1 only with the association with SSB(s) based on a received UL-WUS, i.e. no change to the legacy UE behavior.
Proposal 6: The gNB do not indicate (in UL-WUS configuration) the SSB the UE can expect PDCCH transmission on.
Proposal 7: If a UE has SIB1 request configuration of a cell and before transmitting UL WUS,
If the UE detects a SSB where K_SSB>=24 for FR1 or K_SSB>=13 for FR2, support Alt. 1:
Alt. 1: Only if K_SSB=30 for FR1 and K_SSB=14 for FR2, UE monitors Type 0 PDCCH for SIB1 transmission; Otherwise, UE doesn’t monitor Type 0 PDCCH
The monitoring time window of Type 0 PDCCH should be specified.
Proposal 8: A UE may fail to receive on-demand SIB1 when it detects a SSB at the end of the on-demand SIB1 transmission window due to insufficient remaining time in the SIB1 time window. RAN1 should consider enhancement mechanisms to avoid this case.
Proposal 9: When the NES cell is in NES state without periodic SIB1 transmission and UE receives SI change indication or etwsAndCmasIndication, the following UE behaviors can be considered.
Alt 1: If a UE receives SI change indication or the etwsAndCmasIndication bit of Short Message is set, the UE assumes that the NES cell switches from ”SIB1 is provided on demand” to ”SIB1 is currently being broadcasted”.
Alt 2: If a UE receives SI change indication, the UE assumes that the updated SIB1 will be transmitted within a time window starting from the next modification period.
Alt 3: If a UE receives Short Message at its PO and the etwsAndCmasIndication bit of Short Message is set, the UE re-acquire the SIB1 within a time window after its PO.
Proposal 10: How to ensure the validity of UL WUS configuration received from cell A should be studied.

3GPP TSG RAN WG1 #120-bis		R1-2502027
Wuhan, China, April 7th – 11th, 2025
Agenda Item:	9.5.2
Source:	China Telecom
Title:	Discussion on on-demand SIB1 for idle/inactive mode UEs 
Document for:	Discussion and Decision

Conclusion
In this paper, we discuss on-demand SIB1operation and have the following observations and proposals.
Proposal 1: Support Option 3, i.e., It is up to UE implementation on whether to monitor Type 0 PDCCH for SIB1.
Proposal 2: Support configuring K_SSB=30 for FR1 and K_SSB=14 for FR2 to indicate UE there is periodically SIB1 broadcasted on NES Cell.  
Proposal 3: Do not support additional contents to RAR in response to UL WUS on top of contents of RAR in response to SI request.

3GPP TSG RAN WG1 #120bis	R1-2502045
Wuhan, China, April 7th – April 11th, 2025

Agenda item:		9.5.2
Source:				Ofinno
Title:					Discussion on on-demand SIB1 for idle/inactive mode UEs
Document for:		Discussion and Decision

Conclusion
This contribution has discussed the remaining issues related to the on-demand SIB1 transmission for UEs in idle/inactive modes. The following are our proposals: 
Proposal 1: Maintain the same UE assumption to legacy SIB1 transmission within OD-SIB1 window: “The UE assumes that, in the OD-SIB window, PDCCH for an OD-SIB1 is transmitted in at least one PDCCH monitoring occasion corresponding to each transmitted SSB and thus the selection of SSB for the reception OD-SIB1 messages is up to UE implementation”. 
Proposal 2. Support Alt 2 with a minimum requirement that a UE should monitor at least one Type0 PDCCH occasion before sending UL-WUS.
Proposal 3. Support an indication, in RAR, on not accepting request of OD-SIB1. 
Proposal 4: If a paging occasion (PO) on Cell A and OD-SIB1 procedures (e.g., a WUS transmission, RAR window, or OD-SIB1 window) in an NES cell collide/overlap with each other, then the UE is allowed to skip the PO and perform OD-SIB1 procedure on NES cell.

3GPP TSG RAN WG1 #120bis	R1- 2502128
Wuhan, China, April 7th – 11st, 2025	

Agenda Item:	9.5.2
Source: 	Fujitsu
Title:	Discussion on on-demand SIB1 transmission for network energy savings
Document for:	Discussion/Decision

Conclusions
In this contribution, we discussed on-demand SIB1 for UEs in idle/inactive. The following observations and proposals are provided.
Proposal 1. 1-bit indication can be included in UL WUS configuration to indicate whether the type 0 PDCCH for on-demand SIB1 is transmitted using the SSB beam associated with UL WUS or each transmitted SSB beams.
Proposal 2. The UE assumption and the UE behavior on PDCCH monitoring are as follows
If the 1-bit indication is included, the UE assumes that the PDCCH for on-demand SIB1 is transmitted via at least the SSB beam associated with UL WUS.
The UE monitors on the type 0 PDCCH monitoring occasions corresponding to the SSB associated with UL WUS.
If not, the UE assumption is the same as legacy, i.e., the PDCCH for on-demand SIB1 is transmitted via each transmitted SSB beam. 
It is up to UE implementation for the selection of SSB for type 0 PDCCH monitoring.
Proposal 3. RAN1 to discuss the UE assumption on on-demand SIB1 repetitions within the time window. The following two alternatives can be considered.
Alt 1. UE assumes that the SIB1 transmitted within the time window are all repetitions
Alt 2. UE assumes that the SIB1 transmitted within the time window follows the mechanism of repetition within a 160 ms period
Proposal 4. The time offset to determine the starting time of the time window for type 0 PDCCH monitoring of on-demand SIB1 is indicated by ra-ResponseWindow in UL WUS configuration. 
Observation 1. Since the network can choose to transmit on-demand SIB1 only via the SSB beam associated with UL WUS, not all the PDCCH occasions corresponding to the actual transmitted SSB indexes will have PDCCH transmitted on them. 
Proposal 5. The time window for on-demand SIB1 starts at the first type 0 PDCCH monitoring occasion after the time offset ends. Regarding the first type 0 PDCCH monitoring occasion, the following three options can be considered.
Option 1. the type 0 PDCCH occasion corresponds to SSB index 0
Option 2. the type 0 PDCCH occasion corresponds to the first SSB index of the transmitted SSBs
Option 3. the type 0 PDCCH occasion corresponds to the SSB index associated with the transmitted UL WUS
Note: the above options refer to the type 0 PDCCH occasion in the first slot for corresponding SSB indexes in the case of multiplexing pattern 1.
Observation 2. If UE knows that on-demand SIB1 is being transmitted due to other UE’s UL WUS signal(s), it can directly acquire SIB1 without transmitting UL WUS, which helps to avoid unnecessary UL WUS transmission.
Observation 3. 
By changing the kSSB value or repurposing a MIB parameter, the gNB may not be able to notify the UE in time about the switch of SIB1 transmission state, given that the MIB period is 80 ms.
Regarding the approach of repurposing a parameter in PBCH payload generated by the PHY layer, there may be no parameter/bit available for repurposing. 
Proposal 6. If a UE has SIB1 request configuration of a cell and before transmitting UL WUS,
If the UE detects a SSB where K_SSB>=24 for FR1 or K_SSB>=13 for FR2, support Alt 2 or Alt 3. 
Alt. 2: UE monitors Type 0 PDCCH for SIB1 transmission
The monitoring time window of Type 0 PDCCH is up to UE implementation.
Alt. 3: It is up to UE implementation on whether to monitor Type 0 PDCCH for SIB1 transmission

3GPP TSG RAN WG1 #120-bis	R1-2502165
Wuhan, China, April 7th–April 11th, 2025

Source: 	CMCC
Title:	Discussion on on-demand SIB1 for UEs in idle/inactive mode
Agenda item:	9.5.2
Document for:	Discussion & Decision

Conclusions
In this contribution, we provide our views on UE behavior for SIB1 reception and specific content in RAR. The proposals are listed as below.
Proposal 1: When a UE has SIB1 request configuration of a cell and before transmitting UL WUS and detects a SSB where K_SSB>=24 for FR1 or K_SSB>=13 for FR2, support Alt. 2 (UE monitors Type 0 PDCCH for SIB1 transmission) and the monitoring time window of Type 0 PDCCH is up to UE implementation.

Proposal 2: For spatial domain behavior on SIB1 reception, support the following:
The UE only monitors SIB1 on the SSB beam direction that is associated with the transmitted UL WUS.
The UE monitors SIB1 on the SSB beam direction that is configured by gNB (e.g. via WUS configuration).

Proposal 3: For the specific content in RAR, support one of the followings:
Do not support to include other parameter in RAR.
Up to RAN2 discussion to decide whether other parameter is included in RAR, and how to deal with the potential misalignment for legacy UE.

3GPP TSG RAN WG1 #120bis	R1-2502199

Wuhan, China, April 7th – 11th, 2025	

Agenda item:	9.5.2
Source:	NEC
Title:	Discussion on on-demand SIB1 for UEs in Idle/Inactive mode
Document for:	Discussion 

Conclusion
From the discussion, we have the following observations and proposals:
Proposal 1: 	Support Alt. 2: UE monitors Type 0 PDCCH for SIB1 transmission. RAN1 to further consider the following options for time duration of Type 0 PDCCH monitoring 
The monitoring time window is specified by the network.
UE monitors Type 0 PDCCH for SIB1 transmission at least for a duration of 160ms

Proposal 2:	If WUS resources are configured independent of PRACH resources for other usages, discuss the cases of time and/or frequency overlap of WUS resources and RACH resources for other usages.

Proposal 3:	Support PRACH transmission based on only Type-1 random access procedure for WUS. 

Proposal 4:	WUS response message from the network shall not include UL grant, timing advance command or Temporary C-RNTI. Discuss the applicability of RAPID depending on whether the WUS response message also includes response for other RACH resources.

Proposal 5:	RAN1 to study DCI based WUS response from the network. 

Proposal 6: WUS response message may contain the information on the time offset between the reference time point and the starting time for the time window of on-demand SIB1.

Proposal 7: The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity).


Proposal 8: No restriction on the PDCCH monitoring occasions that the UE monitors, such as to the SSBs associated with the PRACH for UL-WUS. 

3GPP TSG-RAN WG1 Meeting #120bis	R1-2502230
Wuhan, China, April 7 - 11, 2025
 
Agenda item:		9.5.2
Source:		Huawei, HiSilicon
Title:		Discussion on on-demand SIB1 for eNES
Document for:		Discussion and Decision

Conclusions
The paper discussed how to design on demand SIB1, with the following observations and proposals:

For the UE with WUS configuration, the term  in the PRACH baseband signal generation of section 5.3.2 of TS38.211 is not known if  is not included in the UL WUS configuration. 

The reference time point to determine the starting slot of on-demand SIB1 window is the slot containing the starting symbol of RAR window.
The start of the OD-SIB1 window is at least one symbol after the UL WUS transmission.
For PRACH baseband signal generation of section 5.3.2 of TS38.211, CarrierBandwidth is included in the UL-WUS configuration to enable the UE to calculate k1. Otherwise, RAN1 clarifies how the UE determines .
For initial uplink BWP related parameters, initial uplink BWP configuration is included in UL WUS configuration. Otherwise, RAN1 clarifies how to determine the initial UL BWP and how to ensure the center frequency alignment for TDD.
RAN1 clarifies frequencyBandList in UL WUS configuration refers to the IE within FrequencyInfoUL-SIB.
Search space configuration provided by the IE of SearchSpace is included in the UL WUS configuration to configure the RAR search space. If not included, the RAR search space is the Search Space 0.
ControlResourceSetId in SearchSpace IE is 0.
For the RAR search space configured by ra-SearchSpace in PDCCH-ConfigCommon in SIB1 and the RAR search space configured by UL WUS configuration, RAN1 discusses whether they should be the same or can be different. 
If a UE has SIB1 request configuration of a cell and before transmitting UL WUS, if the UE detects an SSB where K_SSB>=24 for FR1 or K_SSB>=12 for FR2, prefer one of
Alt. 2: UE monitors Type 0 PDCCH for SIB1 transmission
Alt. 3: It is up to UE implementation on whether to monitor Type 0 PDCCH for SIB1 transmission.
After transmitting an UL-WUS, UE expects that PDCCH for an on-demand SIB1 is transmitted in at least one PDCCH monitoring occasion corresponding to each transmitted SSB (same as legacy on-demand OSI).
The selection of SSB for the reception of SIB1 messages is up to UE implementation.

3GPP TSG RAN WG1 #120bis		R1-2502262
Wuhan, China, April 7th – 11th, 2025

Source:	OPPO
Title:	Discussion on the enhancement to support on demand SIB1 for idle/inactive mode UE
Agenda Item:	9.5.2
Document for:	Discussion and Decision

Conclusion
In this document, we continue studying designs for on demand SIB1 mechanisms. The observations and proposals are summarized below:
Proposal 1: 	To check SIB1 broadcast status, for the case where SIB1 is being broadcast triggered by 	UL-WUS request and in the case where SIB1 is being broadcast in SI modification period 	due to SI message update, down-select from the following options:
Option 1: K_SSB can be reset by the network 
Option 1-1: K_SSB is reset to K_SSB=30 for FR1 and K_SSB=14 for FR2
Option 1-2: K_SSB is reset to K_SSB<=23 for FR1 or K_SSB<=12 for FR2
Option 2: K_SSB cannot be reset by the network
Option 2-1: UE monitors Type 0 PDCCH for SIB1 transmission (Alt.2 from RAN1#120 agreement)
Option 2-2: Use PBCH to inform UE SIB1 is being broadcast (Alt.5 from RAN1#120 agreement)

Proposal 2: 	For time window configuration and determination, the following restrictions should be 	discussed:
If  SIB1 being broadcast in time window will provoke a change of K_SSB value, the time window should be aligned with SI modification period.
If  SIB1 being broadcast in time window will provoke a change of PBCH payload, the time window should be aligned with 80 ms MIB period.

Proposal 3: 	RAN1 to discuss the UE behavior for case Cell A switching to NES Cell. 

                   

3GPP TSG RAN WG1#120bis	        	R1-2502321
Wuhan, China, April 7th – 11th, 2025

Agenda Item:					    9.5.2
Source:	Sony
Title:	On-demand SIB1 for idle/inactive mode UEs
Document for:	Discussion

Conclusions
The following proposals were made in this contribution.
Proposal 1: If Rel-19 NES-capable UE has SIB1 request configuration of a cell and before transmitting UL WUS, Alt. 2 (UE monitors Type 0 PDCCH for SIB1 transmission if the UE detects a SSB where K_SSB>=24 for FR1 or K_SSB>=12 for FR2) should be selected.
Proposal 2: The transmission time of the on-demand SIB1 on the NES cell should be restricted into one time window.

3GPP TSG RAN WG1 #120bis		                                      R1-2502335 
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.5.2
Source:	InterDigital Inc.
Title:	Discussion on on-demand SIB1 for idle/inactive mode UEs
Document for:	Discussion 

Conclusion
In this contribution, the following proposals are made:
Proposal 1: UE does not expect PDCCH for OD-SIB1 in the PMO corresponding to the SSB beams other than the beam used for UL-WUS 
Proposal 2: Indication in UL-WUS configuration on the corresponding SSB beam in UE can expect PDCCH for OD-SIB1 is not supported 
Proposal 3: For selecting SSB from NES cell for OD-SIB1 request, UE can select any SSB if none of the measured SSBs are above the RSRP threshold (per legacy)   
Proposal 4: Support UE monitoring Type 0 PDCCH for SIB1 transmission (Alt. 2) before transmitting UL-WUS to the NES cell       
Appendix: Agreements on OD-SIB1 in Idle/Inactive mode
RAN1#120 Agreements

RAN1#119 Agreements

RAN1#118bis Agreements

RAN1#118 Agreements

RAN1#117 Agreements

RAN1#116bis Agreements

RAN1#116 Agreements

3GPP TSG RAN WG1 #120bis	R1-2502373
Wuhan, Hubei, China, April 7th – 11th, 2025
Agenda item:	9.5.2
Source:	Samsung
Title:	On-demand SIB1 for idle/inactive mode UEs
Document for:	Discussion and decision

Conclusion
In this contribution, we discussed details on supporting on-demand SIB1 operation for UEs in idle/inactive mode. The following proposals were made:
Proposal 1: Support Alt. 4 to inherit legacy UE behavior without any RAN1 spec impact.
Proposal 2: RAN1 further studies the UE behavior and whether/how to indicate one or more PDCCH monitoring occasion: 
Option 1: Actual transmitted SSB based PDCCH monitoring occasion indication.
FFS: 1 bit or N bit indication
Option 2: SSB-RO mapping based PDCCH monitoring occasion indication.
Without any additional parameter in UL WUS configuration
Option 3: Up to implementation.
Proposal 3: Support the following additional RRC parameters in UL WUS configuration to configure UL WUS resource and generate UL WUS signal as legacy:
locationAndBandwidth and cyclicPrefix for the initial BWP including UL WUS transmission


References:
RP-242354, “Revised WID: Enhancements of network energy savings for NR”
Chairman’s notes, RAN1#120, February 2025.
Chairman’s notes, RAN2#127bis, October 2024.

3GPP TSG RAN WG1 #120bis			R1-2502446
Wuhan, China, April 7th – 11th, 2025

Agenda item:	9.5.2
Source:	Xiaomi
Title:	Discussion on on-demand SIB1 for Idle/Inactive mode UEs
Document for:	Decision

Conclusion
In this contribution, we provide our views on on-demand SIB1. We have the following proposals:
Proposal 1:  UE can camp on NES cell following current cell selection/reselection procedure.
Proposal 2: NES capable UE keeps NES cell supporting on-demand SIB1 in its serving cell list if it doesn’t obtain SIB1 on it before request.
Proposal 3: For parameters agreed for UL WUS, they are mandatory.
Proposal 4: For associated SSB(s) for on-demand SIB1 transmission, UE expects PDCCH on PDCCH monitoring occasion corresponding to SSB other than the one associated with PRACH for UL-WUS.
Proposal 5: If UE has obtained UL WUS configuration and before transmitting UL WUS, it is up to UE implementation on whether to monitor Type 0 PDCCH for SIB1 reception. 

3GPP TSG RAN WG1 #120-bis			R1-2502469
Wuhan, China, April 17th – 21, 2025
Agenda item: 	9.5.2
Source: 	Tejas Networks Ltd
Title:	On On-demand SIB1 for IDLE/INACTIVE mode UEs
Document for:	Discussion and Decision
 

Conclusion

Alt:1 will increase the NES UE access latency, when NES UE does not have a valid UL-WUS configuration. This is because NES UE has to find the CELL-A SSB location by blind search, instead of using a GSCN offset (Indicated by K_SSB of the NES CELL) value to identify the CELL-A SSB location.

For Alt2: Power consumption due to blind decoding of PDCCH by UE for OD-SIB1 will be more under low and medium load scenarios.

Supporting Alt-5, UE monitors Type 0 PDCCH for SIB1 based on some repurposed parameters in MIB or PBCH.
 Spare bit in the MIB can be repurposed to indicate the UE that, whether it can monitor Type 0 PDCCH for SIB1 transmission or not.

NES CELL is expected to give good coverage as the CELL range could be less as compared to the CELL-A. Hence transmission of SIB1 message in PDCCH monitoring occasions corresponding to the SSB associated with the PRACH for UL-WUS is sufficient.
Not supporting the transmission of SIB1 message in PDCCH monitoring occasions corresponding to SSB not associated with the PRACH for UL-WUS.

Include TotalNumberOfRA-Preambles in the UL-WUS configuration.

3GPP TSG RAN WG1 #120bis			                  R1- 2502479
Wuhan, China, April 7th – 11st, 2025

Agenda Item:	9.5.2
Source: 	LG Electronics
Title: 	On-demand SIB1 for idle/inactive mode UEs
Document for:	Discussion and decision

Conclusions
In this contribution, on-demand SIB1 procedure for idle/inactive mode UEs was discussed, and the followings were proposed.
Proposal #1: For NES Cell selection, consider the following two methods.
Method #1: gNB’s explicit indication of NES Cell(s) from UL WUS configuration
Method #2: UE’s determination based on DL signal reception quality measured by SSB on NES Cell
Proposal #2: Support Alt 1 (If the UE detects SSB where K_SSB=30 for FR1 and K_SSB=14 for FR2, UE monitors Type 0 PDCCH for SIB1 transmission) or Alt 2 (If the UE detects a SSB where K_SSB>=24 for FR1 or K_SSB>=13 for FR2, UE monitors Type 0 PDCCH for SIB1 transmission), where the UE decides whether to transmit UL WUS after monitoring type 0 PDCCH for SIB1 transmission during the monitoring time window configured by the gNB before requesting SIB1 from the NES cell.
If the UE fails to receive SIB1 PDCCH for the monitoring time window, it transmits UL WUS.
If the UE succeeds to receive SIB1 PDCCH, it expects that SIB1 will be transmitted for a time window. FFS how to define the time window 
Proposal #3: After a UE transmits UL WUS for a NES cell and SIB1 PDCCH is detected before the RAR is received, the UE considers OD-SIB1 procedure as successful.
Proposal #4: To support UEs to monitor the RAR for SIB1 requests sent by other UEs, the following two methods can be considered:
1) UE monitors DCI scrambled by RA-RNTI which is associated with RO allocated for on-demand SIB1 but not associated with RO containing PRACH transmitted by UE 
2) Introduce a new RNTI (i.e., cell-specific or beam-specific RNTI) to monitor RAR corresponding to UL WUS for requesting SIB1
3) Use only PDCCH (i.e., without RAR MAC CE) as the RAR where the PDCCH contains RAPID directly
Proposal #5: Clarify whether the time window of OD-SIB1 starts immediately after the time offset from the reference time point or it starts from the OD-SIB1 MO (i.e., Type 0 PDCCH MO) corresponding to SSB index associated with UL WUS transmitted by the UE. 
Proposal #6: Support gNB to provide the SSB index(es) for which SIB1 is currently being transmitted in the NES Cell through the UL WUS configuration. If received quality for provided SSB index(es) is above threshold, UE can receive SIB1 in NES cell without UL WUS transmission. Otherwise, UE should transmit UL WUS to request SIB1 on NES Cell.
Proposal #7: Discuss how to guarantee on-demand SIB1 transmission while the UE receives SIBx (other than SIB1) or performs the existing on-demand SI procedure.

3GPP TSG RAN WG1 #120bis                                       R1-2502514
Wuhan, China, April 7th – 11th, 2025
Source: 	ETRI
Title:	On-demand SIB1 for idle/inactive mode UEs
Agenda Item:	9.5.2   On-demand SIB1 for idle/inactive mode UEs
Document for:	Discussion/Decision

Conclusion
In this contribution, we discuss our views on enhancements for on-demand SIB1 transmission for idle/inactive mode UEs, from which the following proposals are drawn:
Proposal 1: For the OD-SIB1 window configuration, down-select from the following two alternatives:
Alt. 1: UE expects at least one Type 0 PDCCH monitoring occasion within OD-SIB1 window.
Alt. 2: Up to gNB implementation
Proposal 2: Revise the previous agreement as follows (unless its meaning is clarified):
Agreement (RAN1#120)
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
Proposal 3: The RAR window length for Type 1 PDCCH monitoring after transmitting UL WUS is either provided via UL WUS configuration or predefined.
Proposal 4: If a UE has SIB1 request configuration of a cell and before transmitting UL WUS, if the UE detects a SSB where K_SSB>=24 for FR1 or K_SSB>=13 for FR2, it is up to UE implementation on whether to monitor Type 0 PDCCH for SIB1 transmission (Alt. 3).
Proposal 5: For agreed UL WUS parameters, follow the legacy specification regarding its mandatory or optional presence unless otherwise agreed.
Proposal 6: For agreed UL WUS parameters, regarding their mandatory or optional presence and applicability to TDD and/or FDD, adopt the followings:
PhysCellId and ARFCN-ValueNR are mandatory
frequencyBandList and absoluteFrequencyPointA are present in IE FrequencyInfoUL only for FDD (as in the legacy specification)
K_SSB is mandatory
searchSpaceZero and controlResourceSetZero are mandatory (at least for the agreed K_SSB values)
Duration of OD-SIB1 window is optional (as in the legacy OD-OSI specification)
Proposal 7: If the broadcast status of SIB1 is introduced, study the following UE behaviors in RRC connected mode:
When SIB1 is set to ‘broadcasting’, UE releases the UL WUS resource if it was previously configured
When SIB1 is set to ‘notBroadcasting’, UE assumes that the UL WUS resource remains available – either for itself or for other UEs in RRC idle/inactive mode within the same cell.

3GPP TSG RAN WG1 #120bis		                        R1-2502543
Wuhan, China, April 7th -11th, 2025
Source: 	Transsion Holdings
Title:	Discussion on on-demand SIB1 transmission for idle/inactive mode UEs
Agenda item:	9.5.2
Document for:	Discussion & Decision

Conclusions
In this contribution, some views for UEs in RRC idle/inactive mode to support on-demand SIB1 transmission are discussed, and the following proposals are made.
Proposal 1  The contents of RAR in response to SI request follows legacy operation.
Proposal 2  When K_SSB is not equal to 30 in FR1 and K_SSB is not equal to 14 in FR2, pdcch-ConfigSIB1 in the MIB can be repurposed to provide the GSCN for the SSB of cell A.
Proposal 3  UE assumes that PDCCH for OD-SIB1 message is transmitted not only PDCCH monitoring occasion corresponding to the SSB associated with the transmitted UL WUS, but also in PDCCH monitoring occasion corresponding to other SSBs.
Proposal 4  The status of SIB1 can be divided into three types: broadcast, on-demand transmission requested by other UEs, and on-demand transmission without any UE request. 

3GPP TSG RAN WG1 #120bis	R1-2502570
Wuhan, China, April 7th – 11th, 2025
Agenda item:	9.5.2
Source: 	Lenovo
Title: 	On-demand SIB1 for idle/inactive mode UEs
Document for:	Discussion and Decision

Conclusion
In summary, we have following proposal for on-demand SIB1:
Proposal: From RAN1 perspective, if a UE has SIB1 request configuration of a cell, and if the UE has detected a SIB1 transmission, the UE shall not request SIB1 for the cell.
Note: It is up to UE implementation whether to monitor SIB1 before SIB1 request (i.e., Alt.3 is supported)
Send LS to RAN2

3GPP TSG RAN WG1 #120bis	                                                  R1-2502579
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.5.2
Source:	Panasonic
Title:	Discussion on on-demand SIB1 for idle/inactive mode UEs
Document for:	Discussion/Decision

Conclusion
There is no RAN1 consensus to support the following in Rel-19:
Support joint PRACH request to trigger both OD-SIB1 and a subset of OD-OSI, e.g. SIB2/SIB3/SIB4.  
FFS: parameters in UL-WUS config to support joint PRACH request.

Agreement
If a UE has SIB1 request configuration of a cell and before transmitting UL WUS,
If the UE detects a SSB where K_SSB>=24 for FR1 or K_SSB>=13 for FR2, down select from the following:
Alt. 1: Only if K_SSB=30 for FR1 and K_SSB=14 for FR2, UE monitors Type 0 PDCCH for SIB1 transmission; Otherwise, UE doesn’t monitor Type 0 PDCCH
FFS: Whether monitoring time window of Type 0 PDCCH is up to UE implementation or specified.
Alt. 2: UE monitors Type 0 PDCCH for SIB1 transmission
FFS: Whether monitoring time window of Type 0 PDCCH is up to UE implementation or specified.
Alt. 3: It is up to UE implementation on whether to monitor Type 0 PDCCH for SIB1 transmission
Alt. 4: UE doesn’t monitor Type 0 PDCCH for SIB1 transmission.
Alt. 5: UE monitors Type 0 PDCCH for SIB1 based on some repurposed parameters in MIB or PBCH
Note: If the UE detects a SSB where K_SSB<=23 for FR1 or K_SSB<=12 for FR2, UE monitors Type 0 PDCCH for SIB1 transmission as legacy.
Note: From Ericsson point view, Alt 3 and Alt 4 may be inconsistent with existing RAN2 agreements
Note: The above cases are for SSB on the sync raster.

3GPP TSG RAN WG1 #120bis							   R1-2502613
Wuhan, China, April 7th – 11th , 2025

Agenda item: 	9.5.2
Source: 	Apple
Title:	On On-demand SIB1 for IDLE/INACTIVE mode UEs
Document for:	Discussion/Decision
 

Conclusion
In this contribution, the following proposals are made:
Proposal 1: SSB on NES cell is always on sync-raster, to avoid requiring IDLE/INACTIVE UEs measuring on SSBs off-sync-raster.
Proposal 2: Confirm that even after the start time of the OD-SIB1 monitoring window, UE is not required to monitor PDCCH in search space zero before UE successfully received its RAR.  
Proposal 3: Considering the spec impact, Support Alt 4: UE does not monitor Type 0 PDCCH before sending UL WUS when UE detects an SSB on NES cell with K_SSB>=24 for FR1 or K_SSB>=13 for FR2.

Observation 1: For an NES cell which is indicated to transmitting OD-SIB1 only on the SSB associated with the PRACH for UL-WUS sent by one UE: 
If K_SSB < 24 for FR1 and K_SSB <13 for FR2 on the NES cell, the cell coverage is impacted and wastes power for legacy UEs; 
If K_SSB >= 24 for FR1 and K_SSB >= 13 for FR2 on the NES cell, UE cannot distinguish whether NW is transmitting OD-SIB1 or not, thus UE does not need to monitor PDCCH before sending UL WUS. 

Proposal 4: Do not support gNB indicating in the UL WUS configuration that on which SSB the UE can expect PDCCH transmission.

 

3GPP TSG RAN WG1 Meeting #120-bis    							                              R1-2502658
Wuhan, China, April 7th – 11th, 2025

Agenda item:		9.5.2
Title:						On-demand SIB1 for NES
Source:				Fraunhofer IIS, Fraunhofer HHI
Document for:		Discussion

Conclusions
In this contribution, we discussed an aspects of on-demand SIB1 for NES with the following proposal:

Proposal 1: If a UE has SIB1 request configuration of a cell and before transmitting UL WUS, if the UE detects a SSB where K_SSB>=24 for FR1 or K_SSB>=13 for FR2, the following applies
Alt. 2: UE monitors Type 0 PDCCH for SIB1 transmission
Whether monitoring time window of Type 0 PDCCH is up to UE implementation.

TDoc file reading error

3GPP TSG RAN WG1 #120bis	R1-2502681
Wuhan, China, April 7th – 11th, 2025
Source:	Sharp
Title:	Discussion on on-demand SIB1 transmission for idle UEs
Agenda Item:	9.5.2
Document for:	Discussion and Decision

Conclusion
In this contribution, we have the following observations and proposals:
Observation 1: Alt. 1 in the agreement in RAN1#120 has two interpretations, and it should be clarified before down-selection.
Observation 2: To align with previous RAN2 agreement, Alt.3 and Alt. 4 which may transmit OD-SIB1 request irrespective of the transmissions status, should be excluded from the down-selection.
Observation 3: Although explicit indication of OD-SIB1 transmission status by MIB has benefit to avoid blind detection of OD-SIB1, it requires MIB updates per change of OD-SIB1 transmission status.
Observation 4: Action change of legacy idle UEs by OD-SIB1 transmission status should be avoided as possible.
Proposal 1: NES UE should monitor Type 0 PDCCH irrespective of OD-SIB1 transmission status (i.e. Alt 1-2 or Alt 2).

3GPP TSG RAN WG1 #120bis           	                                   R1-2502709
Wuhan, China, April 7th – 11th, 2025
Agenda Item: 9.5.2
Source: MediaTek Inc.
Title: On-demand SIB1 for idle or inactive mode UEs
Document for: Discussion and decision

Conclusion
In this contribution, we focus on the discussions of on-demand SIB1 for idle or inactive mode UEs and have the following proposals:

Proposal 1: Allow gNB to indicate in UL-WUS configuration the SSB index(es) the UE can expect PDCCH transmission on.

Observation 1: Considering the RAN2 #127b agreement that “UE needs to check if SIB1 is currently being broadcasted or provided on demand for that cell before requesting SIB1 of that cell”, Alt 2 seems the best fit.
Alt. 2: UE monitors Type 0 PDCCH for SIB1 transmission (before transmitting UL WUS)

Observation 2: For Alt. 2, it is not clear monitoring time window of Type 0 PDCCH is up to UE implementation or specified, and hence the amount of additional UE power consumption for Alt. 2 is not clear.

Proposal 2: To limit the amount of additional UE power consumption, adopt Alt. 2 agreed in RAN1 #120:
Alt. 2: UE monitors Type 0 PDCCH for SIB1 transmission (before transmitting UL WUS)
while the monitoring time window of Type 0 PDCCH is up to UE implementation.

Proposal 3: A potential issue of paging dropping may arise if UL-WUS on NES cell overlapped with paging occasion on Cell A as shown in Figure 1. RAN1 can further discuss how to solve this issue.

3GPP TSG-RAN WG1 #120bis	R1-2502750
Wuhan, China, April 7th – 11th, 2025

Source:                    	DENSO CORPORATION
Title:  	Discussion on on-demand SIB1 for idle/inactive mode UEs
Document for:        	Discussion and Decision
Agenda Item:         	9.5.2 - On-demand SIB1 for idle/inactive mode UEs

Summary and proposal
In summary, the followings were observed and proposed:
Proposal 1:	If a UE has SIB1 request configuration of a cell and before transmitting UL WUS, the UE monitors Type 0 PDCCH for SIB1 transmission (Alt.2).
For Type 0 PDCCH monitoring, the gNB can provide SIB1 repetition periodicity, and the UE monitors Type 0 PDCCH occasions according to SIB1 repetition periodicity.
Proposal 2:	It is not necessary to specify whether to transmit additional SIB1 other than that corresponding to UL WUS from UE. It is up to the gNB implementation.

3GPP TSG RAN WG1 #120bis			R1-2502771
Wuhan, China, April 7th – 11th, 2025

Source:	NTT DOCOMO, INC.
Title:	Discussion on on-demand SIB1 for idle/inactive mode UEs
Agenda Item:	9.5.2
Document for: 	Discussion and Decision

Conclusion
In this contribution, we provided the following observations and proposals of on-demand SIB1 transmission for network energy saving.

Proposal 1:
If a UE has SIB1 request configuration of a cell and before transmitting UL WUS, and if the UE detects a SSB where K_SSB>=24 for FR1 or K_SSB>=13 for FR2, 
Alt. 2: UE monitors Type 0 PDCCH for SIB1 transmission within a time window or within one or multiple SSB periodicity. 
 
Proposal 2:
Do not support additional contents to RAR in response to UL WUS on top of contents of RAR in response to SI request.

Proposal 3:
gNB can indicate in WUS configuration that whether the triggered OD-SIB1 is corresponding to one SSB or all SSBs or multiple SSBs.   

3GPP TSG-RAN WG1 Meeting #120bis	Tdoc R1-2502803 
Wuhan, China, April 7th – April 11th, 2025

Agenda Item:	9.5.2
Source:	Ericsson
Title:	On-demand SIB1 for UEs in idle/inactive mode for NES
Document for:	Discussion

1	

Conclusion
In the previous sections we made the following observations: 
Observation 1	The UL-WUS configuration is semi-static and cannot be used to indicate dynamically (per OD-SIB1 request) in which PDCCH occasions that SIB1 is transmitted.
Observation 2	It is not feasible that a NES cell changes its MIB for the brief duration that OD-SIB1 is provided in response to UL WUS.
Observation 3	For a UE that does not monitor Type 0 PDCCH for SIB1 transmission, it is not clear how the UE should check if SIB1 is broadcasted or provided on-demand before sending UL WUS.
Observation 4	If the UE doesn’t know the SIB1 repetition periodicity, then it must monitor SIB1 PDCCH for a duration of 160ms to determine whether SIB1 is provided or not.
Observation 5	If the UE knows the SIB1 repetition periodicity and offset, then it is enough to check one candidate Type0-PDCCH CSS occasion. This will significantly reduce the monitoring delay and effort for the UE.
Observation 6	A UE attempting to access the NES Cell is still camping on Cell A and must follow the paging occasions of Cell A.
Observation 7	Completely overlapping paging occasions in Cell A with UL WUS occasions in the NES Cell is an example of poor network configuration.
Based on the discussion in the previous sections we propose the following:
Proposal 1	Include a parameter in the UL-WUS configuration to indicate if the UE should assume that OD-SIB1 is transmitted in PDCCH monitoring occasions corresponding to each transmitted SSB or just the SSB(s) associated with the PRACH for UL-WUS.
Proposal 2	If gNB indication of PDCCH occasions where the UE can expect SIB1 is supported, PDCCH occasions that are associated other SSBs than the SSB associated with the RACH used for UL WUS, then the indication should be dynamic and carried in the RAR in response to UL WUS.
Proposal 3	If UE has UL WUS configuration for a cell with not CD-SSB, then the UE should monitor at least one Type0-PDCCH CSS occasion before it can request OD-SIB1 (Alt. 2).
Proposal 4	Include assistance parameters in the UL WUS configuration that informs the UE of the SIB1 transmission/repetition occasions. For example: a) SIB1 periodicity and offset, or b) SIB1 search space mask indicating which of the occasions are used by the NES cell
Proposal 5	The assistance parameters in the WUS configuration that informs the of the SIB1 transmission/repetition occasions are also valid after the on-demand SIB1 acquisition procedure.
Proposal 6	The UE should continue to monitor for SIB1 until the next RACH occasion in which it can transmit UL WUS.
Proposal 7	No action is necessary to be specified for collision with paging as the issue can be resolved with appropriate network configuration.
Proposal 8	RAN1 to discuss the value range for the od-sib1-windowLength. Use the value-range for si-windowLength as starting point for discussions.

3GPP TSG RAN WG1 #120bis   		                                                                       R1-2502844 Wuhan, China, April 7th – 11th, 2025

Agenda item:	9.5.2
Source: 	Qualcomm Incorporated
Title: 	On-demand SIB1 procedure
Document for:	Discussion/Decision

Conclusion
The contribution has discussed our views on the remaining aspects to support on-demand SIB1 operation for idle/inactive UEs. In particular, we make the following observations and proposals:
Proposal 1: For PDCCH monitoring for OD-SIB1, UE is indicated with a flag in UL-WUS configuration on whether PDCCH for OD-SIB1 is transmitted over occasions corresponding to SSBs other than the ones associated with the PRACH for UL-WUS or not.
If the flag is enabled, the UE assumes that PDCCH for OD-SIB1 is transmitted over occasions corresponding to SSBs associated with the PRACH for UL-WUS and some other SSBs that are not associated with the PRACH for UL-WUS.
Otherwise, the UE would monitor PDCCH in PDCCH monitoring occasions corresponding to the SSB associated with the PRACH for UL-WUS.
Proposal 2: For PDCCH monitoring for OD-SIB1, if PDCCH for OD-SIB1 is transmitted over occasions corresponding to SSBs other than the ones associated with the PRACH for UL-WUS, the UE is provided with an indication of a list of the SSBs for monitoring PDCCH for OD-SIB1 in RAR in response to UL WUS transmission.
Proposal 3: If a UE has SIB1 request configuration of a cell and detects a SSB where K_SSB>=24 for FR1 or K_SSB>=13 for FR2 on a sync raster, select Alt. 1 or Alt. 3 for PDCCH monitoring before transmitting UL WUS.

3GPP TSG RAN WG1 Meeting #120-bis	  R1-2502918
Wuhan, China, Apri 7th – Apri 11th, 2025

Agenda Item:	9.5.2
Source:	CEWiT
Title:	Discussion on on-demand SIB1.
Document for:	Discussion 

Conclusion
In this contribution, we discussed the techniques required for NES. According to the technical analysis, the following proposals are made, 
Observation 1: Transmitting on-demand SIB1 in association with the beam where the WUS is received can prevent unnecessary transmissions across all beams, conserving network resources and energy.
Observation 2: The evaluation results obtained during the study item demonstrated that SIB1 transmission in limited beams can save energy.
Proposal 1: Support UE assumes that PDCCH for an on-demand SIB1 is transmitted in at least one PDCCH monitoring occasion which corresponds to only the SSB associated with the received WUS.
Proposal 2: Support indicating the transmission status of on-demand SIB1 using repurposed parameters in MIB or PBCH of NES cell for idle UEs. 
Proposal 3: RAN1 to further study how UE determines the following states for the NES cell.
State B: SIB1 is currently being periodically broadcasted (like legacy UE)
State C1: SIB1 is provided on demand within a time window (no SIB1 transmission and UE has to sent SIB1 request) 
Observation 3: On-demand SIB1 impacts the need and validity of periodic RACH occasions and their association with SSBs, requiring adjustments to ensure efficient RRC connection establishment.
Proposal 4: Support handling the impacts of on-demand SIB1 on RACH occasions for RRC connection establishment.

3GPP TSG RAN WG1 #120bis		                                 R1-2502921
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.5.2
Source:	CAICT
Title:	Discussion on on-demand SIB1 in idle/inactive mode
Document for:	Discussion and Decision   

Conclusion
In this contribution, we give following proposals of on-demand SIB1 in idle/inactive mode:
Proposal 1:  For How to use PDCCH-ConfigSIB1 in MIB of NES Cell,we slightly prefer option 3: Do not re-purpose the reserved values of searchSpaceZero and controlResourceSetZero, and option 2:Use it to indicate searchSpaceZero and controlResourceSetZero of OD-SIB1 is the second preference. 
Proposal 2:   it needs further discussion on whether to support SSB with on-demand SIB1 not on sync raster.
Proposal 3: Alt1 is preferred that is Only if K_SSB=30 for FR1 and K_SSB=14 for FR2, UE monitors Type 0 PDCCH for SIB1 transmission; Otherwise, UE doesn’t monitor Type 0 PDCCH. And monitoring time window of Type 0 PDCCH is to be specified.
Proposal 4: Alt5 can also be considered, that is UE monitors Type 0 PDCCH for SIB1 based on some repurposed parameters in MIB or PBCH.

3GPP TSG RAN WG1 #120bis							    R1-2503004
Wuhan, China, April 7th – 11th, 2025

Source:	Moderator (MediaTek)
Title:	FL summary 1 for on-demand SIB1 in idle/inactive mode
Agenda item:	9.5.2
Document for:	Discussion and Decision

Conclusion
The parameter “ssb-PeriodicityServingCell” is not included in the UL-WUS configuration for FDD system.
RA-RNTI is not included in the UL-WUS configuration.
Cell barring information is not included in the UL-WUS configuration.
Cell selection information is not included in the UL-WUS configuration.
Accessible UE types is not included in the UL-WUS configuration.
CarrierBandwidth (for MPR calculation) is not included in the UL-WUS configuration.
InitialUplinkBWP is not included in the UL-WUS configuration.
TotalNumberOfRA-Preambles is not included in the UL-WUS configuration.
SIB1-RequestResourceRedCap is not included in the UL-WUS configuration.
SupplementaryUL is not included in the UL-WUS configuration


Companies’ views for this topic in RAN1 #120-bis are collected below:

Tejas:
Proposal 4:  Include TotalNumberOfRA-Preambles in the UL-WUS configuration.

ETRI:
Proposal 3: The RAR window length for Type 1 PDCCH monitoring after transmitting UL WUS is either provided via UL WUS configuration or predefined.

Proposal 6: For agreed UL WUS parameters, follow the legacy specification regarding its mandatory or optional presence unless otherwise agreed.

Proposal 7: For agreed UL WUS parameters, regarding their mandatory or optional presence and 
applicability to TDD and/or FDD, adopt the followings:
PhysCellId and ARFCN-ValueNR are mandatory
frequencyBandList and absoluteFrequencyPointA are present in IE FrequencyInfoUL only for 
FDD (as in the legacy specification)
K_SSB is mandatory
searchSpaceZero and controlResourceSetZero are mandatory (at least for the agreed K_SSB 
values)
Duration of OD-SIB1 window is optional (as in the legacy OD-OSI specification)

Panasonic:
Proposal 1: In the UL WUS configurati on, a list of NES-CellId should be supported, with each NES cell associated with SIB1-RequestConfi g.

Ericsson:
Proposal 8 The parameter ra-SearchSpace provides the search space for RAR to UL WUS and should be of type SearchSpace.

Proposal 9 The parameter ra-SearchSpace should be OPTIONAL and searchSpaceZero should be used if ra-SearchSpace is absent.

Proposal 10 RAN1 to discuss the value range for the od-sib1-windowLength. Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point for discussions.

Proposal 11 A more descriptive name, e.g., od-sib1-windowStartOffset, should be used instead of the currently proposed offsetToTimeWindow.

Nokia:
Proposal-2: The value of the time offset between the reference time point and the starting time for the time window of UE monitoring Type-0 PDCCH of OD-SIB1 can be either 0, positive value, or negative value. 

Proposal-3: For the case of the time offset value is 0, the UE monitoring window of Type-0 PDCCH of OD-SIB1 and RAR window can be either partially or fully overlapped. 

Proposal-4: For the case of the time offset value is positive (>0), the UE monitoring window of Type-0 PDCCH of OD-SIB1 and RAR window can be either partially or no overlapped. 

Proposal-5: For the case of the time offset value is negative (<0), the UE monitoring window of Type-0 PDCCH of OD-SIB1 and RAR window can be partially overlapped.

Proposal-8: If configuration of SearchSpace#0 and CORESET#0 are fully overlapped for UE monitoring of
RAR and Type-0 PDCCH of OD-SIB1, especially when both RAR and Type-0 PDCCH of OD-SIB1
windows are overlapped. RAN1 shall discuss the corresponding UE monitoring behavior.

Fujitsu:
Proposal 4. The time offset to determine the starting time of the time window for type 0 PDCCH monitoring of on-demand SIB1 is indicated by ra-ResponseWindow in UL WUS configuration.

vivo
Proposal 4: If NES cell indicates a WUS configuration applying to NES cell itself, some parameters can follow the corresponding values in the SIB1 of NES cell itself to further reduce the payload of WUS configuration.

Proposal 6: Add offsetToPointA into WUS configuration to avoid changing the legacy mechanism in deriving UL point A in TDD system.

Proposal 7: ra-PreambleStartIndex, od-sib1-duration, offsetToTimeWindow and ssb-SubcarrierOffset is mandatorily configured in WUS configuration from RAN1 perspective.

Proposal 14: support the following change for row 14.


Proposal 15: support the following change for row 33-34.


Google
Proposal 1: Support to configure an initial downlink BWP by the UL-WUS configuration.
The NW can transmit the RAR and on-demand SIB1 based on the bandwidth of the initial downlink BWP.

NEC
Proposal 7: The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity). 

Huawei/HiSilicon
Observation 1: For the UE with WUS configuration, the term k1 in the PRACH baseband signal generation of section 5.3.2 of TS38.211 is not known if  is not included in the UL WUS configuration.

Proposal 2: For PRACH baseband signal generation of section 5.3.2 of TS38.211, CarrierBandwidth is included in the UL-WUS configuration to enable the UE to calculate k1. Otherwise, RAN1 clarifies how the UE determines k1.

Proposal 3: For initial uplink BWP related parameters, initial uplink BWP configuration is included in UL WUS configuration. Otherwise, RAN1 clarifies how to determine the initial UL BWP and how to ensure the center frequency alignment for TDD.

Proposal 4: RAN1 clarifies frequencyBandList in UL WUS configuration refers to the IE within FrequencyInfoUL-SIB.

Proposal 5: Search space configuration provided by the IE of SearchSpace is included in the UL WUS configuration to configure the RAR search space. If not included, the RAR search space is the Search Space 0. 
ControlResourceSetId in SearchSpace IE is 0.

Proposal 6: For the RAR search space configured by ra-SearchSpace in PDCCH-ConfigCommon in SIB1 and the RAR search space configured by UL WUS configuration, RAN1 discusses whether they should be the same or can be different.

Samsung
Proposal 3: Support the following additional RRC parameters in UL WUS configuration to configure UL WUS resource and generate UL WUS signal as legacy: 
locationAndBandwidth and cyclicPrefix for the initial BWP including UL WUS transmission.

Xiaomi
Proposal 3: For parameters agreed for UL WUS, they are mandatory.

FL Proposal 5-1 (Panasonic, vivo)
In the UL WUS configuration, support a list of NES-CellId, i.e., replace NES-CellId with NES-CellIdList.


FL Proposal 5-2 (Google)
Include initialDownlinkBWP in the UL-WUS configuration.
Note: The NW can transmit the RAR and on-demand SIB1 based on the bandwidth of the initial downlink BWP.

FL Proposal 5-3 (Samsung)
Include locationAndBandwidth and cyclicPrefix in the UL-WUS configuration.


FL Proposal 5-4 (vivo)
Include offsetToPointA in the UL-WUS configuration for TDD system to avoid changing the legacy mechanism in deriving UL point A in TDD system.


FL Proposal 5-5 (vivo)
Support the following change in the current RRC table (R1-2501645).


FL Proposal 5-6 (ETRI)
For agreed UL WUS parameters, follow the legacy specification regarding its mandatory or optional presence unless otherwise agreed.


FL Proposal 5-7 (ETRI/vivo/MTK)
For agreed UL WUS parameters, regarding their mandatory or optional presence and applicability to TDD and/or FDD, adopt the followings:
PhysCellId and ARFCN-ValueNR are mandatory
frequencyBandList and absoluteFrequencyPointA are present in IE FrequencyInfoUL only for FDD (as in the legacy specification)
K_SSB is mandatory
searchSpaceZero and controlResourceSetZero are mandatory
od-sib1-duration is mandatory
ra-PreambleStartIndex, od-sib1-duration, offsetToTimeWindow and ssb-SubcarrierOffset are mandatory


FL Proposal 5-8 (Ericsson)
The parameter ra-SearchSpace in the UL-WUS configuration should be of type SearchSpace.


FL Proposal 5-9 (Ericsson)
Replace the current parameter name offsetToTimeWindow with od-sib1-windowStartOffset (to make the naming more comprehensive).


FL Proposal 5-10 (Ericsson/NEC)
RAN1 to discuss the value range for od-sib1-duration. For example,
Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point.
Option 2: The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity).
Other options are not precluded.


FL Proposal 5-11 (Nokia)
The value of the time offset between the reference time point and the starting time for the time window of OD-SIB1 can be either 0, positive value, or negative value.


FL Proposal 5-12 (Huawei)
RAN1 clarifies frequencyBandList in UL WUS configuration refers to the IE within FrequencyInfoUL-SIB.


FL Proposal 5-13 (Need to revert previous RAN1 #120 conclusion) (Huawei)
Include CarrierBandwidth in the UL-WUS configuration to enable the UE to calculate k1.
Note: For the UE with UL-WUS configuration, the term k1 in the PRACH baseband signal generation of section 5.3.2 of TS38.211 is not known if  is not included in the UL WUS configuration.

Figure from [13, Huawei]


FL Proposal 5-14 (Need to revert previous RAN1 #120 conclusion) (Huawei)
Include initialUplinkBWP in the UL-WUS configuration.
Otherwise, RAN1 clarifies how to determine the initial UL BWP and how to ensure the center frequency alignment for TDD system.


FL Proposal 5-15 (Need to revert previous RAN1 #120 conclusion) (Tejas)
Include TotalNumberOfRA-Preambles in the UL-WUS configuration


Issue 6: UL-WUS on NES cell overlapping with paging occasion on normal cell
Background
The following proposals are brought up in RAN1 #120-bis:

MTK
Proposal 3: A potential issue of paging dropping may arise if UL-WUS on NES cell overlapped with paging occasion on Cell A as shown in Figure 1. RAN1 can further discuss how to solve this issue.

Figure 1. An Example of UL-WUS on NES cell overlapped with paging occasion on normal cell

Ericsson:
Observation 7 Constant overlapping paging occasions in Cell A with UL WUS occasions in the NES Cell is an example of poor network configuration.

Proposal 7 No action is necessary to be specified for collision with paging as the issue can be resolved with appropriate network configuration.

ZTE
Proposal 6: UE behavior on the overlapped resources between UL WUS in NES cell and paging occasions on cell A can be up to UE implementation.

Ofinno
Proposal 4: If a paging occasion (PO) on Cell A and OD-SIB1 procedures (e.g., a WUS transmission, RAR window, or OD-SIB1 window) in an NES cell collide/overlap with each other, then the UE is allowed to skip the PO and perform OD-SIB1 procedure on NES cell.

OPPO
Proposal 3: RAN1 to discuss the UE behavior for case Cell A switching to NES Cell.

For this topic, companies’ views in RAN1 #120-bis are summarized below
What should UE do if UL-WUS on NES cell overlapped with paging occasion on Cell A
Up to UE implementation: Ericsson (can be resolved with appropriate network configuration), ZTE
UE prioritizes receiving the paging occasion from Cell A: MTK
UE prioritizes transmitting the UL WUS to NES cell: Ofinno

Moderator suggests the following proposal with slight majority:
FL Proposal 6-1
It is up to UE implementation to prioritize receiving the paging occasion from Cell A or transmitting the UL WUS to NES cell, if the UL-WUS occasions on NES cell overlapped with the paging occasion on Cell A.

Figure example of UL-WUS on NES cell overlapped with paging occasion on Cell A from [29, MediaTek]

Issue 7: Validicity of UL WUS configuration
Background
The following proposals are brought up in RAN1 #120-bis:

CATT:
Proposal 14: How to ensure the validity of UL WUS configuration received from cell A should be studied.  


CEWiT:
Observation  3:  On-demand SIB1 impacts the need and validity of periodic RACH occasions and their association with SSBs, requiring adjustments to ensure efficient RRC connection establishment.

FL Proposal 7-1
RAN1 to further study how to ensure the validity of UL WUS configuration received from Cell A when the UL WUS configuration is updated and exchanged between Cell A and NES cell.

Figure from [7, CATT]


FL Proposal 7-1-2
It is up to RAN2 to discuss how to ensure the validity of UL WUS configuration received from Cell A when the UL WUS configuration is updated and exchanged between Cell A and NES cell.

Figure from [7, CATT]


Issue 8: UE to monitor the RAR for SIB1 requests sent by other UEs
Background
The following proposals are brought up in RAN1 #120-bis:

LG:
Proposal #4: To support UEs to monitor the RAR for SIB1 requests sent by other UEs, the following 
methods can be considered: 
1)  UE  monitors  DCI  scrambled  by  RA-RNTI  which  is  associated  with  RO  allocated  for  on-
demand SIB1 but not associated with RO containing PRACH transmitted by UE   
2)  Introduce  a  new  RNTI  (i.e.,  cell-specific  or  beam-specific  RNTI)  to  monitor  RAR 
corresponding to UL WUS for requesting SIB1 
3) Use only PDCCH (i.e., without RAR MAC CE) as the RAR where the PDCCH contains RAPID 
directly

Nokia
Proposal-10: RAN1 confirms that the RNTI is common for all UEs for requesting of OD-SIB1 operation based on the common PRACH resource occasion configured in UL WUS configuration.

Proposal-11: RAN1 to discuss the UE monitoring of OD-SIB1 that was earlier requested by other UEs before sending its own UL WUS for requesting SIB1.

FL Proposal 8-1
Support UE to monitor the RAR for SIB1 requests sent by other UEs and down select from the following options:
Option1: UE monitors DCI scrambled by RA-RNTI which is associated with RO allocated for on-demand SIB1 but not associated with RO containing PRACH transmitted by UE.
Option 2: Introduce a new RNTI (i.e., cell-specific or beam-specific RNTI) to monitor RAR corresponding to UL WUS for requesting SIB1.
Option 3: Use only PDCCH (i.e., without RAR MAC CE) as the RAR where the PDCCH contains RAPID directly.
FFS: Under which conditions should UE send its own UL WUS if UE can monitor the RAR for SIB1 requests sent by other UEs


Issue 9: Relation between OD-SIB1 monitoring window and RAR window
Background
In RAN1 #120, it is agreed that:

Agreement
The reference time point to determine the window starting time for on-demand SIB1 is based on the starting slot of the RAR window for UL WUS wherein UE successfully received a RAR.

In RAN2 #129, it is agreed that:
Agreement
Upon reception of RAR, the UE monitors OD-SIB1 in the window agreed by RAN1.

Companies’ views for this topic in RAN1 #120-bis are collected below:

Apple:
Proposal 2: Confirm that even after the start time of the OD-SIB1 monitoring window, UE is not required to monitor PDCCH in search space zero before UE successfully received its RAR.  

Figure from [25, Apple] to illustrate relation between OD-SIB1 monitoring window and RAR window


Nokia:
Proposal-6: RAN1 shall discuss the UE monitoring behavior when both RAR and Type-0 PDCCH of ODSIB1 monitoring windows are applied.

Observation-1: It is not necessary for UE to always detect both RAR and Type-0 PDCCH of OD-SIB1,
especially when both windows are overlapped.

Observation-2: In case when UE has successfully received the Type-0 PDCCH of OD-SIB1, the monitoring and reception of RAR by UE could simply be ignored, which also benefit for UE power saving.

Proposal-7: The monitoring and reception of RAR by UE could be ignored when UE has successfully received the Type-0 PDCCH of OD-SIB1.

vivo:
Proposal 8: Considering the time requirements for RAR reception, RAR decoding and preparation for monitoring, UE starts actual Type 0 PDCCH monitoring from the later one between X time units after RAR reception and offsetToTimeWindow slots after reference point.


FL Proposal 9-1
UE is not required to monitor PDCCH in search space zero before UE successfully received its RAR even after the start time of the OD-SIB1 monitoring window.

Figure from [25, Apple] to illustrate relation between OD-SIB1 monitoring window and RAR window


FL Proposal 9-2
After transmitting the UL WUS, UE starts Type 0 PDCCH monitoring from the later one between X time units after RAR reception and offsetToTimeWindow slots after reference time point.
FFS: Value of X and its unit to address UE processing time for RAR reception, RAR decoding, and preparation for PDCCH monitoring.

Figure to illustrate RAR processing from [4, vivo]


FL Proposal 9-3
The monitoring and reception of RAR by UE could be ignored when UE has successfully received the Type-0 PDCCH of OD-SIB1.

Figure example from [3, Nokia]


Issue 10: UE behaviors inside the OD-SIB1 time window
Background
In RAN1 #118b, it is agreed that:
Agreement
For the repetition periodicity of SIB1 within the time window of on-demand SIB1:
Up to NW implementation (no change to existing specification)

Moderator Note (to Fujitsu Proposal 3 below): 38.331 Clause 5.2.1 has the following text on SIB1 repetition periodicity
the SIB1 is transmitted on the DL-SCH with a periodicity of 160 ms and variable transmission repetition periodicity within 160 ms as specified in TS 38.213 [13], clause 13. The default transmission repetition periodicity of SIB1 is 20 ms but the actual transmission repetition periodicity is up to network implementation. For SSB and CORESET multiplexing pattern 1, SIB1 repetition transmission period is 20 ms. For SSB and CORESET multiplexing pattern 2/3, SIB1 transmission repetition period is the same as the SSB period (TS 38.213 [13], clause 13).

In RAN1 #120, it is agreed that:

Agreement
The reference time point to determine the window starting time for on-demand SIB1 is based on the starting slot of the RAR window for UL WUS wherein UE successfully received a RAR.

Agreement
The time offset between the reference time point and the starting time for the time window of on-demand SIB1 is indicated in the UL WUS configuration.
Unit of the time offset is in slot


Figure. Reference time point and time offset to OD-SIB1 window (revised from [R1-2408856, Qualcomm])

Companies’ views for this topic in RAN1 #120-bis are collected below:

Huawei/HiSilicon
Proposal 1: The reference time point to determine the starting slot of on-demand SIB1 window is the slot containing the starting symbol of RAR window.
The start of the OD-SIB1 window is at least one symbol after the UL WUS transmission.

vivo
Proposal 9: UE stops monitoring Type 0 PDCCH at the end of time window for on-demand SIB1, and the time window for on-demand SIB1 starts at offsetToTimeWindow slots after reference point.

LG:
Proposal #5: Clarify whether the time window of OD-SIB1 starts immediately after the time offset from   the   reference   time   point   or   it   starts   from   the   OD-SIB1   MO   (i.e.,   Type   0   PDCCH   MO) corresponding to SSB index associated with UL WUS transmitted by the UE.


Fujitsu:
Proposal 3. RAN1 to discuss the UE assumption on on-demand SIB1 repetitions within the time window. The following two alternatives can be considered.
Alt 1. UE assumes that the SIB1 transmitted within the time window are all repetitions. 
Alt 2. UE assumes that the SIB1 transmitted within the time window follows the mechanism of repetition within a 160 ms period.

Proposal 5. The time window for on-demand SIB1 starts at the first type 0 PDCCH monitoring occasion after the time offset ends. Regarding the first type 0 PDCCH monitoring occasion, the following three options can be considered.
Option 1. the type 0 PDCCH occasion corresponds to SSB index 0 
Option 2. the type 0 PDCCH occasion corresponds to the first SSB index of the transmitted SSBs
Option 3. the type 0 PDCCH occasion corresponds to the SSB index associated with the transmitted UL WUS
Note: the above options refer to the type 0 PDCCH occasion in the first slot for corresponding SSB indexes in the case of multiplexing pattern 1.

Sony
Proposal 2: The transmission time of the on-demand SIB1 on the NES cell should be restricted into one time window.

ZTE
Proposal 5: The transmission of the updated SIB1 on the NES cell should be within a time window.

FL Proposal 10-1 (from Huawei)
The reference time point to determine the window starting time for on-demand SIB1 is based on the slot containing the starting symbol of RAR window for UL WUS wherein UE successfully received a RAR.
The window starting time for on-demand SIB1 is at least one symbol after the UL WUS transmission.


FL Proposal 10-2 (from vivo/MTK)
UE stops monitoring Type 0 PDCCH at the end of time window for on-demand SIB1.
UE should receive the PDSCH for on-demand SIB1 outside the time window if its corresponding Type 0 PDCCH is located inside the time window for on-demand SIB1.


FL Proposal 10-3 (to address LG/Fujitsu Proposal 5 above)
The time window of OD-SIB1 starts immediately after the time offset from the reference time point.

Figure. Reference time point and time offset to OD-SIB1 window (revised from [R1-2408856, Qualcomm])


FL Proposal 10-4 (to address Sony/ZTE Proposal 2/5 above)
The transmission time of the on-demand SIB1 on the NES cell is restricted in one time window.


Issue 11: Whether other features such as RedCap and NR-U can be combined with OD-SIB1
Background
The following proposals are brought up in RAN1 #120-bis:

vivo:
Proposal 13: Whether some other features such as RedCap and NRU can be combined with OD-SIB1 needs discussion.

FL Proposal 11-1
RAN1 to further study whether the R19 OD-SIB1 feature can work with legacy RedCap features.


FL Proposal 11-2
RAN1 to further study whether R19 OD-SIB1 feature can work with legacy NR-U features.


Issue 12: RO selection based on rsrp-ThresholdSSB
Background
The following proposals are brought up in RAN1 #120-bis:

Google
Proposal 2: Support the UE to select the RO based on the SSB with lowest index among the SSBs that can meet the rsrp-ThresholdSSB requirement.

Proposal 3: If the UE cannot identify any SSB with RSRP higher than rsrp-ThresholdSSB, it should not transmit the PRACH for on-demand SIB1.

Sony:
Proposal 3: For selecting SSB from NES cell for OD-SIB1 request, UE can select any SSB if none of the measured SSBs are above the RSRP threshold (per legacy)

FL Proposal 12-1 (from Google)
UE selects RO based on the SSB with lowest index among the SSBs that can meet the rsrp-ThresholdSSB requirement.


FL Proposal 12-2 (from InterDigital)
For selecting SSB from NES cell for OD-SIB1 request, UE can select any SSB if none of the measured SSBs are above the RSRP threshold (per legacy).


Issue 13: KSSB value within one MIB transmission time interval (80ms)
Background
The following proposals are brought up in RAN1 #120-bis:

Nokia
Observation-9: Based on TS38.212, UE is not expecting change of MIB payload within one MIB TTI of 80ms.

Proposal-25: RAN1 to consider that the network switching between broadcasting SIB1 and on-demand SIB1 is at least 80ms via MIB indication, meaning that UE expects the same value of K_SSB within 80ms.

OPPO
Proposal 2: For time window configuration and determination, the following restrictions should be discussed:
If SIB1 being broadcast in time window will provoke a change of K_SSB value, the time window should be aligned with SI modification period.
 If SIB1 being broadcast in time window will provoke a change of PBCH payload, the time window should be aligned with 80 ms MIB period.

To moderator’s understanding, K_SSB value may need to be updated when the network switches between broadcasting SIB1 and on-demand SIB1, and K_SSB is indicated in MIB. The following proposal is hence suggested:
FL Proposal 13-1 (from Nokia)
The network switching between broadcasting SIB1 and on-demand SIB1 is at least 80ms via MIB indication, meaning that UE expects the same value of K_SSB within 80ms.



FL Proposal 13-1-2 
The network switching between SIB1 is currently being broadcasted or provided on demand is at least 80ms via MIB indication, meaning that UE expects the same value of K_SSB within 80ms.


FL Proposal 13-1-3 
The network switching between SIB1 is currently being broadcasted or provided on demand is at least the SI modification period, meaning that UE expects the same value of K_SSB within one SI modification period.


Issue 14: UE receives SI change indication when SIB1 is not being transmitted
Background
The following proposals are brought up in RAN1 #120-bis:

CATT:
Proposal 9: When the NES cell is in NES state without periodic SIB1 transmission and UE receives SI change indication or etwsAndCmasIndication, the following UE behaviors can be considered.
Alt 1: If a UE receives SI change indication or the etwsAndCmasIndication bit of Short Message is set, the UE assumes that the NES cell switches from “SIB1 is provided on demand” to “SIB1 is currently being broadcasted”.
Alt 2: If a UE receives SI change indication, the UE assumes that the updated SIB1 will be transmitted within a time window starting from the next modification period. •
Alt 3: If a UE receives Short Message at its PO and the etwsAndCmasIndication bit of Short Message is set, the UE re-acquire the SIB1 within a time window after its PO.

FL Proposal 14-1
When the NES cell is in NES state without periodic SIB1 transmission and UE receives SI change indication or etwsAndCmasIndication, down select from the following UE behaviors.
Alt 1: If a UE receives SI change indication or the etwsAndCmasIndication bit of Short Message is set, the UE assumes that the NES cell switches from “SIB1 is provided on demand” to “SIB1 is currently being broadcasted”.
Alt 2: If a UE receives SI change indication, the UE assumes that the updated SIB1 will be transmitted within a time window starting from the next modification period. •
Alt 3: If a UE receives Short Message at its PO and the etwsAndCmasIndication bit of Short Message is set, the UE re-acquire the SIB1 within a time window after its PO.


FL Proposal 14-1-2
It is up to RAN2 to discuss the UE behavior when the NES cell is in NES state without periodic SIB1 transmission and UE receives SI change indication or etwsAndCmasIndication.


Issue 15: Other topics
Discussion place holder for issues not included above.
FL Proposal 15-1
Companies are invited to bring up other proposals which (you think) should be treated in this meeting. Moderator would try to devise further discussion based on received comments.
Proposal receiving support/attention from multiple companies would be visited first.


Resulted RAN1 conclusion/agreement
TBD.


4 References (all from RAN1 #120-bis)
R1-2501714	Discussion of on-demand SIB1 for idle/inactive mode UEs	FUTUREWEI
R1-2501765	Discussion on on-demand SIB1 for NES	ZTE Corporation, Sanechips
R1-2501773	On-demand SIB1 for Idle/Inactive mode UEs	Nokia, Nokia Shanghai Bell
R1-2501811	Discussions on on-demand SIB1 for idle/inactive mode UEs	vivo
R1-2501873	Discussion on on-demand SIB1 for idle/inactive mode UEs	Spreadtrum, UNISOC
R1-2501953	On-demand SIB1 for Idle/Inactive Mode UE	Google
R1-2501997	Discussion on on-demand SIB1	CATT
R1-2502027	Discussion on on-demand SIB1 for idle/inactive mode UEs	China Telecom
R1-2502045	Discussion on on-demand SIB1 for idle/inactive mode UEs	Ofinno
R1-2502128	Discussion on on-demand SIB1 transmission for network energy savings	Fujitsu
R1-2502165	Discussion on on-demand SIB1 for UEs in idle/inactive mode	CMCC
R1-2502199	Discussion on on-demand SIB1 for UEs in idle/inactive mode	NEC
R1-2502230	Discussion on on-demand SIB1 for eNES	Huawei, HiSilicon
R1-2502262	Discussion on the enhancement to support on demand SIB1 for idle/inactive mode UE OPPO
R1-2502321	On-demand SIB1 for idle/inactive mode UEs	Sony
R1-2502335	Discussion on on-demand SIB1 for idle/inactive mode UEs	InterDigital, Inc.
R1-2502373	On-demand SIB1 for idle/inactive mode UEs	Samsung
R1-2502446	Discussion on on-demand SIB1 for idle/inactive mode UEs	Xiaomi
R1-2502469	OD-SIB1 for Idle/Inactive UEs	Tejas Network Limited
R1-2502479	On-demand SIB1 for idle/inactive mode UEs	LG Electronics
R1-2502514	On-demand SIB1 for idle/inactive mode UEs	ETRI
R1-2502543	Discussion on on-demand SIB1 transmission for idle/inactive mode UEs Transsion Holdings
R1-2502570	On-demand SIB1 for idle/inactive mode UEs	Lenovo
R1-2502579	Discussion on on-demand SIB1 for idle/inactive mode UEs	Panasonic
R1-2502613	On On-demand SIB1 for IDLE/INACTIVE mode UEs	Apple
R1-2502658	On-demand SIB1 for NES	Fraunhofer IIS, Fraunhofer HHI
R1-2502678	Remaining details for OD-SIB1 request	ASUSTeK
R1-2502681	Discussion on on-demand SIB1 transmission for idle UEs	Sharp
R1-2502709	On-demand SIB1 for idle or inactive mode UEs	MediaTek Inc.
R1-2502750	Discussion on on-demand SIB1 for idle/inactive mode UEs	DENSO CORPORATION
R1-2502771	Discussion on on-demand SIB1 for idle/inactive mode UEs	NTT DOCOMO, INC.
R1-2502803	On-demand SIB1 for UEs in idle/inactive mode for NES	Ericsson
R1-2502844	On-demand SIB1 procedure	Qualcomm Incorporated
R1-2502918	Discussion on  on-demand SIB1	CEWiT
R1-2502921	Discussion on on-demand SIB1 in idle/inactive mode	CAICT

3GPP TSG RAN WG1 #120bis							   R1-2503005
Wuhan, China, April 7th – 11th, 2025

Source:	Moderator (MediaTek)
Title:	FL summary 2 for on-demand SIB1 in idle/inactive mode
Agenda item:	9.5.2
Document for:	Discussion and Decision

Conclusion
The parameter “ssb-PeriodicityServingCell” is not included in the UL-WUS configuration for FDD system.
RA-RNTI is not included in the UL-WUS configuration.
Cell barring information is not included in the UL-WUS configuration.
Cell selection information is not included in the UL-WUS configuration.
Accessible UE types is not included in the UL-WUS configuration.
CarrierBandwidth (for MPR calculation) is not included in the UL-WUS configuration.
InitialUplinkBWP is not included in the UL-WUS configuration.
TotalNumberOfRA-Preambles is not included in the UL-WUS configuration.
SIB1-RequestResourceRedCap is not included in the UL-WUS configuration.
SupplementaryUL is not included in the UL-WUS configuration


Companies’ views for this topic in RAN1 #120-bis are collected below:

Tejas:
Proposal 4:  Include TotalNumberOfRA-Preambles in the UL-WUS configuration.

ETRI:
Proposal 3: The RAR window length for Type 1 PDCCH monitoring after transmitting UL WUS is either provided via UL WUS configuration or predefined.

Proposal 6: For agreed UL WUS parameters, follow the legacy specification regarding its mandatory or optional presence unless otherwise agreed.

Proposal 7: For agreed UL WUS parameters, regarding their mandatory or optional presence and 
applicability to TDD and/or FDD, adopt the followings:
PhysCellId and ARFCN-ValueNR are mandatory
frequencyBandList and absoluteFrequencyPointA are present in IE FrequencyInfoUL only for 
FDD (as in the legacy specification)
K_SSB is mandatory
searchSpaceZero and controlResourceSetZero are mandatory (at least for the agreed K_SSB 
values)
Duration of OD-SIB1 window is optional (as in the legacy OD-OSI specification)

Panasonic:
Proposal 1: In the UL WUS configurati on, a list of NES-CellId should be supported, with each NES cell associated with SIB1-RequestConfi g.

Ericsson:
Proposal 8 The parameter ra-SearchSpace provides the search space for RAR to UL WUS and should be of type SearchSpace.

Proposal 9 The parameter ra-SearchSpace should be OPTIONAL and searchSpaceZero should be used if ra-SearchSpace is absent.

Proposal 10 RAN1 to discuss the value range for the od-sib1-windowLength. Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point for discussions.

Proposal 11 A more descriptive name, e.g., od-sib1-windowStartOffset, should be used instead of the currently proposed offsetToTimeWindow.

Nokia:
Proposal-2: The value of the time offset between the reference time point and the starting time for the time window of UE monitoring Type-0 PDCCH of OD-SIB1 can be either 0, positive value, or negative value. 

Proposal-3: For the case of the time offset value is 0, the UE monitoring window of Type-0 PDCCH of OD-SIB1 and RAR window can be either partially or fully overlapped. 

Proposal-4: For the case of the time offset value is positive (>0), the UE monitoring window of Type-0 PDCCH of OD-SIB1 and RAR window can be either partially or no overlapped. 

Proposal-5: For the case of the time offset value is negative (<0), the UE monitoring window of Type-0 PDCCH of OD-SIB1 and RAR window can be partially overlapped.

Proposal-8: If configuration of SearchSpace#0 and CORESET#0 are fully overlapped for UE monitoring of
RAR and Type-0 PDCCH of OD-SIB1, especially when both RAR and Type-0 PDCCH of OD-SIB1
windows are overlapped. RAN1 shall discuss the corresponding UE monitoring behavior.

Fujitsu:
Proposal 4. The time offset to determine the starting time of the time window for type 0 PDCCH monitoring of on-demand SIB1 is indicated by ra-ResponseWindow in UL WUS configuration.

vivo
Proposal 4: If NES cell indicates a WUS configuration applying to NES cell itself, some parameters can follow the corresponding values in the SIB1 of NES cell itself to further reduce the payload of WUS configuration.

Proposal 6: Add offsetToPointA into WUS configuration to avoid changing the legacy mechanism in deriving UL point A in TDD system.

Proposal 7: ra-PreambleStartIndex, od-sib1-duration, offsetToTimeWindow and ssb-SubcarrierOffset is mandatorily configured in WUS configuration from RAN1 perspective.

Proposal 14: support the following change for row 14.


Proposal 15: support the following change for row 33-34.


Google
Proposal 1: Support to configure an initial downlink BWP by the UL-WUS configuration.
The NW can transmit the RAR and on-demand SIB1 based on the bandwidth of the initial downlink BWP.

NEC
Proposal 7: The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity). 

Huawei/HiSilicon
Observation 1: For the UE with WUS configuration, the term k1 in the PRACH baseband signal generation of section 5.3.2 of TS38.211 is not known if  is not included in the UL WUS configuration.

Proposal 2: For PRACH baseband signal generation of section 5.3.2 of TS38.211, CarrierBandwidth is included in the UL-WUS configuration to enable the UE to calculate k1. Otherwise, RAN1 clarifies how the UE determines k1.

Proposal 3: For initial uplink BWP related parameters, initial uplink BWP configuration is included in UL WUS configuration. Otherwise, RAN1 clarifies how to determine the initial UL BWP and how to ensure the center frequency alignment for TDD.

Proposal 4: RAN1 clarifies frequencyBandList in UL WUS configuration refers to the IE within FrequencyInfoUL-SIB.

Proposal 5: Search space configuration provided by the IE of SearchSpace is included in the UL WUS configuration to configure the RAR search space. If not included, the RAR search space is the Search Space 0. 
ControlResourceSetId in SearchSpace IE is 0.

Proposal 6: For the RAR search space configured by ra-SearchSpace in PDCCH-ConfigCommon in SIB1 and the RAR search space configured by UL WUS configuration, RAN1 discusses whether they should be the same or can be different.

Samsung
Proposal 3: Support the following additional RRC parameters in UL WUS configuration to configure UL WUS resource and generate UL WUS signal as legacy: 
locationAndBandwidth and cyclicPrefix for the initial BWP including UL WUS transmission.

Xiaomi
Proposal 3: For parameters agreed for UL WUS, they are mandatory.

FL Proposal 5-1 (Panasonic, vivo)
In the UL WUS configuration, support a list of NES-CellId, i.e., replace NES-CellId with NES-CellIdList.


FL Proposal 5-1-2 
In the UL WUS configuration, how to support multiple NES-CellId(s) is up to RAN2 discussion.


FL Proposal 5-2 (Google)
Include initialDownlinkBWP in the UL-WUS configuration.
Note: The NW can transmit the RAR and on-demand SIB1 based on the bandwidth of the initial downlink BWP.

FL Proposal 5-3 (Samsung)
Include locationAndBandwidth and cyclicPrefix in the UL-WUS configuration.


FL Proposal 5-4 (vivo)
Include offsetToPointA in the UL-WUS configuration for TDD system to avoid changing the legacy mechanism in deriving UL point A in TDD system.


FL Proposal 5-5 (vivo)
Support the following change in the current RRC table (R1-2501645).


FL Proposal 5-6 (ETRI)
For agreed UL WUS parameters, follow the legacy specification regarding its mandatory or optional presence unless otherwise agreed.


FL Proposal 5-7 (ETRI/vivo/MTK)
For agreed UL WUS parameters, regarding their mandatory or optional presence and applicability to TDD and/or FDD, adopt the followings:
PhysCellId and ARFCN-ValueNR are mandatory
frequencyBandList and absoluteFrequencyPointA are present in IE FrequencyInfoUL only for FDD (as in the legacy specification)
K_SSB is mandatory
searchSpaceZero and controlResourceSetZero are mandatory
od-sib1-duration is mandatory
ra-PreambleStartIndex, od-sib1-duration, offsetToTimeWindow and ssb-SubcarrierOffset are mandatory


FL Proposal 5-8 (Ericsson)
The parameter ra-SearchSpace in the UL-WUS configuration should be of type SearchSpace.


FL Proposal 5-9 (Ericsson)
Replace the current parameter name offsetToTimeWindow with od-sib1-windowStartOffset (to make the naming more comprehensive).


FL Proposal 5-10 (Ericsson/NEC)
RAN1 to discuss the value range for od-sib1-duration. For example,
Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point.
Option 2: The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity).
Other options are not precluded.


FL Proposal 5-11 (Nokia)
The value of the time offset between the reference time point and the starting time for the time window of OD-SIB1 can be either 0, positive value, or negative value.


FL Proposal 5-11-2 
The value of the time offset between the reference time point and the starting time for the time window of OD-SIB1 can be either 0 or positive value.


FL Proposal 5-12 (Huawei)
RAN1 clarifies frequencyBandList in UL WUS configuration refers to the IE within FrequencyInfoUL-SIB.


FL Proposal 5-13 (Need to revert previous RAN1 #120 conclusion) (Huawei)
Include CarrierBandwidth in the UL-WUS configuration to enable the UE to calculate k1.
Note: For the UE with UL-WUS configuration, the term k1 in the PRACH baseband signal generation of section 5.3.2 of TS38.211 is not known if  is not included in the UL WUS configuration.

Figure from [13, Huawei]


FL Proposal 5-14 (Need to revert previous RAN1 #120 conclusion) (Huawei)
Include initialUplinkBWP in the UL-WUS configuration.
Otherwise, RAN1 clarifies how to determine the initial UL BWP and how to ensure the center frequency alignment for TDD system.


FL Proposal 5-15 (Need to revert previous RAN1 #120 conclusion) (Tejas)
Include TotalNumberOfRA-Preambles in the UL-WUS configuration


FL Proposal 5-16 
Indication of K_SSB value in the UL-WUS configuration should be ssb-SubcarrierOffset, combined with PBCH payload, as in legacy. 

https://howltestuffworks.blogspot.com/2019/10/5g-nr-pbch-and-master-information-block.html 


FL Proposal 5-16-2
Indication of K_SSB value in the UL-WUS configuration should be 5 bits for FR1 and 4 bits for FR2.

https://howltestuffworks.blogspot.com/2019/10/5g-nr-pbch-and-master-information-block.html 


Issue 6: UL-WUS on NES cell overlapping with paging occasion on normal cell
Background
The following proposals are brought up in RAN1 #120-bis:

MTK
Proposal 3: A potential issue of paging dropping may arise if UL-WUS on NES cell overlapped with paging occasion on Cell A as shown in Figure 1. RAN1 can further discuss how to solve this issue.

Figure 1. An Example of UL-WUS on NES cell overlapped with paging occasion on normal cell

Ericsson:
Observation 7 Constant overlapping paging occasions in Cell A with UL WUS occasions in the NES Cell is an example of poor network configuration.

Proposal 7 No action is necessary to be specified for collision with paging as the issue can be resolved with appropriate network configuration.

ZTE
Proposal 6: UE behavior on the overlapped resources between UL WUS in NES cell and paging occasions on cell A can be up to UE implementation.

Ofinno
Proposal 4: If a paging occasion (PO) on Cell A and OD-SIB1 procedures (e.g., a WUS transmission, RAR window, or OD-SIB1 window) in an NES cell collide/overlap with each other, then the UE is allowed to skip the PO and perform OD-SIB1 procedure on NES cell.

OPPO
Proposal 3: RAN1 to discuss the UE behavior for case Cell A switching to NES Cell.

For this topic, companies’ views in RAN1 #120-bis are summarized below
What should UE do if UL-WUS on NES cell overlapped with paging occasion on Cell A
Up to UE implementation: Ericsson (can be resolved with appropriate network configuration), ZTE
UE prioritizes receiving the paging occasion from Cell A: MTK
UE prioritizes transmitting the UL WUS to NES cell: Ofinno

Moderator suggests the following proposal with slight majority:
FL Proposal 6-1
It is up to UE implementation to prioritize receiving the paging occasion from Cell A or transmitting the UL WUS to NES cell, if the UL-WUS occasions on NES cell overlapped with the paging occasion on Cell A.

Figure example of UL-WUS on NES cell overlapped with paging occasion on Cell A from [29, MediaTek]

Issue 7: Validicity of UL WUS configuration
Background
The following proposals are brought up in RAN1 #120-bis:

CATT:
Proposal 14: How to ensure the validity of UL WUS configuration received from cell A should be studied.  


CEWiT:
Observation  3:  On-demand SIB1 impacts the need and validity of periodic RACH occasions and their association with SSBs, requiring adjustments to ensure efficient RRC connection establishment.

FL Proposal 7-1
RAN1 to further study how to ensure the validity of UL WUS configuration received from Cell A when the UL WUS configuration is updated and exchanged between Cell A and NES cell.

Figure from [7, CATT]


FL Proposal 7-1-2
It is up to RAN2 to discuss how to ensure the validity of UL WUS configuration received from Cell A when the UL WUS configuration is updated and exchanged between Cell A and NES cell.

Figure from [7, CATT]


Issue 8: UE to monitor the RAR for SIB1 requests sent by other UEs
Background
The following proposals are brought up in RAN1 #120-bis:

LG:
Proposal #4: To support UEs to monitor the RAR for SIB1 requests sent by other UEs, the following 
methods can be considered: 
1)  UE  monitors  DCI  scrambled  by  RA-RNTI  which  is  associated  with  RO  allocated  for  on-
demand SIB1 but not associated with RO containing PRACH transmitted by UE   
2)  Introduce  a  new  RNTI  (i.e.,  cell-specific  or  beam-specific  RNTI)  to  monitor  RAR 
corresponding to UL WUS for requesting SIB1 
3) Use only PDCCH (i.e., without RAR MAC CE) as the RAR where the PDCCH contains RAPID 
directly

Nokia
Proposal-10: RAN1 confirms that the RNTI is common for all UEs for requesting of OD-SIB1 operation based on the common PRACH resource occasion configured in UL WUS configuration.

Proposal-11: RAN1 to discuss the UE monitoring of OD-SIB1 that was earlier requested by other UEs before sending its own UL WUS for requesting SIB1.

FL Proposal 8-1
Support UE to monitor the RAR for SIB1 requests sent by other UEs and down select from the following options:
Option1: UE monitors DCI scrambled by RA-RNTI which is associated with RO allocated for on-demand SIB1 but not associated with RO containing PRACH transmitted by UE.
Option 2: Introduce a new RNTI (i.e., cell-specific or beam-specific RNTI) to monitor RAR corresponding to UL WUS for requesting SIB1.
Option 3: Use only PDCCH (i.e., without RAR MAC CE) as the RAR where the PDCCH contains RAPID directly.
FFS: Under which conditions should UE send its own UL WUS if UE can monitor the RAR for SIB1 requests sent by other UEs


Issue 9: Relation between OD-SIB1 monitoring window and RAR window
Background
In RAN1 #120, it is agreed that:

Agreement
The reference time point to determine the window starting time for on-demand SIB1 is based on the starting slot of the RAR window for UL WUS wherein UE successfully received a RAR.

In RAN2 #129, it is agreed that:
Agreement
Upon reception of RAR, the UE monitors OD-SIB1 in the window agreed by RAN1.

Companies’ views for this topic in RAN1 #120-bis are collected below:

Apple:
Proposal 2: Confirm that even after the start time of the OD-SIB1 monitoring window, UE is not required to monitor PDCCH in search space zero before UE successfully received its RAR.  

Figure from [25, Apple] to illustrate relation between OD-SIB1 monitoring window and RAR window


Nokia:
Proposal-6: RAN1 shall discuss the UE monitoring behavior when both RAR and Type-0 PDCCH of ODSIB1 monitoring windows are applied.

Observation-1: It is not necessary for UE to always detect both RAR and Type-0 PDCCH of OD-SIB1,
especially when both windows are overlapped.

Observation-2: In case when UE has successfully received the Type-0 PDCCH of OD-SIB1, the monitoring and reception of RAR by UE could simply be ignored, which also benefit for UE power saving.

Proposal-7: The monitoring and reception of RAR by UE could be ignored when UE has successfully received the Type-0 PDCCH of OD-SIB1.

vivo:
Proposal 8: Considering the time requirements for RAR reception, RAR decoding and preparation for monitoring, UE starts actual Type 0 PDCCH monitoring from the later one between X time units after RAR reception and offsetToTimeWindow slots after reference point.


FL Proposal 9-1
UE is not required to monitor PDCCH in search space zero before UE successfully received its RAR even after the start time of the OD-SIB1 monitoring window.

Figure from [25, Apple] to illustrate relation between OD-SIB1 monitoring window and RAR window


FL Proposal 9-2
After transmitting the UL WUS, UE starts Type 0 PDCCH monitoring from the later one between X time units after RAR reception and offsetToTimeWindow slots after reference time point.
FFS: Value of X and its unit to address UE processing time for RAR reception, RAR decoding, and preparation for PDCCH monitoring.

Figure to illustrate RAR processing from [4, vivo]


FL Proposal 9-3
The monitoring and reception of RAR by UE could be ignored when UE has successfully received the Type-0 PDCCH of OD-SIB1.

Figure example from [3, Nokia]


Issue 10: UE behaviors inside the OD-SIB1 time window
Background
In RAN1 #118b, it is agreed that:
Agreement
For the repetition periodicity of SIB1 within the time window of on-demand SIB1:
Up to NW implementation (no change to existing specification)

Moderator Note (to Fujitsu Proposal 3 below): 38.331 Clause 5.2.1 has the following text on SIB1 repetition periodicity
the SIB1 is transmitted on the DL-SCH with a periodicity of 160 ms and variable transmission repetition periodicity within 160 ms as specified in TS 38.213 [13], clause 13. The default transmission repetition periodicity of SIB1 is 20 ms but the actual transmission repetition periodicity is up to network implementation. For SSB and CORESET multiplexing pattern 1, SIB1 repetition transmission period is 20 ms. For SSB and CORESET multiplexing pattern 2/3, SIB1 transmission repetition period is the same as the SSB period (TS 38.213 [13], clause 13).

In RAN1 #120, it is agreed that:

Agreement
The reference time point to determine the window starting time for on-demand SIB1 is based on the starting slot of the RAR window for UL WUS wherein UE successfully received a RAR.

Agreement
The time offset between the reference time point and the starting time for the time window of on-demand SIB1 is indicated in the UL WUS configuration.
Unit of the time offset is in slot


Figure. Reference time point and time offset to OD-SIB1 window (revised from [R1-2408856, Qualcomm])

Companies’ views for this topic in RAN1 #120-bis are collected below:

Huawei/HiSilicon
Proposal 1: The reference time point to determine the starting slot of on-demand SIB1 window is the slot containing the starting symbol of RAR window.
The start of the OD-SIB1 window is at least one symbol after the UL WUS transmission.

vivo
Proposal 9: UE stops monitoring Type 0 PDCCH at the end of time window for on-demand SIB1, and the time window for on-demand SIB1 starts at offsetToTimeWindow slots after reference point.

LG:
Proposal #5: Clarify whether the time window of OD-SIB1 starts immediately after the time offset from   the   reference   time   point   or   it   starts   from   the   OD-SIB1   MO   (i.e.,   Type   0   PDCCH   MO) corresponding to SSB index associated with UL WUS transmitted by the UE.


Fujitsu:
Proposal 3. RAN1 to discuss the UE assumption on on-demand SIB1 repetitions within the time window. The following two alternatives can be considered.
Alt 1. UE assumes that the SIB1 transmitted within the time window are all repetitions. 
Alt 2. UE assumes that the SIB1 transmitted within the time window follows the mechanism of repetition within a 160 ms period.

Proposal 5. The time window for on-demand SIB1 starts at the first type 0 PDCCH monitoring occasion after the time offset ends. Regarding the first type 0 PDCCH monitoring occasion, the following three options can be considered.
Option 1. the type 0 PDCCH occasion corresponds to SSB index 0 
Option 2. the type 0 PDCCH occasion corresponds to the first SSB index of the transmitted SSBs
Option 3. the type 0 PDCCH occasion corresponds to the SSB index associated with the transmitted UL WUS
Note: the above options refer to the type 0 PDCCH occasion in the first slot for corresponding SSB indexes in the case of multiplexing pattern 1.

Sony
Proposal 2: The transmission time of the on-demand SIB1 on the NES cell should be restricted into one time window.

ZTE
Proposal 5: The transmission of the updated SIB1 on the NES cell should be within a time window.

FL Proposal 10-1 (from Huawei)
The reference time point to determine the window starting time for on-demand SIB1 is based on the slot containing the starting symbol of RAR window for UL WUS wherein UE successfully received a RAR.
The window starting time for on-demand SIB1 is at least one symbol after the UL WUS transmission.




FL Proposal 10-2 (from vivo/MTK)
UE stops monitoring Type 0 PDCCH at the end of time window for on-demand SIB1.
UE should receive the PDSCH for on-demand SIB1 outside the time window if its corresponding Type 0 PDCCH is located inside the time window for on-demand SIB1.


FL Proposal 10-3 (to address LG/Fujitsu Proposal 5 above)
The time window of OD-SIB1 starts immediately after the time offset from the reference time point.

Figure. Reference time point and time offset to OD-SIB1 window (revised from [R1-2408856, Qualcomm])


FL Proposal 10-4 (to address Sony/ZTE Proposal 2/5 above)
The transmission time of the on-demand SIB1 on the NES cell is restricted in one time window.


Issue 11: Whether other features such as RedCap and NR-U can be combined with OD-SIB1
Background
The following proposals are brought up in RAN1 #120-bis:

vivo:
Proposal 13: Whether some other features such as RedCap and NRU can be combined with OD-SIB1 needs discussion.

FL Proposal 11-1
RAN1 to further study whether the R19 OD-SIB1 feature can work with legacy RedCap features.


FL Proposal 11-2
RAN1 to further study whether R19 OD-SIB1 feature can work with legacy NR-U features.


Issue 12: RO selection based on rsrp-ThresholdSSB
Background
The following proposals are brought up in RAN1 #120-bis:

Google
Proposal 2: Support the UE to select the RO based on the SSB with lowest index among the SSBs that can meet the rsrp-ThresholdSSB requirement.

Proposal 3: If the UE cannot identify any SSB with RSRP higher than rsrp-ThresholdSSB, it should not transmit the PRACH for on-demand SIB1.

Sony:
Proposal 3: For selecting SSB from NES cell for OD-SIB1 request, UE can select any SSB if none of the measured SSBs are above the RSRP threshold (per legacy)

FL Proposal 12-1 (from Google)
UE selects RO based on the SSB with lowest index among the SSBs that can meet the rsrp-ThresholdSSB requirement.


FL Proposal 12-2 (from InterDigital)
For selecting SSB from NES cell for OD-SIB1 request, UE can select any SSB if none of the measured SSBs are above the RSRP threshold (per legacy).


Issue 13: KSSB value within one MIB transmission time interval (80ms)
Background
The following proposals are brought up in RAN1 #120-bis:

Nokia
Observation-9: Based on TS38.212, UE is not expecting change of MIB payload within one MIB TTI of 80ms.

Proposal-25: RAN1 to consider that the network switching between broadcasting SIB1 and on-demand SIB1 is at least 80ms via MIB indication, meaning that UE expects the same value of K_SSB within 80ms.

OPPO
Proposal 2: For time window configuration and determination, the following restrictions should be discussed:
If SIB1 being broadcast in time window will provoke a change of K_SSB value, the time window should be aligned with SI modification period.
 If SIB1 being broadcast in time window will provoke a change of PBCH payload, the time window should be aligned with 80 ms MIB period.

To moderator’s understanding, K_SSB value may need to be updated when the network switches between broadcasting SIB1 and on-demand SIB1, and K_SSB is indicated in MIB. The following proposal is hence suggested:
FL Proposal 13-1 (from Nokia)
The network switching between broadcasting SIB1 and on-demand SIB1 is at least 80ms via MIB indication, meaning that UE expects the same value of K_SSB within 80ms.



FL Proposal 13-1-2 
The network switching between SIB1 is currently being broadcasted or provided on demand is at least 80ms via MIB indication, meaning that UE expects the same value of K_SSB within 80ms.


FL Proposal 13-1-3 
The network switching between SIB1 is currently being broadcasted or provided on demand is at least the SI modification period, meaning that UE expects the same value of K_SSB within one SI modification period.


Issue 14: UE receives SI change indication when SIB1 is not being transmitted
Background
The following proposals are brought up in RAN1 #120-bis:

CATT:
Proposal 9: When the NES cell is in NES state without periodic SIB1 transmission and UE receives SI change indication or etwsAndCmasIndication, the following UE behaviors can be considered.
Alt 1: If a UE receives SI change indication or the etwsAndCmasIndication bit of Short Message is set, the UE assumes that the NES cell switches from “SIB1 is provided on demand” to “SIB1 is currently being broadcasted”.
Alt 2: If a UE receives SI change indication, the UE assumes that the updated SIB1 will be transmitted within a time window starting from the next modification period. •
Alt 3: If a UE receives Short Message at its PO and the etwsAndCmasIndication bit of Short Message is set, the UE re-acquire the SIB1 within a time window after its PO.

FL Proposal 14-1
When the NES cell is in NES state without periodic SIB1 transmission and UE receives SI change indication or etwsAndCmasIndication, down select from the following UE behaviors.
Alt 1: If a UE receives SI change indication or the etwsAndCmasIndication bit of Short Message is set, the UE assumes that the NES cell switches from “SIB1 is provided on demand” to “SIB1 is currently being broadcasted”.
Alt 2: If a UE receives SI change indication, the UE assumes that the updated SIB1 will be transmitted within a time window starting from the next modification period. •
Alt 3: If a UE receives Short Message at its PO and the etwsAndCmasIndication bit of Short Message is set, the UE re-acquire the SIB1 within a time window after its PO.


FL Proposal 14-1-2
It is up to RAN2 to discuss the UE behavior when the NES cell is in NES state without periodic SIB1 transmission and UE receives SI change indication or etwsAndCmasIndication.


Issue 15: Other topics
Discussion place holder for issues not included above.
FL Proposal 15-1
Companies are invited to bring up other proposals which (you think) should be treated in this meeting. Moderator would try to devise further discussion based on received comments.
Proposal receiving support/attention from multiple companies would be visited first.


Resulted RAN1 conclusion/agreement
TBD.


4 References (all from RAN1 #120-bis)
R1-2501714	Discussion of on-demand SIB1 for idle/inactive mode UEs	FUTUREWEI
R1-2501765	Discussion on on-demand SIB1 for NES	ZTE Corporation, Sanechips
R1-2501773	On-demand SIB1 for Idle/Inactive mode UEs	Nokia, Nokia Shanghai Bell
R1-2501811	Discussions on on-demand SIB1 for idle/inactive mode UEs	vivo
R1-2501873	Discussion on on-demand SIB1 for idle/inactive mode UEs	Spreadtrum, UNISOC
R1-2501953	On-demand SIB1 for Idle/Inactive Mode UE	Google
R1-2501997	Discussion on on-demand SIB1	CATT
R1-2502027	Discussion on on-demand SIB1 for idle/inactive mode UEs	China Telecom
R1-2502045	Discussion on on-demand SIB1 for idle/inactive mode UEs	Ofinno
R1-2502128	Discussion on on-demand SIB1 transmission for network energy savings	Fujitsu
R1-2502165	Discussion on on-demand SIB1 for UEs in idle/inactive mode	CMCC
R1-2502199	Discussion on on-demand SIB1 for UEs in idle/inactive mode	NEC
R1-2502230	Discussion on on-demand SIB1 for eNES	Huawei, HiSilicon
R1-2502262	Discussion on the enhancement to support on demand SIB1 for idle/inactive mode UE OPPO
R1-2502321	On-demand SIB1 for idle/inactive mode UEs	Sony
R1-2502335	Discussion on on-demand SIB1 for idle/inactive mode UEs	InterDigital, Inc.
R1-2502373	On-demand SIB1 for idle/inactive mode UEs	Samsung
R1-2502446	Discussion on on-demand SIB1 for idle/inactive mode UEs	Xiaomi
R1-2502469	OD-SIB1 for Idle/Inactive UEs	Tejas Network Limited
R1-2502479	On-demand SIB1 for idle/inactive mode UEs	LG Electronics
R1-2502514	On-demand SIB1 for idle/inactive mode UEs	ETRI
R1-2502543	Discussion on on-demand SIB1 transmission for idle/inactive mode UEs Transsion Holdings
R1-2502570	On-demand SIB1 for idle/inactive mode UEs	Lenovo
R1-2502579	Discussion on on-demand SIB1 for idle/inactive mode UEs	Panasonic
R1-2502613	On On-demand SIB1 for IDLE/INACTIVE mode UEs	Apple
R1-2502658	On-demand SIB1 for NES	Fraunhofer IIS, Fraunhofer HHI
R1-2502678	Remaining details for OD-SIB1 request	ASUSTeK
R1-2502681	Discussion on on-demand SIB1 transmission for idle UEs	Sharp
R1-2502709	On-demand SIB1 for idle or inactive mode UEs	MediaTek Inc.
R1-2502750	Discussion on on-demand SIB1 for idle/inactive mode UEs	DENSO CORPORATION
R1-2502771	Discussion on on-demand SIB1 for idle/inactive mode UEs	NTT DOCOMO, INC.
R1-2502803	On-demand SIB1 for UEs in idle/inactive mode for NES	Ericsson
R1-2502844	On-demand SIB1 procedure	Qualcomm Incorporated
R1-2502918	Discussion on  on-demand SIB1	CEWiT
R1-2502921	Discussion on on-demand SIB1 in idle/inactive mode	CAICT

3GPP TSG RAN WG1 #120bis							   R1-2503006
Wuhan, China, April 7th – 11th, 2025

Source:	Moderator (MediaTek)
Title:	FL summary 3 for on-demand SIB1 in idle/inactive mode
Agenda item:	9.5.2
Document for:	Discussion and Decision

Conclusion
The parameter “ssb-PeriodicityServingCell” is not included in the UL-WUS configuration for FDD system.
RA-RNTI is not included in the UL-WUS configuration.
Cell barring information is not included in the UL-WUS configuration.
Cell selection information is not included in the UL-WUS configuration.
Accessible UE types is not included in the UL-WUS configuration.
CarrierBandwidth (for MPR calculation) is not included in the UL-WUS configuration.
InitialUplinkBWP is not included in the UL-WUS configuration.
TotalNumberOfRA-Preambles is not included in the UL-WUS configuration.
SIB1-RequestResourceRedCap is not included in the UL-WUS configuration.
SupplementaryUL is not included in the UL-WUS configuration


Companies’ views for this topic in RAN1 #120-bis are collected below:

Tejas:
Proposal 4:  Include TotalNumberOfRA-Preambles in the UL-WUS configuration.

ETRI:
Proposal 3: The RAR window length for Type 1 PDCCH monitoring after transmitting UL WUS is either provided via UL WUS configuration or predefined.

Proposal 6: For agreed UL WUS parameters, follow the legacy specification regarding its mandatory or optional presence unless otherwise agreed.

Proposal 7: For agreed UL WUS parameters, regarding their mandatory or optional presence and 
applicability to TDD and/or FDD, adopt the followings:
PhysCellId and ARFCN-ValueNR are mandatory
frequencyBandList and absoluteFrequencyPointA are present in IE FrequencyInfoUL only for 
FDD (as in the legacy specification)
K_SSB is mandatory
searchSpaceZero and controlResourceSetZero are mandatory (at least for the agreed K_SSB 
values)
Duration of OD-SIB1 window is optional (as in the legacy OD-OSI specification)

Panasonic:
Proposal 1: In the UL WUS configurati on, a list of NES-CellId should be supported, with each NES cell associated with SIB1-RequestConfi g.

Ericsson:
Proposal 8 The parameter ra-SearchSpace provides the search space for RAR to UL WUS and should be of type SearchSpace.

Proposal 9 The parameter ra-SearchSpace should be OPTIONAL and searchSpaceZero should be used if ra-SearchSpace is absent.

Proposal 10 RAN1 to discuss the value range for the od-sib1-windowLength. Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point for discussions.

Proposal 11 A more descriptive name, e.g., od-sib1-windowStartOffset, should be used instead of the currently proposed offsetToTimeWindow.

Nokia:
Proposal-2: The value of the time offset between the reference time point and the starting time for the time window of UE monitoring Type-0 PDCCH of OD-SIB1 can be either 0, positive value, or negative value. 

Proposal-3: For the case of the time offset value is 0, the UE monitoring window of Type-0 PDCCH of OD-SIB1 and RAR window can be either partially or fully overlapped. 

Proposal-4: For the case of the time offset value is positive (>0), the UE monitoring window of Type-0 PDCCH of OD-SIB1 and RAR window can be either partially or no overlapped. 

Proposal-5: For the case of the time offset value is negative (<0), the UE monitoring window of Type-0 PDCCH of OD-SIB1 and RAR window can be partially overlapped.

Proposal-8: If configuration of SearchSpace#0 and CORESET#0 are fully overlapped for UE monitoring of
RAR and Type-0 PDCCH of OD-SIB1, especially when both RAR and Type-0 PDCCH of OD-SIB1
windows are overlapped. RAN1 shall discuss the corresponding UE monitoring behavior.

Fujitsu:
Proposal 4. The time offset to determine the starting time of the time window for type 0 PDCCH monitoring of on-demand SIB1 is indicated by ra-ResponseWindow in UL WUS configuration.

vivo
Proposal 4: If NES cell indicates a WUS configuration applying to NES cell itself, some parameters can follow the corresponding values in the SIB1 of NES cell itself to further reduce the payload of WUS configuration.

Proposal 6: Add offsetToPointA into WUS configuration to avoid changing the legacy mechanism in deriving UL point A in TDD system.

Proposal 7: ra-PreambleStartIndex, od-sib1-duration, offsetToTimeWindow and ssb-SubcarrierOffset is mandatorily configured in WUS configuration from RAN1 perspective.

Proposal 14: support the following change for row 14.


Proposal 15: support the following change for row 33-34.


Google
Proposal 1: Support to configure an initial downlink BWP by the UL-WUS configuration.
The NW can transmit the RAR and on-demand SIB1 based on the bandwidth of the initial downlink BWP.

NEC
Proposal 7: The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity). 

Huawei/HiSilicon
Observation 1: For the UE with WUS configuration, the term k1 in the PRACH baseband signal generation of section 5.3.2 of TS38.211 is not known if  is not included in the UL WUS configuration.

Proposal 2: For PRACH baseband signal generation of section 5.3.2 of TS38.211, CarrierBandwidth is included in the UL-WUS configuration to enable the UE to calculate k1. Otherwise, RAN1 clarifies how the UE determines k1.

Proposal 3: For initial uplink BWP related parameters, initial uplink BWP configuration is included in UL WUS configuration. Otherwise, RAN1 clarifies how to determine the initial UL BWP and how to ensure the center frequency alignment for TDD.

Proposal 4: RAN1 clarifies frequencyBandList in UL WUS configuration refers to the IE within FrequencyInfoUL-SIB.

Proposal 5: Search space configuration provided by the IE of SearchSpace is included in the UL WUS configuration to configure the RAR search space. If not included, the RAR search space is the Search Space 0. 
ControlResourceSetId in SearchSpace IE is 0.

Proposal 6: For the RAR search space configured by ra-SearchSpace in PDCCH-ConfigCommon in SIB1 and the RAR search space configured by UL WUS configuration, RAN1 discusses whether they should be the same or can be different.

Samsung
Proposal 3: Support the following additional RRC parameters in UL WUS configuration to configure UL WUS resource and generate UL WUS signal as legacy: 
locationAndBandwidth and cyclicPrefix for the initial BWP including UL WUS transmission.

Xiaomi
Proposal 3: For parameters agreed for UL WUS, they are mandatory.

FL Proposal 5-1 (Panasonic, vivo)
In the UL WUS configuration, support a list of NES-CellId, i.e., replace NES-CellId with NES-CellIdList.


FL Proposal 5-1-2 
In the UL WUS configuration, how to support multiple NES-CellId(s) is up to RAN2 discussion.


FL Proposal 5-2 (Google)
Include initialDownlinkBWP in the UL-WUS configuration.
Note: The NW can transmit the RAR and on-demand SIB1 based on the bandwidth of the initial downlink BWP.

FL Proposal 5-3 (Samsung)
Include locationAndBandwidth and cyclicPrefix in the UL-WUS configuration.


FL Proposal 5-4 (vivo)
Include offsetToPointA in the UL-WUS configuration for TDD system to avoid changing the legacy mechanism in deriving UL point A in TDD system.


FL Proposal 5-5 (vivo)
Support the following change in the current RRC table (R1-2501645).


FL Proposal 5-6 (ETRI)
For agreed UL WUS parameters, follow the legacy specification regarding its mandatory or optional presence unless otherwise agreed.


FL Proposal 5-7 (ETRI/vivo/MTK)
For agreed UL WUS parameters, regarding their mandatory or optional presence and applicability to TDD and/or FDD, adopt the followings:
PhysCellId and ARFCN-ValueNR are mandatory
frequencyBandList and absoluteFrequencyPointA are present in IE FrequencyInfoUL only for FDD (as in the legacy specification)
K_SSB is mandatory
searchSpaceZero and controlResourceSetZero are mandatory
od-sib1-duration is mandatory
ra-PreambleStartIndex, od-sib1-duration, offsetToTimeWindow and ssb-SubcarrierOffset are mandatory


FL Proposal 5-8 (Ericsson)
The parameter ra-SearchSpace in the UL-WUS configuration should be of type SearchSpace.


FL Proposal 5-9 (Ericsson)
Replace the current parameter name offsetToTimeWindow with od-sib1-windowStartOffset (to make the naming more comprehensive).


FL Proposal 5-10 (Ericsson/NEC)
RAN1 to discuss the value range for od-sib1-duration. For example,
Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point.
Option 2: The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity).
Other options are not precluded.


FL Proposal 5-11 (Nokia)
The value of the time offset between the reference time point and the starting time for the time window of OD-SIB1 can be either 0, positive value, or negative value.


FL Proposal 5-11-2 
The value of the time offset between the reference time point and the starting time for the time window of OD-SIB1 can be either 0 or positive value.


FL Proposal 5-11-3
The value of the time offset between the reference time point and the starting time for the time window of OD-SIB1 can be only positive value.

FL Proposal 5-12 (Huawei)
RAN1 clarifies frequencyBandList in UL WUS configuration refers to the IE within FrequencyInfoUL-SIB.


FL Proposal 5-13 (Need to revert previous RAN1 #120 conclusion) (Huawei)
Include CarrierBandwidth in the UL-WUS configuration to enable the UE to calculate k1.
Note: For the UE with UL-WUS configuration, the term k1 in the PRACH baseband signal generation of section 5.3.2 of TS38.211 is not known if  is not included in the UL WUS configuration.

Figure from [13, Huawei]


FL Proposal 5-14 (Need to revert previous RAN1 #120 conclusion) (Huawei)
Include initialUplinkBWP in the UL-WUS configuration.
Otherwise, RAN1 clarifies how to determine the initial UL BWP and how to ensure the center frequency alignment for TDD system.


FL Proposal 5-15 (Need to revert previous RAN1 #120 conclusion) (Tejas)
Include TotalNumberOfRA-Preambles in the UL-WUS configuration


FL Proposal 5-16 
Indication of K_SSB value in the UL-WUS configuration should be ssb-SubcarrierOffset, combined with PBCH payload, as in legacy. 

https://howltestuffworks.blogspot.com/2019/10/5g-nr-pbch-and-master-information-block.html 


FL Proposal 5-16-2
Indication of K_SSB value in the UL-WUS configuration should be 5 bits for FR1 and 4 bits for FR2.
Note: there is no change to current PBCH structure.

https://howltestuffworks.blogspot.com/2019/10/5g-nr-pbch-and-master-information-block.html 


Issue 6: UL-WUS on NES cell overlapping with paging occasion on normal cell
Background
The following proposals are brought up in RAN1 #120-bis:

MTK
Proposal 3: A potential issue of paging dropping may arise if UL-WUS on NES cell overlapped with paging occasion on Cell A as shown in Figure 1. RAN1 can further discuss how to solve this issue.

Figure 1. An Example of UL-WUS on NES cell overlapped with paging occasion on normal cell

Ericsson:
Observation 7 Constant overlapping paging occasions in Cell A with UL WUS occasions in the NES Cell is an example of poor network configuration.

Proposal 7 No action is necessary to be specified for collision with paging as the issue can be resolved with appropriate network configuration.

ZTE
Proposal 6: UE behavior on the overlapped resources between UL WUS in NES cell and paging occasions on cell A can be up to UE implementation.

Ofinno
Proposal 4: If a paging occasion (PO) on Cell A and OD-SIB1 procedures (e.g., a WUS transmission, RAR window, or OD-SIB1 window) in an NES cell collide/overlap with each other, then the UE is allowed to skip the PO and perform OD-SIB1 procedure on NES cell.

OPPO
Proposal 3: RAN1 to discuss the UE behavior for case Cell A switching to NES Cell.

For this topic, companies’ views in RAN1 #120-bis are summarized below
What should UE do if UL-WUS on NES cell overlapped with paging occasion on Cell A
Up to UE implementation: Ericsson (can be resolved with appropriate network configuration), ZTE
UE prioritizes receiving the paging occasion from Cell A: MTK
UE prioritizes transmitting the UL WUS to NES cell: Ofinno

Moderator suggests the following proposal with slight majority:
FL Proposal 6-1
It is up to UE implementation to prioritize receiving the paging occasion from Cell A or transmitting the UL WUS to NES cell, if the UL-WUS occasions on NES cell overlapped with the paging occasion on Cell A.

Figure example of UL-WUS on NES cell overlapped with paging occasion on Cell A from [29, MediaTek]

Issue 7: Validicity of UL WUS configuration
Background
The following proposals are brought up in RAN1 #120-bis:

CATT:
Proposal 14: How to ensure the validity of UL WUS configuration received from cell A should be studied.  


CEWiT:
Observation  3:  On-demand SIB1 impacts the need and validity of periodic RACH occasions and their association with SSBs, requiring adjustments to ensure efficient RRC connection establishment.

FL Proposal 7-1
RAN1 to further study how to ensure the validity of UL WUS configuration received from Cell A when the UL WUS configuration is updated and exchanged between Cell A and NES cell.

Figure from [7, CATT]


FL Proposal 7-1-2
It is up to RAN2 to discuss how to ensure the validity of UL WUS configuration received from Cell A when the UL WUS configuration is updated and exchanged between Cell A and NES cell.

Figure from [7, CATT]


Issue 8: UE to monitor the RAR for SIB1 requests sent by other UEs
Background
The following proposals are brought up in RAN1 #120-bis:

LG:
Proposal #4: To support UEs to monitor the RAR for SIB1 requests sent by other UEs, the following 
methods can be considered: 
1)  UE  monitors  DCI  scrambled  by  RA-RNTI  which  is  associated  with  RO  allocated  for  on-
demand SIB1 but not associated with RO containing PRACH transmitted by UE   
2)  Introduce  a  new  RNTI  (i.e.,  cell-specific  or  beam-specific  RNTI)  to  monitor  RAR 
corresponding to UL WUS for requesting SIB1 
3) Use only PDCCH (i.e., without RAR MAC CE) as the RAR where the PDCCH contains RAPID 
directly

Nokia
Proposal-10: RAN1 confirms that the RNTI is common for all UEs for requesting of OD-SIB1 operation based on the common PRACH resource occasion configured in UL WUS configuration.

Proposal-11: RAN1 to discuss the UE monitoring of OD-SIB1 that was earlier requested by other UEs before sending its own UL WUS for requesting SIB1.

FL Proposal 8-1
Support UE to monitor the RAR for SIB1 requests sent by other UEs and down select from the following options:
Option1: UE monitors DCI scrambled by RA-RNTI which is associated with RO allocated for on-demand SIB1 but not associated with RO containing PRACH transmitted by UE.
Option 2: Introduce a new RNTI (i.e., cell-specific or beam-specific RNTI) to monitor RAR corresponding to UL WUS for requesting SIB1.
Option 3: Use only PDCCH (i.e., without RAR MAC CE) as the RAR where the PDCCH contains RAPID directly.
FFS: Under which conditions should UE send its own UL WUS if UE can monitor the RAR for SIB1 requests sent by other UEs


Issue 9: Relation between OD-SIB1 monitoring window and RAR window
Background
In RAN1 #120, it is agreed that:

Agreement
The reference time point to determine the window starting time for on-demand SIB1 is based on the starting slot of the RAR window for UL WUS wherein UE successfully received a RAR.

In RAN2 #129, it is agreed that:
Agreement
Upon reception of RAR, the UE monitors OD-SIB1 in the window agreed by RAN1.

Companies’ views for this topic in RAN1 #120-bis are collected below:

Apple:
Proposal 2: Confirm that even after the start time of the OD-SIB1 monitoring window, UE is not required to monitor PDCCH in search space zero before UE successfully received its RAR.  

Figure from [25, Apple] to illustrate relation between OD-SIB1 monitoring window and RAR window


Nokia:
Proposal-6: RAN1 shall discuss the UE monitoring behavior when both RAR and Type-0 PDCCH of ODSIB1 monitoring windows are applied.

Observation-1: It is not necessary for UE to always detect both RAR and Type-0 PDCCH of OD-SIB1,
especially when both windows are overlapped.

Observation-2: In case when UE has successfully received the Type-0 PDCCH of OD-SIB1, the monitoring and reception of RAR by UE could simply be ignored, which also benefit for UE power saving.

Proposal-7: The monitoring and reception of RAR by UE could be ignored when UE has successfully received the Type-0 PDCCH of OD-SIB1.

vivo:
Proposal 8: Considering the time requirements for RAR reception, RAR decoding and preparation for monitoring, UE starts actual Type 0 PDCCH monitoring from the later one between X time units after RAR reception and offsetToTimeWindow slots after reference point.


FL Proposal 9-1
UE is not required to monitor PDCCH in search space zero before UE successfully received its RAR even after the start time of the OD-SIB1 monitoring window.

Figure from [25, Apple] to illustrate relation between OD-SIB1 monitoring window and RAR window


FL Proposal 9-1-2
It is up to UE implementation to monitor PDCCH in search space zero for OD-SIB1 before UE successfully received its RAR.

FL Proposal 9-1-3
It is up to UE implementation to monitor PDCCH in search space zero for OD-SIB1 outside the OD-SIB1 window after UE transmits UL-WUS.

FL Proposal 9-1-4
After transmitting the UL-WUS, UE is not required to monitor Type0-PDCCH occasion before UE successfully received its RAR.

Figure from [25, Apple] to illustrate relation between OD-SIB1 monitoring window and RAR window

FL Proposal 9-2
After transmitting the UL WUS, UE starts Type 0 PDCCH monitoring from the later one between X time units after RAR reception and offsetToTimeWindow slots after reference time point.
FFS: Value of X and its unit to address UE processing time for RAR reception, RAR decoding, and preparation for PDCCH monitoring.

Figure to illustrate RAR processing from [4, vivo]


FL Proposal 9-3
The monitoring and reception of RAR by UE could be ignored when UE has successfully received the Type-0 PDCCH of OD-SIB1.

Figure example from [3, Nokia]


Issue 10: UE behaviors inside the OD-SIB1 time window
Background
In RAN1 #118b, it is agreed that:
Agreement
For the repetition periodicity of SIB1 within the time window of on-demand SIB1:
Up to NW implementation (no change to existing specification)

Moderator Note (to Fujitsu Proposal 3 below): 38.331 Clause 5.2.1 has the following text on SIB1 repetition periodicity
the SIB1 is transmitted on the DL-SCH with a periodicity of 160 ms and variable transmission repetition periodicity within 160 ms as specified in TS 38.213 [13], clause 13. The default transmission repetition periodicity of SIB1 is 20 ms but the actual transmission repetition periodicity is up to network implementation. For SSB and CORESET multiplexing pattern 1, SIB1 repetition transmission period is 20 ms. For SSB and CORESET multiplexing pattern 2/3, SIB1 transmission repetition period is the same as the SSB period (TS 38.213 [13], clause 13).

In RAN1 #120, it is agreed that:

Agreement
The reference time point to determine the window starting time for on-demand SIB1 is based on the starting slot of the RAR window for UL WUS wherein UE successfully received a RAR.

Agreement
The time offset between the reference time point and the starting time for the time window of on-demand SIB1 is indicated in the UL WUS configuration.
Unit of the time offset is in slot


Figure. Reference time point and time offset to OD-SIB1 window (revised from [R1-2408856, Qualcomm])

Companies’ views for this topic in RAN1 #120-bis are collected below:

Huawei/HiSilicon
Proposal 1: The reference time point to determine the starting slot of on-demand SIB1 window is the slot containing the starting symbol of RAR window.
The start of the OD-SIB1 window is at least one symbol after the UL WUS transmission.

vivo
Proposal 9: UE stops monitoring Type 0 PDCCH at the end of time window for on-demand SIB1, and the time window for on-demand SIB1 starts at offsetToTimeWindow slots after reference point.

LG:
Proposal #5: Clarify whether the time window of OD-SIB1 starts immediately after the time offset from   the   reference   time   point   or   it   starts   from   the   OD-SIB1   MO   (i.e.,   Type   0   PDCCH   MO) corresponding to SSB index associated with UL WUS transmitted by the UE.


Fujitsu:
Proposal 3. RAN1 to discuss the UE assumption on on-demand SIB1 repetitions within the time window. The following two alternatives can be considered.
Alt 1. UE assumes that the SIB1 transmitted within the time window are all repetitions. 
Alt 2. UE assumes that the SIB1 transmitted within the time window follows the mechanism of repetition within a 160 ms period.

Proposal 5. The time window for on-demand SIB1 starts at the first type 0 PDCCH monitoring occasion after the time offset ends. Regarding the first type 0 PDCCH monitoring occasion, the following three options can be considered.
Option 1. the type 0 PDCCH occasion corresponds to SSB index 0 
Option 2. the type 0 PDCCH occasion corresponds to the first SSB index of the transmitted SSBs
Option 3. the type 0 PDCCH occasion corresponds to the SSB index associated with the transmitted UL WUS
Note: the above options refer to the type 0 PDCCH occasion in the first slot for corresponding SSB indexes in the case of multiplexing pattern 1.

Sony
Proposal 2: The transmission time of the on-demand SIB1 on the NES cell should be restricted into one time window.

ZTE
Proposal 5: The transmission of the updated SIB1 on the NES cell should be within a time window.

FL Proposal 10-1 (from Huawei)
The reference time point to determine the window starting time for on-demand SIB1 is based on the slot containing the starting symbol of RAR window for UL WUS wherein UE successfully received a RAR.
The window starting time for on-demand SIB1 is at least one symbol after the UL WUS transmission.





FL Proposal 10-1-2 
The reference time point to determine the window starting time for on-demand SIB1 is based on the slot containing the starting symbol of RAR window for UL WUS wherein UE successfully received a RAR.
FFS: The window starting time for on-demand SIB1 is at least one symbol after the UL WUS transmission.

FL Proposal 10-2 (from vivo)
UE stops monitoring Type 0 PDCCH at the end of time window for on-demand SIB1.
UE should receive the PDSCH for on-demand SIB1 outside the time window if its corresponding Type 0 PDCCH is located inside the time window for on-demand SIB1.


FL Proposal 10-3 (to address LG/Fujitsu Proposal 5 above)
The time window of OD-SIB1 starts immediately after the time offset from the reference time point.

Figure. Reference time point and time offset to OD-SIB1 window (revised from [R1-2408856, Qualcomm])


FL Proposal 10-3-2 (to address LG/Fujitsu Proposal 5 above)
The time window of OD-SIB1 starts immediately after the time offset from the reference time point.
The actual time UE starts PDCCH monitoring is the first type 0 PDCCH monitoring occasion where PDCCH for an OD-SIB1 message can be transmitted.

Figure. Reference time point and time offset to OD-SIB1 window (revised from [R1-2408856, Qualcomm])

FL Proposal 10-4 (to address Sony/ZTE Proposal 2/5 above)
The transmission time of the on-demand SIB1 on the NES cell is restricted in one time window.


Issue 11: Whether other features such as RedCap and NR-U can be combined with OD-SIB1
Background
The following proposals are brought up in RAN1 #120-bis:

vivo:
Proposal 13: Whether some other features such as RedCap and NRU can be combined with OD-SIB1 needs discussion.

FL Proposal 11-1
RAN1 to further study whether the R19 OD-SIB1 feature can work with legacy RedCap features.


FL Proposal 11-2
RAN1 to further study whether R19 OD-SIB1 feature can work with legacy NR-U features.


Issue 12: RO selection based on rsrp-ThresholdSSB
Background
The following proposals are brought up in RAN1 #120-bis:

Google
Proposal 2: Support the UE to select the RO based on the SSB with lowest index among the SSBs that can meet the rsrp-ThresholdSSB requirement.

Proposal 3: If the UE cannot identify any SSB with RSRP higher than rsrp-ThresholdSSB, it should not transmit the PRACH for on-demand SIB1.

Sony:
Proposal 3: For selecting SSB from NES cell for OD-SIB1 request, UE can select any SSB if none of the measured SSBs are above the RSRP threshold (per legacy)

FL Proposal 12-1 (from Google)
UE selects RO based on the SSB with lowest index among the SSBs that can meet the rsrp-ThresholdSSB requirement.


FL Proposal 12-2 (from InterDigital)
For selecting SSB from NES cell for OD-SIB1 request, UE can select any SSB if none of the measured SSBs are above the RSRP threshold (per legacy).


Issue 13: KSSB value within one MIB transmission time interval (80ms)
Background
The following proposals are brought up in RAN1 #120-bis:

Nokia
Observation-9: Based on TS38.212, UE is not expecting change of MIB payload within one MIB TTI of 80ms.

Proposal-25: RAN1 to consider that the network switching between broadcasting SIB1 and on-demand SIB1 is at least 80ms via MIB indication, meaning that UE expects the same value of K_SSB within 80ms.

OPPO
Proposal 2: For time window configuration and determination, the following restrictions should be discussed:
If SIB1 being broadcast in time window will provoke a change of K_SSB value, the time window should be aligned with SI modification period.
 If SIB1 being broadcast in time window will provoke a change of PBCH payload, the time window should be aligned with 80 ms MIB period.

To moderator’s understanding, K_SSB value may need to be updated when the network switches between broadcasting SIB1 and on-demand SIB1, and K_SSB is indicated in MIB. The following proposal is hence suggested:
FL Proposal 13-1 (from Nokia)
The network switching between broadcasting SIB1 and on-demand SIB1 is at least 80ms via MIB indication, meaning that UE expects the same value of K_SSB within 80ms.



FL Proposal 13-1-2 
The network switching between SIB1 is currently being broadcasted or provided on demand is at least 80ms via MIB indication, meaning that UE expects the same value of K_SSB within 80ms.


FL Proposal 13-1-3 
The network switching between SIB1 is currently being broadcasted or provided on demand is at least the SI modification period, meaning that UE expects the same value of K_SSB within one SI modification period.


Issue 14: UE receives SI change indication when SIB1 is not being transmitted
Background
The following proposals are brought up in RAN1 #120-bis:

CATT:
Proposal 9: When the NES cell is in NES state without periodic SIB1 transmission and UE receives SI change indication or etwsAndCmasIndication, the following UE behaviors can be considered.
Alt 1: If a UE receives SI change indication or the etwsAndCmasIndication bit of Short Message is set, the UE assumes that the NES cell switches from “SIB1 is provided on demand” to “SIB1 is currently being broadcasted”.
Alt 2: If a UE receives SI change indication, the UE assumes that the updated SIB1 will be transmitted within a time window starting from the next modification period. •
Alt 3: If a UE receives Short Message at its PO and the etwsAndCmasIndication bit of Short Message is set, the UE re-acquire the SIB1 within a time window after its PO.

FL Proposal 14-1
When the NES cell is in NES state without periodic SIB1 transmission and UE receives SI change indication or etwsAndCmasIndication, down select from the following UE behaviors.
Alt 1: If a UE receives SI change indication or the etwsAndCmasIndication bit of Short Message is set, the UE assumes that the NES cell switches from “SIB1 is provided on demand” to “SIB1 is currently being broadcasted”.
Alt 2: If a UE receives SI change indication, the UE assumes that the updated SIB1 will be transmitted within a time window starting from the next modification period. •
Alt 3: If a UE receives Short Message at its PO and the etwsAndCmasIndication bit of Short Message is set, the UE re-acquire the SIB1 within a time window after its PO.


FL Proposal 14-1-2
It is up to RAN2 to discuss the UE behavior when the NES cell is in NES state without periodic SIB1 transmission and UE receives SI change indication or etwsAndCmasIndication.


Issue 15: Other topics
Discussion place holder for issues not included above.
FL Proposal 15-1
Companies are invited to bring up other proposals which (you think) should be treated in this meeting. Moderator would try to devise further discussion based on received comments.
Proposal receiving support/attention from multiple companies would be visited first.


Resulted RAN1 conclusion/agreement
TBD.


4 References (all from RAN1 #120-bis)
R1-2501714	Discussion of on-demand SIB1 for idle/inactive mode UEs	FUTUREWEI
R1-2501765	Discussion on on-demand SIB1 for NES	ZTE Corporation, Sanechips
R1-2501773	On-demand SIB1 for Idle/Inactive mode UEs	Nokia, Nokia Shanghai Bell
R1-2501811	Discussions on on-demand SIB1 for idle/inactive mode UEs	vivo
R1-2501873	Discussion on on-demand SIB1 for idle/inactive mode UEs	Spreadtrum, UNISOC
R1-2501953	On-demand SIB1 for Idle/Inactive Mode UE	Google
R1-2501997	Discussion on on-demand SIB1	CATT
R1-2502027	Discussion on on-demand SIB1 for idle/inactive mode UEs	China Telecom
R1-2502045	Discussion on on-demand SIB1 for idle/inactive mode UEs	Ofinno
R1-2502128	Discussion on on-demand SIB1 transmission for network energy savings	Fujitsu
R1-2502165	Discussion on on-demand SIB1 for UEs in idle/inactive mode	CMCC
R1-2502199	Discussion on on-demand SIB1 for UEs in idle/inactive mode	NEC
R1-2502230	Discussion on on-demand SIB1 for eNES	Huawei, HiSilicon
R1-2502262	Discussion on the enhancement to support on demand SIB1 for idle/inactive mode UE OPPO
R1-2502321	On-demand SIB1 for idle/inactive mode UEs	Sony
R1-2502335	Discussion on on-demand SIB1 for idle/inactive mode UEs	InterDigital, Inc.
R1-2502373	On-demand SIB1 for idle/inactive mode UEs	Samsung
R1-2502446	Discussion on on-demand SIB1 for idle/inactive mode UEs	Xiaomi
R1-2502469	OD-SIB1 for Idle/Inactive UEs	Tejas Network Limited
R1-2502479	On-demand SIB1 for idle/inactive mode UEs	LG Electronics
R1-2502514	On-demand SIB1 for idle/inactive mode UEs	ETRI
R1-2502543	Discussion on on-demand SIB1 transmission for idle/inactive mode UEs Transsion Holdings
R1-2502570	On-demand SIB1 for idle/inactive mode UEs	Lenovo
R1-2502579	Discussion on on-demand SIB1 for idle/inactive mode UEs	Panasonic
R1-2502613	On On-demand SIB1 for IDLE/INACTIVE mode UEs	Apple
R1-2502658	On-demand SIB1 for NES	Fraunhofer IIS, Fraunhofer HHI
R1-2502678	Remaining details for OD-SIB1 request	ASUSTeK
R1-2502681	Discussion on on-demand SIB1 transmission for idle UEs	Sharp
R1-2502709	On-demand SIB1 for idle or inactive mode UEs	MediaTek Inc.
R1-2502750	Discussion on on-demand SIB1 for idle/inactive mode UEs	DENSO CORPORATION
R1-2502771	Discussion on on-demand SIB1 for idle/inactive mode UEs	NTT DOCOMO, INC.
R1-2502803	On-demand SIB1 for UEs in idle/inactive mode for NES	Ericsson
R1-2502844	On-demand SIB1 procedure	Qualcomm Incorporated
R1-2502918	Discussion on  on-demand SIB1	CEWiT
R1-2502921	Discussion on on-demand SIB1 in idle/inactive mode	CAICT

3GPP TSG RAN WG1 #120bis							   R1-2503007
Wuhan, China, April 7th – 11th, 2025

Source:	Moderator (MediaTek)
Title:	FL summary 4 for on-demand SIB1 in idle/inactive mode
Agenda item:	9.5.2
Document for:	Discussion and Decision

Conclusion
The parameter “ssb-PeriodicityServingCell” is not included in the UL-WUS configuration for FDD system.
RA-RNTI is not included in the UL-WUS configuration.
Cell barring information is not included in the UL-WUS configuration.
Cell selection information is not included in the UL-WUS configuration.
Accessible UE types is not included in the UL-WUS configuration.
CarrierBandwidth (for MPR calculation) is not included in the UL-WUS configuration.
InitialUplinkBWP is not included in the UL-WUS configuration.
TotalNumberOfRA-Preambles is not included in the UL-WUS configuration.
SIB1-RequestResourceRedCap is not included in the UL-WUS configuration.
SupplementaryUL is not included in the UL-WUS configuration


Companies’ views for this topic in RAN1 #120-bis are collected below:

Tejas:
Proposal 4:  Include TotalNumberOfRA-Preambles in the UL-WUS configuration.

ETRI:
Proposal 3: The RAR window length for Type 1 PDCCH monitoring after transmitting UL WUS is either provided via UL WUS configuration or predefined.

Proposal 6: For agreed UL WUS parameters, follow the legacy specification regarding its mandatory or optional presence unless otherwise agreed.

Proposal 7: For agreed UL WUS parameters, regarding their mandatory or optional presence and 
applicability to TDD and/or FDD, adopt the followings:
PhysCellId and ARFCN-ValueNR are mandatory
frequencyBandList and absoluteFrequencyPointA are present in IE FrequencyInfoUL only for 
FDD (as in the legacy specification)
K_SSB is mandatory
searchSpaceZero and controlResourceSetZero are mandatory (at least for the agreed K_SSB 
values)
Duration of OD-SIB1 window is optional (as in the legacy OD-OSI specification)

Panasonic:
Proposal 1: In the UL WUS configurati on, a list of NES-CellId should be supported, with each NES cell associated with SIB1-RequestConfi g.

Ericsson:
Proposal 8 The parameter ra-SearchSpace provides the search space for RAR to UL WUS and should be of type SearchSpace.

Proposal 9 The parameter ra-SearchSpace should be OPTIONAL and searchSpaceZero should be used if ra-SearchSpace is absent.

Proposal 10 RAN1 to discuss the value range for the od-sib1-windowLength. Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point for discussions.

Proposal 11 A more descriptive name, e.g., od-sib1-windowStartOffset, should be used instead of the currently proposed offsetToTimeWindow.

Nokia:
Proposal-2: The value of the time offset between the reference time point and the starting time for the time window of UE monitoring Type-0 PDCCH of OD-SIB1 can be either 0, positive value, or negative value. 

Proposal-3: For the case of the time offset value is 0, the UE monitoring window of Type-0 PDCCH of OD-SIB1 and RAR window can be either partially or fully overlapped. 

Proposal-4: For the case of the time offset value is positive (>0), the UE monitoring window of Type-0 PDCCH of OD-SIB1 and RAR window can be either partially or no overlapped. 

Proposal-5: For the case of the time offset value is negative (<0), the UE monitoring window of Type-0 PDCCH of OD-SIB1 and RAR window can be partially overlapped.

Proposal-8: If configuration of SearchSpace#0 and CORESET#0 are fully overlapped for UE monitoring of
RAR and Type-0 PDCCH of OD-SIB1, especially when both RAR and Type-0 PDCCH of OD-SIB1
windows are overlapped. RAN1 shall discuss the corresponding UE monitoring behavior.

Fujitsu:
Proposal 4. The time offset to determine the starting time of the time window for type 0 PDCCH monitoring of on-demand SIB1 is indicated by ra-ResponseWindow in UL WUS configuration.

vivo
Proposal 4: If NES cell indicates a WUS configuration applying to NES cell itself, some parameters can follow the corresponding values in the SIB1 of NES cell itself to further reduce the payload of WUS configuration.

Proposal 6: Add offsetToPointA into WUS configuration to avoid changing the legacy mechanism in deriving UL point A in TDD system.

Proposal 7: ra-PreambleStartIndex, od-sib1-duration, offsetToTimeWindow and ssb-SubcarrierOffset is mandatorily configured in WUS configuration from RAN1 perspective.

Proposal 14: support the following change for row 14.


Proposal 15: support the following change for row 33-34.


Google
Proposal 1: Support to configure an initial downlink BWP by the UL-WUS configuration.
The NW can transmit the RAR and on-demand SIB1 based on the bandwidth of the initial downlink BWP.

NEC
Proposal 7: The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity). 

Huawei/HiSilicon
Observation 1: For the UE with WUS configuration, the term k1 in the PRACH baseband signal generation of section 5.3.2 of TS38.211 is not known if  is not included in the UL WUS configuration.

Proposal 2: For PRACH baseband signal generation of section 5.3.2 of TS38.211, CarrierBandwidth is included in the UL-WUS configuration to enable the UE to calculate k1. Otherwise, RAN1 clarifies how the UE determines k1.

Proposal 3: For initial uplink BWP related parameters, initial uplink BWP configuration is included in UL WUS configuration. Otherwise, RAN1 clarifies how to determine the initial UL BWP and how to ensure the center frequency alignment for TDD.

Proposal 4: RAN1 clarifies frequencyBandList in UL WUS configuration refers to the IE within FrequencyInfoUL-SIB.

Proposal 5: Search space configuration provided by the IE of SearchSpace is included in the UL WUS configuration to configure the RAR search space. If not included, the RAR search space is the Search Space 0. 
ControlResourceSetId in SearchSpace IE is 0.

Proposal 6: For the RAR search space configured by ra-SearchSpace in PDCCH-ConfigCommon in SIB1 and the RAR search space configured by UL WUS configuration, RAN1 discusses whether they should be the same or can be different.

Samsung
Proposal 3: Support the following additional RRC parameters in UL WUS configuration to configure UL WUS resource and generate UL WUS signal as legacy: 
locationAndBandwidth and cyclicPrefix for the initial BWP including UL WUS transmission.

Xiaomi
Proposal 3: For parameters agreed for UL WUS, they are mandatory.

FL Proposal 5-1 (Panasonic, vivo)
In the UL WUS configuration, support a list of NES-CellId, i.e., replace NES-CellId with NES-CellIdList.


FL Proposal 5-1-2 
In the UL WUS configuration, how to support multiple NES-CellId(s) is up to RAN2 discussion.


FL Proposal 5-2 (Google)
Include initialDownlinkBWP in the UL-WUS configuration.
Note: The NW can transmit the RAR and on-demand SIB1 based on the bandwidth of the initial downlink BWP.

FL Proposal 5-3 (Samsung)
Include locationAndBandwidth and cyclicPrefix in the UL-WUS configuration.


FL Proposal 5-4 (vivo)
Include offsetToPointA in the UL-WUS configuration for TDD system to avoid changing the legacy mechanism in deriving UL point A in TDD system.


FL Proposal 5-5 (vivo)
Support the following change in the current RRC table (R1-2501645).


FL Proposal 5-6 (ETRI)
For agreed UL WUS parameters, follow the legacy specification regarding its mandatory or optional presence unless otherwise agreed.


FL Proposal 5-7 (ETRI/vivo/MTK)
For agreed UL WUS parameters, regarding their mandatory or optional presence and applicability to TDD and/or FDD, adopt the followings:
PhysCellId and ARFCN-ValueNR are mandatory
frequencyBandList and absoluteFrequencyPointA are present in IE FrequencyInfoUL only for FDD (as in the legacy specification)
K_SSB is mandatory
searchSpaceZero and controlResourceSetZero are mandatory
od-sib1-duration is mandatory
ra-PreambleStartIndex, od-sib1-duration, offsetToTimeWindow and ssb-SubcarrierOffset are mandatory


FL Proposal 5-8 (Ericsson)
The parameter ra-SearchSpace in the UL-WUS configuration should be of type SearchSpace.


FL Proposal 5-9 (Ericsson)
Replace the current parameter name offsetToTimeWindow with od-sib1-windowStartOffset (to make the naming more comprehensive).


FL Proposal 5-10 (Ericsson/NEC)
RAN1 to discuss the value range for od-sib1-duration. For example,
Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point.
Option 2: The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity).
Other options are not precluded.


FL Proposal 5-10-2 (Ericsson/NEC/ZTE)
RAN1 to discuss the value range for od-sib1-duration. For example,
Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point.
Option 2: The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity).
Option 3: The duration of the time window can be a multiple of the on-demand SIB1 periodicity
Other options are not precluded.

FL Proposal 5-11 (Nokia)
The value of the time offset between the reference time point and the starting time for the time window of OD-SIB1 can be either 0, positive value, or negative value.


FL Proposal 5-11-2 
The value of the time offset between the reference time point and the starting time for the time window of OD-SIB1 can be either 0 or positive value.


FL Proposal 5-11-3
The value of the time offset between the reference time point and the starting time for the time window of OD-SIB1 can be only positive value.

FL Proposal 5-12 (Huawei)
RAN1 clarifies frequencyBandList in UL WUS configuration refers to the IE within FrequencyInfoUL-SIB.


FL Proposal 5-13 (Need to revert previous RAN1 #120 conclusion) (Huawei)
Include CarrierBandwidth and locationAndBandwidth in the UL-WUS configuration. to enable the UE to calculate k1.
Note: For the UE with UL-WUS configuration, the term k1 in the PRACH baseband signal generation of section 5.3.2 of TS38.211 is not known if  is not included in the UL WUS configuration.
The previous agreement is updated as:
Msg1-FrequencyStart is with respect to the first RB of the UE carrier InitialUplinkBWP determined by locationAndBandwidth offsetToCarrier and absoluteFrequencyPointA
\
Figure from [13, Huawei]

FL Proposal 5-13-1 (Need to revert previous RAN1 #120 conclusion) 
Include CarrierBandwidth and locationAndBandwidth in the UL-WUS configuration. 

FL Proposal 5-13-2 
The previous RAN1 #118-bis agreement is updated as:
Msg1-FrequencyStart is with respect to the first RB of the UE carrier InitialUplinkBWP determined by locationAndBandwidth offsetToCarrier and absoluteFrequencyPointA

FL Proposal 5-14 (Need to revert previous RAN1 #120 conclusion) (Huawei)
Include initialUplinkBWP in the UL-WUS configuration.
Otherwise, RAN1 clarifies how to determine the initial UL BWP and how to ensure the center frequency alignment for TDD system.


FL Proposal 5-15 (Need to revert previous RAN1 #120 conclusion) (Tejas)
Include TotalNumberOfRA-Preambles in the UL-WUS configuration


FL Proposal 5-15-2 (Need to revert previous RAN1 #120 conclusion) (Tejas)
It is up to RAN2 to determine whether to include TotalNumberOfRA-Preambles in the UL-WUS configuration.

FL Proposal 5-16 
Indication of K_SSB value in the UL-WUS configuration should be ssb-SubcarrierOffset, combined with PBCH payload, as in legacy. 

https://howltestuffworks.blogspot.com/2019/10/5g-nr-pbch-and-master-information-block.html 


FL Proposal 5-16-2
Indication of K_SSB value in the UL-WUS configuration should be 5 bits for FR1 and 4 bits for FR2.
Note: there is no change to current PBCH structure.

https://howltestuffworks.blogspot.com/2019/10/5g-nr-pbch-and-master-information-block.html 


Issue 6: UL-WUS on NES cell overlapping with paging occasion on normal cell
Background
The following proposals are brought up in RAN1 #120-bis:

MTK
Proposal 3: A potential issue of paging dropping may arise if UL-WUS on NES cell overlapped with paging occasion on Cell A as shown in Figure 1. RAN1 can further discuss how to solve this issue.

Figure 1. An Example of UL-WUS on NES cell overlapped with paging occasion on normal cell

Ericsson:
Observation 7 Constant overlapping paging occasions in Cell A with UL WUS occasions in the NES Cell is an example of poor network configuration.

Proposal 7 No action is necessary to be specified for collision with paging as the issue can be resolved with appropriate network configuration.

ZTE
Proposal 6: UE behavior on the overlapped resources between UL WUS in NES cell and paging occasions on cell A can be up to UE implementation.

Ofinno
Proposal 4: If a paging occasion (PO) on Cell A and OD-SIB1 procedures (e.g., a WUS transmission, RAR window, or OD-SIB1 window) in an NES cell collide/overlap with each other, then the UE is allowed to skip the PO and perform OD-SIB1 procedure on NES cell.

OPPO
Proposal 3: RAN1 to discuss the UE behavior for case Cell A switching to NES Cell.

For this topic, companies’ views in RAN1 #120-bis are summarized below
What should UE do if UL-WUS on NES cell overlapped with paging occasion on Cell A
Up to UE implementation: Ericsson (can be resolved with appropriate network configuration), ZTE
UE prioritizes receiving the paging occasion from Cell A: MTK
UE prioritizes transmitting the UL WUS to NES cell: Ofinno

Moderator suggests the following proposal with slight majority:
FL Proposal 6-1
It is up to UE implementation to prioritize receiving the paging occasion from Cell A or transmitting the UL WUS to NES cell, if the UL-WUS occasions on NES cell overlapped with the paging occasion on Cell A.

Figure example of UL-WUS on NES cell overlapped with paging occasion on Cell A from [29, MediaTek]

Issue 7: Validicity of UL WUS configuration
Background
The following proposals are brought up in RAN1 #120-bis:

CATT:
Proposal 14: How to ensure the validity of UL WUS configuration received from cell A should be studied.  


CEWiT:
Observation  3:  On-demand SIB1 impacts the need and validity of periodic RACH occasions and their association with SSBs, requiring adjustments to ensure efficient RRC connection establishment.

FL Proposal 7-1
RAN1 to further study how to ensure the validity of UL WUS configuration received from Cell A when the UL WUS configuration is updated and exchanged between Cell A and NES cell.

Figure from [7, CATT]


FL Proposal 7-1-2
It is up to RAN2 to discuss how to ensure the validity of UL WUS configuration received from Cell A when the UL WUS configuration is updated and exchanged between Cell A and NES cell.

Figure from [7, CATT]


Issue 8: UE to monitor the RAR for SIB1 requests sent by other UEs
Background
The following proposals are brought up in RAN1 #120-bis:

LG:
Proposal #4: To support UEs to monitor the RAR for SIB1 requests sent by other UEs, the following 
methods can be considered: 
1)  UE  monitors  DCI  scrambled  by  RA-RNTI  which  is  associated  with  RO  allocated  for  on-
demand SIB1 but not associated with RO containing PRACH transmitted by UE   
2)  Introduce  a  new  RNTI  (i.e.,  cell-specific  or  beam-specific  RNTI)  to  monitor  RAR 
corresponding to UL WUS for requesting SIB1 
3) Use only PDCCH (i.e., without RAR MAC CE) as the RAR where the PDCCH contains RAPID 
directly

Nokia
Proposal-10: RAN1 confirms that the RNTI is common for all UEs for requesting of OD-SIB1 operation based on the common PRACH resource occasion configured in UL WUS configuration.

Proposal-11: RAN1 to discuss the UE monitoring of OD-SIB1 that was earlier requested by other UEs before sending its own UL WUS for requesting SIB1.

FL Proposal 8-1
Support UE to monitor the RAR for SIB1 requests sent by other UEs and down select from the following options:
Option1: UE monitors DCI scrambled by RA-RNTI which is associated with RO allocated for on-demand SIB1 but not associated with RO containing PRACH transmitted by UE.
Option 2: Introduce a new RNTI (i.e., cell-specific or beam-specific RNTI) to monitor RAR corresponding to UL WUS for requesting SIB1.
Option 3: Use only PDCCH (i.e., without RAR MAC CE) as the RAR where the PDCCH contains RAPID directly.
FFS: Under which conditions should UE send its own UL WUS if UE can monitor the RAR for SIB1 requests sent by other UEs


Issue 9: Relation between OD-SIB1 monitoring window and RAR window
Background
In RAN1 #120, it is agreed that:

Agreement
The reference time point to determine the window starting time for on-demand SIB1 is based on the starting slot of the RAR window for UL WUS wherein UE successfully received a RAR.

In RAN2 #129, it is agreed that:
Agreement
Upon reception of RAR, the UE monitors OD-SIB1 in the window agreed by RAN1.

Companies’ views for this topic in RAN1 #120-bis are collected below:

Apple:
Proposal 2: Confirm that even after the start time of the OD-SIB1 monitoring window, UE is not required to monitor PDCCH in search space zero before UE successfully received its RAR.  

Figure from [25, Apple] to illustrate relation between OD-SIB1 monitoring window and RAR window


Nokia:
Proposal-6: RAN1 shall discuss the UE monitoring behavior when both RAR and Type-0 PDCCH of ODSIB1 monitoring windows are applied.

Observation-1: It is not necessary for UE to always detect both RAR and Type-0 PDCCH of OD-SIB1,
especially when both windows are overlapped.

Observation-2: In case when UE has successfully received the Type-0 PDCCH of OD-SIB1, the monitoring and reception of RAR by UE could simply be ignored, which also benefit for UE power saving.

Proposal-7: The monitoring and reception of RAR by UE could be ignored when UE has successfully received the Type-0 PDCCH of OD-SIB1.

vivo:
Proposal 8: Considering the time requirements for RAR reception, RAR decoding and preparation for monitoring, UE starts actual Type 0 PDCCH monitoring from the later one between X time units after RAR reception and offsetToTimeWindow slots after reference point.


FL Proposal 9-1
UE is not required to monitor PDCCH in search space zero before UE successfully received its RAR even after the start time of the OD-SIB1 monitoring window.

Figure from [25, Apple] to illustrate relation between OD-SIB1 monitoring window and RAR window


FL Proposal 9-1-2
It is up to UE implementation to monitor PDCCH in search space zero for OD-SIB1 before UE successfully received its RAR.

FL Proposal 9-1-3
It is up to UE implementation to monitor PDCCH in search space zero for OD-SIB1 outside the OD-SIB1 window after UE transmits UL-WUS.

FL Proposal 9-1-4
After transmitting the UL-WUS, UE is not required to monitor Type0-PDCCH occasion before UE successfully received its RAR.

Figure from [25, Apple] to illustrate relation between OD-SIB1 monitoring window and RAR window

FL Proposal 9-2
After transmitting the UL WUS, UE starts Type 0 PDCCH monitoring from the later one between X time units after RAR reception and offsetToTimeWindow slots after reference time point.
FFS: Value of X and its unit to address UE processing time for RAR reception, RAR decoding, and preparation for PDCCH monitoring.

Figure to illustrate RAR processing from [4, vivo]


FL Proposal 9-2-2 (LG revision)
After transmitting the UL WUS, UE starts Type 0 PDCCH monitoring at the first symbol of the earliest CORESET the UE is configured to receive PDCCH for Type 0 PDCCH CSS set, from the later one between X time units after RAR reception and offsetToTimeWindow slots after reference time point.
FFS: Value of X and its unit to address UE processing time for RAR reception, RAR decoding, and preparation for PDCCH monitoring.

Figure to illustrate RAR processing from [4, vivo]

FL Proposal 9-3
The monitoring and reception of RAR by UE could be ignored when UE has successfully received the Type-0 PDCCH of OD-SIB1.

Figure example from [3, Nokia]


Issue 10: UE behaviors inside the OD-SIB1 time window
Background
In RAN1 #118b, it is agreed that:
Agreement
For the repetition periodicity of SIB1 within the time window of on-demand SIB1:
Up to NW implementation (no change to existing specification)

Moderator Note (to Fujitsu Proposal 3 below): 38.331 Clause 5.2.1 has the following text on SIB1 repetition periodicity
the SIB1 is transmitted on the DL-SCH with a periodicity of 160 ms and variable transmission repetition periodicity within 160 ms as specified in TS 38.213 [13], clause 13. The default transmission repetition periodicity of SIB1 is 20 ms but the actual transmission repetition periodicity is up to network implementation. For SSB and CORESET multiplexing pattern 1, SIB1 repetition transmission period is 20 ms. For SSB and CORESET multiplexing pattern 2/3, SIB1 transmission repetition period is the same as the SSB period (TS 38.213 [13], clause 13).

In RAN1 #120, it is agreed that:

Agreement
The reference time point to determine the window starting time for on-demand SIB1 is based on the starting slot of the RAR window for UL WUS wherein UE successfully received a RAR.

Agreement
The time offset between the reference time point and the starting time for the time window of on-demand SIB1 is indicated in the UL WUS configuration.
Unit of the time offset is in slot


Figure. Reference time point and time offset to OD-SIB1 window (revised from [R1-2408856, Qualcomm])

Companies’ views for this topic in RAN1 #120-bis are collected below:

Huawei/HiSilicon
Proposal 1: The reference time point to determine the starting slot of on-demand SIB1 window is the slot containing the starting symbol of RAR window.
The start of the OD-SIB1 window is at least one symbol after the UL WUS transmission.

vivo
Proposal 9: UE stops monitoring Type 0 PDCCH at the end of time window for on-demand SIB1, and the time window for on-demand SIB1 starts at offsetToTimeWindow slots after reference point.

LG:
Proposal #5: Clarify whether the time window of OD-SIB1 starts immediately after the time offset from   the   reference   time   point   or   it   starts   from   the   OD-SIB1   MO   (i.e.,   Type   0   PDCCH   MO) corresponding to SSB index associated with UL WUS transmitted by the UE.


Fujitsu:
Proposal 3. RAN1 to discuss the UE assumption on on-demand SIB1 repetitions within the time window. The following two alternatives can be considered.
Alt 1. UE assumes that the SIB1 transmitted within the time window are all repetitions. 
Alt 2. UE assumes that the SIB1 transmitted within the time window follows the mechanism of repetition within a 160 ms period.

Proposal 5. The time window for on-demand SIB1 starts at the first type 0 PDCCH monitoring occasion after the time offset ends. Regarding the first type 0 PDCCH monitoring occasion, the following three options can be considered.
Option 1. the type 0 PDCCH occasion corresponds to SSB index 0 
Option 2. the type 0 PDCCH occasion corresponds to the first SSB index of the transmitted SSBs
Option 3. the type 0 PDCCH occasion corresponds to the SSB index associated with the transmitted UL WUS
Note: the above options refer to the type 0 PDCCH occasion in the first slot for corresponding SSB indexes in the case of multiplexing pattern 1.

Sony
Proposal 2: The transmission time of the on-demand SIB1 on the NES cell should be restricted into one time window.

ZTE
Proposal 5: The transmission of the updated SIB1 on the NES cell should be within a time window.

FL Proposal 10-1 (from Huawei)
The reference time point to determine the window starting time for on-demand SIB1 is based on the slot containing the starting symbol of RAR window for UL WUS wherein UE successfully received a RAR.
The window starting time for on-demand SIB1 is at least one symbol after the UL WUS transmission.





FL Proposal 10-1-2 
The reference time point to determine the window starting time for on-demand SIB1 is based on the slot containing the starting symbol of RAR window for UL WUS wherein UE successfully received a RAR.
FFS: The window starting time for on-demand SIB1 is at least one symbol after the UL WUS transmission.

FL Proposal 10-2 (from vivo)
UE stops monitoring Type 0 PDCCH at the end of time window for on-demand SIB1.
UE should receive the PDSCH for on-demand SIB1 outside the time window if its corresponding Type 0 PDCCH is located inside the time window for on-demand SIB1.


FL Proposal 10-3 (to address LG/Fujitsu Proposal 5 above)
The time window of OD-SIB1 starts immediately after the time offset from the reference time point.

Figure. Reference time point and time offset to OD-SIB1 window (revised from [R1-2408856, Qualcomm])


FL Proposal 10-3-2 (to address LG/Fujitsu Proposal 5 above)
The time window of OD-SIB1 starts immediately after the time offset from the reference time point.
The actual time UE starts PDCCH monitoring is the first type 0 PDCCH monitoring occasion where PDCCH for an OD-SIB1 message can be transmitted.

Figure. Reference time point and time offset to OD-SIB1 window (revised from [R1-2408856, Qualcomm])

Figure from [20, LG]

FL Proposal 10-4 (to address Sony/ZTE Proposal 2/5 above)
The transmission time of the on-demand SIB1 on the NES cell is restricted in one time window.

Figure. Reference time point and time offset to OD-SIB1 window (revised from [R1-2408856, Qualcomm])

Issue 11: Whether other features such as RedCap and NR-U can be combined with OD-SIB1
Background
The following proposals are brought up in RAN1 #120-bis:

vivo:
Proposal 13: Whether some other features such as RedCap and NRU can be combined with OD-SIB1 needs discussion.

FL Proposal 11-1
RAN1 to further study whether the R19 OD-SIB1 feature can work with legacy RedCap features.


FL Proposal 11-2
RAN1 to further study whether R19 OD-SIB1 feature can work with legacy NR-U features.


Issue 12: RO selection based on rsrp-ThresholdSSB
Background
The following proposals are brought up in RAN1 #120-bis:

Google
Proposal 2: Support the UE to select the RO based on the SSB with lowest index among the SSBs that can meet the rsrp-ThresholdSSB requirement.

Proposal 3: If the UE cannot identify any SSB with RSRP higher than rsrp-ThresholdSSB, it should not transmit the PRACH for on-demand SIB1.

Sony:
Proposal 3: For selecting SSB from NES cell for OD-SIB1 request, UE can select any SSB if none of the measured SSBs are above the RSRP threshold (per legacy)

FL Proposal 12-1 (from Google)
UE selects RO based on the SSB with lowest index among the SSBs that can meet the rsrp-ThresholdSSB requirement.


FL Proposal 12-2 (from InterDigital)
For selecting SSB from NES cell for OD-SIB1 request, UE can select any SSB if none of the measured SSBs are above the RSRP threshold (per legacy).


Issue 13: KSSB value within one MIB transmission time interval (80ms)
Background
The following proposals are brought up in RAN1 #120-bis:

Nokia
Observation-9: Based on TS38.212, UE is not expecting change of MIB payload within one MIB TTI of 80ms.

Proposal-25: RAN1 to consider that the network switching between broadcasting SIB1 and on-demand SIB1 is at least 80ms via MIB indication, meaning that UE expects the same value of K_SSB within 80ms.

OPPO
Proposal 2: For time window configuration and determination, the following restrictions should be discussed:
If SIB1 being broadcast in time window will provoke a change of K_SSB value, the time window should be aligned with SI modification period.
 If SIB1 being broadcast in time window will provoke a change of PBCH payload, the time window should be aligned with 80 ms MIB period.

To moderator’s understanding, K_SSB value may need to be updated when the network switches between broadcasting SIB1 and on-demand SIB1, and K_SSB is indicated in MIB. The following proposal is hence suggested:
FL Proposal 13-1 (from Nokia)
The network switching between broadcasting SIB1 and on-demand SIB1 is at least 80ms via MIB indication, meaning that UE expects the same value of K_SSB within 80ms.



FL Proposal 13-1-2 
The network switching between SIB1 is currently being broadcasted or provided on demand is at least 80ms via MIB indication, meaning that UE expects the same value of K_SSB within 80ms.


FL Proposal 13-1-3 
The network switching between SIB1 is currently being broadcasted or provided on demand is at least the SI modification period, meaning that UE expects the same value of K_SSB within one SI modification period.


Issue 14: UE receives SI change indication when SIB1 is not being transmitted
Background
The following proposals are brought up in RAN1 #120-bis:

CATT:
Proposal 9: When the NES cell is in NES state without periodic SIB1 transmission and UE receives SI change indication or etwsAndCmasIndication, the following UE behaviors can be considered.
Alt 1: If a UE receives SI change indication or the etwsAndCmasIndication bit of Short Message is set, the UE assumes that the NES cell switches from “SIB1 is provided on demand” to “SIB1 is currently being broadcasted”.
Alt 2: If a UE receives SI change indication, the UE assumes that the updated SIB1 will be transmitted within a time window starting from the next modification period. •
Alt 3: If a UE receives Short Message at its PO and the etwsAndCmasIndication bit of Short Message is set, the UE re-acquire the SIB1 within a time window after its PO.

FL Proposal 14-1
When the NES cell is in NES state without periodic SIB1 transmission and UE receives SI change indication or etwsAndCmasIndication, down select from the following UE behaviors.
Alt 1: If a UE receives SI change indication or the etwsAndCmasIndication bit of Short Message is set, the UE assumes that the NES cell switches from “SIB1 is provided on demand” to “SIB1 is currently being broadcasted”.
Alt 2: If a UE receives SI change indication, the UE assumes that the updated SIB1 will be transmitted within a time window starting from the next modification period. •
Alt 3: If a UE receives Short Message at its PO and the etwsAndCmasIndication bit of Short Message is set, the UE re-acquire the SIB1 within a time window after its PO.


FL Proposal 14-1-2
It is up to RAN2 to discuss the UE behavior when the NES cell is in NES state without periodic SIB1 transmission and UE receives SI change indication or etwsAndCmasIndication.


Issue 15: Other topics
Discussion place holder for issues not included above.
FL Proposal 15-1
Companies are invited to bring up other proposals which (you think) should be treated in this meeting. Moderator would try to devise further discussion based on received comments.
Proposal receiving support/attention from multiple companies would be visited first.


Resulted RAN1 conclusion/agreement
TBD.


4 References (all from RAN1 #120-bis)
R1-2501714	Discussion of on-demand SIB1 for idle/inactive mode UEs	FUTUREWEI
R1-2501765	Discussion on on-demand SIB1 for NES	ZTE Corporation, Sanechips
R1-2501773	On-demand SIB1 for Idle/Inactive mode UEs	Nokia, Nokia Shanghai Bell
R1-2501811	Discussions on on-demand SIB1 for idle/inactive mode UEs	vivo
R1-2501873	Discussion on on-demand SIB1 for idle/inactive mode UEs	Spreadtrum, UNISOC
R1-2501953	On-demand SIB1 for Idle/Inactive Mode UE	Google
R1-2501997	Discussion on on-demand SIB1	CATT
R1-2502027	Discussion on on-demand SIB1 for idle/inactive mode UEs	China Telecom
R1-2502045	Discussion on on-demand SIB1 for idle/inactive mode UEs	Ofinno
R1-2502128	Discussion on on-demand SIB1 transmission for network energy savings	Fujitsu
R1-2502165	Discussion on on-demand SIB1 for UEs in idle/inactive mode	CMCC
R1-2502199	Discussion on on-demand SIB1 for UEs in idle/inactive mode	NEC
R1-2502230	Discussion on on-demand SIB1 for eNES	Huawei, HiSilicon
R1-2502262	Discussion on the enhancement to support on demand SIB1 for idle/inactive mode UE OPPO
R1-2502321	On-demand SIB1 for idle/inactive mode UEs	Sony
R1-2502335	Discussion on on-demand SIB1 for idle/inactive mode UEs	InterDigital, Inc.
R1-2502373	On-demand SIB1 for idle/inactive mode UEs	Samsung
R1-2502446	Discussion on on-demand SIB1 for idle/inactive mode UEs	Xiaomi
R1-2502469	OD-SIB1 for Idle/Inactive UEs	Tejas Network Limited
R1-2502479	On-demand SIB1 for idle/inactive mode UEs	LG Electronics
R1-2502514	On-demand SIB1 for idle/inactive mode UEs	ETRI
R1-2502543	Discussion on on-demand SIB1 transmission for idle/inactive mode UEs Transsion Holdings
R1-2502570	On-demand SIB1 for idle/inactive mode UEs	Lenovo
R1-2502579	Discussion on on-demand SIB1 for idle/inactive mode UEs	Panasonic
R1-2502613	On On-demand SIB1 for IDLE/INACTIVE mode UEs	Apple
R1-2502658	On-demand SIB1 for NES	Fraunhofer IIS, Fraunhofer HHI
R1-2502678	Remaining details for OD-SIB1 request	ASUSTeK
R1-2502681	Discussion on on-demand SIB1 transmission for idle UEs	Sharp
R1-2502709	On-demand SIB1 for idle or inactive mode UEs	MediaTek Inc.
R1-2502750	Discussion on on-demand SIB1 for idle/inactive mode UEs	DENSO CORPORATION
R1-2502771	Discussion on on-demand SIB1 for idle/inactive mode UEs	NTT DOCOMO, INC.
R1-2502803	On-demand SIB1 for UEs in idle/inactive mode for NES	Ericsson
R1-2502844	On-demand SIB1 procedure	Qualcomm Incorporated
R1-2502918	Discussion on  on-demand SIB1	CEWiT
R1-2502921	Discussion on on-demand SIB1 in idle/inactive mode	CAICT

3GPP TSG RAN WG1 #120bis							   R1-2503008
Wuhan, China, April 7th – 11th, 2025

Source:	Moderator (MediaTek)
Title:	FL summary 5 for on-demand SIB1 in idle/inactive mode
Agenda item:	9.5.2
Document for:	Discussion and Decision

Conclusion
There is no RAN1 consensus to support SSB with on-demand SIB1 not on sync raster. 

Agreement
The following agreement is updated as follows:
The UE assumes that, in the OD-SIB1 window, PDCCH for an OD-SIB1 message is transmitted in PDCCH monitoring occasions corresponding only to at least the SSB associated with the transmitted PRACH for UL-WUS if this is indicated via UL WUS configuration by a 1-bit indication
If the 1-bit indication is included in UL WUS config and indicate as TRUE, the UE assumes that, in the OD-SIB1 window, PDCCH for an OD-SIB1 message is transmitted in PDCCH monitoring occasions corresponding only to the SSB associated with the PRACH for UL-WUS.
If the 1-bit indication is not included in UL WUS config or the 1-bit indication is FALSE, the UE assumes the same as legacy, i.e., in the OD-SIB1 window, PDCCH for an OD-SIB1 message is transmitted in at least one PDCCH monitoring occasion corresponding to each transmitted SSB.
Further study possible down selection from the following options to indicate additional information related to SSBs associated with PDCCH monitoring occasions
Alt1: The information is provided in UL-WUS config
Alt2: The information is provided in RAR in response to UL-WUS transmission
Alt3: No additional information is provided

Agreement
Indication of K_SSB value in the UL-WUS configuration should be 5 bits for FR1 and 4 bits for FR2.
Note: there is no change to current PBCH structure.
UE does not expect K_SSB to be larger than 23 for FR1 and larger than 11 for FR2

Agreement
The value of the time offset between the reference time point and the starting time for the time window of OD-SIB1 can be either 0 or positive value.

Agreement
After transmitting a UL-WUS, UE is not required to monitor Type0-PDCCH occasion (for OD-SIB1) before UE successfully received its RAR in response to the UL WUS.

Agreement
If a UE has SIB1 request configuration of a cell and before transmitting UL WUS,
If the UE detects a SSB where K_SSB>=24 for FR1 or K_SSB>=12 for FR2, select the following:
Alt. 3: It is up to UE implementation on whether to monitor Type 0 PDCCH for SIB1 transmission

Agreement
In the UL WUS configuration, how to support multiple NES-CellId(s) is up to RAN2 discussion.

Agreement
From RAN1 perspective, for agreed UL WUS parameters, regarding their mandatory or optional presence and applicability to TDD and/or FDD, adopt the followings:
PhysCellId and ARFCN-ValueNR are mandatory
frequencyBandList and absoluteFrequencyPointA are present in IE FrequencyInfoUL for FDD (as in the legacy specification)
K_SSB is mandatory
searchSpaceZero and controlResourceSetZero are mandatory
ra-PreambleStartIndex, od-sib1-duration, offsetToTimeWindow are mandatory

Agreement
The parameter ra-SearchSpace in the UL-WUS configuration is of type SearchSpace.

Agreement
Replace the current parameter name offsetToTimeWindow with od-sib1-windowStartOffset (to make the naming more comprehensive).

Agreement
Include CarrierBandwidth and locationAndBandwidth in the UL-WUS configuration. 
Previous RAN1 #120 conclusion is reverted

Agreement
The following previous RAN1 #118-bis agreement is updated as:
Msg1-FrequencyStart is with respect to the first RB of the UE carrier InitialUplinkBWP determined by locationAndBandwidth offsetToCarrier and absoluteFrequencyPointA (same as legacy)

Agreement
RAN1 to discuss the value range for od-sib1-duration. For example,
Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point.
Option 2: The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity).
Option 3: The duration of the time window can be a multiple of the on-demand SIB1 repetition periodicity (if supported)
Other options are not precluded.

Agreement
RAN1 clarifies frequencyBandList in UL WUS configuration refers to the IE within FrequencyInfoUL-SIB.
4 References (all from RAN1 #120-bis)
R1-2501714	Discussion of on-demand SIB1 for idle/inactive mode UEs	FUTUREWEI
R1-2501765	Discussion on on-demand SIB1 for NES	ZTE Corporation, Sanechips
R1-2501773	On-demand SIB1 for Idle/Inactive mode UEs	Nokia, Nokia Shanghai Bell
R1-2501811	Discussions on on-demand SIB1 for idle/inactive mode UEs	vivo
R1-2501873	Discussion on on-demand SIB1 for idle/inactive mode UEs	Spreadtrum, UNISOC
R1-2501953	On-demand SIB1 for Idle/Inactive Mode UE	Google
R1-2501997	Discussion on on-demand SIB1	CATT
R1-2502027	Discussion on on-demand SIB1 for idle/inactive mode UEs	China Telecom
R1-2502045	Discussion on on-demand SIB1 for idle/inactive mode UEs	Ofinno
R1-2502128	Discussion on on-demand SIB1 transmission for network energy savings	Fujitsu
R1-2502165	Discussion on on-demand SIB1 for UEs in idle/inactive mode	CMCC
R1-2502199	Discussion on on-demand SIB1 for UEs in idle/inactive mode	NEC
R1-2502230	Discussion on on-demand SIB1 for eNES	Huawei, HiSilicon
R1-2502262	Discussion on the enhancement to support on demand SIB1 for idle/inactive mode UE OPPO
R1-2502321	On-demand SIB1 for idle/inactive mode UEs	Sony
R1-2502335	Discussion on on-demand SIB1 for idle/inactive mode UEs	InterDigital, Inc.
R1-2502373	On-demand SIB1 for idle/inactive mode UEs	Samsung
R1-2502446	Discussion on on-demand SIB1 for idle/inactive mode UEs	Xiaomi
R1-2502469	OD-SIB1 for Idle/Inactive UEs	Tejas Network Limited
R1-2502479	On-demand SIB1 for idle/inactive mode UEs	LG Electronics
R1-2502514	On-demand SIB1 for idle/inactive mode UEs	ETRI
R1-2502543	Discussion on on-demand SIB1 transmission for idle/inactive mode UEs Transsion Holdings
R1-2502570	On-demand SIB1 for idle/inactive mode UEs	Lenovo
R1-2502579	Discussion on on-demand SIB1 for idle/inactive mode UEs	Panasonic
R1-2502613	On On-demand SIB1 for IDLE/INACTIVE mode UEs	Apple
R1-2502658	On-demand SIB1 for NES	Fraunhofer IIS, Fraunhofer HHI
R1-2502678	Remaining details for OD-SIB1 request	ASUSTeK
R1-2502681	Discussion on on-demand SIB1 transmission for idle UEs	Sharp
R1-2502709	On-demand SIB1 for idle or inactive mode UEs	MediaTek Inc.
R1-2502750	Discussion on on-demand SIB1 for idle/inactive mode UEs	DENSO CORPORATION
R1-2502771	Discussion on on-demand SIB1 for idle/inactive mode UEs	NTT DOCOMO, INC.
R1-2502803	On-demand SIB1 for UEs in idle/inactive mode for NES	Ericsson
R1-2502844	On-demand SIB1 procedure	Qualcomm Incorporated
R1-2502918	Discussion on  on-demand SIB1	CEWiT
R1-2502921	Discussion on on-demand SIB1 in idle/inactive mode	CAICT