3GPP TSG-RAN WG1 Meeting #104bis-e Tdoc R1-21xxxxx e-Meeting, 12th – 20th April, 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 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] – [29] and captures the following email discussion for the RedCap WI [29]. [104b-e-NR-RedCap-03] Email discussion on aspects related to duplex operation – Chao (Qualcomm) 1st check point: 4/15 2nd check point: 4/19 3rd check point: 4/20 The issues in this document are tagged and color coded like this: High Priority Medium Priority The previous rounds of this email discussion were documented in FL summaries in R1-2103796 and R1-2103884. The latest versions of the FL proposals and questions are tagged ‘FL4’ HD-FDD switching time RAN1#104e made the following agreements related to switching time: 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 On the switching time, two contributions [8, 22] propose to confirm the working assumption on the HD-FDD switching time and one contribution [21] indicates the working assumption can be automatically confirmed upon positive feedback from RAN4. One contribution [18] observes that a relaxed switching time (e.g. 65 usec) is beneficial for UE power saving. Also, it is discussed that the actual switching time required by HD-FDD should take into account both RF retuning gap and RTT required by the timing advance procedure. One contribution [10] instead highlight that the description of UE behaviour in clause 4.3.2 in TS 38.211 is from a UE perspective and thus the timing of the UL symbols has included the timing advance. In [4, 27] it is suggested that gNB scheduler is responsible for creating sufficient gap to cover TA and transition time. High Priority Question 2-1: Should RTT required by the timing advance procedure be accounted in the HD-FDD operation of RedCap UE? What, if any, other potential RAN1 specification impacts are needed to address the possible TA misalignment between gNB and UE? Company Y/N Comments Ericsson Y, and we do not see any new aspects needed to be addressed The RTT and timing advance need to be accounted for in the HD-FDD operation of RedCap UE, and they have been accounted for in TS 38.211 (subclause 4.3) for UE not capable of full-duplex communication and not supporting simultaneous transmission and reception. We do not see any new aspects needed to be addressed. Relaxed switching time (e.g. 65 usec) for UE power saving is a separate aspect. The issue is whether the working assumption needs to be dropped due to UE power saving consideration. Nokia, NSB We agree with Ericsson that they have already been accounted for and no new aspect needs to be addressed. vivo Regarding RTT and TA, we agree with Ericsson and Nokia that they have been accounted by the current specification already. Regarding more relaxed switching time, we think it should be discussed in RAN4 first. Qualcomm Y In the FDD bands supporting HD-FDD operation, the actual switching time required by HD-FDD should take into account both RF retuning gap and the RTT required by timing advance procedure. China Telecom Y In our understanding, RTT required by TA procedure should be considered in HD-FDD operation of RedCap UE. Potential RAN1 specification impacts are FFS and need further study. DOCOMO Y We agree with Ericsson and Nokia that RTT and TA have already been accounted for in current specification. Apple The switching gap for HD-FDD should account for the RTT, the RF retuning time and TA value, which is the same as existing TDD operation. FUTUREWEI Y As with any duplexing, RTT is accounted for in any uplink transmission. With HD-FDD, the uplink transmission behavior is similar to TDD operation. Samsung Y RTT required by the timing advance procedure has been taken into account in the TS38.211for non full-duplex case. Similarly, it can be used for HD-FDD of RedCap UE as well. We don’t see further specification impacts. Spreadtrum We also agree with Ericsson, no other RAN1 specification impacts are needed. Sharp Y TA should be considered for HD-FDD operation of RedCap UE and spec impact need future study CATT Y We also think the RTT and TA have already been accounted for in the HD-FDD operation. Xiaomi Y We agree that the timing advance should be taken into account in HD-FDD UE operation. CMCC Y We agree with Ericsson that RTT and TA have been accounted by the current specification. ZTE Y Legacy NR UE not capable of full-duplex communication has already considered RTT issue and RTT has been accounted for in subclause 4.3 of TS 38.3211 We do not see any new aspects needed to be addressed. Switching time for legacy NR UEs can be reused for HD-FDD RedCap UEs NordicSemi Y Our understanding is that gNB takes care TA and switching time in scheduling. And this is already specified for half-duplex UE. Huawei Y and no spec impact foreseen Intel It is not clear for the exact meaning of ‘accounted’ here. Anyway, the following two factors impacts DL reception and UL transmission jointly. 1) timing advance which at least compensates the RTT; 2) tx-rx or rx-tx switching time. Timing advance is a floating value which changes with UE movement or changes of surrounding environment and is inherently factored in when defining UL symbols. On the other hand, switching time is UE capability for which a requirement should be defined. We agree with Ericsson that the current definition in 38.211 already incorporates TA as it refers to UL symbols from the UE’s perspective. Based on above explanation, we prefer to confirm the working assumption on the HD-FDD switching time. OPPO It has already taken that into account. The gNB scheduler should be aware of that to avoid any conflict in UE side. FL3 Based on the received response, the following conclusion can be considered. High Priority Proposal 2-1: Conclusion: It is RAN1 understanding that the current description of UE behaviour in clause 4.3.2 in TS 38.211 already incorporates TA as it refers to UL symbols from the UE’s perspective Enhancement for potential collision handling due to TA misalignment is not considered for HD-FDD RedCap UEs Company Y/N Comments OPPO Y vivo Y Nokia, NSB Y Ericsson Y NordicSemi Y FUTUREWEI3 Y DOCOMO Y Huawei The proposal is to discuss legacy behavior, not RedCap UEs. Although we share the understanding that it is up to network scheduling, there is no need to conclude anything, as the discussion has been raised for eMBB for many times and no conclusion for any of them. Xiaomi Y Samsung Y Qualcomm Agree with the comments of Huawei CATT Y ZTE Y Spreadtrum Y China Telecom Y Apple Y CMCC Y LG Y Intel Y WILUS Y Company Y/N Comments FL4 The intention for this conclusion is to address the issue whether the timing advance is considered in the switching time for legacy NR UE not capable of full-duplex and whether HD-FDD can reuse the same principle. If it is clear to all the companies, probably we don’t need have such conclusion. vivo Maybe we could try to agree the sub-bullet as conclusion? Enhancement for potential collision handling due to TA misalignment is not considered for HD-FDD RedCap UEs OPPO Y No conclusion is also OK. ZTE Y Ericsson We support the suggestion from Vivo. LG Y Samsung Y Agree Huawei, HiSilicon Y And can be fine with vivo suggestions as well. DOCOMO We support the suggestion from vivo CMCC We are fine with the suggestion from vivo. Intel Y Open issue: whether to define the guard times in symbol units This issue is discussed in the contributions [3, 4, 5, 6, 8, 10, 11, 12, 13, 18, 21, 22, 23, 28, 29]. 8 contributions [3, 4, 6, 8, 10, 12, 22, 23] prefer not to specify guard time in symbol units 7 contributions [5, 11, 13, 18, 21, 28, 29] propose to use the symbol level switching time instead of the absolute time Contribution [3] observes no clear benefits to define the guard time in symbol units. Contribution [10] mentions that the timing offset between DL and UL frames T_TA has granularity finer than symbol duration and defining the guard time in symbol units is therefore not needed as the end of guard time cannot be guaranteed to align with the symbol boundary. The justifications for the symbol level switching time are [11]: Support of the guard period in symbol units is beneficial for lower latency [18]: Guard symbols can be configured for DL to UL switching to accommodate TA and RF retuning gap. [21]: Definition the guard time in symbol units simplifies the descriptions on the collision handling cases for HD-FDD type A in the spec [28, 29]: The switching time of 13 usec can be covered by 1 OFDM symbol duration (including extended CP) for 15, 30, 60 kHz SCSs in FR1 High Priority Proposal 2-2: For HD-FDD switching time, a guard period of N symbols can be configured for UE Rx-to-Tx switching. FFS the value of N. High Priority Question 2-2: Can Proposal 2-2 be agreed? If not, please explain why? Company Y/N Comments Ericsson N We do not see any benefit. We do not see defining the guard times in symbol units has any latency benefit. First, the transition time (NRx-Tx and NTx-Rx) needs to be rounded up to symbol units. Then, the UE needs to wait additional time to wait for the start of the next symbol period as the symbols between DL and UL frames are not aligned. This would end up causing an extra delay. Nokia, NSB N We also do not see any benefit to define guard times in symbol units. vivo N Current specification can already handle the switching time, there is no need to additionally introduce symbol level guard time. Qualcomm Y It is up to network to configure different N value for different frequency bands and/or SCS, where N can be 0,1 or 2. For all NR TDD slot formats supported by a non-RedCap UE (Table 11.1.1-1 of TS 38.213), at least one flexible symbol is configured if there is a switching from DL to UL. The flexible symbol(s) serve as guard symbols of non-RedCap UEs incapable of full-duplex operation, which can accommodate the RTT for timing advance as well as the RF retuning gap. Compared with non-RedCap UE, the latency and throughput requirements of RedCap UE are more relaxed, but coverage (lower frequency bands) and power saving become more crucial. For a RedCap UE deployed in larger cells at FDD bands, longer RTT and more relaxed TX/RX switching gap should be considered and accommodated by a configurable number of guard symbols. China Telecom N We think there is no need and benefit to define new guard period of N symbols. DOCOMO N We agree with Ericsson, Nokia, and vivo that there is no need to introduce guard time in symbol units in addition to the switching time. Apple We do not see the dependency between switching gap duration and symbol or absolute time granularity. If long duration is justified, it can be achieved even with absolute timing as it in current specification. On the other hand, we are open to discuss whether there is benefit to change it to symbol granularity. FUTUREWEI N The procedures for TDD should be considered as a baseline for the timing and reused as much as possible. Samsung N The benefit is unclear. Don’t see a need to introduce the guard period in symbol level. Spreadtrum Y We slightly prefer Yes. A guard period of N symbols simplifies the spec descriptions. Regarding the issue that “the end of guard time cannot be guaranteed to align with the symbol boundary”, we think this problem is still exist even the guard time is based on absolute time. Sharp N We agree with Ericsson, the UE can find the symbols border for transmission and satifsy the switching requirement with a guard in any unit CATT N We do not see the benefit to define switching gap in a symbol unit. We prefer to reuse current definition to keep specification simple and clear. Xiaomi Y (partially) We agree that defining guard period for Tx/Rx switching can simplify UE behavior. But we think it is only useful if DL/UL slot/symbols are configured to HD-FDD Redcap UE. CMCC N We think absolute time in current specification can already handle the switching time, ZTE N NR system has multiple subcarrier spacings in FR1 and FR2. If the guard time is defined in symbol units, then the guard time should be quantified for each subcarrier spacing. Considering that the transition time (NRx-Tx and NTx-Rx) for legacy NR UEs is defined in unit of Tc, RedCap FD-FDD UEs can reuse the same rule. NordicSemi N No need to change NR principles, behaviour of TDD should be used. Huawei N WILUS Y We think the symbol-level definition of gap period makes the specification and UE behavior simple and the additional delay from round up of guard period is not critical to RedCap UE. Sony While defining the switching time in units of symbol could simplify UE behavior, given that the switching time is currently defined in terms of time, the current specification method for switching time is probably OK. Intel N Due to the impact of TA, the exact gap between DL reception and UL transmission is not integer of symbol. therefore, it is not helpful to define switching time with unit of symbol. Further, it is more accurate to define the switching time with its exact time, i.e. removing quantization to symbol(s). LG Y We support the proposal. As captured in the summary above, we see some benefit of defining the guard time in symbol units as it simplifies the descriptions on the collision handling cases for HD-FDD type A in the spec. However, if there is a clear majority view, then we can follow the majority view as we can’t say the difference is big either way. OPPO N We can consider similar method by procedure of Rel15/16. If we define that explicitly, a frame structure indication would also need to be indicted to HD-FDD, which is overspecifying. IDCC N We do not see any benefit of quantizing the guard time. FL3 Five companies (Qualcomm, Spreadtrum, Xiaomi, WILUS, LG) think there are some benefits of defining the guard time in symbol units. Since the exact switching time for HD-FDD UEs is still under discussion in RAN4 and the need for symbol-level guard time may be also dependent on whether or not to support the semi-static TDD-like slot format for HD-FDD RedCap UEs, the FL suggests combing back to this discussion in a later RAN1 meeting Company Y/N Comments OPPO Y Still unclear for the motivation. OK to decide later vivo There are clear majority (16) companies proposed to not define the symbol-level guard time, and considering the WID objective “HD-FDD type A with the minimum specification impact (Note that FD-FDD and TDD are also supported.)”, we suggest to conclude this topic (no support of symbol-level guard time) in this meeting. Nokia, NSB We share the same view as vivo. Ericsson We do not see RAN4 discussion on the exact switching time for HD-FDD UEs and RAN1 discussion on whether or not to support the semi-static TDD-like slot format for HD-FDD RedCap UEs have implication on whether defining guard time in symbol units is needed. The main point is that the DL and UL are not symbol-aligned. Therefore, there is no need for defining guard time in symbol units. NordicSemi Y To be honest I still did not understand the benefits. It would be good to summarize those. For example, QC says that larger switching delay would reduce power consumption, but how this is related to definition of switching delay in number of symbols. We would be supportive of relaxing the switching delay, but we do not support its definition in symbols. FUTUREWEI3 While the exact values for switching time are not available from RAN4, the decision of using Ts and symbol-level guard time is not related to those exact values. We should be able to conclude this topic Huawei Agree with vivo Xiaomi OK to come back Samsung Similar understanding as vivo and Ericsson. Qualcomm Y No consensus at this meeting. Let’s revisit this topic later. CATT Agree with vivo and many companies above. ZTE We share the same view as vivo. Spreadtrum We are fine with the FL’s suggestion. China Telecom We are fine with FL suggestion. Apple Ok to defer the discussions as seems companies have different views on this. CMCC We share the same view as vivo. LG Fine with the FL’s suggestion. Intel Similar understanding as vivo and Ericsson. APT We are fine with FL’s suggestion since whether to support TDD-like configuration has not decided yet. WILUS We are fine with FL’s suggestion. Company Y/N Comments FL4 Regarding “whether RAN1 discussion on whether or not to support the semi-static TDD-like slot format for HD-FDD RedCap UEs will have implication on whether defining guard time in symbol units is needed”, it is the FL understanding that there is such implication. If semi-static TDD-like slot format is configured, then the flexible symbols in a slot can be used for Tx/Rx switching and the minimum guard time that can be configured is one OFDM symbol. Also, some companies propose that the Tx/Rx switching time or guard time should be considered also for some collision handling cases. Since we are still discussing collision handling cases, it is not clear how it should be considered and whether there is any difference for using Ts and symbol-level guard time for collision handling. Based on the above, the FL suggests not rush to an agreement on this issue. We can come back to this discussion in a later RAN1 meeting when the related issues are clear. vivo We are fine to defer the decision, but it would be good to have a common understanding on the real use case of symbol-level guard time. If it is connected with the semi-static TDD-like slot format as commented above, maybe we could make a conclusion like the following The need for defining guard time in symbol units can be further discussed if it is agreed to introduce semi-static TDD-like slot format for HD-FDD UEs. OPPO N After seem some discussion for TDD like slot format. We now think we should conclude that the guard period should not be defined. ZTE Y We are fine with FL’s suggestion. Ericsson Even if Tx/Rx switching time is considered also for some collision handling cases, e.g., Cases 5 and 8, it can be up to the scheduler to take this into account without needing to define the switching time in symbol unit. We support the suggestion from Vivo. LG Y Fine with the FL’s suggestion. Samsung Y OK Huawei, HiSilicon There does not seem to any connection between defining symbol-level GP and configurations of a TDD-like pattern. Suggest to conclude no defining for GP in symbol-level while the other issue is still left open. CMCC Y We are fine with FL’s suggestion. Intel A guard time or gap is anyway existed between DL reception and UL transmission. The potential options include relying on flexible symbols in semi-static TDD configuration, relying on flexible symbols in dynamic slot format indicated by SFI, or up to gNB to generate it assuming neither semi-static configuration nor SFI is available. Since the guard time is generated by reusing flexible symbols which is up to gNB implementation, the above 3 options can be considered for HD-FDD. Open issue: switching position The other issue is whether/how to define the guard time positions. Some contributions [5, 6, 8, 10, 11, 12, 18, 20, 29] have expressed views on the switching position for HD-FDD. [5, 8] supports reusing the LTE definition for Type A HD-FDD, i.e. “not receiving the last part of a downlink subframe immediately preceding an uplink subframe from the same UE” [12, 29] express their views that the switching position for Rx-to-Tx is after the end of the last received downlink symbol and the switching position for Tx-to-Rx is after the end of the last transmitted uplink symobl. [6, 10] indicate that there is no need to explictly specify the DL/UL switching position as the collision handling principles determine whether DL or UL symbols are prioritized in various cases. [11] suggests specifying the switching position based on a defined rule, e.g. the starting symbol based on the BWP with the largest SCS, the smallest SCS or the reference BWP [18] proposes the switching position configuration can be left to NW, in a hybrid way similar to TDD. NW can explicitly configure the switching positions by SI or RRC (e.g. guard symbols in a semi-static slot format). Or, NW does not configure the swithcing positions and UE determines the switching position based on the DCI and semi-static scheduling on DL/UL (SPS, CG, SSB, PRACH, etc.) [20] suggests applying the switching position based on the channel priority, e.g. the switching gap is applied in the channel with the lower priority. If the two channels have the same L1 priority, it is preferable to share the switching portion between the two channels. High Priority Proposal 2-3: For HD-FDD, for the case UL/DL slot pattern (if any) not configured, the switching position is not explicitly specified. It is up to UE to determine the DL/UL switching position based on the prioritized channels/signals. High Priority Question 2-3: Can Proposal 2-3 be agreed? If not, please explain why? Company Y/N Comments Ericsson Y Nokia, NSB N We prefer to have predefined switching position so that any impairment can be properly handled by the gNB. For example, if LTE Type-A switching position is used, the gNB can adjust the MCS accordingly in the last DL subframe before UL. It also provides clear and consistent understanding to the gNB how the transition will be handled. Finally, we prefer to remove “for the case UL/DL slot pattern (if any) not configured” since we do not see clear benefit to operate FD-FDD system this way. vivo There seems to be different interpretations regarding the existing specification, as copied below. Since it says UE is not expected to xxx, our understanding is that UE is not required to handle the case where the scheduled transmission/reception falls into the switching gap, gNB scheduler should avoid such case. So there is no need to specify new UE behavior for determining switching position, we would like to rephrase proposal 2-3 as the following Proposal 2-3(update) For HD-FDD, no additional UE behavior for switching position determination compared to existing specification is specified. TS 38.211 sub-clause 4.3.2 […] 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. Table 4.3.2-3: Transition time N_"Rx-Tx" and N_"Tx-Rx" Transition time FR1 FR2 N_"Tx-Rx" 25600 13792 N_"Rx-Tx" 25600 13792 […] Qualcomm Partially Y gNB should avoid the ambiguity/collision in DL/UL switching that cannot be resolved by the priority rules specified for R17 RedCap UE DOCOMO Y We are also fine with the update from vivo Apple We shared views of Vivo and Qualcomm. On high-level, UE does not expect to transmit/receive during the switching gap. The simultaneous Tx/Rx within switching gap is feasible only where collision handling rules were defined for it. Samsung Y But we'd like to delete “for the case UL/DL slot pattern (if any) not configured”. This is not clear on the pattern for RRC configured (which is not supported for FDD) or the pattern indicated by SFI. Alternatively, we'd like to further confirm that SFI based indication of slot format can be reused, same as current FDD, if configured. CATT We have similar understanding with vivo. Xiaomi Y CMCC Y ZTE N We think “switching position” should be explicitly specified. If not specified, UE and gNB may have different understanding of switching position and may cause incorrect DL reception or UL transmission. Regarding “It is up to UE to determine the DL/UL switching position based on the prioritized channels/signals.”, we want to clarify the meaning. Which one is the correct understanding: Alt 1: It is up to UE’s implementation to determine the priority of channels and then determine the switching position Alt 2: The priority of channels is defined in the specification. The UE determine the switching position according to the specified priority. NordicSemi Y Vivo proposal is a good proposal. Huawei Y WILUS Partially Y We are fine with this proposal, except “for the case UL/DL slot pattern (if any) not configured”. Slot pattern configurations (including semi-static UL/DL configuration and applicability of dynamic SFI) should be separately discussed.. Sony Y When there are known prioritisation rules between signals and channels, the gNB will know where the switching position is applied and can hence choose an appropriate MCS in the DL and receive in the UL without blind decoding. The text from 38.211 section 4.3.2 seems to state how long the switching gap will be, but not necessarily where the switching gap is. E.g. for table 4.3.2-3, which is the last transmitted UL symbol? We think that the understanding of which symbol is the last transmitted UL symbol should depend on the priority of channels / signals. Intel Since the switching time is rather short, for the case that semi-static UL/DL slot pattern or dynamic SFI are both absent, default duplex direction and thus the switching times can be up to UE implementation. We expect gNB to provide sufficient time for any DL-to-UL and UL-to-DL switches following existing definition of switching time in 38.211. For those cases, wherein such switching time may not be provisioned, the handling can follow the corresponding overlap cases for the respective DL and UL channels (cf. response to Question 3-7). LG Y with modification We have the same understanding as Qualcomm. We also think we should remove the “for the case UL/DL slot pattern (if any) not configured,” as it is not needed in this discussion. OPPO We understand the intention. Our understanding is: The UL/DL and DL/UL switching time is on top of channel prioritization/cancellation. In case that cancellation results in switching between DL/UL, the switching time interval should be applied. That can be support in the existing spec. with little change. Vivo’s update could be For HD-FDD, no additional UE behavior for switching position determination compared to existing specification is specified compared to non-full-duplex UE. IDCC Y FL3 Based on the received responses, the following proposal can be considered. For clarification, when following the current description of UE behaviour in clause 4.3.2, in most cases gNB should provide sufficient gap between the scheduled/configured transmission/reception for Tx/Rx switching and then the switching can be up to UE implementation. For some cases when there is a collision, the handling can follow the corresponding case and the switching position can thus be determined accordingly. Therefore, it seems no need to specify additional rule for HD-FDD UEs to determine the switching position at least for the concerned collision and non-collison cases. High Priority Proposal 2-3: For HD-FDD, no additional UE behavior for switching position determination is specified as compared to the existing specification. Company Y/N Comments OPPO Y Agree with FL’s proposal. Our understanding is the collision happened, UE should firstly follow the UL/DL determination rules, mostly reused from TDD non-CA. Then, it should also satisfy the not expect to transmiting/receiving in clause 4.3.2. vivo Y Nokia, NSB N We need further discussion on this point. According to the discussion above on 38.211 4.3.2, when UE is “not expected to”, it means this is an error case and it should be up to the gNB to avoid these error cases. We feel this is quite restrictive. Instead we prefer the LTE Type-A definition - For type A half-duplex FDD operation, a guard period is created by the UE by not receiving the last part of a downlink subframe immediately preceding an uplink subframe from the same UE. The behavior is clear and there is no restriction or special handling that must be done. Ericsson Y NordicSemi Y A TDD UE may monitor PDCCH at the beginning of slot and transmit PUCCH at its end. This is a standard behavior, so gNB is able to do this in TDD, it can do it in FDD for HD-FDD UE. In other words, gNB may reuse TDD scheduler for HD UEs in FDD. DOCOMO Y Huawei Y Xiaomi Y Samsung Y in general Since we are still discussing on collision handling cases, we think it is better to be a working assumption other than agreement to allow further check. Or, we only agree for Case 2 and 4, FFS for other cases. Qualcomm Y We can live with this proposal. CATT Y ZTE Y China Telecom Y Apple Y TCL Y CMCC Y LG Y in general We agree to the FL’s opinion “for some cases when there is a collision, the handling can follow the corresponding case and the switching position can thus be determined accordingly.” We are open to further discuss whether and in which case the general rule as suggested by Nokia has the benefit. Intel Y APT N We think this proposal is related to discussion in proposal 2-2, TDD-like configuration and collision case 9, for instance, potential UE behavior compared to existing specification might need some changes if switching time can be configured in symbol unit. In general, it is too early to decide no new behavior is introduced. WILUS Y The following RAN1 agreements were made in an online (GTW) session on Friday 16th April: Working assumption: For HD-FDD, no additional UE behavior for switching position determination is specified as compared to the existing specification. Collision Handling RAN1#104e made the following agreements related to collision handling for HD-FDD: Agreements: For HD-FDD, for cases (if any) where collision handling needs to be specified, then the existing collision handling principles in Rel-15/16 NR for operation on a single carrier /single cell in unpaired spectrum are used as a starting point if deemed applicable. Agreements: For HD-FDD operation for RedCap UEs, collisions may be addressed or alleviated with proper scheduling. The following cases of potential collisions can be further studied to see if any change to the current specs is necessary: Case 1: Dynamically scheduled DL reception vs. semi-statically configured UL transmission e.g., dynamic PDSCH or CSI-RS collides with configured SRS, PUCCH, or CG PUSCH Case 2: Semi-statically configured DL reception vs. dynamically scheduled UL transmission e.g., PDCCH or SPS PDSCH collides with dynamic PUSCH or PUCCH Case 3: Semi-statically configured DL reception vs. semi-statically configured UL transmission Case 4: Dynamically scheduled DL reception vs. dynamic scheduled UL transmission Case 5: Configured SSB vs. dynamically scheduled or configured UL transmission e.g., PUSCH, PUCCH, PRACH, SRS Case 8: Dynamic or semi-static DL vs. valid RO Case 9: Collision due to direction switching Many contributions [3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29] express views on how UE should handle the seven potential collision cases identified in the last RAN1 meeting. Many contributions noted that although in general collision may be avoided by the scheduler, DL/UL collision may not be avoidable in some scenarios and would be handled by UE. Contribution [11] suggests a general method to handle the collision. For example, three options are proposed including scheduling restriction, defining a prioritization rule, and providing a TDD-like configuration. Contribution [20] proposes to define a set of priority rules between different types of DL and UL channels and the channel collision can be solved through comparing different L1 priorities of two channels. Case 1: Dynamically scheduled DL reception vs. semi-statically configured UL transmission Many contributions [5, 6, 7, 8, 9, 10, 12, 14, 15, 16, 17, 18, 19, 21, 22, 24, 25, 26, 28, 29] express views that the dynamic scheduled DL should be prioritized over the semi-statically configured UL transmission. Contributions [5, 6, 7, 10, 14, 16, 17, 18, 19, 26, 28, 29] propose to reuse the existing rule of Rel-15/16 for Case 1, i.e. configured UL is (partially) cancelled if timeline allows. In the contribution [14] it was proposed to further study whether the timeline can be extended by including the Tx/Rx switching time. Contributions [16, 21] indicate that it should be treated as error case if the first symbol of UL transmission occurs within Tproc,2 relative to a last symbol of the PDCCH. Contribution [24] proposes to further study the case of DL scheduling collision UL CG resources. Contribution [3] highlights that the dynamic scheduling is flexible to avoid collision with semi-static UL transmission. High Priority Proposal 3-1: 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 High Priority Question 3-1: Can Proposal 3-1 be agreed? If not, please explain why? Company Y/N Comments Ericsson Y We can accept the proposal, although we don’t think the FFS is needed. The gNB scheduler can take care of the RX/TX switching time when it schedules the DL. Nokia, NSB Y We are fine with the main proposal but we do not think the FFS is needed. vivo Y if the FFS is removed Agree with Ericsson and Nokia that the FFS is not needed. Qualcomm Y We think the FFS needs to be kept. China Telecom Y We are fine to support FL proposal. Reuse the existing collision handling principles in Rel-15/16 NR as a starting point. And we suggest to delete FFS. DOCOMO Y Apple Y We think FFS should be kept because it may impact on possibility that UE performs switching from UL to DL. TCL Y We are fine with the proposal. Samsung Y OK with the proposal. In our view, on top of the current time line, the RX/TX switching time can be further considered to determine whether or not the semi-statically configured UL is (partially) cancelled. Spreadtrum Y We also think the FFS is unnecessary. Sharp Y CATT Y We are fine with the proposal. Regarding to the FFS part, we see some different views. It seems good to keep it for further discussion. To us, it is unclear whether the DL-UL switching time of the switcher is already considered in current spec, and thus the timeline may or may not be extended. Xiaomi Y We also do not see the need of FFS. CMCC Y According to TS38.214 section 6.4, BWP switching time if triggered and uplink switching gap duration for uplink Tx switch are considered when determining Tproc,2. So it needs to be discussed whether to include RX/TX switching time into Tproc,2. If Tproc,2 is updated to consider the RX/TX switching time, whether to cancel the higher layer configured UL transmission such as SRS, PUCCH, or CG PUSCH will depends on the updated Tproc,2 for HD-FDD RedCap devices. ZTE Y NordicSemi Y FFS is not needed Huawei Y without FFS WILUS Y We think the FFS point is not needed. Sony Y We are not sure the FFS is needed, but are OK to keep it for the time being. Intel Y We support the FL proposal. LG Y We think the FFS part should be kept. Whether the switching time is already considered or not is an important part of supporting HD-FDD for RedCap UEs. OPPO Y We are OK for the proposal. The principle is use that clauses defined for non-full-duplex, mostly TDD. The is following same principle as switching time questions. IDCC Y FL2 9 companies (Ericsson, vivo, Nokia, China Telecomm, Spreadtrum, Xiamo, NordicSemi, Huawei, WILUS) view that FFS part is not needed 5 companies (Qualcomm, Apple, Samsung, CMCC, LG) think the FFS should be kept, and 2 companies (CATT, Sony) are not sure whether the FFS is needed but are OK to keep it. Based on the above, the FL suggests keeping FFS part in the proposal. Based on the proposals in FL summary #2 in R1-2103884, the following RAN1 agreements were made in an online (GTW) session on Wednesday 14th April: 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 Case 2: Semi-statically configured DL reception vs. dynamically scheduled UL transmission Many contributions [5, 6, 7, 8, 10, 12, 14, 15, 16, 17, 18, 19, 21, 22, 25, 26, 28, 29] express views that the dynamic scheduled UL should be prioritized over the semi-statically configured DL reception. The existing collision handling principles in Rel-15/16 NR for operation on a single carrier/single cell in unpaired spectrum can be reused for case 2. Contribution [3, 9, 24] mentioned that the collision between semi-statically configured DL reception and dynamically configured UL transmission is avoidable via proper gNB scheduler implementation. Moreover, it was clarified in the contributions [6, 16] that the semi-statically configured DL reception may include also a CSI-RS and a DL PRS; the dynamically scheduled UL transmission may include also SRS or PRACH preamble transmission triggered by PDCCH order. Based on above, the following proposal can be considered. High Priority Proposal 3-2: 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, SPS PDSCH, CSI-RS or PRS The dynamically scheduled UL transmission may include PUSCH, PUCCH, SRS or PRACH triggered by PDCCH order High Priority Question 3-2: Can Proposal 3-2 be agreed? If not, please explain why? Company Y/N Comments Ericsson Y Nokia, NSB Y vivo Y Qualcomm Y China Telecom Y DOCOMO Y Apple Y TCL Y Samsung Y Spreadtrum Y Sharp Y CATT Y Xiaomi Y CMCC Y ZTE Y NordicSemi Y Huawei Y WILUS Y Sony N An HD-FDD UE cannot monitor for an uplink cancellation indicator (transmitted on PDCCH) while transmitting PUSCH according to current collision handling principles. To allow HD-FDD Redcap UEs to be scheduled in the same frequency range as URLLC devices (which we think would happen in an industrial setting), the UE should monitor PDCCH in the DL for uplink cancellation indication while transmitting dynamically scheduled PUSCH. This allows the network to prioritise a URLLC UL transmission in preference to a lower priority UL transmissions from a Redcap device. The HD-FDD Redcap UE would need to switch to monitoring the DL for the symbols during which a PDCCH carrying uplink cancellation indication could potentially be transmitted. Intel Y We support the FL proposal. Just a clarification, ‘CSI-RS’ in sub-bullet includes all kinds of channel having a structure of CSI-RS, including TRS LG Y with modification We think the same FFS from Proposal 3-1 should be added here. OPPO Y IDCC Y FL2 Based on the received response, the following proposal can be considered. The FFS part is to address Sony’s concern on monitoring of UL cancellation indication. The FFS from Proposal 3-1 is not added since the existing collision handling principles of Rel-15/16 do not consider the timeline for case 2. High Priority Proposal 3-2b: 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 UL CI), SPS PDSCH, CSI-RS or PRS. FFS on PDCCH carrying UL CI. The dynamically scheduled UL transmission may include PUSCH, PUCCH, SRS or PRACH triggered by PDCCH order Based on the proposals in FL summary #2 in R1-2103884, the following RAN1 agreements were made in an online (GTW) session on Wednesday 14th April: 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 Case 3: Semi-statically configured DL reception vs. semi-statically configured UL transmission Many contributions [5, 7, 8, 9, 10, 12, 14, 15, 16, 17, 18, 19, 22, 24, 25, 26] express views that the overlapped semi-static DL reception and semi-static UL transmission can be avoided by gNB scheduler, however, contributions [3, 6] mention it may not be avoidable in some scenarios. In the contribution [6], it was discussed that the semi-static configuration should be further separated as semi-static configuration with cell-specific higher layer parameters and semi-static configuration with dedicated parameters. Since FD-FDD and HD-FDD UEs may co-exist in the same cell, there is a big impact for FD-FDD UE when relying on NW’s configuration to avoid the collision between semi-static DL reception and UL transmission configured by cell-specific higher layer parameters. In the contribution [21], it was proposed to further discuss and down select between the following two alternatives Alt.1 (LTE approach): No DL reception during the guard period (=Tsw) before the start of the first UL transmission Alt.2 (NR approach): No UL transmission during the guard period (=Tsw) after the end of the last DL reception Similarly, contribution [29] proposed that a UE behavior should be defined in this case for which channel/signal should take precedence over the other channel/signal. High Priority Question 3-3: For Case 3, is it sufficient to assume the collision is avoidable via proper gNB implementation and UE does not expect to be configured with overlapped semi-static DL reception and semi-static UL transmission occasions? What, if any, needs to be specified? Company Y/N Comments Ericsson Y No need to specify anything additionally. Nokia, NSB Y vivo N There are four potential sub-cases under case 3 Case 3-1: cell-specifically configured DL reception vs. cell-specifically configured UL transmission Case 3-2: cell-specifically configured DL reception vs. UE-dedicated configured UL transmission Case 3-3: UE-specifically configured DL reception vs. cell-specifically configured UL transmission Case 3-4: UE-specifically configured DL reception vs. UE-specifically configured UL transmission For case 3-2/3-3/3-4, it should be fine to rely on gNB implementation to avoid the collision between the DL reception and UL transmission as at least one UE specific configured DL or UL is involved. Case 3-1 is a bit different. Due to the existence of both FD-FDD and HD-FDD UEs, if we again rely on the gNB configuration to avoid the collision between DL and UL signals, it would cause degraded performance for FD-FDD UEs. For example, gNB has to configure the RACH occasions such that they do not overlap with the broadcast DL channels, e.g. SSB, CORESET#0, Paging occasions, SI occasions, etc, which would mean restricted configuration flexibility for RACH occasions resulting potentially increased initial access latency. Therefore, we would like to define the collision handling rule for cell-specific DL and cell-specific UL so that the performance of FD-FDD UEs including legacy UEs are not impacted. Qualcomm Partially Y Case 3-1 in Vivo’s comments can be further discussed China Telecom Y DOCOMO Partially Y We are fine to further discuss Case 3-1 in vivo’s comments Apple Partially Y Case 3-1 raised by Vivo can be FFS. TCL Partially Y Further discuss Case 3-1 in vivo’s comments Samsung N If SFI is configured, the overlap is handled by SFI. If SFI is not configured, we'd like to have some further discussion, including the cases raised by vivo. Spreadtrum Y Sharp Partially Y Case 3-1 in Vivo’s comments should be considered including static DL vs PO CATT Y, partially It is reasonable to further study the difference of cell-specific and UE-dedicated configuration as raised by vivo. BTW, we think Case 3-2 and Case 3-3 may also be worth to consider. Xiaomi Y We are also fine if case 3-1 is FFS. CMCC Partially Y Case 3-1 in Vivo’s comments can be further discussed ZTE Y It is up to gNB implementation. No need to specify anything NordicSemi Y Regarding cell-specific RACH and SSB, they are currently prioritized for TDD UEs, so if we keep the same behavior for HD-FDD UEs, then there is no issue with random access? And in our opinion, HD-FDD UEs should have their own ROs anyway preferably which would be cell specific. Huawei N Would be much efforts for gNB to support HD-FDD if relying on solely gNB scheduling. WILUS Partially Y At least for Case 3-1 in vivo’s comments, further discussion is needed. Sony N The case from vivo should be considered. The issue of uplink cancellation indication (case 2) also exists for case 3. If Redcap HD-FDD UEs are to coexist with URLLC UEs, it should be possible to cancel semi-static UL transmissions. Intel Y We support the FL proposal. LG N Those cases may be avoidable by gNB implementation. But restrictions are not avoidable in some cases as pointed out by vivo. There may be the cases where providing simple collision handling rules without restriction on the gNB scheduling is a better choice. We think it is early to make a conclusion on this as it is unclear from that aspect. OPPO Partially Y OK for FFS case 3-1 by vivo. IDCC Y FL3 Based on the received response, the following proposal can be considered. High Priority Proposal 3-3: 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: Collision handling if SFI is configured, including whether or not it is supported by HD-FDD RedCap UEs Company Y/N Comments OPPO Y, partially. “FFS: Collision handling if SFI is configured” sounds not need to be discussed. As mentioned in GTW, this would be a UE capability independent. We should avoid to exam if UE should support single capability. We suggest remove this FFS. For other proposals, we can say it is reusing the existing behavior, may be as a main bullet. vivo Question about the last FFS Regarding the last FFS, Case 3 is related to collision handling between semi-static DL and semi-static UL, so we are not sure why SFI is involved here. Nokia, NSB Y Ericsson Y We are fine with this FL3 proposal. Regarding the 1st FFS bullet, our view is that the collision between cell-specifically configured DL reception vs. cell-specifically configured UL transmission can be included in Case 8. NordicSemi Y, partially We now understand the motivation from Vivo, fine to discuss further. On the other hand, no need to discuss whether UE can support optional feature of SFI, unless someone wants to make it mandatory/baseline for RedCap UE type. DOCOMO Y Regarding SFI, if it is configured, semi-static DL reception or UL transmission in semi-static flexible symbols can be cancelled by SFI indication in current spec, which can handle the DL/UL collision in this case. We think that’s why the last FFS was put, and we are fine with the proposal. Huawei Y Xiaomi Y Samsung N In general, we are fine. For the last FFS point, SFI is supported for FDD in NR, which can be used to cancel Semi-configured transmission and reception. So, if UE is configured by RRC to transmit and receive on the same symbol, UE can rely on SFI to cancel one of it. We don’t think there is a need to further study whether SFI is supported for HD-FDD or not. We think SFI can be supported optionally for RedCap UEs (similar to non-RedCap UEs in Rel-16). When SFI is configured, SFI can be used to handle the potentially collision of semi-static UL and DL. Therefore, we suggest the following change: For Case 3, semi-statically configured DL reception vs. semi-statically configured UL transmission If SFI is not configured, 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: Collision handling if SFI is configured, including whether or not it is supported by HD-FDD RedCap UEs If SFI is configured, SFI can be used to handle the collision of semi-statically configured UL and DL, e.g., to cancel one of transmission or reception semi-statically configured by higher layer parameters. QC Y partially Agree with the comments of Vivo. SFI is dynamic, not semi-static. FFS bullet for SFI can be removed. Vivo2 To respond Samsung, we understand that SFI can be used to cancel semi-static DL or UL but if so this is not case 3 anymore as the collision is resolved by SFI. CATT Y, partially The last FFS should be removed. ZTE Y Spreadtrum Y, partially We share the similar views with OPPO and vivo, we don’t think the second FFS is necessary. In our understanding, what we need to do next is analysis the detailed collision cases when a HD-FDD UE receives both cell-specifically configured DL reception and cell-specifically configured UL transmission. If the detailed cases can be identified, then we can further study the possible solutions, like prioritization strategies, SFI or others. If we put the second FFS here, it seems like that we should focus on SFI-based solutions. Obviously, it’s not reasonable. China Telecom Y, partially We have the same view with OPPO. And suggest to delete the last FFS. Apple Y partially Agree to remove FFS of SFI and separately discuss it. TCL Y CMCC Y, partially The last FFS should be removed. LG Y partially We have the same understanding the dynamic SFI belong to the dynamic which has already been covered by other cases. We are okay without the second FFS. Intel Y We think it is beneficial to keep the last FFS at this stage. As defined in FDD in NR, SFI can be used to cancel Semi-configured transmission and reception. This feature should be optionally supported for HD-FDD UE too. WILUS Y, partially Support the proposal without the last FFS. As in vivo’s comment, case 3 is for a collision of semi-static DL and UL. Dynamic SFI can be separately discussed. The following RAN1 agreements were made in an online (GTW) session on Friday 16th April: 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 Case 4: Dynamically scheduled DL reception vs. dynamic scheduled UL transmission Many contributions [3, 5, 6, 7, 8, 10, 12, 14, 15, 16, 17, 18, 19, 22, 24, 25, 26, 27, 28, 29] express views that gNB should be able to handle the case of dynamic scheduled DL reception collides with dynamic scheduled UL transmission, and UE will not expect the collision. Contribution [9] mentioned that when dynamically scheduled UL/DL transmission collide, the earlier scheduled transmission should take effect and the latter should be dropped. In the contribution [21], it was proposed to further discuss and down select between the following two alternatives Alt.1 (LTE approach): No DL reception during the guard period (=Tsw) before the start of the first UL transmission Alt.2 (NR approach): No UL transmission during the guard period (=Tsw) after the end of the last DL reception High Priority Question 3-4: For Case 4, is it sufficient to assume the collision is avoidable via proper gNB implementation and UE does not expect to be dynamically scheduled with overlapped DL reception and UL transmission occasions? What, if any, needs to be specified? Company Y/N Comments Ericsson Y No need to specify anything additionally. Nokia, NSB Y vivo Y Qualcomm Y China Telecom Y Apple Y TCL Y Samsung Y CATT Y Xiaomi Y CMCC Y ZTE Y It is up to gNB implementation. No need to specify anything NordicSemi Y It is already specified for TDD. Huawei Y WILUS Y Sony N If two channels have the same priority, the UE should transmit / receive the channel that was scheduled latest. This allows the gNB to update scheduling decisions (e.g. if the gNB needs to send high priority DL traffic after it had previously scheduled an UL transmission). Intel Y We support the FL proposal. LG Y OPPO Y IDCC Y High Priority Proposal 3-4: For Case 4: dynamically scheduled DL reception vs. dynamic scheduled UL transmission It is considered as error case if a dynamically scheduled DL reception overlaps with a dynamically scheduled UL transmission Modified High Priority Question 3-4: Can Proposal 3-4 be agreed? If not, please explain why? Company Y/N Comments Ericsson Y vivo Y Qualcomm Y China Telecom Y DOCOMO Y Apple Y TCL Y Samsung Y Spreadtrum Y Sharp Y CATT Y Xiaomi Y CMCC Y ZTE Y NordicSemi Y Huawei Y WILUS Y Sony N If two channels have the same priority, the UE should transmit / receive the channel that was scheduled latest. This allows the gNB to update scheduling decisions (e.g. if the gNB needs to send high priority DL traffic after it had previously scheduled an UL transmission). Intel Y LG Y OPPO Y We wonder if this is also the behavior assume by TDD UE in single carrier. Thus, TDD behavior can be covered by the text of 38.211 about Table 4.3.2-3. Should we need further text? IDCC Y FL2 Only one company (Sony) does not support the FL proposal Two companies (Ericsson, ZTE) clarify that the case is under the control of gNB scheduler and no need to specify anything. Based the received response, it seems that Proposal 3-4 can be agreed. Based on the proposals in FL summary #2 in R1-2103884, the following RAN1 agreements were made in an online (GTW) session on Wednesday 14th April: 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 Case 5: Configured SSB vs. dynamically scheduled or configured UL transmission Many contributions [5, 6, 9, 10, 12, 15, 17, 18, 21, 22, 24, 26, 27] express views that the existing TDD rule can be reused so that dynamically scheduled or configured UL transmission should be cancelled when colliding with SSB. Also, contribution [10] indicated that the existing rule may be extended to address the direction switching case by including overlapping with the time intervals that are used for DL-to-UL or UL-to-DL switching. Contribution [8] mentioned that it is up to gNB implementation to avoid collision. Contribution [7, 14, 19] discussed that if UE does not need to receive SSB then dynamically scheduled or configured UL transmission may not be cancelled since gNB can transmit and receive simultaneously on paired spectrum. In the contribution [16], it was noted that UE-autonomous prioritization between SSB reception and UL transmission increases detection complexity at the gNB receiver and therefore as a baseline it can be considered as an error case. Contribution [25] suggested to come back to this issue after the handling for case 2 and 3. Basically, two possibilities can be considered. Alt.1: Follow the handling of case 2 and 3 by considering SSB to be semi-statically configured DL reception Alt.2: Folow the principle of Rel-15/16 Contribution [29] noted that it should not be an issue for the dynamically scheduled UL transmission since it is fully controlled by gNB, but whether to transmit semi-statically configured UL transmission need further study. High Priority Proposal 3-5: For Case 5, down-select between the following two options: Option 1: Follow the handling of case 2 and 3 by considering SSB to be semi-statically configured DL reception Option 2: Reuse the existing collision handling principles in Rel-15/16 NR for operation on a single carrier /single cell in unpaired spectrum High Priority Question 3-5: Can Proposal 3-5 be agreed? If not, please explain why? Company Y/N Comments Ericsson Y, with modification For option 2, we would suggest adding the FFS below. FFS: how to account for Tx/Rx switching time before and after the set of SSB symbols Nokia, NSB Y vivo Y OK for now. The further down-selection will depend on the discussion outcome of case 3, especially how to handle the cell-specific DL reception and cell-specific UL transmission. Qualcomm Y China Telecom Y We are fine to support FL proposal and prefer to align with case 2 and case 3. DOCOMO Y Apple Y TCL Y Samsung Y with modifications We are fine with Ericsson’s suggestion for option 2 And we’d like to add option 3: - Whether SS/PBCH is received or a UL is transmitted is up to UE implementation The reason is because for FDD case, gNB has no issue to receive and transmit at the same time in different frequency range. From UE perspective, it may not need to receive SSB in connected mode. Therefore, UE might be able to transmit UL, especially dynamic scheduled UL. Spreadtrum Y CATT Y, mostly. Samsung’s example seems aligned with the handling of Case 2 (dynamic UL v.s. semi-static DL), where dynamic UL is prioritized (at least partially). To us, Samsung would like to find a combination way between Option 1 and Option 2, i.e. UL transmission is not always dropped, but may be different from Case 2/3. Not sure it is a good idea if the transmission is up to UE implementation, which may lead to gNB’s blind decoding. Anyway, a totally new handling rule is not preferred. If an Option 3 is added, we suggest the following version: Option 3: Combination of Option 1 and Option 2. FFS details, e.g. up to UE implementation, or controlled by gNB. Xiaomi If it is not the right time for downselection, we would rather keep it as FFS. We can discuss this issue after solutions of case 2 and 3 are clarified. CMCC Y with modifications Similar view with Samsung. gNB can transmit and receive simultaneously on paired spectrum. During the overlapping symbols, if UE doesn’t need to receive SSB, dynamically scheduled or configured UL transmission may not be cancelled to improve resource utilization. Whether SSB is received or a UL is transmitted can be up to UE implementation. ZTE Y?with modification For Option 2, we suggest to directly describe the handling principles as following: Option 2: reuse the handling principle that configured SSB has high priority. NordicSemi Y Option 2 Huawei Y WILUS Y Sony Y OK to down select between these two options. There might be different collision handling for different DL channels in cases 2 and 3 (see our responses in the relevant sections), so option 1 might not be as simple as saying that we follow case 2 / case 3 collision handling. Intel Y Option 1 results in a dynamic UL transmission is prioritized over SSB reception. Further, it is not always possible to avoid the collisions between SSB and semi-static UL transmission. Therefore, it may cause much limitation if such overlap is defined as error case. Therefore, Option 1 is not preferred Option 2 can be fine, which means UE always de-prioritize a UL transmission if it is overlapped with a transmitted SSB. As proposed by some companies, it is functionally possible that when UE doesn’t need to receive a SSB, UE can transmit the UL channel that overlaps with the SSB. We are open for such optimizations as well if sufficiently justified considering the potential impact on gNB receiver. LG Y, with modification The switching time needs to be considered for both Options. As we are mainly concerned on DL-to-UL switching, we propose to add the following FFS for both Options. FFS: how to account for Tx/Rx switching time after the set of SSB symbols The clarification from ZTE is helpful. The same could apply to all the previous cases whether the existing collision handling principle applies. OPPO Y Option 2. IDCC Y Option 2. FL3 Based on the received response, the following proposal can be considered. The UE-autonomous prioritization option is assumed to be covered by Option 3 since the details are FFS. Also, for better understanding of Option 1, a list of possible combinations is summarized below, whether the handling of case 3 is based on the latest FL proposal tagged with “FL3”. Example of UE behavior for Option 1 (where the handling of case 3 is based on the FL proposal tagged with “FL3”) Case 2: SSB vs. dynamic PUSCH, PUCCH, SRS or PRACH triggered by PDCCH order SSB reception is cancelled Case 3: SSB vs. UE dedicated configured UL (e.g. configured SRS, PUCCH, or CG PUSCH) Error case Case 3: SSB vs. cell-specific configured UL (e.g. valid RO excluding PRACH triggered by PDCCH order) FFS High Priority Proposal 3-5: For Case 5 of configured SSB vs. dynamically scheduled or configured UL transmission, down select between the following options: Option 1: Follow the handling of case 2 and 3 by considering SSB to be semi-statically configured DL reception Option 2: Reuse the existing collision handling principles of Rel-15/16 for NR TDD that SSB is prioritized over dynamic or semi-static UL Option 3: Combination of Option 1 and Option 2. FFS details, e.g. up to UE implementation, or controlled by gNB FFS: how to account for Tx/Rx switching time before and after the set of SSB symbols Company Y/N Comments vivo We would like to add FFS to option 3 as it has not been sufficiently discussed and the benefit is not clear. Nokia, NSB We are OK with options 1 & 2 but not really clear how option 3 is a combination of options 1 & 2. Maybe it’s more like Option 3 – up to UE combination, and Option 4 – controlled by gNB. Ericsson In the FL3 proposal, it is not clear what Option 3 exactly is. NordicSemi Y We prefer Option 2, but could live with Option 3. The reason is that Ros and SSBs are very important signals to UE, and this holds in both TDD and FDD. DOCOMO Y Huawei Y but The FFS is generally not needed for any of this sort of proposals Samsung We also think option 3 is not a combination of option1 and option 2. We suggest to change option 3 as: Option 3: up to UE implementation Option 4: controlled by gNB Qualcomm Agree with the comments of Vivo and Ericsson. Prefer to keep the FFS bullet CATT Y Also fine to add the FFS to Option 3, or rewrite it into two different options as suggested by Nokia and Samsung. ZTE We share similar view as Ericsson that Option3 is not clearly described. China Telecom It seems that Option 3 is proposed to make a compromise on Option 1 and Option 2. However, the FFS details are not clear. Option 3 makes this proposal more complicated but inefficient. Apple Share Nokia’s view. TCL Agree with the comments of Samsung. CMCC Y LG Down-selection b/w Option 1 and Option 2 is fine. Need further clarification on Option 3. No need to put FFS if it is not clearly understood what it means. Intel We share the views from some companies that option 3 is not clear. Instead of using “up to UE implementation” in general, we prefer to describe exact UE behavior to align gNB and UE’s understanding on the overlap handling. if a dynamically scheduled UL transmission overlap with a SSB, it can be considered as error case If semi-statically configured UL transmission overlaps with an SSB, the UE can receive the SSB if UE needs to receive the SSB; otherwise, UE can transmit the UL transmission. WILUS Agree with the proposal updated by Samsung. Combination of option 1 and option 2 in option 3 is unclear. Company Y/N Comments FL4 The intention of Option 3 is to support the down selection case by case, e.g. using different options for dynamic and semi-static UL. To make it clear, the proposal is modified as following. For the option “controlled by gNB”, the FL understanding is it is based on gNB configuration and can be different for different semi-static UL. Also, the semi-static UL here may include both cell-specific configured UL and UE-dedicated configurated UL. Please clarify if there is different understanding. High Priority Proposal 3-5: 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 the 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 or semi-static UL Option 3: Consider it as an error case (e.g. up to UE implementation) If a semi-static configured UL transmission overlaps with an SSB, down-select one of the following options Option 1: Controlled by gNB 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: Consider it as an error case (e.g. up to UE implementation) FFS: whether/how to account for Tx/Rx switching time before and after the set of SSB symbols vivo For the 2nd bullet, it is not clear what option 1 “Controlled by gNB” means? Does it mean gNB will give another configuration to tell the UE to prioritize DL or UL, or does it mean to introduce some rules specified rule depending on the content of semi-static configured UL transmission? Here the semi-static configured UL transmisison does not include RO, as the RO is covered by proposal 3-6 below, correct? OPPO Y, patially For option3 of both cases, it is somehow contradicting. If this is error cease, this is not up to UE implementation. We can just remove the sentences in brackets. For the second option 1, it is more like as a miss-configuration by gNB. Thus, seems we should also let UE looked is as an error configuration. ZTE As the FL mentioned “the semi-static UL here may include both cell-specific configured UL and UE-dedicated configured UL”, we suggest to add a Note in the 2nd bullet: “The collision handling scheme should be considered separately for cell-specific configured UL and UE-dedicated configured UL” Ericsson The wording “controlled by gNB” is not clear to us. We wonder if that is saying “gNB configuration to avoid such collision and if it happens it is an error case”. We need more time to analyze Case 5. There are different scenarios and the best option depends on whether the UE needs to receive SSB and whether the gNB know when the UE needs to receive SSB. We can agree to the proposal if “Other options are not precluded” is added to the proposal. The meaning of “controlled by gNB” is clarified. LG See no point of changing the structure. Option 1 and 2 were quite clear in the previous version. We needed clarification only for Option 3. If it is still not clear to most of companies, can we go back to the previous version with the Samsung’s suggestion? Then, only the clarification question on “Option 4: controlled by gNB” remains to be answered. For Case 5 of configured SSB vs. dynamically scheduled or configured UL transmission, down select between the following options: Option 1: Follow the handling of case 2 and 3 by considering SSB to be semi-statically configured DL reception Option 2: Reuse the existing collision handling principles of Rel-15/16 for NR TDD that SSB is prioritized over dynamic or semi-static UL Option 3: Combination of Option 1 and Option 2. FFS details, e.g. up to UE implementation, or controlled by gNB Option 3: up to UE implementation Option 4: controlled by gNB FFS: how to account for Tx/Rx switching time before and after the set of SSB symbols Samsung N In our view, up to UE implementation is different from an error case but, it means UE can select whether UE will transmit UL or receive SSB. With this understanding, option 3 can be revised as the following: Option 3: up to UE implementation whether UE transmit the UL or receive SSB And we can add: Option 4: Consider it as an error case Huawei, HiSilicon Agree that the previous version is simpler and clearer. DOCOMO Option 1 for semi-static UL should be removed, as the case when a semi-static configured UL transmission overlaps with an SSB means that it is not controlled by gNB to avoid the collision. If this case happens, it is same as Option 3, i.e. error case. CMCC The previous version is clearer. Agree that “Controlled by gNB” needs to be clarified, “up to UE implementation” and “Consider it as an error case” should be two options. Does case 3 already cover the “semi-static configured UL transmission overlaps with an SSB” of case 5? According to case 3, “cell-specifically configured DL reception vs. dedicated configured UL transmission” is an error case, “cell-specifically configured DL reception vs. cell-specifically configured UL transmission” is FFS. Intel We are fine to list options, targeting down-selection later For “controlled by gNB”, it seems better to reword as “up to gNB to avoid the collision between DL reception and UL transmission”. since the spec is drafted from UE side, such option is equivalent to define the collision as error from UE side. We share the views that ‘error case’ and ‘up to UE implementation’ are different. Therefore, they should be listed as different options. Instead of using ‘up to UE implementation’, it is better to specify the UE behavior for gNB understanding. therefore, we prefer to use that UE can receive the SSB if UE needs to receive the SSB; otherwise, UE can transmit the UL transmission. Case 8: Dynamic or semi-static DL vs. valid RO Many contributions [5, 10, 12, 15, 18, 21, 24, 26, 29] express views that the existing TDD rule can be reused so that the UE will not receive any DL symbols overlapping with the set of symbols corresponding to a valid RO plus Ngap symbols before the valid RO. Also, contribution [10] indicates that the existing rule may be extended to address the direction switching case by including overlapping with the time intervals that are used for DL-to-UL or UL-to-DL switching. Contribution [6, vivo] highlights that for Case 8 of dynamic or semi-static DL vs. valid RO, there are contradictions among the existing collision handling principles of Rel-15/16, and proposes to come back to this issue after a common understanding is made. Contribution [7, 14] mentioned that UE may be allowed to receive the DL signals/signals when colliding with valid RO, for example, when RedCap UE is not in initial access procedure. Similarly, in the contribution [19] it was discussed that prioritization of valid RO over DL reception may result in no DL slots that can be scheduled for RedCap UE when PRACH is configured in all the subframes. Three approaches are thus proposed for further study. Contribution [16] proposed to consider it as error case if a dynamically scheduled or configured DL reception overlaps with a valid RO since gNB has full control on the scheduling. Contribution [9, MTK] proposed that dynamic or semi-static DL vs. valid RO could be treated as Case 3 despite R15, while in the contribution [17] it was proposed to follow Case 1 by considering valid PRACH occasion to be semi-statically configured UL transmission. Contribution [25] suggested to come back to this issue after the handling for case 1 and 3. Basically, two possibilities can be considered. Alt.1: Follow the handling of case 1 and 3 by considering RO to be semi-statically configured UL transmission Alt.2: Folow the principle of Rel-15/16 High Priority Proposal 3-6: For Case 8, down-select between the following two options: Option 1: Follow the handling of case 1 and 3 by considering valid RO to be semi-statically configured UL transmission Option 2: Reuse the existing collision handling principles (valid RO prioritized over dynamic or semi-static DL) in Rel-15/16 NR for operation on a single carrier /single cell in unpaired spectrum High Priority Question 3-6: Can Proposal 3-6 be agreed? If not, please explain why? Company Y/N Comments Ericsson Y, with modification For option 2, we would suggest adding the FFS below. FFS: how to account for Tx/Rx switching time Nokia, NSB Y vivo Y OK for now. The further down-selection will depend on The discussion outcome of case 3, especially how to handle the cell-specific DL reception and cell-specific UL transmission. The outcome of email thread [104b-e-NR-7.1CRs-03] about how to interpret the current specification regarding collision between dynamic scheduled DL and RACH transmission. Qualcomm Y China Telecom Y Same view with Question 3-5. We are fine to support FL proposal and prefer to align with case 1 and case 3. DOCOMO Y We agree with vivo that the down-selection will depend on the outcome of [104b-e-NR-7.1CRs-03] Apple Y TCL Y Samsung N For option 1, if we follow case 1 like “valid RO is (partially) cancelled if timeline allows”, it may impact on the existing RO validity rule. With this reason, we don't support to follow the handling of Case 1. For case 3 in option 1, we suggest directly written as “UE does not expect to be scheduled as DL on the symbols of valid RO and Ngap.”, instead of referring to other cases. For option 2, we are fine to considering the outcome of mail thread [104b-e-NR-7.1CRs-03] Beside, we'd like to add following options: Option 3: Follow DL scheduling (FFS dynamic and/or semi-static) and do not transmit PRACH if at least one symbol of RO is collided with scheduled DL reception considering Ngap. Option 4: Leave it up to UE implementation (i.e., UE can transmit PRACH) The reasons for option 3 and 4 are, gNB is capable of receive UL and transmit DL at the same time. For UE, most of the time, there is no need to transmit PRACH. Even UE choose to transmit PRACH, UE can just simply sent NACK for the corresponding PDSCH. Besides, in the principle of LTE FDD, we don’t think there is any predefined rule on how to handle it. We don’t think it is a good choice to follow TDD-like principle of NR. E.g., for option 1, it may put too much restriction on gNB configuration. At this stage, we’d like to list all the potential solutions. Spreadtrum Y Sharp Y CATT Y, mostly. Similar case with proposal 3-5. For the same reason, the following option 3 can be considered: Option 3: Combination of Option 1 and Option 2. FFS details, e.g. up to UE implementation, or controlled by gNB. Xiaomi If it is not the right time for downselection, we would rather keep it as FFS. We can discuss this issue after solutions of case 2 and 3 are clarified. CMCC Y with modifications Similar as our comment to Proposal 3-5. gNB can transmit and receive simultaneously on paired spectrum and UEs do not always need to transmit PRACH. When RedCap UEs does not need to send PRACH, dynamic or semi-static DL reception may not be cancelled. Whether PRACH is transmitted or a DL is received can be up to UE implementation. ZTE Y ?with modification For Option 2, we suggest to directly describe the handling principles as following: Option 2: reuse the handling principle that valid RO has high priority. NordicSemi Y Option 2 Huawei Y Share vivo comments WILUS Y Sony N We share some of Samsung’s views, including Samsung’s final paragraph. Intel Similar to analysis to option 1 for Case 5, it is not preferred for Option 1 for Case 8 Option 2 can be fine, which means UE always de-prioritize a DL reception if it is overlapped with a valid RO or the Ngap symbols before the RO. As proposed by some companies, it is functionally possible that when UE doesn’t need to transmit a PRACH preamble, UE may be able to receive the DL channel that overlaps with the valid RO. LG Y, with modification The switching time needs to be considered for both Options. As we are mainly concerned on DL-to-UL switching, we propose to add the following FFS for both Options. FFS: how to account for Tx/Rx switching time before the valid RO The clarification from ZTE is helpful. The same could apply to all the previous cases whether the existing collision handling principle applies. OPPO Y Option2 IDCC Y FL3 Based on the received response, the following proposal can be considered. The UE-autonomous prioritization option is assumed to be covered by Option 3 since the details are FFS. Also, for better understanding of Option 1, a list of the possible combinations is summarized below, whether the handling of case 3 is based on the latest FL proposal tagged with “FL3”. Example of UE behavior for Option 1 (where the handling of case 3 is based on the FL proposal tagged with “FL3”) Case 1: dynamic PDSCH or CSI-RS vs. valid RO (excluding PRACH triggered by PDCCH order) To cancel PRACH based on a timeline Case 3: UE dedicated configured DL (e.g. PDCCH USS, SPS PDSCH, CSI-RS or DL PRS) vs. valid RO (excluding PRACH triggered by PDCCH order) Error case Case 3: Cell-specific configured DL (e.g. PDCCH CSS, SSB, Paging or SI occasions) vs. valid RO (excluding PRACH triggered by PDCCH order) FFS High Priority Proposal 3-6: For Case 8 of Dynamic or semi-static DL vs. valid RO, down select between the following options: Option 1: Follow the handling of case 1 and 3 by considering valid RO plus Ngap symbols to be semi-statically configured UL transmission Option 2: Reuse the existing collision handling principles of Rel-15/16 for NR TDD that valid RO plus Ngap symbols is prioritized over dynamic or semi-static DL Option 3: Combination of Option 1 and Option 2. FFS details, e.g. up to UE implementation, or controlled by gNB FFS: how to account for Tx/Rx switching time before and after the valid RO FFS: whether the same definition of valid RO is applied to HD-FDD RedCap UEs Company Y/N Comments OPPO Y vivo Same comment as proposal 3-5, suggest to add FFS to option 3. Regarding how to interpret the current behavior (i.e. option 2) is related to the outcome of email thread [104b-e-NR-7.1CRs-03] so the current wording may not be fully accurate. Nokia, NSB Same comment as Proposal 3-5 Ericsson In the FL3 proposal, it is not clear what Option 3 exactly is. DOCOMO Y Huawei Y without FFS Samsung Same as the comment to proposal 3-5, option 3 is not a combination of option 1 and 2, we suggest to modify it as: Option 3: up to UE implementation Option 4: controlled by gNB Qualcomm Since the TX/RX switching gap is still FFS, we prefer to add a sub-bullet as • exact value of Ngap is FFS CATT Y Also fine to add the FFS to Option 3, or rewrite it into two different options as suggested by Nokia and Samsung. ZTE We share similar view as Ericsson that Option3 is not clearly described. China Telecom The same view with proposal 3-5. The FFS details are not clear. Apple Same comment as Proposal 3-5. TCL Agree with the comments of Samsung. CMCC Y LG Same comment on Option 3 as in Proposal 3-5. Other than that, it is fine. Intel We share the views from some companies that option 3 is not clear. Instead of using “up to UE implementation” in general, we prefer to describe exact UE behavior to align gNB and UE’s understanding on the overlap handling. if a dynamically scheduled DL reception overlap with a valid RO, it can be considered as error case If semi-statically configured DL reception overlaps with a valid RO, the UE can transmit a PRACH preamble. If UE doesnt transmit PRACH preamble, Ue can receive the DL reception. WILUS Agree with the proposal updated by Samsung. Company Y/N Comments FL4 The intention of Option 3 is to support the down selection case by case, e.g. using different options for dynamic and semi-static DL. To make it clear, the proposal is modified as following. For the option “controlled by gNB”, the FL understanding is that it is based on gNB configuration and can be different for different semi-static DL. Also, the semi-static DL here may include both cell-specific configured DL and UE-dedicated configurated DL. Please clarify if there is any different understanding. High Priority Proposal 3-6: If a dynamically scheduled DL reception overlaps with a valid RO, down-select one of the following options: Option 1: Follow the handling of case 1 to cancel PRACH based on a timeline Option 2: Reuse the existing collision handling principles of Rel-15/16 for NR TDD considering the outcome of email thread [104b-e-NR-7.1CRs-03] Option 3: Consider it as an error case (e.g. up to UE implementation) If a semi-static configured DL reception overlaps with a valid RO, down-select one of the following options Option 1: Controlled by gNB Option 2: Reuse the existing collision handling principles of Rel-15/16 for NR TDD considering the outcome of email thread [104b-e-NR-7.1CRs-03] Option 3: Consider it as an error case (e.g. up to UE implementation) FFS: whether/how to account for Tx/Rx switching time before and after the valid RO FFS: whether the same definition of valid RO is applied to HD-FDD RedCap UEs vivo Similar question as to Proposal 3-5, option 1 “controlled by gNB” should be clarified. OPPO Y, partially Similar comments as in3-5 ZTE As FL mentioned “the semi-static DL here may include both cell-specific configured DL and UE-dedicated configured DL”, we suggest to a Note in 2nd bullet: “The collision handling scheme should be considered separately for cell-specific configured DL and UE-dedicated configured DL” Ericsson The wording “controlled by gNB” is not clear to us. We wonder if that is saying “gNB configuration to avoid such collision and if it happens it is an error case”. We need more time to analyze Case 8. We can agree to the proposal if “Other options are not precluded” is added to the proposal. The meaning of “controlled by gNB” is clarified. LG Same comment as in Proposal 3-5. Samsung N Same comment as case 3-5. Option 3 can be revised as the following: Option 3: up to UE implementation whether UE receive the DL or transmit PRACH And we can add: Option 4: Consider it as an error case DOCOMO Similar comment as Case 5. Option 1 for semi-static DL should be removed, as the case when a semi-static configured DL reception overlaps with a valid RO means that it is not controlled by gNB to avoid the collision. If this case happens, it is same as Option 3, i.e. error case. CMCC Similar comment as to Proposal 3-5, Intel Similar comments as in3-5. We are fine to list options, targeting down-selection later For “controlled by gNB”, it seems better to reword as “up to gNB to avoid the collision between DL reception and UL transmission”. since the spec is drafted from UE side, such option is equivalent to define the collision as error from UE side. We share the views that ‘error case’ and ‘up to UE implementation’ are different. Therefore, they should be listed as different options. Instead of using ‘up to UE implementation’, it is better to specify the UE behavior for gNB understanding. therefore, we prefer to use that the UE transmits a PRACH preamble if UE needs to transmit PRACH preamble. If UE doesnt transmit PRACH preamble, Ue can receive the DL reception. Case 9: Collision due to direction switching Many contributions [5, 6, 7, 8, 9, 10, 12, 14, 15, 16, 18, 19, 25, 26, 29] express their views on the collision due to direction switching (i.e. Case 9). Several contributions [5, 8] mention it is up to gNB implementation and no issue is identified for Case 9. Contributions [9, 16] note that any such collision should be treated as part of previous cases and a separate rule is not needed for Case 9. Contribution [10] observes that if this case concerns the back-to-back UL/DL scenario (without gap or with a gap shorter than the Tx/Rx switching time) then it can be avoided for cases 1, 2, 3 and 4 through proper gNB implementation but not for case 5 and 8. Contribution [6] proposes to FFS collision handling due to direction switching b/w cell specific configured DL reception and cell specific configured UL transmission and observes that other cases can be handled by gNB implementation. Several contributions [7, 12, 14, 18, 25, 26] propose to have explicit specification for UE behaviour, e.g. a HD-FDD UE is not required to perform transmission or reception during the switching time. In the contributions [15, 19] it was discussed that the direction switching time should occur in the duration of operation with lower priority and switching gap(s) need to be created before and/or after the high priority direction. High Priority Question 3-7: What, if any, other potential RAN1 specification impacts (beyond possible specification for other cases) do you expect for handling collision due to direction switching (i.e. Case 9)? Company Y/N Comments Ericsson See our comments for 3-5 and 3-6 regarding accounting for Tx/Rx switching time due to direction switching. Nokia, NSB We do not see collision with direction switching vivo This will depend on the outcome of case 3 especially regarding how to handle the cell-specific DL reception and cell-specific UL transmission. For other cases, no additional specification is needed. Qualcomm A HD-FDD UE is not required to transmit/receive during the interval of direction switching DOCOMO A HD-FDD UE is not required to transmit/receive during the direction switching time Apple Share Qualcomm’s view. Samsung Switching gap due to direction switching can be taken into account for other cases (e.g., 3-1, 3-5, 3-6) Spreadtrum No other RAN1 specification impacts CATT The UE is not required to perform neither transmission nor reception during the switching time. CMCC Share Qualcomm’s view. ZTE Share Qualcomm’s view. NordicSemi Would below be sufficient already? 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 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 Tx-Rx is given by Table 4.3.2-3. Huawei Case 9 is more about an error case. Sony There shouldn’t be a collision during direction switching (as stated by other companies). Agree with [15,19] that “direction switching time should occur in the duration of operation with lower priority and switching gap(s) need to be created before and/or after the high priority direction” Intel As a baseline we assume this is avoided for most cases. However, if there may be some cases without sufficient switching times between DL and UL, we prefer to treat Case 9 as part of Case 1/2/3/4/5/8. Therefore, if there is not enough switching time between a DL reception and a UL transmission at UE side, same handling as the corresponding Case 1/2/3/4/5/8 is assumed. LG Can be handled as part of collision handling cases under discussion. OPPO We do not see collision with direction switching FL3 Based on the received response, the following conclusion can be considered. High Priority Proposal 3-7: Conclusion: It is RAN1 understanding that the following is applied also to HD-FDD RedCap UEs 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 Company Y/N Comments OPPO Y vivo Y Nokia, NSB See our comments to Proposal 2-3 Ericsson Y NordicSemi Y DOCOMO Y Huawei N The value is being discussed in RAN4 so we could wait It requires further discussion for the N value for a RedCap UE indicating not support of simultaneous transmission and reception by simultaneousRxTxSUL A modified proposal could be Conclusion: It is RAN1 understanding that the following is applied also to HD-FDD RedCap UEs A UE not capable of full-duplex communication or not supporting simultaneous transmission and reception as defined by parameter by simultaneousRxTxSUL 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 or not supporting simultaneous transmission and reception as defined by parameter by simultaneousRxTxSUL 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] Xiaomi Y Samsung N No need to have such conclusion for now because Tx/Rx switching time is a part of discussion for other cases. Qualcomm Since the TX/RX switching gap is under discussion in RAN4, we prefer to add the following sub-bullet: • FFS NTX-RX and NRX-TX Vivo2 We think the conclusion is in general meaningful as it provide a basis for HD-FDD redcap UEs, we are fine to add “FFS NTX-RX and NRX-TX” as suggested by Qualcomm. CATT Y Also fine with Qualcomm’s suggestion. ZTE Y Spreadtrum Y China Telecom Y And we are fine to add FFS for NTX-RX and NRX-TX. It can be revisited after RAN4 feedback. Apple Y CMCC Y LG No need for this conclusion. The switching time is pending RAN4 confirmation. The conclusion on the switching time and the Proposal 2-3 leads to this conclusion or the others. Intel Y We are not sure about the relation between this FL proposal and the proposals on overlap handling. Taking case 2, i.e. semi-static DL overlapping with dynamic UL as example. Does it mean If the semi-static DL overlaps with dynamic UL in one or more symbols, then UL is prioritized Otherwise, if the two channels (semi-static DL and dynamic UL) do not overlap, but there is not enough switching time, it is considered as error case Is it the intention to have different behaviors of the above bullets? WILUS Y Company Y/N Comments FL4 The intention of the proposal is to clarify HD-FDD UE behavior when the scheduled/configured transmission/reception do not overlap but with a smaller gap than the switching or guard time, e.g. for Case 9. The FL understanding is that the description in clause 4.3.2 in TS 38.211 can be reused for HD-FDD to address this issue except for the switching time that is FFS and to be confirmed by RAN4. Regarding the modification from Huawei, the FL has a concern that it may have implication on supporting SUL for RedCap UE, which is not clear at this moment. It is noted that RAN4 has an on-going discussion for SUL band and its combination for Type A HD-FDD UE. It seems not necessary to repeat the similar discussion in RAN1. The proposal is modified as following for specifying general HD-FDD UE operation, irrespective of whether SUL is supported or not for RedCap. For the values of NTX-RX and NRX-TX, they will be based on RAN4 feedback. High Priority Proposal 3-7: 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 [N_(Rx-Tx) T_c] 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 [N_(Tx-Rx) T_c] after the end of the last transmitted uplink symbol in the same cell FFS NTX-RX and NRX-TX vivo Support. It is our understanding the proposal does not cover the SUL case which will be discussed separately. OPPO Y OK, to have this. Please clarify NTX-RX and NRX-TX applicable for HD-FDD We are not aiming for redefine the existing parameters. ZTE Y Ericsson Y LG No need for this conclusion. The switching time is pending RAN4 confirmation. By the way, I think Intel brought a good question from which companies can have their views aligned. I think we need some discussion on how the Proposal 3-7 works jointly with what we agreed on the Collision Case 2. Ericsson2 Regarding how Proposal 3-7 works jointly with the agreement for collision Case 2 that LG brought up, we now see a potential inconsistency. (Thanks LG) In the case of a dynamically scheduled UL transmission immediately before a semi-statically configured DL reception (i.e. with a gap less than N_(Tx-Rx) T_c), then there is no issue as the UL transmission is prioritized according to both Proposal 3-7 and the agreement for Case 2. But, in the case of a dynamically scheduled UL transmission immediately after a semi-statically configured DL reception (i.e. with a gap less than N_(Rx-Tx) T_c), then the rules according to Proposal 3-7 and the agreement for Case 2 are not consistent. Samsung Y with comments With the understanding that Case 9 is to clarify HD-FDD UE behavior when the scheduled/configured transmission/reception do not overlap, it would be better to capture it for the proposal like: For HD-FDD, reuse the same principle as Rel-15/16 UE not capable of full-duplex communication when the scheduled/configured transmission/reception do not overlap Huawei, HiSilicon No need No conclusion needed, given that the exact values are already in RAN4 discussion and it is not clear now per RAN4 discussion that how HD-FDD is different from a UE not capable of full-duplex communication. DOCOMO Y CMCC Y Intel We agree the FL proposal. As commented using emails, taking the following case as example, a dynamically scheduled UL transmission immediately after a semi-statically configured DL reception (i.e. with a gap less than N_(Rx-Tx) T_c) Proposal 3-7 says that the UE is not expected to transmit before the switching gap after the end of the last received downlink symbol in the same cell, not the last “scheduled” or “configured” DL signal/channel. With the analysis, case 9 can be handled similar to Case 2, i.e. the DL reception would be de-prioritized. Other potential case In [12] it was proposed that the rule for handling the collision between L1-RSRP measurement and dynamic or semi-static UL transmission should be addressed. For example, L1-RSRP measurement can be prioritized and UE is not required to perform UL transmission during the window of L1-RSRP measurement. Medium Priority Question 3-8: Companies are welcome to provide views for this potential collision case, e.g., whether it has been covered by the identified 7 cases or not. Company Y/N Comments TCL Y A potential collision may happen when BWP switching (e.g. trigged by the bwpInactivityTimer or by the MAC entity upon initiation of Random Access procedure) and HD-FDD D-U switching performed successively but the time gap is not sufficient to complete the previous switching. Intel Y We don’t think a separate overlap handling rule is needed. Since L1-RSRP is done based on SSB or CSI-RS, the corresponding rule for overlap between SSB or CSI-RS and UL transmission can be applied. vivo Y Agree with Intel. DOCOMO Y We share the view with Intel ZTE Y Based on the discussion on collision handling in case 3 and case 4, this collision case can be included. Semi-static UL/DL configuration Contributions [15, 16, 18, 24] propose to support semi-static TDD-like slot configuration for HD-FDD Type-A UE; while contributions [21, 27, 28] propose not to configure the semi-static TDD-like slot formats for HD-FDD. In the contributions [16, 18], it was mentioned that with the semi-static configuration of UL/DL pattern UE power consumption can be reduced. Also, [16] mentioned that the semi-static UL/DL configuration can be used to reduce the overhead of Type1 HARQ-ACK codebook size and simplify the collision handling procedures. Based on above, the following proposal can be considered. High Priority Proposal 4-1: FFS the need for NW to optionally configure semi-static TDD-like slot formats for HD-FDD UE. High Priority Question 4-1: Can Proposal 4-1 be agreed? If not, please explain why? Company Y/N Comments Ericsson N We do not see the need for such an FFS. Nokia, NSB N We do not see meaningful benefit from semi-static UL/DL configuration. On the other hand, it introduces considerable complexity in gNB implementation with respect to resource utilization. Qualcomm Y It is up to NW to configure or not configure a TDD-like slot format. This option should not be precluded. DOCOMO Y We are open to further discuss the necessity of the configuration TCL Y Samsung N Spreadtrum N CATT N Xiaomi Y The option is very helpful to avoid most UL/DL collision cases. Also it can help to resolve cell-specific semi-static DL/UL collisions, i.e. semi-static DL is prioritized in DL slots, and semi-static UL is prioritized in UL slots. NW has full flexibility on the configuration, including not configuring it. CMCC Y We are open to further discuss the FFS. ZTE N We do not see the need for such an FFS. Configure semi-static TDD-like slot formats would cause significant restriction on DL/UL switching to HD-FDD UEs. We see no benefit. NordicSemi N HD-FDD UE should consider all symbols are semi-static flexible. Huawei Y WILUS N At this stage, the necessity of semi-static UL/DL configuration is unclear. Sony We are OK if semi-static TDD-link slot formats are FFS. We are open to further discussion on this. Intel Y As clarified in our contribution, the benefit of semi-static TDD slot format includes power saving, Type1 HARQ-ACK codebook size reduction. In general, these additional benefits can be obtained with sacrifice in terms of scheduling restrictions. Depending on use-cases and deployments, such scheduling restrictions may be tolerable. Alternatively, a semi-static pattern of ‘Reserved (R)’ symbols may be configured to the UE to enable the UE power consumption benefits offered by a semi-static UL-DL pattern without incurring much scheduling restrictions. A UE may not be expected to monitor for PDCCH in a symbol indicated as ‘Reserved’. LG N The restriction is quite clear but we don’t see the benefit of such TDD-like slot formats in FDD bands. OPPO N FL3 10 companies (Ericsson, Nokia, Samsung, Spreadtrum, CATT, ZTE, NordicSemi, WILUS, LG, OPPO) express views that there is no need for such FFS. 7 companies (Qualcomm, DOCOMO, TCL, Xiaomi, CMCC, Huawei, Intel) support the FL proposal and are open to further discussion on this configuration. Considering the number of supported companies, Proposal 4-1 can be agreed. High Priority Proposal 4-1: FFS the need for NW to optionally configure semi-static TDD-like slot formats for HD-FDD UE Company Y/N Comments OPPO N We can say FFS the need for configure semi-static TDD-like slot formats for HD-FDD UE. NW can always optionally configure this. vivo OK to study further Nokia, NSB N We do not support FFS. Once the collision rules are clarified, there is no need to further specify TDD-like slot formats for HD-FDD UE. Ericsson N Two main potential motivations of introducing semi-static TDD-like slot formats for RedCap have been mentioned. For avoiding most UL/DL collision cases: However, the discussion in chapter 3 of this FLS is exactly intended for the same purpose. We don’t see any value in introducing yet another mechanism to address the same issue. UE power consumption benefit: The argumentation is mainly that the UE can skip PDCCH monitoring in a symbol indicated as ‘Reserved’. However, there are other ways to achieve UE power saving benefits or to skip PDCCH monitoring. For example, to allow the UE to skip PDCCH monitoring, instead of marking the particular symbols as “Reserved”, the gNB can configure the search space to control how often or how many symbols in a certain time interval the UE monitors PDCCH. NordicSemi N Based on RAN1 chairman principle, FFS is kept if majority of companies wants to keep FFS, which is not the case here based on the counting. DOCOMO Y OK to study further Huawei Y Xiaomi Y Samsung N We don't see a need but can live with the FFS Qualcomm Y CATT N Reasons have been well explained by Nokia, Ericsson and Nordic. ZTE N Collision handling cases have been identified and are being discussed, so TDD-like slot format for HD-FDD UE is not needed to be further studied. Spreadtrum N Similar views with Nokia, Ericsson, Nordic and ZTE. TCL Y CMCC Y OK to study further. LG N We see more restrictions than the benefits. Intel Y We think semi-static TDD-like slot formats should be studied for the power saving and size reduction of Type1 HARQ-ACK codebook. APT Y WILUS N We still cannot see strong motivation to support semi-static slot formats, as explained by Nokia, Ericsson, and ZTE. Due to semi-static slot formats, scheduling flexibility may be restricted. Other aspects (for information) UE capability signalling A few contributions [3, 4, 17] express views on the UE capability of HD-FDD. Contributions [3, 17] note that no specification impact in initial access/random access procedure is expected from HD-FDD Type-A UE and the UE capability signaling of HD-FDD can be reported to the network after initial access through UE capability framework Contribution [4] mentions that it is required for the network to know the UE capability signaling of HD-FDD in the earlier stage of initial access, e.g. to avoid zero gap between HARQ-ACK and the previous DL transmission FD-FDD fallback to HD-FDD A few contributions [17, 18] express views on enabling FD-FDD fall back operation to HD-FDD [17]: Support a signaling mechanism to enable HD-FDD operation for a FD-FDD capable RedCap UE [18]: A RedCap UE capable of full-duplex operation can fall back to Type-A HD-FDD for power saving in RRC connected state subject to the performance requirements for latency and throughput HARQ-ACK bundling support Contribution [8] proposes that HARQ-ACK bundling is not considered for HD-FDD in Rel-17 Medium Priority Question 5-1: Companies are welcome to provide views for the above issues. If there is any new issue to be addressed for half duplex FDD operation, please also indicate here. Company Y/N Comments Qualcomm Y Whether or not to specify different power control parameters for HD-FDD based on the insertion loss and receive sensitivity differences w.r.t. FD-FDD Intel We are fine to discuss the stage that UE can report the HD-FDD capability, either during initial access or after initial access. We don’t think it is necessary to configure FD-FDD UE to operate like a HD-FDD UE. The main difference between FD or HD operation is the overlap handling rules, which cause performance degradation. One additional discussion point is the interpretation of SFI for HD-FDD UE, if SFI for FDD is indicated by DCI 2_0. For example, if a symbol is indicated as ‘F’ in the SFI for DL carrier, however, it is ‘U’ in the SFI for UL carrier, UE may only do UL transmission if any and don’t do DL reception, which achieves similar function as UL symbol indicated by SFI of NR TDD . vivo UE capability signalling We are open to discuss FD-FDD fallback to HD-FDD We are not sure about the need for it. DOCOMO UE capability signalling We are open to discuss FD-FDD fallback to HD-FDD We don’t see the motivation to introduce the mechanism HARQ-ACK bundling support We don’t know why it is tied with HD-FDD Huawei It is not proper from FL to set proposals for information before reaching consensus, they could be discussed later depending on the progress but not treated as such. That said, sharing our view: Ok to discuss capability signalling. No need for FD-FDD fallback to HD-FDD Low priority for the support of HARQ-ACK bundling References [1] RP-210918 Revised WID on support of reduced capability NR devices Nokia, Ericsson [2] R1-2102220 RAN1 agreements for Rel-17 NR RedCap Rapporteur (Ericsson) [3] R1-2102356 Discussion on duplex operation for RedCap Huawei, HiSilicon [4] R1-2102404 On half-duplex operation OPPO [5] R1-2102462 Discussion on aspects related to duplex operation Spreadtrum Communications [6] R1-2102531 Discussion on RedCap half-duplex operation vivo, Guangdong Genius [7] R1-2102640 Discussion on HD-FDD operation CATT [8] R1-2102651 UE complexity reduction aspects related to duplex operation Nokia, Nokia Shanghai Bell [9] R1-2102701 On half duplex operation for RedCap UEs MediaTek Inc. [10] R1-2102724 Duplex operation for RedCap Ericsson [11] R1-2102735 Discussion on aspects related to duplex operation Asia Pacific Telecom, FGI [12] R1-2102856 HD-FDD for reduced capability NR devices ZTE [13] R1-2102874 Discussion on aspects related to duplex operation Potevio Company Limited [14] R1-2102891 Discussion on collision handling of HD-FDD operation CMCC [15] R1-2102990 Discussion on Half-duplex FDD operation of Redcap UE Xiaomi [16] R1-2103040 On HD-FDD support for RedCap devices Intel Corporation [17] R1-2103114 On aspects related to half-duplex operation Apple [18] R1-2103176 Type-A HD-FDD for RedCap UE Qualcomm Incorporated [19] R1-2103248 HD-FDD Operation for RedCap UEs Samsung [20] R1-2103309 Half-duplex FDD operation for Redcap UEs Sony [21] R1-2103354 Aspects related to the duplex operation of RedCap LG Electronics [22] R1-2103423 Duplex operation for RedCap UEs InterDigital, Inc. [23] R1-2103478 Discussion on the duplex operation of redcap UEs Sharp [24] R1-2103536 Half duplex operation for RedCap Lenovo, Motorola Mobility [25] R1-2103542 Aspects related to duplex operation Panasonic Corporation [26] R1-2103585 Discussion on duplex operation for RedCap NTT DOCOMO, INC. [27] R1-2103652 On aspects related to duplex operation Nordic Semiconductor ASA [28] R1-2103666 Discussion on aspects related to duplex operation ASUSTeK [29] R1-2103699 Discussion on duplex operation for RedCap UE WILUS Inc.