3GPP TSG RAN WG1#120-bis			 								                R1-2501724
Wuhan, China, April 7th – 11th, 2025	

Agenda Item:	9.11.5	
Source:	Thales
Title:	Discussion on IoT-NTN TDD mode
Document for:	Discussion and decision

Conclusion
In this contribution. we made the following observations and proposals:
Definition of TDD pattern
Proposal 1 
For NB-IoT NTN TDD operation in 1616-1626.5 MHz MSS band the DownlinkToUplinkGuardPeriod which indicates the downlink to uplink guard period for TDD operation is fixed in the specifications to be 50 subframes at the ULSRP.
Frame structure for NB-IoT NTN TDD mode
Proposal 2 
In IoT NTN TDD, NB-IoT NTN TDD downlink subframe is a subframe that is within the downlink transmission occasions (D=8) of the TDD pattern. 

SIB1-NB scheduling in IoT NTN TDD mode
Observation 1
With NB-IoT NTN TDD mode of operation with N=9, the number of available instances of SIB1-NB within 256 radio frames period would be enough, at least when SIB1-NB sequence is repeated 16 times.
Proposal 3
For N=9, D=8, RAN1 concludes that SIB1-NB reception following current specifications is feasible for all SIB1-NB TBS values supported by the specifications for SIB1-NB, at least when the configured number of repetitions is 16. 
Proposal 4
SIB1-NB transmissions are dropped in non-D NB-IoT subframes. 
Other SI scheduling in IoT NTN TDD mode
Observation 2
In NB-IoT NTN TDD mode of operation with N=9 and nrOfDownlinkSubframes=8, a single SIB2-NB may span two consecutive DL transmission periods when SIB2-NB is transmitted in 8 consecutive valid subframes. 
Observation 3
In NB-IoT NTN TDD mode of operation, the actual DL transmission period may not coincide with the first radio frame for SI message transmission in the SI window indicated by si-RadioFrameOffset.
Observation 4
For SI other than SIB1, the simulation results indicate that both alternatives (Alt1 and Alt2) discussed at the RAN1#120 meeting present the same NPDSCH SI decoding performance.
NPDCCH analysis
Proposal 5
NPDCCH/Search space candidate is postponed to the next DL transmission occasion if it coincides with non NB IoT NTN TDD downlink subframe.  
search space candidates are not postponed beyond the end of the corresponding search period T

Proposal 6
A scaling factor F is introduced to expand the search period T as follows: T= Rmax *G*F
F = 11.5

NPDSCH transmission
Proposal 7
The UE shall not expect NPDSCH in subframe if it is not a NB-IoT NTN TDD downlink subframe. 
Note: a subframe is assumed as a NB-IoT NTN TDD DL subframe if it is within a DL transmission occasion.

Proposal 8
NPDSCH transmissions that could not be completed within a DL transmission occasion, are postponed until the next transmission occasion, except for transmissions of NPDSCH carrying SIB1-NB in subframes 3 and 4 for frame structure type 1.

Proposal 9
In NB-IoT NTN TDD, the periodicity of a DL transmission gap is configured using a new parameter dl-GapPeriodicity-r19: 
dl-GapPeriodicity-r19 = dl-GapPeriodicity-13 * F
F = 11.5

NPRACH analysis:
Observation 5
The P symbol groups are transmitted in a time contiguous manner, therefore, only preamble Format 0 and preamble Format 1 with preamble repetition unit (ms) of 5.6 and 6.4 ms respectevly could be supported in IoT NTN TDD with D and U= 8ms.
Observation 6
For a 1% miss detection rate of the NPRACH, the min required SNR is equal to:
15.1 dB for single NPRACH repetition unit received
10.6 dB for 2 NPRACH repetition units received during a 2x9 radio frames period


Proposal 10
The existing nprach-Periodicity values can be utilized for NB-IoT NTN TDD, with the exception of the nprach-Periodicity of 40ms, which should be avoided.

Proposal 11
NPRACH transmissions are postponed in non-U NB-IoT subframes until the next U NB-IoT subframe(s)
The unit of postponement is PRU

NPUSCH transmission
Proposal 12
Confirm the following working assumption
Working assumption
Uplink transmission gaps do not apply in NB-IoT NTN TDD.

Segmented pre-compensation
Proposal 13
For segmented pre-compensation, support Option 2 with the following revision: A new pre-compensation segment is started at the beginning of each uplink transmission occasion (i.e. 8 U subframes)

Kmac value range extension
Proposal 14
Support Kmac_r19 with value range 1 – 1023 ms
Appendix I

UE DL synchronization evaluation results
The required SNR (dB) for NPSS, NSSS and NPBCH is determined through link level simulation by considering the following simulation parameters as agreed in RAN1#118bis:
Reference scenario: LEO set-1 
Standalone deployment with anchor carrier (i.e. operating in carrier(s) used only for NB-IoT)
TDD pattern: Respectively 1 Tx and Rx opportunity within 9 radio frames.
Power class 3 user equipment (23 dBm Tx power, 0 dBi antenna gain)




NPSS detection performance
A set of simulations is performed to simulate the initial cell search scenario with a carrier offset of 55 kHz, a Timing drift of -34ppm (24 ppm due to Doppler and 10 ppm due to UE XO). Those values are consistent for a 1.6265 GHz carrier.
The NPSS is detected using a two-step method: an auto-correlation at a sampling rate of 240 kHz, followed by a cross-correlation at a sampling rate of 1.92 MHz.
Two types of NPSS detection are simulated:
Single shot detection. The auto-correlation peak over a single 90 ms period is selected. Its timing is then compared to the actual NPSS timing.
Detection by recombining 4 NPSS subframes. After combining auto-correlation metrics of the latest 4 * 90 ms period, the auto-correlation peak is selected. Its timing is then compared to the actual NPSS timing.
The following figure shows the NPSS miss detection rate. The coarse synchronization at 240 kHz is considered successful if the NPSS is detected within +/- 5 samples, i.e., +/- 21 µs, of the actual NPSS timing.

 
Figure 11: NPSS miss detection rate
Based on simulation results we have the following observation on NPSS detection performance:

Observation 1
For a 1% miss detection rate of the NPSS, the min required SNR is equal to:
3.7 dB for single NPSS received
-3.8 dB for 4 NPSS received during a 4x9 radio frames period

NSSS detection performance
A set of simulations is performed assuming that the carrier phase has also been perfectly recovered after NPSS detection. Another set of simulations is performed with a random carrier offset – uniform distribution over 2 * π. That is to simulate the case of an inaccurate carrier phase detection after NPSS detection.
A single NSSS subframe is used to decode the NSSS information. The NSSS decoding is considered as successful if both the cell ID and the radio frame number modulo 8 are correctly estimated.

The following figure shows the NSSS miss detection rate.

Figure 12: NSSS miss detection rate

Based on simulation results we have the following observation on NSSS detection performance:
Observation 2
For a 1% miss detection rate of the NSSS, the min required SNR is equal to -2.8 dB 

NPBCH decoding performance
For the evaluation MIB decoding performance, no frequency, phase or time offsets are considered. Perfect frequency, phase and time recovery are assumed using the NPSS, NSSS and NRS signals.
Over a 640 ms MIB window, 7 MIB suframes or 8 MIB subframes may be received, depending on the phasing between the 640 ms MIB window and the 90 ms period. The usual case is 7 MIB suframes available in a 640 ms window.
A set of simulations is performed to assess the performance of MIB decoding using only one MIB subframe. Another set of simulations is performed combining 7 MIB subframes. The MIB decoding is considered as successful if all the MIB bits are correctly decoded.
The following figure shows the NPBCH decoding performance.

Figure 13: NPBCH decoding performance

Based on simulation results we have the following observation on NPBCH decoding performance:
Observation 3
For NPBCH decoding with 1% BLER, the min required SNR is equal to:
-6.9 dB for a 640 ms window, with 7 MIB subframes received

Link budget analysis
The parameters used for Link budget calculation are the ones given in previous section.  Specifically, the following parameters are considered:
Frequency band: 1.6265 GHz
For LEO600 and LEO1200 scenarios, payload characteristics for DL and UL transmissions as given in section 6.2 of [4]
For LEO800, payload characteristics for DL and UL transmissions as given in section 4.1.1 of this contribution.
The same UE characteristics adopted in 3GPP TR 36.763 [4]: UE PC3 with antenna gain of 0dBi and NF of 7dB
A channel bandwidth of 180kHz up to 180 kHz with all permissible smaller resource allocations 12*15 kHz, 6*15 kHz, 3*15 kHz, 1*15 kHz, 1*3.75 kHz.
The following losses as per the TR 36.763 [2]:

For the uplink 3 dB additional loss due to beamwidth defined by HPBW at edge of the beam for LEO600km and LEO1200km are considered. The payload can compensate for such additional loss in case of LEO800km, thereby no additional is considered for LEO800km [3].
The target elevation angle: 27.0 deg for LEO600km, 26.3 for LEO1200km and 8.2 deg for LEO800km	
By considering the above parameters, an effective link budget analysis is performed to assess the overall performance of NPSS/NSSS and NPBCH detection/decoding and feasibility of operating with a new TDD mode for NB-IoT NTN.
The following table shows the CNR for the following satellite orbit/parameters sets: LEO600 Set1 and Set 1-2 LEO1200 Set1:
Table 6 Link budget for different satellite parameters sets and orbits

Based on the results of the Link budget for different satellite parameters sets and orbits, we have the following observation:
Observation 4
The DL Carrier-to-noise ratio (CNR) for LEO600, LEO1200 and LEO800 is shown in the following table: 


Summary of DL synchronization evaluation results
By comparing the required SNR (dB) determined through link level simulation and the CNR derived from the link budget calculations, we can determine the coverage margin for DL synchronisation signals and channel as depicted in the following table.
Tableau 2 Coverage margin for DL synchronisation signals and channel for different orbits 

Based on the evaluation of DL synchronization performance conducted in the previous sections, we have the following observations/conclusions:

Observation 5
No tangible impact observed due to the periodic pattern with N=9 radio frames on UE downlink synchronization

Observation 6
When operating in the new TDD mode for NB-IoT NTN, successful NPSS/NSSS/NPBCH detection/decoding can be achieved with an adequate coverage margin for the satellite parameter set1 and the LEO600 and LEO1200 orbits considered in 3GPP TR 36.763, and for orbit LEO800 with associated satellite parameter set.

On the assessment of downlink synchronization (NPSS/NSSS/NPBCH) for IoT-NTN TDD, RAN1#119 made the following observations. Other observations capturing company’s results could be found in the appendix.


Appendix II
RAN1#120 made the following agreements [11]:

RAN1#119 made the following agreements [10]:


 RP-243293, Revised WID on introduction of IoT-NTN TDD mode, Iridium Satellite LLC RAN Meeting #106, December, 2024
RP-242415 	New WID on introduction of IoT-NTN TDD mode, 3GPP TSG RAN Meeting #105, Melbourne, Australia, September 9-12, 2024
TR 38.811
R4-2404267 Motivation for Iridium NB-IoT, 3GPP TSG-RAN WG4 Meeting # 110-bis, April 2024
3GPP TR 36.763, Study on Narrow-Band Internet of Things (NB-IoT) / enhanced Machine Type Communication (eMTC) support for Non-Terrestrial Networks (NTN) (Release 17)
RP-241526, Potential Additional Enhancements to NB-IoT NTN, 3GPP TSG RAN Meeting #104, June 2024
R1-161981, “NB-PSS and NB-SSS Design (Revised)”, Qualcomm Incorporated, 3GPP TSG RAN WG1 NB-IoT Ad-Hoc Meeting, Sophia Antipolis, France, March 22-24, 2016
3GPP TR 38.811 V15.2.0 Study on New Radio (NR) to support non-terrestrial networks (Release 15)
RAN1 Chair’s Notes, 3GPP TSG RAN WG1 #118bis, Hefei, China, October 14th – 18th, 2024
RAN1 Chair’s Notes, 3GPP TSG RAN WG1 #119, Orlando, US, November 18th – 22nd, 2024
RAN1 Chair’s Notes, 3GPP TSG RAN WG1 #120, Athens, Greece, February 17th – 21st, 2025

3GPP TSG RAN WG1 #120bis                                                                                            R1-2501826
Wuhan, China, April 7th – 11th, 2025

Source:	vivo
Title:	Discussion on IoT-NTN TDD mode
Agenda Item:	9.11.5
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide our views on IoT-NTN TDD mode, and have the following observations and proposals.
Observation 1: For a NPRACH transmission across multiple UL bursts, the UE can adjust the uplink transmission timing by implementation before an uplink burst resource.
Observation 2: For a NPUSCH transmission across multiple UL bursts, the UE can adjust the uplink transmission timing by implementation before an uplink burst resource.
Proposal 1: No new TBS value for SIB1-NB is introduced in Rel-19.
Proposal 2: SIB1-NB is also dropped in non-D NB-IoT subframes.
Proposal 3: G of NPDCCH search space can be properly configured to avoid overlapping between different search space periods. No specification change (e.g., new scaling factor) is needed for NPDCCH monitoring.
Proposal 4: No further enhancement on DL gap is introduced.
Proposal 5: Confirm the working assumption that uplink transmission gaps do not apply in NB-IoT NTN TDD.
Proposal 6: The NPRACH transmission can be postponed based on the unit of PRU.
Proposal 7: Non-U NB-IoT subframes between two UL bursts can be regarded as an uplink transmission gap, after which UE can adjust the uplink transmission timing by implementation.

3GPP TSG RAN WG1 #120bis                                             	R1-2501884
Wuhan, China, 07th – 11th April 2025
Agenda Item:	9.11.5
Source:	Spreadtrum, UNISOC
Title:	Discussion on IoT-NTN TDD mode
Document for:	Discussion and decision

Conclusion
In this contribution, we provided views on IoT-NTN TDD mode. In summary, we have following observations and proposals:
RAN1 to discuss whether UE can receive 8 NPBCH blocks in one NPBCH period and if not, whether it would effect UE decode NPBCH and obtain MIB.
SIB1-NB transmissions are dropped in non-D NB-IoT subframes.
Not introduce new periodicities for NPDCCH monitoring.
Depending on network implementation, configured values for NPDCCH are valid.
Reuse legacy DL gap mechanism without any modification in NB-IoT NTN TDD.
NPRACH transmission are postponed in non-U NB-IoT subframes and the unit of postponement can be one symbol group or four symbol groups.
Confirm the working assumption: Uplink transmission gaps do not apply in NB-IoT NTN TDD.
Segmented pre-compensation does not apply for NB-IoT NTN TDD.

3GPP TSG RAN WG1 #120bis                                             R1- 2501903
Wuhan, China, April 7th – 11th, 2025
Source:	ZTE Corporation, Sanechips
Title:	Discussion on IoT-NTN TDD mode
Agenda Item:	9.11.5
Document for: Discussion

Conclusions
According to the analysis given above, we have the following observations and proposals:
Observation 1: RAN1 concludes that SIB1-NB reception following current specifications is feasible at least for some configurations.
Proposal 1: SIB1-NB transmissions are dropped in non-D NB-IoT subframes.
Observation 2: NPDCCH is only mapped to NB-IoT DL subframes. No need to introduce additional NB-IoT TDD-specific rules for handling non “NB-IoT DL subframes” for NPDCCH.
Observation 3: NPDCCH overlapping with non-D NB-IoT subframes will be postponed to NB-IoT DL subframes per current specification and agreement.
Observation 4: Current specifications have already defined rules to handle the overlap of NPDCCH search spaces. That is, the overlap of NPDCCH search spaces due to postponement can be handled by current specification and no need to match the periodicity of NPDCCH monitoring and TDD pattern.
Proposal 3: No need to introduce new NPDCCH monitoring periodicities.
Proposal 4: All the configuration values for NPDCCH can be kept to provide higher configuration flexibility and minimize spec effort. eNB can avoid the configuration of improper values (e.g., too large repetition number) up to implementation.
Observation 5: According to assumptions in study phase, the DL link budget is high and long DL repetition may not be needed. Enhancement on DL transmission gap is not necessary.
Proposal 5: No need to modify the mechanism of DL transmission gap for IoT-NTN TDD.
Proposal 6: NPRACH transmissions are postponed in non-U NB-IoT subframes until the next U NB-IoT subframe(s) and the unit of postponement should be preamble repetition unit.
Proposal 7: Introduction of new NPRACH periodicities is not necessary after adopting the option to postpone NPRACH transmission in non-U NB-IoT subframes to next U NB-IoT subframes.
Proposal 8: For segmented pre-compensation, adopt following option for IoT-NTN TDD mode.
Option 1: Dropped/postponed NPUSCH / NPRACH are counted for segment determination

3GPP TSG RAN WG1 #120bis                                            R1-2501976
Wuhan, China, April 7th – 11th, 2025 

Agenda Item:	9.11.5
Source:	CATT
Title:	Discussion on physical layer design of IoT-NTN TDD
Document for:	Discussion and Decision

Conclusion
Observation 1: When the start boundary of the D subframe is aligned with the start boundary of DL4, and the end boundary of the U subframe is aligned with UL4, the guard period is maximized at 48.62ms.
Observation 2: When the guard period is fixed at 48ms or 49ms, the UE cannot transmit at the subframe boundary.
Observation 3: When the transmission timing of Iridium and IoT NTN are aligned, the subframes [3 4 5 6 7 8 9 0] cannot be aligned with the DL slot of any slot pair.
Observation 4: Defining new periodicities for NPRACH may trigger a new NPRACH format, which would have significant impact on the specifications.
Observation 5: When the unit of postponement for NPRACH is a single symbol group, it disrupts the continuity of NPRACH transmission and affects detection performance.
Observation 6: In the IoT NTN TDD mode, there is no long uplink transmission, so segmented pre-compensation may not be necessary.

Proposal 1：The guard period should be fixed in the specifications to be [48, 49] ms at the ULSRP, no need 50ms configuration.
Proposal 2：There are two options for adjusting subframe timing to ensure that the DL and UL subframes remain within the original slot boundary:
Option 1: The network side sends parameters indicating the TA offset to the UE via the MIB message, and these parameters correspond to different slot pairs.
Option 2: The guard period is configured as an RRC parameter and broadcasted in the SIB message, with the offset being adjustable through common TA adjustment.
Proposal 3：In the IoT NTN TDD mode operation, SIB-NB is transmitted only on subframes defined as NB-IoT DL subframes, and the number of repeated transmissions is fixed at 8 or 16.
Proposal 4：When the NPDCCH candidates of a certain monitoring occasion collide with the ongoing NPDCCH candidates, postpone the NPDCCH candidates of that monitoring occasion without introducing a new NPDCCH periodicity.
Proposal 5：When the subframe of the starting radio frame of the DL GAP belongs to non-NB-IoT subframes, postpone the GAP until the next NB-IoT DL subframe.
Proposal 6：For IoT NTN TDD mode operation, NPRACH in non-NB-IoT UL subframes is postponed to the next NB-IoT UL subframes for transmission, with the unit of P symbol groups. 
Proposal 7：Segmented pre-compensation does not apply for NB-IoT NTN TDD.

3GPP TSG RAN WG1 Meeting #120-bis	R1-2502057
Wuhan, China, April 07 - 11, 2025

Title:	Remaining aspects of loT-NTN TDD mode
Source: 	Iridium, CCL
Type:	Discussion
Document for:	Decision 
Agenda Item:	9.11.5	

Conclusion
In this contribution, we have evaluated the remaining topics from RAN1#120 related to scheduling and timing aspect of downlink and uplink channels in NB-IoT NTN TDD mode with Half-Duplex FDD frame structure and provided our views on how it can work with minimal impact to the current NB-IoT specifications. We have also shared link level simulation results for the SI decoding performance. Our observations and proposals are listed below:
Observation 1: In IoT-NTN TDD mode, the postponement of the NPDCCH search space is restricted to the beginning of the next NPDCCH search space, maintaining a 4ms gap in accordance with the current NB-IoT specification (36.213 §16.6).
Observation 2: In IoT-NTN TDD mode, the smallest value of the NPDCCH period that is practically useful is 64ms when N= 9 and D = 8.
Observation 3: A NPDCCH period lower than 64 can impact procedures using MAC timer values defined in NPDCCH periods, such as the RAR window and other MAC timers. Therefore, a minimum NPDCCH period of 64 should be configured.
Observation 4: The existing set of NPDCCH configuration parameters is sufficient and can work for IoT-NTN TDD mode. Therefore, there is no need to introduce new NPDCCH configuration parameters.
Observation 5: In IoT-NTN TDD mode, a single NPRACH preamble repetition unit of P=5 symbols groups can fit in a single UL active time opportunity for NPRACH format 0 and format 1.  
Observation 6: In IoT-NTN TDD mode NPRACH repetition > 1 results in splitting of the repetition unit across UL active time opportunities. This results in the partial transmission of a symbol at the uplink active time boundaries and can have adverse impact on the receiver NPRACH decoding performance.
Observation 7: In IoT-NTN TDD mode, with NPRACH repetition > 1, whole preamble repetition unit consisting of P symbol groups should be transmitted in consecutive UL active time opportunities to improve receiver NPRACH decoding performance.
Observation 8: In IoT-NTN TDD mode, the existing set of NPRACH configuration parameters is sufficient and there is no need to introduce new NPRACH periodicity in multiples of 90ms.
Observation 9: In IoT-NTN TDD mode, when the downlink transmission gap is scaled up by a factor of 16, increased duration of the downlink gap in absolute number of subframes is sufficient to provide an effective transmission gap during downlink active subframes. The existing parameter set for calculating the downlink transmission gap duration is sufficient.
Observation 10: In IoT-NTN TDD mode, SI messages of all transport block sizes can be successfully decoded by receiving fewer than 16 subframes or two repetitions carrying the SI message at the LEO-600 and LEO-1200 operating point.
Observation 11: In IoT-NTN TDD mode, SI messages of all transport block sizes can be successfully decoded with a maximum of two repetitions, given a link margin of more than 3.81 dB for the LEO-600 operating point and 4.1 dB for the LEO-1200 operating point.
Proposal 1: In IoT-NTN TDD mode, minimum NPDCCH period (T) should be defined as  where   is the scaling factor. The scaling factor   when  and  allows minimum NPDCCH period of 64.
Proposal 2:  In IoT-NTN TDD mode, when the transmission of P symbol groups overlaps with a subframe which is not NB-IoT UL subframe, the start of the P symbol groups will be postponed to the next NB-IoT UL subframe.
Proposal 3: In IoT-NTN TDD mode, for any uplink segments not starting in a NB-IoT uplink subframe, time and frequency pre-compensation adjustment is postponed to the start of the next NB-IoT uplink subframe.
Proposal 4: In IoT-NTN TDD mode, the periodicity of the downlink transmission gap periodicity should be scaled up by a scaling factor F. A value of F=16 is effective.
Proposal 5: In IoT-NTN TDD mode, there is no need to have uplink transmission gaps during longer uplink transmissions.
Proposal 6: For the IoT-NTN TDD 1616-1626.5 MHz band, fix the time gap to 50ms from the end of the downlink active time to the start of the next uplink active time.

3GPP TSG RAN WG1 #120-bis															R1-2502059
Wuhan, China, April 7th – 11th, 2025 

Source:	Iridium
Title:	Stage 2 proposal (for RAN2 TS 36.300) for Introduction of IoT-NTN TDD mode
Release:	Release 19
Agenda Item:	9.11.5
Document for:	Agreement

Proposals below:

Proposal 1: A description of IoT-NTN TDD mode shall be added in 36.300 [section 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] are fixed per IoT-NTN TDD band specified in [TBD]

Figure 1 IoT-NTN TDD mode with HD-FDD frame structure


Proposal 2: Anchor carrier definitions in 36.300 [section 3.1] 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 3: In 36.300 [section 23.2.1] 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.
		
Proposed Draft LS on IOT NTN TDD TP for TS 36.300:

3GPP TSG RAN WG1 #120bis 	R1- 2502095
Wuhan, China, 7 – 11 April 2025
 

Agenda item:		9.11.5
Source:	Nokia, Nokia Shanghai Bell
Title:	Discussion on IoT-NTN TDD mode
Document for:		Discussion and Decision

Conclusion
In this contribution, we discussed our view on IoT NTN TDD mode. Our observations and proposals are as follows:
Observation 1: The set of contiguous UL subframe should cover all UE’s UL transmission with different differential delay.
Observation 2: The limited number of radio frames with contiguous UL subframes and contiguous DL subframes may impact the DL synchronization and cell search.
Observation 3: maximum number of NPBCH without changing content in TDD carrier should be increased for same coverage of FDD carrier.
Observation 4: Postpone of NPUSCH/NPDSCH overlapped with non-NB-IoT subframe, as legacy spec/implementation, will have no impact to spec, impemetnation and scheduling, with no additional complexity. While dropping will request more work on evaluation, impact on spec/implementation and scheuding, also with additional complexity. 
Observation 5: based on legacy specifications, SIB1-NB fall into non-NB-IoT DL subframe will be postponed to next available non-NB-IoT DL subframe for SIB1-NB, resulting only 1/8 SIB1-NB can be transmitted to UE and never success decoding.
Observation 6: dropping the SIB1-NB block falling into non-NB-IoT DL subframe will result UE always need to receive al the repetitions before the decoding, especially for case with 4 or 8 repetitions in 2560ms SIB1 period, resulting large latency and power consumption for UE to receive the SIB1-NB.
Observation 7: Using the current specifications to map NPDSCH and NPUSCH there is a risk of capacity issues in the next available DL/UL occasion, because the scheduling delay can cause many UEs to defer to the same occasion.

Proposal 1: RAN1 should discuss how to allocate the period of active contiguous subframe for UL to cover all the UE with different differential delay.
Proposal 2: RAN1 should study how to have accurate DL synchronization and cell search in this IoT NTN TDD mode.
Proposal 3: RAN1 to send LS to RAN4 to study both DL synchronization and cell search issue in this IoT NTN TDD mode.
Proposal 4: Before make further study on the impact to the specification and feasibility of the mapping of the channel/signals, the exact information on the starting/ending time of the subframes in UL and DL duration should be clear.
Proposal 5: RAN1 to discuss the impact on the achievable link budget if the number of repetitions and resource unit length are restricted due to the use of every Nth radio frame and a limited number of DL/UL subframes. 
Proposal 6: RAN1 to evaluate the cell capacity when accounting for at least NPSS, NSSS, NRS, MIB and relevant System Information Blocks (at least SIB1-5 and SIB31).
Proposal 7: RAN1 should evaluate the UL capacity for NPRACH and NPUSCH considering the active radio frame per N radio frame.
Proposal 8: Postpone should be performed for NPUSCH/NPDSCH as legacy spec.
Proposal 9: Sequential mapping of SIB1-NB blocks into the NB-IoT DL subframe available to SIB1-NB during SIB1-NB period 2560ms should be supported in IoT NTN TDD.
Proposal 10: The duration of repetition for SIB1-NB can be enlarged to e.g. 16*8 frames, to provide more available occasion for SIB1-NB transmission.
Proposal 11: RAN1 to discuss to update the scheduling delay to distribute UEs to different UL/DL occasions by defining the scheduling delay field of DCI formats N0 and N1 distribute according to a multiple of the TDD frame periodicity. 
Proposal 12: RAN1 discuss reusing FDD segment precompensation method in IoT NTN TDD.

3GPP TSG RAN WG1 #120bis             	              R1-2502177
Wuhan, China, April 7th– 11th, 2025

Source: 	CMCC
Title:	Discussion on the new NB-IoT NTN TDD mode
Agenda item:	9.11.5
Document for:	Discussion & Decision

Conclusions
In this contribution, we provide our views on the new modes allowing the usage of radio resources with a periodic subset of the UL and DL subframes. The observations and proposals are listed below. 
Observation 1: For IoT-NTN TDD mode, according to the current configuration parameters of NPRACH occasions, part of ROs overlapping with the available UL subframes within the TDD pattern can be used for PRACH transmission.
Proposal 1: For IoT-NTN TDD mode, SIB1-NB can be dropped in non-D NB-IoT subframes.
Proposal 2: For IoT-NTN TDD mode, if NPRACH (including NPRACH occasions) will overlap with non-U NB-IoT subframes, postponement of PRACH repetition when it overlaps with non-U NB-IoT subframes can be considered.
Proposal 3: For NB-IoT NTN TDD mode, it is not necessary to preform segmented pre-compensation.

3GPP TSG-RAN WG1 Meeting #120bis	R1-2502223
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.11.5
Source:	Huawei, HiSilicon
Title:	Discussion on IoT-NTN TDD mode
Document for:	Discussion and Decision

Conclusions
The observations and proposals made in this contribution are summarized below:
Proposal 1: The guard period between the end of the downlink subframes and the beginning of the uplink subframes is fixed in specifications to be 49 ms at the UL reference point.
Observation 1: SIB1-NB reception following current specifications is feasible for all existing SIB1-NB TBS values, at least when the configured number of repetitions is 16 and additionalTransmissionSIB1 is set to TRUE in the scenario of LEO600(0dBi) and LEO1200(0dBi). If additionalTransmissionSIB1 is set to TRUE, SIB1-NB reception for 208bit TBS is feasible in the scenario of LEO600(-5.5dBi). 
Proposal 2: According to the performance of SIB1-NB decoding, the SIB1-NB transmission can be dropped in non-D NB-IoT subframes, similar as the handling of NPSS/NSSS/NPBCH.
Proposal 3: NPDSCH for SI other than SIB1-NB should be mapped on NB-IoT DL subframes as legacy.
Proposal 4: The value range of starting subframe configuration(G) for USS (npdcch-StartSF-USS) and type-2 CSS (npdcch-StartSF-CSS-RA) for NB-IoT TDD in TN should be used in IoT NTN TDD.
Proposal 5: For all search spaces, UE should skip the following monitoring occasions of a search space if they overlap with ongoing monitoring occasion of the same search space.
Proposal 6: The RAR window configuration and RA-RNTI calculation for NB-IoT TDD in TN should be used for IoT NTN TDD.  
Proposal 7: To reduce the overlap of NPRACH occasions with non-U IoT NTN TDD subframes, new NPRACH periodicities should be introduced to align with the TDD structure (i.e. option 1). If a NPRACH transmission can’t be finished within a TDD pattern, the remaining transmission can be postponed. The unit of postponement should be one PRU (i.e. option 2).
Proposal 8: Segmented pre-compensation does not apply for NB-IoT NTN TDD (option 4).
Proposal 9: For Release-19 IoT NTN TDD mode, the value range of RRC parameters in Table 3 should be changed.

3GPP TSG RAN WG1 #120bis		  R1-2502269
Wuhan, China, April 7th – 11th, 2025

Source:	OPPO
Title:	Discussion on IoT-NTN TDD mode
Agenda Item:	9.11.5
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide an analysis on the potential issues on the downlink synchronization for NB-IoT TDD mode. Based on the analysis we give some observations and proposals for the future work. 
Observation 1: In legacy system, the SIB1-NB transmission period is 2560 ms, where one 	SIB1-NB is 	transmitted over 160 ms (i.e., 16 radio frames). Over the 160 ms, the actual 	SIB1-NB 	transmission is over 8 alternate radio frames. This SIB1-NB transmission may 	not compatible with periodic pattern and would lead to a shortage of SIB1-NB resources. 
Proposal 1:	RAN1 considers to extend the SIB1-NB transmission period as well as the one SIB1-NB 	transmission duration by a factor of N=9. 
Proposal 2: 	RAN1 considers search space splitting over multiple D subframes. 
Proposal 3: 	NPRACH period configuration can be modified to add a period of 90ms or multiple of 	90ms. 
Proposal 4: 	When NPRACH transmission cannot fit into U subframe, postponing NPRACH to next U 	subframe can be considered with postpone granularity of NPRACH repetition. 
Proposal 5: 	For UL segment handling, adopt Option 2 and Option 3. 
Proposal 6: RAR window and CR timer starting time postpone is to be considered to 	ensure the starting time is in D subframe.
Proposal 6: 	RAR window and CR timer starting time postpone is to be considered to ensure the 	starting time is in D subframe.
Proposal 7: 	Outside D subframe, the CR timer can be paused. 

3GPP TSG RAN WG1 #120bis			R1- 2502345
Wuhan, China, April 7th – 11th, 2025 

Agenda Item:	9.11.5
Source:	Sharp
Title:	IoT NTN TDD guard period and uplink segmentation
Document for:	Discussion and Decision

Conclusions
In this contribution, we present our views on the IoT NTN TDD frame structure and guard period, and UL segment transmissions, and we propose the following:
Proposal 1: the fixed guard period in the specification can be set as 48.34ms using DL4 and UL4 pair distance with with slot center transmission assumptions.
Proposal 2: RAN1 to consider a smaller number of repetitions for the NPBCH in IoT NTN TDD.
Proposal 3: For segmented pre-compensation, RAN1 supports Option 3 without additional segment gap handling.
Option 3: UL segment should only be defined in consecutive U subframes

3GPP TSG RAN WG1 #120bis    		                           R1-2502387
Wuhan, China, April 7th – 11th, 2025
Agenda item:		9.11.5
Source:			Samsung
Title:			Discussion on IoT-NTN TDD mode
Document for:		Discussion and decision

Conclusion
This contribution discusses issues for IoT NTN TDD mode, and the followings are observation and proposals. 
Proposal 1: Consider dropping SIB1-NB in non-D NB-IoT subframes

Proposal 2: Consider option 1 for NPRACH

Observation 1: There is no additional specification impacts for segmented pre-compensation 

TDoc file reading error

3GPP TSG RAN WG1 #120bis			R1-2502633
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.11.5
Source:	Apple
Title:	Discussion on IoT-NTN TDD mode
Document for:	Discussion/Decision

Conclusion
In this contribution, we provided our views on IoT-NTN TDD mode. Our observation and proposals are as follows:
Observation 1: To be compatible with satellite frame structure, the time offset between satellite frame and NB-IoT TDD mode pattern is in the unit of 0.01ms. 
Proposal 1: NB-IoT DL subframes and NB-IoT UL subframes within 90ms TDD pattern are separately indicated by two bitmaps.  
Proposal 2: Within the 90ms TDD pattern, the first NB-IoT UL subframe in the UL slot is derived by a subframe offset relative to the first NB-IoT DL subframe in the DL slot.  
Proposal 3: For NPRACH transmission in IoT-NTN TDD mode, 
Introduced new NPRACH periodicities (multiple of 90ms). 
NPRACH transmissions are postponed in non-U NB-IoT subframes until the next U NB-IoT subframe(s). 
guard time created by postponement is shorter than one symbol group.
Proposal 4: Confirm the following working assumption: Uplink transmission gaps do not apply in NB-IoT NTN TDD.
Proposal 5: Segmented pre-compensation does not apply for IoT-NTN TDD mode.   

3GPP TSG RAN WG1 #120bis		 	R1-2502782
Wuhan, CN, Apr 7th – 11th, 2025

Source:	NTT DOCOMO, INC.
Title:	Discussion on IoT-NTN TDD mode
Agenda Item:	9.11.5
Document for: 	Discussion/Decision

Conclusion
Proposal 1:
For NPRACH, New NPRACH periodicities (multiple of 90ms) are introduced for NB-IoT NTN TDD.
E.g., new periodicities of 90ms or multiples of 90ms are configured. 
Proposal 2:
Confirm the working assumption made in RAN1#120 for uplink transmission gap.
Proposal 3:
For segmented pre-compensation, down-select between the following options:
Option 2: A new pre-compensation segment is started at the beginning of each uplink burst
Option 3: UL segment should only be defined in consecutive U subframes

3GPP TSG RAN WG1 #120bis					        R1- 2502819
Wuhan, China, April 7th – 11th, 2025
Agenda Item:	9.11.5
Source: 	LG Electronics
Title: 	Discussion on IoT-NTN TDD mode
Document for:	Discussion and decision

Conclusions
In this contribution, we discussed TDD mode for IoT-NTN. Based on the above discussion, our observations and proposals are given as follows:
Observation 1: According to the existing specification, for USS and Type 2/2A CSS, the search space including the starting subframe are defined in consecutive NB-IoT DL subframes excluding subframes used for transmission of SI messages.
Observation 2: According to the existing specification, the UE shall not expect NPDCCH in subframe that is not a NB-IoT DL subframe, and the NPDCCH transmission in subframes that are not NB-IoT DL subframes is postponed until the next NB-IoT DL subframe.
Observation 3: eNB can estimate two phase differences by using at least three symbol groups in PRU for TA determination. 
Observation 4: For IoT-NTN, the overall TA will be covered by the UE-specific TA and the common TA. Then, in TDD mode, it would be beneficial to maximize the NPRACH transmission opportunities. 
Observation 5: If NPRACH occasions are redefined to be included in U NB-IoT subframes by using new periodicity and offset, the granularity unit of PRU for dropping is equivalent to the granularity unit of a single symbol group for dropping.
Observation 6: Depending on the UL segment size (e.g., 128 or 256 msec), it would be beneficial in terms of UE complexity or UE power consumption to allow the case where multiple UL bursts across different TDD pattern periods belongs to the same UL segment.

Proposal 1: For IoT-NTN TDD mode, consider one of more of followings for SIB1-NB transmission: 
Option 1: Support only 208 bits when the TDD mode is enabled or applied.
Option 2: SIB1-NB transmission could be postponed in non-D NB-IoT subframes within the SIB1-NB period.
Proposal 2: RAN1 does not pursue specific enhancement on the new periodicity of NPDCCH monitoring for the IoT-NTN TDD mode. 
Proposal 3: There is no DL transmission gap in NPDCCH/NPDSCH for the IoT-NTN TDD mode.
Proposal 4: For IoT-NTN TDD mode, one or more of followings can be considered for initial access procedure: 
RAR window starts in DL subframe provided by the TDD pattern subject to the existing required time.
UE (re)starts the contention resolution timer at the DL subframe provided by the TDD pattern subject to the existing required time.
Proposal 5: For NPRACH in IoT-NTN TDD mode, support both Option 1 and Option 2 with some update:
Option 1: New NPRACH periodicities (multiple of 90ms) are introduced for NB-IoT NTN TDD. 
New NPRACH offset is introduced to ensure at least one PRU is confined within the consecutive 8 U NB-IoT subframes in a TDD pattern period. 
Option 2: NPRACH transmissions are postponed in non-U NB-IoT subframes until the next U NB-IoT subframe(s)
The unit of postponement is a PRU.
Proposal 6: For segmented pre-compensation in IoT-NTN TDD mode, UL segment gap is not present at the beginning of each uplink burst. 
Proposal 7: For a UE communicating over NTN, after transmissions (and/or postponements due to NPRACH and/or postponements due to overlapping with non-U NB-IoT subframes) of  time units, for frame structure type 1, a transmission gap of  time units shall be counted for the NPUSCH resource mapping but not used for transmission of the NPUSCH.

3GPP TSG RAN WG1 #120bis			R1-2502824
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.11.5
Source:	Lenovo
Title:	Discussion on IoT-NTN TDD mode 
Document for:	Discussion and decision

Conclusions
In this contribution, considerations of IoT NTN TDD mode are provided. The following proposals are present: 
Proposal 1: All D subframes in 90ms TDD pattern are assumed as a NB-IoT DL subframe except the subframe contains NPSS/NSSS/NPBCH/ SystemInformationBlockType1-NB transmission.
Proposal 2. SIB1-NB transmissions are dropped in non-D NB-IoT subframes. 
Proposal 3: Adjustment of the NPDCCH search space period should be considered for IoT NTN TDD.
Proposal 4: All U subframes in 90ms TDD pattern are assumed as a NB-IoT UL subframe.
Proposal 5: Both the option 1 and option 2 can be combined to solve the RO overlapping issue in IoT NTN TDD.
Proposal 6: Whether segmented pre-compensation applied for NB-IoT NTN TDD (e.g., Option 3 or 4) is determined by the configured consecutive uplink duration.

3GPP TSG RAN WG1 Meeting #120bis	R1-2502858
Wuhan, China, April 07th – 11th, 2025

Agenda item:	9.11.5
Source: 	Qualcomm Incorporated
Title: 	IoT-NTN TDD mode
Document for:	Discussion and Decision

Conclusion
It is RAN1’s understanding that the issue of scheduling and transmitting SI messages in the presence of non-D subframes will be solved mainly (or completely) by RAN2 specifications. RAN1 may discuss potential impact on RAN1 specifications, if any.

Agreement
For segmented pre-compensation, RAN1 to further discuss at least the following options:
Option 1: Dropped/postponed NPUSCH / NPRACH are counted for segment determination
Option 2: A new pre-compensation segment is started at the beginning of each uplink burst
Option 3: UL segment should only be defined in consecutive U subframes
Option 4: Segmented pre-compensation does not apply for NB-IoT NTN TDD.
FFS: How to handle the UL segment gap.


In this contribution we present our views on remaining issues for IOT NTN TDD.
Impact on downlink channels
As a general rule, all channels that are mapped to non-D subframes should be postponed until the next D subframe. This rule should apply to all channels except those used for initial access (e.g. SIB1 should follow the legacy mapping and dropped when needed). In the previous meeting, the following agreements were reached:

We propose to solve some of the FFS issues as follows:
Proposal 1: For handling collisions of NPDCH / NPDCCH with non-NBIOT DL subframes:
NPDSCH carrying SIB1-NB is dropped
It is up to the network whether to configure a large number of repetitions or additional repetitions for SIB1-NB to improve the link budget
No additional enhancements / specification impact are introduced for the following:
Whether all the configuration values for NPDCCH are valid for NB-IoT NTN TDD.

One additional issue not solved by the proposal above is NPDCCH monitoring. Multiple search spaces may occur within a 90ms period, and most of those search spaces will be postponed until the next 8ms downlink period. Therefore, search spaces may overlap and some of those search spaces will be dropped, which is not desirable from system perspective. For instance, this text in TS 36.213 may result in dropping of all search spaces (since all of them are postponed and start at the same time, which happens after k0 of all of them):

RAN1 should design solutions to this problem, ensuring that NPDCCH is available in every downlink burst. One solution to this issue would be to introduce new periodicities that are multiples of 9 radio frames.
Proposal 2: RAN1 specifies a mechanism to enable NPDCCH monitoring in every downlink burst (e.g. introducing new periodicities for NPDCCH monitoring).

Because of the TDD pattern, the availability of NRS will be greatly reduced. If we take D=8, we will have at most 7 DL subframes every 90ms to perform measurements, update tracking loops, channel estimation, etc. The current specification, however, would not guarantee availability of NRS in every subframe, per TS 36.213:

Given the sparse nature of downlink transmissions, we think it would be beneficial to ensure that NRS is available in all the downlink subframes before and after SIB1 decoding. For instance, if the downlink pattern includes subframes : [3 4 5 6 7 8 9 0], the UE may assume that NRS is present in subframes #3, #4, #6, #7, #8, #0 and subframe #9 not including NSSS.
Proposal 3: The UE may assume that NRS is available in every DL subframe not including sync signals.

Impact on uplink channels
Similar to the case of downlink, the general treatment of uplink channels should be to postpone the transmissions that collide with non-U slots. Unlike the downlink case, where transmissions are always 1-ms based, uplink transmissions have a different structure:
For NPRACH, a PRU should never be split and, therefore, the unit for postponement should be a PRU.
For 3.75kHz SCS, the unit of postponement should a 2ms slot (similar to e.g. collisions with NPRACH)
For 15kHz SCS, the unit of postponement can remain 1ms.
The last 2 bullets are in line with the current specifications and in line with the agreement in RAN1#120. For the issue of NPRACH, we would have a preference to keep the same “basic unit” of a PRU:
Proposal 4: For NPRACH, collision with non-U NB-IoT subframes:
Option 2: NPRACH transmissions are postponed in non-U NB-IoT subframes until the next U NB-IoT subframe(s)
The unit of postponement is one PRU.

Another aspect of uplink is how to perform segmented pre-compensation. According to current specifications, the pre-compensation is performed periodically, and phase continuity is lost between segments. In the presence of a TDD pattern, the UE should not be expected to keep phase continuity between consecutive UL bursts due to their separation in time, and the UE should start a new pre-compensation segment at the beginning of the uplink burst.
Proposal 5: For segmented uplink pre-compensation:
Option 2: A new pre-compensation segment is started at the beginning of each uplink burst

Finally, due to the TDD structure under consideration in this work item, uplink transmission gaps do not have any functionality: even if gaps are introduced, during the duration of the gap (which is within the uplink slots) there cannot be any reception of downlink signals (since uplink and downlink do not overlap). Therefore, we propose to confirm the working assumption reached in the previous meeting
Proposal 6: Confirm the following working assumption:
Uplink transmission gaps do not apply in NB-IoT NTN TDD.



Summary
In this contribution we presented our views on NB-IoT TDD mode. We made the following observations and proposals:
Proposal 1: For handling collisions of NPDCH / NPDCCH with non-NBIOT DL subframes:
NPDSCH carrying SIB1-NB is dropped
It is up to the network whether to configure a large number of repetitions or additional repetitions for SIB1-NB to improve the link budget
No additional enhancements / specification impact are introduced for the following:
Whether all the configuration values for NPDCCH are valid for NB-IoT NTN TDD.

Proposal 2: RAN1 specifies a mechanism to enable NPDCCH monitoring in every downlink burst (e.g. introducing new periodicities for NPDCCH monitoring).

Proposal 3: The UE may assume that NRS is available in every DL subframe not including sync signals.

Proposal 4: For NPRACH, collision with non-U NB-IoT subframes:
Option 2: NPRACH transmissions are postponed in non-U NB-IoT subframes until the next U NB-IoT subframe(s)
The unit of postponement is one PRU.

Proposal 5: For segmented uplink pre-compensation:
Option 2: A new pre-compensation segment is started at the beginning of each uplink burst


Proposal 6: Confirm the following working assumption:
Uplink transmission gaps do not apply in NB-IoT NTN TDD.

3GPP TSG RAN WG1 #120b	R1-2502881
Wuhan, China, Apr 7th - Apr 12th, 2025

Agenda item:		9.11.5
Source:	Nordic Semiconductor ASA
Title:					On R19 TDD IoT-NTN
Document for:		Discussion and Decision

Conclusions 
Proposal-1: The guard period between the end of the downlink subframes and the beginning of the uplink subframes is fixed in specifications to be 50 ms.
Proposal-2: SIB1-NB transmissions in non-D NB-IoT subframes are dropped. Conclude that no specification changes to SIB1-NB scheduling are required in R19 TDD NTN IoT.
Proposal-3: For segmented pre-compensation select Option 2 + Option 4: 
R17 segmented pre-compensation are not applicable to R19 TDD IoT NTN
UE shall perform pre-compensation before every UL burst.
Observation-1: It is expected that UEs will spend long time in RRC connected, having long periods of time doing monitoring for NPDCCH once 90ms. 
Proposal-4: If deep sleep shall be supported in R19 TDD IoT NTN system in Connected mode, it is essential that additional synchronization signals (e.g. NSSS) is located in DL burst starting subframe #3, at least on non-anchor.
Proposal-5: NPRACH transmissions in non-U NB-IoT subframes are postponed until the next U NB-IoT subframe(s).
Proposal-6: NPRACH repetitions are postponed, in units of PRU, to subsequent 90ms DL burst(s) and start from the first U subframe of each DL burst.
Proposal-7: If DL gap support is found essential, the duration is in number of valid R19 TDD DL subframes.
Proposal-8: Legacy valid DL subframe bitmap should not be applicable to R19 TDD, unless NTN operator(s) find its support essential.
Proposal-9: NPDCCH and NPDSCH channels are postponed to the next valid DL subframe(s). 
In R19 TDD NTN NB-IoT system, minimum configurable * G is 64ms.
Maximum .

3GPP TSG RAN WG1 #120-bis	R1-2502999
Wuhan, China, April 7th – 11th, 2025

Agenda item:	9.11.5
Source: 	Moderator (Qualcomm Incorporated)
Title: 	Feature lead summary #1 on IoT-NTN TDD mode
Document for:	Discussion and Decision

Conclusion
It is RAN1’s understanding that the issue of scheduling and transmitting SI messages in the presence of non-D subframes will be solved mainly (or completely) by RAN2 specifications. RAN1 may discuss potential impact on RAN1 specifications, if any.

Agreement
For segmented pre-compensation, RAN1 to further discuss at least the following options:
Option 1: Dropped/postponed NPUSCH / NPRACH are counted for segment determination
Option 2: A new pre-compensation segment is started at the beginning of each uplink burst
Option 3: UL segment should only be defined in consecutive U subframes
Option 4: Segmented pre-compensation does not apply for NB-IoT NTN TDD.
FFS: How to handle the UL segment gap.



TDD frame structure - general
2.1 Guard period

In RAN1#120, the following agreement was reached:
Agreement
The guard period between the end of the downlink subframes and the beginning of the uplink subframes is fixed in specifications to be [48…50] ms at the ULSRP.
NOTE: This corresponds to the largest separation between DL and UL Iridium slot pairs. Adjustments to align with different UL/DL pair can be achieved by adjusting the common TA.

The following input has been received in this meeting regarding the guard periods:
[TH], [NOR], [Iri]: 50 subframes
[CATT]: [48, 49] ms
[HW]: 49ms
[SH]: 48.34ms
[APP]; Time offset is in the unit of 0.01ms
There seems to be some fundamental difference between 49 and 50 subframes.
On the camp of <50sf the input from [HW] is based on the following figure and analysis:

For example, the guard period between DL subframes and UL subframes are 47.98ms, 48.10ms, 48.22ms, 48.32ms
The input from [TH] is as follows:
By considering the design constraints of the legacy system as captured in RAN1#119 agreement recopied hereafter, it is observed that different DL/UL pairs of legacy frame structure do not have the same DownlinkToUplinkGuardPeriod. Because the DownlinkToUplinkGuardPeriod should be fixed per band as per the revised WID, the value to be defined for this DL to UL gap should be greater or equal to the maximum gap between DL and UL of DL/UL pairs of legacy frame structure. Common TA could be used to adjust guard period when deemed necessary. By considering the existing design constraints, a value of 50 subframes could be defined for the target MSS allocated band.   
Based on the analysis above, a guard period of 49 subframes seems to be enough (assuming the guard periods presented above are correct).
Proposal 2.1-1 [HIGH]: The guard period between the end of the downlink subframes and the beginning of the uplink subframes is fixed in specifications to be 49ms at the ULSRP.


Handling of downlink channels
3.1 SIB1
In the previous meeting, the handling of SIB1 when colliding with non-U subframes as been left for further study. The following input has been received in this meeting:
[TH], [VIVO], [SPDR], [ZTE], [CMCC], [HW], [SS],[XMI]. [LEN], [QC], [NOR]: SIB1 transmission is dropped
[CATT]: Number of repeated transmissions is fixed to 8 or 16
[NOK], [OPPO]: Repetition for SIB1-NB can be enlarged
[LGE]: Either reduce TBS or postpone instead of dropping.
There is a very clear majority (11 companies) proposing to drop SIB1-NB.
Proposal 3.1-1 [HIGH]: SIB1-NB is dropped in non-D NB-IoT subframes
NOTE: “non-D NB-IoT subframes” are subframes not contained within the set of D=8 usable consecutive downlink subframes in the TDD structure.


3.2 PDCCH
On PDCCH monitoring, the following input has been received:
[TH], [IRI], [QC], [LEN]: Introduce new periodicities ([TH] by scaling factor)
[TH] proposes that search space candidates are not postponed beyond the end of the corresponding search period T
[vivo], [SPDR], [ZTE], [LGE]: Do not introduce new periodicities
 [HW], [CATT]: Change monitoring rule (e.g. UE should skip the following monitoring occasions of a search space if they overlap with ongoing monitoring occasion of the same search space)
[XMI]: Either introduce scaling factor or have restriction on Rmax / T
[NOR]: Restrict the set of Rmax / T that can be configured.
There seems to be no convergence on specifying new periodicities, but several companies mentioned that it would be desirable to define some solutions to handle collisions (in a different way from current specifications).
FL brings the following proposal for discussion:
Proposal 3.1-2: No new periodicities are introduced for NPDCCH search space monitoring
FFS: Changes in postponing / overlapping rules
FFS: Introduction of constraints on the configuration of search space parameters (e.g. Rmax, G…)



3.3 NRS / DL bitmap
On DL bitmap and NRS, the following input has been received:
[NOR], [LEN]: DL bitmap is not valid for NB-IoT NTN TDD (all available D subframes are NB-IoT DL subframes)
[QC]: All DL subframes (not including sync signals) carry NRS

Proposal 3.3-1: DL bitmap is not applicable to NB-IoT NTN TDD mode.
A UE may assume that NRS is present in all D NB-IoT subframes (except those carrying NPSS/NSSS)
All D NB-IoT subframes (except those carrying NPSS/NSSS/SIB1-NB/NPBCH) are NB-IoT DL subframes.
NOTE: “D NB-IoT subframes” are subframes contained within the set of D=8 usable consecutive downlink subframes in the TDD structure.


3.4 DL gap
The following input has been received regarding handling of DL gap in NB-IoT NTN TDD:
[TH], [Iri]: Introduce a new scaling factor for DL gap
[vivo], [SPDR], [ZTE]: No specification enhancements
[LGE]: DL gaps do not apply
[CATT]: If the starting radio frame belongs to non-NB-IoT subframes, it is postponed.
[NOR]: If support of DL gaps is essential, it applies only in D subframes
There seems to be no convergence on this issue. In FL’s understanding, the original (Rel-13) intention of having DL gaps was to accommodate users with very different link budget: UEs with a large number of repetitions would see “gaps” that would allow to schedule users with a smaller number of repetitions. It is unclear whether this use case can apply to NB-IoT NTN TDD mode. Companies are encouraged to discuss this issue 
Proposal 3.4-1: DL gaps do not apply for NB-IoT NTN TDD mode.


Handling of uplink channels
4.1 NPRACH
The following was agreed in RAN1#120 regarding enhancements for NPRACH:
Agreement
For NPRACH, further consider the two options until RAN1#120bis:
Option 1: New NPRACH periodicities (multiple of 90ms) are introduced for NB-IoT NTN TDD.
Option 2: NPRACH transmissions are postponed in non-U NB-IoT subframes until the next U NB-IoT subframe(s)
FFS: The unit of postponement (e.g. PRU)

There seems to be a majority of companies that want to specify both options.
On new periodicities, the following has been proposed:
[TH], [ZTE], [NOR]: No new periodicities.
[HW], [OPPO], [SS], [XMI], [APP], [DCM], [LGE], [LEN],  Introduce new periodicities (multiple of 90 ms)

Proposal 4.1-1 [HIGH]: 	New NPRACH periodicities (multiple of 90ms) are introduced for NB-IoT NTN TDD.


On postponement, the following has been proposed:
[TH], [vivo], [SPDR], [ZTE], [Iri], [CMCC], [HW], [OPPO], [XMI], [LGE], [QC], [NOR], [CATT]: NPRACH is postponed in non-U NB-IoT subframes with a unit of PRU
Proposal 4.1-2 [HIGH]: 	NPRACH transmissions are postponed in non-U NB-IoT subframes until the next U NB-IoT subframe(s). The unit of postponement is one PRU.
NOTE: “U NB-IoT subframes” are subframes contained within the set of U=8 usable consecutive uplink subframes in the TDD structure.


4.2 UL gaps
On UL gaps, the following working assumption was reached in the previous meeting:
Working assumption
Uplink transmission gaps do not apply in NB-IoT NTN TDD.

A clear majority of companies support confirming the working assumption:
[TH], [vivo], [SPDR], [Iri], [DCM], [QC], [APP]: Confirm the working assumption

 Proposal 4.2-1 [HIGH]: Confirm the following working assumption:
Uplink transmission gaps do not apply in NB-IoT NTN TDD.



4.3 Segmented pre-compensation
In RAN1#120, the following agreement was reached regarding segmented pre-compensation:
Agreement
For segmented pre-compensation, RAN1 to further discuss at least the following options:
Option 1: Dropped/postponed NPUSCH / NPRACH are counted for segment determination
Option 2: A new pre-compensation segment is started at the beginning of each uplink burst
Option 3: UL segment should only be defined in consecutive U subframes
Option 4: Segmented pre-compensation does not apply for NB-IoT NTN TDD.
FFS: How to handle the UL segment gap.

The following input was provided to this meeting. The input is very varied so FL created the following caregorization
Start precompensation at the start of each burst:
[NOR]: Option 2 + Option 4
[QC],[XMI], [TH]: Option 2
[DCM]: Option 2 or Option 3
[OPPO]: Option 2 and Option 3
[vivo]: UE can adjust timing by implementation
Segmented precompensation does not apply:
[APP], [HW], [CMCC], [CATT]: Option 4
[SS]: No impact
Postponement of the start of the segment
[SH]: Option 3
[LEN]: Option 3 or 4 depending on duration
[LGE]: Option 3 + don’t count NPRACH postponement
[LGE]: No gap is introduced at the beginning of an uplink burst.
[Iri]: Postpone the segment start
Others
[ZTE]: Option 1
[NOK]: RAN1 discuss reusing FDD segment precompensation method in IoT NTN TDD
Although the input is quite misaligned, it is FL’s understanding that the following should be the common understanding among companies
The UE should not be required to keep phase coherence across UL bursts (since there is an 82ms gap in between). Therefore, the UE can change its time/frequency pre-compensation between bursts.
A key difference between companies seems to be whether the UE needs any additional precompensation within the set of consecutive uplink subframes.
Regarding the pre-compensation gap, it should also be the common understanding that for a segment starting at the beginning of the burst, no gap is needed (since there is a very large gap introduced by the TDD structure before the start of the burst)
Proposal 4.3-1: For segmented precompensation:
The UE adjusts its time/frequency pre-compensation at the beginning of each set of consecutive 8 uplink subframes. No pre-compensation gap is needed for this case.
FFS: Whether it is supported to perform segmented pre-compensation within the set of 8 consecutive uplink subframes, and whether in this case a pre-compensation gap is needed.

Others
There are several topics brought up by a minority of companies. FL considers these issues lower priority and can be treated towards the end of the week if sufficient progress is made in other topics. These topics are:
Issue 5.1: [Len]: All U subframes are NB-IoT UL subframes (no additional reservation on top of the TDD structure).
Issue 5.2: [Nor]: If deep sleep in RRC_CONNECTED is supported, introduce NSSS in non-anchor for re-synchronizaiton
Issue 5.3: [LGE], [OPPO], [HW] : Issues related to RAR, RA-RNTI calculation and contention resolution window. In FL’s view, these should be discussed in RAN2.
Issue 5.4: [XMI]: How to treat GNSS gaps (“For GNSS gap, the starting time and duration should be non D and non U NB-IoT subframes operating Iridium system service”)
Issue 5.5: [XMI],[NOK]: Whether to introduce new scheduling delays
Issue 5.6: Several companies brought up the issue of updating the SI conclusion on the set of {repetitions, SIB1-NB TBS} that are supported by NB-IoT NTN TDD. From FL perspective, this is not necessary to complete the work item (network can just choose the correct parameters by implementation)
Companies are encouraged to provide comments on the issues above 


Proposals for online discussion
Proposal 4.2-1: Confirm the following working assumption:
Uplink transmission gaps do not apply in NB-IoT NTN TDD.

Proposal 4.1-2: 	NPRACH transmissions are postponed in non-U NB-IoT subframes until the next U NB-IoT subframe(s). The unit of postponement is one PRU.
NOTE: “U NB-IoT subframes” are subframes contained within the set of U=8 usable consecutive uplink subframes in the TDD structure.
NPRACH periodicity of 40ms is not supported in NB-IoT NTN TDD mode

Proposal 4.1-1: New NPRACH periodicities (multiple of 90ms) are introduced for NB-IoT NTN TDD.

Proposal 3.1-1: SIB1-NB is dropped in non-D NB-IoT subframes
NOTE 1: “non-D NB-IoT subframes” are subframes not contained within the set of D=8 usable consecutive downlink subframes in the TDD structure.
NOTE 2: RAN1 observes that some combinations of {TBS, number of repetitions, additional SIB1 repetitions}, and depending on aspects such as minimum elevation angle or antenna gain, may not meet the link budget. It is up to the network to properly configure such values to ensure the link budget is met. No specification impact.


Proposal 2.1-1: The guard period between the end of the downlink subframes and the beginning of the uplink subframes is fixed in specifications to be 49ms at the ULSRP.
NOTE: This corresponds to the largest separation between DL and UL Iridium slot pairs. Adjustments to align with different UL/DL pair can be achieved by adjusting the common TA.


Proposal 3.1-2: No new periodicities are introduced for NPDCCH search space monitoring
FFS: Changes in postponing / overlapping rules
FFS: Introduction of constraints on the configuration of search space parameters (e.g. Rmax, G…)

FL comment: For the proposal above, several companies highlighted that there is no need to change the overlapping / postponing rules for NPDCCH. However, keeping the current rules would create some issues as explained in the following.
First, current version of TS 36.213 states the following:

 
Let’s consider the case where the network wants to ensure that there is a search space with Rmax = 8 in every downlink burst. According to the current parameters in 36.331, we would configure Rmax = 8, G= 8, with a resulting periodicity of 64 ms.
If we apply the postoponing rules + the constraint above, we will see the following:

Note that the search space with a k0 in subframe 128 (k0 #3) would be postponed to subframe 183. However, this search space will finish in subframe 190, which does not meet the constraint of a separation of 4ms with respect to the next k0 (k0 #4, which falls in subframe 192). Under the current rules, the search space (or a subset of its candidates depending on whether the UE is configured with 1 or 2 HARQ processes) would be dropped.

Proposal 4.3-1: For segmented precompensation:
The UE adjusts its time/frequency pre-compensation at the beginning of each set of consecutive 8 uplink subframes. No pre-compensation gap is needed for this case.
FFS: Whether it is supported to perform segmented pre-compensation within the set of 8 consecutive uplink subframes, and whether in this case a pre-compensation gap is needed.

Proposal 3.3-1: DL bitmap is not applicable to NB-IoT NTN TDD mode.
A UE may assume that NRS is present in all D NB-IoT subframes (except those carrying NPSS/NSSS)
All D NB-IoT subframes (except those carrying NPSS/NSSS/SIB1-NB/NPBCH) are NB-IoT DL subframes.
NOTE: “D NB-IoT subframes” are subframes contained within the set of D=8 usable consecutive downlink subframes in the TDD structure.

Proposal 3.4-1: DL gaps do not apply for NB-IoT NTN TDD mode.
Proposals from contributions

3GPP TSG RAN WG1 #120-bis	R1-2503081
Wuhan, China, April 7th – 11th, 2025

Agenda item:	9.11.5
Source: 	Moderator (Qualcomm Incorporated)
Title: 	Feature lead summary #1 on IoT-NTN TDD mode
Document for:	Discussion and Decision

Conclusion
It is RAN1’s understanding that the issue of scheduling and transmitting SI messages in the presence of non-D subframes will be solved mainly (or completely) by RAN2 specifications. RAN1 may discuss potential impact on RAN1 specifications, if any.

Agreement
For segmented pre-compensation, RAN1 to further discuss at least the following options:
Option 1: Dropped/postponed NPUSCH / NPRACH are counted for segment determination
Option 2: A new pre-compensation segment is started at the beginning of each uplink burst
Option 3: UL segment should only be defined in consecutive U subframes
Option 4: Segmented pre-compensation does not apply for NB-IoT NTN TDD.
FFS: How to handle the UL segment gap.



TDD frame structure – general [CLOSED]


Handling of downlink channels
3.1 SIB1
In the previous meeting, the handling of SIB1 when colliding with non-U subframes as been left for further study. The following input has been received in this meeting:
[TH], [VIVO], [SPDR], [ZTE], [CMCC], [HW], [SS],[XMI]. [LEN], [QC], [NOR]: SIB1 transmission is dropped
[CATT]: Number of repeated transmissions is fixed to 8 or 16
[NOK], [OPPO]: Repetition for SIB1-NB can be enlarged
[LGE]: Either reduce TBS or postpone instead of dropping.
There is a very clear majority (11 companies) proposing to drop SIB1-NB.
Based on the discussion of the 1st round, the proposal is modified as follows
Proposal 3.1-1v2: SIB1-NB is dropped in non-D NB-IoT subframes
NOTE 1: “non-D NB-IoT subframes” are subframes not contained within the set of D=8 usable consecutive downlink subframes in the TDD structure.
NOTE 2: RAN1 observes that some combinations of {TBS, number of repetitions, additional SIB1 repetitions}, and depending on aspects such as minimum elevation angle or antenna gain, may not meet the link budget. It is up to the network to properly configure such values to ensure the link budget is met. No specification impact.


3.2 PDCCH
On PDCCH monitoring, the following input has been received:
[TH], [IRI], [QC], [LEN]: Introduce new periodicities ([TH] by scaling factor)
[TH] proposes that search space candidates are not postponed beyond the end of the corresponding search period T
[vivo], [SPDR], [ZTE], [LGE]: Do not introduce new periodicities
 [HW], [CATT]: Change monitoring rule (e.g. UE should skip the following monitoring occasions of a search space if they overlap with ongoing monitoring occasion of the same search space)
[XMI]: Either introduce scaling factor or have restriction on Rmax / T
[NOR]: Restrict the set of Rmax / T that can be configured.
There seems to be no convergence on specifying new periodicities, but several companies mentioned that it would be desirable to define some solutions to handle collisions (in a different way from current specifications).
Based on the input in the 1st round of discussions, we performed some additional analysis on the postponement behavior of search spaces:
Several companies highlighted that there is no need to change the overlapping / postponing rules for NPDCCH. However, keeping the current rules would create some issues as explained in the following.
First, current version of TS 36.213 states the following:

 
Let’s consider the case where the network wants to ensure that there is a search space with Rmax = 8 in every downlink burst. According to the current parameters in 36.331, we would configure Rmax = 8, G= 8, with a resulting periodicity of 64 ms.
If we apply the postoponing rules + the constraint above, we will see the following:

Note that the search space with a k0 in subframe 128 (k0 #3) would be postponed to subframe 183. However, this search space will finish in subframe 190, which does not meet the constraint of a separation of 4ms with respect to the next k0 (k0 #4, which falls in subframe 192). Under the current rules, the search space (or a subset of its candidates depending on whether the UE is configured with 1 or 2 HARQ processes) would be dropped.

FL brings the following proposal for discussion:
Proposal 3.1-2: No new periodicities are introduced for NPDCCH search space monitoring
FFS: Changes in postponing / overlapping rules
FFS: Introduction of constraints on the configuration of search space parameters (e.g. Rmax, G…)



3.3 NRS / DL bitmap
On DL bitmap and NRS, the following input has been received:
[NOR], [LEN]: DL bitmap is not valid for NB-IoT NTN TDD (all available D subframes are NB-IoT DL subframes)
[QC]: All DL subframes (not including sync signals) carry NRS

Proposal 3.3-1: DL bitmap is not applicable to NB-IoT NTN TDD mode.
A UE may assume that NRS is present in all D NB-IoT subframes (except those carrying NPSS/NSSS)
All D NB-IoT subframes (except those carrying NPSS/NSSS/SIB1-NB/NPBCH) are NB-IoT DL subframes.
NOTE: “D NB-IoT subframes” are subframes contained within the set of D=8 usable consecutive downlink subframes in the TDD structure.


3.4 DL gap
The following input has been received regarding handling of DL gap in NB-IoT NTN TDD:
[TH], [Iri]: Introduce a new scaling factor for DL gap
[vivo], [SPDR], [ZTE]: No specification enhancements
[LGE]: DL gaps do not apply
[CATT]: If the starting radio frame belongs to non-NB-IoT subframes, it is postponed.
[NOR]: If support of DL gaps is essential, it applies only in D subframes
There seems to be no convergence on this issue. In FL’s understanding, the original (Rel-13) intention of having DL gaps was to accommodate users with very different link budget: UEs with a large number of repetitions would see “gaps” that would allow to schedule users with a smaller number of repetitions. It is unclear whether this use case can apply to NB-IoT NTN TDD mode. Companies are encouraged to discuss this issue 
Proposal 3.4-1: DL gaps do not apply for NB-IoT NTN TDD mode.

Based on the input in the 1st round, FL proposes to first agree on a set of options for downselection:
Proposal 3.4-1v2: For the issue of handling DL gaps in NB-IoT NTN TDD mode:
Option 1: DL gaps do not apply for NB-IoT NTN TDD mode.
Option 2: DL gaps apply based on current specifications.
Option 3: DL gaps apply, where the periodicity of the downlink gap is scaled by a fixed factor F
FFS: Value of F


Handling of uplink channels
4.1 NPRACH [CLOSED]

4.2 UL gaps [CLOSED]

4.3 Segmented pre-compensation
In RAN1#120, the following agreement was reached regarding segmented pre-compensation:
Agreement
For segmented pre-compensation, RAN1 to further discuss at least the following options:
Option 1: Dropped/postponed NPUSCH / NPRACH are counted for segment determination
Option 2: A new pre-compensation segment is started at the beginning of each uplink burst
Option 3: UL segment should only be defined in consecutive U subframes
Option 4: Segmented pre-compensation does not apply for NB-IoT NTN TDD.
FFS: How to handle the UL segment gap.

The following input was provided to this meeting. The input is very varied so FL created the following caregorization
Start precompensation at the start of each burst:
[NOR]: Option 2 + Option 4
[QC],[XMI], [TH]: Option 2
[DCM]: Option 2 or Option 3
[OPPO]: Option 2 and Option 3
[vivo]: UE can adjust timing by implementation
Segmented precompensation does not apply:
[APP], [HW], [CMCC], [CATT]: Option 4
[SS]: No impact
Postponement of the start of the segment
[SH]: Option 3
[LEN]: Option 3 or 4 depending on duration
[LGE]: Option 3 + don’t count NPRACH postponement
[LGE]: No gap is introduced at the beginning of an uplink burst.
[Iri]: Postpone the segment start
Others
[ZTE]: Option 1
[NOK]: RAN1 discuss reusing FDD segment precompensation method in IoT NTN TDD
Although the input is quite misaligned, it is FL’s understanding that the following should be the common understanding among companies
The UE should not be required to keep phase coherence across UL bursts (since there is an 82ms gap in between). Therefore, the UE can change its time/frequency pre-compensation between bursts.
A key difference between companies seems to be whether the UE needs any additional precompensation within the set of consecutive uplink subframes.
Regarding the pre-compensation gap, it should also be the common understanding that for a segment starting at the beginning of the burst, no gap is needed (since there is a very large gap introduced by the TDD structure before the start of the burst)
Proposal 4.3-1: For segmented precompensation:
The UE adjusts its time/frequency pre-compensation at the beginning of each set of consecutive 8 uplink subframes. No pre-compensation gap is needed for this case.
FFS: Whether it is supported to perform segmented pre-compensation within the set of 8 consecutive uplink subframes, and whether in this case a pre-compensation gap is needed.

Based on the 1st round of discussions, FL updates the proposal as follows

Proposal 4.3-v2: For segmented precompensation:
The UE adjusts its time/frequency pre-compensation at the beginning of each set of consecutive 8 uplink subframes. No pre-compensation gap is needed for this case.
FFS: Whether it is supported to perform segmented pre-compensation within the set of 8 consecutive uplink subframes, and whether in this case a pre-compensation gap is needed.


Others
There are several topics brought up by a minority of companies. FL considers these issues lower priority and can be treated towards the end of the week if sufficient progress is made in other topics. These topics are:
Issue 5.1: [Len]: All U subframes are NB-IoT UL subframes (no additional reservation on top of the TDD structure).
Issue 5.2: [Nor]: If deep sleep in RRC_CONNECTED is supported, introduce NSSS in non-anchor for re-synchronizaiton
Issue 5.3: [LGE], [OPPO], [HW] : Issues related to RAR, RA-RNTI calculation and contention resolution window. In FL’s view, these should be discussed in RAN2.
Issue 5.4: [XMI]: How to treat GNSS gaps (“For GNSS gap, the starting time and duration should be non D and non U NB-IoT subframes operating Iridium system service”)
Issue 5.5: [XMI],[NOK]: Whether to introduce new scheduling delays
Issue 5.6: Several companies brought up the issue of updating the SI conclusion on the set of {repetitions, SIB1-NB TBS} that are supported by NB-IoT NTN TDD. From FL perspective, this is not necessary to complete the work item (network can just choose the correct parameters by implementation)
Companies are encouraged to provide comments on the issues above 


Proposals for online discussion

Offline consensus:
Proposal 3.4-1v2: For the issue of handling DL gaps in NB-IoT NTN TDD mode:
Option 1: DL gaps do not apply for NB-IoT NTN TDD mode.
Option 2: DL gaps apply based on current specifications.
Option 3: DL gaps apply, where new periodicity(ies) are introduced (either implicity e.g. the periodicity is scaled by a fixed factor F (FFS: Value of F), or explicitly)


Proposal 3.1-2: For the issue of handling NPDCCH postponing:
Option 1: No new periodicities are introduced for NPDCCH search space monitoring
FFS: Changes in postponing / overlapping rules, if any
FFS: Introduction of constraints on the configuration of search space parameters (e.g. Rmax, G…), if any
Option 2: New periodicities are introduced for NPDCCH search space monitoring
FFS: Details of the new periodicity, e.g. the existing periodicity is scaled by a fixed factor F, explicit signalling of the new periodicity, reusing the NB-IoT TN TDD periodicities, etc.


Proposal 3.3-1: (Working assumption) DL bitmap (downlinkBitmap / downlinkBitmapNonAnchor) is not applicable to NB-IoT NTN TDD mode.
All D NB-IoT subframes (except those carrying NPSS/NSSS/SIB1-NB/NPBCH) are NB-IoT DL subframes.
NOTE: “D NB-IoT subframes” are subframes contained within the set of D=8 usable consecutive downlink subframes in the TDD structure.
FFS: A UE may assume that NRS is present in all D NB-IoT subframes (except those carrying NPSS/NSSS)

No consensus yet
Clear majority (same proposal as in previous session):
Proposal 3.1-1v2: SIB1-NB is dropped in non-D NB-IoT subframes
NOTE 1: “non-D NB-IoT subframes” are subframes not contained within the set of D=8 usable consecutive downlink subframes in the TDD structure.
NOTE 2: RAN1 observes that some combinations of {TBS, number of repetitions, additional SIB1 repetitions}, and depending on aspects such as minimum elevation angle or antenna gain, may not meet the link budget. It is up to the network to properly configure such values to ensure the link budget is met. No specification impact.

1 company preference:
Proposal 3.1-1v2: SIB1-NB is transmitted in the subframes that meet both following conditions:
Subframes that are used in NB-IoT FDD for transmitting SIB1-NB as per legacy specifications, and
Subframes that are contained within the set of D=8 consecutive downlink subframes.
FFS: Mapping within these subframes.


Not discussed in offline
Proposal 4.3-v2: For precompensation:
The UE adjusts its time/frequency pre-compensation at the beginning of each set of consecutive 8 uplink subframes. No pre-compensation gap is needed for this case.
FFS: Whether it is supported to perform segmented pre-compensation within the set of 8 consecutive uplink subframes, and whether in this case a pre-compensation gap is needed.

Proposal: For GNSS measurement gap, RAN1 to further discuss at least the following options: 
Option 1: No enhancement on the Rel-18 timeline for the start of GNSS gap
Option 2: The start of the GNSS measurement gap starts at a non-D/non-U subframe 
Option 3: GNSS measurement gap does not apply for NB-IoT NTN TDD


Proposals from contributions

3GPP TSG RAN WG1 #120-bis	R1-2503101
Wuhan, China, April 7th – 11th, 2025

Agenda item:	9.11.5
Source: 	Moderator (Qualcomm Incorporated)
Title: 	Feature lead summary #1 on IoT-NTN TDD mode
Document for:	Discussion and Decision

Conclusion
It is RAN1’s understanding that the issue of scheduling and transmitting SI messages in the presence of non-D subframes will be solved mainly (or completely) by RAN2 specifications. RAN1 may discuss potential impact on RAN1 specifications, if any.

Agreement
For segmented pre-compensation, RAN1 to further discuss at least the following options:
Option 1: Dropped/postponed NPUSCH / NPRACH are counted for segment determination
Option 2: A new pre-compensation segment is started at the beginning of each uplink burst
Option 3: UL segment should only be defined in consecutive U subframes
Option 4: Segmented pre-compensation does not apply for NB-IoT NTN TDD.
FFS: How to handle the UL segment gap.



TDD frame structure – general [CLOSED]


Handling of downlink channels [CLOSED]
Handling of uplink channels
4.1 NPRACH [CLOSED]

4.2 UL gaps [CLOSED]

4.3 Segmented pre-compensation
In RAN1#120, the following agreement was reached regarding segmented pre-compensation:
Agreement
For segmented pre-compensation, RAN1 to further discuss at least the following options:
Option 1: Dropped/postponed NPUSCH / NPRACH are counted for segment determination
Option 2: A new pre-compensation segment is started at the beginning of each uplink burst
Option 3: UL segment should only be defined in consecutive U subframes
Option 4: Segmented pre-compensation does not apply for NB-IoT NTN TDD.
FFS: How to handle the UL segment gap.

The following proposal was discussed in online and offline discussions:

Proposal 4.3-v2: For segmented precompensation:
The UE adjusts its time/frequency pre-compensation at the beginning of each set of consecutive 8 uplink subframes. No pre-compensation gap is needed for this case.
FFS: Whether it is supported to perform segmented pre-compensation within the set of 8 consecutive uplink subframes, and whether in this case a pre-compensation gap is needed.

A minority of the companies want to keep Option 1, while the majority of the companies want to agree with the proposal above (a small variation of Option 2).

The current specification for precompensation is as follows:

RRC parameter that indicates the Tx Duration:

NPUSCH-TxDuration-NB-r17 ::=    SEQUENCE {
    npusch-TxDuration-r17          ENUMERATED {ms2, ms4, ms8, ms16, ms32, ms64, ms128, ms256}
}

Procedural text indicating the location of the segments:



Let’s assume that the UE starts an NPUSCH transmission at the beginning of one of the uplink bursts, and see how the precompensation segments would look like in subsequent bursts for different values of segment duration. We number as “0” the 1st subframe in the 1st burst


For the red / green cases, we can see that Option 1 results in a larger number of segments (3 vs 2, or 2 vs 1). Similar examples can be found for other cases, since the values of segmented precompensation are not multiples of 90ms).
Note that for values larger than 8ms, Option 2 is the same as Option 4.

In view of the above, please discuss the issue in the table below based on the proposal brought for online:





















Others [CLOSED]

Proposals for online discussion
The proposal previously discussed online seems to be acceptable to all companies except one:
Proposal 1v1: For precompensation:
The UE adjusts its time/frequency pre-compensation at the beginning of each set of consecutive 8 uplink subframes. No pre-compensation gap is needed for this case.
FFS: Whether it is supported to perform segmented pre-compensation within the set of 8 consecutive uplink subframes, and whether in this case a pre-compensation gap is needed.

A potential compromise based on comments of the single company is shown below, but the one company still does not accept this:

Proposal 1v2: (Working assumption) For precompensation, from RAN1 perspective:
The UE adjusts its time/frequency pre-compensation the beginning of each set of consecutive 8 uplink subframes. No pre-compensation gap is needed for this case.
It is not supported to perform segmented pre-compensation within the set of 8 consecutive uplink subframes.

Inform RAN4 of the WA above and ask if there are any issues with the above WA.

The following proposal makes some small progress but defers the decision to the next meeting:

Proposal 1-v3: For segmented pre-compensation:
Option 1: Postponed NPUSCH / NPRACH are counted for segment determination
Option 2: The UE adjusts its time/frequency pre-compensation the beginning of each set of consecutive 8 uplink subframes. No pre-compensation gap is needed for this case.
FFS: Whether it is supported to perform segmented pre-compensation within the set of 8 consecutive uplink subframes, and whether in this case a pre-compensation gap is needed.


Proposals from contributions

3GPP TSG RAN WG1 #120bis	        	        R1-2503166
Wuhan, China, April 7th – 11th, 2025
Agenda item:	9.11.5
Source:		Moderator (Motorola Mobility)
Title:	Summary of email discussion [Post-120bis-Rel-19-36.213- IoT_NTN_TDD-Core]
Document for:	Discussion
1	

TDoc file conclusion not found