3GPP TSG-RAN WG1 Meeting #105-e R1-210xxxx e-Meeting, 19th – 27th May 2021 Agenda Item: 8.6.1.3 Title: FL summary [#2] on duplex operation for RedCap Source: Moderator (Qualcomm Inc.) Document for: Discussion, Decision 1 Introduction This feature lead (FL) summary concerns the Rel-17 work item for support of reduced capability (RedCap) NR devices [1]. Earlier RAN1 agreements for this work item are summarized in [2]. This document summarizes contributions [3] – [30] submitted to agenda item 8.6.1.3 and captures the following email discussion for the RedCap WI. [105-e-NR-R17-RedCap-03] Email discussion regarding aspects related to duplex operation – Chao (Qualcomm) * 1st check point: 5/21 * 2nd check point: 5/25 * Final check: 5/27 The issues in this document are tagged and colour coded with High priority or Medium priority. In a first round of this discussion, companies were invited to comment on the High Priority questions/proposals. The latest versions of the FL proposals and questions are tagged ‘FL2”. 2 HD-FDD switching time 2.1 General 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. o FFS: whether to define the guard times in symbol units o FFS: the switching positions * Sending an LS to RAN4 to inform the above working assumption, and to ask for feedback if any o 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 made the following WA regarding HD-FDD switching time for RedCap [2]: Working assumption: * For HD-FDD, no additional UE behavior for switching position determination is specified as compared to the existing specification. From the received response, no issue is found for reusing the existing mechanism to determine the switching position for HD-FDD RedCap UEs. Therefore, the following proposal can be considered. High Priority Proposal 2-1: Confirm following working assumption * For HD-FDD, no additional UE behavior for switching position determination is specified as compared to the existing specification Company Y/N Comments Sharp Y We are ok with the proposal Spreadtrum Y vivo Y Huawei, HiSi Y CATT Y ZTE, Sanechips Y NordicSemi Y Nokia, NSB Y Xiaomi Y LG Y Qualcomm Could the FL clarify if this proposal includes the FFS bullets pending RAN4 reply ? DOCOMO Y Intel Y Samsung Y Ericsson Y China Telecom Y CMCC Y OPPO Y FL2 According to discussion in the GTW session, we will come back to this FFS after RAN4 providing feedback on the transition time. 2.2 Open issue: whether to define the guard time in symbol units Contributions [3, 5, 8, 7, 10, 11, 13, 27, 28] express views on whether to define the guard time in symbol units. * No need to define the guard time in symbol units o Supported by Ericsson, vivo, CATT, ZTE, Nokia, China Telecom, Sharp * The guard time is defined in the symbol units instead of the actual time unit. [1] OFDM symbol duration for 15, 30 or 60 kHz SCS can be considered o Supported by WILUS, Qualcomm * Further discuss after deciding whether TDD-like configuration is supported o Supported by Asia Pacific Telecom, FGI The issue has been discussed in the last RAN1 meeting. Decision cannot be made since it may be related to the decision on whether to introduce semi-static TDD-like slot format for HD-FDD RedCap UEs. Also, it may need the reply LS from RAN4 for the transition time. 3 Collision handling 3.1 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. o 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 [3, 5, 16] indicated that the FFS is relevant only for the case of UE capable of partial cancellation. In such case, gNB can take into account the Tx/Rx switching time when scheduling dynamic DL to avoid collision with switching time and there is no need to extend the timeline to include the Tx/Rx switching time. Contributions [6, 8, 11, 14, 19, 28] express the similar view. Contributions [4, 7, 18] expressed views that whether to introduce an extended timeline to include the switching time can be further discussed, after RAN4 providing feedback about the Tx/Rx switching time. In the contribution [9] it was viewed that similar to BWP switching time and uplink switching gap that have been included in Tproc,2, the Tx/Rx switching can be considered in PUSCH preparation time Tproc,2 for HD-FDD case.. It was noted in the contribution [27] that UE may switch to UL transmission before the DCI scheduling a DL reception is decoded and in such case a UL-to-DL switching time is needed for UE to cancel the configured UL transmission and to perform the DL reception. Normally, PUSCH preparation time Tproc,2 is much larger than the Tx/Rx switching time and therefore UE could perform PUSCH preparation at the same time as Rx/Tx switching. Also, gNB would be expected to ensure sufficient switching time is available for UE before DL reception. Then, the necessity to extend the timeline to include the Tx/Rx switching time is not clear. But this can be revisited if a large Tx/Rx switching time is introduced by RAN4. High Priority Proposal 3.1-1: * For Case 1, the existing timeline in Rel-15/16 NR for operation on a single carrier /single cell in unpaired spectrum is reused for HD-FDD o Can revisit if a large Tx/Rx switching time is required for HD-FDD based on RAN4 feedback Company Y/N Comments Sharp It can be remained as “FFS” waiting for RAN4 feedback Spreadtrum Y As summarized above, we think gNB can take into account the Tx/Rx switching time when scheduling dynamic DL to avoid collision with switching time and there is no need to extend the timeline to include the Tx/Rx switching time. But at this stage, we can accept the FL proposal. vivo Y Huawei, HiSi Y CATT Y OK ZTE, Sanechips Y NordicSemi Y Nokia, NSB Y Xiaomi Y LG Y Qualcomm Agreed with the comments of Sharp. If there is a possibility/need to revisit it after getting RAN4’s feedback, it is not necessary to have this proposal now in RAN1. DOCOMO Y Intel Y Samsung In general, we are fine with the main bullet. In our understanding on the sub-bullet, it is related to how to secure the switching time. So, it would be good to first clarify how to secure the switching time in the current specification since a TDD UE already requires the switching time as well. That is, whether the switching time is secured by UE implementation within the timeline or is secured by scheduling dynamic DL to avoid collision with switching time. Ericsson Y with modification We would like to suggest the sub-bullet is revised as follows. * Can revisit if needed, considering a possibility for gNB to ensure sufficient switching time for UE and if a large Tx/Rx switching time is required for HD-FDD based on RAN4 feedback China Telecom Have the same view with Sharp and Qualcomm. CMCC Y OPPO Y 3.2 Case 2: Semi-statically configured DL reception vs. dynamically scheduled UL transmission RAN1#104bis-e reached the following agreements [2]: 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 o 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) o The dynamically scheduled UL transmission may include PUSCH, PUCCH, SRS or PRACH triggered by PDCCH order The remaining FFS is regarding whether or not the UL cancellation indicator (UL CI) is included as part of PDCCH in the collision handling rule. Contribution [30] has expressed view that ULCI is a key enabler for the coexistence of IWSN and URLLC devices in a spectral efficient manner and RedCap UE can support ULCI without an increase in UE complexity. Therefore, in contribution [30] it is proposed that RedCap UE should prioritize reception of PDCCH carrying ULCI over dynamically scheduled UL transmission In contribution [6] it is viewed that a minimum value of UL CI periodicity needs to be considered for HD-FDD RedCap UE to monitor ULCI. Contributions [7, 8] propose that ULCI is not supported by HD-FDD RedCap UE, and contributions [11, 19, 20] indicate whether or not ULCI is supported by RedCap Ues can be discussed in a later stage for UE feature discussion. Contributions [3, 4, 5, 9, 16, 18, 20, 24, 28, 29] express view that no special handling is required to support ULCI for HD-FDD RedCap Ues. It is noted in contribution [3] that it may not even be possible to make an exception in the rule by simply excluding PDCCH carrying UL CI unless some indication is introduced to allow UE to distinguish a PDCCH carrying ULCI from other PDCCHs without actually decoding it. Since a clear majority view is not to have an exception for PDCCH carrying ULCI in the collision handling rule, the following proposal can be considered. High Priority Proposal 3.2-1: * For Case 2, no special handling for PDCCH carrying ULCI, if supported Company Y/N Comments Sharp Y Spreadtrum This proposal means the dynamically scheduled UL is prioritized when the dynamically scheduled UL is overlapped with UL-CI. If we adopt this proposal, it may bring negative impacts to URLLC. The UL-CI is introduced to cancel the UE’s UL transmission without higher requirements on latency/reliability, and maintain the performance of URLLC service. If the UL-CI is dropped, the transmission information of URLLC is unknown to the RedCap UE, and the follow-up transmission in UL from RedCap may bring interference to URLLC. Therefore, we think the UL-CI is very important in coexistence scenarios, and the reception of PDCCH carrying ULCI should be prioritized over dynamically scheduled UL transmission. Further, considering the periodicity of UL-CI is relatively small (from mini-slot level to 10 slots), it may lead to very frequent switching between UL and DL or even have no opportunity to transmit in UL for RedCap, so we think the UL-CI periodicity should be no smaller than X slots for RedCap Ues. Vivo Y Huawei, HiSi Y CATT Y ZTE, Sanechips It is suggested that whether or not ULCI is supported by RedCap Ues should be discussed firstly after BWP related issues have more progress. It is too early to discuss the detailed collision handling principle for PDCCH carrying ULCI. NordicSemi Y * The requirements for these services are higher than LPWA (i.e. LTE-MTC/NB-IoT) but lower than URLLC and eMBB. * Device complexity: Main motivation for the new device type is to lower the device cost and complexity as compared to high-end eMBB and URLLC devices of Rel-15/Rel-16. This is especially the case for industrial sensors. URLLC is not in scope of this WID. And this should have been pointed out already yesterday when URLLC CQI Table 3 was discussed. Nokia, NSB Y Xiaomi Y LG Y Qualcomm Agree with the comments of ZTE. ULCI processing with relaxed timeline helps with the co-existence of RedCap UE and non-RedCap (e.g. eMBB) UE, especially after UL coverage recovery/enhancement is introduced in R17. DOCOMO Y Intel Y We are supportive to the FL proposal. We agree with the analysis in [3]. On the other hand, there is no special handling on the priority rule of UL CI for non-RedCap UE too. Therefore, we think no special handling is needed for a low-cost low complexity UE. Samsung Y Ericsson Y CMCC Y OPPO Y Even a RedCap UE support ULCI, the gNB should avoid scheduling that dynamical UL to avoid conflicting. gNB should ensure the overall system works well. FL1 18 companies (Sharp, vivo, Huawei, HiSi, CATT, ZTE, Sanechips, NordicSemi, Nokia, NSB, Xiaomi, LG, DOCOMO, Intel, Samsung, Ericsson, CMCC, OPPO) support FL proposal. 3 companies (Spreadtrum, ZTE, Qualcomm) are not supportive to FL proposal. 1 company (Spreadtrum) proposes that the reception of PDCCH carrying ULCI should be prioritized over dynamically scheduled UL transmission and special handling for the periodicity of ULCI is also needed. Following the majority view, the proposal below is proposed for agreement. High Priority Proposal 3.2-1: * For Case 2, no special handling on the priority rule for PDCCH carrying ULCI, if supported by HD-FDD RedCap UEs Based on the proposals in FL summary #1 in R1-2106006, the following RAN1 agreements were made in an online (GTW) session on Friday 22nd May: Agreement: * For Case 2 (semi-statically configured DL reception vs. dynamically scheduled UL transmission), a HD-FDD RedCap UE is not required to monitor ULCI o No special handling on the priority rule for PDCCH carrying ULCI 3.3 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 o 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 o 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 o 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 o FFS on cell-specifically configured DL reception vs. cell-specifically configured UL transmission o FFS: whether or not there are conditions that need to be considered The remaining FFS is regarding a collision between cell-specifically configured DL reception and cell-specifically configured UL transmission. Many contributions express view that an exception could be made for the case of cell-specially configured DL reception vs. cell-specially configured UL transmission, particularly SSB vs. valid ROs where overlapping occasions are allowed. Contributions [5, 7, 12, 17] indicate there are some overlapping between case 3, case 5 and case 8, and further identification on the cell-specifically configured DL reception and cell-specifically configured UL transmission other than SSB and valid ROs are required. Contributions [4, 5, 6, 7, 9, 11, 14, 16, 22, 26, 28, 29] express view that the cell-specifically configured DL reception may also comprise cell specific PDCCH (i.e. in Type-0/0A/1/2 CSS set) and the corresponding PDSCH (i.e. on paging/SI occasions). In contributions [4, 11, 14] it is viewed that the cell specially configured UL transmission comprises also cell specific PUCCH configured by PUCCH-ConfigCommon. Since common PUCCH is used only before RRC connection, and the DL reception and UL transmission for initial access procedure are sequentially operated for a given UE, it seems no need to define collision handling rule for common PUCCH. Collision handling or prioritization can be left to UE implementation. High Priority Question 3.3-1: For case 3 of cell-specially configured DL reception vs. cell-specially configured UL transmission, is it sufficient to consider the following subcases? To avoid overlapping with case 5 and case 8, can these subcases be discussed under Case 8? * Subcase 1: Configured SSB vs. valid RO * Subcase 2: PDCCH in CSS and the corresponding PDSCH vs. valid RO Company Y/N Comments Sharp Y Spreadtrum Y vivo Indeed there were some overlap among different cases. We would be fine if these cases (collision between cell-specific configured DL and cell-specific configured UL ) will be explicitly discussed in case 5 or case 8. Huawei, HiSi Almost In case 2-step RACH is supported later some rewording is needed. The RO and PRU are bundled in 2-step RACH, and these are also cell-specially configured UL resource, thus, the “RO” in this proposal needs to be changed to “RO, or RO+PUSCH in msgA”. CATT Y For Subcase 1, discussion in either case 5 or case 8 is fine to us. ZTE, Sanechips Y Agree that Subcase1 and Subcase2 should be discussed under Case 8. NordicSemi Y WID: “Specify functionality that will enable RedCap UEs to be explicitly identifiable to networks through an early indication in Msg1 and/or Msg3, and Msg A if supported, …” PUSCH occasions of MSGA is FFS Nokia, NSB Y Xiaomi Y LG Similar view with Huawei and NordicSemi. Valid PUSCH occasion for step-RACH should also be taken into account. Can be discussed under Case 8 together with valid RO. Qualcomm Y partially Agree with the comments of LG and NordicSemi. The subcases listed above can be a starting point for discussion. Additional cases can be further discussed if needed. DOCOMO Y Also fine to consider 2-step RACH case Intel Y We are supportive to FL proposal. For HD-FDD, it may need a clarification what is the definition of ‘valid RO’. To avoid duplicated discussion on the definition, it is reasonable that all ‘valid RO’ related case is merged to Case 8. Samsung The subcases are fine, except the corresponding PDSCH. PDCCH scheduled PDSCH can be treated as dynamic DL. As one FFS for Case 3 on whether or not there are conditions that need to be considered, there exist CG for UL with a small periodicity (e.g., 2 symbols). With such small periodicity of CG, there is no way for a gNB to configure a search space for PDCCH without a collision with the CG and then the gNB cannot avoid the collision of semi-static UL and semi-static DL. In addition, similar collision may happen between CG UL and CSS configured in a cell-specific way.To address the issue, the priority indication can be considered to solve the conflict between semi-static UL and DL. In addition, SFI is the existing mechanism for FDD and then for HD-FDD RedCap UE, SFI can be used to cancel one of the directions whether the semi-statically configured DL is received, or the semi-statically configured UL is transmitted. Ericsson Y The FL suggestion is fine with us. However, there are additional overlapping between Cases 3, 5, and 8. We suggest the 2nd sub-bullet in the agreement should exclude SSB to avoid overlapping with Case 5, and the 3rd sub-bullet in the agreement should exclude RO to avoid overlapping with Case 8. China Telecom Y There are some overlapping between collision handling cases. We do not want see any discrepancy and duplicated discussions. CMCC Y Remove “the corresponding PDSCH” in subcase 2. OPPO Y We are also fine to consider the 2-step PRU, if it can also be looked as RO conflicting case. 3.4 Case 4: Dynamically scheduled DL reception vs. dynamic scheduled UL transmission RAN1#104bis-e reached the following agreements [2]: Agreements: * 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 o That is, it is considered as an error case if a dynamically scheduled DL reception overlaps with a dynamically scheduled UL transmission From the received responses, no open issue has been identified for Case 4. 3.5 Case 5: Configured SSB vs. dynamically scheduled or configured UL transmission 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: o Option 1: Follow the handling of case 2 that dynamic UL is prioritized over SSB o Option 2: Reuse the existing collision handling principles of Rel-15/16 for NR TDD that SSB is prioritized over dynamic UL o Option 3: Leave to UE implementation whether to receive the SSB or transmit the UL transmission o Other options are not precluded * If a semi-static configured UL transmission overlaps with an SSB, down-select from the following options: o Option 1: Up to gNB configuration to avoid such collision and if it happens it is an error case o Option 2: Reuse the existing collision handling principles of Rel-15/16 for NR TDD that SSB is prioritized over semi-static UL o Option 3: Leave to UE implementation whether to receive the SSB or transmit the UL transmission o 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 3.5.1 Configured SSB overlaps with dynamic UL For the case of configured SSB overlaps with dynamically scheduled UL transmission, companies’ views are summarized in Table 3.5-1. Table 3.5-1: Views on collision handling for configured SSB vs. dynamically scheduled UL transmission Index Description Companies # of Companies Option 1 Follow the handling of case 2 that dynamic UL is prioritized over SSB Nokia, Ericsson, Huawei, CATT, China Telecom, WILUS, ASUSTEK 76 Option 2 Reuse the existing collision handling principles of Rel-15/16 for NR TDD that SSB is prioritized over dynamic UL Intel, Apple, LGE, Xiaomi, Qualcomm, OPPO, Potevio, Lenovo, Sharp, DCM, Panasonic, MTK, IDCC, NordicSemi 1415 Option 3 Leave to UE implementation whether to receive the SSB or transmit the UL transmission Apple, Samsung, Spreadtrum, CMCC, ASUSTEK 5 Option 4 If SSB is indicated by SSB-MTC, SSB is prioritized; otherwise the dynamically scheduled UL is prioritized vivo 1 Option 5 If dynamically scheduled UL is during RA procedure, UL transmission is prioritized; otherwise the SSB reception is prioritized ZTE 1 Based on Table 3.5-1 above, clearly Option 2 is the preferred option by major companies. From the received response, the concern on Option 2 is less flexible compared to Option 1, however, it imposes less impact on UE measurement using SSB consistent with TDD. For example, the SSB-based neighbor cell RRM measurement (SSB within SMTC) will not be cancelled by DCI. High Priority Proposal 3.5-1: * For Case 5 of SSB overlaps with dynamically scheduled UL transmission, re-use the existing collision handling principles of Rel-15/16 for NR TDD that configured SSB is prioritized over dynamic UL o Configured SSB includes the SSB indicated by ssb-PositionsInBurst and/or SSB-MTC Company Y/N Comments Sharp Y vivo Y Huawei, HiSi N Prioritizing SSBs used also for legacy UEs will just restrict network configuration/dynamic scheduling for RedCap UEs. And especially for HD-FDD in FDD network reusing the rules designed for TDD brings similar network restriction to a FDD network where it does not have to before, which is not desirable. From UE perspective, a RedCap UE is not expected to support too many collision handling rules. Sometime the SSBs do not necessarily to be decoded, and consider those as normal semi-static resources is simpler and sufficient. CATT N We think dynamic UL should be prioritized in this case. A gNB will schedule the UE with a dynamic grant only when the gNB thinks it is proper and urgent. Even if dynamic UL is prioritized, if the gNB would like to leave the UE to receive SSB, it can choose not to send the dynamic grant. Note that the SSB occupies non-negligible number of DL symbols and we don’t want them totally unavailable for UL transmission. ZTE, Sanechips Different from TDD, spectrum resources are separate for UL and DL in HD-FDD. The collision handling principle for HD-FDD RedCap UEs may not completely reuse the principle of legacy TDD NR. If dynamically scheduled UL is transmitted in RRC_CONNECTED mode, we agree that the SSB reception is prioritized if the collision happens. During random access procedure, considering that the UE is establishing a connection with gNB, the UE will not do SSB reception. Therefore, at least in random access procedure, the SSB reception is not prioritized over dynamically scheduled UL transmission (e.g., Msg3 or Msg3 re-transmission). For the subbullet, in TS38.331, SSB-MTC is used to indicate SSB measurement period and time duration, the measured SSB index(s) is indicated by ssb-ToMeasure. Therefore, the SSB used for measurement is indicated by both SSB-MTC and ssb-ToMeasure. NordicSemi Y The same reason as TDD apply for HD-FDD, SSB is a priority for UE. There is no need to change spec. Nokia, NSB N Our preference is Option 1 (not Option 2 as stated in the above table). We think that dynamic UL transmission should be prioritized as that is what the gNB has decided. We think the behavior should be consistent with Case 2. Xiaomi Y We support the FL proposal. LG Y The same principle with TDD is preferred. Minimum spec impact is also an important aspect that we have to keep in mind. o Duplex operation: * HD-FDD type A with the minimum specification impact (Note that FD-FDD and TDD are also supported.) Qualcomm Y We can live with this proposal. On the other hand, a simpler way for NW and RedCap UE to handle this and other cases of direction collisions is to specify a semi-static slot format (similar to NR TDD) for RedCap UE, and the semi-static slot format can be configured by SI/RRC. DOCOMO Y Intel We are supportive to reuse existing rule from NR TDD to handle Case 5. One clarification on the sub-bullet. Do we need a special handling for SSB indicated by SSB-MTC? If I didn’t miss something, the existing specification doesn’t describe the way to handle overlap a SSB indicated by SSB-MTC and UL transmission. SSB in current specification. That means, gNB should gurantee such overlap doesn’t happen. Following the same principle, gNB may also guarantee no overlap SSB indicated by SSB-MTC and UL transmission for a HD-FDD UE. With the analysis, it means it is enough to agree on the main bullet of FL proposal. Samsung N We think HD-FDD is different from TDD case and the TDD solution shall not be reused in the Case 5. In TDD system, a gNB will transmit SSB as DL and the gNB cannot receive UL at the same time. However, in FDD system, from gNB point of view, we don’t see any issue for the gNB to receive UL and transmit SSB at the same time. And from UE point of view, for most of the case, UE doesn’t need to receive SSB in connected mode. Even in the case that UE needs to receive SSB, there is no harm for the gNB to try to receive the dynamically scheduled UL transmission. We don’t see the need to introduce unnecessary rule for UE to handle some special case. We think option 3 is the best option. Ericsson On an FDD carrier, at any given time there are both DL and UL resources, since there are separate DL and UL frequency allocations. Thus, in FDD every SSB symbol in principle overlaps with an UL symbol, from a network perspective. However, in the TDD case, such overlapping occurs much less often. Thus, we think reusing the existing collision handling principles of Rel-15/16 TDD for HD-FDD could result in unnecessary constraint for dynamic UL scheduling. We see the benefit of additional flexibility of Option 1. For example, for SSB occasions intended for RRM measurements, gNB can avoid scheduling dynamic UL overlapping with such SSB. For other occasions, gNB would have more flexibility to schedule UL data without much constraint. China Telecom N In our understanding, configured SSB can be treated as semi-statically configured DL reception. We do not want see any discrepancy between Case 2 and Case 5. Considering less flexible for Option 2, we prefer Option 1. CMCC N We prefer option3. A RedCap UE does not always need to do SSB reception and gNB may not know exactly whether a UE needs to receive SSB at a time. For HD-FDD case, during the overlapping symbols of SSB and dynamic UL transmission, when a RedCap UE doesn’t need to receive SSB, RedCap UE can perform UL transmission. When a RedCap UE has requirement to receive SSB, RedCap UE can perform SSB reception. For option2, if SSB is always prioritized, DL symbols of SSB will be unavailable for UL transmission, the resource utilization is sacrificed. OPPO Y For half-duplex UE, it seems not very urgent to have UL priority transmission for the very small latency improvement. FL2 Based on the received response, Option 1 and 2 have more support than other options. o Option 1: Follow the handling of case 2 that dynamic UL is prioritized over SSB * (10) Supported by Huawei, HiSi, vivo, CATT, Nokia, NSB, Ericsson, China Telecom, WILUS, ASUSTEK o Option 2: Re-use the existing collision handling principles of Rel-15/16 for NR TDD that configured SSB is prioritized over dynamic UL. * (14) Supported by Sharp, vivo, NordicSemi, Xiaomi, LG, Qualcomm, DOCOMO, Intel, Apple, OPPO, Potevio, Lenovo, Panasonic, MTK, IDCC For option 3, two companies support it. But the concern is the reduction in resource utilization efficiency since network cannot know whether UE performs scheduled UL transmission or not. Regarding ZTE’s comment on initial access, probably we can add one FFS for Option 2 that whether or not the same UE behavior is applied to Msg3 initial and/or retransmission. Also, for Option 2, the sub-bullet on configured SSB has been removed to align with the current specification for NR TDD based on the received response. High Priority Proposal 3.5-1: * For Case 5 of SSB overlaps with dynamically scheduled UL transmission, down-select from the following options in RAN1#105-e: o Option 1: Follow the handling of case 2 that dynamic UL is prioritized over SSB o Option 2: Re-use the existing collision handling principles of Rel-15/16 for NR TDD that configured SSB is prioritized over dynamic UL. * FFS whether or not the same UE behavior is applied to Msg3 initial and/or retransmission. Ericsson Y (prefer Option 1) On an FDD carrier, at any given time there are both DL and UL resources, since there are separate DL and UL frequency allocations. Thus, in FDD every SSB symbol in principle overlaps with an UL symbol, from a network perspective. However, in the TDD case, such overlapping occurs much less often. Thus, we think reusing the existing collision handling principles of Rel-15/16 TDD for HD-FDD could result in unnecessary constraint for dynamic UL scheduling. We see the benefit of additional flexibility of Option 1. For example, for SSB occasions intended for RRM measurements, gNB can avoid scheduling dynamic UL overlapping with such SSB. For other occasions, gNB would have more flexibility to schedule UL data without much constraint. FUTUREWEI2 Y (prefer option 1) 3.5.2 Configured SSB overlaps with configured UL For the case of configured SSB overlaps with semi-statically configured UL transmission except valid RO, companies’ positions are summarized in Table 3.5-2. Table 3.5-2: View on collision handling for semi-statically SSB vs. semi-statically configured UL except valid RO Index Description Companies # of Companies Option 1 Up to gNB configuration to avoid such collision and if it happens it is an error case Nokia, Lenovo (for UE-dedicated configured UL), Sharp 3 Option 2 Reuse the existing collision handling principles of Rel-15/16 for NR TDD that SSB is prioritized over semi-static UL CATT, Apple, Samsung, LGE, Xiaomi, WILUS, Qualcomm, OPPO, Potevio, Lenovo (for cell specific configured UL), DCM, Panasonic, MTK, IDCC, NordicSemi 15 Option 3 Leave to UE implementation whether to receive the SSB or transmit the UL transmission Ericsson (based on RRM requirement), Intel, Apple, Spreadtrum, CMCC, ASUSTEK 6 Option 4 If SSB is indicated by SSB-MTC, SSB is prioritized; otherwise the semi-static UL transmission prioritized vivo 1 Option 5 If semi-static UL is in RA procedure, UL transmission is prioritized; otherwise the SSB reception is prioritized ZTE 1 Option 6 Follow the handling of Case 3 by considering SSB as semi-statically configured DL. The exact procedure depends on whether the semi-static UL is UE specific or cell level configured Huawei, China Telecom 2 Based on Table 3.5-2 above, clearly Option 2 is the preferred option by major companies. From the received response, the concern on Option 1 is that it is difficult to avoid overlapping of some periodic occasions. Option 3 may lead to increased gNB blind decoding of UL transmission or UE’s power consumption in case NW assumes UE prioritizes SSB. Option 2 can be reasonable to reuse the existing collision handling principles of Rel-15/16 for NR TDD. High Priority Proposal 3.5-2: * For Case 5 of SSB overlaps with semi-statically configured UL except valid RO, re-use the existing collision handling principles of Rel-15/16 for NR TDD that configured SSB is prioritized over configured UL o Configured SSB includes the SSB indicated by ssb-PositionsInBurst and/or SSB-MTC Company Y/N Comments Sharp N The gNB should avoid configuring semi-static UL overlaps with the SSB.For example, if a periodic PUCCH that overlaps with the SSB is cancelled, it will introduce an additional HARQ delay. vivo Y Huawei, HiSi N Prioritizing SSBs used also for legacy UEs will just restrict network configuration for RedCap UEs, e.g. configured UL grant with short periodicity will not be able to be used, or introducing more delay thus more power consumption for RedCap UEs if SSBs are prioritized. It would be desirable to enable more flexibility for network to handle different priority for collision handing in different scenarios. CATT Y, partially We can accept prioritizing SSB in this case, or give the decision to network as HW suggested. ZTE, Sanechips In TS 38.331, cell specific PUCCH parameters is configured by IE PUCCH-ConfigCommon, thus the corresponding PUCCH is considered as semi-statically configured UL and is used to carry HARQ-ACK of Msg4. During random access procedure, since the UE is establishing a connection with gNB, the UE will not do SSB reception obviously. Therefore, at least in random access procedure, the SSB reception is not prioritized over semi-statically configured UL transmission (PUCCH for HARQ-ACK of Msg4). For the subbullet, in TS 38.331 SSB-MTC is used to indicate SSB measurement period and time duration, the measured SSB index(s) is indicated by ssb-ToMeasure. Therefore, the SSB used for measurement is indicated by both SSB-MTC and ssb-ToMeasure. NordicSemi Y Periodic PUCCH is for SR and CSI. HARQ-ACK is indicated dynamically by K1, gNB may schedule in next UL symbol or slot. There has not been issues with this in TDD and no issues are seen in HD-FDD. Moreover, URLLC latency is not an KPI defined by the WID, target service requirements “are higher than LPWA (i.e. LTE-MTC/NB-IoT) but lower than URLLC and eMBB” Nokia, NSB N We think this kind of situation should be avoided by gNB. If it cannot be avoided, then we can leave it to UE implementation. It would not be a good idea to always prioritize SSB. Xiaomi Y LG Y May not be the best solution. But, also don’t see a strong motivation to handling the same situation different for HD-FDD. Qualcomm Y Agree with the comments of LG. On the other hand, a simpler way for NW and RedCap UE to handle this and other cases of direction collisions is to specify a semi-static slot format (similar to NR TDD) for RedCap UE, and the semi-static slot format can be configured by SI/RRC. DOCOMO Y Intel We are fine to reuse the rule in existing spec due to the clear majority of Option 2. We think agree on the main bullet is sufficient, with same analysis as for dynamic UL. Samsung Y Ericsson Similar to our comment for Proposal 3.5-1. On an FDD carrier, at any given time there are both DL and UL resources, since there are separate DL and UL frequency allocations. Thus, in FDD every SSB symbol in principle overlaps with an UL symbol, from a network perspective. However, in the TDD case, such overlapping occurs much less often. Thus, we think reusing the existing collision handling principles of Rel-15/16 TDD for HD-FDD could result in unnecessary constraint for utilizing the configured UL resources. This may as a consequence unnecessarily reduce the UL resource utilization. China Telecom N Have the same view with High Priority Proposal 3.5-1. In our understanding, configured SSB can be treated as semi-statically configured DL reception. We do not want see any discrepancy between Case 3 and Case 5. Hence, we prefer Option 6 by following the handling of Case 3. CMCC In this case, we prefer to left it to UE implementation depending on whether RedCap UE needs to receive the SSB or transmit the UL transmission. OPPO Y, partially We think the reusing existing rules should further clarify. E.g. is that reusing of TDD rules or FDD rules. Both are existing in the spec. FL2 For Option 1, as commented by companies, it is difficult to avoid overlapping of some periodic occasions, e.g. configured UL grant with short periodicity. Therefore, Option 1 is not acceptable due to unnecessary constraint for periodic UL resource configuration for HD-FDD RedCap UEs. The similar issue can be found also for Option 6 since the agreement for Case 3 assumes it is an error case for collision between semi-statically configured DL reception and UE dedicated configured UL (e.g. CG-PUSCH with short periodicity). Therefore, the proposed way forward is to down-select from Option 2 and Option 3. o Option 2: Re-use the existing collision handling principles of Rel-15/16 for NR TDD that configured SSB is prioritized over configured UL * (16) Supported by vivo, CATT, NordicSemi, Xiaomi, LG, Qualcomm, DOCOMO, Intel, Samsung, OPPO, Apple, WILUS, Potevio, Panasonic, MTK, IDCC o Option 3: Leave to UE implementation whether to receive the SSB or transmit the UL transmission * (4) Supported by vivo, Nokia, NSB, Ericsson, CMCC High Priority Proposal 3.5-2: * For Case 5 of SSB overlaps with semi-statically configured UL except RO, down-select from the following options in RAN1#105-e o Option 2: Re-use the existing collision handling principles of Rel-15/16 for NR TDD that configured SSB is prioritized over configured UL o Option 3: Leave to UE implementation whether to receive the SSB or transmit the UL transmission Ericsson Y (prefer Option 3) Similar to our comment for Proposal 3.5-1. On an FDD carrier, at any given time there are both DL and UL resources, since there are separate DL and UL frequency allocations. Thus, in FDD every SSB symbol in principle overlaps with an UL symbol, from a network perspective. However, in the TDD case, such overlapping occurs much less often. Thus, we think reusing the existing collision handling principles of Rel-15/16 TDD for HD-FDD could result in unnecessary constraint for utilizing the configured UL resources. This may as a consequence unnecessarily reduce the UL resource utilization. FUTUREWEI2 Prefer option 3 3.5.3 Whether to account for Tx/Rx switching time Regarding to the FFS on whether/how to account for Tx/Rx switching time before and after the set of SSB symbols, there are different views as summarized below * 2 companies: Ericsson, vivo, think there is no need to account for Tx/Rx switching time before and after the set of SSB symbols * 1 company, ZTE, views Tx/Rx switching time should be considered for determining the collision * 1 company: LGE, thinks the Rx-to-Tx switching time after the set of SSB symbols neds to be accounted for HD-FDD * 1 company, Samsung, thinks the Tx/Rx switching time is considered for SRS overlapped with SSB since SRS can be transmitted before and/or after the set of SSB symbols Since the UE behavior as described in the working assumption for Case 9 can ensure that Tx/Rx switching time is fulfilled for the case of SSB immediately followed by an UL transmission or SSB immediately follows the last symbol of an UL transmission, it is reasonable not to account for Tx/Rx switching time before and after the set of SSB symbols. High Priority Question 3.5-1: * For Case 5, is it sufficient not to account for Tx/Rx switching time before and/or after the set of SSB symbols for HD-FDD? If not, please provide the justifications why it cannot be covered by the working assumption for Case 9. Company Y/N Comments Sharp N It depends on if SSB is always prioritized and can be remained as FFS vivo Y We agree with the FL assessment. Huawei, HiSi Y CATT Not sure whether there are some cases need to consider the switching time, e.g. CG-PUSCH repetitions overlapping with SSB and if SSB is prioritized. We can keep it as FFS. ZTE, Sanechips N For Case 5, if SSB reception is prioritized, the UE will do SSB reception in the overlapped resources. Moreover, in order to guarantee the successful reception of SSB, the UE is not expected to transmit UL in a set of symbols before the first configured symbol of the SSB reception. The size of the set of symbols depends on the value of Tx to Rx switching time. However, based on the collision handling principle of “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” in the WA of Case 9, last part of SSB reception within the Tx to Rx switching time will be dropped if the gap between UL transmission and SSB reception is less than the Tx to Rx switching time, obviously it may cause the unsuccessful reception of SSB. Therefore, the switching direction defined in the WA of Case 9 cannot be completely reused for case 5. NordicSemi Y Fine to postpone Nokia, NSB Y Xiaomi We are fine to further discuss on this issue. From our perspective, if it is agreed to always prioritize SSB reception, taking the switching time into account could helpful to guarantee that SSB reception is not interrupted. LG N If SSB is prioritized, then the Tx/Rx switching time should be taken into account. Either gNB takes it into account, or a collision handling rule needs to be developed to take it into account. Qualcomm N The TX/RX switching time needs to be accounted for. DOCOMO Y Intel Tx/Rx switching time has impact on transmission/reception of HD-FDD UE, so it should be handled. For example, if overlap between SSB and SRS is considered, if some SRS symbols are dropped without considering Tx/Rx switching time, the gap between SSB and remaining SRS symbol may be less than Tx/Rx switching time. We need clarification whether such a case can happen and how to handle such case. Our preference is to discuss all Tx/Rx switching time related things under Case 9 Samsung If there is a partial overlap between UL (e.g., multiple SRS symbols) and SSB, it is true SRS can be transmitted by considering the RX/TX switching time before and after the set of SSB symbols. In this sense, if Case 9 can ensure the RX/TX switching time by UE implementation, we are fine with not accounting additional switching time. Ericsson Y (if clarification on Case 9 is added, see our comments on Case 9) A clarification on the interpretation of Case 9 working assumption is needed, especially on UE behavior to ensure that the switching time is satisfied, e.g., in case SSB is immediately followed by a (semi-static) UL transmission or SSB immediately follows the last symbol of a (semi-static) UL transmission. See also our comments on Case 9. China Telecom Fine to revisit it after Case 9 has been discussed clearly. CMCC N Similar view as ZTE, xiaomi, LG. For Case 5, if SSB reception is prioritized and the first SSB symbol is after the first symbol of UL transmission, based on the collision handling principle of Case 9, first part of SSB reception within the Tx/Rx switching time will be dropped if the gap between UL transmission and SSB reception is less than the Tx/Rx switching time, which may cause the unsuccessful reception of SSB. If SSB reception is prioritized and the first SSB symbol is before the first symbol of UL transmission, the reception of SSB is not impacted OPPO Decide after case9 FUTUREWEI2 Y 3.6 Case 8: Dynamic or semi-static DL vs. valid RO 3.6.1 Valid RO overlaps with dynamic DL Table 3.6-1 summarizes the proposed options for the case of valid RO overlaps with dynamically scheduled DL reception. Table 3.6-1: View on collision handling for dynamic DL vs. valid RO 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 Ericsson, ZTE, Qualcomm, Intel, Apple, Potevio, Lenovo, IDCC 7 Option 2 Leave to UE implementation whether to receive the SSB or transmit the PRACH on a valid RO Spreadtrum, Nokia, CMCC, ASUTEK 4 Option 3 Follow the handling of Case 1 to cancel PRACH based on a timeline (Interpretation 2 in R1-2103809) CATT, China Telecom 2 Option 4 Valid RO including Ngap symbols before the valid RO is prioritized over dynamic UL (Interpretation 3 in R1-2103809) LGE, DCM, Panasonic, NordicSemi 4 Option 5 Down-select from the options provided in R1-2103809 vivo 1 In RAN1#104bis-e meeting, an issue on collision handling for PRACH transmission for Rel-15/16 NR was discussed in email thread [104b-e-NR-7.1CRs-03], and the summary can be found in R1-2103809. Although there are different interpretations of the existing collision handling principles on the current spec, the issues will not be further discussed for Rel-15 and Rel-16. High Priority Question 3.6-1: * For Case 8 of valid RO overlaps with dynamically scheduled DL reception, is it sufficient to down-select from the following options? If not, what other options can be considered? o 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 o Option 2: Leave to UE implementation whether to receive the SSB or transmit the PRACH on a valid RO o Option 3: Follow the handling of Case 1 to cancel PRACH based on a timeline (Interpretation 2 in R1-2103809) o Option 4: Valid RO including Ngap symbols before the valid RO is prioritized over dynamic UL (Interpretation 3 in R1-2103809) o 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) Company Y/N Comments Sharp Y Spreadtrum Y Fine with the FL proposal. Fix a possible typo: * For Case 8 of valid RO overlaps with dynamically scheduled DL reception, is it sufficient to down-select from the following options? If not, what other options can be considered? o 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 o Option 2: Leave to UE implementation whether to receive the SSB or transmit the PRACH on a valid RO o Option 3: Follow the handling of Case 1 to cancel PRACH based on a timeline (Interpretation 2 in R1-2103809) o Option 4: Valid RO including Ngap symbols before the valid RO is prioritized over dynamic UDL (Interpretation 3 in R1-2103809) o 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) vivo Regarding option 1, clearly no common understanding on how to interpret Rel-15/16 TDD behavior, as captured in R1-2103809. We should either remove option 1, or try to clearly spell out what is the intended behavior. We are fine with other options. Huawei, HiSi Whatever option is agreed it will imply R15/R16 is the same handing, since it is agreed to reuse the handling from R15/R16. We would prefer companies who choose Option1 also indicate their opinion of other options, as it is not clear to us which one is the R15/R16 behavior in mind. In addition, can PUSCH in msgA be accounted in the above? Since it is associated with RO and cell specific, it would be good to treat it together instead of taking it in other cases separately. CATT First of all, since this proposal is discussing dynamic DL vs. valid RO, it seems Option 2 is unnecessary to be placed here. Secondly, we have similar concern with vivo. ZTE, Sanechips Y NordicSemi Y We support Option 3, as Initial access folks in R15 agreed an exception to general design made by HARQ and scheduling. The fact that such agreement was not incorporated to Sub-clause 11 of 38.213 is a shame of whole 3GPP ??. Nokia, NSB Y Xiaomi Y Since it is “dynamically scheduled DL” in the main bullet, from our understanding, option 2 should be “Leave to UE implementation whether to receive the SSBDL or transmit the PRACH on a valid RO”. LG Y We also think some clarification on the intention of Option 1 is needed as it was confirmed in the previous meeting that companies have different understandings on the existing collision handling principles of Rel-15/16 for NR TDD for operation on a single carrier /single cell in unpaired spectrum. Qualcomm Y Agree with the comments of Spreadtrum and Xiaomi. On the other hand, a simpler way for NW and RedCap UE to handle this and other cases of direction collisions is to specify a semi-static slot format (similar to NR TDD) for RedCap UE, and the semi-static slot format can be configured by SI/RRC. DOCOMO We share the same view with vivo Intel Y We share the views from vivo that Option 1 should clarified. Without clarification, agreeing on Option 1 unfortunately means there is no common understanding on the UE operation in some scenarios of Case 8. Samsung Y Ericsson It seems that Options 3, 4, 5 are different interpretations of Option 1. Therefore, it is not possible to really separate them. Moreover, the reference to interpretations 1, 2, 3 in R1-2103809 is rather unclear since R1-2103809 discuss both Rel-15 and Rel-16 where there is a difference on how “timeline” is used depending on the UE capability of partial cancellation. It is better to spell out the rule in each option more clearly, considering also UE capability of partial cancellation. China Telecom Agree with vivo and CATT. Reusing the existing collision handling principles of Rel-15/16 for NR TDD is not clear for us. In our understanding, valid RO can be treated as semi-statically configured UL transmission. We do not want see any discrepancy between Case 1 and Case 8. CMCC Y Fine with Xiaomi’s modification. OPPO We also think the option1 need to be clarified. Which existing one, TDD or FDD. 3.6.2 Valid RO overlaps with configured DL For the case of valid RO overlaps with semi-statically configured DL reception, contribution [5] proposed to clarify whether the semi-static DL includes only cell-specifically configured DL reception with the assumption of the UE-dedicated configured DL covered by the agreement for Case 3. The contribution [7] also pointed out that following the RAN1#104-e and RAN1#104bis-e agreements there could be two different directions for handling the collision between UE-dedicated configured DL and valid RO. High Priority Question 3.6-2: * For Case 8 of valid RO overlaps with semi-statically configured DL reception, is it common understanding that the semi-statically configured DL includes only cell specifically configured DL reception (i.e. SSB, PDCCH in Type-0/0A/1/2 CSS set and the corresponding PDSCH)? Company Y/N Comments Spreadtrum Y vivo Y CATT We are open to this issue. If semi-statically configured DL includes only cell specifically configured DL reception, this means valid RO is considered as the cell-specific UL transmission in RAN1#104bis-e agreement in Case 3. ZTE, Sanechips Y NordicSemi Y Nokia, NSB Y LG Y Qualcomm Y partially Semi-statically configured DL resources can also include CSI-RS, TRS and PRS. DOCOMO Y Intel Y We are fine to limit it to cell-specific configured DL. The case that valid RO is overlapped with dedicatedly configured DL belongs to Case 3. We would like to know whether/how to differentiate PRACH preamble for CBRA and CFRA? Samsung N First of all, we think the corresponding PDCCH scheduled PDSCH can be treated as dynamic PDSCH. Besides, as we commented above, valid RO potentially might collide with UE specific SPS/CSI-RS. We think some additional rules are needed to handle the collision. Otherwise, this may lead to that a gNB cannot find a proper pattern to configure such features. Ericsson We suggest treating cell specifically configured DL versus Ros as separate sub cases of case 8. We see this is also the intention of the FL in formulating Proposals 3.6-2 and 3.6-3. China Telecom In our understanding, valid RO can be treated as semi-statically configured UL transmission. We do not want see any discrepancy between Case 3 and Case 8. CMCC Y OPPO We can look them mostly in case 8. Table 3.6-2 summarizes the proposed options for the case of valid RO overlaps with SSB. Table 3.6-2: View on collision handling for valid RO vs. SSB Index Description Companies # of Companies Option 1 Leave to UE implementation whether to receive the SSB or transmit the PRACH on the valid RO Ericsson, CATT, Intel, Samsung, Spreadtrum, Nokia, CMCC, Panasonic 8 Option 2 SSB is prioritized over valid RO LGE, OPPO, China Telecomm 3 Option 3 When random access procedure is triggered, the PRACH preamble transmission is prioritized; otherwise, SSB reception is prioritized ZTE 1 Based on Table 3.6-2 above, clearly Option 1 is the preferred option by major companies. Therefore, the following proposal can be considered. High Priority Proposal 3.6-2: * For Case 8 of valid RO overlaps with configured SSB, leave to UE implementation whether to receive the SSB or transmit the PRACH on the valid RO Company Y/N Comments Sharp Y We are ok with the proposal Spreadtrum Y vivo Y Huawei, HiSi N Our understanding is the RO is invalid in R15. CATT Y ZTE, Sanechips Y NordicSemi N Same understanding as Huawei, and we also prefer to follow this principle Nokia, NSB Y Xiaomi Y We can accept the proposal. LG N Same understanding as Huawei and NordicSemi. The same principle can apply without a big issue. Qualcomm Agree with the comments of Huawei. For half duplex operation like TDD and HD-FDD, the RO validation procedure need to account for at least Ngap symbols and RX/TX switching gap. DOCOMO Y We are OK with the proposal Intel Y gNB may not know exactly whether a UE needs to receive SSB or transmit in a valid RO at a time. On the other hand, gNB can anyway simultaneously transmit SSB and do PRACH preamble detection. Therefore, it is preferrable to up to UE implementation to do transmission or reception. Samsung Y Ericsson Y China Telecom Y We are fine with this proposal. CMCC Y OPPO We also prefer Huawei’s view, and seems this invalidation is also exiting behavior We see the implementation solution would lead to unclear procedure. FL1 6 companies (Huawei, HiSi, NordicSemi, LG, Qualcomm, OPPO) indicate support for reusing the existing TDD principles (i.e. Option 3), and therefore the following proposal can be considered. High Priority Proposal 3.6-2: * For Case 8 of valid RO overlaps with configured SSB, down-select from the following options in RAN1#105-e o Option 1: Leave to UE implementation whether to receive the SSB or transmit the PRACH on the valid RO * (16) Supported by Sharp, Spreadtrum, vivo, CATT, ZTE, Sanechips, Nokia, NSB, Xiaomi, DOCOMO, Intel, Samsung, Ericsson, China Telecom, CMCC, Panasonic o Option 2: SSB is prioritized over valid RO (same as TDD case) * (6) Supported by Huawei, HiSi, NordicSemi, LG, Qualcomm, OPPO FL2 Based on the input from companies and the discussion in the GTW session, the proposal is updated as follows: High Priority Proposed Working Assumption 3.6-2: * For Case 8 of valid RO overlaps with configured SSB, leave to UE implementation whether to receive the SSB or transmit the PRACH on the valid RO o The valid RO definition for NR FDD is reused to HD-FDD (i.e. all PRACH occasions are valid) Ericsson Y Table 3.6-3 summarizes the proposed options for the case of valid RO overlaps cell-specific configured DL except SSB. Table 3.6-3: View on collision handling for valid RO vs. cell specific configured DL except SSB 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 Ericsson, ZTE, Apple, LGE, WILUS, IDCC, DCM, NordicSemi 8 Option 2 Leave to UE implementation whether to receive the DL or transmit the PRACH on the valid RO CATT, Nokia, Intel, Spreadtrum, CMCC 5 Option 3 If semi-static DL is PDCCH in Type-2 CSS set, then PDCCH in Type-2 CSS set is prioritized; otherwise the valid RO is prioritized vivo 1 Option 4 Cell-specific configured DL is prioritized over valid RO China Telecomm 1 Option 5 Configured by network, e.g. via a priority indicator Huawei, Samsung 2 High Priority Question 3.6-3: * For Case 8 of valid RO overlaps with cell-specific configured DL except SSB, is it sufficient to down-select from the following options? If not, what other options can be considered? o 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 o Option 2: Leave to UE implementation whether to receive the DL or transmit the PRACH on the valid RO o Option 3: If semi-static DL is PDCCH in Type-2 CSS set, then PDCCH in Type-2 CSS set is prioritized; otherwise the valid RO is prioritized o Option 4: Cell-specific configured DL is prioritized over valid RO o Option 5: Configured by network, e.g. via a priority indicator Company Y/N Comments Sharp Y Spreadtrum Y Fine with the FL proposal. Vivo Same comment as for High Priority Question 3.6-1:, we think Option 1 is unclear due to lack of common understanding about existing behavior. We should either remove option 1, or try to clearly spell out what is the intended behavior. Huawei, HiSi Almost Similar comments that, PUSCH in MsgA may need to be accounted for together. CATT Similar concern as vivo. ZTE, Sanechips Y NordicSemi Almost Similar comment that 2-step RACH is not yet supported for RedCap Nokia, NSB Y Xiaomi Y LG N We would like to add an Option to prioritize the valid RO over the cell-specific configured DL. Qualcomm A simpler way for NW and RedCap UE to handle this and other cases of direction collisions is to specify a semi-static slot format (similar to NR TDD) for RedCap UE, and the semi-static slot format can be configured by SI/RRC. DOCOMO Our preference for this case is not Option 1 and we share the same view with vivo Intel Y Samsung Y Ericsson Y China Telecom Have the same view with vivo. Option 1 is not clear for us. We are open to discuss other options. CMCC Similar view as vivo. OPPO Option 1 should be clarified which existing behaviors are. 3.6.3 Whether to account for Tx/Rx switching time Contributions [18, 19] express view on whether to account for Tx/Rx switching time before and after the valid RO. The contribution [18] proposed that if Ngap symbols are specified for HD-FDD RedCap UEs, it can be utilized as the RX/TX switching time; otherwise the RX/TX switching time can be additionally considered. The contribution [19] indicated that the Rx-to-Tx switching time before the valid RO needs to be accounted for HD-FDD. Similar to Case 5, the UE behavior as described in the working assumption for Case 9 can ensure that Tx/Rx switching time is fulfilled, and therefore, it is reasonable not to account for Tx/Rx switching time before and after the valid RO. High Priority Question 3.6-4: * For Case 8, is it sufficient not to account for Tx/Rx switching time before and/or after the valid RO for HD-FDD? If not, please provide the justifications why it cannot be covered by the working assumption for Case 9. Company Y/N Comments Sharp N It can be remained FFS before discussion for 3.6-3 vivo Y We agree with FL assessment. CATT We think this is similar to the SSB case. We can go back here when the SSB case is clear. ZTE, Sanechips N Similar analysis to question 3.5-1, the switching direction defined in the WA of Case 9 cannot be completely reused for case 8. NordicSemi Fine to postpone to later discussion. There seems not to be lack of proposal in this AI. Xiaomi Similar as comments in question for SSB case. OK to further discuss on this issue. LG N Similar comment as for SSB. Qualcomm N Agree with the comments of LG. DOOCMO OK to postpone Intel As commented to question 3.5-1, we prefer to discuss all Tx/Rx switching related issues with Case 9. Samsung We are fine with not accounting additional switching time if Case 9 can ensure the RX/TX switching time by UE implementation. On the other hand, it would be good to clarify whether or not the Ngap is considered for the collision handling of the HD-FDD RedCap because the Ngap has been specified in TDD only. Ericsson Y (if clarification on Case 9 is added, see our comments on Case 9) A clarification on the interpretation of Case 9 working assumption is needed, especially on UE behavior to ensure that the switching time is satisfied, e.g., in case where semi-static DL reception is immediately followed by a RO. See also our comments on Case 9. China Telecom Fine to revisit it after Case 9 has been discussed clearly. CMCC Fine to postpone. OPPO Decide later. 3.7 Case 9: Collision due to direction switching 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 o 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 o 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 o FFS NTX-RX and NRX-TX o FFS: how it jointly works with the agreement for other collision cases Contributions [5, 8, 16, 24] support to confirm the working assumption. Regarding how it jointly works with the agreement for other collision cases, contributions [3, 5, 11, 14, 24, 29] express the following views. * Ericsson [3]: Collision with the switching time after applying collision handling rules may occur, and for such an occasion, it is up to UE to ensure that the switching time is satisfied * ZTE [11]: Any collision handling principle for Case1~Case 8 should follow the restriction defined for Case 9 * Intel [14]: The similar issue may exist in NR TDD. Further study on the two solutions * MTK [24]: gNB makes sure that collision due to direction switching either does not occur or can be tolerated * NordicSemi [29]: The conclusion from NR TDD in RAN#98b can be followed by HD-FDD UE Since the working assumption for Case 9 is proposed to reuse the same principle as Rel-15/16 UE not capable of full-duplex communication, it is reasonable to follow the same conclusion for TDD. Considering there is nothing in the specification for NR TDD on this issue, there is no need to introduce any special rule to HD-FDD. High Priority Proposal 3.7-4: Confirm the following working assumption with removing the last FFS. * For HD-FDD, reuse the same principle as Rel-15/16 UE not capable of full-duplex communication o 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 o 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 o FFS NTX-RX and NRX-TX. o FFS: how it jointly works with the agreement for other collision cases Company Y/N Comments Spreadtrum Y Fine to confirm the above working assumption. Vivo Y Huawei, HiSi Y CATT Y ZTE, Sanechips Y NordicSemi Y Nokia, NSB Y Xiaomi Y LG N We are not comfortable with removing the FFS. As we are still working on the collision cases, it should be okay to leave the FFS as it is. As a compromise, we can accept to confirm the working assumption without removing the last FFS. Qualcomm Agree with the comments of LG DOCOMO Y Intel We would like to clarity what is the exact intended behavior of the FL proposal. For example, for the overlap between a prioritized DL channel 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. How to handle this case? As we discussed in our contribution, two options can be considered, i.e. either considering it as error case, or consider the Tx/Rx switching time in the overlap handling. We would like to see a common understanding on the issue. Samsung Y Ericsson We still think it helps to add clarification on UE behaviour needed for ensuring that the switching time is satisfied. Our suggestion is the replace the last FFS sub-bullet according to the suggestion below. * For HD-FDD, reuse the same principle as Rel-15/16 UE not capable of full-duplex communication o 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 o 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 o Collision with the switching time after applying collision handling rules may occur, and for such an occasion, it is up to the UE to ensure that the switching time, [NRX-TX Tc] or [NTX-RX Tc], is satisfied. o FFS NTX-RX and NRX-TX. o FFS: how it jointly works with the agreement for other collision cases China Telecom N Agree with LG and Qualcomm. There are still overlapping between collision handling cases. We suggest to keep the last FFS for further check. vivo We would like to comment on Ericsson’s proposed clarification above. Our understanding is that in Rel-15/16, NW shall guarantee sufficient switching time at the UE side, and if not, UE behavior is unspecified. UE is not required to find a way to ensure the switching time if gNB scheduling does not give sufficient time for UE. Since we are going to reuse the Rel-15/16 behavior, so the following are proposed (based on Ericsson’s version) if there is a need to clarify this. * For HD-FDD, reuse the same principle as Rel-15/16 UE not capable of full-duplex communication o 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 o 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 o If Collision with the switching time after applying collision handling rules may still occur, and for such an occasion, the UE behaviour is unspecified. it is up to the UE to ensure that the switching time, [NRX-TX Tc] or [NTX-RX Tc], is satisfied. o FFS NTX-RX and NRX-TX. o FFS: how it jointly works with the agreement for other collision cases CMCC There are still some problems when case 9 jointly works with the agreement for other collision cases. We suggest to further discuss the last FFS. OPPO Y We think Rel-15/16 actually not use the time gap for error cases. If that gap can not meet, the signal in that period is just undefine. The current proposal is in the same way. Ericsson Regarding the latest Vivo comment above, we agree that for dynamic scheduling, the gNB scheduler can try to avoid the collision with the switching time. However, for semi-statically configured DL/UL (including both UE-specific and cell-specific), it may be difficult in general for the network to avoid overlap. Note that it is more likely that “back-to-back” scheduling/configuration of DL/UL will happen in FDD than in TDD. Thus, if “UE behavior is not defined” means that UE would not even consider such configurations as valid, there might be excessive restrictions imposed on network configuration. As a consequence, the performance of HD-FDD UEs might be greatly impacted due to unnecessarily excessive restriction on network configuration. Thus, we think it helps to ensure the RedCap UE does not regard collisions with the switching time in the case of back-to-back transmissions/receptions of configured DL/UL (including both UE-specific and cell-specific) as invalid configurations. FUTUREWEI Y 4 Semi-static UL/DL configuration and dynamic SFI 4.1 Open issue: Whether to introduce semi-static UL/DL pattern Contributions [3, 7, 8, 10, 11, 12, 13, 14, 19, 20] express view on whether to support semi-static TDD-like slot pattern for HD-FDD. Contributions [3, 7, 8, 11, 12] propose that semi-static UL/DL pattern is not considered for HD-FDD due to the following drawbacks * Negative impact on scheduling flexibility * Increased scheduling complexity when there are other FD-FDD UEs in a cell * Will have significant specification impact Contributions [10, 14, 20] think there are clear benefits for HD-FDD UEs to be configured with semi-static UL/DL pattern, such as UE power consumption reduction, compressed Type1 HARQ-ACK codebook size, and allowing gNB to control collision handling and prioritization for the collision between cell-specifically configured DL and UL operation. In contribution [10] it is also proposed that multiple slot formats with complementary DL and UL configurations can be specified for RedCap UEs supporting Type-A HD-FDD operation and sharing the same cell. Contributions [13] indicate that whether it is up to gNB to configure the TDD-like slot pattern needs further study. Contribution [19] expresses view that the semi-static slot format should not be mandatory to support for HD-FDD. High Priority Proposal 4-1: * Further study on whether and what amount of power saving gains can be achieved from configuring semi-static UL/DL pattern to HD-FDD RedCap UEs and decide in RAN1#106-e whether or not to support semi-static UL/DL pattern for HD-FDD Company Y/N Comments Sharp N Huawei, HiSi N Open for discussion if there are sufficient benefits, possibly in addition to power saving gains. CATT N ZTE, Sanechips N Semi-static TDD-like slot format based scheme would introduce negative impact on scheduling flexibility and significant specification impact. Moreover, collision cases and the corresponding collision handling rules for HD-FDD RedCap UEs are under discussion. Once the collision handling rules for all potential collision cases have been clarified, there is no need to further consider semi-static TDD-like slot format based scheme for HD-FDD RedCap UEs. NordicSemi Y “and/or being completely wireless with a battery life of several years” is clearly mentioned in the WID. We are open to further discuss if power saving benefits from TDD config are worth of trouble for HD-FDD UE. Nokia, NSB N We do not support semi-static UL/DL configuration due to the reasons summarized by the FL. Xiaomi Y LG N We also don’t support the semi-static UL/DL pattern for HD-FDD in FDD band. For the proposal itself, the power saving gain, if any, is just one aspect. From our perspective, that is not a game changer due to the drawbacks summarized by the FL. Qualcomm Y We think such option should not be excluded. It is up to NW to decide whether or not to configure a semi-static slot format for RedCap UE. If configured, RedCap UE can benefit from the power saving gain and reduced complexity in handling direction collisions. To reduce the signaling overhead of slot format configuration, NW can broadcast one or two cell-specific D/U/S patterns similar to NR TDD, and HD-FDD UEs can be configured with a slot offset by RRC. DOCOMO N We share the same view with Huawei Intel Y We are supportive to adopt semi-static UL/DL pattern and fine with further study in next meeting. Samsung N Share other companies’ view on no semi-static UL/DL pattern. Ericsson N We see no clear benefit on semi-static UL/DL pattern, but several drawbacks on scheduling flexibility and complexity. It should also be noted that configuring semi-static UL/DL pattern for HD-FDD RedCap UEs as a power saving feature is not in the scope of the WID. China Telecom We are open to have further discussion on this topic. Whether it is up to gNB to configure semi-static TDD-like slot format or not needs further study. If semi-static TDD-like slot formats is supported for RedCap, it should be clarified how to use it to avoid UL/DL collisions. CMCC Y Open for further discussion. OPPO N Seems not benefit for configure it. FL2 13 companies (Sharp, Huawei, HiSi, CATT, ZTE, Sanechips, Nokia, NSB, LG, DOCOMO, Samsung, Ericsson, OPPO) do not support FL proposal and think no need for further discussion on supporting semi-static TDD-like slot format for HD-FDD RedCap UEs. 6 companies (NordicSemi, Xiaomi, Qualcomm, Intel, CMCC, China Telecom) are fine with further study in next meeting for power saving benefits and using it to avoid UL/DL collision. Based on the received response, seems the main concern is whether it is valuable for supporting it to HD-FDD UEs. At this moment there are diverse of companies’ views, and therefore it is reasonable to further study and discuss it in next meeting. High Priority Proposal 4-1: * Further study and discussion until RAN1#106-e on whether specification support of semi-static UL/DL pattern to HD-FDD RedCap UEs can be justified by power saving benefits and reduced complexity in handling direction collisions. Company Y/N Comments Ericsson N [repeat our previous comments] We see no clear benefit on semi-static UL/DL pattern, but several drawbacks on scheduling flexibility and complexity. It should also be noted that configuring semi-static UL/DL pattern for HD-FDD RedCap UEs as a power saving feature is not in the scope of the WID. FUTUREWEI2 N This power savings study is out of scope of the WID 4.2 Open issue: Whether to support dynamic SFI Contributions [12, 14, 18] express view whether dynamic SFI can be optionally supported by HD-FDD RedCap UEs. In contribution [12] it is viewed that the SFI indication that requires the group-common DCI monitoring may be too much complexity for HD-FDD operation Contribution [14] thinks such feature may be beneficial for use in various industrial IoT applications relying on dynamic TDD operations. Contribution [18] indicates that SFI can be used to cancel one of the directions whether the semi-statically configured DL is received, or the semi-statically configured UL is transmitted. 5 Other aspects Definition and identification of HD-FDD UE A few contributions [12, 16] express views on reporting the UE capability of HD-FDD. * OPPO [12]: The HD-FDD capability of RedCap UE should be identifiable by gNB during the initial access * Apple [16]: HD-FDD support is reported through UE capability framework for RedCap devices FD-FDD fallback to HD-FDD One contribution [16] expresses views on enabling FD-FDD fall back operation to HD-FDD * Apple [16]: Support a signaling mechanism to enable HD-FDD operation for a FD-FDD capable RedCap UE References [1] RP-210918 Revised WID on support of reduced capability NR devices Nokia, Ericsson [2] R1-2104027 RAN1 agreements for Rel-17 NR RedCap Rapporteur (Ericsson) [3] R1-2104181 Duplex operation for RedCap Ericsson [4] R1-2104285 Duplex operation for RedCap Huawei, HiSilicon [5] R1-2104367 Discussion on RedCap half-duplex operation vivo, Guangdong Genius [6] R1-2104429 Discussion on duplex operation for RedCap Spreadtrum Communications [7] R1-2104528 Discussion on HD-FDD operation CATT [8] R1-2104545 Aspects related to duplex operation Nokia, Nokia Shanghai Bell [9] R1-2104618 Discussion on collision handling of HD-FDD operation CMCC [10] R1-2104679 Type-A HD-FDD for RedCap UE Qualcomm Incorporated [11] R1-2104712 HD-FDD for reduced capability NR devices ZTE, Sanechips [12] R1-2104784 On half-duplex operation OPPO [13] R1-2104852 Discussion on duplex operation for RedCap China Telecom [14] R1-2104913 On support of HD-FDD for RedCap Intel Corporation [15] R1-2105053 Discussion on aspects related to duplex operation Potevio Company Limited [16] R1-2105113 Duplex operation for RedCap Apple [17] R1-2105219 Half duplex operation for RedCap Lenovo, Motorola Mobility [18] R1-2105318 HD-FDD Operation for RedCap UEs Samsung [19] R1-2105431 Aspects related to the duplex operation of RedCap LG Electronics [20] R1-2105569 Discussion on Half-duplex FDD operation of Redcap UE Xiaomi [21] R1-2105637 Discussion on the duplex operation of redcap UEs Sharp [22] R1-2105705 Discussion on duplex operation for RedCap NTT DOCOMO, INC. [23] R1-2105729 Aspects related to duplex operation Panasonic Corporation [24] R1-2105738 On half duplex operation for RedCap UEs MediaTek Inc. [25] R1-2105748 Duplex operation for RedCap UEs InterDigital, Inc. [26] R1-2105801 Discussion on aspects related to duplex operation ASUSTEK COMPUTER (SHANGHAI) [27] R1-2105823 Discussion on aspects related to duplex operation Asia Pacific Telecom, FGI [28] R1-2105875 Discussion on duplex operation for RedCap UE WILUS Inc. [29] R1-2105884 On aspects related to duplex operation Nordic Semiconductor ASA [30] R1-2105900 Half-duplex FDD redcap operation Sony