TDoc file reading error

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

Agenda item:	8.17
Source:	vivo
Title:	Further Discussion on IoT-NTN TDD mode
Document for:	Discussion and Decision

Conclusion
In this contribution, we have further discussed the IoT-NTN TDD mode. And we make the following observations and proposals:
Impacts of invalid subframes within the PDCCH monitoring window:
Proposal 1: It is RAN2’s understanding that the issue of UE behaviour within the invalid subframes within the PDCCH monitoring window will be solved mainly (or completely) by RAN1. 
Impacts on MAC timers in units of subframes:
Proposal 2: RAN2 to confirm that the legacy HARQ RTT timer is set based on scheduling, and no additional enhancement is needed for IoT-NTN TDD. 
Scheduling and transmission of the SI message:
Observation 1: The Postponement of a channel when it overlaps with non-U/D NB-IoT subframes may make the system timing relationship complicated and ambiguous.
Observation 2:  UE behaviour is unclear and cannot be specified from the spec perspective if the SI window is postponed to the next valid DL subframe.
Observation 3:  Dropping (full or partial) of SI windows when they overlap with non-valid DL NB-IoT subframes has impacts on system performance. 
Observation 4:  Dropping (full or partial) of SI windows when they overlap with non-valid DL NB-IoT subframes may cause complicated UE behaviour. 
Observation 5: New periodicities based on the TDD frame and/or the hyper TDD frame can save the issue of the SI window and all other resource overlap with the non-valid DL/UL subframe and have limited spec impacts on the resource calculation formula. 
Proposal 3: Introduce new periodicities based on the time unit of the TDD frame and/or the hyper TDD frame to decide the SI window and SI transmission resource.  
Proposal 4: Send LS to RAN1 to indicate RAN2 agreements on scheduling of the SI window and SI transmission resource.

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

Agenda Item:	8.17
Source:	NEC
Title:	SI transmission for IoT-NTN TDD mode
Document for:	Discussion, Decision

Conclusion and Proposal
We have the following proposals:

Proposal-1: The other SI-message transmission can be postponed to the next valid D NB-IoT subframe within the SI-Window.
Proposal-2: A proper configuration based on network implementation ensure no overlapping between the postponed transmission and the other repetitions in the next TDD radio frame within the SI-Window.  Or otherwise, the postponed transmission from the first radio frame to the second radio frame should be discarded by the network to avoid its overlapping with the other repetitions.

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

Agenda Item:	8.17
Source: 	CATT
Title: 	Discussion on support of NB-IoT NTN TDD
Document for: 	Discussion and Decision

Conclusion
In this contribution, the issue of RAN2 impact of TDD is discussed, with the following proposals:
Proposal 1: RAN2 follows the agreement of RAN1 for the MIB-NB and SIB1-NB transmission in NB-IoT NTN TDD mode, and discusses whether to capture the UE behavior in TS 36.331 that the UE skips the reception of MIB/SIB1-NB in a non-D NB-IoT subframe, even if the subframe is determined as the subframe used to broadcast MIB-NB and SIB1-NB per the current Spec. 
Proposal 2: RAN2 confirms the understanding that the scheduling and transmission of SI (other than MIB/SIB1) should be postponed in the subframe which is determined for the SI transmission according to the current specification but is a non-D NB-IoT subframe. 
Proposal 2a: RAN2 clarifies whether to capture the below UE behavior in the transmission procedure of other SIs in TS 36.331: UE skips the reception on a non-D NB-IoT subframe, even if the subframe is determined as the subframes used to broadcast an SI (other than MIB and SIB1) per the current Spec.
Proposal 3: If a PUR/UL SPS occasion determined as per current Spec is overlapped with non-U subframe, RAN2 confirms which understanding is correct w.r.t. the agreement on postponing the PUR/SPS resources:
Understanding 1: The PUR/UL SPS occasion is not considered as a valid UL grant, and no MAC PDU for new transmission is obtained from the MUX entity for this PUR/UL SPS occasion. 
Understanding 2: A MAC PDU for new transmission is still obtained and stored in the corresponding HARQ buffer for this PUR/UL SPS occasion, but the HARQ entity does not really perform the transmission of this MAC PDU on this specific occasion (so the transmission of the stored MAC PDU is delayed to later PUR/SPS UL grants with real UL NB-IoT subframe).

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

Agenda Item:	8.17
Source:	OPPO
Title:	Discussion on IoT NTN TDD mode
Document for:	Discussion, Agreement

Conclusion
Based on the discussion we propose the following:
In NTN TDD mode, for parameter nB, only values of oneSixteenthT and oneThirtySecondT T are supported.
In NTN TDD mode, legacy NB-IoT SI scheduling mechanism is used. When the determined SI message transmission subframe is not a valid downlink subframe, the SI message transmission is postponed to the nearest valid downlink subframe.
In NTN TDD mode, it is up to network to configure si-Periodicity and si-WinfowLength, with proper values to avoid collisions between SI message transmission.
In NTN TDD mode, for si-RepetitionPattern, only a value of every16thRF is supported.
In NTN TDD mode, UE is configured with a (starting) subframe id within the 8 UL NB-IoT subframes for all UL SPS transmissions.
In NTN TDD mode, UE doesn’t start onDurationTimer within the UL segmented transmission gap.

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

Title:	IoT-NTN TDD mode SI scheduling and UE procedures
Source: 	Iridium, CCL
Document for:	Discussion and Decision 
Agenda Item:	8.17

Conclusion
In this contribution, we discussed the impact of IoT-NTN TDD mode on associated RAN2 procedures. The NPDCCH scheduling aspect is still under discussion in RAN1, but based on RAN1#120bis agreements we can assess the impact on RAN2, including any required ASN.1 changes. Our observations and proposals are listed below:
Observation 1: When operating in IoT-NTN TDD mode, the SIB1 repetition of 16 radio frames works even with the maximum allowed transport block size of 680 bits with adequate link budget margin of 3.91 dB and 4.51 dB for LEO-600 and LEO-1200 respectively.
Observation 2: When operating in IoT-NTN TDD mode, SIB1 repetition pattern should be configured as 16 radio frames to allow every alternate active downlink opportunity to carry SIB1 subframes for optimal SIB1 decoding performance and acquisition time.
Observation 3: When operating in IoT-NTN TDD mode, with SIB1 repetition pattern of every 16 RFs, maximum delay in receiving SIB1 is 2520ms. 
Observation 4: With the IoT-NTN TDD mode frame pattern, it is possible for the SI window start time to fall within the inactive downlink period.
Observation 5: With IoT-NTN TDD mode frame pattern, it is not possible to transmit all 8 subframes of SI transport blocks within a single downlink active time opportunity when SI TBS is greater than 120 bits.
Observation 6: With the IoT-NTN TDD mode frame pattern, postponement of the transmission of SI transport block to the next downlink active time can result in overlap with the transmission of the next SI repetition when N=9 and SI repetition pattern is configured as lower than every 16th radio frame.
Observation 7: With the IoT-NTN TDD mode frame pattern, postponement of the transmission of SI transport block to the next downlink active time results in no overlap when N=9 and the SI repetition pattern is configured as every 16th radio frame.
Observation 8: With IoT-NTN TDD mode frame pattern, the postponement of transmission of SI transport block to the next downlink active time can result in SI transmission in the subframes outside of the configured SI window.
Observation 9: In IoT-NTN TDD mode, if NPDCCH period scaling is agreed in RAN1, it can be specified as a fixed value in RAN1 specification.
Proposal 1: When operating in IoT-NTN TDD mode, there is no need to update the SIB1 scheduling mechanism in the existing specifications, except for disabling transmissions during downlink inactive time.
Proposal 2: In IoT-NTN TDD mode, if start of the SI window falls within the downlink inactive time, it shall be postponed to the next downlink active time.
Proposal 3: In IoT-NTN TDD mode, subframes from a single repetition of the SI transmission shall be allowed to be postponed to the next downlink active time opportunity.
Proposal 4: In IoT-NTN TDD mode, SI transmissions shall be truncated if, due to the proposed postponement, they overlap with the transmission of the next SI repetition within the SI window.
Proposal 5: In IoT-NTN TDD mode, SI transmission shall be truncated if, due to the proposed SI transmission postponement, it overflows the configured SI window length.
Proposal 6: In IoT-NTN TDD mode, by making modifications to the SI scheduling mechanism, all SI messages can be delivered to the UE. This can be achieved by updating 36.331 §5.2.3a as follows:
1> if the UE is a NB-IoT UE: 
2>	receive and accumulate SI message transmissions on DL-SCH from the start of the SI-window and continue until the end of the SI-window whose absolute length in time is given by si-WindowLength, starting from the radio frames as provided in si-RepetitionPattern and in subframes as provided in downlinkBitmap, or until successful decoding of the accumulated SI message transmissions excluding the subframes used for transmission of NPSS, NSSS, MasterInformationBlock-NB/ MasterInformationBlock-TDD-NB, and SystemInformationBlockType1-NB, and in the IoT-NTN TDD mode excluding subframes outside of active downlink time. If there are not enough subframes for one SI message transmission in the radio frames as provided in si-RepetitionPattern, the UE shall continue to receive the SI message transmission in the radio frames following the radio frame indicated in si-RepetitionPattern;
     In the IoT-NTN TDD mode, if postponement of SI subframes due to downlink inactive time results in overlap with the subframes of the next SI repetition, or falls outside SI window, SI transmission should be truncated to the last non-overlapping subframe or last subframe within the SI window.

Proposal 7: In IoT-NTN TDD mode, there is no need to introduce additional NPDCCH ASN.1 configuration parameter.
Proposal 8: For IoT-NTN TDD mode, update the RRC ASN.1 IE NPRACH-ConfigSIB-NB to include new NPRACH periodicities of 90ms and 180ms.
Proposal 9: For IoT-NTN TDD mode, add a note to RRC ASN.1 parameters description that NPRACH periodicity of 40ms and 80ms are not supported if the new ASN.1 only provides additional periodicities instead of full supported set.
Proposal 10: In IoT-NTN TDD mode, The RA-RNTI should be calculated based on the SFN of the first radio frame in which the Random-Access Preamble is transmitted after the postponement, not the actual occurrence of the NPRACH opportunity.
Proposal 11: In IoT-NTN TDD mode, for MAC timers specified in NPDDCH periods, invalid subframes are considered part of the timer duration, just like the legacy NB-IoT FDD. In IoT-NTN TDD mode, it is assumed that minimum allowed NPDCCH period value is 64ms.
Proposal 12: A description of IoT-NTN TDD mode shall be added in 36.300 [§5] as follows:
Downlink and uplink transmissions are organized into radio frames with 10 ms duration. Three radio frame structures are supported:
- Type 1, applicable to FDD and IoT-NTN TDD;
- Type 2, applicable to TDD;
…
For IoT-NTN TDD mode, Frame Structure Type-1 is used where uplink and downlink transmissions are separated in the time domain and constitute of set of D non-overlapping usable contiguous DL subframes and set of U usable contiguous UL subframes separated by fixed guard period (GP) as per Figure 1. This pattern is repeated every N radio frames. The values of N, D, U, [TBD for GP and start subframe for D] are fixed per IoT-NTN TDD band specified in [TBD]

Proposal 13: Anchor carrier definitions in 36.300 §3 needs updating:
Anchor carrier: in NB-IoT, a carrier where the UE assumes that NPSS/NSSS/NPBCH/SIB-NB for FDD and IoT-NTN TDD or NPSS/NSSS/NPBCH for TDD are transmitted.

Proposal 14: In 36.300 §23.21 should be updated to reflect that NTN is applicable to both FDD and IoT-NTN TDD system:
In this release of the specification, NTN is only applicable to FDD and IoT-NTN TDD system.

Note: As per RAN2 VC instructions after the RAN2 #129 [5], the rapporteur of IOT NTN TDD WI has submitted the above three proposals for consideration into RAN1 120-bis and again into RAN1 121,  and the above three proposals brought up here are simply for completeness.

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

Agenda item:		8.17
Source:		Lenovo
Title:		DL and UL impacts of TDD pattern in IoT NTN
Document for:		Discussion

Conclusion
In this contribution we discuss issues and potential solutions in cell barring, cell reselection and operation information exchange for S&F operations in IoT NTN. The following proposal are provided:
Proposal 1: UE in IDLE determines the timing of SIB31 acquirasion based on the DL active time derived from the TDD resource configuration.
Proposal 2: UE in IDLE only monitors for SIB31 reception at the DL active time opportunities or subframes derived from the TDD resource configuration.
Proposal 3a: For UE in CONNECTED, if current ephemeris expires within DL inactive duration (or a non-D subframe), UE may start SIB31 acquirasion before current ephemeris expiration considering DL active time opportunities or subframes.
Proposal 3b: For UE in CONNECTED, if the expiration timing of the configured T318 is within DL inactive duration (or a non-D subframe), UE can continue SIB31 acquirasion considering DL active time opportunities or subframes delaying RLF.
Proposal 4: RAN2 to discuss how to handle an UL reporting triggered at a non-U subframe based on TDD resource configuration.

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

Agenda Item:	8.17
Source:	Toyota ITC
Title:	Discussion on IoT-NTN TDD mode
Document for:	Discussion and Decision

Conclusion
This contribution discusses IoT-NTN TDD mode. Observation and proposals are summarized as follows: 
Observation 1: There is currently no definition for the IoT-NTN TDD mode, but such a definition is necessary for all impacted specifications.
Observation 2: The UE capabilities have not yet been addressed.
Observation 3: The indication of the enabling/activation and disabling/deactivation of the feature has not been discussed yet.
Proposal 1: Include the N value in the indication from the network side for the sake of future proofness, even if it has a fixed value in Release 19.
Proposal 2: Separate the indication of restrictions from the N value with its own indicator from the network side.
Proposal 3: Introduce the following definition for IoT-NTN TDD mode in the impacted RAN2 specifications:
IoT-NTN TDD mode: allows use of NB-IoT channels with TDD mode for NTN with fixed values of D non-overlapping usable contiguous DL subframes and set of U usable contiguous UL subframes separated by fixed guard period.
Proposal 4: In TS 36.306, all the Rel-17 and Rel-18 UE capabilities or optional features without UE capability that are applicable in NTN NB-IoT are also applicable in IoT-NTN TDD mode.

Proposal 5: Add a statement in TS 36.306 reflecting that the UE capabilities that apply in TDD do not apply in IoT-NTN TDD, unless otherwise stated.

Proposal 6: RAN2 to agree on one of the two options below for IoT-NTN TDD mode:
Option 1: UE radio access capability parameter signalled and corresponding to a field in RRC (specified in clause 4 of 36.306).
Option 2: Optional feature without UE radio access capability parameters (specified in clause 6 of 36.306).

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

Agenda Item:	8.17
Source: 	Huawei, HiSilicon
Title: 	Discussion on RAN2 impacts of IoT-NTN TDD
Document for:	Discussion and Decision

Conclusion 
The observations and proposals made in this contribution are summarized below:

Impacts on SI
Proposal 1: NPDSCH for SI messages other than SIB1-NB should be mapped on NB-IoT DL subframes.
Proposal 2: For the SI reception within an SI-window, UE should prioritize the previous SI reception in case there is collision between the previous SI repetitions and the subsequent SI reception.  

Impact on Measurement
Proposal 3: Measurement such as GNSS measurement and inter-frequency neighboring cell measurement can be performed during the period outside the serving cell's available UL and DL subframes to avoid interfering the normal data transmission during the serving cell’s available UL and DL subframes.

3GPP TSG-RAN2#130										                             R2-2504082
St.Julians, Malta, May 19th – 23rd , 2025   
                         
Source: 			ZTE Corporation, Sanechips
Title: 	                  Consideration on IoT- NTN TDD mode
Agenda item:	      8.17
Document for:       Discussion and Decision

Conclusion
The following observations and proposals are made: 
Observation 1: In TS 36.321 specification, the length of timer in unit of PDCCH periods is defined as number of PDCCH-subframes.
Observation 2: In TS 36.321 specification, the PDCCH-subframe for NB-IoT is defined as all NB-IoT downlink subframes.
Observation 3: Based on the IoT NTN TDD work item, the PDCCH-subframe definition for NB-IoT UE also applies to IoT NTN TDD UE.
Observation 4: If IoT NTN TDD supports same coverage enhancement level(e.g. UL with maximal 128 repetitions and DL with maximal 2048 repetitions), some of the existing value range of Timer with unit of ms or seconds(e.g. T300, T301, T311,T-PollRetransmit) will be insufficient and need to be extended(e.g. extended to 4 times of legacy TDD value).
Observation 5: Based on the RAN1 agreement, the legacy coverage enhancement level (e.g. DL with maximal 2048 repetitions) can not be provided in IoT NTN TDD.
Observation 6: si-WindowLength extension is not necessary for IoT NTN TDD.
Observation 7: Kmac is used by the UE for UP timers adjustment, which is a cell specific value for idle/inactive UEs. The extended Kmac values cannot be used by legacy UEs, which could lead to misunderstanding between NW and UE on the timers status (RAR window, contentionResolutionTimer and etc.), thus lead to failed scheduling/transmission. 

Proposal 1: For timer in unit of PDCCH periods, the definition in existing specs is clear enough, not need for further clarification.
Proposal 2: RAN2 assumes not extension is needed on the value range of timer in unit of ms or s for IoT NTN TDD. This assumption can be revisited if RAN1 provides the exact overage enhancement level(e.g. the maximal repetitions number) that is supported in IoT NTN TDD system.
Proposal 3: For the timer of ra-ResponseWindowSize and mac-ContentionResolutionTimer, the absolute value limitation for TDD (i.e., 20.48s) is used for IoT NTN TDD.
Proposal 4: For RA-RNTI calculation in IoT NTN TDD, H-SFN is considered and carrier id is not considered. 
Proposal 4a: For RA-RNTI calculation in IoT NTN TDD, the NB-IoT TDD RA-RNTI calculation is used as baseline.
Proposal 5: RAN2 discusses whether to use floor (SFN_id/4) or floor(SFN_id/9) in RA-RNTI calculation. If floor(SFN_id/9) is used, then RA-RNTI = 1 + floor(SFN_id/9) + 114*(H-SFN mod 2), otherwise RA-RNTI = 1 + floor(SFN_id/4) + 256*(H-SFN mod 2).
Proposal 6: Use the existing terminology “the first radio frame of the specified PRACH” and “the first hyper frame of the specified PRACH” for RA-RNTI calculation. 
Proposal 7: Define value range with multiple 90ms for si-RepetitionPattern, e.g. with value range of every9thRF, every18thRF, every36thRF etc.
Proposal 8: SI transmission can be dropped in non-D NB-IoT subframes, and the SI-Window determination can follow the legacy NB-IoT mechanism.
Proposal 9: It is up to NW implementation to avoid SI-window overlap.
Proposal 10: UE drops the non-DL subframes for SC-PTM reception.
Proposal 11: Kmac extension value of 512ms to 1023ms does not apply to NR NTN and legacy IoT NTN.
Proposal 12: NPDCCH monitoring issue can wait for more progress in RAN1.

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


Agenda item:	8.17
Source:	Samsung
Title:	On RAN2 aspects of IoT NTN TDD
WID/SID:	IoT_NTN_TDD
Document for:	Discussion and Decision

Conclusion
In this contribution, we provided some proposals on IoT NTN TDD:
Proposal 1: RAN2 agrees to down-prioritize enhancements on GNSS measurement gap for IoT NTN TDD. 
Proposal 2: RAN2 agrees current value ranges of NB-IoT timers (in PDCCH periods and in absolute time) are sufficient for practical deployments for IoT NTN TDD. 
Proposal 3: Extended k-Mac is mandatory for UEs supporting IoT NTN TDD band(s). 
Proposal 4: Extended k-Mac is indicated to be supported as a mandatory feature of IoT NTN TDD in 36.306. FFS how the IoT NTN TDD feature is captured in 36.306. 
Proposal 5: The extended k-Mac is introduced by introducing a new value and not configuring the legacy k-Mac. 
Proposal 6: Take the RRC implementation example in Appendix 5.1 as a baseline.  

3GPP TSG-RAN WG2 Meeting #130                                    	R2-2504320
St. Julians, Malta, 19 - 23 May 2025                 	 
	 
Agenda item:	8.17
Source:	Qualcomm Incorporated
Title:	Discussion on new NB-IoT NTN TDD mode
Document for:	Discussion and Decision

Conclusion
Following proposals are made:
Proposal 1	RAN2 assume the cell with new TDD frame structure is called NB-IoT NTN TDD cell.
Proposal 2	Discuss whether to introduce new SIB1 scheduling information in MIB-NB in the new TDD mode cell.
Proposal 3	The SI message repetitions falling on the invalid DL subframes are postponed to the next valid DL subframes within a SI window.
Proposal 4	The SI scheduling information is not changed and discuss how to make sure the SI window length includes enough valid DL subframes required for the SI message repetitions.
Proposal 5	The remaining paging repetitions falling on the invalid DL SFNs are postponed to the next valid DL SFNs.
Proposal 6	Network configures the gap between two POs (i.e., parameter NB) to be sufficiently long such that it includes enough number of valid DL subframes for NumRepetitionPaging-r13.
Proposal 7	When the start of the paging is postponed to the next valid DL SFN, clarify which subframe the UE should monitor the paging.
Proposal 8	Introduce a new list of neighbor cells operating in TDD mode for measurements and cell reselection.
Proposal 9	Discuss how to provide the UEs with timing information of neighbor cell that is operating in NB-IoT TDD mode for measurements.

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

Agenda item:		8.17
Work Item:			IoT_NTN_TDD
Source:	Nordic Semiconductor ASA
Title:					On SI scheduling, postponing impacts, and early implementation of the IoT-NTN TDD mode
Document for:		Discussion and Decision

Conclusions
In this paper, we discussed IoT-NTN TDD mode SI scheduling impacts and H-SFN change impact with IDLE mode eDRX. Our observations and proposals are listed below:
SI Scheduling:
Observation-1: A transmission of one “other SI” message always takes two 90ms TDD frames.
Observation-2: Postponing of other SI subframes to the next 90ms TDD frame is required.
Proposal-1: When operating in IoT-NTN TDD mode the scheduling mechanism of SIB1-NB remains unchanged.
Proposal-2: The SIB1-NB subframes that fall into “non-D NB-IOT subframes” are plain dropped.
Proposal-3: The scheduling procedure of other SI messages remains unchanged. 
Proposal-4: Postponing of other SI subframes to the next 90ms TDD frame is supported. 
Proposal-5: A network configuration shall ensure SI repetitions within a SI-window never overlap. 
Proposal-6: Other SI transmission that overflows a configured SI-window shall be truncated. 
Early implementation of the IoT-NTN TDD mode:
Observation-3: The UE capability of the IoT-NTN TDD mode is implicitly associated with the used TDD band. 
Observation-4: The network capability of the IoT-NTN TDD mode is implicitly associated with the used TDD band. 
Observation-5: The Rel-19 IoT-NTN TDD mode can be implemented on top of Rel-17.
Observation-5: There is no UE IoT-NTN TDD mode capability or band support ambiguity from the network point of view, since supporting UEs are only being served on specific IoT-NTN TDD mode bands.
Observation-6: The Rel-19 IoT-NTN TDD mode can be implemented on top of Rel-17.
Proposal-7: Document in 3GPP TS36.331 Annex G that Rel-19 IoT-NTN TDD mode is early implementable feature starting from Rel-17. 

3GPP TSG RAN WG2 Meeting #130	R2-2504395
St.Julians, Malta, May 19th – 23rd, 2025
Agenda Item:	8.17
Source:	CMCC	
Title:	Support of IoT-NTN TDD mode
Document for:	Discussion, Decision

Conclusion
Based on the discussions mentioned above, in this contribution we provide some discussions on IoT-NTN TDD mode and have the following proposals:
Observation 1: Compared to the new IoT-NTN TDD pattern, there might be much shorter/fewer invalid subframes for legacy NB-IoT.
Proposal 1: Kindly suggest RAN2 to add clarification that it is up to UE implementation to suspend the timers in invalid DL subframes duration and resume when valid subframes occur. 
Proposal 2: No need to extend the k-Mac for IoT NTN and NR NTN.
Proposal 3: It is proposed that if the NB-IoT NTN system operates in TDD mode, the HARQ feedback is disabled by default, and to be simple, we could just add related description in TS 36.300.
Proposal 4: Starting time of SI-window needs to consider the new TDD pattern.
Proposal 5: It is proposed that measurement gap configuration enhancements (e.g introduction of new measurement gap repetition period values) could be discussed to match the new TDD pattern.

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

Agenda item:	8.17
Source:	Nokia, Nokia Shanghai Bell
Title:	Further discussion on support of TDD mode for IoT-NTN
WID/SID:	IoT_NTN_TDD - Release 19
Document for:	Discussion and Decision
1	

Conclusion
This document has made the following observations:
Observation 1: The 8 DL subframes of a DL occasion may have insufficient capacity to carry RAR for all UEs transmitting a preamble in the preceding UL occasion.
Observation 2: The time separation between an UL and a DL occasion in the NB-IoT TDD NTN frame structure is about 25 ms.
Observation 3: The RAR window may occur primarily during the UL-DL occasion gap if the start of the window is based on UE-eNB RTT.
Observation 4: The Contention Resolution timer may run primarily during the UL-DL occasion gap if the start of the timer is based on UE-eNB RTT.
Observation 5: RAN4 has agreed measurement requirements are applicable if the UE is provided with information on the active periods of the neighbour cells configured for the measurements.
Observation 6: when multiple UEs postpone their PUR/SPS resource to the next valid UL subframe there may be collisions between different UEs. 
And proposed the following:
Proposal 1: The start of the RAR window and Contention Resolution timer shall be aligned with the start of the DL occasions, when the UE-eNB RTT is shorter than the UL-DL gap.
Proposal 2: RAN2 to discuss how to provide assistance information on the active periods of the neighbour cells configured for measurements.
Proposal 3: RAN2 to discuss reusing the AS operation from GNSS measurement gap for RRC Connected UE working in NB-IoT TDD NTN, except the neighbor cell measurement which is possible outside the serving cell’s UL-DL pair.
Proposal 4: RAN2 to discuss handling of the PUR & SPS postponement including postponement to another valid UL subframe to avoid UL collision between different UEs.
Proposal 5: RAN2 to discuss how to provide SI other than SIB1-NB, for example by use of dropping or postpone NPDSCH.
Proposal 6: leave it to network implementation to ensure NPDSCH carrying a SI message is not postponed appearing in a next SI window (i.e. SI window for a different SI message) if NPDSCH carrying SIB-NB is postponed.   
Proposal 7: RAN2 to introduce a drx-Cycle value which is aligned with the 90 ms TDD frame periodicity.

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

Agenda Item:	8.17
Source:	THALES
Title:	Discussion on support of IoT-NTN TDD mode
Document for:	Discussion

1	

Conclusion
In this contribution, the following observations and proposals was provided:

It is possible to align the beginning of the first SI-Window with a D subframe, but the others SI-Windows may not be aligned with a D subframe because si-Periodicity available configurations can not align with the 90 ms periodicity of the frame structure
Within a SI-Window, the transmission of SI w.r.t repetition pattern may not occur all the time in a D subframe and for some configurations, it may not occur at all for a given SI-Window length
The scheduling procedure of other SI messages remains unchanged
The SI-message transmission can be postponed to the next valid D frame within the SI-Window
Down select one of the transmission options when SI transmissions overlap:
Option 1: If an SI transmission corresponding to a first radio frame according to si-RepetitionPattern overlaps (after postponing) with a second radio frame according to si-RepetitionPattern, the remaining repetitions corresponding to the first radio frame are dropped
Option 2: If an SI transmission corresponding to a first radio frame according to si-RepetitionPattern overlaps (after postponing) with a second radio frame according to si-RepetitionPattern, the repetitions corresponding to the second radio frame are dropped and the repetitions corresponding to the first radio frame are not dropped
At most 6 SF are available in D frame for a SI-message transmission, while for TBS>120 bits, SI-message are transmitted with 8 SFs
For the SI transmission D frame overflow case with a collision with the next SI transmission, down select one of the transmission option:
Option a: truncate the remaining SF of the last SI transmission
Option b: truncate the firsts SF of the new SI transmission
RAN1 still discuss the NPDCCH postponing handling due to invalid subframes
No clarification needed to take into account impact of invalid subframes on NPDCCH periods