3GPP TSG-RAN WG1 Meeting #106-e	R1-21xxxxx
e-Meeting, 16th 每 27th August 2021


Agenda Item:	8.6.1.3

Title:	FL summary #1 on duplex operation for RedCap

Source:	Moderator (Qualcomm Inc.)

Document for:	Discussion, Decision

Introduction
This feature lead (FL) summary (FLS) concerns the Rel-17 work item (WI) for support of reduced capability (RedCap) NR devices [1]. Earlier RAN1 agreements for this WI are summarized in [2].
This document summarizes contributions [3] 每 [26] submitted to agenda item 8.6.1.3 and captures this email discussion on duplex operation for RedCap:
[106-e-NR-R17-RedCap-03] Email discussion regarding aspects related to duplex operation 每 Chao (Qualcomm)
 1st check point: 8/19
 2nd check point: 8/24
 Final check: 8/27
The final FLS from the previous RAN1 meeting can be found in [27]. The issues that are in the focus of the first round of discussion in this meeting are furthermore tagged FL1.
The issues in this document are tagged and color coded with High Priority or Medium Priority.
Collision handling for Case 5
RAN1#104bis-e reached the following working assumptions [2]:
Working assumption:
 If a dynamically scheduled UL transmission overlaps with an SSB, down-select one of the following options:
 Option 1: Follow the handling of case 2 that dynamic UL is prioritized over SSB
 Option 2: Reuse the existing collision handling principles of Rel-15/16 for NR TDD that SSB is prioritized over dynamic UL 
 Option 3: Leave to UE implementation whether to receive the SSB or transmit the UL transmission
 Other options are not precluded
 If a semi-static configured UL transmission overlaps with an SSB, down-select from the following options:
 Option 1: Up to gNB configuration to avoid such collision and if it happens it is an error case
 Option 2: Reuse the existing collision handling principles of Rel-15/16 for NR TDD that SSB is prioritized over semi-static UL
 Option 3: Leave to UE implementation whether to receive the SSB or transmit the UL transmission
 Other options are not precluded
 FFS: whether/how to account for Tx/Rx switching time before and after the set of SSB symbols
 FFS: whether or not the semi-static configured UL transmission includes a valid RO

SSB overlaps with dynamically scheduled UL transmission
For the case of SSB overlaps with dynamically scheduled UL transmission, companies＊ views are summarized in Table 2.1-1.

Table 2.1-1: Views on collision handling for SSB overlaps with dynamically scheduled UL transmission
IndexDescription Companies# of CompaniesOption 1Follow the handling of case 2 that dynamic UL is prioritized over SSBEricsson, vivo, Nokia, CATT, China Telecom, CMCC, ASUSTeK (1st choice), WILUS8Option 2Reuse the existing collision handling principles of Rel-15/16 for NR TDD that SSB is prioritized over dynamic ULSpreadtrum (2nd choice), Samsung (2nd choice), NordicSemi, OPPO, QC, LG, Intel, Apple, DoCoMo, Xiaomi (2nd choice), Panasonic, ASUSTeK (2nd choice)12Option 3Leave to UE implementation whether to receive the SSB or transmit the UL transmissionSpreadtrum (1st choice), Samsung (1st choice), Apple (2nd choice), Xiaomi (1st choice)4
Another option that differentiates Msg3 or Msg3 re-transmission with other dynamically scheduled UL transmission was proposed in contribution [ZTE08]. That is, if the dynamically scheduled UL transmission happens during RA procedure, the dynamically scheduled UL transmission is prioritized; otherwise, the SSB reception is prioritized.
From the above, Option 1 and 2 receives relatively more support. Specific comments regarding benefits, advantages, drawbacks, concerns and impacts for each of the options in the RAN1#104bis-e agreement are summarized below. 
Option 1: dynamic UL is prioritized over SSB

	Benefits/advantages:
 Additional flexibility for scheduler and is consistent with principle of dynamic scheduling [Ericsson04, CATT10]
 With this option, gNB can still avoid scheduling UL overlapping with SSB [Ericsson04]
   Drawbacks/concerns/impacts:
 Will have impact on time and frequency tracking loop at the UE side since UE [ZTE08, Apple19]
 UE may not be able to monitor the overlapped SSB and meet RAN4 RRM timeline [Qualcomm14]
 Risk of introducing more complicated rule for multiplexing between UL channels if different collision handling rules are considered for dynamic and semi-static UL [Samsung09]
Option 2: SSB is prioritized over dynamic UL

	Benefits/advantages:
 Minimum spec change [Xiaomi23, Spreadtrum07]
   Drawbacks/concerns/impacts:
 Lack of flexibility [Ericsson04]

Option 3: Leave to UE implementation 

	Benefits/advantages:
 UE can make the decision based on RRM measurement implementation [Apple19]
   Drawbacks/concerns/impacts:
 Increased detection complexity at gNB [vivo05]

FL1 High Priority Question 2.1-1:
 Companies are invited to comment whether and what additional speficiation work are needed to adress the potential risk or concern for each option in the above, in particular regarding whether it is necessary to consider a unified solution to handle all the subcases of Case 5? 
CompanyY/NCommentsvivoAs dynamic scheduled UL transmission is UE specific and fully controlled by gNB, if we allow such collision (SSB v.s. dynamic scheduled UL transmission), the dynamic scheduled UL transmission should be prioritized, i.e., option 1, otherwise, there seems no point to allow such collision to happen i.e. option 2 (gNB can avoid scheduling UL transmission over the SSB symbols). Option 3 is not a good way forward as gNB will not try to schedule UL transmission over SSB symbols if the UE reaction is not predictable. 
Therefore, if there is no agreement between option 1 and option 2, we would propose to make such collision case as error case. 
In addition, we do not think it is necessary to have a unified solution to handle the collision for the configured UL Tx vs SSB, and the collision for dynamic UL Tx vs. SSB. In Rel-15, UE behaviour is different for DL/UL collisions that involving DG and CG. CATTPrefer to prioritize dynamically scheduled UL. In FDD cell, prioritizing dynamically scheduled UL transmission for HD-FDD does not introduce specification impact. Because the HD-FDD UE will transmit the dynamically scheduled UL regardless of overlapping with SSB or not, which is the same with FDD UEs.
But if SSB is prioritized over dynamically scheduled UL, the negative impact on UL resource utilization and flexibility is introduced. Also, the specification impact will arise (specifying dropping rule for dynamically scheduled UL in FDD cell).SpreadtrumAdditional specification work For option 1: Our preference is option 3(1st choice) and option 2(2nd choice), we share the same view with other companies that option 1 may impact the T/F tracking loop or impact the RRM measurement at the UE side. To address this risk, the gNB needs to avoid such an overlapping, which means the dynamic UL will never overlap with SSB from UE side, it bring huge scheduling restriction to gNB.
A unified solution: From our perspective, we prefer to consider a unified solution to handle all the subcases of Case 5 since we do not see the need to have different solutions for those cases. Our top preference is ※Leave to UE implementation§, but it seems that option 2 are majority supported, we can also accept option 2 ※Reuse the existing collision handling principles＃§.ZTE, SanechipsFirstly, from our perspective, when Msg3 or Msg3 re-transmission or PUCCH for msg4 are not included in the dynamically scheduled UL transmission, we prefer Option 2, since it has the minimum spec change if it is used for HD-FDD RedCap UEs. Furthermore, in order to guarantee the successful transmission of the dynamical UL, gNB can avoid the collision by scheduling the dynamical UL on the resources which is not overlapped with SSB in time domain. So we think option 2 is flexible enough.
For Msg3 or Msg3 re-transmission or PUCCH for msg4 during random access procedure,  if SSB is also prioritized when the collision happens, some problems/issues will occur:
 the RA procedure may be interrupted by not sending Msg3 or PUCCH for msg4 from UE. It results in the significant increase of access latency of RA procedure.
 gNB can not avoid the collision by scheduling UL resources for Msg3 or PUCCH for msg4 that are not overlapped with SSB since there is no consensus on the early identification of HD-FDD RedCap UEs by separate PRACH resources. If not supporting earlier indication of HD-FDD RedCap UEs, in order to solve the collision, gNB should schedule UL resources for Msg3 or PUCCH for msg4  that are not overlapped with SSB whatever the UE is a HD-FDD RedCap UE or not. As a result, the average access latency of random access procedure for FD-FDD RedCap UEs will be increased.
Therefore, for a dynamically scheduled UL transmission overlaps with an SSB, if the dynamically scheduled UL transmission includes Msg3 or Msg3 retransmission or PUCCH for msg4, they should be prioritized; otherwise, Option 2 is prioritized.EricssonWe prefer Option 1 as it provides scheduling flexibility which is consistent with the principle of dynamic scheduling. With this option, it is still possible that gNB can avoid scheduling dynamic UL overlapping with SSB occasions. In our view, the added flexibility is worth specifying a different collision handling behavior under Case 5. In term of specification work, it is possible to expand the collision handling rule in Case 2 to include SSB as part of semi-static DL, thus minimal specification effort/impact.
In our view, there should not be a serious concern on the UE implementation due to Option 1 as the collision handling would be like Case 2. However, we are open to hear and understand more companies＊ views, if any.NordicThe SSB is important for UE in RRC connected for serving cell measurements and also to maintain synchronization. Contrary, optimization for eMBB (improved UL TP) or URLLC (latency) are not in scope of this WID. Finally, unified solution is necessary, otherwise priority rules for collision handling would need to be defined.Nokia, NSBOur preference is Option 1. This will allow additional scheduling flexibility and also provide the same handling with FDD UE. We do not think there will be significant specification impact as this is, in principle, the same as semi-statically configured DL reception vs. dynamically scheduled UL transmission (Case 2).
Also, in our view, there is no need to have a unified solution for Case 5.IntelIn general, we prefer to define a unified solution for dynamic UL and configured UL. If different handling of dynamic UL and configured UL are used, we need to clearly categorize the different kinds of channel/signals. The potential differentiation of PUCCH carrying HARQ-ACK is just one example. However, it may become quite complicated. Apple Our preference is Option 2. It should be noted that it is up to UE implementation regarding which SSBs are selected for measurement e.g., T/F tracking, intra-frequency RRM measurements as long as the requirement is met. Typically, it is maintained by a separate loop by hardware in implementation, which is not interacted with any L1 control signalling including UL grant. Opt.1 essentially mandates UE to first check the overlapping of DG-PUSCH with the target SSB and then decides to select it or not. This prohibits to reuse the current implementation, especially for HD-FDD UE that does NOT target for high peak data rate. 
More that, from system wise, the UL resource that overlaps with SSB can still be utilized by FD-FDD UE and Opt.2 does not cause any resource wastage. 
We also prefer to have a unified solution for both CG-PUSCH and DG-PUSCH i.e., priotizing SSB or leaving it to UE implementation. QualcommWe support Option 2, with the exception of PDCCH ordered PRACH. We can re-visit the case of PDCCH ordered PRACH after progress is made for RO validation rule of HD-FDD UE.Lenovo, Motorola Mobility Our preference is option 2. We also prefer a unified solution for dynamic UL and configured UL. SamsungOur first preference is option 3. But, taking into account the agreement on SSB vs. configured UL, we prefer to have the common rule for SSB vs. dynamic UL as well which can avoid handling complicated scenarios for UCI multiplexing caused by collisions between DG PUSCH and CG PUSCH in the future. 
Contribution [Qualcomm14] proposed that PDCCH ordered PRACH should be excluded from the dynamically scheduled UL transmission since it is considered in Case 8, while contribution [vivo05] has a different view that the dynamically scheduled UL transmission includes PUSCH, PUCCH, SRS and PRACH triggered by PDCCH order.

FL1 High Priority Question 2.1-2:
 For Case 5 of SSB overlapping with dynamically scheduled UL transmission, should PRACH triggered by PDCCH order be considered also? 
CompanyY/NCommentsVivoYFrom current specification, the PDCCH ordered PRACH is usually treated similarly as dynamic scheduled UL transmission. It would be good to better understand the justification to treat PDCCH ordered PRACH differently for HD-FDD UEs. CATTWe think PRACH triggered by PDCCH order can be considered as dynamically scheduled UL.DOCOMONSince the PRACH triggered by PDCCH order is transmitted on valid RO, it should be considered in Case 8ZTE, SanechipsFrom an agreement made in RAN1 #104bis-e shown bellow, PRACH triggered by PDCCH order is included in dynamically scheduled UL transmission.
Agreements:
 For Case 1 (dynamically scheduled DL reception vs. semi-statically configured UL transmission), reuse the existing collision handling principles in Rel-15/16 NR for operation on a single carrier /single cell in unpaired spectrum. 
 FFS whether the timeline is extended to include the RX/TX switching time for HD-FDD
 For Case 4: dynamically scheduled DL reception vs. dynamic scheduled UL transmission, reuse the existing collision handling principles in Rel-15/16 NR for operation on a single carrier /single cell in unpaired spectrum
 That is, it is considered as an error case if a dynamically scheduled DL reception overlaps with a dynamically scheduled UL transmission
 For Case 2 (semi-statically configured DL reception vs. dynamically scheduled UL transmission), reuse the existing collision handling principles in Rel-15/16 NR for operation on a single carrier/single cell in unpaired spectrum
 The semi-statically configured DL reception may include PDCCH (excluding ULCI), SPS PDSCH, CSI-RS or PRS. 
 FFS on PDCCH carrying ULCI, including whether or not it is supported by RedCap UEs (including potential difference between HD vs. FD RedCap UEs)
 The dynamically scheduled UL transmission may include PUSCH, PUCCH, SRS or PRACH triggered by PDCCH order
So  PRACH triggered by PDCCH order should  be considered in dynamic UL transmission. 
Also, this problem is related to the collision between SSB and valid RO in case 8. it is suggested to follow the handling rule for case8. EricssonYIn view of the agreement for Case 2 (which basically reused the TDD rule), PRACH triggered by PDCCH order is treated as dynamically scheduled UL transmission. In our view, the same principle can be considered for Case 5 here.NordicPostponeUntil valid RO for HD-FDD UE is clarifiedNokia, NSBYBased on the previous agreement from RAN1#104bis-e, we should follow the same principle as for Case 2.IntelYWe prefer to have unified solution to all dynamic scheduled UL transmissionApple YThe rule can be applied for PDCCH-ordered RO. For example, gNB has a full freedom to select a RO by PDCCH to avoid overlapping. QualcommNAlthough RAN1#104 agreed that PDCCH ordered PRACH belongs to dynamic scheduled UL in general, there is no consensus on the RO validation rule for HD-FDD UE. Therefore, further discussion/agreements were made at RAN1#105 to separate the discussion of PRACH/valid RO from other UL transmissions.SamsungWe don't have strong preference but slightly prefer to handle PDCCH ordered PRACH in Case 8.

SSB overlaps with configured UL transmission
For the case of SSB overlaps with semi-statically configured UL transmission, companies＊ positions are summarized in Table 2.2-1.
Table 2.2-1: View on collision handling for SSB overlaps with semi-statically configured UL transmission
IndexDescription Companies# of CompaniesOption 1Up to gNB configuration to avoid such collision and if it happens it is an error caseOption 2Reuse the existing collision handling principles of Rel-15/16 for NR TDD that SSB is prioritized over semi-static ULEricsson, vivo, Spreadtrum (2nd choice), ZTE, Samsung (2nd choice), CATT, NordicSemi, China Telecom, OPPO, QC, CMCC, LG, Apple, DCM, Xiaomi (2nd choice), Panasonic, ASUSTeK, WILUS18Option 3Leave to UE implementation whether to receive the SSB or transmit the UL transmissionvivo, SPREADTRUM (1st choice), Samsung (1st choice), Apple (2nd choice), Xiaomi (1st choice)5
Another two new options are also presented by some companies.
 Contribution [Nokia06] considers a combination of Options 1 and 3. That is, it is up to gNB configuration to avoid such collision. However, if collision occurs, it is up to UE implementation whether to receive the SSB or to transmit on the uplink
 Contribution [Intel18] presents a new option to differentiate CG-PUSCH from other configured UL transmission, i.e., using Option 3 for CG-PUSCH and Option 2 for configured UL transmission other than CG PUSCH. 

In contribution [Ericsson03], it is viewed that Option 3 may lead to increased gNB decoding of UL transmission, and a modified version of Option 3 is proposed, i.e., leave it to UE implementation whether to receive the SSB or transmit the UL transmission based on the RRM requirement of the UE. 

Views regarding whether the semi-static configured UL transmission includes a valid RO are summarized as following:
 Contributions [vivo05, ZTE08, Qualcomm14] clarify that the configured UL transmission includes PUSCH, PUCCH and SRS but not PRACH
 Contribution [LG16] views that the semi-static configured UL transmission also includes a valid RO and a valid PUSCH occasion for 2-step RACH
From the above, Option 2 receives the majority support. It is noted that most companies supporting Option 3 also consider Option 2 as a secondary preferred solution. 
Regarding whether the semi-static configured UL transmission includes a valid RO and/or a valid PUSCH occasion for 2-step RACH, the FL suggestion is to further discuss it in Case 8 to avoid the overlapping discussion. 
FL1 High Priority Proposal 2.2-1: 
 For Case 5 of SSB overlaps with configured UL transmission, re-use the existing collision handling principles of Rel-15/16 for NR TDD that configured SSB is prioritized over configured UL
 The configured UL transmission may include CG-PUSCH, PUCCH or SRS

CompanyY/NCommentsvivoYSmall modification for the sub-bullet: 
The configured UL transmission may includes CG-PUSCH, PUCCH or SRSCATTYTo our understanding, in this proposal, configured PUCCH transmission means the PUCCH not triggered by a DCI.EricssonY
Based on the proposals in FL summary #1 in R1-2108252, the following RAN1 agreements were made in an online (GTW) session on Monday 16th August:

Agreement:
 For Case 5 of SSB overlaps with in configured UL transmission, re-use the existing collision handling principles of Rel-15/16 for NR TDD that SSB is prioritized over configured UL transmission
 The configured UL transmission includes CG-PUSCH or SRS
 FFS: Confirm that PUCCH is included
FL1 High Priority Question 2.2-2: 
 Companies are invited to comment whether to confirm that PUCCH is included in the above agreement. If not, please provide the justification or any modification

CompanyY/NCommentsCATTPUCCH resource is more or less configured by higher layer parameters. However, the key point is whether the PUCCH is dynamically triggered or not. 
Specifically, in this proposal, configured PUCCH transmission means a PUCCH that NOT triggered by a DCI. 
An example for configured PUCCH transmission in this agreement is P-PUCCH for P-CSI report.
So PUCCH for Msg4 is not included here and should be regarded as dynamic UL.DOCOMOYConfigured UL transmission should be included as TDD case. We have the same understanding that configured PUCCH transmission means a PUCCH which is not triggered by a DCIZTE, SanechipsAgree with CATT＊s view. PUCCH for msg4 belong to the dynamic UL transmission.EricssonYAgree with comments from other companies that configured PUCCH should be included, but that Msg4 PUCCH can be considered as dynamic PUCCH.NordicPostponeReading CATT comment, one more reason to have the same behaviour for configured and dynamic UL in FL1 High Priority Question 2.1-1:
No need to further discuss.Nokia, NSBYSimilar view as CATT.IntelAs discussed online, we prefer to clarify the definition of dynamic PUCCH for HARQ-ACK transmission, and semi-static PUCCH for HARQ-ACK transmission. the wording suggested by Xueming is one way. 
 for HARQ-ACK channel without associated DCI, e.g. HARQ-ACK channel for SPS PDSCH is semi-static
 otherwise, since K1 can be indicated by the DCI, the HARQ-ACK channel is considered as dynamic 
Just to note, this issue doesn＊t exist in NR TDD. That is, due to  unified handling of SSB overlapping with dynamic UL and configured UL, it is not necessary to differentiate types of HARQ-ACK channels. 
In this discussion, depending on the agreement handling SSB overlapping with dynamic UL, such differentiation becomes necessary. Apple YWe do NOT see the need to differentiate the PUCCH, with or without HARQ-ACK, to seek for a unified UE behavior for overlapping between SSB and PUCCH. 
Note that SSB overlapping with PUCCH, especially for PUCCH using for HARQ-ACK feedback, gNB has full control to avoid this collision by properly setting the K1 value in DCI. Especially, for Msg-4 HARQ-ACK during initial access, increasing latency a bit for HD-FDD UE should be less concerned during initial access. QualcommPUCCH carrying HARQ feedback for msg4/msgB are dynamically scheduled UL transmission(s) on configured resources.SamsungYAgree with other companies that configured PUCCH is included except Msg4 PUCCH which should be considered as dynamic PUCCH.
Whether to account for Tx/Rx switching time before and after the set of SSB symbols 
An FFS identified in RAN1#104bis-e for Case 5 is whether the Tx/Rx switching time should be accounted before and after the set of SSB symbols. 
 In contribution [Ericsson04], it is viewed that if the UE behavior for Case 9 is clarified to ensure that Tx/Rx switching time is fulfilled, there is no need to further account for the Tx/Rx switching time under Case 5
 Contributions [Vivo05, Apple19] express view that gNB should ensure the sufficient Tx/Rx switching time before and after the set of SSB symbols and no special handling is needed
 Contribution [ZTE08] presents that Tx/Rx switching time should be considered for SSB overlapped with UL when determining the collision handling rules
 Contribution [Samsung09] indicates that the TX/RX switching time should be considered for SRS overlapped with SSB since SRS can be transmitted before and/or after the set of SSB symbols is received
 Contribution [LG16] has expressed view that the Rx-to-Tx switching time after the set of SSB symbol should be accounted for HD-FDD operation in FDD bands 
From the above, the views are split. A common question is whether the back-to-back (without sufficient gap) scenarios can be avoided by gNB, and if not, whether the WA for Case 9 is sufficient to handle the collision, e.g., treating it as an error case. Contribution [ZTE] concerns that reception of SSB may not be successful for the case of SSB immediately following the last symbol of UL transmission without sufficient time gap. 
Considering this may be coupled with the discussion for Case 9, the FL suggests we come back to this FFS after Case 9 has been discussed clearly. 
Collision handling for Case 8
PRACH occasion validation for HD-FDD UEs
For the definition of ※valid RO§ for HD-FDD UEs, the following options are discussed in RAN1#105-e meeting:
 Option 1: Same as NR FDD that all PRACH occasions are valid
 Option 2: Similar to NR TDD that a PRACH occasion in a PRACH slot is valid if?it does not precede a SS/PBCH block in the PRACH slot and starts at least Ngap symbols after a last SS/PBCH block symbol

Table 3.1-1 summarizes the companies view for the above two options
Table 3.1-1: Views on RO validation for HD-FDD UEs
IndexDescription Companies# of CompaniesOption 1FDD definitionHuawei, Ericsson, vivo, Nokia, ZTE, Samsung, CATT, CMCC, MTK, Intel, Apple, DCM, Xiaomi, Panasonic14Option 2TDD definitionOPPO, LG, WILUS, Qualcomm4
Specific comments regarding benefits, advantages, drawbacks, concerns and impacts for each of the options are summarized in the following table below.
   
FDD validitation ruleTDD validation rulegNB impactsSupport sharing ROs b/w FD-FDD and HD-FDD UEs with consistent SSB-to-RO mapping Mismatch on SSB-to-RO mapping between FD-UD and HD-UE thus potentially increasing gNB complexity for PRACH detection HD-FDD UE impactsIncreased RACH latency

May not be able to transmit on the ROs associated with the best SSB beams due to persistent collision 

May not be able to meet performance requirements for RRM measurements if valid RO is prioritizedAll valid ROs can be used for PRACH transmissionSpec. impactsNeed to specify collision handling rule for SSB vs. valid RONeed to support configuration of dedicated PRACH resources to HD-FDD UEs   
Contribution [NordicSemi11] presents a new option to address the SSB-to-RO mapping issue by mapping the transmitted SSBs to all PRACH occasions irrespective whether they are valid or not when the TDD rule is reused for HD-FDD.
In Contribution [Huawei01], it is proposed that not only the RO validation but also the PO validation and the RO/Po-to-PRU mapping rules of HD-FDD UEs should follow the rules of FDD＊s definition.
For Option 1, there is the case of SSB colliding with valid ROs and the following alternatives are discussed in the contributions
 Alt. 1: Leave it to UE whether to receive SSB or transmit PRACH (e.g., based on RRM requirement)
 Alt. 2: Prioritize only the valid RO used for PRACH transmission; otherwise, SSB reception is prioritized
 Alt. 3: Always prioritize either SSB or RO 

Contributions [Ericsson04, vivo05, Nokia06, CATT10, CT12, MTK17, Intel18, Apple19, IDCC21, DCM22, Panasonic24] support Alt. 1 since it provides flexibility and does not expect to cause an impact on gNB operation. 
Alt. 2 is considered in contribution [ZTE08] since it is noted that the collision between the valid RO and SSB does not exist if a valid RO is not used for preamble transmission.
 

FL1 High Priority Question 3.1-1:
 In order to facilitate a converged understanding, companies are invited to comment on the benefits and drawbacks for both Option 1 and 2, in particular regarding how each option can be designed to overcome/minimize the identified drawbacks of the option

CompanyY/NCommentsvivoFor Option 2, we think the gNB impact is not only the detection complexity, it may cause PRACH detection failure if incorrect reception beam is chosen by the gNB. 
For Option 1, it is not clear reusing FDD validation rule will increase the PRACH latency. On the contrary, reusing TDD validation rule (option 2) will increase the PRACH latency if the PRACH detection often fails due to incorrect reception beam at the gNB side. 
For the additional spec impact for Option 1, we think Alt 1 should be sufficient, and Alt 2 can be considered as one particular exemplary UE implementation of Alt 1. 
There is additional specification impact for option 2 that the spec needs to define that for paired the spectrum, the RO validation for HD-FDD UE follows the TDD＊s definition, which is different from the FD-FDD UE. CATTSupport Option 1, i.e. following FDD definition. Sharing the same SSB-to-RO mapping is preferred to avoid increasing the gNB complexity.
Latency for initial access is unlikely to be a serious issue.
Regarding to the ＆Need to specify collision handling rule for SSB vs. valid RO＊, note that Alt. 1 (Leave it to UE implementation) does not require collision handling rule.ZTE , SanechipsFor the definition of ※valid RO§ for HD-FDD UEs, if Option 2 is used, mismatch on SSB-to-RO mapping between FD-UD and HD-UE as summarized by FL is a serious problem, and from our perspective, only a separate PRACH resource configuration dedicated for HD-FDD RedCap UEs can address it.  So both full duplex and half duplex RedCap UEs should be identified by PRACH, considering NR PRACH may also be used for other purposes in Rel-17 NR, such as for the identification of NR UE with coverage enhancement, it will finally result in the excessive fragmentation of PRACH and cause the decrease of PRACH resource utilization. 
For Option 1, regarding the collision with SSB and valid ROs, as we explain in our contribution, the collision does not exist if the HD-FDD RedCap UE intends not to send preamble on the valid RO since the UL(valid ROs) and DL(SSBs) are separate in frequency domain.  It is not recommended that all valid ROs should follow the same scheme. 
Therefore, from our perspective, Option 1 is prioritized and in the case of SSB colliding with valid ROs Alt 2 is prioritized.EricssonThe drawbacks of using TDD validation rule (Option 2) have been clearly stated in many contributions, i.e., different SSB-to-RO mappings between FD-FDD UE and HD-FDD UE, leading to increased gNB complexity for PRACH detection and the need for dedicated PRACH resources for HD-FDD UEs.
In our view, all the concerns listed above for Option 1 can be overcome if the collision handling rule for valid RO vs. SSB is defined to be up to UE implementation whether to receive SSB or transmit PRACH (Alt. 1). Note that this rule (Alt. 1) is also the majority view among companies. That is, the UE can take into account RRM measurement requirements to prioritize SSB if needed. On the other hand, if the UE wishes to transmit PRACH, e.g., on the RO associated with the best SSB beam, it can prioritize PRACH, and thus not incurring further RACH latency. 
From the above, we think it is clear that Option 1 is preferred over Option 2.NordicThere are two aspect to be clarified 
 Mapping of SSBs to ROs and PRACH sequences
 Collision handling of SSB and valid RO
Therefore, we suggest compromise solution
Proposal-Nordic
Set valid RO as TDD (for collision handling),  but clarify in specification that  for HD-FDD UE SSBs are mapped to all ROs irrespective whether valid or not. 



Nokia, NSBOur preference is Option 1.
We prefer not to have separate valid RO definition for FDD and HD-FDD UE as this will increase gNB complexity.
For collision rule, our preference is Alt 2 but we would also be OK with Alt 1.IntelThe RO validation of NR TDD, especially the Ngap symbols, is defined considering the necessary switching time at TDD gNB. However, this is not a problem for FDD gNB at all. 
Further, applying different rules of RO validation for HD-FDD UE and FD-FDD UE complicate the gNB configuration. Apple Our preference is option 1. 
As commented by vivo, the valid RO is used for the association with SSBs. Opt.2 results in different RO association between FD-FDD and HD-FDD UEs in a same cell and causes PRACH detection problem at gNB side due to different preamble transmission direction from FD-FDD and HD-FDD UEs. 
The prioritization between overlapping SSB and RO is a separate issue. Even we agree a RO is valid when it is overlapped with SSB. We can still further discuss which of SSB/RO is prioritized for HD-FDD UE.  QualcommBased on the example shown below (R1-2107353), the RO validation rule of non-RedCap  (FD capable) UE is not suitable for RedCap UE incapable of FD-FDD operation, due to the persistent collisions between SSB and RO. As a result, a RedCap UE is not able to transmit on the RO associated with the best SSB beams within a SSB-to-RO association (pattern) period and meet the measurement accuracy requirements, especially for 1 RX UE.
Moreover, the RO valid for non-RedCap UE cannot be assumed valid for RedCap UE by default, since the valid RO for non-RedCap UE is not necessarily within the initial UL BWP of RedCap UE (i.e. initial UL BWP of non-RedCap UE is wider than the max BW of RedCap UE). 
Furthermore, R16 already supports separate PRACH resource configuration and different SSB-to-RO mapping patterns when 4-step RACH and 2-step RACH co-exist (TS 38.213, Clause 8.1) on the same CC.
As a trade-off between RO validation rule of FDD and TDD, we have the following proposal for Type-A HD-FDD operation:
For a PRACH occasion configured for HD-FDD RedCap UE, the RO is valid if:
 it is within the initial UL BWP of the RedCap UE
 it does not precede a SS/PBCH block in the PRACH slot and starts at least n_(g,min)  symbols after a last SS/PBCH block symbol, where  n_(g,min)≡1  
 the candidate SS/PBCH block index of the SS/PBCH block corresponds to the SS/PBCH block index provided by ssb-PositionsInBurst in SIB1 or in ServingCellConfigCommon, as described in Clause 4.1 of TS 38.213




Lenovo, Motorola MobilityOur preference is option 1. Similar with Nokia＊s view, there is no need to have separate valid RO definition for FDD and HD-FDD. SamsungOur preference is Option 1. We think the second or third drawback for HD-FDD UE impacts from Option 1 in the above table is up to how to define the collision handling rule. If Alt.1 (up to UE implementation) is adopted, there is no issue for such drawbacks.

valid RO overlaps with PDCCH in Type 0/0A/1/2 CSS set
From RAN1 #105-e [2] ,the following agreements were reached for this collision sub-cases:
Agreement:
 For Case 8 of valid RO overlapping with PDCCH in Type 0/0A/1/2 CSS set, down-select from the following options
 Option 1: Reuse the existing collision handling principles of Rel-15/16 for NR TDD that valid RO is prioritized over configured PDCCH
 Option 2: Leave to UE implementation whether to receive the configured PDCCH or transmit the PRACH on the valid RO
 Option 3: If configured PDCCH is in a Type-2 CSS set, then PDCCH is prioritized; otherwise the valid RO is prioritized
 Option 4: Configured PDCCH is prioritized over valid RO
 Option 5: Configured by network, e.g. via a priority indicator
 FFS: whether or not the set of symbols overlapping with PDCCH in CSS set includes also Ngap symbols before the valid RO and whether the same value for Ngap in current spec is reused for HD-FDD
 FFS whether a valid RO follows TDD＊s or FDD＊s definition, and if so, the corresponding impact
 FFS: whether or not the same principle is applied to PUSCH occasion of MSGA in 2-step RACH, if supported

Table 3.2-1 summarizes the companies view for the 5 options in RAN1#105-e agreement.
Table 3.2-1: Views on collision handling for valid RO overlaps with PDCCH in Type 0/0A/1/2 CSS set
IndexDescription Companies# of CompaniesOption 1Reuse the existing collision handling principles of Rel-15/16 for NR TDD that valid RO is prioritized over configured PDCCHEricsson (1st choice), Spreadtrum (2nd choice), NordicSemi, OPPO, LG, Apple, Sharp, IDCC, DCM, Panasonic, ASUSTeK, WILUS12Option 2Leave to UE implementation whether to receive the configured PDCCH or transmit the PRACH on the valid ROHuawei, Ericsson (2nd choice), Nokia, Spreadtrum (1st choice), Samsung, CATT, QC, CMCC, MTK, Intel, Xiaomi , Apple (2nd choice)12Option 3If configured PDCCH is in a Type-2 CSS set, then PDCCH is prioritized; otherwise, the valid RO is prioritizedvivoOption 4Configured PDCCH is prioritized over valid ROOption 5Configured by network, e.g., via a priority indicator
In contribution [ZTE08], it is noted that if a valid RO is not used for preamble transmission, the collision between the valid RO and dynamically scheduled DL does not exist. Therefore, it is suggested to differentiate the collision handling for the valid RO based on whether it has been selected by the UE for preamble transmission, and for the ROs not intended for preamble transmission, the collision handling rules can be defined per CSS set. 
In contributions [Ericsson04, Samsung09, Apple19], it is suggested to consider a unified solution to handle all the sub-cases under Case 8 to minimize the specification impact as well as simplify the collision handling operation.
Contribution [vivo05] argues that Option 3 can achieve better trade-off among prioritizing random access, reception of important downlink signalling and UE complexity. Contribution [OPPO13] views that Type 2 CSS set overlapping with valid RO happens less frequently and the network can ensure the paging to HD-FDD UE not to be sent in a RO slot. 
From the above, a common question is whether to define the priority rule per CSS set. Also, it is noted that in the following agreement for Case 2, the PRACH triggered by PDCCH order has a higher priority than the semi-statically configured DL reception (including PDCCH in CSS set). Therefore, it needs to be clarified whether the valid RO in this collision subcase include the RO associated with PRACH triggered by PDCCH order.
Agreements:
 For Case 2 (semi-statically configured DL reception vs. dynamically scheduled UL transmission), reuse the existing collision handling principles in Rel-15/16 NR for operation on a single carrier/single cell in unpaired spectrum
 The semi-statically configured DL reception may include PDCCH (excluding ULCI), SPS PDSCH, CSI-RS or PRS. 
 FFS on PDCCH carrying ULCI, including whether or not it is supported by RedCap UEs (including potential difference between HD vs. FD RedCap UEs)
 The dynamically scheduled UL transmission may include PUSCH, PUCCH, SRS or PRACH triggered by PDCCH order

Agreements:
 For Case 2 (semi-statically configured DL reception vs. dynamically scheduled UL transmission), a HD-FDD RedCap UE is not required to monitor ULCI
 No special handling on the priority rule for PDCCH carrying ULCI
 
FL1 High Priority Question 3.2-1:
 For Case 8 of valid RO overlapping with PDCCH in Type 0/0A/1/2 CSS set, should RAN1 consider to define the pirority rule per CSS set? Companies are invited to comment whehter the valid RO in this collision subcase should include the RO associated with PRACH triggered by PDCCH order.
CompanyY/NCommentsvivoThe reason we propose option 3 was due to the much less paging occasions that RACH occasion so it would make sense to prioritize Paging monitoring than RACH transmission. However, given the current situation we are fine to accept option 2 also. 
The collision handling between PDCCH monitoring and PRACH triggered by PDCCH has already be resolved by the agreement cited by FL above for case 2, no need to re-open the discussion here.  CATTWe do not think there is strong need to define priority rule per CSS set.SpreadtrumDefine the priority rule per CSS set: From our perspective, a unified solution is preferred to handle all the CSS set. For type 2 CSS set, we agree that paging and SI are very important, but we think the gNB can avoid this overlapping, so there is no need to treat it specially.DOCOMONWe don＊t see the need to consider priority rule per CSS set.
As commented in Question 2.1-2, PRACH triggered by PDCCH order should be included in this caseZTE,SanechipsAs our comment in Question 3.1-1, if we can reach a consensus that the collision for valid RO and DL does not exist if the HD-FDD RedCap UE intends not to send preamble on the valid RO, it is no need to define the priority rule per CSS set. For the valid ROs with no preamble sending, always prioritize valid RO would put too much restrictions for gNB configuring the Type 0/0A/1/2 CSS. For the valid ROs with preamble sending, the RA procedure should not be interrupted with the consequence of increasing access delay. Therefore, valid RO is prioritized on which HD-FDD RedCap UE intends to send preamble ; otherwise, PDCCH in Type 0/0A/1/2 CSS set is prioritized.
As our comment in Question 2.1-2, PRACH triggered by PDCCH order is included in dynamically scheduled UL transmission, so the corresponding collision handling rule can follow Case 2.  EricssonNAmong the options listed, Option 1 and Option 2 receive most support, and these options do not require that RAN1 defines the priority rule per CSS set.
In view of the agreement for Case 2, PRACH triggered by PDCCH order can be treated as dynamically scheduled UL transmission. For the sake of discussion, we think that it is fine to separate normal valid RO (treated here in Case 8) from those intended for PRACH triggered by PDCCH order. 
In our view, if either Option 1 or Option 2 is selected for Case 8, there will not be any conflict in collision handling rule with that in Case 2.NordicYWe prefer legacy behaviour, but can live with left up to implementation Nokia, NSBNThere is no need to define priority rule per CSS set. In our view, PRACH triggered by PDCCH order is considered dynamically scheduled UL transmission and does not needed to be treated in Case 8.IntelNSince the Type 0/0A/1/2 CSS set may share the same monitoring occasions, we prefer to define the same overlap handling rule for all Type 0/0A/1/2 CSS sets. 
In our understanding, Case 8 is to define the overlapping handling for cell-specifically configured valid RO that is used in CBRA. On the other hand, PRACH triggered by PDCCH order is considered as dynamic channel (known to both gNB and UE), hence Case 2 applies. Apple NPrefer to define a unified approach to handle these cases. 
Given the less frequent preamble transmission for a given UE, we can go with Opt.2 to leave it for UE implementation. NOTE leaving it for UE implementation in this case does not increase any complexity at gNB side. QualcommIn NR R15/16, triggers of RACH procedure have been specified by RAN2. Therefore, unless RACH procedure is triggered by higher layer or ordered by PDCCH,  UE is not required to transmit PRACH on the valid RO.
Since RedCap UEs monitoring broadcast PDCCH in Type 0/0A/1/2 CSS set may or may not be ※triggered§ or ※ordered§ to transmit PRACH on the valid RO, we think such collision handling should be left to UE implementation.SamsungNNo need to define the priority rule per CSS set and one common rule is sufficient for all CSS sets. As commented in Case 5, we prefer to include PDCCH ordered PRACH in this Case.
valid RO overlaps with UE-dedicated configured DL reception
From RAN1 #105-e [2] ,the following agreements were reached for this collision sub-cases. There are 3 options in the agreements and other options are not precluded
Agreement:
 For Case 8 of valid RO overlapping with UE-dedicated configured DL reception (e.g. PDCCH in USS, SPS PDSCH, CSI-RS or DL PRS), down-select from the following options
 Option 1: Reuse the existing collision handling principles of Rel-15/16 for NR TDD that valid RO is prioritized over configured DL
 Option 2: Leave to UE implementation whether to receive the configured DL or transmit the PRACH on the valid RO
 Option 5: Configured by network, e.g. via a priority indicator
 Other options are not precluded.
 FFS: whether or not the set of symbols overlapping with configured DL includes also Ngap symbols before the valid RO and whether the same value for Ngap in current spec is reused for HD-FDD
 FFS: whether or not the same principle is applied to PUSCH occasion of MSGA in 2-step RACH, if supported

Table 3.3-1 summarizes the companies＊ views for the 3 options in RAN1#105-e agreements.
Table 3.3-1: Views on collision handling for valid RO overlaps with UE-dedicated configured DL reception
IndexDescription Companies# of CompaniesOption 1Reuse the existing collision handling principles of Rel-15/16 for NR TDD that valid RO is prioritized over configured DLEricsson, Spreadtrum  (2nd choice), CATT, NordicSemi, OPPO, CMCC, LG, Apple, Sharp, IDCC, DCM, Panasonic, ASUSTeK13Option 2Leave to UE implementation whether to receive the configured DL or transmit the PRACH on the valid RONokia, Spreadtrum  (1st choice), Samsung, MTK, Intel, Xiaomi6Option 5Configured by network, e.g. via a priority indicatorHuawei1
In contribution [ZTE08], it is noted that if a valid RO is not used for preamble transmission, the collision between the valid RO and dynamically scheduled DL does not exist. Therefore, it is suggested to support Option 1 but only for the valid ROs on which UE intends to send preamble
Contribution [vivo05] argues that all the three options in the RAN#105-e agreement have some issues and proposes another two options for down-selection with a slight preference for Option 4.
 Option 3: UE-dedicated configured DL reception is prioritized over the valid RO 
 Option 4: Treated as a configuration error of NW (error case)

Contributions [CT12, QC14] express a similar view that the collision handling for this subcase can follow the handling of Case 3, i.e., the overlapping between valid RO and UE-dedicated configured DL reception is not expected by UE and will be treated as a configuration error.
From the above, there is a clear majority view for Option 1. The main concern for Option 2 is the ambiguity exist between the gNB and UE and thus the gNB complexity may also increase unnecessarily. Regarding the new option 4, based on the FL understanding, there is no essential difference compared to option 1. Both options may require the network not to configure the UE-dedicated configured DL reception in the valid RO slots, except that one is soft restriction (i.e., Option 1) and the other is hard restriction (i.e., Option 4).
. 
FL1 High Priority Proposal 3.3-1:
 For Case 8 of valid RO overlapping with UE-dedicated configured DL reception (e.g. PDCCH in USS, SPS PDSCH, CSI-RS or DL PRS), valid RO is prioritized over UE-dedicated configured DL reception (same as TDD case)
CompanyY/NCommentsvivoUE would not transmit PRACH in most of the valid ROs, thus always prioritize valid RO would put too much restrictions for gNB to configure the semi-static DL receptions. Option 2, however does not result in such restrictions thus can be acceptable to us as 2nd preference. CATTYSpreadtrumYesWe have the similar concerns with vivo that always prioritize valid RO would waste some resources, so our first preference is option 2. But for the sake of progress, we can accept option 1 since the spec impact of this option is small and it is majority supported.DOCOMOYZTE, SanechipsAs our comment in Question 3.1-1, the collision for valid RO and DL does not exist if the HD-FDD RedCap UE intends not to send preamble on the valid RO.
For the valid ROs with no preamble sending, always prioritize valid RO would put too much restrictions for gNB configuring the DL transmission. For the valid ROs with preamble sending, the RA procedure should not be interrupted with the consequence of increasing delay for access, TA update and beam switching. 
Therefore, for Case 8 of valid RO on which HD-FDD RedCap UE intends to send preamble overlapping with UE-dedicated configured DL reception, valid RO is prioritized; otherwise, UE-dedicated configured DL reception is prioritized.EricssonYNordic YNokia, NSBOur preference is that the valid RO can be prioritized if the UE has to send PRACH. Otherwise the UE should receive the DL. IntelWe share the same view as vivo, it is not good to always prioritize valid RO since a PRACH preamble is most likely not transmitted at all. In NR TDD, if there is a valid RO, TDD gNB can never transmit. So it is reasonable to prioritize valid RO. It is not the case for FDD gNB. 
Having a unified handling of valid RO overlap with any configured DL reception maybe another reason, which depends on the decision of other cases. Apple YWe are also ok with Opt.2. However, Opt.1 may cause DL resource wastage as it is unknown by gNB whether UE performs RO transmission or not and always transmit DL SPS.  QualcommNBased on the agreement in RAN1#105, other options are not precluded. Therefore, we think such collisions can be treated as a NW configuration error, which is the simplest solution for RedCap UE.
On the other hand, UE (non-RedCap or RedCap) not necessarily needs to transmit PRACH on a valid RO, since RACH  needs to be triggered by higher layer or ordered by PDCCH. Therefore, we are open to discuss the option of ※leaving to UE implementation§ when a valid RO overlaps with UE-dedicated configured DL reception.Lenovo, Motorola MobilityYSamsungOur first preference is to leave it to UE implementation and share similar view with vivo and Spreadtrum that Option 1 is too much restrictions for gNB. But, we can live with the proposal if the proposal is applied for all sub-cases.
valid RO overlaps with dynamically scheduled DL reception
From RAN1 #105-e [2] ,the following agreements were reached for this collision sub-cases:
Agreement:
 For Case 8 of valid RO overlapping with dynamically scheduled DL reception, down-select from the following options
 Option 1: Reuse the existing collision handling principles of Rel-15/16 for NR TDD for operation on a single carrier /single cell in unpaired spectrum
 Option 2: Leave to UE implementation whether to receive the DL or transmit the PRACH on a valid RO
 Option 3: Follow the handling of Case 1 that when the cancellation timeline is satisfied, the UE cancels the PRACH transmission and receives the DL signal/channels on the symbols overlapping with PRACH occasion (Interpretation 2 in R1-2103809)
 Option 4: Valid RO is prioritized over dynamic DL that UE performs PRACH transmission and does not perform the DL receptions (Interpretation 3 in R1-2103809)
 Option 5: When the cancellation timeline is satisfied, the UE neither performs transmission nor receives any DL signal/channels on the symbols overlapping with PRACH occasion (Interpretation 1 in R1-2103809)
 FFS: whether or not the set of symbols overlapping with dynamic DL reception includes also Ngap symbols before the valid RO and whether the same value for Ngap in current spec is reused for HD-FDD
 FFS: whether or not the same principle is applied to PUSCH occasion of MSGA in 2-step RACH, if supported
Table 3.4-1 summarizes the companies view for the above 5 options in RAN1#105-e agreement.
Table 3.4-1: Views on collision handling for valid RO overlaps with dynamically scheduled DL reception
IndexDescription Companies# of CompaniesOption 1Reuse the existing collision handling principles of Rel-15/16 for NR TDD for operation on a single carrier /single cell in unpaired spectrumOPPO, LG, Apple, IDCC4Option 2Leave to UE implementation whether to receive the DL or transmit the PRACH on a valid RONokia, Spreadtrum (1st choice), Samsung, MTK, Xiaomi5Option 3When the cancellation timeline is satisfied, the UE cancels the PRACH transmission and receives the DL signal/channels on the symbols overlapping with PRACH occasion (Interpretation 2 in R1-2103809)Huawei, vivo, CATT, China Telecom, MTK, Sharp, ASUSTeK7Option 4Valid RO is prioritized over dynamic DL that UE performs PRACH transmission and does not perform the DL receptions (Interpretation 3 in R1-2103809)Ericsson, Spreadtrum (2nd choice), NordicSemi, CMCC, Intel, DCM, Panasonic, Apple8Option 5When the cancellation timeline is satisfied, the UE neither performs transmission nor receives any DL signal/channels on the symbols overlapping with PRACH occasion (Interpretation 1 in R1-2103809)Spreadtrum (2nd choice)1
The views on the above 5 options in the RAN1#105-e agreement are split. 
 Contribution [Ericsson] indicates that a clarification may be needed for Option 3 and 5 for a UE capable of partial UL cancellation and Option 4 is viewed as the cleanest solution among all the options
 Contribution [vivo05] views that option 2 is not desirable since the ambiguity may exist between the gNB and UE, and option 5 resolves the UE behaviour ambiguity but it is not clear what is the motivation for such UE behaviour since the UE loses both PRACH transmission opportunity and DL receptions
 Contribution [Nokia06] presents that UE should prioritize valid RO over dynamically scheduled DL reception if UE needs to transmit PRACH in case of valid RO overlapping with dynamically scheduled DL reception
 In contribution [ZTE08], it is noted that if a valid RO is not used for preamble transmission, the collision between the valid RO and dynamically scheduled DL does not exist, and thus it is suggested to support Option 1 but only for the valid ROs on which UE intends to send preamble
 Contribution [MTK17] indicates that Option 4 and 5 are not meaningful and the optimization achieved by Option 2 is minor
 In contribution [Qualcomm14], it is proposed that the overlapping between valid RO and dynamically scheduled DL reception is not expected by UE and will be treated as a configuration error of NW
 Contributions [Samsung09, Apple19] suggest supporting the same collision handling rule for all the sub-cases in order to avoid creating another complicated scenario, instead of case-by-case optimization
 In contribution [Sharp20], it is noted that the DL reception should be canceled for a TDD cell if the two rules are applied to the same set of symbols, but for a FDD cell and HD-FDD UEs, Option 3 may be the only interpretation of the wording in the specification
 Contribution [IDCC21] views that according to the spec, the UE does not receive the DL transmission and also cancels the UL transmission as timeline allows
 Contribution [Xiaomi23] notes that gNB cannot predict when UE will use the valid RO opportunity for UL transmission and considering gNB can anyway simultaneously transmit DL and do PRACH detection it is preferred to solve the UL/DL collision issue of valid RO by UE implementation
 Contribution [ASUSTeK25] discusses that for scenario that valid RO overlapping with more than one subcase of DL receptions, an identical collision handling rule can be applied 
From the above, Option 5 has the minimum number of supports compared to other options thus can be deleted for down-selection. For Option 3 and Option 4, the difference is whether to allow UE to perform full cancellation of PRACH transmission when timeline is satisfied or partial PRACH cancellation when time is not satisfied (i.e., for a UE capable of partial UL cancellation). Option 4 is relatively easier for implementation since the valid RO is always prioritized over dynamically scheduled DL reception, but UE may lose the possibility to receive any DL signal/channels on the symbols overlapping with PRACH occasion. 
FL1 High Priority Question 3.4-1:
 Companies are invited to comment whether the conditional PRACH cancellation (fully or partially) will lead to increased UE implementation complexity, and whether it is necessary to support the same collision handling rule for all the subcases under Case 8?
CompanyY/NCommentsvivoWe do not see much UE complexity issue for PRACH cancellation (at least for the full cancellation) when timeline requirement is satisfied. 
The problem of Option 4 is that: UE would not transmit PRACH in most of the valid ROs, thus always prioritize valid RO would put too much restrictions for gNB to schedule the DL transmission, for example the urgent DL transmission cannot be delivered to the UE due to collision with RO. CATTWe think there is no much complexity to implement PRACH cancellation. This is similar to the cancellation of other UL channels. Option 3 is preferred to improve the DL flexibility and resource utilization for HD-FDD UEs.SpreadtrumSupport the same collision handling rule: for simplify, we prefer to support the same collision handling rule for all the subcases under Case 8. In HD-FDD, gNB can receive and transmit at the same time in different frequency range, and UE may need to transmit PRACH in some cases while in other cases UE could receive DL. Therefore, it can be left to UE implementation to dicided whether to receive DL or transmit PRACH in valid RO. Considering the spec impact and resource utilization, we think ※leave to UE implementation§ is suitable for all cases.ZTE, SanechipsFrom our perspective, we suggest to clarify firstly that whether the collision for valid RO and DL exists if the HD-FDD RedCap UE intends not to send preamble on the valid RO. In another word, the collision only happens when the RO intends to send a preamble. Based on this, the same collision handling rule can be provided under case8.EricssonIt is preferred to have the same collision handling rule for all the subcases under Case 8 though not necessarily. In our view, Case 4 is reasonable and the simplest among the options. NordicWe prefer the same behaviour as for configured DL whether it is Option 2 or Option 1 (with clarification that valid RO is prioritized)Nokia, NSBOur preference is Option 4, i.e. UE should prioritize valid RO over dynamically scheduled DL reception if UE needs to transmit PRACH.IntelWe believe it is fine to define different handling for the overlap with dynamic DL and configured DL. Such solution is commonly used in Case 1/2/3/4/5 too. Since gNB has full control to schedule DL reception in a resource not overlapped with valid RO, we think valid RO should be prioritized. Apple We do not see differences between Opt. 1 and Opt.4. Hence, we also added name under Opt.4. We also prefer to have a unified solution to treat the collisions as much as possible. QualcommIt is not necessary to judge on the complexity for partial PRACH cancellation, since the existing rule in NR TDD depends on UE capability and the gap w.r.t. the scheduling PDCCH.
For the collision between valid RO and dynamically scheduled DL reception, we think the easiest way for a HD-FDD RedCap UE is to treat it as a configuration error of NW. 
On the other hand, we are open to discuss the option of  ※leaving to UE implementation§, considering valid RO is just a necessary condition for PRACH transmission and it is not necessary to prioritize valid RO all the time.Lenovo, Motorola MobilityOur preference is option 4, PRACH transmission is prioritized over dynamic DL reception. This option is easy to be implemented in the UE side.SamsungIt is unclear the benefit to take the conditional PRACH cancellation and also have two types of capabilities for full and partial cancellation.
We prefer to have the common collision rule in order to avoid handling complicated scenarios by different rules in the future.

Whether or not Ngap symbols before the valid RO is included
FFS: whether or not the set of symbols overlapping with dynamic DL reception includes also Ngap symbols before the valid RO and whether the same value for Ngap in current spec is reused for HD-FDD
 Contributions [Ericsson04,  CATT10] express view that Ngap symbols is accounted for in the collision handling related to valid RO since it can be utilized as the Rx/Tx swithcing time and the same value for Ngap for unpaired spectrum in the current specification is reused for HD-FDD
 In contribution [Samsung09], it is discussed that if Ngap symbols are specified for HD-FDD UEs, it can be utilized as the RX/TX switching time. Otherwise, the RX/TX switching time can be additionally considered
 In contribution [vivo05], it is discussed that for the collision subcases where DL reception is cell-specifically configured, including Ngap symbols before the valid RO may be beneficial to account for the DL-to-UL switching time, but for collision case where DL reception is dynamically scheduled or dedicatedly configured, including Ngap symbols before the valid RO is not necessary 
 Contribution [LG16] indicates that the Rx-to-Tx switching time before the valid RO needs to be accounted for all the subcases of Case 8 and proposes FFS on whether the Ngap symbols before the valid RO already covers the Rx-to-Tx switching time.
 Contribution [Nokia06] presents that the set of symbols overlapping with dynamic DL reception does not include the Ngap symbols before the valid RO
From the above, the majority view is that the Rx/Tx switching time before the valid RO needs to be accounted at least for the collision subcases where DL reception is cell-specifically configured. Dependent on whether Ngap symbols are specified for HD-FDD UEs (i.e., according to the RO validation discussion in section 3.1), specification work can be different.

FL1 High Priority Question 3.5-1:
 Should RAN1 consider to use the Ngap symbols before the valid RO to account for the DL-to-UL switching time? If yes, comapnies are invited to commen whether the same value for Ngap for unpaired spectrum in the current specification (Table 8.1-2 in TS 38.213) can be reused for HD-FDD?
CompanyY/NCommentsvivoYRx/Tx switching time before the valid RO needs to be accounted at least for the collision subcases where DL reception is cell-specifically configured.
Same value as in current specification for unpaired spectrum can be reused. CATTYWe think the same value for Ngap can be reused. We do not see any timing advance is different for RedCap or non-RedCap UE.DOCOMOYSame value as in current specification for unpaired spectrum can be reusedZTE, SanechipsYThe value of Ngap  used for TDD NR can be reused for HD-FDD.EricssonYThe same Ngap for unpaired spectrum in the current specification can be reused for HD-FDD.NordicYreuse TDD valueNokia, NSBWe are OK to go with majority view and reuse the same Ngap value for HD-FDD.IntelIt is true Rx/Tx switching time is needed before and after the valid RO. However, ＆Ngap symbols＊ is a different thing. Ngap can be 0 or 2 depending on SCS in current NR. In summary, we think ＆Ngap symbols＊ is not applicable to HD-FDD UE, that means, we should discuss Rx/Tx switching time separately. Apple YQualcommIn principle, we think the DL-to-UL switching time should be rounded to a minimum number of guard symbol(s) for RO validation.
We are open to further discuss the value of Ngap for RO validation.Lenovo, Motorola MobilityYReuse TDD valueSamsungYWe prefer to use Ngap symbols as in the current specification. 

Whether or not the same principle is applied to PUSCH occasion of MsgA in 2-step RACH, if supported
In contribution [Ericsson04], it is proposed not to have special treatment for PUSCH occasion of Msg A, i.e., the collision handling rule is the same as other configured PUSCH since the 2-step RACH can fallback to the 4-step RACH, e.g., when RA preamble is detected but PUSCH is not received.
Contributions [CATT10, MTK17] view that the handling of MsgA PUSCH follows the handling of valid RO
Contribution [Nokia06] proposes to prioritize MsgA PUSCH over dynamic or semi-static DL.
In contribution [Intel18], it is discussed that when a MsgA PUSCH is overlapped with a dynamically scheduled DL reception, the MsgA PUSCH is cancelled if the cancellation time for MsgA PUSCH is met (overlap handling Case 1); and when a MsgA PUSCH is overlapped with a configured DL reception, the MsgA PUSCH is cancelled.
Considering this may be coupled with the discussion of collision handling rule for valid RO, the FL suggests we come back to this issue after the collision handling for valid RO has been discussed clearly. 

Collision handling for Case 9
RAN1#104bis-e reached the following working assumptions [2]:
Working assumption:
 For HD-FDD, reuse the same principle as Rel-15/16 UE not capable of full-duplex communication
 A HD-FDD UE is not expected to transmit in the uplink earlier than [NRX-TX Tc] after the end of the last received downlink symbol in the same cell
 A HD-FDD UE is not expected to receive in the downlink earlier than [NTX-RX Tc] after the end of the last transmitted uplink symbol in the same cell
 FFS NTX-RX and NRX-TX
 FFS: how it jointly works with the agreement for other collision cases 

Regarding the second FFS in the above agreement, the following are discussed in the contributions:
Contribution [Nokia06, CT12, Apple19] view that the concerned collision due to DL/UL direction switching can be handled by gNB, i.e., scheduling the back-to-back DL-to-UL and UL-to-DL transmission and reception with the necessary gaps.
In contribution [Sharp20] it is also suggested to define adequate Tx/Rx switching time for HD-FDD UEs. 
In contribution [vivo05], it is viewed that for back-to-back transmission/reception configured by cell-specific higher layer parameters, given the proposal that the Ngap symbols have been included in valid RO, hence the handling of direction switching can be the same as the collision case and a separate rule is not needed. For other cases, the gNB scheduler should ensure the switching time.
Contribution [Ericsson04] views that the collision with the switching time after applying collision handling rules can occur since it may be difficult for gNB scheduler to avoid the immediate back-to-back (without sufficient gap) scenarios for cases involving semi-statically configured DL/UL (including both UE specific and cell specific). If it is interpreted as an error case, excessive restrictions will be imposed on network configuration. Two options are proposed for further discussion.
 Option 1: An earlier DL reception or UL transmission is prioritized by puncturing or skipping first few symbols of the later UL transmission or DL reception
 Option 2: Leave it to UE implementation to ensure the switching time is satisfied

Contributions [Xiaomi23, Intel18] also raise concern for treating it as an error case if the switching time is not enough after applying the collision handling rule and suggest further discussion for the following two alternatives 
 Alt. 1: Treat it as an error case
 Alt. 2: Consider it as an UL/DL collision and apply the associated collision handling rule defined in other cases 

In contribution [ZTE08], it is discussed that the ※last received downlink symbol§ or ※last transmitted uplink symbol§ in this WA may not be equivalent to ※last scheduled/configured§ downlink or uplink symbol and thus any collision handling rule defined in Case1~Case 8 should follow the restriction defined in Case 9.

FL1 High Priority Question 4-1:
 Shall RAN1 discuss the case that collision with the switching time after applying collision handling rules may occur, in particular regarding whether UE behaviour in suh case should be specified?
CompanyY/NCommentsvivoNThe same principle as in current specification for unpaired spectrum shall be reused, i.e. gNB shall ensure sufficient gap to avoid the collision between DL reception and UL transmission at the UE side, otherwise it is an error case (as no special UE behaviour defined). CATTWe think gNB can handle the gap well, and no further RAN1 discussion is needed.SpreadtrumNDOCOMOYIt is difficult to avoid all the collisions especially for configured DL/UL, and hence, UE behaviour in this case should be specifiedZTE, SanechipsThe collision handling rule defined in Case 9 should be used as the basic rule for ensuring the sufficient gap.EricssonYYes, it would be beneficial to specify one of the options listed in the summary above, i.e.:
 Option 1: An earlier DL reception or UL transmission is prioritized by puncturing or skipping first few symbols of the later UL transmission or DL reception
 Option 2: Leave it to UE implementation to ensure the switching time is satisfied
We are also open to consider alternative solutions.
Nordic YA conclusion could be made that gNB shall handle to accommodate TA and switching time.  Since gNB knows both. Nokia, NSBYOur view is that it should be sufficient for gNB to avoid collisions. However, we are open to discuss further.IntelWe see the need to clarify both two cases
 There is not overlap between DL reception and UL transmisison, but the gap between them is shorter than the necessary swithing time
 When there is overlap between DL reception and UL transmisison, the gap after overlap handling may be shorter than the necessary switching time. 
For case a), it is preferred to clarify how to interpret the current agreement. Is it error case, or allowed but up to UE to handle it? For case b), we prefer to clarify what is the behaviour in NR TDD and what to be defined/enhanced in HD-FDD operation. Apple NWe think it should be treated as error case and avoided by gNB scheduler. QualcommNNW should avoid the collision with RX/TX switching time of HD-FDD UE in UL/DL scheduling.SamsungYWe see a necessity of specified UE behaviour and share similar view with Intel. As one example, for the overlap between SSB and SRS, if only the overlapped SRS symbols are cancelled, the gap between SSB and remaining SRS symbol may be less than TX/RX switching time. For this case, it should be discussed how to handle the remaining SRS symbol.
Other aspects (medium priority)
Whether to define the guard times in symbol units
RAN1#104e made the following agreements related to switching time [2]:
Agreements:
 (Working assumption) For HD-FDD switching time, reuse existing switching times for UE not capable of full duplex in TS 38.211, Table 4.3.2-3.
 FFS: whether to define the guard times in symbol units
 FFS: the switching positions
 Sending an LS to RAN4 to inform the above working assumption, and to ask for feedback if any 
 The LS will not include the two FFS bullets

Draft LS in R1-2102094 is approved. Final LS to be uploaded/updated depending on whether or not there are additional agreements for RedCap related to RAN4. Final LS in R1-2102146

RAN1#104bis-e reached the following WA regarding the second FFS [2]:
Working assumption:
 For HD-FDD, no additional UE behavior for switching position determination is specified as compared to the existing specification. 

In [Ericsson04, vivo05, Nokia06, CATT10, CT12], it is suggested to conclude that there is no need to define guard time in symbol units. 
Contributions [SPRD07, QC14, WILUS26] prefer to use the symbol-level switching time instead of the actual time unit. It is viewed in contribution [Spreadtrum07, WILUS26] that one OFDM symbol can be defined. Contribution [QC14] discusses that no guard symbol is configured for Tx-to-Rx switching and at least one guard symbols is configured for Rx-to-Tx switching at the UE. 
Contribution [LG16] presents that defining the guard time in symbols units can be considered only when we are not reusing the existing switching time (pending confirmation from RAN4).
Considering this may be coupled with the RAN4 feedback about the TX/RX switching time, the FL suggests we come back to this issue after receiving the RAN4 replying LS.

Case 1: Dynamically scheduled DL reception vs. semi-statically configured UL transmission
RAN1#104bis-e reached the following agreements [2]:
Agreements:
 For Case 1 (dynamically scheduled DL reception vs. semi-statically configured UL transmission), reuse the existing collision handling principles in Rel-15/16 NR for operation on a single carrier /single cell in unpaired spectrum. 
 FFS whether the timeline is extended to include the RX/TX switching time for HD-FDD

The remaining FFS is regarding whether the timeline in the above rule should be extended to include the Tx/Rx switching time for HD-FDD. 
Contributions [Ericsson04, vivo05, Nokia06, SPRD07, ZTE08, CT12, LG16, Intel18, Apple19, Xiaomi23, WILUS26] express views that there is no need to extend the timeline to include the Tx/Rx switching time since gNB could take into account the switching time when scheduling dynamic DL to avoid collision with the switching time. 
Contribution [Ericsson04] also pointed out that if there are still colliding symbols with the switching time after partial cancellation, then the UE behavior to be clarified under Case 9 can be applied [4].

Figure 2 from [4]: In case of UE capable of partial cancellation, gNB can take into account the switching time when scheduling dynamic DL, e.g., schedule a PDSCH after T_{proc,2} + switching time, to avoid collision with the switching time


Figure 3 from [4]: After partial cancellation of CG PUSCH based on the timeline, there may still be symbols colliding with the switching time. In this case, a UE behavior to be clarified under Case 9 can be applied to ensure that UE does not receive or transmit during the switching time

In contribution [Samsung09], it is proposed to further discuss whether the RX/TX switching time is considered in Case 1 by taking into account the interpretation and also future RAN4 feedback about the RX/TX switching time.
From the above, the great majority view is that there is no need to extend the timeline to include the Tx/Rx switching time in Case 1. Considering the minimum value of Tproc,2 is larger than 5 symbols much larger than the required switching time, the FL suggestion is to make a conclusion without waiting for RAN4 feeedback about the Tx/Rx switching. 
FL1 Medium Priority Proposed Conclusion 5.2-1:
 For Case 1 (dynamically scheduled DL reception vs. semi-statically configured UL transmission), there is no need to extend the timeline to include the Tx/Rx switching time.
CompanyY/NCommentsvivoYCATTYOKSpreadtrumYDOCOMOYZTE, SanechipsYEricssonYNokia, NSBYIntelYQualcommNeed to consider RAN4＊s reply to RAN1 LS.SamsungY
Case 3: Semi-statically configured DL reception vs. semi-statically configured UL transmission
RAN1#104bis-e reached the following agreements [2]:
Agreements:
 For Case 3, semi-statically configured DL reception vs. semi-statically configured UL transmission
 A HD-FDD UE does not expect to receive both dedicated higher layer parameters configuring transmission from the UE in the set of symbols of the slot and dedicated higher layer parameters configuring reception in the set of symbols of the slot 
 A HD-FDD UE does not expect to receive both dedicated higher layer parameters configuring transmission from the UE in the set of symbols of the slot and cell specific higher layer parameters configuring reception in the set of symbols of the slot 
 A HD-FDD UE does not expect to receive both cell specific higher layer parameters configuring transmission from the UE in the set of symbols of the slot and dedicated higher layer parameters configuring reception in the set of symbols of the slot 
 FFS on cell-specifically configured DL reception vs. cell-specifically configured UL transmission
 FFS: whether or not there are conditions that need to be considered

Some contributions [Ericsson04, vivo05, ZTE08, CT12, Xiaomi23] express views that the agreements for Case 3 may have some overlapping with Case 5 and Case 8 which deal with SSB and valid ROs. 
Contributions [Ericsson04, NordicSemi11, Intel18] propose to adopt the following FL proposal in RAN1#104bis-e [4] to revise the RAN1#104bis-e agreements for Case 3.
Proposal 3.3-1: Revise the RAN1#104bis-e agreement for Case 3 as the following 
 For Case 3, semi-statically configured DL reception vs. semi-statically configured UL transmission
 A HD-FDD UE does not expect to receive both dedicated higher layer parameters configuring transmission from the UE in the set of symbols of the slot and dedicated higher layer parameters configuring reception in the set of symbols of the slot 
 A HD-FDD UE does not expect to receive both dedicated higher layer parameters configuring transmission from the UE in the set of symbols of the slot and cell specific higher layer parameters configuring reception in the set of symbols of the slot
 Cell-specifically configured DL reception refers to PDCCH in Type-0/0A/[1]/2 CSS set
 A HD-FDD UE does not expect to receive both cell specific higher layer parameters configuring transmission from the UE in the set of symbols of the slot and dedicated higher layer parameters configuring reception in the set of symbols of the slot 
 FFS on cell-specifically configured DL reception vs. cell-specifically configured UL transmission
 FFS: whether or not there are conditions that need to be considered
 Note: Collision handling related to SSB or RO are to be treated in case 5 and case 8.
According to discussions in RAN1#104bis-e, some companies prefer to make new agreements under Case 5 and 8 instead of revising the previous agreements. Therefore, the FL suggestion is to come back to Case 3 after Case 5 and 8 have been discussed clearly.
For the second FFS in the agreement, contribution [Samsung09] presents two conditions can be further considered. One is to use the SFI to cancel one of the directions. Another is to use a priority indication for collision handling in some cases, e.g., CG-PUSCH with small periodicity overlapping with PDCCH in CSS set.

Whether SFI can be optionally supported for HD-FDD UE
Regarding whether SFI can be optionally supported for HD-FDD UEs, the following are discussed in a few contributions:
 Contribution [Nokia 06] indicates that there is no need to support dynamic SFI for HD-FDD RedCap UE.
 Contribution [Intel18] raises a potential issue when SFI is supported for HD-FDD UEs. Currently, the DL SFI and UL SFI are separately processed as NR FDD, an open issue is the order to check SFI and to apply overlap handling of a DL reception and a UL transmission since the SFI may cancel certain configured DL reception or UL transmission in the set of overlapped symbols.

Definition and Identification of HD-FDD UE
One contribution presents view on the UE capability reporting of HD-FDD.
 Contribution [OPPO13] proposes that UE capability of HD-FDD is explicitly defined and to be known by gNB. And the HD-FDD capability of RedCap UE should be identifiable by gNB during the initial access since it may be requested for configuring HARQ-ACK to ensure non-zero gap between the PUCCH and previous DL transmission

Annex: Companies＊ point of contact
FL1 Question: Please consider entering contact info below for the points of contact for this email discussion.
CompanyPoint of contactEmail addressvivoXueming Panpanxueming@vivo.comCATTYongqiang FEIfeiyongqiang@catt.cnSpreadtrumSicong ZhaoSicong.zhao@unisoc.comDOCOMOShinya Kumagaishinya.kumagai@docomo-lab.comZTE, SanechipsYoujun Huhu.youjun1@zte.com.cnEricssonJohan Bergmanjohan.bergman@ericsson.comNordicKarol Schoberkarol.schober@nordicsemi.noNokia, NSBRapeepat Ratasukrapeepat.ratasuk@nokia-bell-labs.comIntelYingyang Liyingyang.li@intel.comApple Hong Hehhe5@apple.com QualcommJing Leileijing@qti.qualcomm.comLenovo, Motorola MobilityYuantao Zhangzhangyt18@lenovo.comSamsungSeunghoon Choiseunghoon.choi@samsung.com
References
[1]RP-211574Revised WID on support of reduced capability NR devicesEricsson[2]R1-2106213RAN1 agreements for Rel-17 NR RedCapRapporteur (Ericsson)[3]R1-2106461Duplex operation for RedCapHuawei, HiSilicon[4]R1-2106565Duplex operation for RedCapEricsson[5]R1-2106603Discussion on RedCap half-duplex operationvivo, Guangdong Genius[6]R1-2106650UE Complexity Reduction aspects related to duplex operationNokia, Nokia Shanghai Bell[7]R1-2106706Discussion on duplex operation for RedCapSpreadtrum Communications[8]R1-2106843HD-FDD for reduced capability NR devicesZTE, Sanechips[9]R1-2106896HD-FDD Operation for RedCap UEsSamsung[10]R1-2106979Discussion on HD-FDD operationCATT[11]R1-2107042On aspects related to duplex operationNordic Semiconductor ASA[12]R1-2107129Discussion on duplex operation for RedCapChina Telecom[13]R1-2107251On half-duplex operationOPPO[14]R1-2107353Type-A HD-FDD for RedCap UEQualcomm Incorporated[15]R1-2107410Discussion on collision handling of HD-FDD operationCMCC[16]R1-2107450Aspects related to the duplex operation of RedCapLG Electronics[17]R1-2107497On half duplex operation for RedCap UEsMediaTek Inc.[18]R1-2107597On HD-FDD support for RedCapIntel Corporation[19]R1-2107748Duplex Operation for RedcapApple[20]R1-2107796Discussion on the duplex operation of redcap UEsSharp[21]R1-2107811Duplex operation for RedCap UEsInterDigital, Inc.[22]R1-2107866Discussion on duplex operation for RedCapNTT DOCOMO, INC.[23]R1-2107928Discussion on Half-duplex FDD operation of Redcap UEXiaomi[24]R1-2108042Aspects related to duplex operationPanasonic Corporation[25]R1-2108061Discussion on aspects related to duplex operationASUSTeK[26]R1-2108155Discussion on duplex operation for RedCap UEWILUS Inc.[27]R1-2106244FL summary #3 on duplex operation for RedCapModerator (Qualcomm)