3GPP TSG-RAN WG1 Meeting #105-e R1-210xxxx e-Meeting, 19th – 27th May 2021 Agenda Item: 8.6.1.3 Title: FL summary #3 on duplex operation for RedCap Source: Moderator (Qualcomm Inc.) Document for: Discussion, Decision 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. The previous rounds of this email discussion were documented in FL summaries in R1-2106006 and R1-2106145. The latest versions of the FL proposals and questions are tagged ‘FL5”. HD-FDD switching time 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. 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 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. 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 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 Supported by WILUS, Qualcomm Further discuss after deciding whether TDD-like configuration is supported 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. Collision handling 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 [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 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 FL3 Based on the received response, some companies (Sharp, Qualcomm, China Telecom) prefer to revisit the FFS after getting RAN4 feedback. Since it is not urgent, it may be fine to postpone to later discussion 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 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 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 No special handling on the priority rule for PDCCH carrying ULCI 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 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. FL3 Based on the received response, most companies support to discuss the subcases of cell specifically configured DL overlapping with cell specially configured UL in Case 5 and 8. The two subcases can be a starting point for discussion. Additional cases can be further discussed if needed. Regarding whether PUSCH occasions of MSGA in 2-step RACH should be considered as cell-specifically configured UL transmission, the FL suggestion is to discuss it more in Case 8. At least for TDD case, the FL understanding is that the valid RO in collision handling does not include PUSCH occasion of msgA. But it should be fine to discuss it further for HD-FDD. Regarding whether broadcast PDSCH can be treated as cell-specifically configured DL reception, the FL checks the current specification on Case 1 collision handling in TDD, which says “the UE detects a DCI format indicating to the UE to receive CSI-RS or PDSCH in a subset of symbols from the set of symbols”. Note there is no restriction on the DCI format, and therefore dynamic DL should cover also broadcast PDSCH. Companies are welcome to provide comment if there is a different view. Regarding Samsung’s proposal on using the priority indication for collision handling, the FL understanding is it is for the case of cell-specific configured DL overlapping with UE-dedicated configured UL, for which an agreement was made in last meeting. But it is fine to discuss other options that are acceptable to companies. One company (Ericsson) suggests clarifying that the 2nd sub-bullet in the agreement for Case 3 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. Also, based on the response for High Priority Question 3.6-2, most companies think the 3rd sub-bullet in the agreement for Case 3 covers valid RO since majority view for cell specific configured UL transmission refer to a valid RO. To avoid possible misunderstanding, it seems necessary to clarify the 2nd sub-bullet and 3rd sub-bullet in the RAN1#104bis-e agreement for Case 3. Therefore, two new questions 3.3-1a and 3.3-1b are provided for companies to provide their views. Company Y/N Comments Samsung Our proposal about the priority indication is to complement at least sub-bullet 1 and sub-bullet 2 (and possibly sub-bullet 3 as well) in the last agreement. When the gNB wants to configure a small periodicity of the semi-static DL or UL and there is no way for the gNB to avoid such collisions by only scheduling, a configuration of the priority indication would be beneficial to solve the collision. Besides, since A/N for DL SPS can also be treated as UE specific semi-UL, there may also be some issues, e.g., the potential collision with semi-DL (e.g., PDCCH). [FL3] High Priority Question 3.3-1a: For the 2nd sub-bullet in the RAN1#104bis-e agreement for Case 3, is it common understanding that cell-specifically configured DL reception refers to CORESET for Type-0/0A/1/2 CSS set? If not, please provide your view on what is cell-specifically configured DL reception for this agreement? Company Y/N Comments vivo The agreement itself was not clear. However, to avoid duplicated discussion, we are fine to restrict the discussion to CORESET for Type-0/0A/1/2 CSS set in case 3, given the understanding that the collision handling between related to SSB are to be treated in case 5. Qualcomm For PDCCH in Type-1 CSS and the associated RAR, they are dynamically (in response to msg1 from a certain RO) instead of semi-statically scheduled in time. Therefore, we don’t think they belong to semi-statically configured DL reception. Panasonic Y OPPO Yes China Telecom Y Huawei, HiSi Although the SSB is surely one of cell-specifically configured DL resources, for the discussion progress, we are fine to consider it in case 5. Spreadtrum Similar views with vivo. NordicSemi Y Intel Y CMCC Y Sharp Y ZTE, Sanechips Y Xiaomi Similar view as HW. DOCOMO Y Nokia, NSB Y LG Y Ericsson Y Might be good to further clarify that collision handling related to SSB are to be treated in case 5. CATT Y Fine to discuss SSB collision case in Case 5 Samsung Y It is our view the cell-specific configured DL includes CORESET for type-0/0A/1/2 CSS set. WILUS Y [FL3] High Priority Question 3.3-1b: For the 3rd sub-bullet in the RAN1#104bis-e agreement for Case 3, is it common understanding that cell-specifically configured UL transmission refers to valid RO? If not, please provide your view on what is cell-specifically configured UL transmission for this agreement. Company Y/N Comments vivo Y Qualcomm We think msgA PUSCH occasion should also be considered here, but can live with this proposal if that is the majority view of companies. Panasonic Y OPPO Yes China Telecom Y Huawei, HiSi We think MsgA PUSCH also needs to be considered. Spreadtrum Y NordicSemi Y MSGA (if supported) Intel Y CMCC Y PUSCH occasion of msgA can also be considered. Sharp Y ZTE, Sanechips Y The valid RO related collision handling rules in Case 3 is overlapped with that of case 8, thus to avoid overlapping with Case 8, it is suggested that valid RO is not included in Case 3. Xiaomi Yes We also think MsgA PUSCH can be included. DOCOMO Y MsgA PUSCH occasion is also included subject to the support of 2-step RACH Nokia, NSB Y LG N We think valid RO should be handled in Case 8. The same collision handling as in TDD is preferred. Ericsson N Similar to the comment from ZTE, Sanechips, we also suggest that valid RO is not included in Case 3, but treated in Case 8. We would like to note that when the agreement for Case 3 was made in RAN1#104bis, there was a parallel discussion on Case 8 specifically for valid ROs. For Case 8, the discussion included sub-dividing semi-statically configured UL/DL into sub-cases of cell-specific and UE-specific configurations. In our understanding, the intention was to treat collision handling related to RO separately. Thus, in our view, similar to collision handling related to SSB, collision handling related to RO should be treated separately in Case 8. This is also consistent to how the collision handling in TDD is specified. If we treat valid RO vs. UE-specific DL in Case 3 instead, it means that gNB should not e.g. configure PDCCH monitoring occasions or DL SPS occasion overlapping with ROs; otherwise the UE behavior is not defined. This is even more restrictive than the existing collision handling for TDD copied below. Note that the 1st paragraph below is about the error case, but it specifically says that that is for dedicated higher layer parameters configuring transmission versus dedicated higher layer parameters configuring reception. Since it is for higher layer parameters configuring transmission, it does not include valid ROs. Note also that the 2nd paragraph below covers RO where it says at least the configuration resulting in overlapping occasions between dedicated higher layer parameters configuring reception and ROs is allowed and the UE prioritizes PRACH. For a set of symbols of a slot that are indicated to a UE as flexible by tdd-UL-DL-ConfigurationCommon, and tdd-UL-DL-ConfigurationDedicated if provided, the 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 by the UE in the set of symbols of the slot. For a set of symbols of a slot corresponding to a valid PRACH occasion and Ngap symbols before the valid PRACH occasion, as described in Clause 8.1, the UE does not receive PDCCH, PDSCH, or CSI-RS in the slot if a reception would overlap with any symbol from the set of symbols. The UE does not expect the set of symbols of the slot to be indicated as downlink by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated. CATT As discussed in our contribution, valid RO is considered as the most typical cell-common UL. However, since case 8 is used to discuss valid RO, we think RO-related issue can be discussed in case 8. Other cell-common UL, if any, can be discussed in case 3. Samsung Y It is our view that cell-specific configured UL includes valid RO. WILUS Y MSGA PUSCH is also included (if supported) Summary of the 2nd round email discussion: For the 2nd sub-bullet in the RAN1#104bis-e agreement for Case 3, most companies have the same understanding as the FL that cell-specifically configured DL reception refers to CORESET for Type-0/0A/1/2 CSS set. One company (Qualcomm) thinks that PDCCH in Type-1 CSS is dynamically scheduled (in response to msg1 from a certain RO) and therefore should not be included in cell-specially configured DL reception. Also, companies (vivo, Huawei, HiSi, Spreadtrum, Xiaomi, Ericsson, CATT) indicate it may be good to clarify to further clarify that collision handling related to SSB are to be treated in case 5. For the 3rd sub-bullet in the RAN1#104bis-e agreement for Case 3, most companies support the FL proposal that cell-specifically configured UL transmission refers to valid RO. Companies (ZTE, Sanechips, LG, Ericsson) view that valid RO should not be included in Case 3, but treated in Case 8. One company (Ericsson) also indicate it is even more restrictive than TDD if we treat valid RO vs. UE-specific DL in Case 3 that means that gNB should not e.g. configure PDCCH monitoring occasions or DL SPS occasion overlapping with ROs. Companies (Qualcomm, Huawei, HiSi, NordicSemi, CMCC, Xiaomi, DOCOMO) express view that PUSCH occasion of msgA can also be considered. Way forward by the FL: Although PDCCH in Type-1 CSS is dynamically scheduled in time in response to msg1 transmission by UE, the FL understanding it is still possible to treat PDCCH in Type-1 CSS vs. UE-specific configured UL in Case 3, it means that gNB should not configure PDCCH monitoring occasions for Type-1 CSS overlapping with CG-PUSCH, PUCCH or SRS. If PDCCH in Type-1 CSS is treated as dynamically scheduled DL, collision with semi-static UL cannot be covered by the agreement for Case 1 since only dynamic DL scheduled by DCI, such as PDSCH or CSI-RS is considered in Case 1. The FL suggests more companies to provide views on whether PDCCH in Type-1 CSS can be covered by Case 3 or not. Regarding whether to treat valid RO vs. UE-specific DL in Case 3, the FL is fine to further discuss it considering no explicit specification on cell specifically configured UL transmission in the agreement and the intention to treat collision handling related to RO separately in Case 8 following the RAN1#104-e agreement. Therefore, the following proposal can be considered. [FL4] High Priority 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. Company Y/N Comments LG Y DOCOMO Y We are fine with the revision CATT Y vivo Though no objection, we prefer to not revise the previous agreement, instead we can make new agreements, e.g. under case 5 or case 8 to specify the UE behavior regarding SSB and RO. Samsung We are fine with that PDCCH in Type-1 CSS is covered by Case 3 and also RO is handled in Case 8 as suggested by FL. But, we suggest to further clarify whether the cell-specific DL in the second bullet includes the parameters configured in dedicated signaling, since PDCCH-ConfigCommon can be configured in SIB as well as in dedicated signalling. In our understanding, as long as the parameters are cell specific parameters, they are covered by second bullet.   On the other hand, as commented several times, we’d like to further discuss collision issues if a small periodicity is configured for the semi-static DL or UL (e.g., 2 symbols for UL CG, 1 slot for DL SPS) because it is difficult to avoid such collisions by only gNB scheduling. So, we’d like to add one more FFS as follows: FFS: how to address a collision if a small periodicity is configured for the semi-static DL or UL. Intel Y We are supportive to the FL proposal Huawei, HiSi There are many companies proposing to clarify MsgA PUSCH which is missing in either the FL consideration or the proposal. Some clarification from FL is preferred. Fine with Samsung adding. Fine/better with new agreements as vivo commented. Type-1 CSS is also a semi-static configured reception, as in current spec. The bracket is not necessary. NordicSemi Y In our understanding PDCCH-ConfigCommon in SIB1 configures PDCCH in Type-0/0A/[1]/2 CSS set. But this could be clarified in FL proposal Nokia, NSB Y ZTE, Sanechips Y IDCC Y MediaTek Y Ericsson Y FL5 The intention of this proposal is to clarify whether collision handling related to RO is treated in Case 8 or in Case 3. It may not be desirable to introduce any new aspect for discussion. If the current proposal is not acceptable, then vivo’s proposal with new agreements under case 5 or case 8 may also work from the FL perspective. Regarding Samsung’s comment, I think your proposal of priority indication approach has been included as one option for the collision handling of valid RO vs. PDCCH. Whether it can be used for other cases (e.g. CG PUSCH vs. SPS PDSCH) can be further discussed in the next meeting. 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 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. 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: 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 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 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. 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. 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 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: Option 1: Follow the handling of case 2 that dynamic UL is prioritized over SSB 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) Qualcomm Y (prefer option 2) To minimize the spec impact for HD-FDD and reduce UE’s complexity in half duplex operations (TDD and HD-FDD), the direction collision handling procedures of NR TDD on single carrier should be re-used. LG Y (prefer option 2) Share the same view with Qualcomm. FL3 Regarding FFS on Option 2, the FL’s understanding is that if the same UE behavior is applied to Msg3 initial and/or retransmission, gNB may not receive Msg3 from HD-FDD UEs when collision with SSB. Then does it imply that early indication of HD-FDD UE capability is needed to avoid possible Msg3 loss from HD-FDD UEs? For companies supporting Option 2, please also provide your views on the FFS part if possible. 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: Option 1: Follow the handling of case 2 that dynamic UL is prioritized over SSB 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 Company Y/N Comments vivo Y We prefer option 1. This is a new scenario which unlikely to happen in Rel-15/16 TDD, therefore reusing Rel-15/16 TDD behavior would cause gNB scheduler restrictions unnecessarily. Qualcomm Y The initial transmission and/or retransmission of msg3 are based on a dynamic grant transmitted in CSS, which should be treated as dynamic UL transmission. Panasonic Y (prefer option 2) Handling on Msg3 needs further discussion. Having the FFS is fine to us. Even if it was agreed that Msg3 is dropped, the gNB would schedule Msg3 so as to avoid the SSB. Then we think it may not be a large issue although it can be worth discussing whether there is a significant effect on resource utilization. OPPO Y (prefer option 2) For the earlier indication, it is also supported by majority of companies. In that case, gNB would know the msg3 conflicting with SSB. There is no clear benefit to introduce that priority to let UL override SSB. China Telecom Y Considering less flexible for Option 2, we prefer Option 1. Huawei, HiSi Y(prefer option 1) Similar view with vivo. NordicSemi Y It is up to gNB whether it wants to adopt its MSG3 scheduling also for legacy UEs, or it will configured early identification for RedCap UEs, to handled potential HD-FDD UEs. At Chipset side there is clear benefit of having same behavior if reduced capability half-duplex UE shall support both TDD and FDD bands. Intel Y (Option 2) For msg3 initial or retransmission, gNB may schedule UL resources that are not overlapped with SSB. CMCC Y (prefer option 1) Option 1 enables higher resource utilization efficiency and the Msg3 issue does not exist. Sharp Y(option 2) ZTE, Sanechips Y (Option 2) We support Option 2 with FFS sub-bullet. For dynamic UL except for Msg3 initial and/or retransmission, SSB is prioritized. But during random access procedure, considering that the UE is establishing a connection with gNB, the UE will not do SSB reception. Moreover, in FDD system, FD-FDD RedCap UE can transmit Msg3 and receive SSB simultaneously. If SSB reception is prioritized for HD-FDD RedCap UE, Msg3 transmission will be dropped when collision happens. As a result, the UE behavior during random access procedure may be different for FD-FDD RedCap UE and HD-FDD RedCap UE if collision happens. If Msg3 initial and/or retransmission is prioritized for HD-FDD RedCap UE, the UE behavior during random access procedure can keep the same for FD-FDD RedCap UE and HD-FDD RedCap UE if collision happens. Therefore, for Msg3 initial and/or retransmission, we think Msg3 initial and/or retransmission should be prioritized over configured SSB. Xiaomi Y (prefer option 2) We do not think early indication of HD-FDD is necessary. We are open to further discuss the FFS subbullet. DOCOMO Y We support Option 2. Collision between SSB and Msg3 initial/retransmission can be avoided by proper gNB scheduling if early indication in Msg1 is used. Nokia, NSB Y (option 1) Option 1 provides greater flexibility to gNB. Also agree with vivo that this is a new scenario specifically for FDD, and therefore we should not reuse TDD principle in this case. LG Y Option 2 is preferred. Agree with the previous comments that the same rule applies to Msg3 initial and retransmission and whether to avoid collision in this case is up to gNB. FUTUREWEI3 Y (option 1) As several companies noted, this is new FDD-specific scenario. The principles for TDD may not be applicable. 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. CATT Y (Option 1) From gNB’s view, a FDD cell is always capable for transmission and reception simultaneously. From UE’s view, a UE is not expected to always receive SSB all the time. Dynamic UL should be prioritized. Note that 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. Samsung Regarding the concern on the UL resource efficiency, it can be a very special case whether SSB and dynamic UL is collided each other and then UL resource efficiency would not be sacrificed so much. So, we believe option 3 is more than enough to address this collision case with no specifications impacts. WILUS Y (Option 1) We support option 1 which can provide higher UL resource efficiency and scheduling flexibility. Summary of the 2nd round email discussion: Companies positions do not change compared to the 1st round email discussion. For the case of SSB vs. dynamic UL, Option 1 and 2 have almost the same number of supports. Option 1: Follow the handling of case 2 that dynamic UL is prioritized over SSB (11+1) Supported by Huawei, HiSi, vivo, China Telecom, CMCC, CATT, Nokia, NSB, Ericsson, FUTUREWEI, WILUS, [ASUSTEK] Option 2: Re-use the existing collision handling principles of Rel-15/16 for NR TDD that configured SSB is prioritized over dynamic UL. (11+5) Supported by Qualcomm, Panasonic, OPPO, NordicSemi, Intel, Sharp, ZTE, Sanechips, Xiaomi, LG, DOCOMO, [Apple], [Potevio], [Lenovo], [MTK], [IDCC] There is similar observation for the case of SSB vs. configured UL except RO as discussed in section 3.5.2. Option 2: Re-use the existing collision handling principles of Rel-15/16 for NR TDD that configured SSB is prioritized over configured UL (14+4) Supported by Qualcomm, Panasonic, OPPO, China Telecom, CATT, CMCC, Sharp, ZTE, Sanechips, Xiaomi, LG, DOCOMO, Samsung (2nd choice), WILUS, [Apple], [Potevio], [MTK], [IDCC] Option 3: Leave to UE implementation whether to receive the SSB or transmit the UL transmission (6) Supported by vivo, Nokia, NSB, Ericsson, Samsung (1st choice), FUTUREWEI Way forward by the FL: Either option has pros and cons. It is very difficult to accommodate all the comments and reach consensus. But for progress we need to make a decision for the down-selection. Since most companies supporting Option 2 for semi-static UL also support Option 2 for dynamic UL, and companies supporting Option 3 for semi-static UL also support Option 1 for dynamic UL, a compromise is to use Option 1 for dynamic UL and Option 2 for semi-static UL. Option 2 for semi-static UL has more supports than Option 3, and there is no issue about uncertain UE behavior since UL resource utilization can be improved by assigning the collided configured UL resources to other FD-FDD UEs. Similarly, Option 1 for dynamic UL subcase provides more flexibility to gNB and the Msg3 issue does not exist. From the FL perspective, the compromised proposal of using Option 1 for dynamic UL and Option 2 for semi-static UL seems reasonable. [FL4] High Priority Proposal 3.5-1: For Case 5 of SSB overlapping with dynamically scheduled UL transmission, follow the handling of case 2 that dynamic UL is prioritized over SSB For Case 5 of SSB overlapping with semi-statically configured UL except RO, reuse the existing collision handling principles of Rel-15/16 for NR TDD that configured SSB is prioritized over configured UL Company Y/N Comments LG N Prioritizing SSB over both dynamic and semi-static UL is simple yet has minimum spec impact. For the first bullet, it is up to gNB to avoid collision of the dynamic UL with the SSB. DOCOMO Y Thanks moderator for proposing a middle ground. We can live with the proposal CATT Y Support the proposal. We can live with prioritizing SSB to semi-static UL. But if SSB is also prioritized even to dynamic UL, it is too restrictive for the scheduling of a FDD cell, and will have non-negligible negative impact on UL data rate/capacity for HD-FDD RedCap UE. vivo Y We would be fine with the compromised proposal Samsung N but For both collision cases, our first preference is UE implementation and then we believe no specification is needed. But, for the sake of progress, we can live with the FL proposal as WA if this is majority support. Intel N We propose a compromise proposal between Option 2 and Option 3 handling semi-static UL in last reply. We would like see if any other companies have the same consideration. Regarding dynamic UL, we share LG’s view that gNB can handle the overlap between SSB and msg3. Therefore, Option 2 is preferred Huawei, HiSi Y NordicSemi N Agree with LG Nokia, NSB Y We prefer to leave the case of SSB overlapping with semi-statically configured UL except RO to UE implementation, but we can accept the compromise. ZTE, Sanechips N For Case 5 of SSB overlapping with dynamically scheduled UL transmission, if dynamic UL is prioritized over SSB, in case the overlapped SSB(s) is used for RRM measurement or carrying updated system information the UE may be disconnected from the system due to not achieving channel quality information or essential system information in time. Therefore, Option 1 is not a good collision handling rule. During initial access procedure, Msg3 initial and/or retransmission is prioritized over SSB. In connected mode, dynamic UL is prioritized over SSB. We suggest to differentiate the two use cases: during initial access procedure or in Connected mode. IDCC N Agree with LG. MediaTek N Agree with LG. Ericsson Y Although we prefer Option 3 for the case of SSB overlapping with configured UL, we are fine with the FL4 proposal for the sake of progress. FL5 Based on the discussion in the GTW session, no consensus on the current proposal. Therefore, the FL suggestion is to revert to the previous separate discussion. It seems the dynamic case is more controversial thus requiring more time for convergence, we can focus more on the semi-static case in the remaining time of this e-meeting. 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 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. 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 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 Option 2: Re-use the existing collision handling principles of Rel-15/16 for NR TDD that configured SSB is prioritized over configured UL 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 Qualcomm Y (prefer Option 2) To minimize the spec impact for HD-FDD and reduce UE’s complexity in half duplex operations (TDD and HD-FDD), the direction collision handling procedures of NR TDD on single carrier should be re-used. LG Y (prefer Option 2) May not be the best solution. But, also don’t see a strong motivation to handle the same situation differently from TDD for HD-FDD. FL3 For Option 3, if it is up to UE implementation, gNB may not know whether or not the UE will transmit on the configured UL resources. This may not be a problem for CG-PUSCH since DTX CG-PUSCH is allowed. But for periodic PUCCH and SRS, it is not clear whether DTX is allowed by the current specification and what is impact on gNB receiver if supported. Companies supporting Option 3, please provide your views on this issue if possible. 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 Option 2: Re-use the existing collision handling principles of Rel-15/16 for NR TDD that configured SSB is prioritized over configured UL Option 3: Leave to UE implementation whether to receive the SSB or transmit the UL transmission Company Y/N Comments vivo Y We prefer option 3, the reason is the same as for Proposal 3.5-1. Regarding PUCCH and SRS transmission behavior for option 3, we think at least periodic SR should have no issue as DTX has been there since Rel-15. For other periodic PUSCH such as P-CSI or beam report, and SRS, we think DTX can also be allowed, given that gNB already knows the UE capability (FD or HD) when configuring the periodic transmission. Qualcomm Y Option 2 is preferred because it won’t cause misunderstandings between UE and gNB. Given UE’s capability for HD-FDD, most of the time NW should be able to avoid the potential collisions between SSB and configured UL. Panasonic Y Support Option 2. OPPO Y (prefer option 2) The collision may happen by the cancellation of UL does not have strong impact. China Telecom Y We prefer Option 2 by reusing the existing collision handling principles of Rel-15/16 for NR TDD. Huawei, HiSi Since this case mainly affects the network’s detection, it is reasonable that network can configure the priority of SSB and configured UL, e.g. in system information. Leaving to UE implementation may cause much invalid detection of gNB. NordicSemi Y Configurability means that UE has to support both. Again the question is whether complexity is at smart gNB or at reduced capability UE. Intel Either option has pros and cons. The concern to Option 3 is that gNB cannot know whether UE transmits the UL channel/signal. As mentioned by Moderator, gNB anyway needs to do blind reception for CG PUSCH. A compromise solution could be For configured UL except CG PUSCH, follow Option 2; For CG PUSCH, follow option 3. CMCC Y Support Option 2. Sharp Y We perfer Option2 ZTE, Sanechips Y Option 2 Xiaomi Y (prefer option 2) Reusing Rel-15/16 UE behavior does not create any problem and thus we do not need to over-optimize on this issue. DOCOMO Y We support Option 2 Nokia, NSB Y We support Option 3. LG Y We prefer Option 2. 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. CATT Y Prefer Option 2. From gNB view, uncertain UE behavior should be minimized. We can live with‘UE implementation’ for the case of cell-common DL vs cell-common UL. By for this case, we prefer Option 2. Samsung Y Prefer option 3 but can live with option 2. For semi-UL, e.g., CG PUSCH, currently, UE can skip the transmission by itself. We don’t see issue to go for option 3 at least for CG-PUSCH. WILUS Y Prefer option 2. Prioritization of SSB over semi-static UL transmission is a baseline. FL5 At least for PUCCH and SRS, network can avoid collision with SSB via proper configuration. In case any collision handling needs to be specified, the existing TDD principle is simple due to minimum spec impact. I think the concern is mainly for CG-PUSCH with small periodicity. As commented by some companies, UE skipping CG-PUSCH transmission is already supported by the spec. The FL suggestion is to agree both proposals, and if not possible at least the first can be considered for agreement. [FL5] High Priority Proposal 3.5-2a: For Case 5 of configured SSB overlapping with semi-statically configured UL including at least PUCCH and SRS, SSB is prioritized over configured UL (same as TDD case) [FL5] High Priority Proposal 3.5-2b: For Case 5 of configured SSB overlapping with CG-PUSCH, leave to UE implementation whether to receive the SSB or transmit the PUSCH Company Y/N Comments vivo Y Maybe it would be better to remove “at least” in the proposal 3.5-2a, unless we have some other things in mind. LG Y to 2a, N to 2b We support the Proposal 3.5-2a. We prefer the same handling for 2b which is to prioritize SSB reception over PUSCH transmission. 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 FL3 Based on the received response, the FL suggestion is to postpone discussing this FFS after Case 9 has been discussed clearly. Case 8: Dynamic or semi-static DL vs. valid RO 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? 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 SSB or transmit the PRACH on a valid RO Option 3: Follow the handling of Case 1 to cancel PRACH based on a timeline (Interpretation 2 in R1-2103809) Option 4: Valid RO including Ngap symbols before the valid RO is prioritized over dynamic UL (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) 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? 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 SSB or transmit the PRACH on a valid RO Option 3: Follow the handling of Case 1 to cancel PRACH based on a timeline (Interpretation 2 in R1-2103809) Option 4: Valid RO including Ngap symbols before the valid RO is prioritized over dynamic UDL (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) 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. FL3 Option 1 is based on the response in the contributions. It is the FL understanding that companies supporting Option 1 want to reuse the same implementation as NR TDD for HD-FDD. That is the motivation for including Option 1. Also, the implementation of Option 1 in specification requires minimum spec change. Since for Option 1 companies may have different interpretation on the existing collision handling principles for NR TDD on the current spec, other options are also introduced to allow having an aligned UE behaviour for HD-FDD. Based on the received response, the following proposal can be considered. The FL suggestion is to further discuss whether Option 1 and/or other options can be removed to simplify down-selection. Companies supporting Option 1, please also indicate which interpretation (Option 3, 4 or 5) is in mind if possible. High Priority Proposal 3.6-1: For Case 8 of valid RO (including Ngap symbols before the valid RO) overlaps with dynamically scheduled DL reception, down-select one from the following option 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 to cancel PRACH based on a timeline 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 PUSCH occasion of MSGA in 2-step RACH, if supported, should be included or not Company Y/N Comments vivo We expect companies prefer option 1 can make a selection among option 3/4/5 so that option 1 can eventually be removed from further consideration. Qualcomm We don’t agree with Option 2 since it leads to ambiguities for both UE and gNB procedures. We support Option 1 in principle. Based on the procedures described in Clause 11.1 of TS 38.213 for NR TDD, a RedCap UE’s procedure should depend at least on its capabilities, including: Whether or not DCI format 2_0 is supported Whether or not partialCancellation is supported In addition, we think a RedCap UE operating in Type-A HD-FDD cannot assume all ROs are valid because the RX-to-TX switching time has to be accounted for. Panasonic Y Support Option 1 at least to avoid spec impact. The interpretation of the current spec needs further discussion. Our original interpretation is option 4. OPPO Y The FFS point of PUSCH MsgA should not be the sub-bullet. The “included or not” is not clear. Is it means included to RO? A specification does not define the PRU as RO. Modification as second bullet: FFS: Whether PUSCH occasion of MSGA in 2-step RACH, if supported, is prioritized if overlapped dynamical DL. China Telecom Y Our interpretation is Option 3. 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. Huawei, HiSi Fine Spreadtrum Y NordicSemi OK Intel We prefer a simple behavior of Option 4. It is up to gNB to avoid a collision between valid RO and dynamic DL channel/signals CMCC Y We support option2, and option1 can be accepted. Sharp Y ZTE, Sanechips Y Xiaomi Our preference is to reuse Rel-15/16 TDD UE behavior to reduce the standardization complexity and to align the UE implementation. Therefore, we can generally agree on option 1. We are not sure whether we need to further make decision among option 3, 4, 5 since no interpretation can be agreed in R1-2103809, and different companies having different interpretations is allowed in Rel-15 and Rel-16. DOCOMO We prefer Option 4. As suggested by moderator, proponents of Option 1 should indicate their interpretation of current spec for proper down-selection Nokia, NSB Y LG Y We prefer Option 4. Agree with Intel in that gNB can avoid the collision if needed. Ericsson We share the same view as Xiaomi. CATT Agree that Option 1 should be removed after detailed interpretation. Prefer Option 3: to cancel PRACH based on a timeline 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 We hope to give the gNB opportunity to perform DL transmission during the valid RO time. Samsung We also agree that option 1 should be clarified. We agree with vivo that, Interpretations in R1-2103809 can be a starting point. If there is no conclusion, we think option 2 can be the final outcome. WILUS Y FL4 Based on the received response, each option has supporting companies. Therefore, let us keep all 5 options at this moment. Also, considering Option 1 can be interpreted as Option 3, 4 or 5, the proposal for down-selecting one option seems problematic. Therefore, the word ‘one” in the main bullet can be removed. Another question from the FL is whether Ngap symbols before the valid RO should be considered for collision handling. According to the discussion in RAN1#92bis, the Ngap symbols after a last SS/PBCH block symbol is introduced to TDD to avoid DL-to-UL interference from neighbor cell, which does not exist for HD-FDD due to UL/DL operation on different bands. If the FDD rule is reused for valid RO in HD-FDD, the question is whether Ngap symbols before the valid RO should be included. The FL proposal is to leave it FFS for further discussion. [FL4]High Priority Proposal 3.6-1: For Case 8 of valid RO (including Ngap symbols before the valid RO) overlaps with dynamically scheduled DL reception, down-select one from the following option 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 to cancel PRACH based on a timeline 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 LG Y We prefer not to change the main bullet as we don’t see it necessary to remove or optimize the Ngap in front of the valid RO for HD-FDD. But, we can live with this proposal if a majority of companies wants to further discuss on this point. We prefer the same handling for the valid PUSCH occasion for MsgA in 2-step RACH. DOCOMO If Option 1 can be interpreted as one of Options 3, 4 or 5, we can live with the proposal. Otherwise, i.e., there is a possibility of another interpretation of Option 1, Option 1 should be FFS. CATT Y, mostly Option 1 seems redundant (eventually it should be one of Option 3, 4 or 5 for clear definition) in this proposal, and does not provide additional information other than Option 3, 4 and 5. But if the majority view is to keep it, we can live with it. vivo We still think companies support option 1 should make a selection among option 2/3/4, yes there is ambiguity in the Rel-15/16 specification but what is the benefit to keep such ambiguity still in Rel-17? Spreadtrum We have the similar views with vivo, we need to make it clear in Rel.17. Samsung Y Intel Y We are fine with current list of Option 1-5. In worst case, if there is no agreement among Option 2/3/4/5, we end up with Option 1 to follow legacy specification Huawei, HiSi Y And also as DCM commented, Option1 can be removed. NordicSemi Y Nokia, NSB Y ZTE, Sanechips Y IDCC Y Mediatek Y Ericsson Y We have the same view as LG that we can keep “(including Ngap symbols before the valid RO)”. We are fine with leave this aspect for FFS. FL5 The main concern for the proposal is whether to include Option 1 in the list. Based on the received response, option 1 is to follow legacy specification for TDD case (although there are different interpretations). From the FL perspective, the proposal is useful for further discussion in the next meeting. At least we can know each company position clearly from the indicated option. The proposal is slightly updated by adding the same FFS for valid RO that has been agreed for the PDCCH case in Tuesday’s GTW session. If there is serious concern on the proposal, please indicate below. [FL5] High Priority Proposal 3.6-1: For Case 8 of valid RO overlaps with dynamically scheduled DL reception, down-select from the following option 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 to cancel PRACH based on a timeline 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 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 vivo We can live with the ambiguity of option 1 in the current proposal as it anyway requires more discussion. LG Y We prefer the definition of valid RO follows the TDD case. Even if the half-duplex RedCap UE operates in FDD bands, unlike full-duplex UEs, it cannot receive in the downlink while transmitting in the uplink. So, while applying the FDD rule means no prioritization for full-duplex UEs, it means the valid RO is always prioritized for half-duplex UEs. One may argue that even with the always-prioritized valid RO, PRACH transmission can be dropped according to current spec. But, as SSB-to-RO mappings are defined based on the valid RO, the valid RO should be protected as much as possible, once it is defined as valid. With all these aspects, we think reusing the TDD rule is simple and proven, and also has the minimum spec impact. 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. FL3 Further discussion will continue in High Priority Question 3.3-1a and 3.3-1b 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 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 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 The valid RO definition for NR FDD is reused to HD-FDD (i.e. all PRACH occasions are valid) Ericsson Y Qualcomm N For UE supporting FD-FDD operation, all ROs are valid because of the presence of duplexer. In HD-FDD operation, the duplexer is assumed to be replaced by a switch and a DL/UL switching gap is needed. Therefore, not all ROs are valid in HD-FDD. For RO validation in HD-FDD, the procedures similar to NR TDD should be used, which needs to take into account at least Ngap symbols as shown by Table 8.1-2 of TS 38.213. LG N Agree with Qualcomm. We need to check the spec carefully if there is no issue when we say all ROs are valid for HD-FDD. Same for the valid PUSCH occasions for the 2-step RACH. FL3 Regarding valid RO for HD-FDD, the FL suggestion is to discuss it separately, which is an FFS in Case 8. Therefore, the proposal is updated as following. High Priority Proposed Working Assumption 3.6-2: For Case 8 of valid RO (including Ngap symbols before the 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 vivo Y Qualcomm A clarification for the RO validation rules is preferred for HD-FDD UE. In configuring the ROs for RedCap/HD-FDD UEs on FDD bands, gNB can take into account the Ngap symbols to avoid a potential waste of the PRACH resource allocation for RedCap UEs. We can discuss this proposal after companies reach a consensus on “valid RO” for HD-FDD UEs. Panasonic Y OPPO N The definition of valid RO is used in the working assumption. However, it is unclear since HD-FDD case newly introduced. We would also prefer to clarify the definition of RO for HD-FDD first, is it: Option 1 Reused for paired spectrum. Leave it for implementation Or, considering prioritization. Option 2 It is invalid if overlapped with SSB. Huawei, HiSi In addition, PUSCH in MsgA needs to be accounted for together, which also requires validation and mapping. Spreadtrum Y NordicSemi Y Based on discussion so far, we prefer to reuse the TDD rules for HD-FDD Intel Y CMCC Y Sharp Y ZTE, Sanechips Y Xiaomi We can accept either option 1 (UE implementation) or option 2 (reusing TDD). We agree with other companies that it may be better to first clarify the definition of valid RO. DOCOMO Y Nokia, NSB Y LG N We agree with previous comments that valid RO needs to be discussed first to proceed with proposed working assumption. Ericsson Y CATT Y Samsung OK with the FL proposal. But, given “the valid RO” is included in the FL proposal, it would be good to clarify first what “the valid RO” means here i.e., all ROs are valid RO in FDD. WILUS Y FL4 Based on the received response, the proposals for “valid RO for HD-FDD” are to reuse either FDD rule or TDD rule. Also, Qualcomm indicates that the Rx-to-Tx switching should be accounted for the RO validation in the discussion of High Priority Proposal 3.6-1. Therefore, the following proposals can be considered. [FL4]High Priority Proposal 3.6-2a: For the definition of valid RO in HD-FDD, down-select one of the following options 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 FFS: whether/how to account for the Rx-to-Tx switching time for the RO validation for HD-FDD Regarding collision b/w SSB vs. RO, the proposal is updated as following. [FL4]High Priority Proposed Working Assumption 3.6-2b: For Case 8 of valid RO (including Ngap symbols before the valid RO) overlapping with configured SSB, leave to UE implementation whether to receive the SSB or transmit the PRACH on the valid RO FFS: whether or not the set of symbols overlapping with SSB 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 LG Y only for 3.6-2a We are okay with the Proposal 3.6-2a only. Our preference is Option 2. In Option 2, SSB is prioritized as the collision would invalidate the RO. If we go for Option 2 for the valid RO, we don’t need to discuss the 3.6-2b, which clearly has the minimum spec impact. DOCOMO Y CATT Y vivo N for Proposal 3.6-2a Y for Working Assumption 3.6-2b Regarding Proposal 3.6-2a:, we are not sure how option 2 can work, since this is an FDD system, option 2 will result in different valid RO set and therefore different SSB-to-RO mapping between FD-FDD and HD-FDD UEs. NW does not know how to perform receiver beam sweeping for RACH reception, and which beam to be selected for RAR transmission. Samsung N We have strong concern on proposal 3.6-2a. We cannot agree on any change of RO validation. Intel Y Option 2 in Proposal 3.6-2a may work, for example if the set of RO for RedCap and non-RedCap UE are separately configured. NordicSemi Y only for 3.6-2a Option 2 is our preference Nokia, NSB Y ZTE, Sanechip For proposal 3.6-2a, we prefer Option 1. Agree with the WA 3.6-2b IDCC Y MediaTek Y Ericsson Y The Rx-to-Tx switching time needed for the RO can be accounted for by keeping Ngap in the collision handling rule. We are fine with leaving the Ngap aspect for FFS. FL5 Based on the received response, Proposal 3.6-2b is dependent on Proposal 3.6-2a, and it can be discussed later when the discussion for valid RO is clear. From the FL perspective, Proposal 3.6-2a is needed to address the FFS part for valid RO in the agreement for collision handling made in Tuesday’s GTE session. For Proposal 3.6-2a, the main concern on Option 2 is the impact on FD-HDD UEs. It can be further discussed. Another question is whether to consider the RO should be after SSB in the PRACH slot. In TDD the valid RO should not precede a SS/PBCH block is to avoid multiple DL/UL switching in a slot. Probably this limitation is not need for HD-FDD when following TDD rule. The FL suggests the proponents of Option 2 confirm whether the FL understanding is correct or not. [FL5] High Priority Proposal 3.6-2a: For the definition of valid RO in HD-FDD, down-select one of the following options 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 FFS the impact on FD-FDD UEs FFS: whether/how to account for the Rx-to-Tx switching time for the RO validation for HD-FDD Company Y/N Comments vivo We can live with current proposal. We think option 2 cannot guarantee the co-existence with FD-FDD UEs, unless NW configures dedicated PRACH resource for HD-FDD UEs. Hope more proponents of option 2 can share their view on this point, which will be useful for the down-selection in next meeting. LG N We prefer the previous version with the [ ] for the Ngap symbols if it is not sure at this time. For the definition of valid RO in HD-FDD, down-select one of the following options 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 FFS: whether/how to account for the Rx-to-Tx switching time for the RO validation for HD-FDD We still see it safer to not allow the valid RO in front of SSB in the same slot wherein Type0-PDCCH CSS are typically monitored. So, we don’t support putting the new [ ] as in FL5. And we don’t think Option 2 is creating any critical issues to the FD-FDD UEs, so prefer to remove the FFS under Option 2. 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? 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 the valid RO 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 Option 4: Cell-specific configured DL is prioritized over valid RO 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. FL3 The FL understanding is that Option 1 of reusing the existing collision handling principles for NR TDD is to prioritize valid RO over cell-specific configured PDCCH when colliding, according to the following specification in 38.213. Companies are welcome to provide comments if there is a different view. // 38.213 For a set of symbols of a slot corresponding to a valid PRACH occasion and symbols before the valid PRACH occasion, as described in Clause 8.1, the UE does not receive PDCCH, PDSCH, or CSI-RS in the slot if a reception would overlap with any symbol from the set of symbols. The UE does not expect the set of symbols of the slot to be indicated as downlink by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated. // Based on the received response, the following proposal can be considered. The FL suggestion is to further discuss whether any options can be removed to simplify down-selection. Note cell specific configured DL except SSB has been replaced by cell specific configured PDCCH since broadcast PDSCH is not cell-specific configured DL reception based on the discussion in High Priority Question 3.3-1. High Priority Proposal 3.6-3: For Case 8 of valid RO (including Ngap symbols before the valid RO) overlaps with cell-specific configured PDCCH in Type 0/0A/1/2 CSS setDL except SSB, down-select one 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 cell-specific configured PDCCH Option 2: Leave to UE implementation whether to receive the cell-specific configured PDCCH or transmit the PRACH on the valid RO Option 3: If cell specific configured PDCCH is in a Type-2 CSS set, then cell-specific PDCCH is prioritized; otherwise the valid RO is prioritized Option 4: Cell-specific configured PDCCH is prioritized over valid RO Option 5: Configured by network, e.g. via a priority indicator FFS: whether PUSCH occasion of MSGA in 2-step RACH, if supported, should be included or not Company Y/N Comments vivo Y We are OK with the proposal based on the clarification from FL. We think paging miss would be highly undesirable, so prefer option 3. Qualcomm N We have concern to categorize the PDCCH in Type 1 CSS as cell-specific. In addition, we think the dependency on UE capabilities (e.g. whether or not partialcancellation and SFI are supported by RedCap UE) and timeline (Tproc,2) should be covered, which are missed from the options above. Panasonic Y Support Option 1. OPPO Y The options are fine for us. The FFS point of PUSCH MsgA should not be the sub-bullet. The “included or not” is not clear. Is it means included to RO? A specification does not define the PRU as RO. Modification as second bullet: FFS: Whether PUSCH occasion of MSGA in 2-step RACH, if supported, is prioritized if overlapped with cell-specific configured PDCCH in Type 0/0A/1/2 CSS. Huawei, HiSi Y Spreadtrum Y Nordic Semi Y Intel Y We prefer Option 2. CMCC Y We support Option 2, and option 1 can be accepted. Sharp Y ZTE, Sanechips Y Xiaomi Y DOCOMO Y Thanks moderator for the clarification of Option 1. We support Option 1 in general, but Option 3 can be considered further as paging drop should be avoided as pointed out by vivo Nokia, NSB Y LG Y We prefer Option 1. Ericsson Y CATT Y Samsung Y WILUS Y Our preference is option 1 but option 2 is acceptable. FL4 The proposal is updated as following. Similar to High Priority Proposal 3.6-1, whether to include Ngap symbols before the valid RO can be further discussed. Also, Type-1 CSS is FFS. The word ‘one” in the main bullet is removed for the possibility using different options for different PDCCH. [FL4]High Priority Proposal 3.6-3: For Case 8 of valid RO (including Ngap symbols before the valid RO) overlapping with cell-specific configured PDCCH in Type 0/0A/[1]/2 CSS set, down-select one 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 cell-specific configured PDCCH Option 2: Leave to UE implementation whether to receive the cell-specific configured PDCCH or transmit the PRACH on the valid RO Option 3: If cell specific configured PDCCH is in a Type-2 CSS set, then cell-specific PDCCH is prioritized; otherwise the valid RO is prioritized Option 4: Cell-specific 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 cell-specific PDCCH 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 LG Y Similar comment as the previous one. We prefer not to change the main bullet as we don’t see it necessary to remove or optimize the Ngap in front of the valid RO for HD-FDD. But, we can live with this proposal if a majority of companies wants to further discuss on this point. We prefer the same handling for the valid PUSCH occasion for MsgA in 2-step RACH. DOCOMO Y CATT Y vivo Y Spreadtrum Y Samsung Y Intel Y Huawei, HiSi Almost Type 1 CSS is not exclusion. NordicSemi Y Nokia, NSB Y ZTE, Sanechips Y IDCC Y MediaTek Y Ericsson Y We have the same view as LG that we can keep “(including Ngap symbols before the valid RO)”. By doing so, we can follow the TDD rule and the Rx-to-Tx switching time needed for the RO would automatically be accounted for. For the sake of progress, we are fine with leaving this aspect for FFS The following RAN1 agreements were made in an online (GTW) session on Tuesday 25th May: 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 Based on the discussion for High Priority Question 3.3-1b, the collision handling for valid RO vs. UE-dedicated configured DL reception should be discussed in Case 8. The following proposal is thus proposed. The options are very similar to those for the PDCCH case except option 3 and 4 are removed. [FL5] High Priority Proposal 3.6-5: 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 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 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 Company Y/N Comments vivo Partially Option 1 is unclear depending on what interpretation is for the existing specification. But similar to the other proposal 3.6-1, we can live with such ambiguity assuming more discussion is needed. And we think it is not clear at this point whether it is good idea to treat all the configured DL reception including PDCCH USS, SPS, CSI-RS, PRS, etc by the same way, so prefer the proposal can be more inclusive. Therefore, we would like to add another sub-bullet “other options are not precluded” LG Y 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. FL3 Based on the received response, the FL suggestion is to postpone discussing this FFS after Case 9 has been discussed clearly. 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 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 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 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 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 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 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. FFS NTX-RX and NRX-TX. 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 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 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. FFS NTX-RX and NRX-TX. 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 FL3 Based on the received response, the concern is that after applying collision handling rule the gap between DL and UL symbols may be less than Tx/Rx switching time. In such case, we can either define clear UE behaviour on how to puncture DL or UL, or just leave it to UE implementation to ensure the sufficient switching time as proposed by Ericsson. A third option is to treat it as an error case (vivo’s proposal), but it may be too restrictive in some cases. Therefore, the FL suggestion is to further discuss it based on Ericsson’s proposal as following. High Priority Proposal 3.7-4: Replace the RAN1#104bis-e working assumption with the following agreement 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 If collision with the switching time after applying collision handling rules may still 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 FFS NTX-RX and NRX-TX. Pending RAN4 feedback FFS: how it jointly works with the agreement for other collision cases Company Y/N Comments vivo Discussion is necessary for the red part It seems at least when one of the duplex collision channel (i.e. DL or UL) is dynamically scheduled, it is agreeable to leave it as an error case, if collision with the switching time after applying collision handling rules may still occur, such understanding is also shared by Ericsson. If the collision transmission and reception are both semi-static configured, we can discuss if optimization is need. But do companies agree with the fact that in Rel-15/16, NW shall ensure such case does not happen, (i.e. collision with the switching time after applying collision handling rules may still occur), which means error case for UE, even for semi-static configured DL and UL, w.r.t the following text in 38.211. 4.3.2 Slots A UE not capable of full-duplex communication is not expected to transmit in the uplink earlier than N_"Rx-Tx" T_"c" after the end of the last received downlink symbol in the same cell where N_"Rx-Tx" is given by Table 4.3.2-3. A UE not capable of full-duplex communication is not expected to receive in the downlink earlier than N_"Tx-Rx" T_"c" after the end of the last transmitted uplink symbol in the same cell where N_"Tx-Rx" is given by Table 4.3.2-3. We have traced the discussion history about this issue, following agreement was made in RAN1#93, and after that, no additional UE behavior was agreed to handle such case, the current spec does not have such UE behavior either, so it should be understood as the error case for UE. Agreements (RAN1#93): UE is not required to receive on a downlink symbol and then transmit on a uplink symbol if those two symbols are not separated by at least Rx2Tx us on unpaired spectrum for a given serving cell, from the UE perspective Discuss further whether it’s an error case or to specify a UE behavior Note that the exact value of Rx2Tx has been specified in RAN4 [R4-1805766] Qualcomm N It is unclear to us how UE can ensure the switching time is satisfied in the third sub-bullet newly added. Actually, if the RX/TX switching time depends on UE capability and is reported to NW, gNB should avoid potential collisions scheduled within the RX/TX switching time. Besides, we don’t understand why the last FFS bullet is removed in this and the previous proposal. Panasonic Y OPPO Y We think the current spec in 211 is actually “It is up to the UE to ensure that the switching time, [NRX-TX Tc] or [NTX-RX Tc], is satisfied”. We don’t think Rel-15 treat it as error case, otherwise the spec don’t work. China Telecom Y We are generally fine with FL proposal. And suggest to keep the last FFS for further check. NordicSemi Y We agree with QC, the behaviour for what to do with TA and switching is not up to UE, rather it is concluded for R15 that UE is not expected to receive the end of DL preceding UL. In a slot having “D”s, “F”s, and “U”s, when the UE is configured to receive/monitor DL (e.g., to monitor PDCCH) in the symbols of “F”, if UL symbols come earlier than the “F”s due to TA, the UE is not expected to receive/monitor DL on the “F”s after the “U”s due to TA (see following figure). Intel We prefer to define a clear rule for collision with switching time after applying collision handling rules Case 1/2/3/4/5/8. Otherwise, gNB may have to do blind detection on the UL channel/signal, which are same issues as discussed in Case 1/2/3/4/5/8. To avoid defining any new rule, we prefer to prioritize the same DL or UL channel/signal as in corresponding Case 1/2/3/4/5/8 CMCC "it is up to the UE to ensure that the switching time, [NRX-TX Tc] or [NTX-RX Tc], is satisfied" needs to be further clarified. Sharp We agree with Nordic ZTE, Sanechips Y Xiaomi We support to further discuss on the red part of the proposal. From our understanding, in Rel-15/16 gNB scheduling should avoid the case of no enough Tx/Rx switching time between non-full duplex UE UL/DL operations. However, for Redcap HD-FDD UE, a clear rule to resolve the collision may be preferred to avoid putting too many restrictions on gNB scheduling. DOCOMO Regarding the updated part, we are open to further discuss whether it is up to UE or to define a clear rule. Nokia, NSB We also support further discussion on the red text. In our view it would be better to define clear UE behavior. LG N We also prefer to define a clear rule to resolve the collision to avoid putting restrictions on gNB scheduling. For the newly added red part, how a UE ensure that the switching time is satisfied is not clearly for us. To repeat our previous comment, we are not comfortable with removing the last FFS from the original working assumption. 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. Ericsson Y We agree with the intention of the FL to further discuss the 3rd sub-bullet. We are open to discuss clear UE behaviour, e.g., on how to puncture DL or UL, or clarify that it is left to UE implementation to ensure the sufficient switching time. As we commented, the main concern we have is that there might be excessive restrictions imposed on network configuration if this is interpreted as an error case. CATT The new red part needs further clarification. If possible, a clear rule would be considered, to make UE behavior clear. Or if determined to leave to UE implementation, it should be guaranteed that the UE is always capable to tackle collision. Samsung The third bullet can be modified to reflect current situations based on the discussion so far, as follows: o If collision with the switching time after applying collision handling rules may still 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 or further specification on UE behavior. Semi-static UL/DL configuration and dynamic SFI 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 Qualcomm Y The configuration of semi-static slot format is up to NW. The benefits include power saving and complexity reduction (in handling direction collisions, RO validation, PUSCH occasion validation, and etc.) for RedCap UE. This is consistent with the WI objective to minimize the spec impacts, since most of the NR TDD procedures can be re-used with less controversy and standardization efforts. LG N From our perspective, the drawbacks summarized by the FL feels more important. Even for LTE, the HD-FDD is supported in FDD bands without the restrictions on the scheduling flexibility. Power saving study does not fully justify the introduction of the semi-static slot format from our perspective. So, we prefer to draw a conclusion in this meeting or the next without studying power saving. OPPO N The benefit of that configuration is not justified. We did not see the strong need for HD-FDD UE need a longer gap that what TDD UE had. On the other side, introducing that configuration of UL/DL and even SFI would be overly design for HD-FDD and deviated from the purpose of HD-FDD. We think if there is not common understanding, RAN1 should not conclude in the topic. China Telecom Y We are open to have further discussion on this topic. ZTE, Sanechips N As we commented before, 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. DOCOMO N We can study further if sufficient benefits are shown by proponent, but we are not convinced yet. Rather, there are concerns on limiting the scheduling flexibility and complicated scheduling under the coexistence with FD-FDD UEs CATT N In our view there is no strong benefit foreseen. For power saving, RAN2-led features such as eDRX enhancement and RRM relaxation are more promising. Samsung N In general, we don’t object further study. But, it seems all companies including us are already aware of pros. and cons. from the new scheme, very well. In this sense, we’d like to conclude this issue in this meeting. Intel Y We support FL proposal The following RAN1 conclusion was made in an online (GTW) session on Tuesday 25th May: Conclusion: No consensus of specification support of semi-static UL/DL pattern to HD-FDD RedCap UEs in Rel-17. 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. [FL3] Medium Priority Proposal 4-2: Companies are welcome to provide views on whether dynamic SFI monitoring can be optionally supported by HD-FDD RedCap UEs and whether it can be used to solve the conflict between semi-static UL and DL? Company Y/N Comments vivo SFI can be optionally supported by HD-FDD Redcap UEs, but we do not expect additional behavior specified for SFI to address the conflict between semi-static UL and DL. Qualcomm Y It can be optionally supported by RedCap UE. If SFI is supported by RedCap UE, the SFI related collision handling procedures described for NR TDD in Clause 11.1 of TS 38.213 can be re-used/re-considered with minimal spec impacts. OPPO N We see no motivation as we comment in the previous topic. NordicSemi Y But work on this should start only when we are done with the case without “SFI in DCI 2_0 configured” Intel Y When a gNB relies on dynamic SFI to prioritize DL or UL channel/signal for FD-FDD UE, it is not reasonable to assume the same gNB has to take care DL/UL prioritization without help of dynamic SFI for HD-FDD UE. DOCOMO We are fine with optional support of SFI for RedCap UEs to handle the conflict with no/minimal spec impact Nokia, NSB N Ericsson N We do not see the need for HD-FDD RedCap UE to receive SFI. It would just increase HD-FDD RedCap UE complexity unnecessarily. Different collision cases are already being discussed and clear rules are being defined. CATT N Can be discussed for FD-FDD RedCap UE, but we do not think a HD-FDD UE needs this, which is not friendly to PDCCH monitoring nor complexity. Samsung Y As commented, 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. FL5 There are similar views as the semi-static TDD-like UL/DL configuration. Therefore, the following conclusion can be considered. Medium Priority Proposed Conclusion 4-2: No consensus of supporting dynamic SFI to HD-FDD RedCap UEs in Rel-17 LG Y 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