TDoc file reading error

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

Agenda item:	8.9.4
Source:	vivo
Title:	Remaining Issues on PWS Support for NB-IoT
Document for:	Discussion and Decision

Conclusion
In this contribution, we have further discussed the PWS support for NB-IoT. And we make the following observations and proposals:
FFS to accelerate the PWS acquisition:
Observation 1: PWS acquisition using the current mechanism leads to comparable long latency. 
Observation 2: The current spec already supports the NW to provide the SIB31(-NB) scheduling information to UE before the SIB31(-NB) is scheduled. 
Proposal 1: To avoid UE reacquire the SIB1-NB upon acquiring the PWS message, the network provides the SIB10-NB/SIB11-NB/SIB12-NB scheduling information within SIB1-NB.  
Proposal 2: When acquiring SIB10-NB/SIB11-NB/SIB12-NB, UE may assume that the scheduling is unchanged. 
FFS to support the inter-cell PWS reception:
Observation 3: Both RAN2 and RAN3 impacts are foreseen to support the PWS reception across cells.
Observation 4: Only RAN2 and NB-IoT NTN are within the scope for the PWS enhancement.
Proposal 3: RAN2 to check with RAN3 whether the current RAN3 spec can support UE to receive and assemble PWS segments across different cells.  

3GPP TSG-RAN WG2 Meeting #130	R2-2503501
St Julian’s, Malta, 19th – 23rd May, 2025 
Source:	ZTE Corporation, Sanechips
Title:	Remaining issues for PWS support in IoT NTN
Agenda Item:	8.9.4
Document for:	Discussion and Decision

Conclusion
Based on the above analysis, the following proposals are given:
Proposal 1a: It’s suggested to follow the legacy scheme to acquire SIB10-NB~SIB12-NB, e.g., upon receiving the PWS notification from eNB, the PWS-capable NB-IoT UE firstly needs to re-acquire schedulingInfoList contained in SIB1 immediately without waiting until the next system information modification period boundary, and then acquire the corresponding PWS messages.
Proposal 1b: No need to support any scheme of providing pre-configured scheduling information for SIB10-NB~SIB12-NB when there is no PWS notification.

Proposal 2a: For NB-IoT UE, the ETWS, CMAS, PWS requirement may not be met in some cases. Besides the case when the UE is in eDRX, there are also other cases, e.g., when the UE is configured with a large DRX cycle (e.g., rf512, rf1024), or when PSM is enabled.
Proposal 2b: It’s suggested to capture Proposal 2a in section “4.10 NB-IoT” in TS 36.300 running CR as below:

Proposal 3: It’s suggested to introduce support for acceptable cell and also support for “Camped on Any Cell state” for NB-IoT NTN UE.

Proposal 4a: Two capabilities of supporting ETWS or CMAS reception can be introduced for NB-IoT UE.
Proposal 4b: It’s suggested RAN2 to discuss the following potion to mitigate the potential signaling storm issue caused by releasing UEs to idle state to acquire PWS messages:
To introduce a waiting time range (e.g., similar as the backoff parameter in RACH procedure) in SIB or RRC release message to facilitate the UEs to randomly select a waiting time in this range on their own.

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

Source: 	Huawei, HiSilicon, Turkcell
Title: 	Remaining issues on PWS support for NB-IoT
Agenda Item:	8.9.4
Document for:	Discussion and decision

Conclusion
This contribution discussed the support of PWS for NB-IoT. Proposals are summarized as follows:
Proposal 1: (RRC-5) NW can choose to send the scheduling information of PWS SIBs in advance and indicate whether the PWS SIBs are being broadcast or not similar to NR on-demand SI si-BroadcastStatus indication. 
Proposal 2: (RRC-6) A UE is allowed to assemble the PWS segments from different cells within an area. 

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

Agenda Item:	8.9.4
Source:	OPPO
Title:	Discussion on PWS for NB-IoT
Document for:	Discussion, Agreement

Conclusion
Based on the discussion we propose the following:
The existing ETWS/CMAS notification RRC procedures for eMTC is reused for NB-IoT

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

Agenda item:	8.9.4
Source:	Nokia, Nokia Shanghai Bell
Title:	Remaining issues on support of PWS for NB-IoT NTN
WID/SID:	IoT_NTN_Ph3-Core - Release 19
Document for:	Discussion and Decision
1	

Conclusion
Inter-cell PWS reception (open issue RRC-6)
Observation 1: In legacy, the PWS message segmentation feature is only supported for the intra-cell scenario.
Observation 2: In NTN, all the segments of PWS message may not be delivered to UE successfully within a single cell in moving cell scenario.
Proposal 1: Support continued reception of PWS segmentation of a message from different cells in moving cell scenario. 
Proposal 2: Introduce a new indication in SIB for inter-cell PWS segmentation reception.
Proposal 3: The segementation size of PWS message should be exchanged via inter-node message to support inter-cell PWS reception.
PWS Support in SF mode
Observation 3: PWS delivery when cell operates in S&F mode may have impacts on meeting delay requirements of PWS services.
Observation 4: RAN2 assumes no additional impact in supporting PWS functionality in S&F operation.
Proposal 4: Support for PWS in SF operation is decided at SA2. RAN2 to decide whether to send LS on this or wait for SA2 decision.
WUS Efficiency Impacts for PWS Transmission 
Observation 5: WUS configuration helps to minimize downlink monitoring related energy consumption for UE configured with shorter eDRX cycle.
Observation 6: Network that supports PWS and shorter eDRX cycle configuration for UE may activate WUS functionality to reduce the overall energy consumption associated with faster PWS reception.
Observation 7: When WUS is configured in NB-IoT cell, the PWS transmission may false wake-up all the UE outside the PWS service area resulting in reducing the overall efficiency of WUS benefits.
Proposal 5: RAN2 to consider PWS specific WUS configuration for improved paging efficiency for PWS related paging notification.

TDoc file reading error

3GPP TSG-RAN WG2 Meeting#130                               	R2-2503799
St. Julians, Malta, May 19th – 23rd, 2025	
	
Agenda item:	8.9.4
Source: 	Google
Title: 	Open issues on the support for PWS in NB-IoT
Document for:	Discussion and Decision

Conclusion
In this paper, we discuss two open issues for supporting the broadcast of PWS messages in NB-IoT, among the open issues listed by the RRC running CR rapporteur. Based on the observations and discussion in this paper, we respectfully ask RAN2 to discuss and consider the following proposals.
(RRC-6) Handling of PWS segments after switching to a new cell:
Observation 1	(RRC-6) An LTE UE switching to a new cell would discard any previously buffered PWS segments, if it has not fully received a segmented PWS message in the original cell.
Observation 2	(RRC-6) Most likely, an UE in the idle mode would connect to the same eNB while moving from one NTN cell to another. Discarding previously buffered PWS segments in such instances would lead to significant inefficiencies in both resource utilization and power consumption.
Proposal 1	(RRC-6) UE is allowed to retain previously buffered PWS segments and resume PWS reception when transitioning to a new NTN cell from a previously served NTN cell.
Proposal 2	(RRC-6) If P1 is agreed, RAN2 to adopt the TP in Annex A into the current 36.331 running CR.
(RRC-4) Inclusion of PWS area information in Paging:
Observation 3	(RRC-4) The likelihood of paging an irrelevant UE in an NTN cell for a PWS alert is very high.
Proposal 3	(RRC-4) PWS area information in coarse level can be signaled together with a PWS indication in Paging-NB. The UE not within the area determined by the PWS area information can skip acquiring the system information relevant to the PWS.
Proposal 4	(RRC-4) If P3 is agreed, RAN2 to adopt the TP in Annex B into the current 36.331 running CR.

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

Agenda item:		8.9.4
Source:		Lenovo
Title:		Further considerations on PWS broadcast support in IoT NTN
Document for:		Discussion

Conclusion
In this contribution we discuss further issues and potential solutions to support PWS broadcast for NB-IoT in NTN. The following observations are given:
Observation 1: The warningAreaCoordinatesSegment can be used to indicate Geo-Fencing Maximum Wait Time, which is the time a device shall allow to determine its position meeting operator policy.
Observation 2: If the device is unable to determine its position meeting operator policy within the Geo-Fencing Maximum Wait Time, it shall present the alert to the user and discontinue further positioning determination for the alert.
Observation 3: Except for Write-Replace Warning Request, the legacy PWS procedures between eNB and MME can only indicate cell-level PWS information.
Observation 4: The PWS broadcast service area indication can be associated to the paging indication or PWS contents in PWS SIBs to facilitate area-based delivery to NB-IoT UEs.
And we propose:
Proposal 1: RAN2 to discuss whether the outcome of GNSS positioning for UL synchronization in NTN at UE can be used to fulfill the requirement of the positioning from reception of warningAreaCoordinatesSegment indicating Geo-Fencing Maximum Wait Time.
Proposal 2: RAN2 to discuss whether the outcome of GNSS positioning for reception of warningAreaCoordinatesSegment indicating Geo-Fencing Maximum Wait Time can be used for UL synchronization in NTN.
Proposal 2-bis: If the outcome of GNSS positioning for reception of warningAreaCoordinatesSegment indicating Geo-Fencing Maximum Wait Time can be used for UL synchronization in NTN, RAN2 to discuss whether UE shall trigger report of gnss-ValidityDuration.
Proposal 3: RAN2 to discuss if the Geo-Fencing Maximum Wait Time indicated in warningAreaCoordinatesSegment is shorter than the gnss-PositionFixDuration, whether UE shall stop triggering GNSS positioning for reception of warningAreaCoordinatesSegment indicating Geo-Fencing Maximum Wait Time. The UE may still attempt for other positioning methods.
Proposal 4: For emergency broadcast service in a geographical area smaller than an NTN cell, RAN2 to discuss whether emergency broadcast service area information is needed for PWS procedures other than Write-Replace Warning Request. (Send LS to RAN3 if needed)
Proposal 5: RAN2 to discuss the association between PWS broadcast service area and paging indication or PWS contents in PWS SIBs.

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


Agenda item:	8.9.4
Source:	Samsung, Iridium, Vivo, Thales
Title:	Acceptable cell camping for NB-IoT
WID/SID:	IoT_NTN_Ph3-Core
Document for:	Discussion and Decision

Conclusion
In this contribution, we discussed issues related to PWS signaling for NB-IoT. 
Observation 1: In eMTC and normal LTE, a UE can camp on an acceptable cell to receive PWS broadcasting and originate emergency calls. This is a crucial part of cellular operation that users rely on daily. 
Observation 2: NB-IoT did not introduce camping on any cell or an acceptable cell as emergency calls or PWS signalling was never supported. 
Proposal 1: A UE shall be able to camp on an NB-IoT NTN cell for the purpose of receiving PWS broadcast, without the cell being a part of UEs PLMNs. 
Proposal 2: RAN2 to discuss introducing acceptable cell category for NB-IoT NTN. 

3GPP TSG-RAN WG2 Meeting #130                                    	R2-2504319
St. Julians, Malta, 19 - 23 May 2025               	 
	 
Agenda item:	8.9.4
Source:	Qualcomm Incorporated
Title:	Discussion on PWS in NB-IoT NTN
Document for:	Discussion and Decision

Conclusion
Following proposals are made:
Proposal 1	Introduce a new indication in MIB using a spare bit that a NB-IoT cell supports PWS feature.
Proposal 2	While searching for the suitable cell, NB-IoT UEs may camp on an acceptable cell that supports the PWS feature.
Proposal 3	Support of geofencing for PWS is optional feature without capability signaling.
Proposal 4	Consider pre-configuring the scheduling information of SIB10/11/12 in SIB1 and validating it by the PWS notification.
Proposal 5	Old PWS segments are discarded upon cell change.

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

Agenda Item:	8.9.4
Source: 	CATT
Title: 	Remaining issue on support of PWS for NB-IoT NTN UE
Document for: 	Discussion and Decision

Conclusion
In this contribution, the remaining issue on support of PWS for NB-IoT UE is discussed with the following proposal:
Proposal 1: RAN2 down-selects from the following way forwards regarding whether SIB1(-NB) needs to be first acquired upon PWS indication:
WF 1: Reuse the same mechanism as in LTE, i.e. the PWS indication triggers the UE to re-acquire schedulingInfoList contained in SIB1-NB to get scheduling info for corresponding PWS message.
WF 2: The schedulingInfoList contained in SIB1-NB includes the scheduling information for PWS message even when eNB does not broadcast PWS message, and the PWS indication triggers UE to acquire the corresponding PWS message immediately based on the stored schedulingInfoList.

3GPP TSG RAN WG2 Meeting #130	R2-2504394
St.Julians, Malta, May 19th – 23rd, 2025
Agenda Item:	8.9.4
Source:	CMCC	
Title:	Support of PWS messages for NB-IoT
Document for:	Discussion, Decision

Conclusion
Based on the discussions mentioned above, in this contribution we provide some discussions on broadcast of PWS messages for NB-IoT and have the following observations and proposals:
Observation 1: In NR NTN, it is agreed to include warningAreaCoordinates in SIB6 and warningAreaCoordinatesSegment in SIB7 to indicate Warning Area Coordinates IE for ETWS.
Proposal 1: It is proposed that warningAreaCoordinates and warningAreaCoordinatesSegment should be also included in SIB10-NB and SIB11-NB respectively.
Proposal 2: We could just extend the existing mechanism to NB-IoT NTN for SIB1-NB acquisition, and no further enhancement is needed.
Observation 2: Different from TN, for NTN system, satellites are always moving rapidly, which would lead to that UE may be not able to receive the whole PWS message from the serving cell.
Proposal 3: It is proposed that allow UE to receive and assemble PWS segments from different cells during mobility.

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

Agenda Item:	8.9.4
Source:	Ericsson
Title:	Enhancements to support PWS in NB-IoT NTN
Document for:	Discussion, Decision
1	

Conclusion
In the previous sections we made the following observations: 
Observation 1	First commercial NB-IoT NTN UEs may not be battery constrained and may prioritize better service delivery.
Observation 2	Frequent cell changes in NTN may lead to the UE discarding warningMessageSegment and potentially a failure in receiving an emergency notification.

Based on the discussion in the previous sections we propose the following:
Proposal 1	A UE interested in receiving PWS may indicate its interest to the network to adjust the assigned power saving configuration.
Proposal 2	RAN2 enables a NB-IoT UE to skip SIB1-NB acquisition when receiving the ETWS primary notification.
Proposal 3	Provided it is served by the same gNB, the UE should be allowed to assemble warningMessageSegments received from different cells/satellites.
Proposal 4	The network can indicate whether the UE should discard or continue using the previously buffered warningMessageSegments upon cell/satellite switch.


4