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

Source:	SageRAN
Title:	Discussion on support of HD-FDD (e)RedCap UEs with NR NTN
Agenda Item:	9.11.2
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide our views on the support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN band. According to the discussions, we have the following observations and proposals:
Observation 1: For collision case 4, it is possible that no DL grant detected in the search space in the case of DL prioritized.
Observation 2: For collision case 4, it is possible that UL preparation time is insufficient due to shorter UE-specific offset setting in some dynamic UL scheduling cases.
Observation 3: If DL is prioritized, DTX detection at UL receiver can help gNB be indicated implicitly the happening of collision and conduct the following scheduling adjustment.
Observation 4: The DTX detection of HARQ-ACK feedback may be not applicable because DL HARQ feedback is probably disabled for NTN scenario.
Proposal 1: In collision case 4 (dynamic scheduled DL reception collides with dynamic scheduled UL transmission), the following option is selected: 
DL is prioritized by default, and network is allowed to indicate UL overriding DL;
No exceptional use case;
The indicated signaling is the same as case 3.
Observation 5: The case of multiple overlapping transmissions happens in RRC-connected state only.
Observation 6: The aligned rules between collision scenarios can help solving the issue of multiple overlapping transmissions.
Proposal 2: The uniform priority rule should be used for both collision case 3 and case 4 and the signaling for overriding should be shared or aligned between 2 cases.
Observation 7: Finer TA report granularity may impact other timing signaling but bring limited benefit.
Proposal 3: No enhancement for finer TA report granularity in FR1-NTN.
Observation 8: The information of TA drifting is helpful for gNB to estimate the TA change in a future duration. Then the potential collision can be predicted and mitigated by gNB in advance.
Proposal 4: Introducing enhanced TA report with TA drifting information.
Proposal 5: The TA drifting information should include TA drift rate, TA drift variant rate and effective period at least. 
Proposal 6: No smaller TA offset threshold for TA report enhancement.
Proposal 7: It should be supported to trigger a TA report when the collision is detected at the UE.
Proposal 8: It should not be supported to trigger a TA report from gNB.

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

Source:	vivo
Title:	Discussion on support of RedCap and eRedCap UEs with NR-NTN
Agenda Item:	9.11.2
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide our views on the support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN band. According to the discussions, we have the following observations and proposals:
Observation 1: PDSCH scheduled by PDCCH with CRC scrambled by P-RNTI for type 2 PDCCH CSS is not received by UE in RRC connected mode.
Observation 2: The handling of collision with dedicated PDSCH scheduled by PDCCH with DCI scrambled by C-RNTI, CS-RNTI, or MCS-C-RNTI by type 0/0A/1/2 PDCCH CSS is left to UE implementation.
Observation 3: The PDCCH order triggered PRACH is used to re-obtain UL synchronization.
Observation 4: According to the note in the working assumption, the UL cancellation timeline is up to UE implementation.
Observation 5: It is very difficult and complicated to define the prioritization rule for multiple collision cases.
Observation 6: If the TA report is supported by a UE, a smaller TA offset threshold leads to more power consumption of UE and increases the signaling overhead of the system, and the maximum TA mismatch caused by the limited value of the TA threshold can be controlled by the configuration of gNB. The benefit of smaller granularity is limited. The TA mismatch caused by TA drifting can be covered by CP.
Observation 7: If the TA report is not supported by the UE, the maximum TA variation can be estimated by the gNB based on the maximum differential delay and the timing drift. The maximum differential delay in the cell can be calculated by the gNB. The gNB can perform scheduling based on the estimated maximum TA variation to avoid UL and DL collision.

Proposal 1: Confirm the working assumption that the handling of collision with PDSCH scheduled by type 1 PDCCH CSS in RRC-connected mode is left to UE implementation.
Proposal 2: The handling of collision with PUSCH scheduled by RAR UL grant in PDSCH scheduled by type 1 PDCCH CSS in RRC connected mode is left to UE implementation.
Proposal 3:
For Rel-19 NTN HD-FDD (e)Redcap UE in RRC connected mode, the following handling rule for collision case 4 is supported:
Handling of collision with PDSCH (at least for system information) scheduled by Type-0/0A[/1][/2]-PDCCH CSS in RRC-Connected mode, or PUSCH scheduled by RAR UL grant  in PDSCH scheduled by type 1 PDCCH CSS in RRC connected mode, is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
FFS: handling of PDCCH ordered PRACH transmission
For PDCCH order triggered PRACH collision with DL transmission except PDSCH scheduled by Type-0/0A/1 PDCCH CSS in RRC-Connected mode, the PDCCH order triggered PRACH is prioritized
For other use cases, default priority rule for collision case 4 in RRC-Connected mode is that [DL or UL] is prioritized.
Network is allowed to indicate [UL or DL] overriding [DL or UL] for all cases
This is signaled by one UE specific RRC parameter
Note: if DL is prioritized, the DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.
Note: UE shall comply to the following existing procedure in 38.331:
UEs in RRC_CONNECTED shall monitor for SI change indication in any paging occasion at least once per modification period if the UE is provided with common search space, including pagingSearchSpace, searchSpaceSIB1 and searchSpaceOtherSystemInformation, on the active BWP to monitor paging, as specified in TS 38.213 [13], clause 13. 
Proposal 4: When the collision happens at the UE side for collision case 3 and case 4, it is up to UE implementation to prioritize UL transmission or DL reception.
Proposal 5: No enhancement on TA report in Rel-19.

3GPP TSG RAN WG1 #120bis			R1-2501881
Wuhan, China, April 7th – 11th, 2025
Agenda item:	9.11.2
Source: 	Spreadtrum, UNISOC
Title: 	Discussion on support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands 
Document for:	Discussion and decision

Conclusion
In this contribution, we made the following observations and proposals.
Confirm the following WA with some changes:
Working assumption 
For Rel-19 NTN HD-FDD (e)Redcap UE in RRC connected mode, the following handling rule for collision case 4 is supported:
Handling of collision with PDSCH (at least for system information) scheduled by Type-0/0A[/1][/2]-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
FFS: handling of PDCCH ordered PRACH transmission
For other use cases, default priority rule for collision case 4 in RRC-Connected mode is that [DL or UL] is prioritized.
Network is allowed to indicate [DL or UL]  overriding [DL or UL]  for all cases
This is signaled by one UE specific RRC parameter
Note: if DL is prioritized, the DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.
Note: UE shall comply to the following existing procedure in 38.331:
UEs in RRC_CONNECTED shall monitor for SI change indication in any paging occasion at least once per modification period if the UE is provided with common search space, including pagingSearchSpace, searchSpaceSIB1 and searchSpaceOtherSystemInformation, on the active BWP to monitor paging, as specified in TS 38.213 [13], clause 13. 
When network indicates DL overriding UL in RRC-Connected mode for collision case 4, one UE-specific RRC parameter is used to indicate overriding for all the applicable other use cases except for collisions with PDSCH scheduled by Type-0/0A/1-PDCCH CSS.
No enhancement of TA report is introduced in Rel-19 NTN.

3GPP TSG RAN WG1 #120bis                                              R1-2501900
Wuhan, China, April 7th – 11th, 2025
Source:	ZTE Corporation, Sanechips
Title:	Discussion on support of RedCap/eRedCap UEs for NR NTN
Agenda Item:	9.11.2
Document for: Discussion

Conclusions
According to the analysis given above, we have the following observations and proposals:
Observation 1: With finer TA report granularity and smaller triggering offset threshold, the ratio of unavailable resource for the scheduled UE due to avoiding collisions can be further reduced due to smaller TA mismatch.
Observation 2: In current spec, TA report granularity (1 ms) greater than the minimum TA triggering offset threshold (0.5 ms) may incur unnecessary TA reports even if the actual TA has not changed.
Proposal 1: As a general approach, TA report can be enhanced by introducing finer granularity and smaller triggering offset threshold to further reduce the ratio of unavailable resource due to avoiding collision cases.
Proposal 2: To mitigate the collisions of case 3 and case 4, the following finer TA report granularity can be further down-selected:
Symbol level using 15 kHz
Slot level using 30 kHz.
Proposal 3: Following three options can be considered for introducing finer TA report granularity:
Option 1: The gNB configures TA report granularity
Option 2: The gNB/UE determines TA report granularity according to predefined rules
Option 3: The UE determines TA report granularity relying on UE’s implementation and then indicates TA value and TA report granularity together to the gNB via MAC CE.
Proposal 4: The working assumption reached in RAN1 #120 meeting can be revised and then confirmed as follows.
Proposal 5: The issue of collisions involving more than two overlapping transmissions should be clarified and solved. Following three options can be down-selected.
Opt. 1: Up to UE implementation 
Opt. 2: In chronological order
Opt. 3: On a case by case basis
For collisions involving multiple transmissions (>2) with different cases, the order of collision handling is: case 4 --> case 1/2 --> case 3
For collisions involving multiple transmissions (>2) with a same case (case 3 or case 4), the order of collision handling is: exceptional case --> other cases.

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

Agenda Item:	9.11.2
Source:	CATT
Title:	         Discussion on the enhancement of RedCap and eRedCap UEs in NTN 
Document for:	Discussion and Decision

Conclusion
In this contribution, we analzyed potential issues of the operation of RedCap and eRedCap UEs in NTN, and the observations and proposals are listed as follows:
The collision case exists between a UE-specific PDSCH scheduled by Type1-PDCCH CSS and dynamic UL. 
The collision case between the PDSCH scheduled by the Type-2-PDCCH CSS and the dynamic UL is not existing. 
gNB is not aware of the behaviour of the UE when UE determine priority based on UL cancellation timeline.
For dynamic downlink except for the PDSCH scheduled by Type-0/0A-PDCCH, when it collides with the dynamic uplink, UL is prioritized.
TA reporting granularity with 0.5ms is benefical to reduce resource waste and match the TA reporting threshold, and meanwhile, there is no clear risk for secuity issue. 

For case 4, it is necessary to design default uniform rules similar to case 3. 
For Rel-19 NTN HD-FDD (e)Redcap UE in RRC connected mode, the following handling rule for collision case 4 is supported:
Handling of collision with PDSCH (at least for system information) scheduled by Type-0/0A-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
For other use cases, default priority rule for collision case 4 in RRC-Connected mode is that UL is prioritized.
Network is allowed to indicate DL overriding UL for all cases
This is signaled by one UE specific RRC parameter
Note: UE shall comply to the following existing procedure in 38.331:
UEs in RRC_CONNECTED shall monitor for SI change indication in any paging occasion at least once per modification period if the UE is provided with common search space, including pagingSearchSpace, searchSpaceSIB1 and searchSpaceOtherSystemInformation, on the active BWP to monitor paging, as specified in TS 38.213 [13], clause 13. 
When the collision scenarios with more than two overlapping transmissions occurs in multiple slots, the following two options can be considered
Opt. 1: up to UE implementation
Opt. 2: collision handling in chronological order
For the collision scenarios where there are more than two overlapping transmissions in one slot, it is up to UE implementation whether to prioritize UL or prioritize DL.
Suggest to support 0.5ms TA reporting granularity for RedCap and eRedCap UEs in NTN.

3GPP TSG RAN WG1 #120bis		                         R1-2502032
Wuhan, China, April 7th – 11st, 2025
Agenda Item:	9.11.2
Source:	China Telecom
Title:	Discussion on Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands 
Document for:	Discussion and Decision

Conclusions
In this contribution, we discuss the HD-FDD RedCap UE with NR NTN operating in FR1-NTN bands and have the following proposals:
Proposal 1: For Rel-19 NTN HD-FDD (e)Redcap UE in RRC connected mode, the following handling rule for collision case 4 is supported:
Handling of collision with PDSCH (at least for system information) scheduled by Type-0/0A/1/2-PDCCH CSS in RRC-Connected mode, CSI-RS, and SRS can left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
For other use cases, default priority rule for collision case 4 in RRC-Connected mode is that UL is prioritized.
Network is allowed to indicate DL overriding UL for all cases
This is signaled by one UE specific RRC parameter
Proposal 2: For collision cases 3 and case 4, support 0.5ms TA offset threshold and 0.5ms TA report granularity.
Proposal 3: For collision cases 3 and case 4, support to trigger a TA report when the collision is detected at the UE.

3GPP TSG RAN WG1 #120bis            				                                   				 		  		 R1-2502174
Wuhan, China, April 7th – 11th, 2025
Source: 	CMCC
Title:	Discussion on the collision issues of HD-FDD Redcap UE in FR1-NTN
Agenda item:	9.11.2
Document for:	Discussion & Decision

Conclusions
In this contribution, we provide our views on the potential collision issues and handling rules that may occur for HD-FDD (e)RedCap UEs in NTN scenarios. The observations and proposals are listed below.
Observation 1:
The current TA reporting mechanism based on TA offset cannot guarantee that only the UE who has the traffic reports the TA to the gNB. The TA reporting of UEs without traffic will occupy the uplink transmission resource and consume the UE power.

Observation 2: 
The smaller TA offset threshold may induce redundant TA reporting for those UEs who do not have traffic. And it would also induce additional occupation of radio resources and the UE power consumption.

Observation 3:
One UE’s TA reporting can provide enough information for the gNB’s scheduling over an area, for example, one beam footprint. And other UEs in the same area may not need the TA reporting.

Observation 4:
The gNB’s tracking of a large number of UE’s TA drifting is too complicated and power-consuming, which may also be not necessary.

Observation 5: 
For collision cases 3 and 4, it is essential to enhance the alignment of decisions about DL/UL collisions, as assumed by the network and the UE respectively.

Observation 6:
For collision case 3, when the gNB is uncertain whether a collision occurs at the UE side due to TA mismatch, Solution 1 (Aggressive Network Scheduling & Legacy UE Behavior) is unacceptable, as it may cause problems in Case B2 (no collision at UE side, but the gNB is unsure), for example:
If UL overrides DL, the DL transmission is intended for other UEs. Trying to receive the DL transmission intended for other UEs would waste the target UE’s receiver power consumption, and it may cause degradation of the target UE’s decoding performance if the target UE’s soft buffer is polluted by the DL transmission intended for other UEs.
If DL overrides UL, the same UL resources are allocated for both the target UE and other UEs, which causes UL collision. None of the UL transmissions is decodable at the gNB side, resulting in waste of both the target UE and other UEs’ transmitter power consumption and degradation of the resource utilization efficiency of NTN.
Note: Solution 1 means the gNB assumes a collision occurs at the target UE side and allocates the unused resources (due to overlapping) to other UEs, while the UE determines whether a collision occurs based on its actual TA.

Observation 7:
For collision case 3, when the gNB is uncertain whether a collision occurs at the UE side due to TA mismatch, Solution 2 (Conservative Network Scheduling & Legacy UE Behavior) is better than Solution 1 (Aggressive Network Scheduling & Legacy UE Behavior), but the resource utilization efficiency of NTN may be degraded in Case B1 (collision occurs at UE side, but the gNB is unsure).
Note: Solution 2 means the gNB assumes there is no collision and reserves both the DL & UL resources for the target UE, while the UE determines whether a collision occurs based on its actual TA.

Observation 8:
For collision case 3, when the gNB is uncertain whether a collision occurs at the UE side due to TA mismatch, compared with Solution 2 (Conservative Network Scheduling & Legacy UE Behavior), Solution 3 (Aggressive Network Scheduling & New UE Behavior) can avoid degradation of the resource utilization efficiency of NTN, but at the cost of loss of the UE’s throughput in Case B2 (no collision at UE side, but the gNB is unsure).
Note: Solution 3 means the gNB assumes a collision occurs at the target UE side and allocates the unused resources (due to overlapping) to other UEs, while the UE follows the gNB’s stance and assumes a collision occurs.

Proposal 1:
For Rel-19 NTN HD-FDD (e)Redcap UE in RRC connected mode, for collision case 4,
If the UL cancellation timeline can be satisfied, handling of collision with PDSCH (at least for system information) scheduled by Type-0/0A[/1]-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL
Otherwise, UL is prioritized.
Note: As an example, the UL cancellation timeline means the time interval (GAP) between the last symbol of a PDCCH reception where the HD-UE detects the DCI format scheduling DG DL and the first symbol of the DG UL is no less than Tproc,2.

Proposal 2:
For Rel-19 NTN HD-FDD (e)Redcap UE, PDCCH ordered PRACH transmission should be prioritized for collision case 4.

Proposal 3:
Type 2 PDCCH CSS can be removed from the working assumption for collision Case 4.

Proposal 4:
Confirm the working assumption made in RAN1#120 for collision case 4 if proposal 1-3 are considered.

Proposal 5: 
TA reporting triggered by the gNB or UE can be supported to reduce the reporting overheads, for example:
TA reporting with a new triggering mechanism from the gNB.
Trigger a TA report when the collision is detected at the UE.

Proposal 6: 
Half of the slot, i.e. 0.5ms, can be considered for the finer TA report granularities, if finer TA reporting is supported.

Proposal 7:
To solve the TA mismatch issue and maximize the resource utilization efficiency of NTN, new UE behavior with enhanced collision determination rule can be considered:
The UE determines whether a collision occurs based on the gNB’s assumed TA region, which can be obtained from the UE-reported TA (for example, the gNB’s assumed TA region = {UE-reported TA – GAP, UE-reported TA + GAP}) or according to the cell size (for example, the gNB’s assumed TA region = {min cell TA, max cell TA}).
If there is any TA value within the gNB’s assumed TA region that would cause a collision, the UE assumes a collision occurs and applies either DL reception or UL transmission based on the priority rules.
Otherwise, if all TA values within the gNB’s assumed TA region will not cause a collision, the UE assumes no collision and applies both DL reception and UL transmission simultaneously.
Note: GAP is affected by the TA report granularity and TA offset threshold.

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

Agenda Item:	9.11.2	
Source:	InterDigital, Inc.
Title:		         Discussion on half-duplex RedCap issues for NTN FR1 operation
Document for:	Discussion

Conclusions
In this contribution, the following observations are made:
Observation 1: The network cannot ensure scheduling non-colliding dynamic UL vs dynamic DL transmissions for a HD-FDD UE due to TA drift unless large gap is introduced by the network between such transmissions. 
Observation 2: The network issues a PDCCH ordered PRACH to a UE that has lost UL transmission. 
Observation 3: Based upon the importance of maintaining the link and avoiding link failure for the UE and the network, the case 4 collisions involving PDCCH ordered PRACH transmissions cannot be left to UE implementation. 
Observation 4: Frequent TA reporting, for example by using a smaller TA offset threshold, from several UEs will result in large UL overhead and may lead to poor system efficiency.
Observation 5: Finer TA granularity provides little help against TA drift despite the increased reporting overhead. 
Observation 6: The TA reporting based upon UE collision detection can enable the network to avoid future collisions through updated scheduling, e.g., by introducing suitable gap intervals between the UL and the DL transmissions. 

The observations have led to the following proposals:
 Proposal 1: For Rel-19 HD-FDD (e)Redcap UE in RRC connected mode, for collision case 4, the default priority is that the DL is prioritized.
Proposal 2: For Rel-19 HD-FDD (e)Redcap UEs in RRC connected mode, for collision case 4 if the UL transmission is a PDCCH-ordered-PRACH, the UL is prioritized.
Proposal 3: Support UE configuration to trigger TA reporting upon detecting HD-FDD collision.
Proposal 4: Support the enhanced TA reporting from the UE upon network request where the network may request the reporting granularity or additional details on the past collisions.
Proposal 5: Clarify the UE behavior upon detecting the multi-transmission (>2) collision scenarios for HD-FDD RedCap NTN operation. 

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

Agenda Item:	9.11.2
Source:	Huawei, HiSilicon
Title:	Discussion on HD-FDD RedCap UEs and eRedCap UEs for FR1-NTN
Document for:	Discussion and Decision

Conclusions
In this contribution, enhancements for mitigating issues caused by TA mismatch between actual TA used by the UE and assumed TA for the UE at the gNB for HD collisions cases (cases 3 and 4) to support HD-FDD RedCap UEs and eRedCap UEs operation in FR1-NTN are discussed. The following observations and proposals are presented:
Observation 1: Based on the current TA reporting mechanism, the TA mismatch between UE and gNB can be as large as +/- 16ms with the least frequent report triggering, and up to +/- 1.5ms with the most frequent report triggering. 
Observation 2: For a UE incapable of TA reporting or not configured with TA reporting, the TA mismatch can be as large as the difference between the maximum and minimum TA possible in the cell coverage area.  
Observation 3: It is important for an enhanced TA report to use a MAC CE of same or smaller size as that of the legacy TAR (2 Octets: 14bits + 2 Reserved bits), especially if gNB intends to configure a small triggering threshold offsetThresholdTA to cope with TA variations at the UE.
Observation 4: Based on the SL simulation results, the following observations are made:
-	Even with the smallest value of the triggering offset threshold (0.5ms), the legacy TAR scheme with 1ms granularity renders substantially limited resources (< 8%) for scheduling UL. Thus, TA reporting enhancements are essential for enabling the HD operation of (e)RedCap UEs.
-	Smaller triggering thresholds render more resources available for UL at the expense of increased triggering rate by the same factor. With finer granularity (1OS or less), around 22% more resources are released for UL when the threshold is decreased from 0.5ms to 0.05ms.
-	TADR scheme renders the largest percentage of UL available resources closest to the ideal scheme assuming an absolute (non-quantized) TA report. 
- 	The granularity of 13us allows for better HD collision avoidance than the granularity of 1OS.
-	For a triggering threshold of 0.5ms or less, a 1-Octet MAC CE is sufficient, assuming 13us granularity, to indicate all the +/- delta levels while the remaining bits can be used for indicating the respective report index.  
-	TADR scheme outperforms the enhanced TAR scheme with 1OS granularity by 5~3% for the triggering offset threshold 0.25~0.05ms, however such gain comes as well with %50 savings in UL dynamic signalling overhead due to the reduced MAC CE size.
Observation 5: TA reporting granularity finer than a slot duration (1ms) is beneficial to mitigating the HD-FDD collisions for (e)RedCap operation in FR1-NTN due to the following reasons:
Not all the TDRA of colliding DL signals/channels are slot based, e.g. PDCCH and CSI-RS
Not all the TDRA of colliding UL signals/channels are slot based, e.g. PUSCH rep Type B, PUCCH and SRS
According to existing Rel-17 spec for HD-FDD, cancellation of SRS is partial for only the symbols in collision with a DL reception and not for the whole slot
Actual TA is applied at the UE to the UL transmissions in units of Tc and not in slot units
A UL transmission and a non-overlapping DL reception could be determined as colliding if the gap is less than the minimum transition gap (~13µs) which regardless of the slot duration      
Proposal 1: For collision case 4 (dynamic DL and dynamic UL), the WA from RAN1#120 can be confirmed with following changes: 
For use cases other than collision with PDSCH scheduled by PDCCH in CSS, DL is prioritized by default unless the network indicated otherwise via RRC or the UL cancellation timeline cannot be satisfied.
 UE does not receive PDSCH scheduled by Type-2 PDCCH CSS in RRC CONNECTED. (Remove PDSCH scheduled by Type2-PDCCH from the exceptional use case).
PDSCH scheduled by Type-1 PDCCH CSS can be an exceptional case. (Remove the square brackets around Type1-PDCCH CSS)
No exceptional use case for PDCCH-ordered PRACH 
Proposal 2: RAN1 supports enhanced TA reporting with at least a configurable report granularity finer than 1ms, i.e., X symbols or Y µs.
Proposal 3: RAN1 supports enhanced TA reporting with reduced UL dynamic overhead by using a MAC CE of a smaller size than the existing TAR MAC CE, e.g. ,TA delta reporting (TADR) in 1 Octet, which also allows for increased triggering frequency to cope with the actual TA variation at the UE.
Proposal 4: the legacy TAR procedure can be extended to include additional triggering events upon receiving a request via a DL MAC CE or via a scheduling DCI (e.g. UL grant) to send the latest TA value in a legacy TAR or for the UE MAC entity to recover from missed eTAR/TADR at gNB.
Proposal 5: When determining whether to cancel a UL transmission, the UE should further check the DL/UL collision according to the UL timeline with the latest reported TA in addition to the UL timeline with the actually used TA. The UL cancellation rules should be applied if conditions for a cancellation are satisfied based on either the TA actually used or the TA latest reported.
Proposal 6: RAN1 to discuss the RRC parameters proposed in Table 4 and include the outcome in the LS to RAN2.

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

Source:	OPPO
Title:	Discussion on supporting of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands
Agenda Item:	9.11.2
Document for:	Discussion and Decision

Conclusion
In this contribution, we further provide our views on supporting RedCap and eRedCap UEs with NR NTN, including priority rule for case 4 and TA reporting enhancements. 
The following observations are provided. 
Observation 1: For TA reporting configuration with 0.5ms TA offset threshold, the collisions at UE side may be avoided if an interval between DL and UL scheduling is considered and the interval value is larger than or equal to 1.513ms.  
Observation 2: For TA reporting enhancements with finer TA report granularity and smaller TA offset threshold, the overhead is huge, the benefit is small, and it is not worth enhancing.
Observation 3: The gNB is unable to know the reported TA is triggered by a collision detection or other events, so the motivation and benefit of triggering a TA report when the collision is detected at the UE is unclear.
Observation 4: The gNB may mitigate the collisions of case3 and case4 at UE side with current TA triggering and reporting mechanism, and a new triggering mechanism from gNB is not needed.
Observation 5: TA drifting rate reporting causes a lot of implementation complexity and UE cost, and whether gNB can obtain an accurate TA from TA drifting rate is doubtable.

The following proposals are provided.
Proposal 1: For UE in RRC-Connected mode with collisions between PDSCH scheduled by Type-1-PDCCH CSS and dynamically scheduled UL transmission, PDSCH scheduled by Type-1-PDCCH CSS should have a higher priority.
Proposal 2: For UE in RRC-Connected mode with collisions between PDCCH ordered PRACH transmission and dynamically scheduled DL reception, PDCCH ordered PRACH transmission should have a higher priority.
Proposal 3: For UE in RRC-Connected mode with collisions between PDSCH scheduled by Type-2-PDCCH CSS and dynamically scheduled UL transmission, it is left to UE implementation to prioritize UL or DL.
Proposal 4: For other use cases, default priority rule for collision case 4 in RRC-Connected mode is that UL is prioritized, and network is allowed to indicate DL overriding UL for all case.
Proposal 5: Support legacy Rel-17 TA reporting mechanism to mitigate the collisions of case3 and case4.

3GPP TSG-RAN WG1 Meeting #120-bis	R1-2502305
Wuhan, People’s Republic of China, April 7th – 11th, 2025
Agenda Item:	9.11.2
Source:	Ericsson
Title:	On HD-FDD Redcap UEs for NTN
Document for:	Discussion

1	

Conclusion
Based on the discussion in the previous section we made the following observations:
Observation 1	During RAN1# 120 there was a last-minute request to also surround by brackets “Type-[1]-PDCCH CSS”. However, in our view PDSCH scheduled by Type-[1]-PDCCH CSS in RRC-Connected should be part of collision case 4, since unless there were an exceptional case, a PDSCH scheduled by PDCCH is required.
Observation 2	To keep a proper synergy between collision cases 3 and 4, Type-1-PDCCH should be part of Collision Case 4.
Observation 3	During RAN1# 120, there were opinions that “PDSCH (at least for system information) scheduled by Type-[2]-PDCCH CSS in RRC-Connected” does not apply to collision case 4. One argument was that a “short paging message” applies in this case.
Observation 4	In relation with the previous observation, in our understanding, a “short paging message” is solely carried by PDCCH, thus our current view is that “Type-2” should not be part of collision case 4.
Observation 5	To our knowledge, a “PDCCH ordered PRACH transmission” is used for instructing the UE to initiate the random-access procedure when e.g., the network has identified that the UE is out-of-sync in UL.
Observation 6	In our understanding, a “PDCCH ordered PRACH transmission” does not make use of PDSCH since the order is solely provided through PDCCH using USS.
Observation 7	In our view, the “PDCCH ordered PRACH transmission” does not need to be treated as a special case and can instead be part of the “other use cases” subject to a default priority.
Observation 8	On whether the default priority rule for “other cases” in collision case 4 should be [DL or UL], our preference is keeping consistency with respect to collision case 3 (i.e., DL is the default priority).
Observation 9	The “Note” under the default priority can be further clarified citing the clause of the technical specification where the “UL cancellation timeline” is described.
Observation 10	The smallest the configurable offsetThresholdTA the more accurate is the timing, but the more is signalling overhead and UE battery consumption associated with it.
Observation 11	The suitability of a given offsetThresholdTA is scenario dependent, and therefore frequent, moderately frequent, and even infrequent TA reports are all important to find a suitable trade-off.
Observation 12	In relation with the previous observation, introducing a “Smaller TA offset threshold” cannot be seen (at least not on its own) as a solution that mitigates issues “caused by TA mismatch between actual TA used by the UE and assumed TA for the UE at the gNB” since it won’t be applicable/suitable to all scenarios. In addition, a TA offset threshold smaller than 0.5 ms will further impact the signalling overhead and UE battery consumption.
Observation 13	For each triggered occasion, in our understanding the UE reports the absolute TA value expressed in milliseconds which is rounded up, i.e., ceil(Actual TA in ms). From the obtained results, in can be inferred that a “Smaller TA offset threshold” won’t be beneficial without the introduction of a finer TA report granularity.
Observation 14	If the granularity of the TA report were made to be finer, the potential gains would have to be quantified with respect to the legacy TA report granularity (e.g., both using the legacy offsetThresholdTA configurations). Moreover, any impact on the Timing Advance Report MAC CE should be investigated.
Observation 15	It is important to highlight that adding a finer granularity to the TA report does not necessarily impacts the size of the legacy TA report, which is composed by 14 bits.
Observation 16	In our view, it is key knowing up to how many ms are intended to be covered by the TA report as a function of the max TA for a given orbit.
Observation 17	In relation with the previous observation, the max TA is ~ 541.46 ms for GEO. According with our analysis, it should be possible adding a 0.5 ms granularity and even a symbol-level granularity without impacting the legacy size of the legacy TA report (See Table 5).
Observation 18	The proponents of potential TA report enhancements other than “finer granularity” and “Smaller TA offset threshold,” need to elaborate more on the description of those solutions as to be able to assess their potential benefit, and how they would benefit or will complement with the existing legacy mechanisms. Moreover, as agreed in RAN1# 118, “The benefit, complexity, power consumption and signaling overhead of each scheme is to be further investigated”.
			
Based on the discussion in the previous sections we propose the following:

Proposal 1	Type-1-PDCCH should be part of Collision Case 4.
Proposal 2	Type-2-PDCCH should not be part of Collision Case 4 since a “short message” applies in this case. Thus, Type-2-PDCCH along with its companion “Note” (i.e., the one at the bottom) should be removed from the Working Assumption.
Proposal 3	The “PDCCH ordered PRACH transmission” is part of the “other use cases” of collision case 4 subject to a default priority.
Proposal 4	To keep consistency between default priority of collision cases 3 and 4, the default priority rule for “other cases” in collision case 4 is DL.
	To clarify the procedure related to the “UL cancellation timeline”, the note under the default priority is updated as follows:
“Note: if DL is prioritized, the DL prioritization applies only if the UL cancellation timeline as described in clause 17.2 of TS 38.213 can be satisfied, otherwise UL is prioritized”

5	

3GPP TSG RAN WG1 #120bis    		                           R1-2502384
Wuhan, China, April 7th – 11th, 2025
Agenda item:		9.11.2
Source:			Samsung
Title:			Discussion on support of RedCap and eRedCap UEs with NR NTN 
			operating in FR1-NTN bands
Document for:		Discussion and decision

Conclusion
This contribution discussed on potential issues for RedCap/eRedCap UEs in NTN. The followings are proposals in this contribution. 
Proposal 1: If the parameter indicating prioritizing UL for case 3 is provided, the UE first resolves the overlapping between semi-static UL transmissions and dynamic DL reception, if any, and then resolves the overlapping between semi-static UL transmissions and semi-static DL reception.

Proposal 2: If the parameter indicating prioritizing UL for case 3 is not provided, the UE first resolves the overlapping between semi-static DL transmissions and dynamic UL reception, if any, and then resolves the overlapping between semi-static UL transmissions and semi-static DL reception.

Proposal 3: For collision case 4, confirm working assumption with the following update  

Proposal 4: Deprioritize the discussion on TA reporting enhancements. 

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

Source: 	Xiaomi
Title:	Discussion on the support of Redcap and eRedcap UEs in NR NTN
Agenda item: 	9.11.2
Document for:	Decision

Conclusions
In this contribution, we discuss the potential collision issues to support the HD-FDD Redcap in the NTN scenario. Based on our analysis, we have the following proposals:
Proposal 1: For the collision case 4, confirm the working assumption with revision in red
Working assumption 
For Rel-19 NTN HD-FDD (e)Redcap UE in RRC connected mode, the following handling rule for collision case 4 is supported:
Handling of collision with PDSCH (at least for system information) scheduled by Type-0/0A/1/2[/1][/2]-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
FFS: handling of PDCCH ordered PRACH transmission
For other use cases, default priority rule for collision case 4 in RRC-Connected mode is that [DL or UL] is prioritized.
Network is allowed to indicate [UL or DL] overriding [DL or UL] for all cases
This is signaled by one UE specific RRC parameter
Note: if DL is prioritized, the DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.
Note: UE shall comply to the following existing procedure in 38.331:
UEs in RRC_CONNECTED shall monitor for SI change indication in any paging occasion at least once per modification period if the UE is provided with common search space, including pagingSearchSpace, searchSpaceSIB1 and searchSpaceOtherSystemInformation, on the active BWP to monitor paging, as specified in TS 38.213 [13], clause 13. 
Proposal 2: Finer TA report granularity (less than 1ms) is not needed to be further studied to mitigate the collisions of case3 and case4.
Proposal 3: New TA triggering enhancements, i.e., TA reporting based on a new triggering mechanism gNB triggering and triggering a TA report when the collision is detected at the UE, is not needed to be further studied to mitigate the collisions of case3 and case4.

3GPP TSG RAN WG1 #120bis	R1-2502520
Wuhan, China, April 7th – 11th, 2025
Agenda item:	9.11.2
Source: 	ETRI
Title:	Discussion on HD UEs with NR NTN
Document for:	Discussion/Decision

Conclusion
In this contribution, ETRI’s views on NTN HD UEs were shown and the following observations and proposals were made:

Observation 1. Regarding the alternatives on TA reporting enhancements, pros and cons of each alternative can be summarized as in the following table:

Proposal 1. RAN1 to down-select one of the following alternatives on TA reporting enhancements:
Alt.1: No enhancement in Rel-19
Alt.2: Finer TA report granularity of 0.5 ms granularity
Proposal 2. For Rel-19 NTN HD-FDD (e)Redcap UE in RRC connected mode, the following handling rule for collision case 4 is supported:
Handling of collision with PDSCH (at least for system information) scheduled by Type-0/0A/1/2-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
For other use cases, default priority rule for collision case 4 in RRC-Connected mode is that DL is prioritized.
Network is allowed to indicate UL overriding DL for all cases
This is signaled by one UE specific RRC parameter
Note: if DL is prioritized, the DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.
Proposal 3. (second preference) For Rel-19 NTN HD-FDD (e)Redcap UE in RRC connected mode, the following handling rule for collision case 4 is supported:
Handling of collision with PDSCH (at least for system information) scheduled by Type-0/0A/1/2-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
For other use cases, default priority rule for collision case 4 in RRC-Connected mode is that UL is prioritized.
Network is allowed to indicate DL overriding UL for all cases
This is signaled by one UE specific RRC parameter
Note: if DL is prioritized, the DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.
Proposal 4. In multiple collision scenarios, a UE ignores collision use case that may impact the on-going UE processing timeline, regardless of the nominal collision snapshot at a given time instance.

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

Agenda item:		9.11.2
Source:	Nokia, Nokia Shanghai Bell
Title:	Discussion of support for RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands
WI code:	NR_NTN_Ph3
Release:	Rel-19
Document for:		Discussion and Decision

Conclusion
In this contribution we have made the following observations and proposals: 
Observation 1: The gNB can be aware of potential DL-UL collisions based on knowledge about UE’s timing advance.
Observation 2: Support for TA reporting is an optional feature for the UE, which means that the gNB will potentially not be aware of the timing advance applied at the UE side.
Observation 3: The gNB scheduler may have TA awareness with high or low accuracy depending on the report type, report granularity, and report periodicity.
Observation 4: The UE needs a valid SIB19 to pre-compensate uplink transmissions in NTN and thereby have valid UL synchronization.
Observation 5: The network scheduler is not aware when the UE will attempt to reacquire SIB19 and thus uplink transmission resources, scheduled for time instances where the UE is acquiring SIB19, may be wasted.
Observation 6: The occurrence of collision case 4 can be minimized if the UE provides TA reports and SIB19 validity information.

Proposal 1: RAN1 to define UE Timing Advance reporting is mandatory for Rel-19 half-duplex FDD (e)RedCap UEs operating in NTN.
Proposal 2: RAN1 shall not pursue TA report (granularity, drift rate) enhancements.
Proposal 3: A smaller offsetThresholdTA will lead to increased signalling overhead (more frequent reports) and shall not be pursued by RAN1.
Proposal 4: RAN1 to define the UE may trigger a Timing Advance report if a collision is detected by the UE.
Proposal 5: RAN1 to discuss how to ensure UE and network scheduler have a common understanding of the remaining validity duration of the UE’s current SIB19.  
Proposal 6: RAN1 to discuss the UE may report information regarding the UE’s current SIB19 validity (or validity timer) to ensure a common understanding of which SIB19 reception occasions are prioritized by the UE for SIB19 reacquisition.
Proposal 7: RAN1 to confirm the working assumption of RAN1 #120 for collision case 4 and to assume downlink is prioritized by default.
Proposal 8: The UE shall prioritize uplink (transmission of PRACH) upon receiving a PDCCH order, until the UE has transmitted the PRACH.
Proposal 9: After transmission of PRACH triggered by PDCCH order the UE shall prioritize downlink until reception of msg2/RAR in case uplink is the default priority.
Proposal 10: RAN1 to define the UL priority configuration is common across CSS type-0/0A/1/2.
Proposal 11: RAN1 to continue the discussion on higher layer parameters for network configuration of UL prioritization for collision case 3 & collision case 4 based on the below:
Proposal 12: RAN1 to further discuss whether additional RRC parameters are needed.

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

Source:               TCL
Title:                    Discussion on HD-FDD Redcap UEs and eRedCap UEs for FR1-NTN
Agenda item:      9.11.2
Document for:    Discussion and Decision

Conclusion
In this contribution, the following observations and proposals have been made:
Observation1: For HD-FDD Redcap UEs and eRedCap UEs in FR1-NTN, if the collision between DL reception and UL transmission is avoided based on the gNB scheduling mechanism, resources waste will occur due to TA reporting granularity. 
Observation2: For HD-FDD Redcap UEs and eRedCap UEs in FR1-NTN, if the collision between DL reception and UL transmission is avoided based on the gNB scheduling mechanism, resources waste will occur due to misalignment of TA between gNB and UE.
Proposal 1: For HD-FDD Redcap UEs and eRedCap UEs in FR1-NTN, TA reporting with finer granularity can be considered. 
Proposal 2: For HD-FDD Redcap UEs and eRedCap UEs in FR1-NTN, it is recommended to consider frequent TA updates to ensure the gNB is informed of the actual TA in a timely manner. 
Proposal 3: The collision case 4 (Dynamically scheduled DL reception collides with dynamic scheduled UL transmission) is not considered as an error case for Rel-19 HD-FDD (e)Redcap UE in RRC connected mode. 
default priority rule for collision case 4 in RRC-Connected mode is that DL is prioritized.
4. 

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

Agenda Item:	9.11.2
Source:	Apple
Title:	Discussion on support of RedCap UEs with NR NTN operation   
Document for:	Discussion/Decision

Conclusion
In this contribution, we provided our views on HD-FDD RedCap UE with NTN operation. Our proposal are as follows:
Proposal 1: For Rel-19 NTN HD-FDD (e)Redcap UE in RRC connected mode, the following handling rule for collision case 4 is supported:
Handling of collision with PDSCH (at least for system information) scheduled by Type-0/0A/1/2-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
For other use cases, default priority rule for collision case 4 in RRC-Connected mode is that DL is prioritized.
Network is allowed to indicate UL overriding DL for all cases
This is signaled by one UE specific RRC parameter
Note: if DL is prioritized, the DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.
Note: UE shall comply to the following existing procedure in 38.331:
UEs in RRC_CONNECTED shall monitor for SI change indication in any paging occasion at least once per modification period if the UE is provided with common search space, including pagingSearchSpace, searchSpaceSIB1 and searchSpaceOtherSystemInformation, on the active BWP to monitor paging, as specified in TS 38.213 [13], clause 13. 
Proposal 2: For multiple collision scenarios, UE implementation determines whether to prioritize UL transmission or DL reception, with the restriction that the priority rules for collision case 3 and case 4 are not violated.
Proposal 3: RAN1 to consider finer TA report granularity to mitigate the TA mismatch issue.
Proposal 4: RAN1 to support UE detected collisions as one of the conditions for the TA report triggering. 

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

Source:	Sharp
Title:	Support of (e)RedCap UEs with NR NTN
Agenda Item:	9.11.2
Document for:	Discussion and Decision

Conclusion
In this paper, we discussed some of the outstanding issues for support of (e)RedCap UEs with NR NTN and proposed the following:
Proposal 1: Revoke to revise the working assumption from RAN1#120 to allow network configuration of priority rules for collision case 4 based on the type of dynamically scheduled channels or signals. A default priority by configuration can also be considered.
Proposal 2: Consider the timing of receiving the DCI messages by the UE for determining the priority of the DL or UL scheduled by the DCI messages in collision case 4.
Proposal 3: Support TA reporting enhancements to avoid, or reduce the probability of, DL-UL collisions due to TA mismatch. For example, consider reporting the TA difference and indication of DL-UL collisions.

3GPP TSG RAN WG1 #120bis												   R1-2502696
Wuhan, China, April 7th – 11th, 2025
Agenda Item:	9.11.2
Source:	HONOR
Title:	Discussion on support of (e)RedCap UEs in NR NTN 
Document for:	Discussion and Decision

Conclusions
In this contribution, we analzyed potential issues of the operation of (e)RedCap UEs in NTN, and the observations and proposals are presented as follows:
Observation 1: TA mismatch between gNB and UE may be very large, which may lead to a large loss of system throughput in NTN.
Proposal 1: Confirm the working assumption of RAN1#120 with revisions as follows:
For Rel-19 NTN HD-FDD (e)Redcap UE in RRC connected mode, the following handling rule for collision case 4 is supported:
Handling of collision with PDSCH (at least for system information) scheduled by Type-0/0A/1/2-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
For other use cases, default priority rule for collision case 4 in RRC-Connected mode is that DL is prioritized.
Network is allowed to indicate UL overriding DL for all cases
This is signaled by one UE specific RRC parameter
Note: the DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.
Note: UE shall comply to the following existing procedure in 38.331:
UEs in RRC_CONNECTED shall monitor for SI change indication in any paging occasion at least once per modification period if the UE is provided with common search space, including pagingSearchSpace, searchSpaceSIB1 and searchSpaceOtherSystemInformation, on the active BWP to monitor paging, as specified in TS 38.213 [13], clause 13. 
Proposal 2: Enhanced TA report mechanism including fine TA report granularity and TA drifting rate reporting should be considered in R19 NR NTN.
Proposal 3: RAN1 to consider the collision number during a period as one of the conditions for the TA report triggering. 

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

Agenda Item:	9.11.2
Source:	MediaTek Inc.
Title:	Support of RedCap and eRedCap UEs with NR NTN operating in FR1-NTN bands
Document for:	Discussion and Decision 


1 

Conclusion
In this contribution, the following observations and proposals were made:

TA reporting:
Observation 1: A smaller value than 0.5 ms for offsetThresholdTA-r17 requires a TA report granularity smaller than 1 ms, increases signalling overhead and may not improve slot-based scheduling since the gNB scheduler schedule resources on a slot basis.

Proposal 1: A RedCAp UE may trigger a Timing Advance report if a collision is detected by the UE.

HD collision rules Case 4:
Proposal 2: Confirm Working assumption with the following revisions (the notes are unchanged): 
For Rel-19 NTN HD-FDD (e)Redcap UE in RRC connected mode, the following handling rule for collision case 4 is supported:
Handling of collision with PDSCH (at least for system information) scheduled by Type-0/0A[/1][/2]-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
FFS: handling of PDCCH ordered PRACH transmission
For other use cases, default priority rule for collision case 4 in RRC-Connected mode is that [DL or UL] is prioritized.
Network is allowed to indicate [UL or DL] overriding [DL or UL] for all cases for PDCCH ordered PRACH transmission 
This is signaled by one UE specific RRC parameter
6 

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

Source:	NTT DOCOMO, INC.
Title:	Discussion on support of RedCap and eRedCap UEs in FR1-NTN
Agenda Item:	9.11.2
Document for: 	Discussion and Decision

Conclusion
In this contribution, we discussed support of RedCap/eRedCap UEs in FR1-NTN. Observations/Proposals are summarized as following: 
Proposal 1:
For HD-FDD RedCap/eRedCap UE in Case 4, prioritize DL by default.
Proposal 2:
For HD-FDD RedCap/eRedCap UE in Case 4, remove the first bullet of the working assumption reached in RAN1#120.
Proposal 3:
For HD-FDD RedCap/eRedCap UE in Case 4, NOT support special handling for PDCCH ordered PRACH.
Proposal 4:
For HD-FDD RedCap/eRedCap UE in Case 3 and Case 4,
Define a new mechanism to achieve the same understanding between gNB and UE, of 1) actual TDWs in PUSCH DMRS bundling and 2) PUSCH slot counting in PUSCH repetition type A, e.g.,
Event indication from UE, e.g., information on when an event occurs (e.g., 2 slots later), is multiplexed at the beginning of the UL transmission.
Observation 1:
When scheduling margin is not considered, benefit of TA report with finer granularity is not found. In slot-level TA report, gNB can know slots with potential overlap.
Observation 2:
When scheduling margin is considered, what TA report with finer granularity achieves is possible by slot-level TA report with half-slot offset, without additional overhead.
Proposal 5:
For HD-FDD RedCap/eRedCap UE, TA report with granularity smaller than 1 ms is NOT supported.
Proposal 6:
For HD-FDD RedCap/eRedCap UE, TA report with half-slot offset is supported.
i.e., ‘0’ in TAR MAC CE means 0.5 ms, ‘1’ in TAR MAC CE means 1.5 ms, and so on.
Proposal 7:
For HD-FDD RedCap/eRedCap UE, both of the following schemes are supported for TA report enhancement.
Scheme 1: Trigger a UL TX when the collision is detected at the UE
If PUSCH for the report is available, TA is reported.
Otherwise, SR for TA report is transmitted.
Scheme 2: Trigger a TA report by gNB indication in DCI or MAC-CE
Proposal 8:
For HD-FDD RedCap/eRedCap UE, discuss how to handle more than two overlaps and define handling rule.

3GPP TSG RAN WG1 #120bis					        R1- 2502816
Wuhan, China, April 7th – 11th, 2025
Agenda Item:	9.11.2
Source: 	LG Electronics
Title: 	Discussion on support of (e)RedCap UEs with NR-NTN operating in FR1-NTN bands
Document for:	Discussion and decision

Conclusions
In this contribution, we discussed whether or how to change half-duplex collision rules to support (e)RedCap UEs with NR NTN in FR1. Based on the above discussion, our observations and proposals are given as follows:

Observation #1: Defining DL/UL priority rule(s) does not address the resource utilization inefficiencies.
Observation #2: If the network is unaware of collision decision at the UE, resource inefficiency may occur.

Proposal #1: For collision case 3, it is necessary to clarify the validity period of network overriding.
Proposal #2: For collision case 4, support default priority rule that UL is prioritized.
Network is allowed to indicate DL overriding UL for all cases
Proposal #3: For collision case 4, support the following exceptional handling.
Handling of collision with PDSCH for system information scheduled by Type-0/0A/2-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
Proposal #4: RAN1 clarify that it is expected for (e)RedCap UE to resolve DL/UL collisions sequentially along the time axis.
Proposal #5: For collision cases 3 and 4, support TA reporting with the following enhancement(s):
Finer TA report granularity
Smaller TA offset threshold
Proposal #6: For collision cases 3 and 4, consider aligning the decisions about DL/UL collisions assumed by the network and the UE respectively based on reported TA.
Proposal #7: For UL transmission colliding with SSB, the UE behavior enhancement for collision cases 3 and 4 can be applied to align the DL/UL collision decision between UE and network, and available slot can be counted based on the non-collisional UL slots.
Proposal #8: For actual TDW determination, the UE behavior enhancement for collision cases 3 and 4 can be applied to align the DL/UL collision decision between UE and network, and actual TDW can be determined based on the non-collisional UL slots.

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

Agenda item:	9.11.2
Source: 	Qualcomm Incorporated
Title: 	Support of RedCap and eRedCap UEs in NR NTN
Document for:	Discussion/Decision

Conclusion
For Rel-19 HD-FDD (e)Redcap UE with CG-SDT procedure ongoing in RRC-inactive mode, for collision case 3, 
Handling of collision with PDCCH CSS in RRC-inactive mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
Note: UE shall comply to the following existing procedure in 38.331:
UEs in RRC_INACTIVE while SDT procedure is not ongoing shall monitor for SI change indication in its own paging occasion(s) that the UE monitors as specified in TS 38.304 [20].
UEs in RRC_INACTIVE while SDT procedure is ongoing shall monitor for SI change indication in any paging occasion at least once per modification period, if the initial downlink BWP on which the SDT procedure is ongoing is associated with a CD-SSB.
ETWS or CMAS capable UEs in RRC_INACTIVE while SDT procedure is not ongoing shall monitor for indications about PWS notification in its own paging occasion every DRX cycle.
ETWS or CMAS capable UEs in RRC_INACTIVE while SDT procedure is ongoing shall monitor for indication about PWS notification in any paging occasion at least once every defaultPagingCycle.

Working assumption 
For Rel-19 NTN HD-FDD (e)Redcap UE in RRC connected mode, the following handling rule for collision case 4 is supported:
Handling of collision with PDSCH (at least for system information) scheduled by Type-0/0A[/1][/2]-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
FFS: handling of PDCCH ordered PRACH transmission
For other use cases, default priority rule for collision case 4 in RRC-Connected mode is that [DL or UL] is prioritized.
Network is allowed to indicate [UL or DL] overriding [DL or UL] for all cases
This is signaled by one UE specific RRC parameter
Note: if DL is prioritized, the DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.
Note: UE shall comply to the following existing procedure in 38.331:
UEs in RRC_CONNECTED shall monitor for SI change indication in any paging occasion at least once per modification period if the UE is provided with common search space, including pagingSearchSpace, searchSpaceSIB1 and searchSpaceOtherSystemInformation, on the active BWP to monitor paging, as specified in TS 38.213 [13], clause 13. 

In this contribution, we discuss priority rule and timeline issues for collision case 4, issues concerning slot counting/invalid symbols and TDW determination for PUSCH repetition, and TA enhancements for HD-FDD Redcap and eRedcap UEs when operating in NTN. 
Collision case 4
For collision case 4, a working assumption was made with the following two remaining issues:
Whether to have higher priority for UL or DL by default.
Handling of collision involving PDCCH ordered PRACH transmission is FFS.

Since collision 4 concerns dynamically scheduled transmissions, network should have the ability to avoid collisions for important dynamic transmissions. From this point of view, the priority rule should be focused on facilitating network making real-time scheduling decisions. In NR NTN, the scheduling DCI for a DL transmission often comes later than the DCI for the UL transmission that collides with the DL, due to unknown round-trip delay associated with the UE. From this point of view, DL should be prioritized by default since network can always not schedule the DL transmission if collision is deemed possible and a scheduled UL transmission is considered important. 
Typically, network will refrain from scheduling other transmissions to a UW with a PRACH being ordered until PRACH from the UE is detected. This is also true for Redcap and eRedcap UEs.  Hence, special handing via priority rules for DCI-ordered PRACH is not necessary.
Based on the above discussions, we propose to confirm the working assumption. 
Proposal 1: Confirm the working assumption for collision 4 priority rule as below:
For Rel-19 NTN HD-FDD (e)Redcap UE in RRC connected mode, the following handling rule for collision case 4 is supported:
Handling of collision with PDSCH (at least for system information) scheduled by Type-0/0A[/1][/2]-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
For other use cases, default priority rule for collision case 4 in RRC-Connected mode is that DL is prioritized.
Network is allowed to indicate UL  overriding DL  for all cases
This is signaled by one UE specific RRC parameter
Note: if DL is prioritized, the DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.
Note: UE shall comply to the following existing procedure in 38.331:
UEs in RRC_CONNECTED shall monitor for SI change indication in any paging occasion at least once per modification period if the UE is provided with common search space, including pagingSearchSpace, searchSpaceSIB1 and searchSpaceOtherSystemInformation, on the active BWP to monitor paging, as specified in TS 38.213 [13], clause 13. 

When a case 4 collision happens, there could be potential timeline issues. Shown in Figure 1 are two scenarios: when DL is prioritized and when UL is prioritized.  When UL is prioritized, the reception of the colliding DL transmission needs to be cancelled. Since UE can stop receiving a DL signal at any time, there is no timeline issue. However, when DL is prioritized, the DCI that schedules the DL transmission may come too late such that the UE has no time to stop the transmission process. Similar situation also happens in TDD where a UE not capable of partialCancellation is not required to drop the UL transmission if the first symbol of the UL transmission is within Tproc,2 of relative to the CORSERT where UE detects the DCI scheduling the DL transmission [Sec. 11.1 TS38.213]. Same rule can be applied here. For simplicity, Redcap UE and eRedcapUE does not need to support partialCancellation.


Figure 1. Timeline for collision case 4.

Proposal 2: When DL is prioritized for collision case 4, UE is not expected to cancel the UL transmission if its first symbol is within Tproc,2 relative to the CORSET where UE detects the DCI scheduling a DL transmission colliding with the UL transmission.
Note: for PUSCH, repetitions are considered as separate transmissions.

PUSCH repetitions and TBoMS
For HD-FDD (e)Redcap UE in TN, symbols or slots that collides with a DL transmission are considered as invalid resource for PUSCH repetitions and PUSCH TBoMS. In NR NTN, however, the exact UL symbols or slots that collide with a DL transmission may not be fully known to the network at the time of scheduling. If they are considered as invalid for PUSCH transmission, network have to overprovision the resource for PUSCH transmission. As in the example shown in Figure 2, even with TA report with symbol level accuracy, network may not know exactly which is the case for the UE when counting the slots for a PUSCH transmission. 







For NR NTN, it is therefore not desirable to count colliding UL slots/symbols as invalid for PUSCH repetition and TBoMS. Instead, dropping of the transmission of colliding repetitions or TDW is desirable.
Proposal 3:  For PUSH repetition and TBoMS for HD-FDD UEs in NR NTN, symbols colliding with DL transmissions are considered valid.
For PUSCH repetition Type A and TBoMS, UE drops the slot that has at least one symbol colliding with a prioritized DL transmission.
For PUSCH repetition Type B, UE drops the repetition that has at least one symbol colliding with a prioritized DL transmission.
For DMRS bundling, UE drops the actual TDW that has at least one symbol colliding with a prioritized DL transmission.


Enhanced TA report 
Although UE specific TA report is supported in NR NTN, it was designed for the network to configure appropriate UE specific scheduling delay, Koffset. As such, the granularity of the TA report is 1 ms. In addition, the reported TA indicates the least integer number of slots, using subcarrier spacing of 15 kHz, greater than or equal to the actual TA value, i.e., TAreport=ceil(TAactual) with 1ms granularity. As shown in Figure 3, there is an uncertainty of 1 ms about the actual TA of a UE even with TA report, and for each 1 ms slot used for  UL transmission, network has to assume 2 slots cannot used for DL transmission to the UE due to potential UL and DL collision. In addition, network may assume the TA is in the range of [TAmin, TAmax], where TAmin and TAmax are the minimal and maximal TAs for the cell, respectively. In both cases, the uncertainty about the transmission timing leads to additional loss in time for DL transmission. In the best case when UE TA report is available and up to date, every 1 slot of UL transmission leads to a loss of 2 slots for DL transmission. This means large loss of throughput when frequent DL/UL switching is needed. In the worst case, Ud+Uu<=1 where Ud and Uu are the DL and UL channel time usage in percentage, respectively. 


Figure 3.  Uncertainty about actual transmission time at gNB: a) based on UE TA report, b) based on maximal and minimal TA of the cell.


From the above, there may be excessive loss of throughput for a HD-FDD UE in NR NTN and additional scheduling constraints. For example, for a UE with TAreport=10 and a scheduled UL transmission for slot n+10, the gNB may not send any PDCCH or PDSCH to the UE in slots n and n+1. If the gNB knows that the TA is exactly 9 ms plus 11 symbols, then the gNB can still send PDCCH to the UE in slot n and a PDSCH in slot n+1 as shown in the figure below.

Figure 4. DL and UL scheduling when gNB knows accurate TA of the UE. 
As discussed above, accurate knowledge about the TA of a HD-FDD UE allows gNB more scheduling opportunities and improves the throughput of the UE. Hence, existing TA report should be made mandatory.
Proposal 4: For HD-FDD UEs in NR NTN, UE feature FG 26-4 is mandatory.
To allow subslot scheduling, the granularity of the TA report should be one symbol duration or less.
Proposal 5: For HD-FDD UEs in NR NTN, support an enhanced TA report with the granularity of the duration of a UL symbol.  
One concern about TA report with finer granularity is the associated complexity and power consumption due to more frequent TA reporting. With TA report granularity of one symbol duration, a UE may have to frequently report the TA (e.g., less than one second after last report) if the report is triggered by TA change of half or 1 symbol duration. In practice, network can estimate the TA in the future using, for instance, the TA drift rate of the UE at the beam center. Consider a beam footprint of 50 km served by a satellite at 600 km orbit, the maximal TA drift rate uncertainty is 1 ppm which occurs at the Nadir beam. Consequently, if network use the TA drift of the beam center to estimate a UE’s future TA, the error is less than 10ms after 10s. Hence, TA reporting periodicity does not have to be shorter than 10 seconds if periodic reporting is used. 
Observation 1: TA report trigger based on TA change is not appropriate for report with finer granularity. For TA tracking accuracy less than half of symbol duration at Network, the periodicity of TA report can be far larger than 10 seconds.
Proposal 6: For HD-FDD UEs in NR NTN, support periodic report of enhanced UE TA report.

Summary
In this contribution, we have discussed priority rules and timeline issues for collision case 4, slot counting and TDW determination when PUSCH repetitions colliding with a DL transmission, and enhancements to TA report. Observations and proposals are listed below:
Proposal 1: Confirm the working assumption for collision 4 priority rule as below:
For Rel-19 NTN HD-FDD (e)Redcap UE in RRC connected mode, the following handling rule for collision case 4 is supported:
Handling of collision with PDSCH (at least for system information) scheduled by Type-0/0A[/1][/2]-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
For other use cases, default priority rule for collision case 4 in RRC-Connected mode is that DL is prioritized.
Network is allowed to indicate UL  overriding DL  for all cases
This is signaled by one UE specific RRC parameter
Note: if DL is prioritized, the DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.
Note: UE shall comply to the following existing procedure in 38.331:
UEs in RRC_CONNECTED shall monitor for SI change indication in any paging occasion at least once per modification period if the UE is provided with common search space, including pagingSearchSpace, searchSpaceSIB1 and searchSpaceOtherSystemInformation, on the active BWP to monitor paging, as specified in TS 38.213 [13], clause 13. 

Proposal 2: When DL is prioritized for collision case 4, UE is not expected to cancel the UL transmission if its first symbol is within Tproc,2 relative to the CORSET where UE detects the DCI scheduling a DL transmission colliding with the UL transmission.
Note: for PUSCH, repetitions are considered as separate transmissions.

Proposal 3:  For PUSH repetition and TBoMS for HD-FDD UEs in NR NTN, symbols colliding with DL transmissions are considered valid.
For PUSCH repetition Type A and TBoMS, UE drops the slot that has at least one symbol colliding with a prioritized DL transmission.
For PUSCH repetition Type B, UE drops the repetition that has at least one symbol colliding with a prioritized DL transmission.
For DMRS bundling, UE drops the actual TDW that has at least one symbol colliding with a prioritized DL transmission.

Proposal 4: For HD-FDD UEs in NR NTN, UE feature FG 26-4 is mandatory.

Proposal 5: For HD-FDD UEs in NR NTN, support an enhanced UE specific TA report with the granularity of the duration of a UL symbol.  

Observation 1: TA report trigger based on TA change is not appropriate for report with finer granularity. For TA tracking accuracy less than half of symbol duration at Network, the periodicity of TA report can be far larger than 10 seconds.

Proposal 6: For HD-FDD UEs in NR NTN, support periodic report of enhanced UE TA report.

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

Agenda item:		9.11.2
Source:	Nordic Semiconductor ASA
Title:					Support of RedCap and eRedCap UEs in NR NTN
Document for:		Discussion and Decision

Conclusions

In this contribution we discussed issues related to RedCap and eRedCap UEs in NR NTN system, and we have the following proposals:
Proposal 1: For Rel-19 NTN HD-FDD (e)Redcap UE in RRC connected mode, the following handling rule for collision case 4 is specified:
Handling of collision with PDSCH scheduled by Type-0/0A-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the following note.
For other use cases, default priority rule for collision case 4 in RRC-Connected mode is that DL is prioritized.
Network is allowed to indicate UL overriding DL for all collision cases
This is signaled by one UE specific RRC parameter
Note: The DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.

Note: UE shall comply to the following existing procedure in 38.331:
UEs in RRC_CONNECTED shall monitor for SI change indication in any paging occasion at least once per modification period if the UE is provided with common search space, including pagingSearchSpace, searchSpaceSIB1 and searchSpaceOtherSystemInformation, on the active BWP to monitor paging, as specified in TS 38.213 [13], clause 13. 
Proposal 2: Do not specify any changes to the existing TA reporting scheme.

TDoc file reading error

TDoc file reading error

TDoc file reading error

TDoc file reading error