TDoc file reading error

3GPP TSG-RAN WG2 Meeting #130					        R2-2503391
St.Julians, Malta, May 19th – 23rd , 2025
Agenda item:	8.5.3
Source:	Samsung
Title:	On-demand SIB1
Document for:	Discussion and decision

Conclusion
Proposal 1a: SIB 1 request is supported for both SUL and NUL.
Proposal 1b: RSRP threshold for UL carrier selection is included in SIB1 request configuration.
Proposal 2: Discuss and agree the following for SIB1 request to cell selected for connection re-establishment
SIB X can be delivered to UE using RRC reconfiguration message in RRC_CONNECTED (for the case SIB X cannot be broadcasted in active DL BWP)
UE may send SIB1 request to selected cell (say cell B), if the SIB X last acquired from PCell (say Cell A) includes SIB1 request configuration of Cell B and this SIB X is valid in current modification period.

Proposal 3a: Cell access information in SIBX is supported. 

Proposal 3b: Following information is optionally included in SIB X for a cell whose SIB1 request configuration is included in SIB X. 
List of PLMN identities associated with the cell
List of tracking area codes associated with the cell
cellReservedForOtherUse
cellReservedForFutureUse
cellBarredATG (not needed, if OD-SIB1 is not supported for ATG)           
cellBarredNES                
cellBarred-eRedCap1Rx        
cellBarred-eRedCap2Rx        
cellBarredRedCap1Rx         
cellBarredRedCap2Rx          
cellBarredNTN (not needed, if OD-SIB1 is not supported for NTN)

Proposal 3c: 
List of PLMN identities can be commonly configured. The list of PLMNs per cell can refer to this common list.
List of tracking area codes can be commonly configured. The list of tracking area codes per cell can refer to this common list.
Proposal 3d: Cell access related information can be separately signalled in SIBx instead of signalling them per SIB1 request configuration.
Proposal 4: SIB1 request configuration of a cell (say cell B) from SIB X of PCell can be used for SIB1 request to a cell B selected upon connection release.
Proposal 5: The OD-SIB1 supporting UEs ignores the intraFreqExcludedCellList /interFreqExcludedCellList received from a cell in which SIB X is provided.


References

3GPP TSG-RAN WG2 Meeting #130                 	                                                                                 R2-2503415
St.Julians, Malta, May 19th – 23rd, 2025

		
Source:	CATT 
Title:	Consideration on on-demand SIB1 issues
Agenda Item:	8.5.3
Document for:	Discussion and Decision

Conclusion
According to the analysis in section 2, our observations and proposals are summarized as follows:
Observation 1: A barring indication in SIB1 is used for R18 NES UE with Cell DTX/DRX feature. 
Observation 2: In legacy, UE needs to acquire the SIB1 immediately when receiving the etwsAndCmasIndication in Short Message, which is beneficial for latency.
Observation 3: The paging message for legacy UE is not necessary to be transmitted at OD-SIB1 enabled Cell.   

Proposal 1: (38.304-01) The UE supporting OD-SIB1 always ignores the legacy excluded cell lists received from a cell in which SIBxx is provided.
Proposal 2: (38.304-01) OD-SIB1 enabled Cell is included in the legacy excluded list of a cell in which SIBxx is provided if available.
Proposal 3: Discuss whether there is a scenario where the UE supporting OD-SIB1 is not allowed to access OD-SIB1 enabled Cell.
Proposal 4: Cell access information is not included in UL-WUS configuration.
Proposal 5a: In emergency cases, it is up to network implementation to switch to normal mode or broadcast the SIB1 periodically.
Proposal 5b: UE acquires the SIB1 immediately on OD-SIB1 enabled cell without sending WUS request when receiving the etwsAndCmasIndication in Short Message.
Proposal 6：When the cell supporting on demand SIB1 is broadcasting SIB1 periodically, it is up to NW implementation to set the K_SSB as in legacy or as in an OD-SIB1 enabled cell.
Proposal 7：Discuss how UE supporting OD-SIB1can determine if SIB1 is currently being broadcasted or provided on demand for that cell before requesting SIB1 of that cell.
Proposal 8: A new UE capability for support of OD-SIB1 is introduced in UE-RadioPagingInfo.

3GPP TSG-RAN WG2 Meeting #130	 R2-2503467
St Julian’s, Malta, May 19-23, 2025

Agenda item:		8.5.3	On-demand SIB1
Title:	Remaining issues for On-demand SIB1 request and UE behaviour
Source:		NEC
Document for:		Discussion and Decision	
1. 

Conclusion
In this contribution, we have made the following proposals.

Proposal 1: The monitoring duration for NES cell’s SIB1 before sending the OD-SIB1 request can be up to the UE implementation. 
Proposal 2: RAN2 may consider adding feature-specific cell barring information (e.g., cellBarred-eRedCap, cellBarredNES) to the UL WUS configuration for NES cells with on-demand SIB1. The information can be optional and limited to a few bits to minimize signaling impact.

3GPP TSG-RAN WG2 Meeting #130	                                 	                   R2-2503485
St. Julians, Malta, May 19th – 21st, 2025	                         

Agenda Item:	8.5.3
Source: 	Lenovo
Title: 	Providing Cell Reselection Assistance information
WID/SID:	Netw_Energy_NR_enh
Document for:	Discussion and decision

Conclusion
This doc
Observation 1: Reselection procedure follows mainly two steps: In the first phase (let’s call it “evaluation” phase) the UE shall use parameters provided by the serving cell. In the second phase (let’s call it “final check”), parameters (SIB1, SIB2) from target cell will be needed to check the cell selection criterion. 
Observation 2: Previous RAN2 agreements rightly assume that SIB1 Request is made after the first phase.
Observation 3: MIB cellBarred is the most important barring information for deciding on OD-SIB1 Request and as an example, there’s no use of requesting SIB1 from a target cell that can’t even support emergency call. 
Observation 4: Acquiring MIB/ PBCH during “evaluation” phase is not necessary/ mandatory and some UEs may not do it as it does not come for free.
Observation 5: It is more efficient to perform MIB and SIB1 acquisition (even in rel. 15) for only best cell or highest ranked cell on a frequency, and therefore as part of the “final check” (and not in evaluation phase).
Observation 6: Including information from MIB/ PBCH in the UL WUS configuration is acceptable: RAN1 has already agreed to include some content of MIB/ PBCH (KSSB and pdcch-ConfigSIB1) in the UL WUS configuration, although for different reasons. 
Observation 7: A WUS Configuration should only be provided for a MIB notBarred cell; or an NTN Cell.
Proposal 1: Including the cellBarred of the NES Cell's MIB in the UL WUS configuration is not necessary.
Observation 8: Providing exhaustive assistance information to minimize SIB1 request could be really huge (up to 8 times CellAccessRelatedInfo! + other bits) in each Cell A!
Proposal 2: Include feature specific barring bits from SIB1.
Proposal 3: Other information (PLMN IDs, SNPNs, CAG List and TA) of the NES Cell's SIB1 in the UL WUS configuration can be provided to restrict SIB1 Request if signalling load is managed using e.g., delta signalling with respect to the serving cell.

3GPP TSG-RAN WG2 Meeting #130	R2-2503502
St Julian’s, Malta, 19th May 2025 – 23rd May 2025
Source: 	Huawei, HiSilicon
Title: 	Discussion on remaining issues of on-demand SIB1 operation for NES
Agenda Item:	8.5.3
Document for:	Discussion and decision

Conclusion
In this contribution, we discussed the remaining issues of on on-demand SIB1 operation, and made the following observations and proposals:
Proposal 1: Once a NES UE acquires Cell A’s SIB1 and knows that it provides the new SIBX, it can acquire Cell A’s SIBX to obtain WUS configurations of neighbouring cells, even if the UE type is barred in SIB1. 
Proposal 2: Feature specific barring bits from SIB1 are included in the WUS config, if the OD-SIB1 Cell supports and has enabled a specific feature that has a barring functionality. 
Proposal 3: Parameters in SIBxx should be designed as optional whenever possible to minimize SIBxx overhead.
Proposal 4: If the value in an OD-SIB1 IE is different from the value of the corresponding IE in the WUS configuration, then the value in OD-SIB1 IE overrides the value of the corresponding IE in the WUS configuration. 

3GPP TSG-RAN WG2 #130	R2-2503636 
Malta, May 19th– 23rd, 2025	

Agenda Item:	8.5.3
Source:	Ericsson
Title:	Discussion on on-demand SIB1 for NES
Document for:	Discussion, Decision

1	

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

3GPP TSG RAN WG2 Meeting #130      	                           R2-2503711
St Julian’s, Malta, May 19th – 23rd, 2025                                          

Agenda item:	8.5.3
Source:	Apple
Title:	Remaining issues on on-demand SIB1
WID/SID:	Netw_Energy_NR_enh-Core– Release 19
Document for:	Discussion and Decision
1 

Conclusion
In this contribution, we discuss remaining issues of on-demand SIB1. Our observations are: 
Observation 1: On including feature specific barring, the motivation is to avoid UE unnecessary OD-SIB1 request for checking access restriction information of target OD-SIB1 cell. 
Observation 2: Feature specific barring bits common to all PLMN/NPN (i.e. the UE doesn’t need to check its PLMN/NPN info) only have small signaling overhead (totally 14bit) while PLMN/NPN-specific cell access information have large signaling overhead (149bit for PLMN related access information and 236bit for NPN related access information). 
Observation 3: Absolute frequency of point A is included in UL WUS configuration. It is impossible that two inter-frequency cells can have same absolute point A, i.e. two inter-frequency cells can’t have same WUS config.

Based on observations, our proposals are:
Remaining issue on feature specfic barring
Proposal 1: The following feature specific barring bits common to all PLMN/NPN (totally 14 bit) are optionally included in UL WUS configuraiton:  
cellReservedForOtherUse, cellReservedForFutureUse, cellBarredATG, cellBarred2RxXR, cellBarred-eRedCap1Rx, cellBarred-eRedCap2Rx, cellBarredNES, cellBarredNTN, cellBarredFixedVSAT, cellBarredMobileVSAT, cellBarred-RedCap1Rx, cellBarred-RedCap2Rx, halfDuplexRedCapAllowed, ncr-Support
Key RRC open issues
Proposal 2: Add the following NOTE in Section 5.2.2.3.1 to capture RAN1 agreement:
  “NOTE: It is up to UE implementation on how to check SIB1 is being broadcasted.”
Proposal 3: Only a list of PCIs can be associated with one UL WUS configuration.
Proposal 4: Capture the RAN2#129b agreement (“The UE supporting OD-SIB1 in RRC_CONNECTED regards the stored SIB1 is the latest SIB1.”) in field description of si-BroadcastStatus.
Proposal 5: RAN2 don’t pursue the optimization of co-existence of SBFD and OD-SIB1.
Proposal 6: RAN2 don’t pursue the optimization to allow the UE to trigger OD-SIB1 procedure when there is SDT ongoing (i.e. no need to change the procedure of current running RRC CR).  
Key 38.304 open issues
Proposal 7: RAN2 don’t pursue the enhancement that OD-SIB1 UE always ignores the legacy excluded cell lists received from a cell in which SIBxx is provided.  

4 

3GPP TSG-RAN WG2 Meeting #130																					R2-2503756
St Julian, Malta, 19th – 23rd May 2025
Agenda item:		8.5.3
Title: 	Remaining issues of on-demand SIB1
Source: 			ZTE Corporation, Sanechips
Document for: 	Discussion and Decision

Conclusion and proposals
Based on the analysis in previous sections, the following observations and proposals are given: 
Proposal 1: Include the following parameters from the RAN1 parameter list in SIBxx:
frequencyBandList
Prach-ConfigurationIndex
msg1-FDM
msg1-FrequencyStart
zeroCorrelationZoneConfig
preambleReceivedTargetPower
powerRampingStep
ra-ResponseWindow
searchSpaceZero
controlResourceSetZero
ra-SearchSpace
n-TimingAdvanceOffset
ssb-PeriodicityServingCell
od-sib1-WindowDuration
od-sib1-windowStartOffset
Proposal 2: The list of cells sharing the same WUS configuration would be in the same frequency, i.e. the list of cells is only PCI.
Proposal 3: Use the following ASN.1 to describe the valid cell list of WUS configuration and the range value of PCI-Range can be n2, n4 and n8.
physCellId-r19		SEQUENCE (SIZE (1.. maxPCI-r19)) OF PCI-Range
Proposal 4: Add definition of maxCellODSIB1-r19 and maxPCI-r19 in 6.4 RRC multiplicity and type constraint values.
Proposal 5: The maximum number of on demand SIB1 request configuration, i.e. maxCellODSIB1-r19, should be evaluated and defined after the full set of parameters are included and ready to derive the required signaling overhead and ensure the overall signaling overhead will not go beyond the upper limit of SIB size, i.e. 2976 bits.
Proposal 6: The maxPCI-r19 is 8. 
Proposal 7: Confirm the understanding that having the maxSIB1-Message with value larger than 1 means more than one set of PRACH resources are configured for requesting SIB1 and add the definition of maxSIB1-Message in 6.4 RRC multiplicity and type constraint values.

3GPP TSG-RAN WG2 Meeting#130                               	R2-2503797
St. Julians, Malta, May 19th – 23rd, 2025	
	
Agenda item:	8.5.3
Source: 	Google
Title: 	Open issues in the running CRs for OD-SIB1
Document for:	Discussion and Decision	

Conclusion
In this paper, we discuss several open/FFS issues for supporting the on-demand SIB1 mechanism based on the current running CRs for TS 38.304 and TS 38.331 [2][3]. Based on the observations and discussion in this paper, we respectfully ask RAN2 to discuss and consider the following proposals. 
(38.304 Issue 2) SIB1 acquisition failure upon the expiry of OD-SIB1 monitoring window:
Observation 1	RAN2 agreed that UE can bar a SIB1-less cell ONLY when: 1) UE had no corresponding UL WUS configuration, 2) MAC indicates max number of preamble transmission for the OD-SIB1 request, and 3) UE fails to acquire SIB1 upon the expiry of the SIB1 monitoring window. Hence, no other cases need to be considered and specified in TS 38.304 or TS 38.331.
Observation 2	If we don’t specify the UE behavior for the case 3) above, UEs may keep requesting the OD-SIB1 transmission from a SIB1-less cell even if the OD-SIB1 acquisition is doomed to failure.
Proposal 1	(38.304 Issue 2) RAN2 to specify the UE behavior on the expiry of the SIB1 monitoring window in TS 38.304 (i.e., to remove the brackets in the sub-clause 5.3.1 of the 38.304 running CR [2]).
Proposal 2	(38.304 Issue 2) If P1 is agreed, RAN2 to adopt the TP in Annex A into the 38.331 running CR [3].
The provision of the cell access related information:
Observation 3	The UE may find an OD-SIB1 cell not suitable for cell reselection after requesting and acquiring the on-demand SIB1 from the cell.
Proposal 3	UL-WUS configuration can include the cell access related information (i.e., CellAccessRelatedInfo IE and feature-specific barring indications) per neighboring OD-SIB1 cell.
Proposal 4	If P3 is agreed, RAN2 to adopt the TP in Annex B into the 38.331 running CR [3].

3GPP TSG-RAN WG2#130	R2-2503806
St. Julians, Malta, May 19th – 23rd, 2025

Source: 	Fujitsu
Agenda item:	8.5.3
Title:	Remaining issues on on-demand SIB1 procedure
Document for:	Discussion and decision

Conclusion
In this contribution, the following proposals and observations were made:
Cell access information in UL WUS configuration
Proposal 1:	Cell access information is optionally included in UL WUS configuration.
Proposal 2:	If cell access information is not included in UL WUS configuration, the UE should follow the legacy UE behaviour.
Proposal 2a:	If cell access information is different between Cell A and NES cell, it can be indicated in UL WUS configuration as delta configuration.

Different values between OD-SIB1 and UL WUS configuration
Proposal 3:	RAN2 to confirm there is no specification impact on the UE behaviour even if the value in OD-SIB1 IE can be different from the value of the corresponding IE in the UL WUS configuration.

SIBX acquisition in NES cell in RRC connected mode
Proposal 4:	Legacy UE behaviour is used for acquiring SIBX of NES cell in RRC connected mode.

Handling of legacy excluded cell list
Proposal 5:	The UE always ignores the legacy excluded cell list received from a cell in which SIBX is provided, irrespective of whether dedicated excluded cell list being provided.

On-demand SIB1 transmission status
Proposal 6:	RAN2 to reconfirm the UE will check SIB1 is being broadcasted in the NES cell before requesting SIB1. This should be caputured as normative text in TS 38.331 (as in the RRC running CR). 
Proposal 7:	It is up to UE implementation how to check SIB1 is not broadcasted before requesting SIB1. This should be captured as informative text in TS 38.331.

On-demand SIB1 update in NES cell
Proposal 8:	The updated SIB1 is transmitted during whole next modification period.
Proposal 9:	The UE considers the NES cell as barred if the UE is unable to acquire the updated SIB1 after SI update reception.

3GPP TSG-RAN WG2 Meeting #R2-130		        R2-2503823      St Julians, Malta, May 19-23, 2025	

Agenda Item:	8.5.3
Source: 	Rakuten
Title:  	Remaining issues of OD-SIB1

Document for:	Discussion and decision

Conclusion
We have the following observations:
Observation 1	NES cell triggering OD-SIB1 transmission per UE is sub-optimal from energy savings perspective.
Observation 2	Eligible UEs in IDLE/INACTIVE mode which are camped on Cell A are not aware of NES cell’s OD-SIB1 transmission.
We have the following proposals: 
Proposal 1 	Cell access related information for barred R19 UEs should be included in the UL WUS configuration to avoid unnecessary SIB1 requests on a cell where UE does not have access.
Proposal 2	When an overload condition of IDLE/INACTIVE UEs is detected in Cell A, the Cell A gNB shall initiate offloading of IDLE/INACTIVE UEs to NES cells.
Proposal 3	During overload, Cell A gNB initiates System Info Modification to trigger camped UEs to read modified SIB, acquire UL-WUS configuration, evaluate the radio condition of NES cell, transmit UL WUS request and perform cell re-selection to NES cell.
Proposal 4	The Cell A SIB shall indicate the list of NES Cell IDs selected for offloading UEs and the cause.
Proposal 5	RAN2 asks RAN3 to discuss and agree a solution for Cell A gNB to request NES cell gNB to trigger OD-SIB1 transmission without a UL WUS.
Proposal 6	When the OD-SIB1 transmission is planned to be initiated, the NES cell gNB shall notify the Cell A gNB about the NES Cell ID and its OD-SIB1 transmission. RAN2 asks RAN3 to discuss and agree a way forward for this issue.
Proposal 7	The Cell A gNB shall send a SystemInfoModification notification to all the IDLE/INACTIVE UEs to inform them about the NES Cell ID and its OD-SIB1 transmission.
Proposal 8	The IDLE/INACTIVE UEs on Cell A, who already have the WUS configuration of the given NES cell, may access OD-SIB1 of NES cell without sending a UL WUS request and perform cell re-selection to NES cell.
Proposal 9	RAN2 to discuss and decide if there is a limit on the number of UL WUS configurations broadcasted by any Cell A.

3GPP TSG-RAN WG2 Meeting #130			         R2-2503839
St.Julians, Malta, May 19th – 23rd, 2025
Agenda Item:	8.5.3
Source: 	LG Electronics Inc.
Title:         	Remaining issues on OD-SIB1 operation
Document for: 	Discussion and Decision

Conclusion
Proposal 1	For legacy excluded cell list issue, choose one of the following options:
Option 1. UE always ignores the legacy excluded cell lists received from a cell in which SIBxx is provided.
Option 2. Rel-19 excluded cell list can be configured as an empty list (No new UE behaviour).
Proposal 2	UE can initiate SIB1 request while SDT procedure is ongoing.
Proposal 3	Ask RAN1 first whether they will capture the details on how UE acquire OD-SIB1 in RAN1 specification.
Proposal 4	Capture explicitly the failure case of OD-SIB1 window expiry in 38.331, as other failure cases.
Proposal 5	When T311 is running, if the first PLMN-Identity, systemInformationAreaID and valueTag received from the last serving cell are identical to those of the stored SIB X, UE considers the stored SIB X as valid.
Proposal 6	Add a below NOTE in 5.2.2.3.5:
	NOTE: The UE supporting OD-SIB1 in RRC_CONNECTED considers the si-BroadcastStatus in the stored SIB1 as the latest one, if the UE has a stored valid version of od-SIB1-Config for PCell.
Proposal 7	Capture the triggering conditions for OD-SIB1 request in 5.2.2.3.1.

3GPP TSG-RAN WG2 Meeting #130	R2-2503894
Saint Julian’s, Malta, 19 – 23 May 2025	
	

Agenda item:	8.5.2
Source:	Nokia, Nokia Shanghai Bell
Title:	On-demand SIB1 for Idle/Inactive mode UEs
WID/SID:	Netw_Energy_NR_enh
Document for:	Discussion and Decision
1	

Conclusions
Observation 1: Switching between legacy periodic SIB1 transmission and on-demand SIB1 transmission is a valid issue to be considered by RAN2. 
Observation 2: NES UE with SIB1 request configuration of a NES cell assumes that a NES cell, with SSB containing:
Observation 3: Legacy and NES UEs assume MIB TTI is 80ms. 
Proposal 1: For switching of SIB1 transmission mode, RAN2 to consider that NES UE which has SIB1 request configuration of a cell, NES UE is expected to update MIB until SIB1 acquisition is completed.   
Proposal 2: In case of NW operation in OD-SIB1 mode, UE in RRC_CONNECTED can obtain the SIBX from NWBy the NW dedicatedSytemInformationDeliverySIBX. And then UE can use OD-SIB1 request procedure to acquire SIB1.

Observation 4: It is useless to request OD-SIB1 from the cell where UE cannot anyway camp on
Observation 5: Access related information is used by UE only when starting to establish connection in the cell
Observation 6: There is no benefit for providing access related information as UE will only apply that information when starting to establish connection and the information may have changed while UE is camping in the cell.
Observation 7: For camping in the cell UE needs to know PLMN/NPN, Cell barring as well as Cell reservation information
Proposal 3: Allow in the SIB1 request configuration to provide following information:
Proposal 4: rename OD-SIB1-CellConfig to OD-SIB1_FrequencyConfig
Proposal 5: Add another layer of SEQUENCE in the OD-SIB1-CellConfig to allow a frequency have multiple different od-SIB1-Configs – One needs to assume that it is possible that no single cell shares same configuration.
Proposal 6: Add an indication from RRC to lower layers about successful SIB1 reception and in MAC a procedure to stop RACH procedure triggered due to SIB1 request. See Annex B for TP


Annex A: TP for camping information provision in SIB1 request configuration
NOTE: CHANGE MARKS ARE ON TOP OF VERSION R2-250xxxx Running RRC CR NES Post129bis_V03.docx
–	SIBxx
SIBxx contains information to assist OD-SIB1 acquisition from serving cell or neighbour cells.
SIBxx information element
-- ASN1START
-- TAG-SIBxx-START

SIBxx-r19 ::=                  SEQUENCE {
    od-SIB1-CellConfigList-r19         SEQUENCE (SIZE(1..maxCellODSIB1-r19))  OF OD-SIB1-CellConfig-r19    OPTIONAL,        -- Need R
    lateNonCriticalExtension                 OCTET STRING                                      OPTIONAL,
    ...

}


OD-SIB1-CellConfig-r19 ::=              SEQUENCE {
      carrierFreq-r19                          ARFCN-ValueNR,
      physCellId-r19                      SEQUENCE (SIZE(1..maxPCI-r19))  OF PhysCellId,
      od-SIB1-Config-r19                        od-SIB1-Config-r19                               OPTIONAL,        -- Need R

    ... 
}

























OD-SIB1-Config-r19  ::= {
     sib1-rsrp-ThresholdSSB-r19                       RSRP-Range                                                              OPTIONAL,   -- Need R
      prach-RootSequenceIndex-r19        CHOICE {
        l839                               INTEGER (0..837),
        l139                               INTEGER (0..137)
      }                                                                                                                   OPTIONAL, -- Need R
      msg1-SubcarrierSpacing-r19               ENUMERATED {kHz1dot25, kHz5, kHz15, kHz30, kHz60, kHz120, spare1, spare2}  OPTIONAL, -- Need R
      sib1-tdd-UL-DL-ConfigurationCommon-r19   TDD-UL-DL-ConfigCommon                                                     OPTIONAL, -- Cond TDD
      sib1-restrictedSetConfig-r19             ENUMERATED {unrestrictedSet, restrictedSetTypeA, restrictedSetTypeB}       OPTIONAL, -- Need R
      offsetToCarrier-r19                          INTEGER (0..2199)                                                          OPTIONAL, -- Need R
      absoluteFrequencyPointA-r19                  ARFCN-ValueNR                                                              OPTIONAL, -- Need R 
      p-Max-r19                                    P-Max                                                                      OPTIONAL, -- Need R
      ss-PBCH-BlockPower-r19                       INTEGER (-60..50)                                                          OPTIONAL, -- Need R
      ssb-PositionsInBurst-r19                SEQUENCE {
        inOneGroup                          BIT STRING (SIZE (8)),
        groupPresence                       BIT STRING (SIZE (8))                                   OPTIONAL  -- Cond FR2-Only
    },
      sib1-RequestConfig-r19                   SIB1-RequestConfig-r19                                                     OPTIONAL  -- Need R
}


SIB1-RequestConfig-r19 ::=                SEQUENCE {
     totalNumberOfRA-Preambles-r19           INTEGER (1..63),
     rach-OccasionsSIB1-r19                    SEQUENCE {
        ssb-perRACH-Occasion-r19                ENUMERATED {oneEighth, oneFourth, oneHalf, one, two, four, eight, sixteen}
    }                                                                                                       OPTIONAL,   -- Need R
    sib1-RequestPeriod-r19                    ENUMERATED {one, two, four, six, eight, ten, twelve, sixteen}       OPTIONAL,   -- Need R
    sib1-RequestResources-r19                 SEQUENCE (SIZE (1..maxSIB1-Message)) OF SIB1-RequestResources-r19,
    preambleTransMax-r19                    ENUMERATED {n3, n4, n5, n6, n7, n8, n10, n20, n50, n100, n200}

}

SIB1-RequestResources-r19 ::=             SEQUENCE {
    sib1-ra-PreambleStartIndex-r19               INTEGER (0..63),
    sib1-ra-AssociationPeriodIndex-r19           INTEGER (0..15)                                                     OPTIONAL,   -- Need R
    sib1-ra-ssb-OccasionMaskIndex-r19            INTEGER (0..15)                                                     OPTIONAL    -- Need R
}

-- TAG-SIBxx-STOP
-- ASN1STOP






Editor’s note: Only parameters in R1-2501645 that are in own rows are implemented and not all listed e.g. in cell 17P or 21P. 
FFS to group some parameters under subIEs like frequencyInfoUL 
FFS to separate IE OD-SIB1 as own IE, for review purposes it is here now.
FFS: value for maxCells, maxSIB1-Message, maxPCI
FFS: optionality of the parameters as there was no input on this
FFS: if list of cells is ARFCN&PCI or only PCI

Annex B – on FFS how does UE check is SIB1 is already provided.
----------RRC----------------
5.2.2.4.2	Actions upon reception of the SIB1
Upon receiving the SIB1 the UE shall:
1>	store the acquired SIB1;



1>	if the access is for NTN:
2>	if the UE is in RRC_IDLE or in RRC_INACTIVE, or if the UE is in RRC_CONNECTED while T311 is running:
3>	if the cellBarredNTN in the acquired SIB1 is set to barred or the cellBarredNTN is not included in the acquired SIB1:
4>	consider the cell as barred in accordance with TS 38.304 [20];
4>	perform cell re-selection to other cells on the same frequency as the barred cell as specified in TS 38.304 [20], upon which the procedure ends;
3>	if the UE is a fixed VSAT UE and the cellBarredFixedVSAT in the acquired SIB1 is set to barred or the cellBarredFixedVSAT is not included in the acquired SIB1, or
3>	if the UE is a mobile VSAT UE and the cellBarredMobileVSAT in the acquired SIB1 is set to barred or the cellBarredMobileVSAT is not included in the acquired SIB1:
4>	consider the cell as barred in accordance with TS 38.304 [20];
4>	perform cell re-selection to other cells on the same frequency as the barred cell as specified in TS 38.304 [20], upon which the procedure ends;
------------------ unchanged parts omitted from rest of the section ------------------------------
------------MAC-------------
5.1.6	Completion of the Random Access procedure
Upon completion of the Random Access procedure, the MAC entity shall:
1>	discard any explicitly signalled contention-free Random Access Resources for 2-step RA type and 4-step RA type except the 4-step RA type contention-free Random Access Resources for beam failure recovery request, if any;
1>	flush the HARQ buffer used for transmission of the MAC PDU in the Msg3 buffer and the MSGA buffer.
Upon successful completion of the Random Access procedure initiated for DAPS handover, the target MAC entity shall:
1>	indicate the successful completion of the Random Access procedure to the upper layers.
Upon successful completion of the Random Access procedure initiated for LTM cell switch, the MAC entity shall:
1>	indicate the successful completion of the LTM cell switch to upper layers.

3GPP TSG-RAN WG2 Meeting #130		         R2-2503955
St.Julians, Malta,  May 19th – 23rd , 2025                                                    	

Agenda Item:	8.5.3
Source: 	ITRI, Acer Incorporated
Title:  	Discussion on SIBxx validity check during T311

Document for:	Discussion 

Conclusion
Proposal: 
A connected mode NES capable UE should monitor for SI change indication during T310 if the UE has not yet monitored for SI change indication within the modification period.

3GPP TSG-RAN WG2 Meeting #130	R2-2503999
St. Julians, Malta, May 19th – 23rd, 2025

Agenda Item:	8.5.3
Source:	OPPO
Title:	Consideration on on-demand SIB1
Document for:	Discussion, Decision

Conclusion
We have the following proposals:
Proposal 1	In Rel-19 NES, do not include cell access information originally provided in SIB1 in the UL-WUS configuration.
Proposal 2	RAN2 rely on R1 for Kssb setting upon SIB1 request. No R2 specification impact is foreseen.
Proposal 3	When SDT is on-going, RAN2 discuss to 1) either not support OD-SIB1 request; 2) or support OD-SIB1 request but leave it to UE implementation to handle the collision, if any.

3GPP TSG-RAN WG2 Meeting #130                                    R2-2504037
St.Julians, Malta, May 19th – 23rd, 2025

Agenda Item:	8.5.3
Source:	vivo
Title:	Remaining issues on OD-SIB1
Document for:	Discussion and Decision

Conclusion
Based on the discussion, we have the following observations and proposals:
Access related information in UL WUS configuration
Proposal 1: OD-SIB1 request configuration optionally includes cell access related information. 
Proposal 2: If the UE considers an OD-SIB1 cell as ‘not barred’ according to the cell access related information included in the OD-SIB1 request configuration, the UE can trigger OD-SIB1 request towards the OD-SIB1 cell upon cell reselection.
OD-SIB1 request received by multiple NES cells sharing the same UL WUS configuration
Observation 1: Multiple adjacent OD-SIB1 cells sharing the same UL WUS configuration may receive the same OD-SIB1 request and respond to it, causing unnecessary NES gain loss as only one of them is the target cell for the cell reselection procedure of a UE.
Proposal 3: RAN2 to discuss how to address the issue that multiple adjacent OD-SIB1 cells sharing the same UL WUS configuration may receive the same OD-SIB1 request and respond to it:
Alt.1: Leave it to NW implementation, e.g. adjacent OD-SIB1 cells are not expected to share the same OD-SIB1 request configuration;
Alt.2: OD-SIB1 cells sharing the same OD-SIB1 request configuration can exchange information to avoid simultaneous response to the OD-SIB1 request. Send LS to RAN1/RAN3 to trigger the discussion for the exchanged information.
Impact to the legacy UE upon the cell switching from normal state to NES state
Observation 2: Both Cell A and the NES cell can switch from the normal state (e.g. sending CD-SSB&SIB1) to the NES state (e.g. sending NCD-SSB and monitoring UL WUS).
Proposal 4: The legacy UEs are expected to receive short message notifying SI change when the cell turns from sending CD-SSB to sending NCD-SSB. Once the short message is received, the legacy UEs bar the cell since SIB1 cannot be received due to kssb indicating SIB1 is not scheduled.
Stage-3 details
Proposal 5: Capture the RAN1 agreement “it is up to UE implementation whether to monitor Type 0 PDCCH for SIB1 transmission before transmitting WUS if the UE detects a SSB where K_SSB>=24 for FR1 or K_SSB>=12 for FR2” in RRC specification, as Annex 5.1 (change the triggering behavior to ‘may trigger’) or Annex 5.2 (add a note) shows.
Observation 3: According to the running CR to TS 38.331, the UE will trigger OD-SIB1 request when it receives SI change notification if kssb indicates that SIB1 is not scheduled in the cell, which is against previous RAN2 agreement “Once the NES UE camps on the NES cell, if the UE receives SIB change notification, the UE is expected to receive SIB1 from NES cell.”.
Proposal 6: RAN2 to discuss how the OD-SIB1 UE receives SIB1 if the UE receives SI change notification and the kssb is indicating SIB1 is not scheduled in the cell (e.g. the UE uses the CORESET#0 parameters in OD-SIB1 request configuration to receive SIB1), considering the UE behavior will be falsely requesting OD-SIB1 according to the running CR to TS 38.331. Send LS to RAN1 if needed.
Proposal 7: For the RAN2 agreement “NW ensures that the RRC connected UE has the latest SIB1 (e.g. dedicated RRC message to deliver SIB1 or not configure searchSpaceSIB1), as baseline. UE understands that the stored SIB1 is the latest SIB1.”, add a note in RRC specfication:
Note: If kssb indicates that SIB1 is not scheduled in the cell, the UE in RRC_CONNECTED assumes the stored SIB1 is the latest SIB1.

3GPP TSG-RAN WG2 Meeting #130  	                            R2-2504054
St.Julians, Malta, May 19th – 23rd, 2025			                                				             
	                        	             
Agenda Item:	8.5.3
Source: 	Sony
Title:	Remaining details for on-demand SIB1 
Document for:	Discussion 

Conclusion
We have observation as follows.
Observation 1: RAN2 may need to revisit the previous agreement regarding UE’s behaviour on monitoring OD-SIB1 is being broadcasted before sending the request, after RAN1 makes decision on this issue.
We propose RAN2 to discuss following proposals:
Proposal 1: Send LS to RAN1 informing RAN2 decision on “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.”.

	



  

3GPP TSG RAN WG2 Meeting #130                          	   R2-2504243
St. Julians, Malta, May 19th – 23rd, 2025

Agenda item:	8.5.3     
Source:	Qualcomm Incorporated
Title:	Discussion on On-demand SIB1
WID/SID:	Netw_Energy_NR_enh-Core – Release 19
Document for:	Discussion

Conclusion
In this contribution, we discussed design details of UL-WUS configuration for on-demand SIB1 observations and proposals.
Observation 1. Some UL-WUS parameters in an UL-WUS configuration can be cell specific which may limit the option of sharing an UL-WUS configuration among multiple NES cells.
Observation 2. plmn-IdentityList and trackingAreaCode contain large number of bits (especially plmn-IdentityList) which may increase UL-WUS configuration significantly.
Proposal 1. RAN2 supports the following parameters to be included in UL-WUS configuration.
cellReservedForOtherUse	
cellReservedForFutureUse	
cellBarredATG		
cellBarred-eRedCap1Rx	
Barred-eRedCap2Rx		
cellBarredNES		
cellBarredNTN		
cellBarred-RedCap1Rx	
cellBarred-RedCap2Rx	
Proposal 2. It is network implementation to include the following parameters in UL-WUS configuration.
plmn-IdentityList	
trackingAreaCode	

TDoc file unavailable

3GPP TSG-RAN WG2 Meeting #130	R2-2504387
St.Julians, Malta,  May 19th – 23rd , 2025
Agenda Item:	8.5.3
Source:	CMCC
Title:	Discussion on On-demand SIB1
Document for:	Discussion

Conclusions
In this contribution, we analyse the OD-SIB1 related open issues , following are the proposals and observations:
Proposal 1:Feature-specific barring information can be included in OD-SIB1 WUS configuration.
Proposal 2: Cell access related information is not included in OD-SIB1 WUS configuration.
Proposal 3: The maximum number of configured inter frequency cells can be considered as the maximum  number of WUS configuration, i.e., 16.
Proposal 4: The cell list in WUS configuration indicates the ARFCN&PCI of the NES cell.
Proposal 5: The maximum number of OD-SIB1 resources can be considered as the same with the number of PCIs sharing the same OD-SIB1 resources.
Proposal 6: Support the co-existence of OD-SIB1 and SDT, and OD-SIB1 procedure can only be triggered by the UE while SDT procedure is not ongoing.
Proposal 7: The change of OD-SIB1 related configuration (e.g., WUS configuration) due to SBFD is not supported in Rel-19, and there’s no spec impact to indicate SBFD configuration in SIB1 acquired by UE’s on-demand request.

3GPP TSG RAN WG2 #130			R2-2504419
St Julians, Malta, May 19th – 23rd, 2025

Source:	NTT DOCOMO, INC.
Title:	Discussion on on-demand SIB1
Agenda Item:	8.5.3
Document for: 	Discussion and Decision

Conclusion
In this contribution, we provided the following observations and proposals of on-demand SIB1 operation for idle/inactive mode UEs network energy saving.


Proposal 1: (38.304-1)
It should be possible configurations that Rel-19 UEs being capable of OD-SIB1 are not provided with any excludes cell lists while legacy UEs are provided with only NES cells as excluded cell lists
The following solutions can be considered: 
NES UEs always ignore the legacy excluded-cell list
NES UEs refers to Rel-19 excluded-cell list that is configured as empty

Proposal 2: (38.304-2)
There is no need to explicitly capture the failure case of OD-SIB1 window expiry in 38.304 unless RAN1 specifies that PHY layer indicates it to higher layer.

3GPP TSG-RAN WG2 Meeting #130	R2-2504470
St.Julians, Malta, May 19th – 23rd, 2025

Agenda Item:	8.5.3
Source:	HONOR
Title: 	Discussion on on-demand SIB1
Document for:	Discussion and decision

Conclusions
In this contribution, we discussed several detailed on-demand SIB1 issues, and made the following observations and proposals:
Observation 1: The K_SSB indicated in the MIB of NES cells may no longer retain its original physical meaning, i.e. no longer indicate the subcarrier offset from subcarrier 0 in the common resource block to the lowest-numbered subcarrier of the SS/PBCH block.
Proposal 1: K_SSB/PDCCH-ConfigSIB1 could be used to indicate the SIB1 broadcast status.
Proposal 2: It is proposed to indicate the remaining number of SIB1 transmissions in the SIB1 time window or the end of the SIB1 time window if SIB1 is broadcasting, e.g. redefine the PDCCH-ConfigSIB1.
Proposal 3: NES UE may trigger UL-WUS for SIB1 if it cannot acquire SIB1 upon the expiry of the SIB1 monitoring window triggered by the other NES UEs.
Proposal 4: After the NW sends the SI change indication in the NES cell, it will not actively broadcast the updated SIB1 unless a NES UE sends an OD-SIB1 request.
Proposal 5: In NES cell, the UE could trigger the request for OSI without re-acquiring SIB1 to check OSI broadcasting status. 
Proposal 6: For OD-OSI in NES cell, the mapping between si-RequestResources and SI message should not be changed with broadcasting status of every OSI.
Proposal 7: WUS configuration provides some necessary cell access information optionally, including PLMN ID, and cellbarred indication for UEs with different features as a baseline.

3GPP TSG-RAN WG2 Meeting #130		R2-2504493
St Julian’s, Malta, May 19th – 23th, 2025

Agenda Item:		8.5.3
Source:				ASUSTeK
Title:		Broadcasting status for OD-SIB1 request
Document for: 	Discussion and Decision

Conclusion
In this contribution, we discuss issues related to OD-SIB1 broadcasting status check and have the following observations/proposals:
Observation 1: Based on the agreement made by RAN1 in RAN1120bis, there is no specified way for UE to determine broadcasting status of SIB1.
Observation 2: RAN2 needs to further confirm whether to conduct a broadcasting status check prior to SIB1 request as agreed in RAN2#127.
Proposal: RAN2 decides one of the following alternatives:
Alt. 1: RAN2 sticks to conduct a broadcasting status check by checking K_SSB in MIB of that cell before requesting SIB1of that cell.
Alt.2: RAN2 reverts the following agreement: 
Agreements on OD-SIB1
…
8.	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.
Alt. 3: RAN2 captures a note in the specification to clarify it’s up to UE’s implementation whether and how to check if SIB1 is currently being broadcasted or provided on demand for that cell before requesting SIB1of that cell.

3GPP TSG-RAN WG2 Meeting #130	R2-2504533
St Julian’s, Malta, May 19th- 23th, 2025
Source:	KDDI Corporation
Title:	Discussion on On-demand SIB1
Tdoc Type:	Discussion
Agenda Item:	8.5.3	
Document for:  Discussion 
Release:       Rel-19
1	

Conclusion
We make the following observations and proposals:
Proposal 1: SIB-x is not considered as essential system information.
Proposal 2: SIB-x can be configured as “not-broadcasting” for network energy saving. 
Proposal 3: UE request SIB-x via legacy SI-Request procedure 
Proposal 4: Cell access related information is not needed in the WUS configuration.
Proposal 5: RAN2 discuss the necessity of including ANR in the on-demand SIB1 scenario.
Proposal 6: If RAN2 discuss the coexistence of ANR and on-demand SIB1, RAN2 agree that the solution should be considered within RAN3

TDoc file unavailable

3GPP TSG RAN WG2 Meeting #130     													         R2-2504604
St.Julians, Malta,  May 19th – 23rd , 2025

Agenda item:		8.5.3
Title:						Reducing On-demand SIB1 overhead
Source:				Fraunhofer IIS, Fraunhofer HHI
Document for:		Discussion

Conclusions
In this contribution, we discussed some aspects of on-demand SIB1 for NES. The following observations and proposals have been made:
Observation 1: It is very important to reduce UL WUS configuration overhead in on-demand SIB1.
Proposal 1: In the UL WUS configuration all elements are made optional. Only the ones which differ from Cell A SIB1/PRACH/RAR configuration must be sent on SIBxx by the gNB. The UE shall use the same parameters from Cell A SIB1 for any parameters of SIBxx which were not sent on SIBxx. 

3GPP TSG RAN WG2 #130                              	R2-2504606
St. Julians, Malta, May 19th – 23rd, 2025

Agenda item:	8.5.3
Source: 	Sharp
Title: 	Remaining issues on OD-SIB1 Request
Document for:	Discussion and Decision

Conclusions
Based on the discussion, we have the following observations and proposals:
Firstly,  to reduce the failure rate of RRC re-establishement procedure under RAN shating scenario and factiliate the discussion of cell access related information, Proposal 1~3 are suggested: 

  OD-SIB1 request may support RAN sharing. 
  OD-SIB1 request may be supported by public networks and non-public networks. 
OD-SIB1 request configuration should include the network identities supported by OD-SIB1 cells if SIB1 request supports RAN sharing. 
CellAccessRelatedInfo can be considered as the baseline of access related information in OD-SIB1 request configuration
The CellAccessRelatedInfo of Cell A can be applied as a reference to indicate the CellAccessRelatedInfo of OD-SIB1 cell. Details can be decided by RAN2 WG. 

Then, during cell re-selection procedure, we propose that a UE who supports OD-SIB1 should follows legacy excluded cell lists if OD-SIB1 dedicated excluded cell lists are absent.
If OD-SIB1 dedicated excluded cell lists are absent, the UE supporting OD-SIB1 follows legacy excluded cell lists.
Finally, Proposal 5 is raised to discuss how does a UE in RRC_CONNECTED be notified when a OD-SIB1 cell is switched to a normal cell.
RAN2 to discuss whether OD-SIB1 cell is allowed to switch to normal cell and how the UEs in RRC_CONNECTED can know the switching.