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

Agenda Item:	8.9.1
Source:	Huawei, HiSilicon
Title:	RRC open issue list for IoT NTN
Document for:	Discussion, Decision

Conclusions
The following proposals have been provided based on feedback to the above document:
[Proposals for discussion]
Proposal 1: (RRC-1) RAN2 to further discuss which of the following options to choose for indicating the transition time from normal mode to S&F mode:
Option 1: (5/9) It is up to NW implementation to set the legacy t-Service as the transition time from normal mode to S&F mode. 
Option 2: (5/9) Using the agreed time information in SIB31 for both directions of transition. UE determines which direction it is based on whether the S&F indication is present.

Proposal 2: (RRC-2) RAN2 to further discuss whether to introduce the following assistance information for the neighbour cells:
(5/9) Operation mode. 
(3/9) Mode transition time

Proposal 3: (RRC-4) RAN2 to further discuss whether to reduce the paging monitoring for an S&F UE to save power consumption.

Proposal 4: (RRC-5) RAN2 to further discuss whether to allow the UE to skip reading SIB1-NB to shorten the latency of PWS acquisition.

Proposal 5: (RRC-6) RAN2 to further discuss whether to allow UE to receive and assemble PWS segments from different cells during mobility.

Proposal 6: (RRC-7) RAN2 to further discuss whether to differentiate CB-Msg3 EDT for CP solution and UP solution in the procedure.

Proposal 7: (RRC-8) RAN2 to further discuss whether to model CB-Msg3 EDT as one sub-category of legacy EDT or as a separate concept in a separate section.

3GPP RAN WG2 Meeting #130	R2-2504140
St Julians, Malta May 19th – 23rd, 2025 
Agenda Item:	8.9.1
Source:	Nokia, Nokia Shanghai Bell
Title:	Remaining open issues for Idle mode procedure for IoT-NTN
Document for:	Discussion, Decision

Conclusions
Based on the analysis on the open issues for idle mode operation for IoT-NTN we make following observations and proposals.
Issue 1:  Acceptable camping for NB-IoT for ETWS/PWS reception
Observation 1: Support of acceptable cell camping requires additional UE functionality over the capability for PWS/ETWS reception from suitable cells.
Observation 2: The additional power consumption for idle mode operation without emergency call (only for ETWS reception) support needs to be justified.
Proposal 1:  RAN2 to discuss and conclude whether ETWS/PWS/CMAS reception for NB-IoT can be limited only to suitable cells.
Issue 2:  Emergency call support in SF operation 
Proposal 2: RAN2 to down-select any of the following option related to emergency call support in SF mode operation.
O1:Specification text can indicate that emergency calls are not supported when cell is operating in store and forward mode
O2:It is upto SA2 to clarify the support for IMS services and emergency services for SF operation. EN can be removed and updated if needed based on SA2 specification status.

3GPP RAN WG2 Meeting #130	R2-2504526
Malta, Malta May 19th – 23rd, 2025             
Agenda Item:	8.9.1
Source:	MediaTek. Inc
Title:	Remaining MAC open issues in IoT NTN
Document for:	Discussion, Decision

Conclusions
[Proposals for easy agreement]
Proposal 1 (7/8): The maximum TBS could be different for different CE levels.

Proposal 3 (9/9): For NB-IoT, the configurations of CB-Msg3-EDT for non-anchor carriers are put in the ul-ConfigList of SIB22-NB.

Proposal 5 (9/9): Revise the agreement that, due to only CE mode A is supported for eMTC NTN, only 1 separate RSRP thresholds and 2 CE levels can be supported.

[Proposals for discussion]
Proposal 2: For NB-IoT, RAN2 to discuss the mapping of NPUSCH resource to enhanced coverage levels.
Alt-1 (as legacy RACH):  enhanced coverage levels are numbered from 0 and the mapping of PRACH resources to enhanced coverage levels are done in increasing [number of repetition] order.
Alt-2 : The mapping of NPUSCH resource to enhanced coverage levels is configured in ASN.1 directly.

Proposal 4: For NB-IoT, when multiple carriers carriers provide CB-Msg3-EDT resources for the same enhanced coverage level, RAN2 to select one of below two alternatives: 
Alt-1 (7/11): (as legacy RACH): the NB-IoT UE selects the carrier based on the probabilities of each carrier. A new probability parameter for anchor carrier is introduced in SIB22-NB. The remaining probability is evenly split among the non-anchor carriers.
Alt-2 (4/11): (up to implementation): it is up to UE implementation to select any of the carriers.

Proposal 6: When max re-attempt number for current CE level has been reached, RAN2 to discuss whether the the UE should be in next CE level. 


[Proposal for open issue]
Proposal 7: RAN2 to discuss below open issues for CB-Msg3-EDT procedure.
MAC-2: CB-RNTI calculation
MAC-7: Whether the HARQ operation is applicable to transmit CB-Msg3.
MAC-9: Whether NW/UE processing time is needed when determine the Msg4 monitoring starts.
MAC-10: FFS it will also be possible for the NW to configure that the Msg4 monitoring window starts in the subframe containing the last (N)PUSCH repetition of the first replica plus UE-eNB RTT.
MAC-11: Whether a CB-Msg4 without RRC message is allowed as the complete response to the CB-Msg3 in CP solution.
MAC-12:  FFS how the multiplexing is organized for CB-MSG4.
MAC-13:  FFS new MAC PDU format for CB-Msg4
MAC-14:  FFS for the detail of HARQ operation on CB-Msg4.
MAC-15:  What should be the UE behavior (e.g. the can initiate the legacy 4-step RA) when the CB-Msg3 procedure fails. 
MAC-17: Whether to allow multiple TBSs as in EDT.
MAC-18: How to model the CB-Msg3 response window (i.e. MSG4 monitoring window) ? Should it be a timer as in legacy RA response window, and what should be the value range. 

3GPP TSG-RAN WG2 Meeting #130	R2-2504631
Malta, MT, May 19-23, 2025 	

Agenda Item:	8.9.1
Source:	THALES
Title:	Discussion to align IoT NTN k-Mac with IoT NTN TDD k-Mac
Document for:	Discussion

1	

Conclusion
In this contribution, the following proposals was provided:
It is beneficial for transparent architecture deployement with a limited number of gatewey to support extension of k-Mac parameter
K-Mac extension up to 1023 ms was agreed for IoT NTN TDD that would make an inconsistency between different NTN deployement scenarios
For IoT NTN, support k-Mac with a value range up to 1023 ms for Rel-19