3GPP TSG-RAN WG1 Meeting #121	R1-2503281
St Julian’s, Malta, May 19 – 23, 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: When a UE loses UL synchronization, this does not mean that the UE has lost its DL synchronization nor that it will not be able to receive any critical DL signals/channels.
Observation 4: 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 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) irrespective of the slot duration      
Observation 6: Based on the SLS results assessing the gains in reducing the ratio of cancelled CG PUSCH resources under Cases 1/3 for the legacy and enhanced TA reporting schemes employing different values of report granularity and triggering offset threshold, the following conclusions can be made:
Compared to a No-TAR scheme, legacy TAR with 1ms report granularity achieves a gain of 24% reduction in the ratio of CG PUSCH cancellation
Results conform to the group’s intuition that is no further gain is expected from the legacy 1ms TAR even if new values < 0.5 ms are introduced for the triggering offset threshold
Taking the legacy 1ms TAR with the 0.5ms threshold as the baseline scheme, 
Introducing finer TAR granularity without introducing new values < 0.5 ms for the triggering offset threshold does not provide any further relative gain
Enhanced TAR schemes with granularity finer than 1 ms, can achieve relative gains up to 39% or 12% with new triggering thresholds of 0.05 ms or 0.1ms, respectively
If eTAR employs TA delta reporting with 1-Octet MAC CE, the 50% saving in signalling overhead helps to offset the increased triggering frequency
Observation 7: Despite the priority rules defined in Rel-19 for HD-FDD collision handling in Cases 3 and 4, performance evaluations considering gNB resource reservations for HD-FDD collision avoidance are still relevant to the (e)RedCap UEs that do not indicate the new Rel-19 capability of handling Case 3/4 collisions.
Observation 8: 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, especially UEs incapable of handling Cases 3/4 
-	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 27% to 40% more resources are released for UL when the threshold ranges from 0.5ms to 0.05ms.
-	Enhanced TAR scheme with 13us granularity 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, the relative gain is from 8.5% to 3.5% when the triggering threshold ranges from 0.5ms to 0.05ms, respectively. 
Proposal 1: For collision case 4 (dynamic DL and dynamic UL), the updated WA from RAN1#120bis can be confirmed by removing “at least for system information” and FFS points of the exceptional use case for PDCCH-ordered PRACH. 
Proposal 2: RAN1 to clarify in a conclusion that for Case 4, collision with a PDSCH scheduled by Type 0/0A/1/2-PDCCH CSS is excluded from both, the default UE behaviour, i.e., DL reception is prioritized, and when network override is configured via RRC (TP#1 in R1-2503281 can be endorsed for reference).   
Proposal 3: RAN1 supports enhanced TA reporting with at least a configurable report granularity finer than 1ms, i.e., X µs, and triggering offset threshold values less than 0.5 ms
Note: Assuming a maximum TA of 520 ms, for a 16-bit MAC CE, X ≥ 7.9351 µs (or 15601*Tc)
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 (e)TAR at gNB.
Proposal 5: To conclude on the issue of collisions with more than two Transmissions/Receptions, clarify the following:
the issue results from collisions involving more than one UL transmission or one DL reception
the more than one UL transmissions or DL receptions involved are as determined by the UE based on the actual TA
Proposal 6: RAN1 to discuss the proposed corrections to the RRC parameters in Table 4 and include the outcome in the LS to RAN2.

3GPP TSG RAN WG1 #120                                                                            R1-2503325
Malta, MT, May 19th – 23th, 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 out-of-sync recovery, it is more important to inform gNB TA mismatch than PDCCH order completion.
Observation 2: 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 3: The DTX detection of HARQ-ACK feedback may be not applicable for collision indication because DL HARQ feedback is probably disabled in NTN scenario.
Proposal 1: For the scenario of handling of PDCCH ordered PRACH transmission 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.
Observation 4: Finer TA report granularity may impact other timing signaling (e.g. Koffset) but bring limited benefit.
Proposal 2: No enhancement for finer TA report granularity in FR1-NTN.
Observation 5: 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 3: Introducing enhanced TA report with TA drifting information.
Proposal 4: The TA drifting information should include TA drift rate, TA drift variant rate and effective period at least. 
Proposal 5: No smaller TA offset threshold for TA report enhancement.
Proposal 6: It should be supported to trigger a TA report when the collision is detected at the UE.
Proposal 7: It should not be supported to trigger a TA report from gNB.

3GPP TSG-RAN WG1 Meeting #121	R1-2503337
St Julian’s, Republic of Malta, May 19th – 23rd, 2025
Agenda Item:	9.11.2
Source:	Ericsson
Title:	On HD-FDD Redcap UEs for NTN
Document for:	Discussion

1	

Conclusion: For HD-FDD (e)RedCap in NTN, no TA report enhancements are supported in Rel-19.

5	

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

Source:	vivo
Title:	Remaining issues 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: According to the note in the working assumption, the UL cancellation timeline is up to UE implementation.
Observation 2: It is very difficult and complicated to define the prioritization rule for multiple collision cases.
Observation 3: 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 4: 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: 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 PDCCH CSS is left to UE implementation.
Proposal 2: Handling of collision with PDCCH order triggered PRACH can follow the priority rule and controlled by the network indication.
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-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the note2.
Handling of collision with PDSCH scheduled by Type-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 note2.
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 is prioritized.
Network is allowed to indicate UL overriding DL for all cases
This is signaled by one UE specific RRC parameter
Note1: if DL is prioritized, the DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.

Note2: 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: Delete the condition "operating on a non-NTN serving cell" to include UEs operating in NTN that do not support these new capabilities, and add ‘subject to UE capability’ or ‘UE may determine’ to properly reflect that the behavior is dependent on whether the UE supports the new capability.
Proposal 5: The handling collision case of PDSCH scheduled by a PDCCH in type 0/0A/1/2 CSS should be excluded in the ‘other use cases’ for case 4 (i.e., It should not be controlled by the RRC parameter ntnRedCapCollisionCase4UlPriority).
Proposal 6: Adopt TP#1.
Proposal 7: 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 8: No enhancement on TA report in Rel-19.

3GPP TSG RAN WG1 #121			R1-2503528
St Julian’s, Malta, May 19th – 23th, 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.
Handling of collision with all types of 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 note2.
PDCCH ordered PRACH is not an exception case in case 4
UL cancellation timeline is satisfied 
If the first symbol of PUCCH or PUSCH is after  relative to a last symbol of the PDCCH scheduling CSI-RS or PDSCH.
If a symbol of SRS is after  relative to a last symbol of the PDCCH scheduling CSI-RS or PDSCH.
ntnRedCapCollisionCase4UlPriority is only allowed to indicate UL overriding DL other than PDSCH scheduled by PDCCH reception according to a Type0/0A/1/2-PDCCH CSS set.
No enhancement of TA report is introduced in Rel-19 NTN.

3GPP TSG RAN WG1 #121    		                           R1-2503583
St Julian’s, Malta, May 19th – 23th, 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: Update the agreement made in RAN1#120b meeting as following,
Agreement
Update the working assumption in RAN1 #120 with the following updates: 
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 note2.
Handling of collision with PDSCH scheduled by Type-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 note2.
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 is prioritized.
Network is allowed to indicate UL overriding DL for all cases
This is signaled by one UE specific RRC parameter
Note1: if If DL is prioritized, the DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.

Note2: 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: Deprioritize the discussion on TA reporting enhancements. 

3GPP TSG RAN WG1 #121                                                 R1-2503636
St Julian’s, Malta, May 19th – 23th, 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 updated working assumption reached in RAN1 #120bis 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 Meeting #121	  R1-2503775
St Julian's, Malta, 19 - 23 May, 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:
For the collision case between a UE-specific PDSCH scheduled by Type1-PDCCH CSS and dynamic UL, it will provide more freedom if leaving it to UE implementation.
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. 

Handling of collision with PDSCH (other than 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 note2. 
The collision with PDCCH ordered PRACH transmission is a corner case, no special treating for this case.
There is no need to define new uplink cancellation timeline in NTN.
Update the agreement in RAN1 #120bis with the following updates: 
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 note2.
Handling of collision with PDSCH scheduled by Type-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 note2.
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 is prioritized.
Network is allowed to indicate UL overriding DL for all cases
This is signaled by one UE specific RRC parameter
Note1: if DL is prioritized, the DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.

Note2: 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 #121                                  			               R1-2503813
St Julian’s, Malta, May 19th – 23th, 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 issues a PDCCH ordered PRACH to a UE that has lost UL synchronization. 
Observation 2: 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 3: For case 4 with UL transmission being PDCCH order PRACH, the priority is UL and is evaluated at the UE prior to “other use cases” in the current working assumption.
Observation 4: It is unlikely that PDCCH order PRACH UL transmission collides with PDSCH scheduled by a Type 1 or Type 2 PDCCH. 
Observation 5: Due to periodic SIB1 transmissions, PDCCH order PRACH UL transmission should be prioritized over SIB1, i.e., over PDSCH scheduled by Type 0 PDCCH. 
Observation 6: Due to multiple repetitions of SIB19 in each validity period, PDCCH order PRACH UL transmission should be prioritized over SIB19, i.e., over PDSCH scheduled by Type 0A PDCCH. 
Observation 7: 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 8: Finer TA granularity provides little help against TA drift despite the increased reporting overhead. 
Observation 9: 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 UEs in RRC connected mode, for collision case 4 if the UL transmission is a PDCCH-ordered-PRACH, the UL is prioritized.

Proposal 2: Agree to the following update of the 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:
For collisions involving PDCCH ordered PRACH transmissions, UL is prioritized.
For collisions not involving PDCCH ordered PRACH transmissions, 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 note2.
For collisions not involving PDCCH ordered PRACH transmissions, handling of collision with PDSCH scheduled by Type-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 note2.
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 is prioritized.
Network is allowed to indicate UL overriding DL for all cases
This is signaled by one UE specific RRC parameter
Note1: if DL is prioritized, the DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.

Proposal 3: Support UE configuration to trigger TA reporting upon detecting HD-FDD collision.

Proposal 4: Support 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 #121			                                                            R1-2503846
St Julian’s, Malta, May 19th – 23th, 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: 
Finer TA granularities will not help the gNB to solve the ambiguity issue for scheduling, considering most scheduling is slot-level. And finer TA granularity may also have the potential issue of leaking the UE’s position.

Observation 3: 
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 4: 
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 5: 
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 6: 
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 7: 
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 8: 
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 9: 
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 the collision case 4, the priority of C-RNTI scrambled and/or scheduled PDSCH by Type-0/0A/1/2-PDCCH CSS can be left to UE’s implementation. Namly, the 1st and 2nd bullet in the current working assumption can be agreed as current format. 
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 note2.
Handling of collision with PDSCH scheduled by Type-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 note2.

Proposal :
There is no need to define priority rule for PDCCH ordered PRACH transmission. i.e. the handling of PDSCH ordered PRACH transmission can be removed. 

Proposal :
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 :
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 #121			R1-2503896
St Julian’s, Malta, May 19th – 23rd, 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 in RAN1#120bis
Confirm the working assumption in RAN1 #120bis
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 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 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:

Proposal 2: Finer TA report granularity (less than 1ms) is not needed to be further studied to mitigate the collisions of case 3 and case 4.

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 #121			                                         R1-2504104
St Julian’s, Malta, May 19th – 23rd, 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: Don’t introduced special handling rule for PDCCH ordered PRACH transmission in collision case 4.
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 #121	R1-2504150
St Julian’s, Malta, May 19th – 23th, 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. Confirm the WA from RAN1#120b with the following revision:

Proposal 3. For multiple collision scenarios, down-select one among the following options:
Option 1: For multiple collision case, a HD-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
Option 2: For multiple collision case, collision handling is up to UE implementation

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

3GPP TSG RAN WG1 #121	R1-2504180
St Julian, Malta, 19 – 23 May 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 #120bis for collision case 4.
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 for collision case 3.
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 #121		R1-2504200
St Julian’s, Malta, May 19th - 23th, 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 discuss remaining issues on supporting of RedCap and eRedCap UEs with NR NTN. The following proposals are provided.
Proposal 1: For UE in RRC-Connected mode with collisions between PDCCH ordered PRACH and DCI scheduled PDSCH, 
If DCI scheduled PDSCH is associated with uplink transmission, PDCCH ordered PRACH should have a higher priority;
Otherwise, it is left to UE implementation whether to prioritize UL or DL.
Proposal 2: Adopt the following TP#1 to reflect the impact of TA misalignment for determining collision cases for an NTN HD-UE in specification.
---------------------- start of TP#1 ------------------------
A half-duplex UE (HD-UE) in paired spectrum is not capable of simultaneous transmissions and receptions on a serving cell with paired spectrum. For a HD-UE operating on an NTN serving cell, the transmissions should include the effect of the timing advance. This clause is applicable for communication of a HD-UE on a serving cell with paired spectrum. Procedures for a HD-UE are same as described for a UE in all other clauses of this document unless stated otherwise. 
A HD-UE operating on a non-NTN serving cell does not expect to detect a DCI format scheduling a reception in a set of symbols and detect a DCI format scheduling a transmission in any symbol from the set of symbols. A HD-UE operating on an NTN serving cell in the RRC_CONNECTED state determines based on its implementation whether to either receive in a set of symbols a PDSCH scheduled by a DCI format provided by a PDCCH the HD-UE received according to a Type0/0A/1/2-PDCCH CSS set, or transmit in any symbol from that would overlap with the set of symbols a PUSCH/PUCCH/SRS scheduled by a DCI format.  
----------------
If a HD-UE is configured by higher layers to transmit SRS, or PUCCH, or PUSCH in a set of symbols, or if a HD-UE operating on an NTN serving cell is not provided ntnRedCapCollisionCase4UlPriority and detects a DCI format indicating to the HD-UE to transmit SRS, or PUCCH, or PUSCH in a set of symbols, and the HD-UE operating on a non-NTN serving cell detects a DCI format indicating to the HD-UE to receive CSI-RS or PDSCH in a subset of symbols from the set of symbols, or if the HD-UE operating on an NTN serving cell detects a DCI format indicating to the HD-UE to receive CSI-RS or PDSCH in any symbol that would overlap with the set of symbols, then 
----------------
If a HD-UE operating on an NTN serving cell is provided ntnRedCapCollisionCase4UlPriority and detects a DCI format indicating to the HD-UE transmit SRS, or PUCCH, or PUSCH in a set of symbols, and the HD-UE detects a DCI format indicating to the HD-UE to receive CSI-RS or PDSCH in any symbol from that would overlap with the set of symbols, the HD-UE does not receive the CSI-RS or PDSCH. 
----------------
If a HD-UE would transmit a PRACH or MsgA PUSCH triggered by higher layers in a set of symbols and would receive a PDCCH, or a PDSCH, or a CSI-RS, or a DL PRS, or is indicated presence of SS/PBCH blocks within the active DL BWP by ssb-PositionsInBurst in SIB1 or in ServingCellConfigCommon or by NonCellDefiningSSB in symbols that include any symbol from the set of symbols for operating on a non-NTN serving cell, or in symbols that would overlap with any symbol from the set of symbols for operating on an NTN serving cell, the HD-UE can select based on its implementation whether to either transmit the PRACH or the MsgA PUSCH or receive the PDSCH, or the CSI-RS, or the PL RS, or the PDCCH, or the SS/PBCH blocks.
---------------------- end of TP#1 ------------------------

3GPP TSG RAN WG1 Meeting #121	R1-2504271
St Julian's, Malta, 19th -23rd May, 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:

HD collision rules Case 4:
Proposal 1:  Handling of PDCCH ordered PRACH transmission is up to device implementation. 

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 schedules resources on a slot basis.

Observation 2: The network may not be able to determine whether a RedCAp UE triggered a Timing Advance report if a collision is detected by the UE or some other events.

6 

3GPP TSG RAN WG1 #121			R1-2504343
St Julian’s, Malta, May 19th – 23th, 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: Update the working assumption as follow,
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 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 note2.
Handling of collision with PDSCH scheduled by Type-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 note2.
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
Note1: if DL is prioritized, the DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.
Note2: 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 #121			R1-2504411
St Julian’s, Malta, May 19th – 23th, 2025

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

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-PDCCH CSS in RRC-Connected mode is left to UE implementation whether to prioritize UL or prioritize DL with the constraint in the note2.
Handling of collision with PDSCH scheduled by Type-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 note2.
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
Note1: if DL is prioritized, the DL prioritization applies only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.

Note2: 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 #120-bis			R1-2504432
St Julian’s, Malta, May 19th – 23rd, 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 provided the following observation and proposals:
Observation 1: The working assumption on handling collision case 4 has multiple problems. Notably, the solution lacks flexibility for network configuration; the method can potentially cause ambiguity between NW and UE; and the UE behaviour cannot be captured in the specifications.
Proposal 1: Revoke or revise the working assumption on collision case 4 to allow network configuration of priority rules 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 #121	R1-2504516
St Julian’s, Malta, May 19th – 23rd, 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, NOT support special handling for PDCCH ordered PRACH, i.e., 
Confirm the working assumption with removing the FFS bullet.
Proposal 2:
For HD-FDD RedCap/eRedCap UE in Case 3 and Case 4, for DMRS bundling, 
Two actual TDWs divided due to HD-FDD are dropped.
Proposal 3:
For HD-FDD RedCap/eRedCap UE in Case 3 and Case 4, for PUCCH/PUSCH slot counting in repetitions, 
A dropped slot due to HD-FDD is counted as a valid slot.
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, the same as what TA report with finer granularity achieves is possible by slot-level TA report with half-slot shift in 1 ms granularity, without additional overhead.
Proposal 4:
For HD-FDD RedCap/eRedCap UE, TA report with granularity smaller than 1 ms is NOT supported.
Proposal 5:
For HD-FDD RedCap/eRedCap UE, TA report with half-slot shift in 1 ms granularity 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 6:
For HD-FDD RedCap/eRedCap UE, trigger a TA report 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.
Proposal 7:
For HD-FDD RedCap/eRedCap UE, discuss how to handle more than two overlaps and define handling rule.

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

3GPP TSG RAN WG1 #121						        R1- 2504562
St Julian’s, Malta, May 19th – 23rd, 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: For collision case 4, collision handling is determined when the UL cancellation timeline is satisfied.
Observation #2: The PDCCH processing/buffering issue can occur in collision case 2, where they can be more problematic.

Proposal #1: For collision case 4, exception handling should be allowed only if UE can decide whether to receive DL or not (e.g., system information).
Proposal #2: For collision case 4, SIB (Type 0/0A, SI-RNTI), Msg2/4 (Type 1, RA-RNTI, TC-RNTI), and paging (Type 2, P-RNTI) are considered for exception handling.
Proposal #3: For collision case 4, when UE determines to prioritize PDSCH scheduled by Type 0/0A/1/2 CSS, the DL prioritization is applied only if the UL cancellation timeline can be satisfied, otherwise UL is prioritized.
Proposal #4: Update the WA from RAN1 #120bis as follows:
Proposal #5: RAN1 clarify that it is expected for (e)RedCap UE to resolve DL/UL collisions sequentially along the time axis.
Proposal #6: For collision cases 3 and 4, support TA reporting with the following enhancement(s):
Finer TA report granularity
Smaller TA offset threshold

TDoc file reading error

TDoc file reading error

TDoc file reading error