3GPP TSG-RAN WG1 Meeting #121	R1-2503284
St Julian’s, Malta, May 19th – 23rd, 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: For the issue of handling DL gaps in NB-IoT NTN TDD mode, option 2 is preferred.
Proposal 2: 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 3: For the issue of handling NPDCCH postponing, support both reusing the NB-IoT TN TDD periodicities in option 2 and 1st FFS in option 1.
Proposal 4: For pre-compensation, performing segmented pre-compensation within the set of 8 consecutive uplink subframes is not supported. The working assumption can be confirmed by removing the FFS points.
Proposal 5: For GNSS measurement gap, option 1 is preferred.
Proposal 6: NPDSCH for SI other than SIB1-NB should be mapped on NB-IoT DL subframes as legacy.
Proposal 7: For Release-19 IoT NTN TDD mode, the changes of RRC parameters in Table 3 should be adopted.

3GPP TSG RAN WG1 #121                                                                                            R1-2503382
St Julian's, Malta, May 19th – 23rd, 2025

Source:	vivo
Title:	Remaining issues 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 proposals.
Proposal 1: No specification enhancement is needed on UE’s assumption on NRS presence.
Proposal 2: 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 or new periodicity) is needed for NPDCCH monitoring.
Proposal 3: No further enhancement on DL gap is introduced, which means UE either is not expected to be configured with DL gap(option1) or applies DL gap as legacy if configured(option2).
Proposal 4: No further enhancement on GNSS gap is introduced, which means UE either is not expected to be configured with GNSS gap(option3) or applies GNSS gap as legacy if configured(option1).
Proposal 5: The segmented pre-compensation within the set of 8 consecutive uplink subframes is not needed.
Proposal 6: There is no additional RAN1 impact for pre-compensation.

3GPP TSG RAN WG1 #121      	                                    	R1-2503531
Saint Julian, Malta, May 19th – 23th, 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:
Support option 1 or option 2 for DL gaps.
Option 1: DL gaps do not apply for NB-IoT NTN TDD mode.
Option 2: DL gaps apply based on current specifications.
Support option 1 for PDCCH monitoring.
Option 1: No new periodicities are introduced for NPDCCH search space monitoring.
Support option 3 for GNSS measurement.
Option 3: GNSS measurement gap does not apply for NB-IoT NTN TDD

3GPP TSG RAN WG1 #121    		                           R1-2503586
St Julian’s, Malta, May 19th – 23th, 2025
Agenda item:		9.11.5
Source:			Samsung
Title:			Discussion on IoT-NTN TDD mode
Document for:		Discussion and decision

Conclusion
This contribution discusses remaining issues for IoT NTN TDD mode, and the followings are proposals. 
Proposal 1: Consider either option 1 or option 2 for the issue of handling DL gaps. 

Proposal 2: For handling NPDCCH postponing, if no configuration provides non-overlapping between two search spaces to avoid allowing new changes regarding postponing or overlapping, Option 2 might be considered. Otherwise, it is preferable to consider Option 1, except for the two FFSs.

Proposal 3: No enhancement is needed for GNSS measurement gap in IoT NTN TDD mode. 

3GPP TSG RAN WG1 #121                                                R1- 2503639
St Julian’s, Malta, May 19th – 23th, 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: Current specifications have already supported postponement of NPDCCH overlapping with non-D NB-IoT subframes and 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.
Proposal 1: No new periodicities are introduced for NPDCCH search space monitoring.
Proposal 2: No change of postponing/overlapping rules are introduced for NPDCCH search space monitoring.
Proposal 3: 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 2: 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.
Observation 3: Network can configure no DL transmission gap by implementation according to current specification.
Proposal 4: DL gaps apply based on current specifications.
Proposal 5: For pre-compensation, RAN1 confirm the working assumption with following update:
Proposal 6: No enhancement on the Rel-18 timeline for the start of GNSS gap.

3GPP TSG RAN WG1#121			 								                         R1-2503688
St Julian’s, Malta, May 19th – 23th, 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:

NPDCCH analysis:
Observation 1
Without introducing new periodicities for NPDCCH monitoring (e.g. the existing periodicity is scaled by a fixed factor F), there are many combinations of Rmax and G that result in the search period T not overlapping with DL transmission.
Observation 2
A scaling factor F expanding the periodicities for NPDCCH monitoring, if introduced, will be fixed in the specs without indication to the UE.

Observation 3
The same scaling factor F will be used for expanding downlink transmission gap periods and expanding periodicities for NPDCCH monitoring.

Proposal 1
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 2
A scaling factor F is introduced to expand the search period T as follows: T= Rmax *G*F
F = 11.5

Downlink transmission gap
Observation 4
For NB-IoT NTN TDD with a periodic pattern of 90ms and reduced DL subframes within one DL transmission occasion (i.e., 8 subframes), the same user could be served for an extended period, even if a large number of repetitions might not be necessary (given a sufficient link budget). Consequently, the downlink transmission gap may need to be configured.
Proposal 3
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

Segmented pre-compensation
Observation 5 
The inability to perform segmented pre-compensation within the set of 8 consecutive uplink subframes results in a significant increase in accumulated timing drift, representing 8% of the CP, 12% of the Te-NTN, and 69% of the total timing errors attributed to satellite component (i.e. error of satellite position estimated by the UE) and UE GNSS inaccuracies.
Proposal 4
Confirm RAN1#120-bis working assumption on segmented pre-compensation with the following update:
Allow segmented pre-compensation within the set of 8 consecutive uplink subframes, and 
RAN1 to further discuss the need of a pre-compensation gap, and if determined to be necessary, consider limiting it to a few symbols instead of entire slots.

DL bitmap
Proposal 5
Confirm RAN1#120-bis working assumption on DL bitmap (downlinkBitmap / downlinkBitmapNonAnchor) with the following update:
Additional SIB1-NB is supported in a NB-IoT NTN TDD even with absence of DL bitmap

GNSS measurement gap
Proposal 6
No enhancement on the Rel-18 timeline for the start of GNSS gap

 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 Meeting #121	  R1-2503778
St Julian's, Malta, 19 - 23 May, 2025 

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

Conclusion
Proposal 1: Weighing the pros and cons, DL gaps can apply based on current specifications without additional specification impact.
Proposal 2: For the issue of handling NPDCCH postponing, we prefer no new periodicities are introduced for NPDCCH search space monitoring, and no specification impact.
Proposal 3: For GNSS measurement gap, we prefer Option 2 slightly, that is, the start of the GNSS measurement gap starts at a non-D/non-U subframe. 

3GPP TSG RAN WG1 #121             	              R1-2503849
St Julian’s, Malta, May 19th – 23th, 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. 
Proposal 1: For the handling of NPDCCH postponing, no need to introduce new periodicities for NPDCCH search space monitoring.
Proposal 2: DL gaps can be applied in NB-IoT NTN TDD mode.
The DL gaps periodicity can be scaled by a scaling factor to accommodate the TDD frame structure.
Proposal 3: For NB-IoT NTN TDD mode, the UE adjusts its time/frequency pre-compensation before the beginning of each set of consecutive 8 uplink subframes. No pre-compensation gap is needed before the beginning of each set of consecutive 8 uplink subframes.
It is not necessary to preform segmented pre-compensation within the set of 8 consecutive uplink subframes.

TDoc file reading error

3GPP TSG RAN WG1 Meeting #121	R1-2503958
St Julian, Malta, May 19th – May 23rd, 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#120bis 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. 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 in ASN.1 are sufficient and can work for IoT-NTN TDD mode. The scaling factor can be added as normative text. Therefore, there is no need to introduce new NPDCCH configuration parameters or extending values in ASN.1.
Observation 5: 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 6: The IoT-NTN TDD mode only operates in NB-IoT standalone mode where downlink bitmap length of only 10ms is applicable.
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, if scaling factor is accepted for NPDCCH period, the maximum allowed NPDCCH period value should be capped at 10240ms
Proposal 3: Change the RAN1#129bis working assumption to an agreement that in IoT-NTN TDD mode, the UE adjusts its time/frequency pre-compensation before the beginning of each set of consecutive 8 uplink subframes. No pre-compensation gap is needed before the beginning of each set of consecutive 8 uplink subframes.
Proposal 4: In IoT-NTN TDD mode, when time and frequency pre-compensation is done before the beginning of each set of consecutive 8 uplink subframes, there is no necessity to apply pre-compensation during 8ms uplink transmission burst. 
Proposal 5: 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 6: The IoT-NTN TDD mode can re-use the existing Rel-18 GNSS measurement gap procedures and no further specification enhancement is required.
Proposal 7: In IoT-NTN TDD mode, additional SIB-1 transmissions may be required and for it to work, select between these two options:
Option 1: Maintain support for the DL bitmap in IoT-NTN TDD mode to enable additional SIB-1 transmissions. As support for downlink bitmap is optional for both the anchor and non-anchor carriers, it should be left to the network configuration to allow no specification changes in either RAN1 or RAN2.
Option 2: DL-bitmap is not supported for IoT-NTN TDD mode. Propose changes to RAN-2 to update 36.331, making downlink bitmap transmission an optional IE for IoT-NTN TDD mode, even with additional SIB-1 transmissions.
Proposal 8: In IoT-NTN TDD mode, the downlink bitmap only controls validity of subframes within the active downlink subframes (D subframes) as non-active (non-D) subframe are considered as invalid NB-IoT downlink subframes.
Proposal 9: In IoT-NTN TDD mode, a UE may assume that NRS is present in subframes #0, #3, #4 and in subframes #9 not containing NSSS and in NB-IoT downlink subframes.

3GPP TSG RAN WG1 #121																	R1-2503959
St Julian, Malta, May 19th – 23rd, 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.0] 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.

Proposal 4: Pending decision in RAN1#121 on uplink precompensation: if the working assumption from RAN#120b is confirmed, then the 36.300 [section 23.21.1] should be updated to reflect the decision on segmented precompensation in  IoT-NTN TDD system:
UL segmented transmission is supported for UL transmission with repetitions. The UE shall apply UE precompensation
per segment of UL transmission of PUSCH/PUCCH/PRACH for BL UEs or UEs in enhanced coverage and NPUSCH/NPRACH for NB-IoT UEs from one segment to the next segment except for IoT-NTN TDD. In IoT-NTN TDD, The UE adjusts its time/frequency pre-compensation before the beginning of each set of consecutive 8 uplink subframes. No pre-compensation gap is needed before the beginning of each set of consecutive 8 uplink subframes.

Proposed Draft LS on IOT NTN TDD stage-2 proposals for TS 36.300:

3GPP TSG RAN WG1 #121			R1-2503961
St Julian’s, Malta, May 19th – 23th, 2025

Agenda Item:	9.11.5
Source:	Sharp
Title:	Remaining issues on IoT NTN TDD 
Document for:	Discussion and Decision

Conclusions
In this contribution, we present our views on the remaining issue of IoT NTN TDD, and we propose the following:
Proposal 1: Confirm the working assumption that no pre-compensation gap is needed before the beginning of each set of consecutive 8 uplink subframes. No segmented precompenstaion is neede either.
Propoasl 2: DL gaps do not apply for NB-IoT NTN TDD mode.

Propoasl 3: No new periodicities are introduced for NPDCCH search space monitoring. The NPDCCH transmission should be postponed to the next available D NB-IoT subframe in the D=8 subframes of the next period.

Proposal 4: GNSS measurement gap does not apply for NB-IoT NTN TDD
Proposal 5: RAN1 to study the NPUSCH scheduling enhancement to support indication of the subframe index in a U=8 timeslot and a delay in a number of TDD periods.

3GPP TSG RAN WG1 #121 	R1- 2504035
St Julian’s, Malta, May 19th – 23th, 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: 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 3: In Rel-18 a UE can be triggered to perform a GNSS measurement or autonomously trigger the GNSS measurement at expiry of GNSS validity duration/T390 or during idle periods.
Observation 4: 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 same resource and a long time later considering 8 subframe for UL and DL in 90ms period.

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: Postpone should be performed for NPUSCH/NPDSCH as legacy spec.
Proposal 3: New NPDCCH search space monitoring periodicity(ies) is supported in TDD NTN considering reduced number of available resource, while postponement of NPDCCH can also be specified.
Proposal 4: For GNSS measurements in TDD NTN no enhancements to the Rel-18 solution is needed.
Proposal 5: RAN1 to discuss to update the scheduling delay fields of DCI formats N0 and N1 to allow the network to distribute UEs to different subframes within the consecutive set of UL/DL subframes. 
Proposal 6: RAN1 to confirm the working assumption that the UE can adjust pre-compensation before the beginning of the set of 8 consecutive uplink subframes without the need for a pre-compensation gap.
Proposal 7: Segmented pre-compensation within the set of 8 consecutive uplink subframes is supported in TDD NTN operation.
Proposal 8: DL gaps are supported in TDD NTN mode. New explicit DL gap periodicity(ies) can be specified if RAN1 TU allows.
Proposal 9: The definition of frame periodicity, guard period, number of consecutive downlink subframes, number of consecutive uplink subframes, and the active downlink subframes shall be defined per band in RAN1 specifications.
Proposal 10: leave it to network implementation to ensure NPDSCH carrying a SI message is not postponed to appear in a next SI window (i.e. SI window for a different SI message) if NPDSCH carrying SIB-NB is postponed.   

3GPP TSG RAN WG1 #121		R1-2504203
St Julian’s, Malta, May 19th – 23th, 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:	The gap period can be configured with {64, 128, 256, 512, 1024} subframes and the gap 	coefficients can be configured with {1/8, 1/4, 3/8, 1/2}. This gives various length of the gap 	duration {8,16,24,32,48,64,96,128,256,384,512}ms. In the legacy system the derived gap 	duration is equivalent to possible DL PDSCH transmission duration. With option 1, in 	NTN TDD system, the blockage issue will become more severe. With option 2, the effective 	gap duration will be reduced to {8,16,40,88}ms, which can support only a small part of the 	DL transmission. Thus, an enhancement should be adopted to effectively cover the legacy 	DL gap duration. 
Observation 2:	Although the segment duration is configured by the network, it is clearly mentioned in TS 	36.211 that the configuration is based on the UE capability. It is crucial to support UE 	capability of 2ms and 4ms, respectively. 

Proposal 1:	RAN1 supports the enhancement on DL gap by determine the gap duration based on NTN 	NB-IoT subframe. 
Proposal 2:	Support Option 2: New periodicities are introduced for NPDCCH search space monitoring

Proposal 3: 	Support Option 1: No enhancement on the Rel-18 timeline for the start of GNSS gap
Proposal 4: 	Support to perform segmented pre-compensation within the set of 8 consecutive uplink 	subframes, at least for segment gap equal to 2ms and 4ms, respectively. 

3GPP TSG RAN WG1 #121			R1-2504346
St Julian’s, Malta, May 19th – 23th, 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: Within the 90ms TDD pattern, the subframe offset between the first NB-IoT UL subframe in the UL and the first NB-IoT DL subframe in the DL slot is fixed in the specification or indicate by network. 
Proposal 2: UE doesn’t expect the NPDCCH candiates in two search spaces are overlapping.
Proposal 3: For NB-IoT NTN TDD mode, DL gaps apply based on current specifications.
Proposal 4: No enhancement on the Rel-18 timeline for the start of GNSS gap.

3GPP TSG RAN WG1 #121			R1-2504414
St Julian’s, Malta, May 19th – 23th, 2025

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

Summary
In this contribution we presented our views on NB-IoT TDD mode. We made the following observations and proposals:
Proposal 1: RAN1 specifies a mechanism to enable NPDCCH monitoring in every downlink burst
As a baseline, introduce new periodicities (e.g. multiples of 90ms) for NPDCCH monitoring.

Proposal 2: Confirm the following modified working assumption:
DL bitmap (downlinkBitmap / downlinkBitmapNonAnchor) is not present in a NB-IoT NTN TDD cell.
NOTE1: All D NB-IoT subframes (except those carrying NPSS/NSSS/SIB1-NB/NPBCH) are NB-IoT DL subframes.
NOTE2: “D NB-IoT subframes” are subframes contained within the set of D=8 usable consecutive downlink subframes in the TDD structure.
NOTE3: The UE can assume that NRS is present in subframes 3 4 5 6 7 8 and subframe 9 not containing NSSS. 

Proposal 3: For precompensation, it is supported to perform segmented pre-compensation within the set of 8 consecutive uplink subframes as per legacy specifications.
The segments are counted starting from the beginning of the set of 8 consecutive uplink subframes.
Segmentation gaps are applied as per legacy specifications

Proposal 4: For GNSS measurement gap, RAN1:
Option 1: No enhancement on the Rel-18 timeline for the start of GNSS gap

Proposal 5: Endorse the following RRC parameter 

3GPP TSG RAN WG1 #121			R1-2504461
Malta, May 19th – 23rd, 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: For the issue of handling DL gaps in NB-IoT NTN TDD mode: DL gaps apply, where the new periodicity of the downlink gap is introduced. E.g., 1024 or 2048.
Proposal 2: Adjustment of the NPDCCH search space period (e.g., adding new larger G value and removing NPDCCH period smaller than 90ms, or adjusting NPDCCH period to multiple of 90ms) should be considered for IoT NTN TDD.
Proposal 3: It is not supported to perform segmented pre-compensation within the set of 8 consecutive uplink subframes. No Pre-compensation gap is needed within the set of 8 consecutive uplink subframes.

3GPP TSG RAN WG1 #121		 	R1-2504518
St Julian’s, Malta, May 19th – 23rd, 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 the issue of handling DL gaps in NB-IoT NTN TDD mode, support
Option 2: DL gaps apply based on current specifications
Proposal 2:
For the issue of handling NPDCCH postponing, support
Option 2: New periodicities are introduced for NPDCCH search space monitoring
Proposal 3:
Confirm the following working assumption that DL bitmap is not present in a NB-IoT NTN TDD cell.
Proposal 4:
Confirm the working assumption for uplink pre-compensation.
Not support to perform segmented pre-compensation within the set of 8 consecutive uplink subframes.

3GPP TSG RAN WG1 #121	 					        R1- 2504565
St Julian’s, Malta, May 19th – 23rd, 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: According to the existing specification, if the time gap between two contiguous search space is applicable to two contiguous NPDCCH occasions in the same search space, some combinations of G and R_max in the existing specification would not be used even without a consideration of new TDD pattern. 
Observation 4: If new NPDCCH search space periodicity to be multiples of 90msec is introduced, the new offset definition would be necessary to allow the time locations of the k0 is different across different hyper frames like the TDD pattern. 
Observation 5: If new DL transmission gap periodicity to be multiples of 90msec is introduced, the new offset definition would be necessary to allow the time locations of the DL transmission gap is confined within the DL burst in a TDD pattern period. 
Observation 6: During the DL transmission gap within the DL burst of the TDD pattern, it is not guaranteed that eNB always use it for another NPDCCH transmissions, then it will results the DL resource waste. 
Observation 7: Considering the limited number of available UL resources in TDD mode, the segment size of 8msec without any gap can maximize the UL resource utilization at the expense of the small time/frequency offset error.
Observation 8: When the NPUSCH transmission starts in the middle of the UL burst (8 consecutive uplink subframes), the UE does not need to perform the pre-compensation at the beginning of the UL burst. Moreover, if the UE does not have the NPUSCH transmission in the UL burst, the UE is not required to perform the pre-compensation during the UL burst. 
Observation 9: According to the existing specification, even after applying the TDD pattern, the GNSS measurement gap will start outside the DL burst of the TDD pattern regardless of whether the UE provide HARQ-ACK feedback for the NPDSCH containing GNSS measurement command MAC CE. 
Observation 10: According to the existing specification, even after applying the TDD pattern, UE may stop ongoing DL receptions and UL transmissions until the GNSS measurement and the subsequent procedures including valid GNSS position reacquisition, contention-based random-access procedure, and the remaining GNSS validity duration reporting are completed. 

Proposal 1: No new periodicities are introduced for NPDCCH search space monitoring.
Proposal 2: DL gaps do not apply for NB-IoT NTN TDD mode.
Proposal 3: 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 4: For IoT-NTN TDD mode, NPRACH offset is defined with respect to the beginning of the first TDD pattern within a hyper frame. 
Candidate for the new NPRACH offset: 0, 1, 2
Proposal 5: Confirm the following WA with some change:
Working assumption
For precompensation, from RAN1 perspective:
The UE adjusts its time/frequency pre-compensation before the beginning of each set of consecutive 8 uplink subframes for the postponed NPUSCH transmission. No pre-compensation gap is needed before the beginning of each set of consecutive 8 uplink subframes.
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.
FFS: whether spec impact is in RAN1, RAN4 or both
Proposal 6: For GNSS measurement gap, support 
Option 1: No enhancement on the Rel-18 timeline for the start of GNSS gap

3GPP TSG RAN WG1 #121	R1-2504576
St. Julian’s, Malta, May 19th-23rd 2025

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

Conclusions 
Proposal-1: Confirm working assumption as 
Working assumption
For precompensation, from RAN1 perspective:
The UE adjusts its time/frequency pre-compensation before the beginning of each set of consecutive 8 uplink subframes. No pre-compensation gap is needed before the beginning of each set of consecutive 8 uplink subframes.
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.
 segmented pre-compensations are not supported
Adopt the specification change above
Observation-1: It is expected that UEs will spend long time in RRC connected, having long periods of time doing only  monitoring for NPDCCH once 90ms. 
Proposal-2: 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-3: UE may assume that every D subframe (except of NPSS and NSSS) contains NRS. 
Proposal-4: If DL gap support is found essential, the duration is counted in number of valid R19 TDD DL subframes.
Proposal-5: NPDCCH and NPDSCH channels are postponed to the next valid DL subframe(s). 
In R19 TDD NTN NB-IoT system, minimum configurable T=* G is 64ms.
Maximum 
Scaling factor applied to T can be considered.
Proposal-6: 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.

3GPP TSG-RAN WG1 Meeting #121	R1-2504718
St Julian's, Malta, 19 - 23 May, 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: Additional SIB1-NB transmissions are supported based on current specifications without the need of indicating DL bitmap.
NOTE: RAN1 assumes that all Rel-19 UEs can interpret additionalTransmissionSIB1-r15 in MIB


Proposal 4: For NPDCCH monitoring, new periodicities are introduced for NPDCCH monitoring. RAN1 to downselect during RAN1#121 among the following options for the new periodicities:
Option 1: The periodicity is scaled by a scaling factor F
Option 2: Explicitly indicate the NPDCCH monitoring periodicity (e.g. multiple of 90ms)
Option 3: New set of values for G


Proposal 5: For the issue of handling DL gaps in NB-IoT NTN TDD mode:
Option 2: DL gaps apply based on current specifications for TDD (i.e., values of periodicity of {128, 256, 512,1024}


Proposal 6: Endorse the following TP for 36.300:

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 . This pattern is repeated every N radio frames. The values of N, D, U,  are fixed IoT-NTN TDD band specified in 

Figure IoT-NTN TDD mode frame structure



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.


In this release of the specification, NTN is only applicable to FDD and IoT-NTN TDD system.


Proposal 7: Confirm the working assumption of RAN1#120b with the following modifications
DL bitmap (downlinkBitmap / downlinkBitmapNonAnchor) is not present in a NB-IoT NTN TDD cell.
NOTE1: All D NB-IoT subframes (except those carrying NPSS/NSSS/SIB1-NB/NPBCH) are NB-IoT DL subframes.
NOTE2: “D NB-IoT subframes” are subframes contained within the set of D=8 usable consecutive downlink subframes in the TDD structure.
Up to RAN2 to decide whether DL bitmap (downlinkBitmap / downlinkBitmapNonAnchor) is constrained to not present in a NB-IoT NTN TDD cell, or it can be configured with values all set to ‘1’.


Proposal 8v1: Confirm the working assumption of RAN1#120b with the following modifications:
For precompensation, from RAN1 perspective:
The UE adjusts its time/frequency pre-compensation before the beginning of each set of consecutive 8 uplink subframes. No pre-compensation gap is needed before the beginning of each set of consecutive 8 uplink subframes.
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.
It is not supported to perform segmented precompensation within the set of 8 consecutive uplink subframes
FFS: whether spec impact is in RAN1, RAN4 or both.
NOTE: RAN1 may revisit this agreement if RAN4 reply LS shows concerns

Proposal 8v2: Confirm the working assumption of RAN1#120b with the following modifications:
For precompensation, from RAN1 perspective:
The UE adjusts its time/frequency pre-compensation before the beginning of each set of consecutive 8 uplink subframes (or at the beginning of an uplink transmission if it is not aligned with the beginning of the set of consecutive 8 uplink subframes). No pre-compensation gap is needed before the beginning of each set of consecutive 8 uplink subframes (or at the beginning of an uplink transmission if it is not aligned with the beginning of the set of consecutive 8 uplink subframes).
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.
It is not supported to perform segmented precompensation within the set of 8 consecutive uplink subframes
FFS: whether spec impact is in RAN1, RAN4 or both.
NOTE: RAN1 may revisit this agreement if RAN4 reply LS shows concerns


Proposals from contributions

3GPP TSG-RAN WG1 Meeting #121	R1-2504719
St Julian's, Malta, 19 - 23 May, 2025

Agenda item:	9.11.5
Source: 	Moderator (Qualcomm Incorporated)
Title: 	Feature lead summary #2 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.

1.1.4 RAN1#120b

Agreement
Confirm the following working assumption:
Uplink transmission gaps do not apply in NB-IoT NTN TDD.
Agreement
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 periodicities of 40ms and 80ms are not supported in NB-IoT NTN TDD mode
Instead, periodicities of 90ms and 180ms are supported

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

Agreement
For the issue of handling DL gaps in NB-IoT NTN TDD mode, down-select among the following options:
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, or explicitly)

Agreement
For the issue of handling NPDCCH postponing, down-select among the following options:
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.

Working assumption
DL bitmap (downlinkBitmap / downlinkBitmapNonAnchor) is not present in a NB-IoT NTN TDD cell.
NOTE1: All D NB-IoT subframes (except those carrying NPSS/NSSS/SIB1-NB/NPBCH) are NB-IoT DL subframes.
NOTE2: “D NB-IoT subframes” are subframes contained within the set of D=8 usable consecutive downlink subframes in the TDD structure.

Agreement
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.

Agreement
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


Working assumption
For precompensation, from RAN1 perspective:
The UE adjusts its time/frequency pre-compensation before the beginning of each set of consecutive 8 uplink subframes. No pre-compensation gap is needed before the beginning of each set of consecutive 8 uplink subframes.
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.
FFS: whether spec impact is in RAN1, RAN4 or both.
Inform RAN4 of the WA above and ask if there are any issues with the above WA.

R1-2503141	[DRAFT] LS on precompensation for NB-IoT NTN TDD mode	Qualcomm Incorporated
Friday session: Draft LS is endorsed. Final version of the LS is approved in R1-2503142.


Handling of downlink channels 

For the issue of handling downlink gaps, the following was agreed in RAN1#120b:

The following input was submitted to this meeting:
Option 2 (6): [HW], [ZTE], [CATT], [XMI], [APP], [DCM]
[XMI]: DL gaps are measured in logical NB IoT subframes in TDD mode
Option 1 or option 2 (3): [vivo], [SPDR], [SS]
Option 1 (2): [LGE], [SH]
Option 3 (6): [TH], [CMCC], [XMI], [Iri], [NOK], [LEN]
[TH]: Introduce a scaling factor of 11.5
[CMCC]: Introduce scaling factor
[XMI] A scaling factor can be applied to DL transmission gap
[Iri]: Introduce a scaling factor of F=16
[NOK], [LEN]: Introduce new periodicities
Gap duration is based on NB-IoT D subframes: [OPPO], [NOR]
There seems to be a majority (11 vs 6) that do not want to introduce any enhancements (either by saying that DL gaps do not apply, or by saying they apply based on current specifications). FL makes the following proposal:
Proposal 2.1 [HIGH]: For the issue of handling DL gaps in NB-IoT NTN TDD mode:
•	Option 2: DL gaps apply based on current specifications

There was no consensus on this issue during the first online session. During the offline there was no converngence. FL proposes to go with the majority view on the following table
Proposal 2.1v3 [HIGH]: 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, or explicitly)
Option 4 (subset of Option 3 and 2): DL gaps apply based on current specifications, with the following modification:
dl-GapPeriodicity with a value of “sf1024” is supported instead of the value of “sf64”




For the definition of k0, after the first round of proposals the following alternatives were received. Companies are encouraged to comment with their preference:
Proposal 2.2.2v2 [HIGH]: For the issue of handling the NPDCCH offset:
Option 1: The reference time to determine the location of k0 is the first subframe of the DL bust of the first TDD pattern in a hyper frame. 
Option 2: subframe  is a subframe satisfying the condition , where X is the relative subframe offset between SFN#0 of a hyper frame and the beginning of the first TDD pattern within the hyper frame. 
Option 3: Do not support R_max larger than 4 in NTN TDD.
Option 4: subframe  is a subframe satisfying the condition , where  is the hyperframe number
Option 5: No enhancements are specified in Rel-19

36.300 TP 
[Iri2] has provided a TP to be incorporated in 36.300:

As a result of the 1st round of proposals, the TP has been updated as below:

Proposal 4.1v2 [HIGH]: The TP below is endorsed for TS 36.300


Downlink and uplink transmissions are organized into radio frames with 10 ms duration. Three radio frame structures are supported:
- Type 1, applicable to FDD
- 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). This pattern is repeated every N radio frames. The values of N, D, U,  are fixed IoT-NTN TDD band specified in 




UL segmented transmission is supported for UL transmission with repetitions. The UE shall apply UE precompensation
per segment of UL transmission of PUSCH/PUCCH/PRACH for BL UEs or UEs in enhanced coverage and NPUSCH/NPRACH for NB-IoT UEs from one segment to the next segment except for IoT-NTN TDD. In IoT-NTN TDD, The UE may adjust its time/frequency pre-compensation before the beginning of each set of consecutive 8 uplink subframes. No pre-compensation gap is needed before the beginning of each set of consecutive 8 uplink subframes



RRC parameters [CLOSED]


Others [CLOSED]

Proposals for online discussion
Proposal 2.3v2: Confirm the working assumption of RAN1#120b with the following modifications

DL bitmap (downlinkBitmap / downlinkBitmapNonAnchor) does not apply to a NB-IoT NTN TDD cell.
NOTE1: All D NB-IoT subframes (except those carrying NPSS/NSSS/SIB1-NB/NPBCH) are NB-IoT DL subframes.
NOTE2: “D NB-IoT subframes” are subframes contained within the set of D=8 usable consecutive downlink subframes in the TDD structure.
Up to RAN2 to decide whether DL bitmap (downlinkBitmap / downlinkBitmapNonAnchor) is constrained to not being present in a NB-IoT NTN TDD cell, or it can be configured with values all set to ‘1’.


Proposal 3.1 [HIGH]: Confirm the following working assumption with modifications:
For precompensation, from RAN1 perspective:
The UE may adjust its time/frequency pre-compensation before the beginning of each set of consecutive 8 uplink subframes. No pre-compensation gap is needed before the beginning of each set of consecutive 8 uplink subframes.
The UE may adjust its time/frequency pre-compensation at the beginning of an NPUSCH/NPRACH transmission (same behavior as Rel-18)
Segmented precompensation is not supported.
It is not supported to perform precompensation within the set of 8 consecutive uplink subframes other than at the beginning of an NPUSCH/NPRACH transmission
FFS: whether spec impact is in RAN1, RAN4 or both.
NOTE: RAN1 may revisit this agreement if RAN4 reply LS shows concerns, including concerns on meeting the requirements without segmented precompensation

Proposal 2.2.1-v2:Confirm the following WA with the following modification
For NPDCCH monitoring, new periodicities are introduced for NPDCCH monitoring by scaling the periodicity by a scaling factor F = 11.25 supporting values of G={11.25*4, 11.25*8} instead of G={4,8}

Proposal 4.1v2: The TP below is endorsed for TS 36.300


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.


In this release of the specification, NTN is only applicable to FDD and IoT-NTN TDD system.


Downlink and uplink transmissions are organized into radio frames with 10 ms duration. Three radio frame structures are supported:
- Type 1, applicable to FDD
- 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). This pattern is repeated every N radio frames. The values of N=9, D=8, U=8, GP=50 are fixed for the IoT-NTN TDD band (1616-1626.5 MHz) specified in [36.102]



Proposal 2.1v3 [HIGH]: 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, or explicitly)
Option 4 (subset of Option 3 and 2): DL gaps apply based on current specifications, with the following modification:
dl-GapPeriodicity with a value of “sf1024” is supported instead of the value of “sf64”

FL recommendation: take Option 4


Proposal 2.2.2v2 [HIGH]: For the issue of handling the NPDCCH offset:
Option 1: The reference time to determine the location of k0 is the first subframe of the DL bust of the first TDD pattern in a hyper frame. 
Option 2: subframe  is a subframe satisfying the condition , where X is the relative subframe offset between SFN#0 of a hyper frame and the beginning of the first TDD pattern within the hyper frame. 
Option 3: Do not support R_max larger than 4 in NTN TDD.
Option 4: subframe  is a subframe satisfying the condition , where  is the hyperframe number
Option 5: No enhancements are specified in Rel-19


Proposals from contributions

3GPP TSG-RAN WG1 Meeting #121	R1-2504875
St Julian's, Malta, 19 - 23 May, 2025



Agenda item :		9.11.5
Source:			Moderator (Qualcomm Incorporated)
Title:			Summary#1 of discussions on RRC parameters for Rel-19 IOT NTN TDD mode
Document for:		Discussion and decision


Moderator input
Proposal 1: The following RRC parameters are agreed:

TDoc file conclusion not found