3GPP TSG RAN WG1 #121	R1-2503234
St Julian’s, Malta, May 19th – 23rd, 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: Support Alt 3: No additional information is provided to indicate additional information related to SSBs associated with PDCCH monitoring occasions.
Proposal 2: Support Option 2: The value range for od-sib1-duration can be a multiple of 160ms.
Proposal 3: In the absence of supporting performance evaluations for NR-U, and considering LBT complexity, we recommend excluding OD-SIB1 for NR-U in Rel-19.
Observation 1: The R19 OD-SIB1 feature requires changes of the legacy RedCap initial access.
Proposal 4: If RAN1 supports R19 OD-SIB1 feature for RedCap UEs, provide in UL WUS configuration information on RedCap barring access to the NES cell.

3GPP TSG-RAN WG1 Meeting #121	R1-2503268
St Julian’s, Malta, May 19th – 23rd, 2025
 
Agenda item:		9.5.2
Source:		Huawei, HiSilicon
Title:		Discussion on on-demand SIB1 for eNES
Document for:		Discussion and Decision

Conclusions
In this paper, we have the following proposals:
Adopt TP#1 to clarify the reference time point to determine the starting slot of on-demand SIB1 window is the slot containing the starting symbol of RAR window.
---------------------------------------------------------------------Start of TP#1------------------------------------------------------------
23	 UE procedure to request SIB1 reception

If the UE identifies a RAPID associated with a corresponding PRACH transmission from the UE in a PDSCH reception scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI, the UE can be indicated by higher layers to monitor PDCCH on the second cell to detect a DCI format 1_0 with CRC scrambled by the SI-RNTI according to a Type0-PDCCH CSS set provided by SearchSpaceZero. If the UE is provided XYZ, the UE monitors PDCCH only in monitoring occasions associated with the SS/PBCH block. The UE starts monitoring PDCCH to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI after a number of slots provided by od-sib1-windowStartOffset from the starting slot containing the starting symbol of the window controlled by ra_ResponseWindow, and for a number of slots provided by od-sib1-WindowDuration.
---------------------------------------------------------------------End of TP#1--------------------------------------------------------------
Support Alt3, i.e., no additional information is provided to indicate additional information related to SSBs associated with PDCCH monitoring occasions.
Support to use the value-range for si-windowLength (from 5 slots to 5120 slots) as the value range for od-sib1-duration.

3GPP TSG RAN WG1 meeting #121		                                   R1-2503316
St Julian’s, Malta, May 19th – 23rd, 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: The motivation to indicate additional information related to SSBs associated with PDCCH monitoring occasions is not clear.
Observation 2: The gNB does not know which beams other than the beam corresponding to UL WUS have better performance.
Observation 3: Alt 1 leads to frequent UL WUS configuration updates, increases the interaction between NES cell and cell A and the implementation complexity.
Observation 4: There is no clear gain observed from Alt 2. Alt2 is excluded by RAN2 agreement.

Proposal 1: For additional information related to SSBs associated with PDCCH monitoring occasions, Alt 3 (No additional information is provided) is supported.
Proposal 2: For the value range for od-sib1-duration, both option 2 and option 3 can be considered.
Proposal 3: Whether the OD-SIB1 can be updated within the time window should follow legacy spec. There is no need to restrict the payloads of the OD-SIB1 transmitted in the time window should be the same.
Proposal 4: The transmission of the updated SIB1 and the updated WUS configuration on the NES cell should be within a time duration.
Proposal 5: UE behavior in the case that the resources of UL WUS in NES cell and paging occasions on cell A are overlapped can be up to UE implementation.
Proposal 6: Two options for UE to obtain the UL point A for TDD should be considered.
• Option 1: Configure offsetToPointA in the UL WUS configuration at least for TDD.
• Option 2: The absoluteFrequencyPointA is also present in IE FrequencyInfoUL for TDD.

3GPP TSG RAN WG1 #121                                                 R1-2503366
St Julian’s, Malta, May 19th – 23th, 2025
Source: 	vivo
Title:	Remaining issues 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: UE needs to distinguish whether the received WUS configuration applies to the serving cell or other NES cells.
Observation 2: UE can distinguish the received WUS configuration applies to the serving cell or other NES cells based on PhysCellId which is mandatory configured in WUS configuration.
Observation 3: Both network energy and UE power can be saved if there is an advance indication that whether redcap feature is not supported or not.
Proposal 1: The design principle for WUS configuration is to minimize the size of mandatory parameters in WUS configuration as much as possible.
Proposal 2: If a cell indicates a WUS configuration applying to serving cell itself, some parameters can follow the corresponding values in the SIB1 of serving cell itself to further reduce the payload of WUS configuration.
Proposal 3: Some parameters in WUS configuration can follow the value of the counterpart of cellA to further reduce the payload of WUS configuration.
Proposal 4: Include offsetToPointA in the WUS configuration that is mandatorily present for TDD (to derive UL point A as in legacy).
Proposal 5: frequencyBandList is mandatorily present in WUS configuration for TDD system, which refers to the IE within FrequencyInfoDL-SIB.
Proposal 6: Support option1 for the value range for od-sib1-duration, i.e., use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point.
Proposal 7: Indication of additional information related to SSBs associated with PDCCH monitoring occasions is not supported, i.e., Alt.3.
Proposal 8: UE monitors type 0 PDCCH for SIB1 acquisition using the kssb and pdcch-ConfigSIB1 in the latest stored WUS configuration after receiving Short Message indicating SI change notification.
Proposal 9: Add a parameter such as RedCapAllowed in WUS configuration to indicate whether NES cell supports RedCap UEs to request OD-SIB1.
Proposal 10: Add LBT type in WUS configuration to support NES cell in unlicensed band.
Proposal 11: support to change the following names to align with RAN2 running CR.

3GPP TSG RAN WG1 Meeting #121	R1-2503413
St Julian’s, Malta, May 19th – 23th, 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:
Observation-1: For legacy OD-SI operation, as specified in TS38.331, the network always configures si-WindowLength to be shorter than or equal to the si-Periodicity.
Observation-2: Based on TS38.212, UE is not expecting change of MIB payload within one MIB TTI of 80 ms. 
Proposal-1: RAN1 to discuss that the duration of OD-SIB1 window, od-sib1-WindowDuration, is a multiple of MIB TTI of 80 ms to avoid PBCH combining issue at UE. 
Proposal-2: RAN1 to discuss what the transmission periodicity of OD-SIB1, od-sib1-periodicity, is. Is it the same as legacy SIB1 transmission periodicity of 160 ms or is it aligned with the legacy OD-SI transmission periodicity, where the value range can be from 80 ms to 5120 ms.
Proposal-3: For OD-SIB1 operation, RAN1 to discuss whether the duration of OD-SIB1 window, od-sib1-WindowDuration shall be larger/smaller than or equal to the transmission periodicity of OD-SIB1, od-sib1-periodicity.
Proposal-4: RAN1 to discuss the NW indication of repetition periodicity or periodicity of OD-SIB1 transmission in UL WUS configuration.
Observation-3: 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-5: 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-6: 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-7: RAN1 to discuss on how to indicate the set of neighbouring SSB beams with OD-SIB1 transmission.
Observation-4: As specified in Clause 13 of TS38.213, legacy UE determines the slot to monitor Type0-PDCCH based on the SS/PBCH block index, since legacy UE obtains the Type0-PDCCH configurations from PBCH/MIB carried by SS/PBCH block. 
Observation-5: For legacy operation, the time reference for UE monitoring of Type0-PDCCH is the SSB block slot.
Proposal-8: RAN1 to discuss how UE determines the slot number and symbols for OD-SIB1 monitoring occasions, i.e. the time resources (slots, symbols) for Type 0 PDCCH monitoring occasions within the SIB1 transmission window.
Proposal-9: RAN1 to clarify whether or not the index of starting slot  in TS38.213, for UE to monitor Type0-PDCCH of OD-SIB1 should incorporate with RAR reception slot index. 
Proposal-10: RAN1 to clarify if UE should consider that the index of starting slot  in TS38.213, for UE to monitor Type0-PDCCH of OD-SIB1 is based on SS/PBCH block received after RAR reception. 

3GPP TSG RAN WG1 #121	R1-2503417

St Julian’s, Malta, May 19th – 23rd, 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:	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 2: WUS response message may optionally 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 3: For od-sib1-duration value range, support Option-2 The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity)
Proposal 4: From the options to indicate additional information related to SSBs associated with PDCCH monitoring occasions, support Alt3: No additional information is provided. 

3GPP TSG RAN WG1 #121                                                R1-2503520
Saint Julian, Malta, May 19th – 23th, 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.
Support option 3 for indication of OD-SIB1 Tx beams.
Option 3: No additional information is provided.
Support option 1 for od-sib1-duration.
Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point.
Don’t support additional contents in RAR for OD-SIB1 other than contents of RAR for SI request.

3GPP TSG RAN WG1 #121	R1-2503571
St Julian's, Malta, 19 - 23 May, 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: Make a conclusion in RAN1 that it’s up to gNB implementation to set the kSSB value to be <24 in FR1 or <12 in FR2, such that legacy UE can camp on the cell when on-demand SIB1 is broadcasted.
Proposal 2: Support Option 2 (The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity)) for both Rel-19 NES capable UE and legacy UE
Minimum value of od-sib1-duration is 160 ms.
Proposal 3: Support Alt 3 (No additional information is provided)


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

3GPP TSG RAN WG1 #121			R1-2503717
St Julian's, Malta, May 19th – 23rd, 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

The parameters ‘absoluteFrequencyPointA’, ‘offsetToCarrier’ and ‘locationAndBandwidth’ need to be mandatorily present in the UL-WUS configuration for both FDD and TDD system. 

The reference point to determine the starting slot of on-demand SIB1 window is the start of the slot containing the starting symbol of the RAR window.

The value range of OD-SIB1 window duration should be multiple of SSB periodicity of the NES CELL.

3GPP TSG RAN WG1 #121	R1-2503738
St Julian’s, Malta, May 19th – May 23th, 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: No additional information related to SSBs associated with PDCCH monitoring occasions is provided.
Proposal 2. Define the value range for od-sib1-duration in terms of number of slots from 5 slots to 5120 slots.
Proposal 3: The impact of UL WUS in the NES cell on paging in the normal cell is up to RAN4 decision. 
Proposal 4: Do not study whether the OD-SIB1 can be made applicable to RedCap features in Rel-19 NES WI.

3GPP TSG RAN WG1 #121                                             R1-2503798
St Julian’s, Malta, May 19th – 23rd, 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 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 2: There is a conflict between the agreements of RAN1 and RAN2. The agreement of RAN1 allows the UE implementation to determine whether to monitor Type 0 PDCCH for SIB1 transmission or not by implementation. In contrast, the agreement of RAN2 requires the UE to monitor Type 0 PDCCH before requesting SIB1.
Proposal 1: 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 2: If NES cell transmits SSB and the kSSB = 30 for FR1 or kSSB = 14 for FR2, on demand SIB1 is currently being broadcasted.
Proposal 3: Update RAN1#120-b agreement to support RAN2 agreement.
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, 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
Proposal 5: For indicating additional information related to SSBs associated with PDCCH monitoring occasions, support Alt3.
	Alt3: No additional information is provided.
Proposal 6: 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 7: How to ensure the validity of UL WUS configuration received from cell A should be studied. 

3GPP TSG RAN WG1 #121	R1-2503836
Malta, MT, May 19th–May 23th, 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: For the value range for od-sib1-duration, support Option 3 (The duration of the time window can be a multiple of the on-demand SIB1 repetition periodicity).
20ms can be taken as the starting point for on-demand SIB1 repetition periodicity.

Proposal 2: For additional information related to SSBs associated with PDCCH monitoring occasions, support one of the followings:
Alt 1: The information is provided in UL-WUS config
Alt 3: No additional information is provided

Proposal 3: For the specific content in RAR in response to UL WUS, support one of the followings:
Do not include other parameter in RAR (reuse RAPID-only MAC subPDU in TS 38.321).
Up to RAN2 to decide whether other parameter can be included in RAR, and how to deal with the potential misalignment for legacy UE.

3GPP TSG RAN WG1 #121			R1-2503887
St Julian’s, Malta, May 19th – 23rd, 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: For associated SSB(s) for on-demand SIB1 transmission, Alt.3 is adopted.
Alt. 3: No additional information is provided.
Proposal 2: Only the contents of RAR in response to SI request are included in RAR in response to UL WUS.
Proposal 3: For the value range of the time window duration for on-demand SIB1, Option 1 is adopted.
Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point.
Proposal 4: Adopt text proposal#1 for clause 23 of TS 38.213.

3GPP TSG RAN WG1 #121		                                     	R1-2503973 
St Julian’s, Malta, May 19th – 23th, 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: No additional information is provided on the SSB beams for receiving PDCCH for OD-SIB1 (aside from the 1-bit indication in UL-WUS configuration).
Proposal 2: For the duration of OD-SIB1, support the value-range of si-windowLength (from 5 slots to 5120 slot) as starting point (Option 1)
Appendix: Agreements on OD-SIB1 in Idle/Inactive mode
RAN1#120bis Agreements

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 #121	R1- 2503999
St Julian’s, Malta, May 19th – 23th, 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 the remaining issues for on-demand SIB1 for UEs in idle/inactive. The following observations and proposals are provided.
Proposal 1. Regarding od-sib1-duration, use the value range for si-windowLength (from 5 slots to 5120 slot) as the starting point. 
Observation 1. When the on-demand SIB1 time window overlaps with the RAR window, UE is not required to monitor PDCCH for on-demand SIB1 before successfully reception of the RAR. However, the timing for the UE to start PDCCH monitoring for on-demand SIB1 after RAR reception is unclear.
Observation 2. When the on-demand SIB1 time window overlaps with the RAR window, skipping Type0-PDCCH occasions can lead to PDCCH reception failure and increased network energy consumption.  Therefore, it is crucial to strictly specify when the UE shall start monitoring Type0-PDCCH occasion for on-demand SIB1.
Proposal 2. The UE starts the PDCCH monitoring at the first symbol of the earliest CORESET the UE is configured to receive PDCCH for Type0-PDCCH CSS set, after whichever is later between the time offset relative to the starting slot of the RAR window and the RAR reception.
Proposal 3. Regarding additional information related to SSBs associated with PDCCH monitoring occasions, support Alt 3.
Alt 3: No additional information is provided.
Proposal 4. Regarding the UE assumption on on-demand SIB1 repetitions within the time window, UE assumes that the SIB1 transmitted within the time window follows the legacy SIB repetition mechanism, i.e., repetition within a 160 ms period.
Proposal 5. How to handle the collision issue between UL WUS occasions in NES cell and paging occasions in Cell A is left to RAN4.

3GPP TSG-RAN WG1 Meeting #121	Tdoc R1-2504016 
St Julian’s, Malta, May 19th – May 23rd, 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	If additional information related to SSBs associated with PDCCH monitoring occasions is provided in UL-WUS (Alt1), it is semi-static and must account for all RACH occasions where the UE can send UL WUS.
Observation 2	If additional information related to SSBs associated with PDCCH monitoring occasions is provided in RAR (Alt2), it is dynamic and can be tailored to the PRACH resource used for UL WUS.
Observation 3	If the UE knows the SIB1 transmission pattern within a 160 ms period, then it can avoid blind detection in Type0 PDCCH CSS occasions which are not used.
Observation 4	The granularity of od-sib1-duration in terms of slots is unnecessarily fine and the range, i.e., up to 5120 slots, is unnecessarily long.
Observation 5	The duration of the time window being a multiple of 160ms (Option 2) is a reasonable compromise between flexibility and simplicity.
Observation 6	Relating the duration of the time window with the optional property of repetition periodicity can be error prone and it is best to be avoided.
Based on the discussion in the previous sections we propose the following:
Proposal 1	Support additional information related to SSBs associated with PDCCH monitoring occasions provided in RAR in response to UL-WUS transmission (Alt2) or no additional information is provided (Alt3).
Proposal 2	If Alt2 is adopted, the additional information in RAR consist of a subset of SSBs indicated with a bitmap or a list of SSB indices.
Proposal 3	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 4	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 5	It is clarified that od-sib1-duration corresponds to the time duration where the NES Cell is guaranteed to transmit OD-SIB1 after an OD-SIB1 request.
Proposal 6	Support the duration of the time window is a multiple of 160ms (Option 2). Additionally, support the duration 80ms.

3GPP TSG RAN WG1 #121		R1-2504031
St Julian’s, Malta, May 19th – 23th, 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: Endorse the following TP for 38.211 to clarify the PRACH transmission for SIB1 request
--------------------------------- start of TP for 38.211-------------------------------------
5.3.2	OFDM baseband signal generation for PRACH

-	 is the subcarrier spacing of the initial uplink bandwidth part during initial access. If the PRACH transmission is for a candidate cell  is provided by ltm-PRACH-SubcarrierSpacing in EarlyUL-SyncConfig. If the PRACH transmission is for SIB1 request,  is provided by SIB1-RequestConfig. Otherwise,  is the subcarrier spacing of the active uplink bandwidth part; 
-	 is the largest  value among the subcarrier spacing configurations by the higher-layer parameter scs-SpecificCarrierList;
-	 is the lowest numbered resource block of the initial uplink bandwidth part and is derived by the higher-layer parameter initialUplinkBWP or initialUplinkBWP-RedCap during initial access and from the higher-layer parameters bwp-GenericParameters in EarlyUL-SyncConfig if the PRACH transmission is for a candidate cell and from the higher-layer parameters SIB1-RequestConfig if the PRACH transmission is for SIB1 request. Otherwise,  is the lowest numbered resource block of the active uplink bandwidth part and is derived by the higher-layer parameter BWP-Uplink; 

6.3.3.1	Sequence generation

There are 64 preambles defined in each time-frequency PRACH occasion, enumerated in increasing order of first increasing cyclic shift  of a logical root sequence, and then in increasing order of the logical root sequence index, starting with the index obtained from the higher-layer parameter prach-RootSequenceIndex or rootSequenceIndex-BFR or by msgA-PRACH-RootSequenceIndex if configured and a type-2 random-access procedure is initiated as described in clause 8.1 of [5, TS 38.213] or by prach-RootSequenceIndex in EarlyUL-SyncConfig if the PRACH transmission is for a candidate cell or by prach-RootSequenceIndex in SIB1-RequestConfig if the PRACH transmission is for SIB1 request. Additional preamble sequences, in case 64 preambles cannot be generated from a single root Zadoff-Chu sequence, are obtained from the root sequences with the consecutive logical indexes until all the 64 sequences are found. The logical root sequence order is cyclic; the logical index 0 is consecutive to . The sequence number  is obtained from the logical root sequence index according to Tables 6.3.3.1-3 to 6.3.3.1-4B.
--------------------------------- start of TP for 38.211-------------------------------------

Proposal 2: Support to configure the bandwidth for downlink to improve the performance for RAR and OD-SIB1.

Proposal 3: Endorse the following TP (removing bracket only) for 38.213 to clarify the UE behavior for SIB1 monitoring.
----------------------------------- start of TP for section 23 for 38.213 ------------------------------------
[If the SS/PBCH block on the second cell indicates  for FR1 or  for FR2,] the UE is not required to monitor PDCCH on the second cell to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI prior to a reception of a PDSCH scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI.
----------------------------------- end of TP for section 23 for 38.213------------------------------------

3GPP TSG RAN WG1 #121			R1-2504051
St Julian’s, Malta, May 19th – 23th, 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: Proposal 1: Not support to provide any additional information related to SSBs associated with PDCCH monitoring occasions.
Proposal 2: Support Option 1, i.e., use the value range for si-windowLength (from 5 slots to 5120slots) as a starting point for the value range of od-sib1-duration. 
Proposal 3: It should be up to UE’s implement to monitor OD-SIB1 during the RAR window before the OD-SIB1 window starts.

3GPP TSG RAN WG1 #121	        	R1-2504065
St Julian’s, Malta, May 19th – 23rd, 2025

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

Conclusions
The following observation and proposal were made in this contribution.
Observation 1: To keep consistency between RAN1 and RAN2 agreement, it would be necessary to indicate the information of the transmission status of SIB1 by using any signal that can be indicated before the UE transmits UL WUS, e.g., UL WUS configuration or K_SSB.
Proposal 1: The information indicating the transmission status of SIB1 (e.g., whether the SIB1 of the NES cell is currently being broadcasted or provided on demand) should be included in UL WUS configuration.

3GPP TSG RAN WG1 #121	R1-2504108
St Julian’s, Malta, May 19th – 23rd, 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 1: Adopt the following TP for TS38.213,
Proposal 2: No additional information is provided regarding the association of SSB(s) with OD-SIB1 monitoring occasions, besides the agreed 1-bit indication. 
Proposal 3: Use the value-range for si-windowLength (from 5 slots to 5120 slot) for configuring od-sib1-duration.

3GPP TSG RAN WG1 #121                                          R1-2504142
St Julian’s, Malta, May 19th – 23rd, 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: Use the value range of si-windowLength for the OD-SIB1 window duration (Option 1).
FFS: Whether/how to guarantee valid Type 0 PDCCH monitoring occasion(s) within the window
Proposal 2: Conclude that no additional information is provided (Alt. 3) for Type 0 PDCCH monitoring in the OD-SIB1 window.

3GPP TSG RAN WG1 #121		                        R1-2504177
St Julian’s, Malta, May 19th-23th, 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  Alt 3 (No additional information is provided) can be supported.
Proposal 2  For the value range for od-sib1-duration, option 2 or option 3 can be supported.
Proposal 3  The contents of RAR in response to SI request follows legacy operation.
Proposal 4  There is no need to resolve the issue of UL WUS on NES cell overlapping with paging occasion on normal cell.

3GPP TSG RAN WG1 #121		R1-2504193
St Julian’s, Malta, May 19th – 23th, 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

Conclusions 
In this contribution, we discussed the remaining issues and the draft CR improvements for OD-SIB1. Our proposals and observation can be found as follows:
Observation 1:	UE monitoring type0-PDCCH search space sets may in different locations according to the 	selected SSB index assumption. The time domain difference between different selected SSB 	indexes may differ up to 16 ms (assuming Lmax = 8 and M=2). Due to this reason, an 	absolute time duration for OD-SIB1 window may not be the best choice.

Proposal 1:	the value range for od-sib1-duration is (40 ms, 60 ms, 80 ms,..., 250 ms) with granularity of 	20 ms. 
Proposal 2:	the value range for the time offset between the reference time point and the starting time of 	the OD-SIB1 window is (0 ms, 20 ms, 40 ms). 
Proposal 3:	If RAN1 agreement on OD-SIB1 duration can be reverted, we suggest that the OD-SIB1 	duration should be configured in terms of the number of type0-PDCCH monitoring 	occasions.
Proposal 4:	RAN1 adopts TP#1.
Proposal 5: 	RAN1 adopts TP#2.
Proposal 6: 	RAN1 adopts TP#3.
Proposal 7: 	RAN1 adopts TP#4.

--------------- TP#1 of TS 38.213 in Clause 23 -----------------------

Unless otherwise mentioned, the higher layer parameters in this clause and in referenced clauses are provided by SIB1-RequestConfig on a first cell. 
A UE can be provided, by NES_CellId, a physical cell identity of a second cell and an ARFCN by ARFCN-ValueNR for SS/PBCH block receptions on the second cell. When
-	the UE receives an SS/PBCH block on the second cell, and
-	 for FR1 or  for FR2 is indicated by the SS/PBCH block on the second cell, and
-	conditions for PRACH transmission associated with the SS/PBCH block on the second cell are satisfied [12, TS 38.331],
the UE can transmit a PRACH associated with the SS/PBCH block on the second cell based on:
-	a timing adjustment indicated by n-TimingAdvanceOffset, if provided, as described in Clause 4.2  
-	a power determined as described in Clause 7.4  
-	a procedure determined as in Clause 8.1 based on Type-1 random access procedure
where  for determining the common resource block [4, TS 38.211] is provided by k-ssb. A CORESET for Type0-PDCCH CSS and Type1-PDCCH CSS is provided by controlResourceSetZero.

--------------- end of TP#1 -------------------------------------------------------


--------------- TP#2 of TS 38.213 in Clause 23 -----------------------

If the UE identifies a RAPID associated with a corresponding PRACH transmission from the UE in a PDSCH reception scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI, the UE can be indicated by higher layers to monitor PDCCH on the second cell to detect a DCI format 1_0 with CRC scrambled by the SI-RNTI according to a Type0-PDCCH CSS set provided by SearchSpaceZero. If the UE is provided XYZ, the UE monitors PDCCH only in monitoring occasions associated with the SS/PBCH block. The UE starts monitoring PDCCH to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI after a number of slots provided by od-sib1-windowStartOffset from the starting slot of the window controlled by ra_ResponseWindow, and for a number of slots provided by od-sib1-WindowDuration.

--------------- end of TP#2-------------------------------------------------------


--------------- TP#3 of TS 38.213 in Clause 23 -----------------------

If the UE identifies a RAPID associated with a corresponding PRACH transmission from the UE in a PDSCH reception scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI, the UE can be indicated by higher layers to monitor PDCCH on the second cell to detect a DCI format 1_0 with CRC scrambled by the SI-RNTI according to a Type0-PDCCH CSS set provided by SearchSpaceZero. If the UE is provided XYZ, the UE monitors PDCCH only in monitoring occasions associated with the SS/PBCH block. The UE starts monitoring PDCCH to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI in the next monitoring occasion after a number of slots provided by od-sib1-windowStartOffset from the starting slot of the window controlled by ra_ResponseWindow, and for a number of slots provided by od-sib1-WindowDuration.

--------------- end of TP#3 -------------------------------------------------------

--------------- TP#4 of TS 38.213 in Clause 23 -----------------------

[If the SS/PBCH block on the second cell indicates  for FR1 or  for FR2,] the UE is not required to monitor PDCCH on the second cell to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI prior to a reception of a PDSCH scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI.

--------------- end of TP#4 -------------------------------------------------------

3GPP TSG RAN WG1 #121     	                                                  R1-2504236
St Julian’s, Malta, May 19th – 23th, 2025

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

Conclusion
Based on the discussion, the following proposals are highlighted: 
Proposal 1: Alt 3 is taken that no additional information is provided to indicate the SSBs associated with PDCCH monitoring occasions.
Proposal 2: The value range of od-sib1-duration is defined as the duration of the time window of a multiple of 160ms (i.e. legacy SIB1 periodicity).

3GPP TSG RAN WG1 #121			                  R1-2504248
St. Julian’s, Malta, May 19th – 23rd, 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: RAN1 to discuss whether to specify the UE behaviour if an OD-SIB1 PDCCH is detected in Type0-PDCCH occasion before the UE receives the RAR after the UL WUS transmission.
Proposal #2: To support UEs to monitor the RAR for SIB1 requests sent by other UEs, UE may monitor 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.
Proposal #3: Support gNB to provide the additional information on which SSBs are currently being transmitted by the UL WUS configuration or by RAR in response to the UL WUS. 
Proposal #4: Support gNB to configure SSB group each of which includes one or multiple SSBs by UL WUS configuration. If the UE transmits WUS corresponding to an SSB, the UE assumes that, in the OD-SIB1 window, PDCCH for an OD-SIB1 message is transmitted in PDCCH monitoring occasions corresponding only to SSB(s) associated with SSB group including the SSB.
Proposal #5: 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 #121           	                                   R1-2504263
St Julian’s, Malta, May 19th – 23th, 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:

Observation 1: On indication of additional information related to SSBs
For Alt. 1, providing additional information of SSB in UL-WUS can not adapt with the time-variant channel conditions for each beam. 
For Alt. 2, changing RAR contents would have large RAN1/RAN2 spec impact.

Observation 2: The following RAN2 agreement is achieved in RAN2 #129b
“Align with legacy RAR for OSI for OD-SIB1 operation. Legacy RAR MAC PDU subheader with RAPID only to be used as NW acknowledgement for OD-SIB1 request.”

Proposal 1: On indication of additional information related to SSBs, RAN1 to adopt 
Alt. 3: No additional information is provided.

Proposal 2: 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. UE should prioritize paging if the overlapping happens.

Proposal 3: For value range for od-sib1-duration, as SIB1 contents would be repeated within 160ms, adopt 
Option 2: The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity).

Proposal 4: When OD-SIB1 window starting time falls into the middle of SSB burst, it is up to UE implementation to handle this scenario.
Assuming the value range for od-sib1-duration is set to multiple of 160ms.

3GPP TSG RAN WG1 #120bis							   R1-2504326
St Julian’s, Malta, May 19th – 23th, 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: For the value range of od-sib1-duration, consider the following two options: 
Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point.
Option 4: The duration of the time window can be a multiple of 20ms
Proposal 2: UE starts monitoring Type-0 PDCCH occasions within the OD-SIB1 monitoring window, from the first PDCCH monitoring occasion that is at least N slots from the ending slot of RAR reception. 

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, the K_SSB value on the NES cell is still K_SSB >= 24 for FR1 and K_SSB >= 1, thus a legacy UE would not be able to access the NES cell. 
Proposal 3: Regarding indicating additional information related to SSBs associated with PDCCH monitoring occasions, do not support Alt 1 The information is provided in UL-WUS config, while Alt 2 can be considered. 

 

3GPP TSG RAN WG1 #121   		                                                                       R1-2504399
St Julian’s, Malta, May 19th – 23rd, 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, if the 1-bit indication is included in UL WUS config or the 1-bit indication is TRUE, 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 2: The value range of the PDCCH monitoring window od-sib1-duration is the same value range as si-windowLength (i.e., Option 1).

3GPP TSG-RAN WG1 #121	R1-2504457
St Julian’s, Malta, May 19th – 23rd, 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 proposed:
Proposal 1:	Additional information related to SSBs associated with PDCCH monitoring occasions is not supported (Alt3: No additional information is provided).
Proposal 2:	The value range for the duration of the on-demand SIB1 window is specified as a multiple of the on-demand SIB1 repetition periodicity (Option 3).
Proposal 3:	ULSubcarrierSpacing is used for the subcarrier spacing for PRACH baseband signal generation.

3GPP TSG RAN WG1 #121	R1-2504467
St Julian’s, Malta, May 19th – 23th, 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: a UE find a position of MAC subPDU for RAR in MAC PDU based on the field values of subheaders.
Observation 2: To identify whether a MAC subPDU includes RAR or not, a UE needs to obtain the configuration of SI request which is included in SIB1.
Observation 3: If RACH occasion for OD-SIB1 request is shared with RACH occasion for RACH procedure, and same RA-RNTI definition is reused (i.e. if MAC PDU for OD-SIB1 can be shared with other RAR), it occurs an issue for MAC subPDU location identification within a MAC PDU.
Proposal 1: To solve the issue on MAC subPDU location identification for RAR of OD-SIB1 request, RAN1 should consider following options:
Option 1: RACH occasion for OD-SIB1 request is a dedicated resource and is not used for other purpose
Option 2: New RNTI is introduced for RAR of OD-SIB1 request
Option 3: OD-SIB1 request configuration includes configuration of OD-OSI request (RAPID information)
Observation 4: The UE monitors PDCCH in the same search space (i.e., searchSpaceZero) for the same DCI format (i.e., DCI format 1_0) both before and after RAR reception.
Observation 5: OD-SIB1 reception latency can be reduced with minimal UE overhead by allowing the UE to monitor the PDCCH according to a Type1-PDCCH CSS set provided by searchSpaceZero for a DCI format with CRC scrambled by both RA-RNTI and SI-RNTI during the ra_ResponseWindow. This would enable the UE to receive OD-SIB1 earlier, without waiting for RAR reception, thereby further reducing latency.
Proposal 2: If ra-SearchSpace is not provided by WUS-Config, allow the UE to monitor the PDCCH according to a Type1-PDCCH CSS set provided by searchSpaceZero for DCI format 1_0 with CRC scrambled not only by RA-RNTI but also by SI-RNTI during the ra_ResponseWindow.

3GPP TSG RAN WG1 #121			R1-2504506
St Julian’s, Malta, May 19th – 23th, 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:
For the FFS issue on additional information related to SSBs associated with PDCCH monitoring occasions, we prefer Alt3 (No additional information is provided). 

Proposal 2:
It is up to RAN2 to decide the SSB and PRACH resource selection criterion for UE sending a WUS. 

Proposal 3:
The duration of OD-SIB1 window could be multiple of 160ms, e.g., [160ms, 320ms, 640ms, 1280ms].

Proposal 4:
UE monitors from the first type 0 PDCCH monitoring occasion associated with one or all SSB(s) according to 1-bit indication in UL-WUS from the starting of the slot which is n slot after the slot of PDSCH of RAR reception. 
where,  

Proposal 5:
There is no cross-slot scheduling for SI, then PDSCH of SIB1 is within the same slot as PDCCH scheduling the SIB1. So, following proposal is NOT necessary.
FL Proposal 10-2: 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. 

3GPP TSG-RAN WG1 Meeting #121	R1-2504556
St Julian's, Malta, 19th – 23th May, 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:  The information provided in RAR in response to UL-WUS transmission can indicate additional information related to SSBs associated with PDCCH monitoring occasions.
Proposal 2:  On contents of the RAR for UL WUS, do not support additional parameters on top of contents of RAR in response to SI request.
Proposal 3: 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.

3GPP TSG RAN WG1 Meeting #121	  R1-2504603
St Julian’s, Malta, May 19th – 23th, 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, 
Proposal 1: Support Alt 1: “The information is provided in UL-WUS config” to indicate additional information related to SSBs associated with PDCCH monitoring occasions.
Proposal 2: Support Option 3: “The duration of the time window can be a multiple of the on-demand SIB1 repetition periodicity” for the value range for si-windowLength.
Proposal 3: Support indicating the transmission status of on-demand SIB1 using repurposed parameters in MIB or PBCH of NES cell for idle UEs.
Proposal 4: 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) 

3GPP TSG RAN WG1 #121							   R1-2504679
St Julian’s, Malta, May 19th – 23th, 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


In RAN1 #120-bis, the following are agreed:

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
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.

Value range for od-sib1-duration:
On the value range of od-sib1-duration, companies’ views in RAN1 #121 are collected below:

China Telecom:
Proposal 2: Support Option 1, i.e., use the value range for si-windowLength (from 5 slots to 5120slots) as a 
starting point for the value range of od-sib1-duration.

Lenovo:
Proposal 3: Use the value-range for si-windowLength (from 5 slots to 5120 slot) for configuring od-sib1-duration.

ETRI:
Proposal 1: Use the value range of si-windowLength for the OD-SIB1 window duration (Option 1).
FFS: Whether/how to guarantee valid Type 0 PDCCH monitoring occasion(s) within the window

Transsion:
Proposal 2  For the value range for od-sib1-duration, option 2 or option 3 can be supported.

OPPO:
Proposal 1: the value range for is (40 ms, 60 ms, 80 ms,..., 250 ms) with granularity of 20 ms. 

Proposal 2: the value range for the time offset between the reference time point and the starting time of the OD-SIB1 window is (0 ms, 20 ms, 40 ms).

Proposal 3: If RAN1 agreement on OD-SIB1 duration can be reverted, we suggest that the OD-SIB1 duration should be configured in terms of the number of type0-PDCCH monitoring occasions.

Panasonic:
Proposal 2: The value range of od-sib1-durati on is defi ned as the duration of the time window of a multiple of 160ms (i.e. legacy SIB1 periodicity).

MTK: Option 2: multiple of 160ms

Apple:
Proposal 1: For the value range of od-sib1-duration, consider the following two options: 
- Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point.
- Option 4: The duration of the time window can be a multiple of 20ms

QC:
Proposal 2: The value range of the PDCCH monitoring window od-sib1-duration is the same value range as si-windowLength (i.e., Option 1).

DENSO:
Proposal 2: The value range for the duration of the on-demand SIB1 window is specified as a multiple of the 
on-demand SIB1 repetition periodicity (Option 3).

Proposal 3: ULSubcarrierSpacing is used for the subcarrier spacing for PRACH baseband signal generation.

DCM:
Proposal 3: The duration of OD-SIB1 window could be multiple of 160ms, e.g., [160ms, 320ms, 640ms, 1280ms].

CEWiT:
Proposal 2: Support Option 3 “The duration of the time window can be a multiple of the on-demand SIB1 
repetition periodicity” for the value range for si-windowLength.

FUTUREWEI
Proposal 2: Support Option 2: The value range for od-sib1-duration can be a multiple of 160ms.

Huawei, HiSilicon
Proposal 3: Support to use the value-range for si-windowLength (from 5 slots to 5120 slots) as the value range for odsib1-duration.

ZTE, Sanechips
Proposal 2: For the value range for od-sib1-duration, both option 2 and option 3 can be considered.

vivo
Proposal 6: Support option1 for the value range for od-sib1-duration, i.e., use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point.

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

Proposal-1: RAN1 to discuss that the duration of OD-SIB1 window, od-sib1-WindowDuration, is a multiple of MIB TTI of 80 ms to avoid PBCH combining issue at UE.

Proposal-3: For OD-SIB1 operation, RAN1 to discuss whether the duration of OD-SIB1 window, od-sib1- WindowDuration shall be larger/smaller than or equal to the transmission periodicity of OD-SIB1, od-sib1- periodicity.

NEC
Proposal 3: For od-sib1-duration value range, support Option-2 The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity)

Spreadtrum, UNISOC
Proposal 2 Support option 1 for od-sib1-duration. 
Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point.

Samsung
Proposal 2: Support Option 2 (The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity)) for both Rel-19 NES capable UE and legacy UE.
Minimum value of od-sib1-duration is 160 ms.

Tejas 
Proposal 3: The value range of OD-SIB1 window duration should be multiple of SSB periodicity of the NES CELL.

Ofinno
Proposal 2. Define the value range for od-sib1-duration in terms of number of slots from 5 slots to 5120 slots.

CMCC
Proposal 1: For the value range for od-sib1-duration, support Option 3 (The duration of the time window can be a multiple of the on-demand SIB1 repetition periodicity). 
20ms can be taken as the starting point for on-demand SIB1 repetition periodicity.

Xiaomi
Proposal 3: For the value range of the time window duration for on-demand SIB1, Option 1 is adopted. 
Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point

InterDigital
Proposal 2: For the duration of OD-SIB1, support the value-range of si-windowLength (from 5 slots to 5120 slot) as starting point (Option 1)

Fujitsu
Proposal 1. Regarding od-sib1-duration, use the value range for si-windowLength (from 5 slots to 5120 slot) as the starting point.

Ericsson
Proposal 5 It is clarified that od-sib1-duration corresponds to the time duration where the NES Cell is guaranteed to transmit OD-SIB1 after an OD-SIB1 request.

Observation 4 The granularity of od-sib1-duration in terms of slots is unnecessarily fine and the range, i.e., up to 5120 slots, is unnecessarily long.

Observation 5 The duration of the time window being a multiple of 160ms (Option 2) is a reasonable compromise between flexibility and simplicity.

Observation 6 Relating the duration of the time window with the optional property of repetition periodicity can be error prone and it is best to be avoided. 

Proposal 6 Support the duration of the time window is a multiple of 160ms (Option 2). Additionally, support the duration 80ms.

Companies’ views for value range of od-sib1-duration in RAN1 #121 are summarized below:

For the value range for od-sib1-duration
Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot).
Supported by China Telecom, Lenovo, ETRI, Apple, Qualcomm, Huawei/HiSilicon, vivo, Spreadtrum/UNISOC, Ofinno, Xiaomi, InterDigital, Fujitsu
Option 2: The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity).
Supported by Transsion, Panasonic, MTK, DCM, FUTUREWEI, ZTE/Sanechips, NEC, Samsung, Ericsson (add 80ms),
Option 2a: {20, 40, 80, 160, 320,...}ms 
Supported by Apple, vivo
Option 3: The duration of the time window can be a multiple of the on-demand SIB1 repetition periodicity (if supported)
Supported by Transsion, DENSO, CEWiT, ZTE/Sanechips, CMCC (Ex. 20ms),  
Option 4: The value range for od-sib1-duration is (40 ms, 60 ms, 80 ms, ..., 240 ms) with granularity of 20 ms.
Supported by OPPO
Option 5: The duration of the time window can be configured in terms of the number of type0-PDCCH monitoring occasions.
Supported by OPPO
Option 6: Multiple of 20ms
Supported by Apple
Option 7: Multiple of 80ms
Supported by Nokia
Option 8: Multiple of SSB periodicity of the NES cell
Supported by Tejas
FL Proposal 3-1
On the value range for od-sib1-duration, adopt the following:
Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot)

Vivo: Unit is ms first
FL Proposal 3-1-2
On the value range for od-sib1-duration, adopt the following:
Option 2: The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity).


FL Proposal 3-1-3 (Apple)
On the value range for od-sib1-duration, adopt the following:
{20, 40, 80, 160, 320, ...} ms

FL Proposal 3-2 (Ericsson)
RAN1 confirms that od-sib1-duration corresponds to the time duration where the NES Cell is guaranteed to transmit OD-SIB1 after an OD-SIB1 request.
Note: It is up to the NES Cell to decide whether to prolong it


OD-SIB1 transmission/repetition periodicity:
On OD-SIB1 transmission/repetition periodicity, companies’ views in RAN1 #121 are collected below:

Nokia
Observation-1: For legacy OD-SI operation, as specified in TS38.331, the network always configures si-WindowLength to be shorter than or equal to the si-Periodicity.

Proposal-2: RAN1 to discuss what the transmission periodicity of OD-SIB1, od-sib1-periodicity, is. Is it the same as legacy SIB1 transmission periodicity of 160 ms or is it aligned with the legacy OD-SI transmission periodicity, where the value range can be from 80 ms to 5120 ms. 

Proposal-4: RAN1 to discuss the NW indication of repetition periodicity or periodicity of OD-SIB1 transmission in UL WUS configuration.

Fujitsu
Proposal 4. Regarding the UE assumption on on-demand SIB1 repetitions within the time window, UE assumes that the SIB1 transmitted within the time window follows the legacy SIB repetition mechanism, i.e., repetition within a 160 ms period.

Ericsson
Observation 3 If the UE knows the SIB1 transmission pattern within a 160 ms period, then it can avoid blind detection in Type0 PDCCH CSS occasions which are not used.

Proposal 3 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 4 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.

FL Proposal 3-3 (Nokia, Fujitsu)
RAN1 to clarify the transmission periodicity of OD-SIB1 is
Option 1: same as legacy SIB1 transmission periodicity of 160 ms
Option 2: aligned with the legacy OD-SI transmission periodicity, where the value range can be from 80 ms to 5120 ms.


FL Proposal 3-3-2 (Fujitsu)
RAN1 to draw the following conclusion:
Regarding the UE assumption on on-demand SIB1 repetition/transmission within the time window, UE assumes that the SIB1 transmitted within the time window follows the legacy SIB1 repetition mechanism, i.e., repetition within a 160 ms period.

FL Proposal 3-3-3 (LG)
RAN1 to draw the following conclusion:
The legacy behavior below is applied for OD-SIB1.
The SIB1 is transmitted on the DL-SCH with a periodicity of 160 ms and variable transmission repetition periodicity within 160 ms.

FL Proposal 3-4 (Nokia, Ericsson)
Support NW indication of repetition periodicity or periodicity of OD-SIB1 transmission in UL WUS configuration.
FFS more parameters in the UL WUS configuration:
SIB1 offset
SIB1 search space mask
Note: These parameters are also valid after the on-demand SIB1 acquisition procedure.


Parameters inside UL-WUS configuration other than od-sib1-duration:
On parameters inside UL-WUS configuration other than od-sib1-duration, companies’ views in RAN1 #121 are collected below:

OPPO:
Proposal 4:	RAN1 adopts TP#1 below.
--------------- TP#1 of TS 38.213 in Clause 23 -----------------------
Unless otherwise mentioned, the higher layer parameters in this clause and in referenced clauses are provided by SIB1-RequestConfig on a first cell. 
A UE can be provided, by NES_CellId, a physical cell identity of a second cell and an ARFCN by ARFCN-ValueNR for SS/PBCH block receptions on the second cell. When
-	the UE receives an SS/PBCH block on the second cell, and
-	 for FR1 or  for FR2 is indicated by the SS/PBCH block on the second cell, and
-	conditions for PRACH transmission associated with the SS/PBCH block on the second cell are satisfied [12, TS 38.331],
the UE can transmit a PRACH associated with the SS/PBCH block on the second cell based on:
-	a timing adjustment indicated by n-TimingAdvanceOffset, if provided, as described in Clause 4.2  
-	a power determined as described in Clause 7.4  
-	a procedure determined as in Clause 8.1 based on Type-1 random access procedure
where  for determining the common resource block [4, TS 38.211] is provided by k-ssb. A CORESET for Type0-PDCCH CSS and Type1-PDCCH CSS is provided by controlResourceSetZero.
--------------- end of TP#1 -------------------------------------------------------


ZTE, Sanechips
Proposal 6: Two options for UE to obtain the UL point A for TDD should be considered.
Option 1: Configure offsetToPointA in the UL WUS configuration at least for TDD.
Option 2: The absoluteFrequencyPointA is also present in IE FrequencyInfoUL for TDD.

vivo
Proposal 1: The design principle for WUS configuration is to minimize the size of mandatory parameters in WUS configuration as much as possible.

Observation 1: UE needs to distinguish whether the received WUS configuration applies to the serving cell or other NES cells. 

Observation 2: UE can distinguish the received WUS configuration applies to the serving cell or other NES cells based on PhysCellId which is mandatory configured in WUS configuration. 

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

Proposal 3: Some parameters in WUS configuration can follow the value of the counterpart of cellA to further reduce the payload of WUS configuration.

Proposal 4: Include offsetToPointA in the WUS configuration that is mandatorily present for TDD (to derive UL point A as in legacy).

Proposal 5: frequencyBandList is mandatorily present in WUS configuration for TDD system, which refers to the IE within FrequencyInfoDL-SIB.

Proposal 11: support to change the following names to align with RAN2 running CR. 
rsrp-ThresholdSSB -> rsrp-SIB1ThresholdSSB, 
ra-PreambleStartIndex -> ra-SIB1PreambleStartIndex, 
ra-AssociationPeriodIndex -> ra-AssociationPeriodIndexSib1

NEC
Proposal 1: 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.

Tejas
Proposal 1: The parameters ‘absoluteFrequencyPointA’, ‘offsetToCarrier’ and ‘locationAndBandwidth’ need to be mandatorily present in the UL-WUS configuration for both FDD and TDD system.

Google
Proposal 2: Support to configure the bandwidth for downlink to improve the performance for RAR and ODSIB1.

FL Proposal 3-6 (OPPO)
RAN1 to adopt TP#1 below:
--------------- TP#1 of TS 38.213 in Clause 23 -----------------------
Unless otherwise mentioned, the higher layer parameters in this clause and in referenced clauses are provided by SIB1-RequestConfig on a first cell. 
A UE can be provided, by NES_CellId, a physical cell identity of a second cell and an ARFCN by ARFCN-ValueNR for SS/PBCH block receptions on the second cell. When
-	the UE receives an SS/PBCH block on the second cell, and
-	 for FR1 or  for FR2 is indicated by the SS/PBCH block on the second cell, and
-	conditions for PRACH transmission associated with the SS/PBCH block on the second cell are satisfied [12, TS 38.331],
the UE can transmit a PRACH associated with the SS/PBCH block on the second cell based on:
-	a timing adjustment indicated by n-TimingAdvanceOffset, if provided, as described in Clause 4.2  
-	a power determined as described in Clause 7.4  
-	a procedure determined as in Clause 8.1 based on Type-1 random access procedure
where  for determining the common resource block [4, TS 38.211] is provided by k-ssb. A CORESET for Type0-PDCCH CSS and Type1-PDCCH CSS is provided by controlResourceSetZero.
--------------- end of TP#1 -------------------------------------------------------
Reason of change: The CORESET#0 configuration is not included in Clause 23 of current R19 draft spec. Thus, the UE cannot know that the configuration of CORESET#0 is provided by SIB1-RequestConfig if not specified.


FL Proposal 3-7 (ZTE, vivo, Tejas)
RAN1 to adopt one of the following two options for UE to obtain the UL point A for TDD system.
Option 1: Configure offsetToPointA in the UL WUS configuration at least for TDD system.
Option 2: Configure absoluteFrequencyPointA under the IE FrequencyInfoUL also for TDD system.


FL Proposal 3-8 (vivo)
If a cell indicates a WUS configuration applying to serving cell itself, some parameters can follow the same values in the SIB1 of the cell itself to reduce the payload of WUS configuration.


FL Proposal 3-9 (vivo)
Some parameters in WUS configuration can follow the values of cell A to reduce the payload of WUS configuration.


FL Proposal 3-10 (vivo)
The frequencyBandList is mandatorily present in WUS configuration for TDD system, which refers to the IE within FrequencyInfoDL-SIB.


FL Proposal 3-11 (Tejas)
The parameters ‘absoluteFrequencyPointA’, ‘offsetToCarrier’ and ‘locationAndBandwidth’ are mandatorily present in the UL-WUS configuration for both FDD and TDD system.


FL Proposal 3-12 (Google)
Configure the bandwidth for downlink in the UL WUS configuration (to improve the performance for RAR and OD-SIB1).


Issue 4: UL-WUS on NES cell overlapping with paging occasion on normal cell
Background

It is agreed in RAN2 #129b that:
Agreement
Leave this issue (how to handle paging interruption during OD-SIB1 acquisition) to RAN4.

Companies’ views for this topic in RAN1 #121 are collected below:

MTK
Proposal 2: 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. UE should prioritize paging if the overlapping happens.

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

Transsion:
Proposal 4  There is no need to resolve the issue of UL WUS on NES cell overlapping with paging occasion on normal cell.

CAICT:
Proposal 3:  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.

ZTE, Sanechips
Proposal 5: UE behavior in the case that the resources of UL WUS in NES cell and paging occasions on cell A are overlapped can be up to UE implementation.

Ofinno
Proposal 3: The impact of UL WUS in the NES cell on paging in the normal cell is up to RAN4 decision.

Fujitsu
Proposal 5. How to handle the collision issue between UL WUS occasions in NES cell and paging occasions in Cell A is left to RAN4.


For this topic, companies’ views in RAN1 #121 are summarized below
What should UE do if UL-WUS on NES cell overlapped with paging occasion on Cell A
Up to UE implementation: Transsion, CAICT, ZTE/Sanechips,
UE prioritizes receiving the paging occasion from Cell A: MTK
Left to RAN4: Ofinno, Fujitsu, MTK

FL Proposal 4-1
It is up to RAN4 to discuss whether to prioritize paging 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 5: UE to monitor the RAR for SIB1 requests sent by other UEs
Background
The following proposals are brought up in RAN1 #121:


LG:
Proposal #2: To support UEs to monitor the RAR for SIB1 requests sent by other UEs, UE may monitor 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.

FL Proposal 5-1 (LG)
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.
To support UEs to monitor the RAR for SIB1 requests sent by other UEs,


Issue 6: 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.

In RAN1 #120-bis, it is agreed that:
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.


Companies’ views for this topic in RAN1 #121 are collected below:

China Telecom:
Proposal 3: It should be up to UE’s implement to monitor OD-SIB1 during the RAR window before the OD-SIB1 window starts.

LG:
Proposal #1: RAN1 to discuss whether to specify the UE behaviour if an OD-SIB1 PDCCH is detected in Type0-PDCCH occasion before the UE receives the RAR after the UL WUS transmission.

Apple:
Proposal 2: UE starts monitoring Type-0 PDCCH occasions within the OD-SIB1 monitoring window, from the 
first PDCCH monitoring occasion that is at least N slots from the ending slot of RAR reception.

DCM:
Proposal 4:
UE monitors from the first type 0 PDCCH monitoring occasion associated with one or all SSB(s) according to 1-bit indication in UL-WUS from the starting of the slot which is n slot after the slot of PDSCH of RAR reception. 
where,  

Fig.1 Starting time of PDCCH monitoring occasion  

Fujitsu
Observation 2. When the on-demand SIB1 time window overlaps with the RAR window, skipping Type0- PDCCH occasions can lead to PDCCH reception failure and increased network energy consumption. Therefore, it is crucial to strictly specify when the UE shall start monitoring Type0-PDCCH occasion for on-demand SIB1.

Proposal 2. The UE starts the PDCCH monitoring at the first symbol of the earliest CORESET the UE is configured to receive PDCCH for Type0-PDCCH CSS set, after whichever is later between the time offset relative to the starting slot of the RAR window and the RAR reception.

Sharp:
Proposal 2: If ra-SearchSpace is not provided by WUS-Config, allow the UE to monitor the PDCCH according to a Type1-PDCCH CSS set provided by searchSpaceZero for DCI format 1_0 with CRC scrambled not only by RA-RNTI but also by SI-RNTI during the ra_ResponseWindow.

Lenovo:
Proposal 1: Adopt the following TP for TS38.213,

OPPO:
Proposal 6: RAN1 to adopt TP#3 below.
--------------- TP#3 of TS 38.213 in Clause 23 -----------------------
If the UE identifies a RAPID associated with a corresponding PRACH transmission from the UE in a PDSCH reception scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI, the UE can be indicated by higher layers to monitor PDCCH on the second cell to detect a DCI format 1_0 with CRC scrambled by the SI-RNTI according to a Type0-PDCCH CSS set provided by SearchSpaceZero. If the UE is provided XYZ, the UE monitors PDCCH only in monitoring occasions associated with the SS/PBCH block. The UE starts monitoring PDCCH to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI in the next monitoring occasion after a number of slots provided by od-sib1-windowStartOffset from the starting slot of the window controlled by ra_ResponseWindow, and for a number of slots provided by od-sib1-WindowDuration.
--------------- end of TP#3 -------------------------------------------------------

Proposal 7: RAN1 to adopt TP#4 below.
--------------- TP#4 of TS 38.213 in Clause 23 -----------------------
[If the SS/PBCH block on the second cell indicates  for FR1 or  for FR2,] the UE is not required to monitor PDCCH on the second cell to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI prior to a reception of a PDSCH scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI.
--------------- end of TP#4 -------------------------------------------------------

Tejas
Proposal 2: The reference point to determine the starting slot of on-demand SIB1 window is the start of the slot containing the starting symbol of the RAR window.

Huawei, HiSilicon
Proposal 1: Adopt TP#1 to clarify the reference time point to determine the starting slot of on-demand SIB1 window is the slot containing the starting symbol of RAR window.


FL Proposal 6-1 (LG)
RAN1 to discuss whether to specify the UE behaviour if an OD-SIB1 PDCCH is detected in Type0-PDCCH occasion before the UE receives the RAR after the UL WUS transmission.


FL Proposal 6-2 (Apple, DOCOMO, Fujitsu)
After transmitting the UL WUS, UE starts Type 0 PDCCH monitoring from the later one between N slots after RAR reception and offsetToTimeWindow slots after the reference time point.
[N= ]

Figure to illustrate RAR processing from [34, vivo]


FL Proposal 6-3 (Sharp)
If ra-SearchSpace is not provided by WUS-Config, UE monitors the PDCCH according to a Type1-PDCCH CSS set provided by searchSpaceZero for DCI format 1_0 with CRC scrambled not only by RA-RNTI but also by SI-RNTI during the ra_ResponseWindow.


FL Proposal 6-4 (Lenovo)
Adopt the following TP for TS38.213 Clause 23.
Reason of change: To better align with previous RAN1 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.”


FL Proposal 6-5 (OPPO)
RAN1 to adopt TP#3 below.
--------------- TP#3 of TS 38.213 in Clause 23 -----------------------
If the UE identifies a RAPID associated with a corresponding PRACH transmission from the UE in a PDSCH reception scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI, the UE can be indicated by higher layers to monitor PDCCH on the second cell to detect a DCI format 1_0 with CRC scrambled by the SI-RNTI according to a Type0-PDCCH CSS set provided by SearchSpaceZero. If the UE is provided XYZ, the UE monitors PDCCH only in monitoring occasions associated with the SS/PBCH block. The UE starts monitoring PDCCH to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI in the next monitoring occasion after a number of slots provided by od-sib1-windowStartOffset from the starting slot of the window controlled by ra_ResponseWindow, and for a number of slots provided by od-sib1-WindowDuration.
--------------- end of TP#3 -------------------------------------------------------
Reason of change: Current spec text may cause confusion that the UE starts monitoring after a number of slots provided by od-sib1-windowStartOffset from the starting slot of the window controlled by ra_ResponseWindow, even without PDCCH monitoring occasions available in the slot.


FL Proposal 6-6 (OPPO)
Proposal 7: RAN1 to adopt TP#4 below.
--------------- TP#4 of TS 38.213 in Clause 23 -----------------------
The UE starts monitoring PDCCH to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI after a number of slots provided by od-sib1-windowStartOffset from the starting slot of the window controlled by ra_ResponseWindow, and for a number of slots provided by od-sib1-WindowDuration.
[If the SS/PBCH block on the second cell indicates  for FR1 or  for FR2,] the UE is not required to monitor PDCCH on the second cell to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI prior to a reception of a PDSCH scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI.
--------------- end of TP#4 -------------------------------------------------------
Reason of change: This part is duplicated with the paragraph above it.


FL Proposal 6-7 (Tejas, Huawei/HiSilicon)
The reference point to determine the starting slot of on-demand SIB1 window is the start of the slot containing the starting symbol of the RAR window.



Issue 7: 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 #121 are collected below:

MTK:
Proposal 4: When OD-SIB1 window starting time falls into the middle of SSB burst, it is up to UE implementation to handle this scenario.

Figure from [R1-2401292, MTK]

Nokia
Observation-4: As specified in Clause 13 of TS38.213, legacy UE determines the slot to monitor Type0- PDCCH based on the SS/PBCH block index, since legacy UE obtains the Type0-PDCCH configurations from PBCH/MIB carried by SS/PBCH block. 

Observation-5: For legacy operation, the time reference for UE monitoring of Type0-PDCCH is the SSB block slot.

Proposal-8: RAN1 to discuss how UE determines the slot number and symbols for OD-SIB1 monitoring occasions, i.e. the time resources (slots, symbols) for Type 0 PDCCH monitoring occasions within the SIB1 transmission window. 

Proposal-9: RAN1 to clarify whether or not the index of starting slot n0 in TS38.213, for UE to monitor Type0-PDCCH of OD-SIB1 should incorporate with RAR reception slot index. 

Proposal-10: RAN1 to clarify if UE should consider that the index of starting slot n0 in TS38.213, for UE to monitor Type0-PDCCH of OD-SIB1 is based on SS/PBCH block received after RAR reception.

ZTE, Sanechips
Proposal 3: Whether the OD-SIB1 can be updated within the time window should follow legacy spec. There is no need to restrict the payloads of the OD-SIB1 transmitted in the time window should be the same.

Proposal 4: The transmission of the updated SIB1 and the updated WUS configuration on the NES cell should be within a time duration.

FL Proposal 7-1 (MTK)
When the OD-SIB1 window starting time falls into the middle of SSB burst and/or SIB1 transmission time corresponding to one SSB burst, it is up to UE implementation to monitor
from the first Type 0 PDCCH monitoring occasion inside the OD-SIB1 window, or 
from the first Type 0 PDCCH monitoring occasion inside the OD-SIB1 window corresponding to the next SSB burst.


FL Proposal 7-2 (Nokia)
RAN1 to clarify:
how UE determines the slot number and symbols for OD-SIB1 monitoring occasions, i.e. the time resources (slots, symbols) for Type 0 PDCCH monitoring occasions within the SIB1 transmission window
whether or not the index of starting slot n0 in TS38.213, for UE to monitor Type0-PDCCH of OD-SIB1 should incorporate with RAR reception slot index
if UE should consider that the index of starting slot n0 in TS38.213, for UE to monitor Type0-PDCCH of OD-SIB1 is based on SS/PBCH block received after RAR reception


FL Proposal 7-3 (ZTE)
Whether the OD-SIB1 can be updated within the time window should follow legacy spec, i.e. no restriction on the payloads of the transmitted OD-SIB1 being the same in the time window.


FL Proposal 7-4 (ZTE)
Proposal 4: The transmission of the updated SIB1 and the updated WUS configuration on the NES cell should be within a time duration.


Issue 8: Whether other features such as RedCap and NR-U can be combined with OD-SIB1 (vivo)
Background
The following proposals are brought up in RAN1 #121:

FUTUREWEI
Proposal 3: In the absence of supporting performance evaluations for NR-U, and considering LBT complexity, we recommend excluding OD-SIB1 for NR-U in Rel-19.

Observation 1: The R19 OD-SIB1 feature requires changes of the legacy RedCap initial access.

Proposal 4: If RAN1 supports R19 OD-SIB1 feature for RedCap UEs, provide in UL WUS configuration information on RedCap barring access to the NES cell.

vivo
Observation 3: Both network energy and UE power can be saved if there is an advance indication that whether redcap feature is not supported or not. 

Proposal 9: Add a parameter such as RedCapAllowed in WUS configuration to indicate whether NES cell supports RedCap UEs to request OD-SIB1.

Proposal 10: Add LBT type in WUS configuration to support NES cell in unlicensed band.

Ofinno
Proposal 4: Do not study whether the OD-SIB1 can be made applicable to RedCap features in Rel-19 NES WI.

FL Proposal 8-1 (vivo, FUTURWEI)
Add a parameter such as RedCapAllowed in WUS configuration to indicate whether NES cell supports RedCap UEs to request OD-SIB1.


FL Proposal 8-2 (vivo)
Add LBT type in WUS configuration to support NES cell in unlicensed band.


FL Proposal 8-3 (FUTUREWEI)
Exclude support of OD-SIB1 for NR-U in Rel-19.


Issue 9: RO selection based on rsrp-ThresholdSSB
Background
The following proposals are brought up in RAN1 #121:

DCM:
Proposal 2:  
It is up to RAN2 to decide the SSB and PRACH resource selection criterion for UE sending a WUS.

FL Proposal 9-1 (DOCOMO)
It is up to RAN2 to decide the SSB and PRACH resource selection criterion for UE sending a WUS.


Issue 10: Whether/how to indicate the OD-SIB1 transmission status to UE
Background
In RAN2 #127b, the following is agreed
Agreement
A cell for which SIB1 request configuration is available, can periodically broadcast SIB1.

Agreement
If UE has SIB1 request configuration of a cell, UE needs to check if SIB1 is currently being broadcasted or provided on demand for that cell before requesting SIB1 of that cell.

In RAN1 #120, it was agreed that:
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.

In RAN1 #120b, it was agreed that:
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>=123 for FR2, select the following:
Alt. 3: It is up to UE implementation on whether to monitor Type 0 PDCCH for SIB1 transmission


Companies’ views for this topic in RAN1 #121 are collected below:

Sony:
Proposal 1: The information indicating the transmission status of SIB1 (e.g., whether the SIB1 of the NES cell is currently being broadcasted or provided on demand) should be included in UL WUS configuration.

CEWiT:
Proposal 3: Support indicating the transmission status of on-demand SIB1 using repurposed parameters in MIB or PBCH of NES cell for idle UEs.

Proposal 4: 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)

vivo
Proposal 8: UE monitors type 0 PDCCH for SIB1 acquisition using the kssb and pdcch-ConfigSIB1 in the latest stored WUS configuration after receiving Short Message indicating SI change notification.

Samsung
Proposal 1: Make a conclusion in RAN1 that it’s up to gNB implementation to set the kSSB value to be <24 in
FR1 or <12 in FR2, such that legacy UE can camp on the cell when on-demand SIB1 is broadcasted.

CATT
Observation 1: If NES cell transmits SSB and the SSB is with 23< kSSB < kSSB

Proposal 1: 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 2: If NES cell transmits SSB and the kSSB = 30 for FR1 or kSSB = 14 for FR2, on demand SIB1 is currently being broadcasted.

Observation 2: There is a conflict between the agreements of RAN1 and RAN2. The agreement of RAN1 allows the UE implementation to determine whether to monitor Type 0 PDCCH for SIB1 transmission or not by implementation. In contrast, the agreement of RAN2 requires the UE to monitor Type 0 PDCCH before requesting SIB1.

Proposal 3: Update RAN1#120-b agreement to support RAN2 agreement.

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, 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

FL Proposal 10-1 (Sony, CEWIT, CATT)
Support indicating the transmission status of on-demand SIB1 using repurposed parameters in MIB or PBCH or UL WUS configuration of NES cell.


FL Proposal 10-2 (vivo)
UE monitors type 0 PDCCH for SIB1 acquisition using the kssb and pdcch-ConfigSIB1 in the latest stored WUS configuration after receiving Short Message indicating SI change notification.


Issue 11: Relation between OD-SIB1 procedure and existing on-demand SI procedure
Background
The following proposals are brought up in RAN1 #121:

LG:
Proposal #5: Discuss how to guarantee on-demand SIB1 transmission while the UE receives SIBx (other than SIB1) or performs the existing on-demand SI procedure.

FL Proposal 11-1 (LG)
Discuss how to guarantee on-demand SIB1 transmission while the UE receives SIBx (other than SIB1) or performs the existing on-demand SI procedure.


Issue 12: MAC subPDU location identification for RAR of OD-SIB1 request
Background
The following proposals are brought up in RAN1 #121:

Sharp:
Proposal 1: To solve the issue on MAC subPDU location identification for RAR of OD-SIB1 request, 
RAN1 should consider following options:
Option 1: RACH occasion for OD-SIB1 request is a dedicated resource and is not used for other purpose
Option 2: New RNTI is introduced for RAR of OD-SIB1 request
Option 3: OD-SIB1 request configuration includes configuration of OD-OSI request (RAPID 
information)

FL Proposal 12-1 (Sharp)
RAN1 should consider following options to solve the issue on MAC subPDU location identification for RAR of OD-SIB1 request
Option 1: RACH occasion for OD-SIB1 request is a dedicated resource and is not used for other purpose
Option 2: New RNTI is introduced for RAR of OD-SIB1 request
Option 3: OD-SIB1 request configuration includes configuration of OD-OSI request (RAPID 
information)


Issue 13: PRACH transmission for SIB1 request
Background
The following proposals are brought up in RAN1 #121:

Google:
Proposal 1: Endorse the following TP for 38.211 to clarify the PRACH transmission for SIB1 request
--------------------------------- start of TP for 38.211-------------------------------------
5.3.2	OFDM baseband signal generation for PRACH

-	 is the subcarrier spacing of the initial uplink bandwidth part during initial access. If the PRACH transmission is for a candidate cell  is provided by ltm-PRACH-SubcarrierSpacing in EarlyUL-SyncConfig. If the PRACH transmission is for SIB1 request,  is provided by SIB1-RequestConfig. Otherwise,  is the subcarrier spacing of the active uplink bandwidth part; 
-	 is the largest  value among the subcarrier spacing configurations by the higher-layer parameter scs-SpecificCarrierList;
-	 is the lowest numbered resource block of the initial uplink bandwidth part and is derived by the higher-layer parameter initialUplinkBWP or initialUplinkBWP-RedCap during initial access and from the higher-layer parameters bwp-GenericParameters in EarlyUL-SyncConfig if the PRACH transmission is for a candidate cell and from the higher-layer parameters SIB1-RequestConfig if the PRACH transmission is for SIB1 request. Otherwise,  is the lowest numbered resource block of the active uplink bandwidth part and is derived by the higher-layer parameter BWP-Uplink; 

6.3.3.1	Sequence generation

There are 64 preambles defined in each time-frequency PRACH occasion, enumerated in increasing order of first increasing cyclic shift  of a logical root sequence, and then in increasing order of the logical root sequence index, starting with the index obtained from the higher-layer parameter prach-RootSequenceIndex or rootSequenceIndex-BFR or by msgA-PRACH-RootSequenceIndex if configured and a type-2 random-access procedure is initiated as described in clause 8.1 of [5, TS 38.213] or by prach-RootSequenceIndex in EarlyUL-SyncConfig if the PRACH transmission is for a candidate cell or by prach-RootSequenceIndex in SIB1-RequestConfig if the PRACH transmission is for SIB1 request. Additional preamble sequences, in case 64 preambles cannot be generated from a single root Zadoff-Chu sequence, are obtained from the root sequences with the consecutive logical indexes until all the 64 sequences are found. The logical root sequence order is cyclic; the logical index 0 is consecutive to . The sequence number  is obtained from the logical root sequence index according to Tables 6.3.3.1-3 to 6.3.3.1-4B.
--------------------------------- start of TP for 38.211-------------------------------------

FL Proposal 13-1 (Google)
Adopt the following TP for 38.211 to clarify the PRACH transmission for SIB1 request.
--------------------------------- start of TP for 38.211-------------------------------------
5.3.2	OFDM baseband signal generation for PRACH

-	 is the subcarrier spacing of the initial uplink bandwidth part during initial access. If the PRACH transmission is for a candidate cell  is provided by ltm-PRACH-SubcarrierSpacing in EarlyUL-SyncConfig. If the PRACH transmission is for SIB1 request,  is provided by SIB1-RequestConfig. Otherwise,  is the subcarrier spacing of the active uplink bandwidth part; 
-	 is the largest  value among the subcarrier spacing configurations by the higher-layer parameter scs-SpecificCarrierList;
-	 is the lowest numbered resource block of the initial uplink bandwidth part and is derived by the higher-layer parameter initialUplinkBWP or initialUplinkBWP-RedCap during initial access and from the higher-layer parameters bwp-GenericParameters in EarlyUL-SyncConfig if the PRACH transmission is for a candidate cell and from the higher-layer parameters SIB1-RequestConfig if the PRACH transmission is for SIB1 request. Otherwise,  is the lowest numbered resource block of the active uplink bandwidth part and is derived by the higher-layer parameter BWP-Uplink; 

6.3.3.1	Sequence generation

There are 64 preambles defined in each time-frequency PRACH occasion, enumerated in increasing order of first increasing cyclic shift  of a logical root sequence, and then in increasing order of the logical root sequence index, starting with the index obtained from the higher-layer parameter prach-RootSequenceIndex or rootSequenceIndex-BFR or by msgA-PRACH-RootSequenceIndex if configured and a type-2 random-access procedure is initiated as described in clause 8.1 of [5, TS 38.213] or by prach-RootSequenceIndex in EarlyUL-SyncConfig if the PRACH transmission is for a candidate cell or by prach-RootSequenceIndex in SIB1-RequestConfig if the PRACH transmission is for SIB1 request. Additional preamble sequences, in case 64 preambles cannot be generated from a single root Zadoff-Chu sequence, are obtained from the root sequences with the consecutive logical indexes until all the 64 sequences are found. The logical root sequence order is cyclic; the logical index 0 is consecutive to . The sequence number  is obtained from the logical root sequence index according to Tables 6.3.3.1-3 to 6.3.3.1-4B.
--------------------------------- end of TP for 38.211-------------------------------------


Issue 14: Other topics
Discussion place holder for issues not included above.
FL Proposal 14-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 #121)
R1-2503234	Discussion of on-demand SIB1 for idle/inactive mode UEs	FUTUREWEI
R1-2503268	Discussion on on-demand SIB1 for eNES	Huawei, HiSilicon
R1-2503316	Discussion on on-demand SIB1 for NES	ZTE Corporation, Sanechips
R1-2503366	Remaining issues on-demand SIB1 for idle/inactive mode UEs   vivo
R1-2503413	On-demand SIB1 for Idle/Inactive mode UEs	Nokia, Nokia Shanghai Bell
R1-2503417	Discussion on on-demand SIB1 for UEs in idle/inactive mode	NEC
R1-2503520	Discussion on on-demand SIB1 for idle/inactive mode UEs	Spreadtrum, UNISOC
R1-2503571	On-demand SIB1 for idle/inactive mode UEs	Samsung
R1-2503717	OD-SIB1 for idle/inactive UEs	Tejas Network Limited
R1-2503738	Discussion on on-demand SIB1 for idle/inactive mode UEs	Ofinno
R1-2503798	Discussion on on-demand SIB1	CATT
R1-2503836	Discussion on on-demand SIB1 for UEs in idle/inactive mode	CMCC
R1-2503887	Discussion on on-demand SIB1 for idle/inactive mode UEs	Xiaomi
R1-2503973	Discussion on on-demand SIB1 for idle/inactive mode UEs	InterDigital, Inc.
R1-2503999	Discussion on on-demand SIB1 transmission for network energy savings	Fujitsu
R1-2504016	On-demand SIB1 for UEs in idle/inactive mode for NES	Ericsson
R1-2504031	On-demand SIB1 for Idle/Inactive Mode UE	 Google
R1-2504051	Discussion on on-demand SIB1 for idle/inactive mode UEs	China Telecom
R1-2504065	On-demand SIB1 for idle/inactive mode UEs	Sony
R1-2504108	On-demand SIB1 for idle/inactive mode UEs	Lenovo
R1-2504142	On-demand SIB1 for idle/inactive mode UEs	ETRI
R1-2504177	Discussion on on-demand SIB1 transmission for idle/inactive mode UEs Transsion Holdings
R1-2504193	Discussion on the enhancement to support on demand SIB1 for idle/inactive mode UE OPPO
R1-2504236	Discussion on on-demand SIB1 for idle/inactive mode UEs	Panasonic
R1-2504248	On-demand SIB1 for idle/inactive mode UEs	LG Electronics
R1-2504263	On-demand SIB1 for idle or inactive mode UEs	MediaTek Inc.
R1-2504326	On On-demand SIB1 for IDLE/INACTIVE mode UEs	Apple
R1-2504399	On-demand SIB1 procedure	Qualcomm Incorporated
R1-2504457	Discussion on on-demand SIB1 for idle/inactive mode UEs	DENSO CORPORATION
R1-2504467	Discussion on on-demand SIB1 transmission for idle UEs	Sharp
R1-2504506	Discussion on on-demand SIB1 for idle/inactive mode UEs	NTT DOCOMO, INC.
R1-2504556	Discussion on on-demand SIB1 in idle/inactive mode	CAICT
R1-2504603	Discussion on  on-demand SIB1	CEWiT
R1-2501811	Discussions on on-demand SIB1 for idle/inactive mode UEs	vivo (RAN1 #120b)

pat3GPP TSG RAN WG1 #121							   R1-2504680
St Julian’s, Malta, May 19th – 23th, 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


In RAN1 #120-bis, the following are agreed:

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
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.

Value range for od-sib1-duration:
On the value range of od-sib1-duration, companies’ views in RAN1 #121 are collected below:

China Telecom:
Proposal 2: Support Option 1, i.e., use the value range for si-windowLength (from 5 slots to 5120slots) as a 
starting point for the value range of od-sib1-duration.

Lenovo:
Proposal 3: Use the value-range for si-windowLength (from 5 slots to 5120 slot) for configuring od-sib1-duration.

ETRI:
Proposal 1: Use the value range of si-windowLength for the OD-SIB1 window duration (Option 1).
FFS: Whether/how to guarantee valid Type 0 PDCCH monitoring occasion(s) within the window

Transsion:
Proposal 2  For the value range for od-sib1-duration, option 2 or option 3 can be supported.

OPPO:
Proposal 1: the value range for is (40 ms, 60 ms, 80 ms,..., 250 ms) with granularity of 20 ms. 

Proposal 2: the value range for the time offset between the reference time point and the starting time of the OD-SIB1 window is (0 ms, 20 ms, 40 ms).

Proposal 3: If RAN1 agreement on OD-SIB1 duration can be reverted, we suggest that the OD-SIB1 duration should be configured in terms of the number of type0-PDCCH monitoring occasions.

Panasonic:
Proposal 2: The value range of od-sib1-durati on is defi ned as the duration of the time window of a multiple of 160ms (i.e. legacy SIB1 periodicity).

MTK: Option 2: multiple of 160ms

Apple:
Proposal 1: For the value range of od-sib1-duration, consider the following two options: 
- Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point.
- Option 4: The duration of the time window can be a multiple of 20ms

QC:
Proposal 2: The value range of the PDCCH monitoring window od-sib1-duration is the same value range as si-windowLength (i.e., Option 1).

DENSO:
Proposal 2: The value range for the duration of the on-demand SIB1 window is specified as a multiple of the 
on-demand SIB1 repetition periodicity (Option 3).

Proposal 3: ULSubcarrierSpacing is used for the subcarrier spacing for PRACH baseband signal generation.

DCM:
Proposal 3: The duration of OD-SIB1 window could be multiple of 160ms, e.g., [160ms, 320ms, 640ms, 1280ms].

CEWiT:
Proposal 2: Support Option 3 “The duration of the time window can be a multiple of the on-demand SIB1 
repetition periodicity” for the value range for si-windowLength.

FUTUREWEI
Proposal 2: Support Option 2: The value range for od-sib1-duration can be a multiple of 160ms.

Huawei, HiSilicon
Proposal 3: Support to use the value-range for si-windowLength (from 5 slots to 5120 slots) as the value range for odsib1-duration.

ZTE, Sanechips
Proposal 2: For the value range for od-sib1-duration, both option 2 and option 3 can be considered.

vivo
Proposal 6: Support option1 for the value range for od-sib1-duration, i.e., use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point.

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

Proposal-1: RAN1 to discuss that the duration of OD-SIB1 window, od-sib1-WindowDuration, is a multiple of MIB TTI of 80 ms to avoid PBCH combining issue at UE.

Proposal-3: For OD-SIB1 operation, RAN1 to discuss whether the duration of OD-SIB1 window, od-sib1- WindowDuration shall be larger/smaller than or equal to the transmission periodicity of OD-SIB1, od-sib1- periodicity.

NEC
Proposal 3: For od-sib1-duration value range, support Option-2 The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity)

Spreadtrum, UNISOC
Proposal 2 Support option 1 for od-sib1-duration. 
Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point.

Samsung
Proposal 2: Support Option 2 (The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity)) for both Rel-19 NES capable UE and legacy UE.
Minimum value of od-sib1-duration is 160 ms.

Tejas 
Proposal 3: The value range of OD-SIB1 window duration should be multiple of SSB periodicity of the NES CELL.

Ofinno
Proposal 2. Define the value range for od-sib1-duration in terms of number of slots from 5 slots to 5120 slots.

CMCC
Proposal 1: For the value range for od-sib1-duration, support Option 3 (The duration of the time window can be a multiple of the on-demand SIB1 repetition periodicity). 
20ms can be taken as the starting point for on-demand SIB1 repetition periodicity.

Xiaomi
Proposal 3: For the value range of the time window duration for on-demand SIB1, Option 1 is adopted. 
Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot) as starting point

InterDigital
Proposal 2: For the duration of OD-SIB1, support the value-range of si-windowLength (from 5 slots to 5120 slot) as starting point (Option 1)

Fujitsu
Proposal 1. Regarding od-sib1-duration, use the value range for si-windowLength (from 5 slots to 5120 slot) as the starting point.

Ericsson
Proposal 5 It is clarified that od-sib1-duration corresponds to the time duration where the NES Cell is guaranteed to transmit OD-SIB1 after an OD-SIB1 request.

Observation 4 The granularity of od-sib1-duration in terms of slots is unnecessarily fine and the range, i.e., up to 5120 slots, is unnecessarily long.

Observation 5 The duration of the time window being a multiple of 160ms (Option 2) is a reasonable compromise between flexibility and simplicity.

Observation 6 Relating the duration of the time window with the optional property of repetition periodicity can be error prone and it is best to be avoided. 

Proposal 6 Support the duration of the time window is a multiple of 160ms (Option 2). Additionally, support the duration 80ms.

Companies’ views for value range of od-sib1-duration in RAN1 #121 are summarized below:

For the value range for od-sib1-duration
Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot).
Supported by China Telecom, Lenovo, ETRI, Apple, Qualcomm, Huawei/HiSilicon, vivo, Spreadtrum/UNISOC, Ofinno, Xiaomi, InterDigital, Fujitsu
Option 2: The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity).
Supported by Transsion, Panasonic, MTK, DCM, FUTUREWEI, ZTE/Sanechips, NEC, Samsung, Ericsson (add 80ms),
Option 2a: {20, 40, 80, 160, 320,...}ms 
Supported by Apple, vivo
Option 3: The duration of the time window can be a multiple of the on-demand SIB1 repetition periodicity (if supported)
Supported by Transsion, DENSO, CEWiT, ZTE/Sanechips, CMCC (Ex. 20ms),  
Option 4: The value range for od-sib1-duration is (40 ms, 60 ms, 80 ms, ..., 240 ms) with granularity of 20 ms.
Supported by OPPO
Option 5: The duration of the time window can be configured in terms of the number of type0-PDCCH monitoring occasions.
Supported by OPPO
Option 6: Multiple of 20ms
Supported by Apple
Option 7: Multiple of 80ms
Supported by Nokia
Option 8: Multiple of SSB periodicity of the NES cell
Supported by Tejas
FL Proposal 3-1
On the value range for od-sib1-duration, adopt the following:
Option 1: Use the value-range for si-windowLength (from 5 slots to 5120 slot)

Vivo: Unit is ms first
FL Proposal 3-1-2
On the value range for od-sib1-duration, adopt the following:
Option 2: The duration of the time window can be a multiple of 160ms (i.e. legacy SIB1 periodicity).


FL Proposal 3-1-3 (Apple)
On the value range for od-sib1-duration, adopt the following:
{20, 40, 80, 160, 320, ...} ms

FL Proposal 3-2 (Ericsson)
RAN1 confirms that od-sib1-duration corresponds to the time duration where the NES Cell is guaranteed to transmit OD-SIB1 after an OD-SIB1 request.
Note: It is up to the NES Cell to decide whether to prolong it


OD-SIB1 transmission/repetition periodicity:
On OD-SIB1 transmission/repetition periodicity, companies’ views in RAN1 #121 are collected below:

Nokia
Observation-1: For legacy OD-SI operation, as specified in TS38.331, the network always configures si-WindowLength to be shorter than or equal to the si-Periodicity.

Proposal-2: RAN1 to discuss what the transmission periodicity of OD-SIB1, od-sib1-periodicity, is. Is it the same as legacy SIB1 transmission periodicity of 160 ms or is it aligned with the legacy OD-SI transmission periodicity, where the value range can be from 80 ms to 5120 ms. 

Proposal-4: RAN1 to discuss the NW indication of repetition periodicity or periodicity of OD-SIB1 transmission in UL WUS configuration.

Fujitsu
Proposal 4. Regarding the UE assumption on on-demand SIB1 repetitions within the time window, UE assumes that the SIB1 transmitted within the time window follows the legacy SIB repetition mechanism, i.e., repetition within a 160 ms period.

Ericsson
Observation 3 If the UE knows the SIB1 transmission pattern within a 160 ms period, then it can avoid blind detection in Type0 PDCCH CSS occasions which are not used.

Proposal 3 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 4 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.

FL Proposal 3-3 (Nokia, Fujitsu)
RAN1 to clarify the transmission periodicity of OD-SIB1 is
Option 1: same as legacy SIB1 transmission periodicity of 160 ms
Option 2: aligned with the legacy OD-SI transmission periodicity, where the value range can be from 80 ms to 5120 ms.


FL Proposal 3-3-2 (Fujitsu)
RAN1 to draw the following conclusion:
Regarding the UE assumption on on-demand SIB1 repetition/transmission within the time window, UE assumes that the SIB1 transmitted within the time window follows the legacy SIB1 repetition mechanism, i.e., repetition within a 160 ms period.

FL Proposal 3-3-3 (LG)
RAN1 to draw the following conclusion:
The legacy behavior below is applied for OD-SIB1.
The SIB1 is transmitted on the DL-SCH with a periodicity of 160 ms and variable transmission repetition periodicity within 160 ms.

FL Proposal 3-4 (Nokia, Ericsson)
Support NW indication of repetition periodicity or periodicity of OD-SIB1 transmission in UL WUS configuration.
FFS more parameters in the UL WUS configuration:
SIB1 offset
SIB1 search space mask
Note: These parameters are also valid after the on-demand SIB1 acquisition procedure.


Parameters inside UL-WUS configuration other than od-sib1-duration:
On parameters inside UL-WUS configuration other than od-sib1-duration, companies’ views in RAN1 #121 are collected below:

OPPO:
Proposal 4:	RAN1 adopts TP#1 below.
--------------- TP#1 of TS 38.213 in Clause 23 -----------------------
Unless otherwise mentioned, the higher layer parameters in this clause and in referenced clauses are provided by SIB1-RequestConfig on a first cell. 
A UE can be provided, by NES_CellId, a physical cell identity of a second cell and an ARFCN by ARFCN-ValueNR for SS/PBCH block receptions on the second cell. When
-	the UE receives an SS/PBCH block on the second cell, and
-	 for FR1 or  for FR2 is indicated by the SS/PBCH block on the second cell, and
-	conditions for PRACH transmission associated with the SS/PBCH block on the second cell are satisfied [12, TS 38.331],
the UE can transmit a PRACH associated with the SS/PBCH block on the second cell based on:
-	a timing adjustment indicated by n-TimingAdvanceOffset, if provided, as described in Clause 4.2  
-	a power determined as described in Clause 7.4  
-	a procedure determined as in Clause 8.1 based on Type-1 random access procedure
where  for determining the common resource block [4, TS 38.211] is provided by k-ssb. A CORESET for Type0-PDCCH CSS and Type1-PDCCH CSS is provided by controlResourceSetZero.
--------------- end of TP#1 -------------------------------------------------------


ZTE, Sanechips
Proposal 6: Two options for UE to obtain the UL point A for TDD should be considered.
Option 1: Configure offsetToPointA in the UL WUS configuration at least for TDD.
Option 2: The absoluteFrequencyPointA is also present in IE FrequencyInfoUL for TDD.

vivo
Proposal 1: The design principle for WUS configuration is to minimize the size of mandatory parameters in WUS configuration as much as possible.

Observation 1: UE needs to distinguish whether the received WUS configuration applies to the serving cell or other NES cells. 

Observation 2: UE can distinguish the received WUS configuration applies to the serving cell or other NES cells based on PhysCellId which is mandatory configured in WUS configuration. 

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

Proposal 3: Some parameters in WUS configuration can follow the value of the counterpart of cellA to further reduce the payload of WUS configuration.

Proposal 4: Include offsetToPointA in the WUS configuration that is mandatorily present for TDD (to derive UL point A as in legacy).

Proposal 5: frequencyBandList is mandatorily present in WUS configuration for TDD system, which refers to the IE within FrequencyInfoDL-SIB.

Proposal 11: support to change the following names to align with RAN2 running CR. 
rsrp-ThresholdSSB -> rsrp-SIB1ThresholdSSB, 
ra-PreambleStartIndex -> ra-SIB1PreambleStartIndex, 
ra-AssociationPeriodIndex -> ra-AssociationPeriodIndexSib1

NEC
Proposal 1: 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.

Tejas
Proposal 1: The parameters ‘absoluteFrequencyPointA’, ‘offsetToCarrier’ and ‘locationAndBandwidth’ need to be mandatorily present in the UL-WUS configuration for both FDD and TDD system.

Google
Proposal 2: Support to configure the bandwidth for downlink to improve the performance for RAR and ODSIB1.

FL Proposal 3-6 (OPPO)
RAN1 to adopt TP#1 below:
--------------- TP#1 of TS 38.213 in Clause 23 -----------------------
Unless otherwise mentioned, the higher layer parameters in this clause and in referenced clauses are provided by SIB1-RequestConfig on a first cell. 
A UE can be provided, by NES_CellId, a physical cell identity of a second cell and an ARFCN by ARFCN-ValueNR for SS/PBCH block receptions on the second cell. When
-	the UE receives an SS/PBCH block on the second cell, and
-	 for FR1 or  for FR2 is indicated by the SS/PBCH block on the second cell, and
-	conditions for PRACH transmission associated with the SS/PBCH block on the second cell are satisfied [12, TS 38.331],
the UE can transmit a PRACH associated with the SS/PBCH block on the second cell based on:
-	a timing adjustment indicated by n-TimingAdvanceOffset, if provided, as described in Clause 4.2  
-	a power determined as described in Clause 7.4  
-	a procedure determined as in Clause 8.1 based on Type-1 random access procedure
where  for determining the common resource block [4, TS 38.211] is provided by k-ssb. A CORESET for Type0-PDCCH CSS and Type1-PDCCH CSS is provided by controlResourceSetZero.
--------------- end of TP#1 -------------------------------------------------------
Reason of change: The CORESET#0 configuration is not included in Clause 23 of current R19 draft spec. Thus, the UE cannot know that the configuration of CORESET#0 is provided by SIB1-RequestConfig if not specified.


FL Proposal 3-6-1 (Samsung)
RAN1 to adopt TP#1 below:
--------------- TP#1 of TS 38.213 in Clause 23 -----------------------
Unless otherwise mentioned, the higher layer parameters in this clause and in referenced clauses are provided by SIB1-RequestConfig on a first cell. 
A UE can be provided, by NES_CellId, a physical cell identity of a second cell and an ARFCN by ARFCN-ValueNR for SS/PBCH block receptions on the second cell. When
-	the UE receives an SS/PBCH block on the second cell, and
-	 for FR1 or  for FR2 is indicated by the SS/PBCH block on the second cell, and
-	conditions for PRACH transmission associated with the SS/PBCH block on the second cell are satisfied [12, TS 38.331],
the UE can transmit a PRACH associated with the SS/PBCH block on the second cell based on:
-	a timing adjustment indicated by n-TimingAdvanceOffset, if provided, as described in Clause 4.2  
-	a power determined as described in Clause 7.4  
-	a procedure determined as in Clause 8.1 based on Type-1 random access procedure
where  for determining the common resource block [4, TS 38.211] is provided by k-ssb. The UE determines a CORESET of the Type0-PDCCH CSS from controlResourcesetZero provided in [uplink-WUS-Config] and determines Type0-PDCCH monitoring occasions from searchSpaceZero provided in [uplink-WUS-Config]
--------------- end of TP#1 -------------------------------------------------------
Reason of change: The CORESET#0 configuration is not included in Clause 23 of current R19 draft spec. Thus, the UE cannot know that the configuration of CORESET#0 is provided by SIB1-RequestConfig if not specified.


FL Proposal 3-7 (ZTE, vivo, Tejas)
RAN1 to adopt one of the following two options for UE to obtain the UL point A for TDD system.
Option 1: Configure offsetToPointA in the UL WUS configuration at least for TDD system.
Option 2: Configure absoluteFrequencyPointA under the IE FrequencyInfoUL also for TDD system.


FL Proposal 3-8 (vivo)
If a cell indicates a WUS configuration applying to serving cell itself, some parameters can follow the same values in the SIB1 of the cell itself to reduce the payload of WUS configuration.


FL Proposal 3-9 (vivo)
Some parameters in WUS configuration can follow the values of cell A to reduce the payload of WUS configuration.


FL Proposal 3-10 (vivo)
The frequencyBandList is mandatorily present in WUS configuration for TDD system, which refers to the IE within FrequencyInfoDL-SIB.


FL Proposal 3-11 (Tejas)
The parameters ‘absoluteFrequencyPointA’, ‘offsetToCarrier’ and ‘locationAndBandwidth’ are mandatorily present in the UL-WUS configuration for both FDD and TDD system.


FL Proposal 3-11-2 (Tejas)
The parameters ‘absoluteFrequencyPointA’, ‘offsetToCarrier’ and ‘locationAndBandwidth’ are mandatorily present in the UL-WUS configuration for both FDD and TDD system.


FL Proposal 3-12 (Google)
Configure the bandwidth for downlink in the UL WUS configuration (to improve the performance for RAR and OD-SIB1).


Issue 4: UL-WUS on NES cell overlapping with paging occasion on normal cell
Background

It is agreed in RAN2 #129b that:
Agreement
Leave this issue (how to handle paging interruption during OD-SIB1 acquisition) to RAN4.

Companies’ views for this topic in RAN1 #121 are collected below:

MTK
Proposal 2: 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. UE should prioritize paging if the overlapping happens.

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

Transsion:
Proposal 4  There is no need to resolve the issue of UL WUS on NES cell overlapping with paging occasion on normal cell.

CAICT:
Proposal 3:  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.

ZTE, Sanechips
Proposal 5: UE behavior in the case that the resources of UL WUS in NES cell and paging occasions on cell A are overlapped can be up to UE implementation.

Ofinno
Proposal 3: The impact of UL WUS in the NES cell on paging in the normal cell is up to RAN4 decision.

Fujitsu
Proposal 5. How to handle the collision issue between UL WUS occasions in NES cell and paging occasions in Cell A is left to RAN4.


For this topic, companies’ views in RAN1 #121 are summarized below
What should UE do if UL-WUS on NES cell overlapped with paging occasion on Cell A
Up to UE implementation: Transsion, CAICT, ZTE/Sanechips,
UE prioritizes receiving the paging occasion from Cell A: MTK
Left to RAN4: Ofinno, Fujitsu, MTK

FL Proposal 4-1
It is up to RAN4 to discuss whether to prioritize paging 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 5: UE to monitor the RAR for SIB1 requests sent by other UEs
Background
The following proposals are brought up in RAN1 #121:


LG:
Proposal #2: To support UEs to monitor the RAR for SIB1 requests sent by other UEs, UE may monitor 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.

FL Proposal 5-1 (LG)
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.
To support UEs to monitor the RAR for SIB1 requests sent by other UEs,


Issue 6: 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.

In RAN1 #120-bis, it is agreed that:
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.


Companies’ views for this topic in RAN1 #121 are collected below:

China Telecom:
Proposal 3: It should be up to UE’s implement to monitor OD-SIB1 during the RAR window before the OD-SIB1 window starts.

LG:
Proposal #1: RAN1 to discuss whether to specify the UE behaviour if an OD-SIB1 PDCCH is detected in Type0-PDCCH occasion before the UE receives the RAR after the UL WUS transmission.

Apple:
Proposal 2: UE starts monitoring Type-0 PDCCH occasions within the OD-SIB1 monitoring window, from the 
first PDCCH monitoring occasion that is at least N slots from the ending slot of RAR reception.

DCM:
Proposal 4:
UE monitors from the first type 0 PDCCH monitoring occasion associated with one or all SSB(s) according to 1-bit indication in UL-WUS from the starting of the slot which is n slot after the slot of PDSCH of RAR reception. 
where,  

Fig.1 Starting time of PDCCH monitoring occasion  

Fujitsu
Observation 2. When the on-demand SIB1 time window overlaps with the RAR window, skipping Type0- PDCCH occasions can lead to PDCCH reception failure and increased network energy consumption. Therefore, it is crucial to strictly specify when the UE shall start monitoring Type0-PDCCH occasion for on-demand SIB1.

Proposal 2. The UE starts the PDCCH monitoring at the first symbol of the earliest CORESET the UE is configured to receive PDCCH for Type0-PDCCH CSS set, after whichever is later between the time offset relative to the starting slot of the RAR window and the RAR reception.

Sharp:
Proposal 2: If ra-SearchSpace is not provided by WUS-Config, allow the UE to monitor the PDCCH according to a Type1-PDCCH CSS set provided by searchSpaceZero for DCI format 1_0 with CRC scrambled not only by RA-RNTI but also by SI-RNTI during the ra_ResponseWindow.

Lenovo:
Proposal 1: Adopt the following TP for TS38.213,

OPPO:
Proposal 6: RAN1 to adopt TP#3 below.
--------------- TP#3 of TS 38.213 in Clause 23 -----------------------
If the UE identifies a RAPID associated with a corresponding PRACH transmission from the UE in a PDSCH reception scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI, the UE can be indicated by higher layers to monitor PDCCH on the second cell to detect a DCI format 1_0 with CRC scrambled by the SI-RNTI according to a Type0-PDCCH CSS set provided by SearchSpaceZero. If the UE is provided XYZ, the UE monitors PDCCH only in monitoring occasions associated with the SS/PBCH block. The UE starts monitoring PDCCH to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI in the next monitoring occasion after a number of slots provided by od-sib1-windowStartOffset from the starting slot of the window controlled by ra_ResponseWindow, and for a number of slots provided by od-sib1-WindowDuration.
--------------- end of TP#3 -------------------------------------------------------

Proposal 7: RAN1 to adopt TP#4 below.
--------------- TP#4 of TS 38.213 in Clause 23 -----------------------
[If the SS/PBCH block on the second cell indicates  for FR1 or  for FR2,] the UE is not required to monitor PDCCH on the second cell to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI prior to a reception of a PDSCH scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI.
--------------- end of TP#4 -------------------------------------------------------

Tejas
Proposal 2: The reference point to determine the starting slot of on-demand SIB1 window is the start of the slot containing the starting symbol of the RAR window.

Huawei, HiSilicon
Proposal 1: Adopt TP#1 to clarify the reference time point to determine the starting slot of on-demand SIB1 window is the slot containing the starting symbol of RAR window.


FL Proposal 6-1 (LG)
RAN1 to discuss whether to specify the UE behaviour if an OD-SIB1 PDCCH is detected in Type0-PDCCH occasion before the UE receives the RAR after the UL WUS transmission.


FL Proposal 6-2 (Apple, DOCOMO, Fujitsu)
After transmitting the UL WUS, UE starts Type 0 PDCCH monitoring from the later one between N slots after RAR reception and offsetToTimeWindow slots after the reference time point.
[N= ]

Figure to illustrate RAR processing from [34, vivo]


FL Proposal 6-3 (Sharp)
If ra-SearchSpace is not provided by WUS-Config, UE monitors the PDCCH according to a Type1-PDCCH CSS set provided by searchSpaceZero for DCI format 1_0 with CRC scrambled not only by RA-RNTI but also by SI-RNTI during the ra_ResponseWindow.


FL Proposal 6-4 (Lenovo)
Adopt the following TP for TS38.213 Clause 23.
Reason of change: To better align with previous RAN1 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.”


FL Proposal 6-5 (OPPO)
RAN1 to adopt TP#3 below.
--------------- TP#3 of TS 38.213 in Clause 23 -----------------------
If the UE identifies a RAPID associated with a corresponding PRACH transmission from the UE in a PDSCH reception scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI, the UE can be indicated by higher layers to monitor PDCCH on the second cell to detect a DCI format 1_0 with CRC scrambled by the SI-RNTI according to a Type0-PDCCH CSS set provided by SearchSpaceZero. If the UE is provided XYZ, the UE monitors PDCCH only in monitoring occasions associated with the SS/PBCH block. The UE starts monitoring PDCCH to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI in the next monitoring occasion after a number of slots provided by od-sib1-windowStartOffset from the starting slot of the window controlled by ra_ResponseWindow, and for a number of slots provided by od-sib1-WindowDuration.
--------------- end of TP#3 -------------------------------------------------------
Reason of change: Current spec text may cause confusion that the UE starts monitoring after a number of slots provided by od-sib1-windowStartOffset from the starting slot of the window controlled by ra_ResponseWindow, even without PDCCH monitoring occasions available in the slot.


FL Proposal 6-5-1 (Ericsson, QC)
RAN1 to adopt TP below.
--------------- TP of TS 38.213 in Clause 23 -----------------------
If the UE identifies a RAPID associated with a corresponding PRACH transmission from the UE in a PDSCH reception scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI, the UE can be indicated by higher layers to monitor PDCCH on the second cell to detect a DCI format 1_0 with CRC scrambled by the SI-RNTI according to a Type0-PDCCH CSS set provided by SearchSpaceZero. If the UE is provided XYZ, the UE monitors PDCCH only in monitoring occasions associated with the SS/PBCH block. The UE starts monitoring monitors PDCCH to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI after a number of slots provided by od-sib1-windowStartOffset from the starting slot of the window controlled by ra_ResponseWindow, and for a number of slots provided by od-sib1-WindowDuration.
--------------- end of TP -------------------------------------------------------
Reason of change: Considering the RAR processing time and OD-SIB1 window starting time may fall into the middle of SSB burst and/or SIB1 transmission time corresponding to one SSB burst, when to start the PDCCH monitoring in the OD-SIB1 window is up to UE implementation.



FL Proposal 6-6 (OPPO)
Proposal 7: RAN1 to adopt TP#4 below.
--------------- TP#4 of TS 38.213 in Clause 23 -----------------------
The UE starts monitoring PDCCH to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI after a number of slots provided by od-sib1-windowStartOffset from the starting slot of the window controlled by ra_ResponseWindow, and for a number of slots provided by od-sib1-WindowDuration.
[If the SS/PBCH block on the second cell indicates  for FR1 or  for FR2,] the UE is not required to monitor PDCCH on the second cell to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI prior to a reception of a PDSCH scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI.
--------------- end of TP#4 -------------------------------------------------------
Reason of change: This part is duplicated with the paragraph above it.


FL Proposal 6-7 (Tejas, Huawei/HiSilicon)
The reference point to determine the starting slot of on-demand SIB1 window is the start of the slot containing the starting symbol of the RAR window.



Issue 7: 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 #121 are collected below:

MTK:
Proposal 4: When OD-SIB1 window starting time falls into the middle of SSB burst, it is up to UE implementation to handle this scenario.

Figure from [R1-2401292, MTK]

Nokia
Observation-4: As specified in Clause 13 of TS38.213, legacy UE determines the slot to monitor Type0- PDCCH based on the SS/PBCH block index, since legacy UE obtains the Type0-PDCCH configurations from PBCH/MIB carried by SS/PBCH block. 

Observation-5: For legacy operation, the time reference for UE monitoring of Type0-PDCCH is the SSB block slot.

Proposal-8: RAN1 to discuss how UE determines the slot number and symbols for OD-SIB1 monitoring occasions, i.e. the time resources (slots, symbols) for Type 0 PDCCH monitoring occasions within the SIB1 transmission window. 

Proposal-9: RAN1 to clarify whether or not the index of starting slot n0 in TS38.213, for UE to monitor Type0-PDCCH of OD-SIB1 should incorporate with RAR reception slot index. 

Proposal-10: RAN1 to clarify if UE should consider that the index of starting slot n0 in TS38.213, for UE to monitor Type0-PDCCH of OD-SIB1 is based on SS/PBCH block received after RAR reception.

ZTE, Sanechips
Proposal 3: Whether the OD-SIB1 can be updated within the time window should follow legacy spec. There is no need to restrict the payloads of the OD-SIB1 transmitted in the time window should be the same.

Proposal 4: The transmission of the updated SIB1 and the updated WUS configuration on the NES cell should be within a time duration.

FL Proposal 7-1 (MTK)
When the OD-SIB1 window starting time falls into the middle of SSB burst and/or SIB1 transmission time corresponding to one SSB burst, it is up to UE implementation to monitor
from the first Type 0 PDCCH monitoring occasion inside the OD-SIB1 window, or 
from the first Type 0 PDCCH monitoring occasion inside the OD-SIB1 window corresponding to the next SSB burst.


FL Proposal 7-2 (Nokia)
RAN1 to clarify:
how UE determines the slot number and symbols for OD-SIB1 monitoring occasions, i.e. the time resources (slots, symbols) for Type 0 PDCCH monitoring occasions within the SIB1 transmission window
whether or not the index of starting slot n0 in TS38.213, for UE to monitor Type0-PDCCH of OD-SIB1 should incorporate with RAR reception slot index
if UE should consider that the index of starting slot n0 in TS38.213, for UE to monitor Type0-PDCCH of OD-SIB1 is based on SS/PBCH block received after RAR reception


FL Proposal 7-3 (ZTE)
Whether the OD-SIB1 can be updated within the time window should follow legacy spec, i.e. no restriction on the payloads of the transmitted OD-SIB1 being the same in the time window.


FL Proposal 7-4 (ZTE)
Proposal 4: The transmission of the updated SIB1 and the updated WUS configuration on the NES cell should be within a time duration.


Issue 8: Whether other features such as RedCap and NR-U can be combined with OD-SIB1 (vivo)
Background
The following proposals are brought up in RAN1 #121:

FUTUREWEI
Proposal 3: In the absence of supporting performance evaluations for NR-U, and considering LBT complexity, we recommend excluding OD-SIB1 for NR-U in Rel-19.

Observation 1: The R19 OD-SIB1 feature requires changes of the legacy RedCap initial access.

Proposal 4: If RAN1 supports R19 OD-SIB1 feature for RedCap UEs, provide in UL WUS configuration information on RedCap barring access to the NES cell.

vivo
Observation 3: Both network energy and UE power can be saved if there is an advance indication that whether redcap feature is not supported or not. 

Proposal 9: Add a parameter such as RedCapAllowed in WUS configuration to indicate whether NES cell supports RedCap UEs to request OD-SIB1.

Proposal 10: Add LBT type in WUS configuration to support NES cell in unlicensed band.

Ofinno
Proposal 4: Do not study whether the OD-SIB1 can be made applicable to RedCap features in Rel-19 NES WI.

FL Proposal 8-1 (vivo, FUTURWEI)
Add a parameter such as RedCapAllowed in WUS configuration to indicate whether NES cell supports RedCap UEs to request OD-SIB1.


FL Proposal 8-2 (vivo)
Add LBT type in WUS configuration to support NES cell in unlicensed band.


FL Proposal 8-3 (FUTUREWEI)
Exclude support of OD-SIB1 for NR-U in Rel-19.


Issue 9: RO selection based on rsrp-ThresholdSSB
Background
The following proposals are brought up in RAN1 #121:

DCM:
Proposal 2:  
It is up to RAN2 to decide the SSB and PRACH resource selection criterion for UE sending a WUS.

FL Proposal 9-1 (DOCOMO)
It is up to RAN2 to decide the SSB and PRACH resource selection criterion for UE sending a WUS.


Issue 10: Whether/how to indicate the OD-SIB1 transmission status to UE
Background
In RAN2 #127b, the following is agreed
Agreement
A cell for which SIB1 request configuration is available, can periodically broadcast SIB1.

Agreement
If UE has SIB1 request configuration of a cell, UE needs to check if SIB1 is currently being broadcasted or provided on demand for that cell before requesting SIB1 of that cell.

In RAN1 #120, it was agreed that:
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.

In RAN1 #120b, it was agreed that:
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>=123 for FR2, select the following:
Alt. 3: It is up to UE implementation on whether to monitor Type 0 PDCCH for SIB1 transmission


Companies’ views for this topic in RAN1 #121 are collected below:

Sony:
Proposal 1: The information indicating the transmission status of SIB1 (e.g., whether the SIB1 of the NES cell is currently being broadcasted or provided on demand) should be included in UL WUS configuration.

CEWiT:
Proposal 3: Support indicating the transmission status of on-demand SIB1 using repurposed parameters in MIB or PBCH of NES cell for idle UEs.

Proposal 4: 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)

vivo
Proposal 8: UE monitors type 0 PDCCH for SIB1 acquisition using the kssb and pdcch-ConfigSIB1 in the latest stored WUS configuration after receiving Short Message indicating SI change notification.

Samsung
Proposal 1: Make a conclusion in RAN1 that it’s up to gNB implementation to set the kSSB value to be <24 in
FR1 or <12 in FR2, such that legacy UE can camp on the cell when on-demand SIB1 is broadcasted.

CATT
Observation 1: If NES cell transmits SSB and the SSB is with 23< kSSB < kSSB

Proposal 1: 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 2: If NES cell transmits SSB and the kSSB = 30 for FR1 or kSSB = 14 for FR2, on demand SIB1 is currently being broadcasted.

Observation 2: There is a conflict between the agreements of RAN1 and RAN2. The agreement of RAN1 allows the UE implementation to determine whether to monitor Type 0 PDCCH for SIB1 transmission or not by implementation. In contrast, the agreement of RAN2 requires the UE to monitor Type 0 PDCCH before requesting SIB1.

Proposal 3: Update RAN1#120-b agreement to support RAN2 agreement.

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, 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

FL Proposal 10-1 (Sony, CEWIT, CATT)
Support indicating the transmission status of on-demand SIB1 using repurposed parameters in MIB or PBCH or UL WUS configuration of NES cell.


FL Proposal 10-2 (vivo)
UE monitors type 0 PDCCH for SIB1 acquisition using the kssb and pdcch-ConfigSIB1 in the latest stored WUS configuration after receiving Short Message indicating SI change notification.


Issue 11: Relation between OD-SIB1 procedure and existing on-demand SI procedure
Background
The following proposals are brought up in RAN1 #121:

LG:
Proposal #5: Discuss how to guarantee on-demand SIB1 transmission while the UE receives SIBx (other than SIB1) or performs the existing on-demand SI procedure.

FL Proposal 11-1 (LG)
Discuss how to guarantee on-demand SIB1 transmission while the UE receives SIBx (other than SIB1) or performs the existing on-demand SI procedure.


Issue 12: MAC subPDU location identification for RAR of OD-SIB1 request
Background
The following proposals are brought up in RAN1 #121:

Sharp:
Proposal 1: To solve the issue on MAC subPDU location identification for RAR of OD-SIB1 request, 
RAN1 should consider following options:
Option 1: RACH occasion for OD-SIB1 request is a dedicated resource and is not used for other purpose
Option 2: New RNTI is introduced for RAR of OD-SIB1 request
Option 3: OD-SIB1 request configuration includes configuration of OD-OSI request (RAPID 
information)

FL Proposal 12-1 (Sharp)
RAN1 should consider following options to solve the issue on MAC subPDU location identification for RAR of OD-SIB1 request
Option 1: RACH occasion for OD-SIB1 request is a dedicated resource and is not used for other purpose
Option 2: New RNTI is introduced for RAR of OD-SIB1 request
Option 3: OD-SIB1 request configuration includes configuration of OD-OSI request (RAPID 
information)


Issue 13: PRACH transmission for SIB1 request
Background
The following proposals are brought up in RAN1 #121:

Google:
Proposal 1: Endorse the following TP for 38.211 to clarify the PRACH transmission for SIB1 request
--------------------------------- start of TP for 38.211-------------------------------------
5.3.2	OFDM baseband signal generation for PRACH

-	 is the subcarrier spacing of the initial uplink bandwidth part during initial access. If the PRACH transmission is for a candidate cell  is provided by ltm-PRACH-SubcarrierSpacing in EarlyUL-SyncConfig. If the PRACH transmission is for SIB1 request,  is provided by SIB1-RequestConfig. Otherwise,  is the subcarrier spacing of the active uplink bandwidth part; 
-	 is the largest  value among the subcarrier spacing configurations by the higher-layer parameter scs-SpecificCarrierList;
-	 is the lowest numbered resource block of the initial uplink bandwidth part and is derived by the higher-layer parameter initialUplinkBWP or initialUplinkBWP-RedCap during initial access and from the higher-layer parameters bwp-GenericParameters in EarlyUL-SyncConfig if the PRACH transmission is for a candidate cell and from the higher-layer parameters SIB1-RequestConfig if the PRACH transmission is for SIB1 request. Otherwise,  is the lowest numbered resource block of the active uplink bandwidth part and is derived by the higher-layer parameter BWP-Uplink; 

6.3.3.1	Sequence generation

There are 64 preambles defined in each time-frequency PRACH occasion, enumerated in increasing order of first increasing cyclic shift  of a logical root sequence, and then in increasing order of the logical root sequence index, starting with the index obtained from the higher-layer parameter prach-RootSequenceIndex or rootSequenceIndex-BFR or by msgA-PRACH-RootSequenceIndex if configured and a type-2 random-access procedure is initiated as described in clause 8.1 of [5, TS 38.213] or by prach-RootSequenceIndex in EarlyUL-SyncConfig if the PRACH transmission is for a candidate cell or by prach-RootSequenceIndex in SIB1-RequestConfig if the PRACH transmission is for SIB1 request. Additional preamble sequences, in case 64 preambles cannot be generated from a single root Zadoff-Chu sequence, are obtained from the root sequences with the consecutive logical indexes until all the 64 sequences are found. The logical root sequence order is cyclic; the logical index 0 is consecutive to . The sequence number  is obtained from the logical root sequence index according to Tables 6.3.3.1-3 to 6.3.3.1-4B.
--------------------------------- start of TP for 38.211-------------------------------------

FL Proposal 13-1 (Google)
Adopt the following TP for 38.211 to clarify the PRACH transmission for SIB1 request.
--------------------------------- start of TP for 38.211-------------------------------------
5.3.2	OFDM baseband signal generation for PRACH

-	 is the subcarrier spacing of the initial uplink bandwidth part during initial access. If the PRACH transmission is for a candidate cell  is provided by ltm-PRACH-SubcarrierSpacing in EarlyUL-SyncConfig. If the PRACH transmission is for SIB1 request,  is provided by SIB1-RequestConfig. Otherwise,  is the subcarrier spacing of the active uplink bandwidth part; 
-	 is the largest  value among the subcarrier spacing configurations by the higher-layer parameter scs-SpecificCarrierList;
-	 is the lowest numbered resource block of the initial uplink bandwidth part and is derived by the higher-layer parameter initialUplinkBWP or initialUplinkBWP-RedCap during initial access and from the higher-layer parameters bwp-GenericParameters in EarlyUL-SyncConfig if the PRACH transmission is for a candidate cell and from the higher-layer parameters SIB1-RequestConfig if the PRACH transmission is for SIB1 request. Otherwise,  is the lowest numbered resource block of the active uplink bandwidth part and is derived by the higher-layer parameter BWP-Uplink; 

6.3.3.1	Sequence generation

There are 64 preambles defined in each time-frequency PRACH occasion, enumerated in increasing order of first increasing cyclic shift  of a logical root sequence, and then in increasing order of the logical root sequence index, starting with the index obtained from the higher-layer parameter prach-RootSequenceIndex or rootSequenceIndex-BFR or by msgA-PRACH-RootSequenceIndex if configured and a type-2 random-access procedure is initiated as described in clause 8.1 of [5, TS 38.213] or by prach-RootSequenceIndex in EarlyUL-SyncConfig if the PRACH transmission is for a candidate cell or by prach-RootSequenceIndex in SIB1-RequestConfig if the PRACH transmission is for SIB1 request. Additional preamble sequences, in case 64 preambles cannot be generated from a single root Zadoff-Chu sequence, are obtained from the root sequences with the consecutive logical indexes until all the 64 sequences are found. The logical root sequence order is cyclic; the logical index 0 is consecutive to . The sequence number  is obtained from the logical root sequence index according to Tables 6.3.3.1-3 to 6.3.3.1-4B.
--------------------------------- end of TP for 38.211-------------------------------------


Issue 14: Other topics
Discussion place holder for issues not included above.
FL Proposal 14-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 #121)
R1-2503234	Discussion of on-demand SIB1 for idle/inactive mode UEs	FUTUREWEI
R1-2503268	Discussion on on-demand SIB1 for eNES	Huawei, HiSilicon
R1-2503316	Discussion on on-demand SIB1 for NES	ZTE Corporation, Sanechips
R1-2503366	Remaining issues on-demand SIB1 for idle/inactive mode UEs   vivo
R1-2503413	On-demand SIB1 for Idle/Inactive mode UEs	Nokia, Nokia Shanghai Bell
R1-2503417	Discussion on on-demand SIB1 for UEs in idle/inactive mode	NEC
R1-2503520	Discussion on on-demand SIB1 for idle/inactive mode UEs	Spreadtrum, UNISOC
R1-2503571	On-demand SIB1 for idle/inactive mode UEs	Samsung
R1-2503717	OD-SIB1 for idle/inactive UEs	Tejas Network Limited
R1-2503738	Discussion on on-demand SIB1 for idle/inactive mode UEs	Ofinno
R1-2503798	Discussion on on-demand SIB1	CATT
R1-2503836	Discussion on on-demand SIB1 for UEs in idle/inactive mode	CMCC
R1-2503887	Discussion on on-demand SIB1 for idle/inactive mode UEs	Xiaomi
R1-2503973	Discussion on on-demand SIB1 for idle/inactive mode UEs	InterDigital, Inc.
R1-2503999	Discussion on on-demand SIB1 transmission for network energy savings	Fujitsu
R1-2504016	On-demand SIB1 for UEs in idle/inactive mode for NES	Ericsson
R1-2504031	On-demand SIB1 for Idle/Inactive Mode UE	 Google
R1-2504051	Discussion on on-demand SIB1 for idle/inactive mode UEs	China Telecom
R1-2504065	On-demand SIB1 for idle/inactive mode UEs	Sony
R1-2504108	On-demand SIB1 for idle/inactive mode UEs	Lenovo
R1-2504142	On-demand SIB1 for idle/inactive mode UEs	ETRI
R1-2504177	Discussion on on-demand SIB1 transmission for idle/inactive mode UEs Transsion Holdings
R1-2504193	Discussion on the enhancement to support on demand SIB1 for idle/inactive mode UE OPPO
R1-2504236	Discussion on on-demand SIB1 for idle/inactive mode UEs	Panasonic
R1-2504248	On-demand SIB1 for idle/inactive mode UEs	LG Electronics
R1-2504263	On-demand SIB1 for idle or inactive mode UEs	MediaTek Inc.
R1-2504326	On On-demand SIB1 for IDLE/INACTIVE mode UEs	Apple
R1-2504399	On-demand SIB1 procedure	Qualcomm Incorporated
R1-2504457	Discussion on on-demand SIB1 for idle/inactive mode UEs	DENSO CORPORATION
R1-2504467	Discussion on on-demand SIB1 transmission for idle UEs	Sharp
R1-2504506	Discussion on on-demand SIB1 for idle/inactive mode UEs	NTT DOCOMO, INC.
R1-2504556	Discussion on on-demand SIB1 in idle/inactive mode	CAICT
R1-2504603	Discussion on  on-demand SIB1	CEWiT
R1-2501811	Discussions on on-demand SIB1 for idle/inactive mode UEs	vivo (RAN1 #120b)

pat3GPP TSG RAN WG1 #121							   R1-2504681
St Julian’s, Malta, May 19th – 23th, 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
There is no consensus on the support of OD-SIB1 for NR-U in Rel-19.

Agreement
RAN1 to adopt TP below.
--------------- TP of TS 38.213 in Clause 23 -----------------------
If the UE identifies a RAPID associated with a corresponding PRACH transmission from the UE in a PDSCH reception scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI, the UE can be indicated by higher layers to monitor PDCCH on the second cell to detect a DCI format 1_0 with CRC scrambled by the SI-RNTI according to a Type0-PDCCH CSS set provided by SearchSpaceZero. If the UE is provided XYZ, the UE monitors PDCCH only in monitoring occasions associated with the SS/PBCH block. The UE starts monitoring monitors PDCCH to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI after a number of slots provided by od-sib1-windowStartOffset from the starting slot of the window controlled by ra_ResponseWindow, and for a number of slots provided by od-sib1-WindowDuration.
--------------- end of TP -------------------------------------------------------
Reason of change: Considering the RAR processing time and OD-SIB1 window starting time may fall into the middle of SSB burst and/or SIB1 transmission time corresponding to one SSB burst, when to start the PDCCH monitoring in the OD-SIB1 window is up to UE implementation.
Agreement
The parameters ‘absoluteFrequencyPointA’, ‘offsetToCarrier’ and ‘locationAndBandwidth’ are mandatorily present in the UL-WUS configuration for both FDD and TDD system.

Agreement
The frequencyBandList is mandatorily present in WUS configuration for TDD system, which refers to the IE within FrequencyInfoDL-SIB.

Agreement
The reference point to determine the starting slot of on-demand SIB1 window is the start of the slot containing the starting symbol of the RAR window.

Agreement
RAN1 adopts TP below for clause 23 of TS 38.213.

4 References (all from RAN1 #121)
R1-2503234	Discussion of on-demand SIB1 for idle/inactive mode UEs	FUTUREWEI
R1-2503268	Discussion on on-demand SIB1 for eNES	Huawei, HiSilicon
R1-2503316	Discussion on on-demand SIB1 for NES	ZTE Corporation, Sanechips
R1-2503366	Remaining issues on-demand SIB1 for idle/inactive mode UEs   vivo
R1-2503413	On-demand SIB1 for Idle/Inactive mode UEs	Nokia, Nokia Shanghai Bell
R1-2503417	Discussion on on-demand SIB1 for UEs in idle/inactive mode	NEC
R1-2503520	Discussion on on-demand SIB1 for idle/inactive mode UEs	Spreadtrum, UNISOC
R1-2503571	On-demand SIB1 for idle/inactive mode UEs	Samsung
R1-2503717	OD-SIB1 for idle/inactive UEs	Tejas Network Limited
R1-2503738	Discussion on on-demand SIB1 for idle/inactive mode UEs	Ofinno
R1-2503798	Discussion on on-demand SIB1	CATT
R1-2503836	Discussion on on-demand SIB1 for UEs in idle/inactive mode	CMCC
R1-2503887	Discussion on on-demand SIB1 for idle/inactive mode UEs	Xiaomi
R1-2503973	Discussion on on-demand SIB1 for idle/inactive mode UEs	InterDigital, Inc.
R1-2503999	Discussion on on-demand SIB1 transmission for network energy savings	Fujitsu
R1-2504016	On-demand SIB1 for UEs in idle/inactive mode for NES	Ericsson
R1-2504031	On-demand SIB1 for Idle/Inactive Mode UE	 Google
R1-2504051	Discussion on on-demand SIB1 for idle/inactive mode UEs	China Telecom
R1-2504065	On-demand SIB1 for idle/inactive mode UEs	Sony
R1-2504108	On-demand SIB1 for idle/inactive mode UEs	Lenovo
R1-2504142	On-demand SIB1 for idle/inactive mode UEs	ETRI
R1-2504177	Discussion on on-demand SIB1 transmission for idle/inactive mode UEs Transsion Holdings
R1-2504193	Discussion on the enhancement to support on demand SIB1 for idle/inactive mode UE OPPO
R1-2504236	Discussion on on-demand SIB1 for idle/inactive mode UEs	Panasonic
R1-2504248	On-demand SIB1 for idle/inactive mode UEs	LG Electronics
R1-2504263	On-demand SIB1 for idle or inactive mode UEs	MediaTek Inc.
R1-2504326	On On-demand SIB1 for IDLE/INACTIVE mode UEs	Apple
R1-2504399	On-demand SIB1 procedure	Qualcomm Incorporated
R1-2504457	Discussion on on-demand SIB1 for idle/inactive mode UEs	DENSO CORPORATION
R1-2504467	Discussion on on-demand SIB1 transmission for idle UEs	Sharp
R1-2504506	Discussion on on-demand SIB1 for idle/inactive mode UEs	NTT DOCOMO, INC.
R1-2504556	Discussion on on-demand SIB1 in idle/inactive mode	CAICT
R1-2504603	Discussion on  on-demand SIB1	CEWiT
R1-2501811	Discussions on on-demand SIB1 for idle/inactive mode UEs	vivo (RAN1 #120b)

pat3GPP TSG RAN WG1 #121							   R1-2504682
St Julian’s, Malta, May 19th – 23th, 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
There is no consensus on the support of OD-SIB1 for NR-U in Rel-19.

Agreement
RAN1 to adopt TP below.
--------------- TP of TS 38.213 in Clause 23 -----------------------
If the UE identifies a RAPID associated with a corresponding PRACH transmission from the UE in a PDSCH reception scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI, the UE can be indicated by higher layers to monitor PDCCH on the second cell to detect a DCI format 1_0 with CRC scrambled by the SI-RNTI according to a Type0-PDCCH CSS set provided by SearchSpaceZero. If the UE is provided XYZ, the UE monitors PDCCH only in monitoring occasions associated with the SS/PBCH block. The UE starts monitoring monitors PDCCH to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI after a number of slots provided by od-sib1-windowStartOffset from the starting slot of the window controlled by ra_ResponseWindow, and for a number of slots provided by od-sib1-WindowDuration.
--------------- end of TP -------------------------------------------------------
Reason of change: Considering the RAR processing time and OD-SIB1 window starting time may fall into the middle of SSB burst and/or SIB1 transmission time corresponding to one SSB burst, when to start the PDCCH monitoring in the OD-SIB1 window is up to UE implementation.
Agreement
The parameters ‘absoluteFrequencyPointA’, ‘offsetToCarrier’ and ‘locationAndBandwidth’ are mandatorily present in the UL-WUS configuration for both FDD and TDD system.

Agreement
The frequencyBandList is mandatorily present in WUS configuration for TDD system, which refers to the IE within FrequencyInfoDL-SIB.

Agreement
The reference point to determine the starting slot of on-demand SIB1 window is the start of the slot containing the starting symbol of the RAR window.

Agreement
RAN1 adopts TP below for clause 23 of TS 38.213.

4 References (all from RAN1 #121)
R1-2503234	Discussion of on-demand SIB1 for idle/inactive mode UEs	FUTUREWEI
R1-2503268	Discussion on on-demand SIB1 for eNES	Huawei, HiSilicon
R1-2503316	Discussion on on-demand SIB1 for NES	ZTE Corporation, Sanechips
R1-2503366	Remaining issues on-demand SIB1 for idle/inactive mode UEs   vivo
R1-2503413	On-demand SIB1 for Idle/Inactive mode UEs	Nokia, Nokia Shanghai Bell
R1-2503417	Discussion on on-demand SIB1 for UEs in idle/inactive mode	NEC
R1-2503520	Discussion on on-demand SIB1 for idle/inactive mode UEs	Spreadtrum, UNISOC
R1-2503571	On-demand SIB1 for idle/inactive mode UEs	Samsung
R1-2503717	OD-SIB1 for idle/inactive UEs	Tejas Network Limited
R1-2503738	Discussion on on-demand SIB1 for idle/inactive mode UEs	Ofinno
R1-2503798	Discussion on on-demand SIB1	CATT
R1-2503836	Discussion on on-demand SIB1 for UEs in idle/inactive mode	CMCC
R1-2503887	Discussion on on-demand SIB1 for idle/inactive mode UEs	Xiaomi
R1-2503973	Discussion on on-demand SIB1 for idle/inactive mode UEs	InterDigital, Inc.
R1-2503999	Discussion on on-demand SIB1 transmission for network energy savings	Fujitsu
R1-2504016	On-demand SIB1 for UEs in idle/inactive mode for NES	Ericsson
R1-2504031	On-demand SIB1 for Idle/Inactive Mode UE	 Google
R1-2504051	Discussion on on-demand SIB1 for idle/inactive mode UEs	China Telecom
R1-2504065	On-demand SIB1 for idle/inactive mode UEs	Sony
R1-2504108	On-demand SIB1 for idle/inactive mode UEs	Lenovo
R1-2504142	On-demand SIB1 for idle/inactive mode UEs	ETRI
R1-2504177	Discussion on on-demand SIB1 transmission for idle/inactive mode UEs Transsion Holdings
R1-2504193	Discussion on the enhancement to support on demand SIB1 for idle/inactive mode UE OPPO
R1-2504236	Discussion on on-demand SIB1 for idle/inactive mode UEs	Panasonic
R1-2504248	On-demand SIB1 for idle/inactive mode UEs	LG Electronics
R1-2504263	On-demand SIB1 for idle or inactive mode UEs	MediaTek Inc.
R1-2504326	On On-demand SIB1 for IDLE/INACTIVE mode UEs	Apple
R1-2504399	On-demand SIB1 procedure	Qualcomm Incorporated
R1-2504457	Discussion on on-demand SIB1 for idle/inactive mode UEs	DENSO CORPORATION
R1-2504467	Discussion on on-demand SIB1 transmission for idle UEs	Sharp
R1-2504506	Discussion on on-demand SIB1 for idle/inactive mode UEs	NTT DOCOMO, INC.
R1-2504556	Discussion on on-demand SIB1 in idle/inactive mode	CAICT
R1-2504603	Discussion on  on-demand SIB1	CEWiT
R1-2501811	Discussions on on-demand SIB1 for idle/inactive mode UEs	vivo (RAN1 #120b)

pat3GPP TSG RAN WG1 #121							   R1-2504683
St Julian’s, Malta, May 19th – 23th, 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 consensus on the support of OD-SIB1 for NR-U in Rel-19.

Agreement
RAN1 to adopt TP below.
--------------- TP of TS 38.213 in Clause 23 -----------------------
If the UE identifies a RAPID associated with a corresponding PRACH transmission from the UE in a PDSCH reception scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI, the UE can be indicated by higher layers to monitor PDCCH on the second cell to detect a DCI format 1_0 with CRC scrambled by the SI-RNTI according to a Type0-PDCCH CSS set provided by SearchSpaceZero. If the UE is provided XYZ, the UE monitors PDCCH only in monitoring occasions associated with the SS/PBCH block. The UE starts monitoring monitors PDCCH to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI after a number of slots provided by od-sib1-windowStartOffset from the starting slot of the window controlled by ra_ResponseWindow, and for a number of slots provided by od-sib1-WindowDuration.
--------------- end of TP -------------------------------------------------------
Reason of change: Considering the RAR processing time and OD-SIB1 window starting time may fall into the middle of SSB burst and/or SIB1 transmission time corresponding to one SSB burst, when to start the PDCCH monitoring in the OD-SIB1 window is up to UE implementation.
Agreement
The parameters ‘absoluteFrequencyPointA’, ‘offsetToCarrier’ and ‘locationAndBandwidth’ are mandatorily present in the UL-WUS configuration for both FDD and TDD system.

Agreement
The frequencyBandList is mandatorily present in WUS configuration for TDD system, which refers to the IE within FrequencyInfoDL-SIB.

Agreement
The reference point to determine the starting slot of on-demand SIB1 window is the start of the slot containing the starting symbol of the RAR window.

Agreement
RAN1 adopts TP below for clause 23 of TS 38.213.

4 References (all from RAN1 #121)
R1-2503234	Discussion of on-demand SIB1 for idle/inactive mode UEs	FUTUREWEI
R1-2503268	Discussion on on-demand SIB1 for eNES	Huawei, HiSilicon
R1-2503316	Discussion on on-demand SIB1 for NES	ZTE Corporation, Sanechips
R1-2503366	Remaining issues on-demand SIB1 for idle/inactive mode UEs   vivo
R1-2503413	On-demand SIB1 for Idle/Inactive mode UEs	Nokia, Nokia Shanghai Bell
R1-2503417	Discussion on on-demand SIB1 for UEs in idle/inactive mode	NEC
R1-2503520	Discussion on on-demand SIB1 for idle/inactive mode UEs	Spreadtrum, UNISOC
R1-2503571	On-demand SIB1 for idle/inactive mode UEs	Samsung
R1-2503717	OD-SIB1 for idle/inactive UEs	Tejas Network Limited
R1-2503738	Discussion on on-demand SIB1 for idle/inactive mode UEs	Ofinno
R1-2503798	Discussion on on-demand SIB1	CATT
R1-2503836	Discussion on on-demand SIB1 for UEs in idle/inactive mode	CMCC
R1-2503887	Discussion on on-demand SIB1 for idle/inactive mode UEs	Xiaomi
R1-2503973	Discussion on on-demand SIB1 for idle/inactive mode UEs	InterDigital, Inc.
R1-2503999	Discussion on on-demand SIB1 transmission for network energy savings	Fujitsu
R1-2504016	On-demand SIB1 for UEs in idle/inactive mode for NES	Ericsson
R1-2504031	On-demand SIB1 for Idle/Inactive Mode UE	 Google
R1-2504051	Discussion on on-demand SIB1 for idle/inactive mode UEs	China Telecom
R1-2504065	On-demand SIB1 for idle/inactive mode UEs	Sony
R1-2504108	On-demand SIB1 for idle/inactive mode UEs	Lenovo
R1-2504142	On-demand SIB1 for idle/inactive mode UEs	ETRI
R1-2504177	Discussion on on-demand SIB1 transmission for idle/inactive mode UEs Transsion Holdings
R1-2504193	Discussion on the enhancement to support on demand SIB1 for idle/inactive mode UE OPPO
R1-2504236	Discussion on on-demand SIB1 for idle/inactive mode UEs	Panasonic
R1-2504248	On-demand SIB1 for idle/inactive mode UEs	LG Electronics
R1-2504263	On-demand SIB1 for idle or inactive mode UEs	MediaTek Inc.
R1-2504326	On On-demand SIB1 for IDLE/INACTIVE mode UEs	Apple
R1-2504399	On-demand SIB1 procedure	Qualcomm Incorporated
R1-2504457	Discussion on on-demand SIB1 for idle/inactive mode UEs	DENSO CORPORATION
R1-2504467	Discussion on on-demand SIB1 transmission for idle UEs	Sharp
R1-2504506	Discussion on on-demand SIB1 for idle/inactive mode UEs	NTT DOCOMO, INC.
R1-2504556	Discussion on on-demand SIB1 in idle/inactive mode	CAICT
R1-2504603	Discussion on  on-demand SIB1	CEWiT
R1-2501811	Discussions on on-demand SIB1 for idle/inactive mode UEs	vivo (RAN1 #120b)