3GPP TSG-RAN WG1 Meeting #105-e R1-21xxxxx e-Meeting, 19th 每 27th May 2021 Agenda Item: 8.6.1.1 Title: FL summary #2 on reduced maximum UE bandwidth for RedCap Source: Moderator (Ericsson) Document for: Discussion, Decision 1 Introduction This feature lead (FL) summary (FLS) concerns the Rel-17 work item (WI) for support of reduced capability (RedCap) NR devices [1]. Earlier RAN1 agreements for this WI are summarized in [2]. This document summarizes contributions [3] 每 [31] submitted to agenda item 8.6.1.1 and relevant parts of contributions [32] 每 [34] submitted to agenda item 8.6.3 and captures this email discussion on reduced maximum UE bandwidth: [105-e-NR-R17-RedCap-01] Email discussion regarding aspects related to reduced maximum UE bandwidth 每 Johan (Ericsson) * 1st check point: 5/21 * 2nd check point: 5/25 * Final check: 5/27 The final FLS from the previous RAN1 meeting and the draft LS that was discussed then can be found in [35] and [36]. The issues in this document are tagged and color coded like this: 1. High Priority 2. Medium Priority In this round of the discussion, companies are requested to: 1. Express potential concerns/objections with the proposals tagged FL3 as soon as possible, preferable before the start of the GTW session, i.e. before Friday 21st May 12:00 UTC. 2. Provide comments on the questions tagged FL3 before the quiet period, i.e. before Friday 21st May 23:59 UTC. Follow the naming convention in this example: * RedCapBwFLS2-v000.docx * RedCapBwFLS2-v001-CompanyA.docx * RedCapBwFLS2-v002-CompanyA-CompanyB.docx * RedCapBwFLS2-v003-CompanyB-CompanyC.docx If needed, you may ※lock§ the discussion document for 30 minutes by creating a checkout file, as in this example: * Assume CompanyC wants to update RedCapBwFLS2-v002-CompanyA-CompanyB.docx. * CompanyC uploads an empty file named RedCapBwFLS2-v003-CompanyB-CompanyC.checkout * CompanyC then has 30 minutes to upload RedCapBwFLS2-v003-CompanyB-CompanyC.docx * If no update is uploaded in 30 minutes, other companies can ignore the checkout file. * Note that the file timestamps on the server are in UTC time. In file names, please use the hyphen character (not the underline character) and include ＆v＊ in front of the version number, as in the examples above and in line with the general recommendation (see slide 10 in R1-2104152), otherwise the sorting of the files will be messed up (which can only be fixed by the RAN1 secretary). To avoid excessive email load on the RAN1 email reflector, please note that there is NO need to send an info email to the reflector just to inform that you have uploaded a new version of this document. 2 Initial DL BWP 2.1 Initial DL BWP during initial access RAN1#104bis-e agreed the following working assumption related to initial DL BWP during initial access: Working assumption: * During initial access, the bandwidth of the initial DL BWP for RedCap UEs is not expected to exceed the maximum RedCap UE bandwidth. o The bandwidth and location of the initial DL BWP for RedCap UEs can be the same as the bandwidth and location of the MIB-configured initial DL BWP for non-RedCap UEs. o This does not preclude a SIB-configured initial DL BWP for non-RedCap UEs only with a wider bandwidth than the maximum RedCap UE bandwidth. o This does not preclude separate or additional bandwidth and location for initial DL BWP for RedCap UEs (FFS). Regarding the initial DL BWP, contributions unanimously agree to confirm the working assumption indicating that, during initial access, the bandwidth of the initial DL BWP for RedCap UEs is not expected to exceed the maximum RedCap UE bandwidth [3, 4, 6, 7, 9, 10, 13, 14, 17, 18, 19, 21, 22, 26]. However, one contribution [31] discusses that a RedCap UE can be configured with a BWP larger than its maximum supported bandwidth. FL1 High Priority Proposal 2.1-1: Confirm the following RAN1#104bis-e working assumption: * During initial access, the bandwidth of the initial DL BWP for RedCap UEs is not expected to exceed the maximum RedCap UE bandwidth. o The bandwidth and location of the initial DL BWP for RedCap UEs can be the same as the bandwidth and location of the MIB-configured initial DL BWP for non-RedCap UEs. o This does not preclude a SIB-configured initial DL BWP for non-RedCap UEs only with a wider bandwidth than the maximum RedCap UE bandwidth. o This does not preclude separate or additional bandwidth and location for initial DL BWP for RedCap UEs (FFS). Company Y/N Comments Huawei, HiSi Y Qualcomm Y The bracket for FFS in the third sub-bullet can be removed. Xiaomi Y ZTE, Sanechips Y vivo Y OPPO Y NordicSemi With modification The sub-bullet should be modified as follows o This does not preclude separate or additional bandwidth and location for initial DL BWP/CORESET#0 for RedCap UEs (FFS). As our technical concern is that UEs during initial access should not receive in BW other than 24/48/96 RB (i.e. CORESET#0) based on current specification, so this should be the baseline opearation. Spreadtrum Y RedCap UE should not operate in the initial DL BWP wider than the RedCap UE bandwidth. Sharp Y NEC Y CATT Y Fujitsu Y Samsung N We are not ready to confirm the WA. We need to clarify first on how RedCap UE determinate BW or frequency location of initial DL BWP first. IDCC Y Nokia, NSB Y CMCC Y LG Y We also think the FFS in the third sub-bullet is not needed. Ericsson Y FUTUREWEI Y The FFS should be kept Intel Y FL2 Based on the received responses, the same proposal can be considered again. High Priority Proposal 2.1-1: Confirm the following RAN1#104bis-e working assumption: * During initial access, the bandwidth of the initial DL BWP for RedCap UEs is not expected to exceed the maximum RedCap UE bandwidth. o The bandwidth and location of the initial DL BWP for RedCap UEs can be the same as the bandwidth and location of the MIB-configured initial DL BWP for non-RedCap UEs. o This does not preclude a SIB-configured initial DL BWP for non-RedCap UEs only with a wider bandwidth than the maximum RedCap UE bandwidth. o This does not preclude separate or additional bandwidth and location for initial DL BWP for RedCap UEs (FFS). Qualcomm Y DOCOMO Y vivo Y China Telecom Y Xiaomi Y LG Y Huawei, HiSi Y CMCC Y Panasonic Y TCL Y NordicSemi N If last sub-bullet is kept FFS, then it is unclear how gNB can operate RedCap UE in TDD and at what UE and gNB cost. We suggest to discuss FFS before confirming this WA. OPPO Y Samsung N We are not ready to confirm the WA. We need to clarify first on how RedCap UE determinate BW or frequency location of initial DL BWP first. Spreadtrum Y Sharp Y NEC Y Lenovo, Motorola Mobility Y CATT Y ZTE, Sanechips Y Nokia, NSB Y Ericsson Y FUTUREWEI2 Y FL3 Most responses support confirming the working assumption. Some responses have proposed to remove the FFS (either just the word FFS or the entire sub-bullet with the FFS), and one response has explicitly opposed removing the FFS. It should be noted that removing or keeping the FFS does not mean that ※separate or additional bandwidth and location for initial DL BWP for RedCap UEs§ is agreed to be included or excluded in the specification. One response proposes to clarify how a RedCap UE determines the bandwidth or frequency location of the initial DL BWP. A corresponding new question (High Priority Question 2.1-3) has been added in this document to address that aspect. Since most responses support the proposal as is, the FL suggests attempting to agree the proposal as is. High Priority Proposal 2.1-1: Confirm the following RAN1#104bis-e working assumption: * During initial access, the bandwidth of the initial DL BWP for RedCap UEs is not expected to exceed the maximum RedCap UE bandwidth. o The bandwidth and location of the initial DL BWP for RedCap UEs can be the same as the bandwidth and location of the MIB-configured initial DL BWP for non-RedCap UEs. o This does not preclude a SIB-configured initial DL BWP for non-RedCap UEs only with a wider bandwidth than the maximum RedCap UE bandwidth. o This does not preclude separate or additional bandwidth and location for initial DL BWP for RedCap UEs (FFS). Intel Y Qualcomm Y Ericsson Y vivo Y China Telecom Y FUTUREWEI3 Y Panasonic Y Regarding the FFS for whether a separate or additional bandwidth and location for initial DL BWP for RedCap UEs, most of the contributions state that the possibility of configuring such separate initial DL BWP can be beneficial in terms of e.g. flexibility and offloading purposes [3, 10, 16, 18, 19, 20, 21, 22, 24, 25, 26, 30]. One contribution [8] argues that separate/additional bandwidth and location for initial DL BWP for RedCap Ues should not be considered in Rel-17 because it occupies additional DL resources and there is no issue with using the same initial DL BWP for RedCap and non-RedCap Ues. The following proposal concerns initial DL BWP use during initial access. A related proposal regarding use after initial access is included in Section 2.2. FL1 High Priority Proposal 2.1-2: * An initial DL BWP for RedCap Ues for use during initial access can be configured separately from the initial DL BWP for non-RedCap Ues. Company Y/N Comments Huawei, HiSi Conditioned Y The same CORESET#0 is assumed and additional other CORESETs are to be further discussed. Qualcomm Partially Y For RedCap UE, NW is not necessary to configure a separate initial DL BWP for use during initial access (i.e. MIB configured CORESET0) when: 1) BW of initial UL BWP for non-RedCap UE ≒ max BW of RedCap UE and 2) RedCap and Non-RedCap Ues share the same initial UL BWP Xiaomi Can be agreed with some condition In the TDD system, if a separate initial UL BWP is configured and this newly configured initial UL BWP has different centre frequency compared with the MIB-configured initial DL BWP, then additional DL BWP can be configured to keep the same centre frequency between initial DL BWP and initial UL BWP. For other cases, we don＊t see strong need ZTE, Sanechips Y OPPO Y Two motivations for additional initial DL BWP during initial access for RedCap UE 1) Offloading Align central frequency of initial DL/UL BWP for RedCap NordicSemi Y, but with Similar concern as in Proposal 2.1.-1 During initial access, UE＊s initial DL BWP is CORESET#0 BW. I hope nobody want to change this. An initial DL BWP/CORESET#0 for RedCap Ues for use during initial access can be configured separately from the initial DL BWP/CORESET#0 for non-RedCap Ues. Spreadtrum Y The separate initial DL BWP during initial access has the benefits, e.g. offloading, alignment of centre frequency b/w the initial DL BWP and the initial UL BWP for the RedCap UE in TDD system. Sharp Y Same view with OPPO and Spreadtrum NEC Y vivo Y And we assume the spec should allow NW to configure CORESETs in the Redcap specific initial DL BWP for Redcap Ues to monitor paging and SI, etc. CATT Need FFS Creating additional cell-common initial DL BWP and potentially broadcasting information will lead to heavy DL resource cost, which seems not worthy to serve the small number of RedCap Ues in an early release. The legacy initial DL BWP is enough to serve the RedCap Ues for the purpose of initial access. Fujitsu Y Additional CORESETs can be configured for RedCap Ues as discussed in section 2.3. Samsung Y Maybe FFS can be added as sub-bullet FFS: whether the additional initial DL BWP for RedCap UE needs to contain entire CORESET #0 range. IDCC Y Nokia, NSB During initial access, we don＊t see strong need to have a separate MIB-configured initial DL BWP for RedCap UE given that there is no bandwidth issue in this case. We can understand the desire in TDD to have the same center frequency for UL and DL but we don＊t feel that is a strong motivation. CMCC Y Same view with OPPO and vivo. LG Y By agreeing on this proposal, our understanding is that we support the network configures separate initial DL BWP for RedCap Ues. Under what condition, and whether it can be in addition to the initial DL BWP shared with non-RedCap Ues can be discussed as a next step. Ericsson Y Same view as OPPO, Spreadtrum, Sharp, and CMCC. Regarding alignment of the center frequencies of DL and UL BWPs, we think it is good to allow the NW to have the flexibility of aligning the center frequencies if it prefers to do so. However, we also see flexible DL and UL BWPs placement can be beneficial in certain scenarios. FUTUREWEI It is unclear whether we are agreeing to separate (additional) configuration. This proposal seems related but a little broader than the FFS from 2.1-1. We agree with Qualcomm＊s observations that in many cases this proposal not needed and with CATT that more signaling is needed. We should focus on the FFS issue (2.1-1) directly, clarify CORESET#0 used (as mentioned by several companies), and discuss whether the configuration is needed or it can be defined somehow. Intel We can accept the motivation of offloading, IF we are now to address high RedCap UE density scenarios. However, it needs to be considered as to whether all common control needs to be duplicated in the additional initial DL BWP or not. Regarding the motivation of aligning center frequencies between DL and UL in TDD, we do not need there is sufficient justification for this motivation due to potential OH being excessive. FL2 Based on the received responses, the following updated proposal can be considered, where the only changes are in the sub-bullet. Note that additional CORESET is a separate issue which is discussed in Section 2.3. High Priority Proposal 2.1-2a: * An initial DL BWP for RedCap Ues for use during initial access can be configured separately from the initial DL BWP for non-RedCap Ues. o The same MIB-configured CORESET#0 is assumed and additional CORESETs are FFS. Qualcomm Partially Y We are not sure about the purpose of the sub-bullet. If a separate initial DL BWP is configured for RedCap UE and is used during initial access, additional CORESETs should be configured. Otherwise, offloading is not achievable. We can live with the main bullet, but a clarification is needed for the following case: 1) BW of initial UL BWP for non-RedCap UE ≒ max BW of RedCap UE and 2) RedCap and Non-RedCap Ues share the same initial UL BWP DOCOMO Y Our interpretation of ※can be configured§ is that gNB can configure either shared or separate initial DL BWP with/from non-RedCap Ues. Vivo We are fine with the main bullet but have the same question/concern as QC about the sub-bullet, we think additional CORESET should be naturally supported if the initial DL BWP for Redcap Ues is configured separately from the non-redcap Ues. China Telecom We agree with QC and vivo. We support the main bullet, and think there is no need to keep the FFS for additional CORESET. In our understanding, it would bring benefits like offloading by introducing additional CORESET. Xiaomi We think additional DL BWP is only necessary for the purpose of center frequency alignment in BWP pair in TDD system. We see some companies mentioned for the purpose of offloading, but up to now, we don＊t see concrete analysis to prove there is traffic congestion issue. So, here we want put a condition for this proposal. Our suggested revision on the main bullet is as follow High Priority Proposal 2.1-2a: * An initial DL BWP for RedCap Ues for use during initial access can be configured separately from the initial DL BWP for non-RedCap Ues only for the purpose of center frequency alignment in BWP pairs in TDD system. As for the subbullet, we have the same concern with QC. LG We share the same view with QC, vivo and China Telecom. We can only agree with the main bullet. Huawei, HiSi Y To some comments on the subbullet: If the understanding is naturally additional CORESET is supported, then there won＊t be proposal Question 2.3-1. If the additional CORESET is for offloading, then it must be additional CORESET#0 for RedCap Ues, otherwise RedCap UE still monitor legacy CORESET#0 then no offloading is offered. Or, we should revise the text to use ※separate CORESET§ instead of ※additional CORESET§, since the latter does not offer offloading but just require more resources. The support of additional CORESET#0 introduces multiple initial BWPs and CSSs of same type from gNB point of view which increase the detection efforts and consume more resources. If the traffic of RedCap Ues are large enough it is worthwhile consideration but for the first release there is no strong need to do it. Sharing the single CORESET#0 seems sufficient. On the other hand, if separate CORESET#0 for RedCap is deemed necessary in Rel-17, it should then consider to mandatory support RedCap UE BWP outside SSB, otherwise it will either require gNB to send multiple SSBs which cause even significant overhead or to require RedCap Ues to mandatorily support BWP without restriction (i.e. without SSB) and do switching/retuning for DL reception. The former is not desirable from network point of view as has impact on overall system efficiency, while the latter we might be able to consider. CMCC We agree with the main bullet. Separate initial DL BWP for RedCap Ues is configurable by gNB for the purpose of offloading or coexistence with non-RedCap Ues. When BW of initial UL BWP for non-RedCap UE is larger than max BW of RedCap UE and separate initial DL BWP is configured for coexistence, if separate initial DL BWP includes MIB-configured CORESET#0, RedCap Ues can use the same CORESET#0. When separate initial DL BWP is configured for offloading and separate initial DL BWP does not include MIB-configured CORESET#0, additional CORESET can be configured within separate initial DL BWP. Panasonic Y TCL Y NordicSemi Y, but remove FFS Clearly separate BWP that is not overlapping with MIB CORESET#0 is beneficial for TDD. Clearly some CORESET is needed for UE to operate in such BWP if CORESET#0 is not there. Such CORESET could be * CORESET#0 or CommonControlResource configured in pddch-ConfigCommon in SIB1 * Other CORESET And this can be discussed further. If above is not supported, then either UE would need additional capabilities in TDD (compared to eMBB) or gNB flexibility and legacy UE performance is impacted. OPPO Partially Y We agree with the main bullet. But for the sub-bullet, we share similar view with vivo, Huawei, CMCC, additional CORESET or separate CORESET is needed since it is for a different DL BWP. Samsung Y We think additional CORESET can be supported. So , no need to put FFS there. Besides, we like to add an FFS, which is not related to additional CORESET, but the location of initial DL BWP. FFS: whether the additional initial DL BWP for RedCap UE needs to contain entire CORESET #0 range. However, if this proposal is not intended to have any restriction of the location of initial DL BWP for Redcap, we are fine. Spreadtrum We share the same view with most companies. For the sub-bullet: The same MIB-configured CORESET#0 is assumed and additional CORESETs are FFS. We are not sure the MIB-configured CORESET#0 should be contained in the separate initial DL BWP for the RedCap UE. And we are confused about the additional CORESET discussed below. In current 38.331, CORESET#0 seems cell-specific and cannot be modified by ControlResourceSet IE. Value 0 identifies the common CORESET configured in MIB and in ServingCellConfigCommon (controlResourceSetZero) and is hence not used here in the ControlResourceSet IE The sub-bullet needs further discussion. Sharp Y We are OK with the proposal and also OK to remove the sub bullet. Separate initial DL BWP during initial access should be applied at least for alignment of the center frequency alignment of initial DL/UL BWP (with Proposal 3.1-2). Then in that case, if the separate initial DL BWP does not include CORESET#0, additional CORESET should be allocated in the separate initial DL BWP. NEC Y Lenovo, Motorola Mobility N We can agree with the main bullet, but not the FFS. If during initial access the RedCap Ues use legacy MIB-configured CORESET#0, the RedCap Ues have same behaviour with legacy Ues during initial access. The separate initial DL BWP for RedCap Ues, if configured (and contain legacy CORESET#0), is used only after initial access If separate initial DL BWP is configured for RedCap Ues to be used during initial access, then there is an additional CORESET in the configured initial DL BWP. CATT N We have even more concerns now. Assuming the same MIB-configured CORESET#0 is applied, and then based on the current mechanism, the initial DL BWP should include CORESET#0. For a RedCap UE with 20 MHz BW in FR1, a ＆new＊ initial DL BWP will largely overlap with the legacy initial DL BWP, which does not help offloading. And we observed that the concerns from the 1st round discussion are not addressed by the new proposal. ZTE, Sanechips Y Nokia, NSB We still have same concern as before. As described by some proponents, the goal is to have separate CORESET/BWP for RedCap to use during initial access instead of using CORESET#0 and associated BW. We don＊t see strong need to have a separate initial DL BWP for RedCap UE given that there is no bandwidth issue in this case. We can understand the desire in TDD to have the same center frequency for UL and DL but we don＊t feel that is a strong motivation. We also don＊t really see offloading as a strong motivation as we don＊t expect massive number of RedCap devices in the cell. Ericsson Y We agree with most companies that a separate initial DL BWP can naturally include an additional CORESET. However, we think that RedCap can rely on CORESET #0 for SIB1, and then it can use the potential additional CORESET in the separate initial DL BWP for other transmissions during initial access. FUTUREWEI2 The issues/concerns raised by companies were not addressed with this revised proposal, and in fact, more comments are raised with the FFS FL3 Based on the received responses, the following updated proposal can be considered, where the changes are in the sub-bullets. Note that additional CORESET is a separate issue which is discussed in Section 2.3. High Priority Proposal 2.1-2b: * An initial DL BWP for RedCap Ues for use during initial access can be configured separately from the initial DL BWP for non-RedCap Ues. o The configuration for a separately configured initial DL BWP for RedCap Ues can include a CORESET configuration. o FFS: whether a separately configured initial DL BWP for RedCap Ues needs to contain the entire CORESET #0 Intel We now understand that the main use-case here is for use post-RRC connection and not necessarily in Idle/inactive modes. With this understanding, we can support the proposal. In this regard, we would suggest adding a note to clarify that the separate initial DL BWP for RedCap Ues does not apply until after RRC connection. If the separate initial DL BWP is to be used prior connection establishment, further clarifications are necessary on what is expected of the UE prior connection establishment. Qualcomm Y We can live with FL3 proposal. However, a clarification is preferred regarding when the initial DL BWP for RedCap Ues should be separately configured. Ericsson Y Regarding Intel＊s comment, we have different understanding. We think this proposal concerns use during initial access as stated in the main bullet. However, regarding the potential need for further clarifications of what is expected from the UE prior to connection establishment, see also our comments on Question 2.1-3. Vivo Modification needed 1. It is our understanding that the seperate initial DL BWP for redcap Ues should be applicable for IDLE/INACTIVE Ues, otherwise, the offloading benefit and DL/UL BWP alignment cannot be achieved for IDLE/INACTIVE Ues. This seems to be differnt from Intel＊s understanding above, so clarification would be needed from FL on this point 2. The FFS bullet is still unclear. As commented by CATT, if the seperate initial DL BWP for redcap has to contain entire CORESET#0 and considering the fact that the size should be no larger than the UE BW capability, then it seems the seperate initial DL BWP for redcap would largely overlap (or mostly overlap) with the legacy initial DL BWP, then no offloading benefit can be achieved. Based on some of the replies above, it seems the following might be the real intention of the FFS? FFS: The Redcap UE behaviour for CORESET#0 monitoring if the separate initial DL BWP does not contain CORESET#0. FUTUREWEI3 We are not convinced the moderator addressed the issues. Also, we suggest to replace ※configured§ with ※configured/defined§ Also state the RedCap UE UL BWP is ※no wider than the RedCap UE maximum bandwidth§ Panasonic Y One response to High Priority Proposal 2.1-1 above proposed to clarify how a RedCap UE determines the bandwidth or frequency location of the initial DL BWP. FL3 High Priority Question 2.1-3: * How should the RedCap UE determine the bandwidth and frequency location of the initial DL BWP for RedCap Ues? (Do the legacy procedures apply to RedCap Ues, or what are the differences?) Company Comments Intel If it is separately configured, it can be provided in SIB1 and should follow similar principles of applicability, e.g., of locationAndBandwidth parameter, as for Rel-15 每 that is, RedCap UE should apply the separate initial DL BWP configuration after RRC connection establishment. In terms of actual indication, whether the entire initial DL BWP configuration is repeated or only certain parameters are separately provided and UE reuses the rest from the SIB1-configured initial DL BWO for non-RedCap Ues could be further studied. Qualcomm If the initial DL BWP for RedCap UE is separately configured, the BWP information element for locationAndBandwidth can be carried SIB1, or based on rules (e.g. LUT) specified in spec. Ericsson If no separate initial DL BWP is configured for RedCap Ues, the RedCap UE follows the legacy procedure. If a separate initial DL BWP is configured for RedCap Ues, the RedCap UE acquires such configuration in SIB1. In our view, the RedCap UE can already switch to the separate initial DL BWP during initial access, after it has acquired the configuration information of the separate initial DL BWP. Vivo The bandwidth and frequency location of the initial DL BWP for RedCap Ues can be provided by SIB1. And it is our understanding that such separate initial DL BWP for redcap Ues should be applicable for IDLE/INACTIVE Ues, i.e. before RRC connection. Panasonic The configuration on separate initial DL BWP can be given via SIB1. 2.2 Initial DL BWP after initial access RAN1#104bis-e agreed the following working assumption related to initial DL BWP after initial access: Working assumption: * After initial access, at least for BWP#0 configuration option 1 (as in 38.331, Appendix B2), a RedCap UE is not expected to operate with an initial DL BWP wider than the maximum RedCap UE bandwidth. o FFS: BWP#0 configuration option 2 (as in 38.331, Appendix B2) One of the working assumptions indicated in RAN1#104bis-e is that after initial access, at least for BWP#0 configuration option 1 (as in 38.331, Appendix B2), a RedCap UE is not expected to operate with an initial DL BWP wider than the maximum RedCap UE bandwidth and it is FFS whether this applies to BWP#0 configuration option 2 (as in 38.331, Appendix B2). Most of the contributions, e.g. [3, 5, 6, 7, 8, 9, 12, 13, 14, 16, 18, 20], agree to confirm this working assumption. Also, regarding the FFS, they indicate that, similar to the case for BWP#0 configuration option 1, a RedCap UE is not expected to operate with an initial DL BWP wider than the maximum RedCap UE bandwidth for BWP#0 configuration option 2. One contribution [4] mentions that further clarification on BWP#0 configuration is needed, especially regarding the term ※after initial access§. FL1 High Priority Proposal 2.2-1: Replace the RAN1#104bis-e working assumption with the following agreement: * After initial access (i.e., after RRC Setup, RRC Resume, or RRC Reestablishment), for both BWP#0 configuration options 1 and 2 (as in 38.331, Appendix B2), a RedCap UE is not expected to operate with an initial DL BWP wider than the maximum RedCap UE bandwidth. Company Y/N Comments Huawei, HiSi Y Qualcomm Y Xiaomi Y ZTE, Sanechips Y OPPO Y NordicSemi Y, but We are fine to go this direction, but design should ensure that gNB provides an non-cell-defining SSB (i.e. SSB without PBCH) in initial DL BWP used after initial access, and needed at least for serving cell RRM. Spreadtrum Y After initial access, it is natural that gNB should configure the initial DL BWP no wider than the RedCap UE bandwidth. After the effective time of RRC reconfiguration, it is natural that gNB should configure the BWP (including the initial DL BWP) no wider than the RedCap UE bandwidth. There is no spec impact. In the time interval b/w Msg.4 (RRCSetup/RRCResume/RRCReestablishment) and effective time of RRC reconfiguration, as the legacy rule, the legacy UE should apply the frequency location and bandwidth reconfigured by LocationAndBandwidth, The reconfigured bandwidth is usually wider than CORESET#0. Therefore, - If the RedCap UE is in the shared initial DL BWP (no wider than the RedCap UE bandwidth), LocationAndBandwidth should not be applied to the RedCap UE. - If the RedCap UE is in the separate initial DL BWP, LocationAndBandwidth for the separate initial DL BWP should not indicate the bandwidth wider than the RedCap UE bandwidth. It is natural. Regarding BWP#0 configuration option 2, the current network (e.g. single BWP mentioned by some companies) has to be updated not only for the initial DL BWP but also the initial UL BWP (even the shared initial BWP). Even if RF-retuning is supported, gNB scheduling should be update due to time gap of RF-returning. Sharp Y NEC Y vivo Y CATT Y Fujitsu Y Samsung We are OK to update the proposal as working assumption. IDCC Y Nokia, NSB Y CMCC Y LG Y Ericsson Y FUTUREWEI Y Intel Y FL2 Based on the received responses, the following updated proposal can be considered, where the proposal is now a revised working assumption rather than a proposed agreement. High Priority Proposal 2.2-1a: Replace the RAN1#104bis-e working assumption with the following revised working assumption: * Working assumption: After initial access (i.e., after RRC Setup, RRC Resume, or RRC Reestablishment), for both BWP#0 configuration options 1 and 2 (as in 38.331, Appendix B2), a RedCap UE is not expected to operate with an initial DL BWP wider than the maximum RedCap UE bandwidth. Qualcomm Y DOCOMO Y vivo We are fine with making a working assumption for BWP#0 configuration option 2 if companies still need time to check, but to make progress, agreement should be made for BWP#0 configuration option 1 (it has been a working assumption already since last meeting). China Telecom Y We are fine with this working assumption. Xiaomi We share the same view with vivo. At least BWP#0 configuration option 1 can be agreed. LG Y Huawei, HiSi Agree with vivo CMCC Y Panasonic Y TCL Y NordicSemi Y OPPO Y Samsung N but We are OK to update the proposal as working assumption instead of a proposal. Spreadtrum Y Sharp Y NEC Y Lenovo, Motorola Mobility Y CATT Y ZTE, Sanechips Y Nokia, NSB Y Ericsson Y FUTUREWEI2 Y Similar observation about option 1 (it was a working assumption in last meeting) FL3 Based on the received responses, the following updated proposal can be considered. High Priority Proposal 2.2-1b: Replace the RAN1#104bis-e working assumption with the following agreement (for option 1) and working assumption (for option 2): * After initial access (i.e., after RRC Setup, RRC Resume, or RRC Reestablishment), for BWP#0 configuration option 1 (as in 38.331, Appendix B2), a RedCap UE is not expected to operate with an initial DL BWP wider than the maximum RedCap UE bandwidth. * Working assumption: After initial access (i.e., after RRC Setup, RRC Resume, or RRC Reestablishment), for BWP#0 configuration option 2 (as in 38.331, Appendix B2), a RedCap UE is not expected to operate with an initial DL BWP wider than the maximum RedCap UE bandwidth. Intel Y Qualcomm Y Ericsson Y vivo Y China Telecom Y FUTUREWEI3 Y Panasonic Y The following proposal is related to a corresponding proposal in Section 2.1. FL1 High Priority Proposal 2.2-2: * If an initial DL BWP for RedCap UEs for use during initial access is configured separately from the initial DL BWP for non-RedCap UEs, this separately configured initial DL BWP for RedCap UEs can also be used after initial access (i.e., after RRC Setup, RRC Resume, or RRC Reestablishment). Company Y/N Comments Huawei, HiSi Y Qualcomm Y Xiaomi This is not an urgent issue, we can further discuss it when there is stable conclusion for Proposal 2.1-2 ZTE, Sanechips Y vivo Y And we assume the spec should allow NW to configure CORESETs in the Redcap specific initial DL BWP for Redcap UEs to monitor paging and SI, etc. OPPO Y If there is no initial DL BWP configured by SIB, this is a natural way for RedCap UE. NordicSemi N Initial DL BWP/CORESET#0 for RedCap UEs is used during initial access (e.g. 24RB). In Option 2, a gNB may configure Initial DL BWP by SIB1 (e.g. 51 RB) for RedCap UEs. In Option 1, UE gets dedicated BWP#1 by dedicated RRC. Spreadtrum Y In the current spec, the initial DL BWP configured by SIB1 can be used after initial access. Also, it is also allowed that gNB reconfigures the initial DL BWP by dedicated RRC signalling. There is no spec impact. Sharp Y NEC Y CATT Same view as Xiaomi. Should be discussed based on the outcome of Proposal 2.1-2 Fujitsu Y Samsung Y IDCC Y Nokia, NSB Y CMCC Y LG Y Ericsson Y Can also wait until the discussion on Proposal 2.1-2 is stable. FUTUREWEI We should wait until the FFS is resolved in 2.1-1 Intel Y (conditional) As mentioned by others, it may be better to wait until resolution of Proposal 2.1-2. FL2 Based on the received responses, the same proposal can be considered again after Proposals 2.1-1 and 2.1-2 have seen more progress. High Priority Proposal 2.2-2: * If an initial DL BWP for RedCap UEs for use during initial access is configured separately from the initial DL BWP for non-RedCap UEs, this separately configured initial DL BWP for RedCap UEs can also be used after initial access (i.e., after RRC Setup, RRC Resume, or RRC Reestablishment). Qualcomm Y DOCOMO Y vivo Y China Telecom Y Xiaomi We still think it is a bit early to agree this proposal since there is no conclusion on the configuration of additional initial DL BWP. But If the majority is OK, we can live with it. LG Y Huawei, HiSi Y CMCC Y Panasonic Y TCL Y NordicSemi N We have issue with ※If an initial DL BWP for RedCap UEs for use during initial access is configured ＃＃ this separately configured initial DL BWP for RedCap UEs can also be used after initial access§. Particularly with word ※use and also§, which implies that arbitrary BW size configured in initial DL BWP in SIB1 would be immediately applicable to REDCAP UE, e.g. for DCI format size determination on Pcell. Change of DCI 1_0 format size during initial access is unnecessary complexity. Therefore, we suggest to refine the wording If an initial DL BWP for RedCap UEs for use during initial access is configured separately from the initial DL BWP for non-RedCap UEs, this separately configured initial DL BWP for RedCap UEs can also be used after initial access (i.e., after RRC Setup, RRC Resume, or RRC Reestablishment). OPPO Y Spreadtrum Y Sharp Y NEC Y Lenovo, Motorola Mobility Y CATT Prefer to wait for more progress of Proposal 2.1-2 ZTE, Sanechips Y Nokia, NSB Y We are fine but this depends on Proposal 2.1-2 Ericsson Y Can also wait until the discussion on Proposal 2.1-2a is stable. FUTUREWEI2 We should wait until the FFS is resolved in 2.1-1 FL3 Based on the received responses, the following updated proposal (based on the response from Nordic Semiconductor) can be considered. High Priority Proposal 2.2-2a: * If an initial DL BWP for RedCap UEs during initial access is configured separately from the initial DL BWP for non-RedCap UEs, this separately configured initial DL BWP for RedCap UEs can be used after initial access (i.e., after RRC Setup, RRC Resume, or RRC Reestablishment). Intel Y Qualcomm Y Ericsson Y vivo N First of all, we need to have clear understanding on Proposal 2.1-2b: on whether the separately configured initial DL BWP for redcap UEs is applicable for IDLE/INACTIVE UEs. From our understanding, it should be applicable. And if this is the correct understanding we should go back to the previous FL proposal. If an initial DL BWP for RedCap UEs for use during initial access is configured separately from the initial DL BWP for non-RedCap UEs, this separately configured initial DL BWP for RedCap UEs can also be used after initial access (i.e., after RRC Setup, RRC Resume, or RRC Reestablishment). China Telecom Y We are fine to support vivo＊s updated proposal. FUTUREWEI3 N Need to wait on the outcome of 2.1-1b Wording suggestion: change ※configured§ to ※configured/defined§ Panasonic Y 2.3 Additional CORESET for Msg2/Msg4/Paging/SI Another FFS (identified in RAN1#104-e) is whether an additional CORESET can be configured for RedCap for the purpose of offloading Msg2/Msg4/Paging/SI messages. Agreements: * FFS whether or not to further introduce the following (e.g., for offloading purpose, for differentiation of RedCap vs. non RedCap Ues, for different BWP#0 configuration options, etc.) o Whether an additional CORESET can be configured for scheduling of RACH (msg2 & msg4)/Paging/SI messages for RedCap Ues o Whether the SIB-configured initial DL BWP for RedCap Ues can also be configured to be different from the SIB-configured initial DL BWP for non-RedCap Ues. o Whether the SIB-configured initial UL BWP for RedCap Ues can also be configured to be different from the SIB-configured initial UL BWP for non-RedCap Ues. There are different views on introducing an additional CORESET for offloading purposes. Several contributions [3, 12, 16, 20, 21, 25] state that having additional CORESET for scheduling of Msg2/Msg4/Paging messages (and perhaps but not necessarily for SI messages) can be beneficial for congestion mitigation and offloading purposes. Meanwhile, a few other contributions [5, 8, 9] argue that an additional CORESET is not needed in Rel-17 since the congestion is not expected to be significant. One contribution [6] states that a separate initial DL BWP for RedCap UE is preferred and that it is not necessary to support the additional CORESET that is within the initial DL BWP shared between the RedCap and non-RedCap Ues. FL1 High Priority Question 2.3-1: * Should the possibility to configure an additional CORESET for scheduling of Msg2 and/or Msg4 and/or Paging and/or SI for RedCap Ues be supported? Please provide a motivation for your answer. Company Y/N Comments Huawei, HiSi Traffic load for the initial commercialization of RedCap might not be significant as one aspect. Additionally there could be the potential impact at gNB side in the above case in order to support multiple CSS of same type. We are not in favour of this approach. Qualcomm Y We support an additional CORESET for RedCap Ues because: * When the channel BW is wider than the max BW of RedCap UE, such configuration helps with traffic offloading and co-existence of different UE types * It helps with center frequency alignment of initial DL BWP and initial UL BWP in TDD bands, which can avoid the undue spec impacts in RAN1/RAN2/RAN4, timeline changes, and potential increase of UE complexity and power consumption. * An non-cell-defining SSB (for non-RedCap Ues) can be jointly configured with this CORESET to simplify the RRM/RLM measurements of RedCap Ues and non-RedCap Ues (when the intial DL BWP of RedCap Ues are partially overlapping with RedCap UE＊s active DL BWPs). Xiaomi From the aspect of traffic offloading, we don＊t see strong need to introduce additional CORESETE for scheduling Mg2 and/or Msg4 and/or Paging and/or SI for RedCap Ues We think this issue is related to the configuration of additional initial DL BWP. If Redcap and non-Redcap share the same initial DL BWP, we don＊t see the necessity to configure additional CORESET. But on the other hand, if additional DL BWP is configured as we talked in Proposal 2.1-2 , in the TDD system, if a separate initial UL BWP is configured and this newly configured initial UL BWP has different centre frequency compared with the MIB-configured initial DL BWP, then additional initial DL BWP can be configured to keep the same centre frequency between initial DL BWP and initial UL BWP. In this case, additional CORESET for scheduling Msg.2 and Msg.4 should be defined in this new additional initial DL BWP. ZTE, Sanechips Y For scheduling of Msg2/Msg4, the key motivation is for offloading. For scheduling of paging, the key motivation is for UE＊s power saving. In addition, to configure an additional CORESET can reduce the negative impact on scheduling of Mag2/Msg4/Paging of legacy NR Ues caused by 1 Rx RedCap Ues. Vivo Our understanding is if the separate initial DL BWP is configured for RedCap Ues, then the additional CORESET for scheduling of Msg2 and/or Msg4 and/or Paging and/or SI should be naturally supported in the separate initial DL BWP. However, if the legacy initial DL BWP is shared between the RedCap and non-RedCap Ues, there is no need to support the additional CORESET for RedCap Ues. The assumption for this question is not clear. The question can be modified as ※When the initial DL BWP is shared between the RedCap and non-RedCap Ues, Should the possibility to configure an additional CORESET for scheduling of Msg2 and/or Msg4 and/or Paging and/or SI for RedCap Ues be supported§ and our views is No for the modified question. OPPO Y Share similar views with ZTE NordicSemi Y We agree with QC points. In addition, an additional CORESET (CORESET#0A or whatever other name we invent for it ) should follow sizes 24,48,96 RBs as CORESET#0. Of course, simplest is to use the same configuration as signalled for non-RedCap Ues in MIB, but location in frequency can be different. Spreadtrum For the legacy UE, the additional CORESET is confined in CORESET0, as described in 38.331: The network configures the commonControlResourceSet in SIB1 so that it is contained in the bandwidth of CORESET#0 Therefore, - If the RedCap UE is in the shared initial DL BWP (no wider than the RedCap UE bandwidth), the additional CORESET can be used by the RedCap UE. - If the RedCap UE is in the separate initial DL BWP, We are not sure whether the ※additional§ CORESET in the separate initial DL BWP can be the CORESET with index 0 for the RedCap UE or CORESET with index x for the RedCap UE, where x>0. The definition of the ※additional§ CORESET in the separate initial DL BWP should be clarified. Sharp Y If separate initial DL BWP during initial access is applied (either offloading purpose and/or center frequency alignment purpose), the additional CORESET should be allocated within the initial DL BWP for RedCap Ues. If not (i.e. common initial DL BWP is applied), the necessity of the additional CORESET for offloading purpose needs to be further discussed. CATT Need FFS If the additional CORESET is introduced along with the ＆new＊ initial DL BWP, it has the same drawback as the ＆new＊ initial DL BWP (e.g. not able to solve congestion or not able to include SSB). If the additional CORESET is introduced in the legacy initial DL BWP, then it does not help offloading due to occupation of DL resource from the legacy initial DL BWP. Fujitsu Y We agree that having an additional CORESET for scheduling of Msg2/Msg4/Paging messages/SI can be beneficial for congestion mitigation and offloading purposes. Samsung Y Maybe we can first clarify that, if a separated initial DL BWP is configured for RedCap UE, whether the CORESET on the initial DL BWP for Redcap is treated as the ※additional CORESET§ here. In our opinion, if the dedicated initial DL BWP for RedCap is configured, additional CORESET will be configured accordingly. If dedicated initial DL BWP is not configured, we are also see the benefit to configure additional CORESET for Msg 2/4/paging/SI. Which can be used for traffic offloading, different from non-Redcap UE(if needed, e.g., together with separated Ros) IDCC Y Additional CORESET can be useful for offloading purposes. Nokia, NSB We currently do not see strong need to have an additional CORESET for Msg2/Msg4/Paging/SI. This also follows our view that a separate MIB-configured initial DL BWP does not seem necessary for RedCap UE. CMCC Share similar views with vivo and Sharp. LG Y We share a similar view with other companies in that the additional CORESET can be useful for offloading purpose and if a separate initial DL BWP can be configured, then a separate CORESET can also be configured. So, our answer is Yes for this question. Whether the separate or additional CORESET can also be configured within the initial DL BWP shared with non-RedCap UE and how we call it can be further discussed as a next step. Ericsson Y According to the Rel-15 specifications, it is already possible to configure additional CORESETs for initial access, but with the limitation that the additional CORESET needs to be within the bandwidth of CORESET #0 and this does not considerably help in increasing the scheduling capacity. In fact, given the limited size of CORESET #0 (i.e., at most 48 CCEs), the PDCCH capacity can be limited when there is a need for scheduling many Ues. An additional CORESET which can help offloading DL transmissions during initial access when CORESET #0 becomes congested. Such potential additional CORESET should not be confined within the bandwidth of CORESET #0 (i.e., the new CORESET should be partially or fully non-overlapping with CORESET #0 in the frequency domain). FUTUREWEI N We did not agree on offloading. The traffic we evaluated in the study was not ※massive§. Intel Relationship to Proposal 2.1-2 needs to be clarified first as they seem to overlap in terms of motivation as well as the solution itself. FL2 Please continue to discuss the following question, taking the responses above into account. High Priority Question 2.3-1: * Should the possibility to configure an additional CORESET for scheduling of Msg2 and/or Msg4 and/or Paging and/or SI for RedCap Ues be supported? Please provide a motivation for your answer. Qualcomm Y (Recap) We support an additional CORESET for RedCap Ues because: * When the channel BW is wider than the max BW of RedCap UE, such configuration helps with traffic offloading and co-existence of different UE types * It helps with center frequency alignment of initial DL BWP and initial UL BWP in TDD bands, which can avoid the undue spec impacts in RAN1/RAN2/RAN4, timeline changes, and potential increase of UE complexity and power consumption. * An non-cell-defining SSB (for non-RedCap Ues) can be jointly configured with this CORESET to simplify the RRM/RLM measurements of RedCap Ues and non-RedCap Ues (when the intial DL BWP of RedCap Ues are partially overlapping with RedCap UE＊s active DL BWPs). DOCOMO Y At least when separate initial DL BWP is configured for RedCap Ues, additional CORESET should be configured accordingly. We are open to further discuss whether it should be supported or not when shared initial DL BWP is configured for RedCap Ues. Vivo Y The answer depends on whether separate initial DL BWP is configured for redcap Ues. ? If seperate initial DL BWP is configured for redcap Ues, it is natrual that additional CORESET(s) for broadcast channel scheduling should be configured. The motivation is to achieve offloading and center frequency alignment between initial DL BWP and initial UL BWP for redcap Ues in TDD. ? If redcap Ues share the same initial DL BWP as for non-redcap Ues, we do not see strong motivation to configure additional CORESET(s) for or broadcast channel scheduling for redcap Ues. Xiaomi Partially Y ? The configuration of additional CORESET for scheduling Msg.2/Msg.4/Paging/SI depends on the configuration additional initial DL BWP. Furthermore, separate initial DL BWP for Redcap can be considered during initial access and after initial access due to different motivations, so these two cases should be handled separately. - If separate initial DL BWP used during initial access is configured then additional CORESET is needed at least for scheduling of Msg.2 and Msg.4. Otherwise, the existing CORESET#0 can be reused during the initial access . - If separate initial DL BWP used after initial access is configured and the additional initial DL BWP does not contain the MIB-configured CORESET#0, then additional CORESET for scheduling Msg.2/Msg.4/paging/SI can be reused. Otherwise, the existing CORESET#0 can be reused LG Y We share a similar view with other companies in that the additional CORESET can be useful for offloading purpose and if a separate initial DL BWP can be configured, then a separate CORESET can also be configured. Whether the separate or additional CORESET can also be configured within the initial DL BWP shared with non-RedCap UE can be further discussed as a next step. Huawei, HiSi FFS Similar comments as previously indicated in 2.1-2a CMCC Y Additional CORESET within separate initial DL BWP for RedCap Ues is beneficial for offloading and coexistence with non-RedCap Ues. If RedCap Ues share the same initial DL BWP as for non-RedCap Ues, additional CORESET can be associated with dedicated search spaces for RedCap Ues in SIB1. Panasonic Y As companies propose, we think it is needed to configure additional CORESET at least within separate initial DL BWP if configured. Whether to support additional CORESET within the shared initial DL BWP can be discussed further although we don＊t see the strong motivation now. NordicSemi Y Agree with QC assessment. Support of initial DL BWP not overlapping with MIB-CORESET#0 in SIB1 provides good flexibility for gNB and does not need extra capability at UE side. This is win-win situation for UE and Infra. OPPO Y The motivations are: 1) Offloading 2) align central frequencies of DL/UL initial BWP. Samsung Y Similar comments as before. Spreadtrum We are not clear about the definition of additional CORESET for the RedCap UE. - If the RedCap UE is configured with the shared initial DL BWP (no wider than the RedCap UE bandwidth), the additional CORESET (by the existing IE commonControlResourceSet) can be used by the RedCap UE. - If the RedCap UE is configured with the separate initial DL BWP, * If the separate initial DL BWP contains CORESET#0, the additional CORESET (by the existing IE commonControlResourceSet) can be used by the RedCap UE. * If the separate initial DL BWP does not contain CORESET#0, we are not sure whether the ※additional§ CORESET in the separate initial DL BWP can be a new CORESET with index 0 for the RedCap UE or a new CORESET with index x for the RedCap UE, where x>0. The definition of the ※additional§ CORESET in the separate initial DL BWP should be clarified firstly. Sharp Y Same view with other companies. If a separated initial DL BWP is configured, additional CORESET should be allocated in the separate initial DL BWP. Lenovo, Motorola Mobility Y Additional CORESET is configured at least for the case where a dedicated initial DL BWP is configured and used during initial access. CATT If the additional CORESET is introduced along with the ＆new＊ initial DL BWP, we should wait for more progress in Proposal 2.1-2. If the additional CORESET is introduced in the legacy initial DL BWP, then it does not help offloading due to occupation of DL resource from the legacy initial DL BWP. ZTE, Sanechips Y ? For scheduling of Msg2/Msg4, the key motivation is for offloading and reducing the negative impact on non-RedCap Ues. ? For scheduling of paging, the key motivation is for UE＊s power saving and reducing the negative impact on scheduling of Msg2/Msg4/Paging of legacy NR Ues caused by 1 Rx RedCap Ues. Nokia, NSB We currently do not see strong need to have an additional CORESET for Msg2/Msg4/Paging/SI. This also follows our view that a separate initial DL BWP during initial access does not seem necessary for RedCap UE. Ericsson Y FUTUERWEI2 N Similar comments as before FL3 The FL suggestion is to come back to this question (about possibility to configure an additional CORESET for scheduling of Msg2 and/or Msg4 and/or Paging and/or SI for RedCap Ues) after the proposals in Section 2.1 have seen some further progress. Intel If this case is left open, then the intention of High Priority Proposal 2.1-2b needs further clarification as indicated there 每 specifically, is the UE expected to use the locationAndBandwidth parameter for the proposal in High Priority Proposal 2.1-2b before RRC connection establishment? Qualcomm Agree with the comments of Intel above. If an initial DL BWP is separately configured for RedCap UE and CORESET#0 is not fully confined within this initial DL BWP, additional CORESET for scheduling of Msg2 and/or Msg4 and/or Paging and/or SI for RedCap Ues should be configured as well within this initial DL BWP. Vivo As commented before, we think the separate initial DL BWP for Redcap Ues should be applicable before RRC connection. And additional CORESET(s) for scheduling of Msg2 and/or Msg4 and/or Paging and/or SI for RedCap Ues should be configured on the Redcap initial DL BWP. FUTUREWEI Agree to come back later In addition, there are a few more detailed proposals related to the additional CORESET, if introduced: * Contributions [3, 20] argue that in the frequency domain, the additional CORESET should be non-overlapping (partially or fully) with CORESET #0. * Contribution [3] suggests that the additional CORESET can be defined within the RedCap initial DL BWP and used for offloading Msg2, Msg4, paging and SI (other than SIB1) message transmissions, while CORESET #0 is used for scheduling SIB1. * Contribution [16] comments that an additional CORESET can be beneficial for offloading paging and/or random access for RedCap Ues, but since the same SI messages are expected to be shared between RedCap and non-RedCap Ues, it may not be as beneficial to offload SI messages (RMSI, OSI) to an additional BWP. FL3 Medium Priority Question 2.3-2: * In case RAN1 would introduce a possibility to configure an additional CORESET for offloading purposes for RedCap Ues, what are your views on the following aspects? a) The position/configuration of such new CORESET b) The messages/transmissions which can or cannot be offloaded on this CORESET Company Comments Spreadtrum a) Confined in the separate initial DL BWP b) Paging, SIB1 and Msg2/4 vivo a) The new CORESET is configured along with the seperate initial DL BWP for Redcap Ues, by SIB b) Most of the broadcast channels can be considered, such as paging, SIB, MSG2/4, etc. Samsung a) If separated initial DL BWP is introduced, the freq location can be in the separated initial DL BWP, and the additional CORESET(s) should be configured together with the separated initial DL BWP. Even if initial DL BWP is shared with non-Redcap Ues, we think this could also be helpful. The time location can be outside of CORESET #0 location for offloading purpose. Besides, if separated PRACH resource is configured for Redcap UE from non-RedCap Ues, at least separated CORESET(s) for RAR/Msg 3 retx/ msg 4, can be configured as part of separated RACH resource. b) Paging, other SIBs than SIB 1, Msg 2/msg 3 retx/msg 4. FFS for SIB 1. ZTE a) Confined in the separate initial DL BWP b) Msg2/4 and Paging can be considered but SIB1 cannot be considered. Intel Here, we assume that the proposal is about Idle/inactive modes. If this is correct, then better to clarify. a) Additional CORESET, if provided, should be part of a separate initial DL BWP configuration 每 §separate§ from the initial DL BWP defined by CORESET #0 indicated by MIB. b) Can be offloaded: i. Paging, RA-related DL control and shared channels. ii. FFS: SIB, including SIB1, and SSB (it is preferred to avoid duplication of SIB and SSB). Qualcomm If an additional CORESET is configured for RedCap UE, it should be fully confined within the initial DL BWP separately configured for RedCap UE. Regarding the messages/transmissions that can be offloaded to this CORESET (and the separately configured initial DL BW), we think they can include at least: * paging, OSI, RAR, contention resolution message, and other RRC messages for 4-step RACH (and 2-step RACH, if supported) * PDCCH and PDSCH for SDT (if SDT is supported) * SSB (and CSI-RS/TRS) for tracking loops and RRM measurement o Note: It is necessary to include SSB within this initial DL BWP separately configured for RedCap UE. Otherwise, RedCap UE has to support FG 6-1a as a mandatory UE feature. The SSB can be transmitted off the sync raster, which can be re-used by non-RedCap Ues for measurements. 3 Initial UL BWP 3.1 General RAN1#104bis-e made the following agreements related to initial UL BWP [2]: Agreements: * During initial access, for the scenario where the initial UL BWP for non-RedCap Ues is configured to be wider than the RedCap UE bandwidth, down select among the following options in RAN1#105-e o Option 1: The scenario is allowed, and a RedCap UE can use the same UL BWP. o Option 2: The scenario is allowed, but a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap Ues. o Option 3: The scenario is not allowed, and a RedCap UE is not expected to operate in an initial UL BWP wider than the RedCap UE maximum bandwidth. Agreements: * After initial access, for the scenario where the initial UL BWP for non-RedCap Ues is configured to be wider than the RedCap UE bandwidth, down select among the following options in RAN1#105-e: o Option 1: The scenario is allowed, and a RedCap UE can use the same UL BWP. o Option 2: The scenario is allowed, but a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap Ues. o Option 3: The scenario is not allowed, and a RedCap UE is not expected to operate in an initial UL BWP wider than the RedCap UE maximum bandwidth. Almost all contributions listed in the references discuss the options of initial UL BWP according to the above-mentioned agreements. In the consideration of preferred or acceptable options, all the sources also consider the related issues of RACH occasions and PUCCH/PUSCH transmissions during initial access. Many contributions identify important issues and foreseeable impacts concerning each of these options. These aspects can be further considered. Option 1: The scenario is allowed, and a RedCap UE can use the same UL BWP * Specification impact (e.g. RF-retuning delay, PUCCH/Msg3 design, allowing configuring a BWP wider than the UE BW) [3, 4, 8, 9, 20, 22, 24, 27] * Negative impact on UE power consumption and/or complexity [9, 11, 12, 13, 24, 25] * Reduce the demodulation performance of PUCCH and/or PUSCH [10, 18] * Introducing complexity at the network [9] * Reduced throughput due to BWP switching delay [29] * Early identification is desired to avoid multiplexing RedCap Ues and non-RedCap Ues on the same [10] * UL resource wastage due to RF retuning [16] * The feasibility and the impact on the UL/DL switching time should be studied if the centre frequency of the UL resource is different from the centre frequency of DL BWP [22] * Scheduling of Msg1/Msg2/Msg3/Msg4 needs to take into account the delay necessary for RF retuning [27] Option 2: The scenario is allowed, but a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap Ues * PUSCH resoure fragmentation [3, 20, 24, 27, 32] * May lead to signaling overhead in SIB1. New SIB information is needed [17, 20, 24] * Some resource utilization efficiency loss since normal UE and RedCap devices may not share certain channels or resources [22] * PRACH resource fragmentation due to a rigid split between RedCap and non-RedCap resources [27] * Should avoid specifying multiple initial UL BWPs for RedCap UE and allowing BWP switching during initial access will increase the signaling overhead of NW, complexity of UE, and the spec impacts of RAN1/RAN2/RAN4 [11] Option 3: The scenario is not allowed, and a RedCap UE is not expected to operate in an initial UL BWP wider than the RedCap UE maximum bandwidth * Too restricted with reduced flexibility on the network, which might lead to negative impact on non-RedCap Ues [3, 6, 8, 10, 12, 13, 14, 20, 22, 24, 25, 27, 29] * PUSCH resource fragmentation [3, 32] * The performance of RedCap Ues may be impacted [29] When all the aspects are considered, the proposals from the submitted contributions are summarized as follows. * A majority of the contributions prefer Option 2 for both during and after initial access [5, 6, 7, 8, 10, 12, 13, 14, 17, 18, 19, 21, 22, 23, 24, 25, 28, 29]. * Contribution [8] prefers Option 2 but can also accept Option 1. * Contributions [3, 20, 27, 32] consider both Options 1 and 2 for further discussion. * Contribution [31] prefers Option 1. * Contributions [9, 16] prefer Option 3 but can also accept Option 2. * Contribution [4] proposes to down select between Options 2 and 3. As summarized above, among the contributions that prefer or include Option 3, most can also accept Option 2. Furthermore, many contributions express concerns with the impact on non-RedCap Ues from Option 3 [3, 6, 8, 10, 12, 13, 14, 20, 22, 24, 25, 27, 29]. Thus, it seems that it might be possible to agree to the FL proposal below. FL1 High Priority Proposal 3.1-1: * Both during and after initial access, the scenario where the initial UL BWP for non-RedCap Ues is configured to be wider than the RedCap UE bandwidth is allowed. Company Y/N Comments Huawei, HiSi Y Qualcomm Y partially Please clarify if the ※RedCap UE bandwidth§ means max BW of RedCap UE. Xiaomi Y ZTE, Sanechips Y vivo N The proposal cannot be agreed without the solution on how to achieve it. Given the majority companies support option 2, we would like to modify the proposal as Both during and after initial access, the scenario where the initial UL BWP for non-RedCap Ues is configured to be wider than the RedCap UE bandwidth is allowed by configuring/defining a separate initial UL BWP for RedCap Ues that is no wider than the RedCap UE maximum bandwidth. Or Proposal 3.1-1 is not needed if Proposal 3.1-2 below is agreed. So we can directly discuss the proposal 3.1-2. OPPO Y NordicSemi Y QC clarification would make proposal more precise Spreadtrum Y We support the FL proposal, but we have great concern on Option 1. We support Option 2. Sharp Y No impact on the flexibility of initial DL BWP for non-RedCap Ues should be expected NEC Y CATT Y We think this proposal does not mean the initial UL BWP for non-RedCap UE (larger than maximum RedCap UE bandwidth) is used by RedCap Ues. Fujitsu Y Samsung Y IDCC Y Nokia, NSB We support Option 3 but would be OK with this proposal if Option 2 is selected and is part of the proposal. Therefore we support Vivo＊s suggestion. CMCC Y We support Option 2. LG Y We are okay to agreeing on this first and then discuss how to deal with the scenario as a next step as suggested below. Ericsson Y This is essential to avoid negative impacts on non-RedCap Ues while coexisting with RedCap Ues. FUTUREWEI N Agree with Qualcomm＊s comment about the clarification Note that there is minor specification impact for initial access using Option 3. Considering option 2, there are a number of solutions possible with some solutions requiring significant specification work. We should strive for solutions with the least impact to specification and maximize resource sharing (as possible with options 2 and 3). Intel Same view as Nokia. Option 3 is sufficient and preferred but if companies strongly feel about this restriction, we can consider the proposal if clarified with Option 2 as suggested by Vivo. FL2 Based on received responses, the following updated proposal can be considered, where it has been clarified that the RedCap UE bandwidth is the maximum RedCap UE bandwidth. Some responses suggest doing further down selection (to Option 2). This is considered in Proposal 3.1-2. High Priority Proposal 3.1-1a: * Both during and after initial access, the scenario where the initial UL BWP for non-RedCap Ues is configured to be wider than the maximum RedCap UE bandwidth is allowed. Qualcomm Y Thanks for the update of FL. DOCOMO Y vivo We prefer to combine Proposal 3.1-1a and Proposal 3.1-2a and try to agree with them together as a package. We do not want to agree to Proposal 3.1-1a alone without an agreement on Proposal 3.1-2a China Telecom We agree with vivo, and prefer to combine Proposal 3.1-1a and Proposal 3.1-2a. Xiaomi Y LG Y Huawei, HiSi Y CMCC Y Panasonic Y TCL Y NordicSemi Y OPPO Y Samsung Y Spreadtrum Y Sharp Y NEC Y Lenovo, Motorola Mobility Y CATT Y ZTE, Sanechips Y Nokia, NSB Same view as before that we prefer this proposal to be considered together with 3.1-2a. Ericsson Y We agree with the FL proposal. This is essential to avoid negative impacts on non-RedCap Ues while coexisting with RedCap Ues. Also, as pointed out by CATT, it does not necessarily mean that the initial UL BWP for non-RedCap UE (larger than maximum RedCap UE bandwidth) is used by RedCap Ues. FUTUREWEI2 N Thanks for the clarification about the BW. Further clarification is needed: is this proposal discussing option 2 or can RedCap BWP be larger than the BW of the RedCap UE? Text similar to vivo＊s suggestions should be added to the proposal. FL3 Based on received responses, Proposal 3.1-1a and Proposal 3.1-2a have been combined into Proposal 3.1-2b below. Furthermore, considering the strong support for Option 2, a possible way forward is to consider agreeing to Option 2 as a working assumption and aim to address the main issues identified for Option 2. To that end, many contributions identify the problem of PUSCH resource fragmentation [3, 5, 24, 26, 27, 32], and contributions [3, 5, 16, 32] consider the following possible solutions: * The narrower initial UL BWP for RedCap UE may be configured at an edge of the UL carrier, thereby minimizing impact from UL resource fragmentation. [3, 16, 32] * RF retuning may occur between uplink transmission and downlink reception in TDD for RedCap Ues. [3, 5, 32] * Disable frequency hopping for Msg4 PUCCH. [3, 32] * A RedCap BWP can be configured with multiple locations (start PRB). [5] o BWP retuning occurs among different locations (start PRB). o A RedCap BWP can be configured with multiple locations (start PRB). BWP retuning occurs among different locations associated to the same RedCap BWP (index). FL1 High Priority Proposal 3.1-2: * Working assumption: Both during and after initial access, for the scenario where the initial UL BWP for non-RedCap Ues is configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap Ues. o The specifications shall ensure coexistence with non-RedCap Ues (e.g. avoiding or minimizing PUSCH resource fragmentation), if a separate initial UL BWP for RedCap Ues is configured. Company Y/N Comments Huawei, HiSi Y and ※coexistence with non-RedCap Ues§ is already in the WID. We think a step forward could be: o The specifications shall ensure coexistence with non-RedCap Ues (e.g. avoiding or minimizing PUSCH resource fragmentation), if a separate initial UL BWP for RedCap Ues is configured, Strive for a mean to avoid or minimize the PUSCH resource fragmentation for the above case. Qualcomm Y partially Before the introduction of RedCap Ues, we think the PUSCH/msg3 resource fragmentation issues already exist in NR R15/R16. To name a few, 1) FG 2-7 in TR 38.822 specifies the support of ※almost contiguous UL CP-OFDM,§ which suggests the FDRA is not always continuous on UL. 2) NR R16 introduces 2-step RACH for RRC idle/inactive Ues. The resources for msgA PUSCH are configured by SIB1 within the initial UL BWP of non-RedCap UE. Intra-slot FH can be enabled for msgA PUSCH transmission. It is up to NW configuration to avoid/mitigate the potential collisions among msgA PUSCH, msg3, and PUCCH for HARQ feedback of msg4/msgB. 3) Periodic PRACH occasions are configured for CBRA/CFRA of non-RedCap UE within its initial UL BWP. It is up to NW configuration to avoid/mitigate the potential resource fragmentation incurred by PRACH transmission. 4) Co-existence of non-RedCap Ues with different active UL BWP configurations. Having said that, we think the initial UL BWP configuration for RedCap Ues should take into account the solutions capable by NW and the practical constraints of RedCap Ues (complexity, power consumption) to minimize further resource fragmentation for PUSCH. Xiaomi Y and Considering there is possibility that the newly configured initial UL BWP may have different centre frequency compared with the MIB-configured initial DL BWP, which will break the requirement of same center frequency in BWP pair in TDD system, we think another sub-bullet should be added * Working assumption: Both during and after initial access, for the scenario where the initial UL BWP for non-RedCap Ues is configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap Ues. o The specifications shall ensure coexistence with non-RedCap Ues (e.g. avoiding or minimizing PUSCH resource fragmentation), if a separate initial UL BWP for RedCap Ues is configured. o The specification shall ensure the same center frequency in the initial BWP pair in TDD system ZTE, Sanechips Y vivo Y Huawei＊s modification above is also fine for us. OPPO Y and 1) We agree with Qualcomm frequency fragementation is already there. In addition to the cases listed by Qualcomm, NR supports BWP fremework which will unavoidably introduce frequency fragementation if the configured BWP is narrower than the carrier bandwidth. We agree with Xiaomi that it shall ensure the same central frequency in the initial BWP pair for TDD. NordicSemi Y We agree that some solution to resource fragmentation is needed, but low complexity solutions should be preferred over others. For example, as /// proposed, possibility to remove intra-slot hopping for RedCap Ues in their BWP is one simple and straightforward solution to address this. Spreadtrum Y Regarding UL resource fragmentation, we think it is not so critical. During initial access, - For Msg.1, if early indication is supported in Msg.1, resource fragmentation of Msg.1 is present for both the shared initial UL BWP and the separate initial UL BWP; if early indication is not supported in Msg.1, resource of Msg.1 for the separate initial UL BWP can be configured without overlapping with that of the initial UL BWP for the non-RedCap UE. - For Msg.3, gNB can dynamically schedule PUSCH to fully utilize the UL resource for both the shared initial UL BWP and the separate initial UL BWP. - For PUCCH of Msg.4, gNB can dynamically schedule PUSCH to avoid the collision with PUCCH of Msg.4. After initial access, resource sharing across different BWPs is natural function for gNB implementation, e.g. eMBB and URLLC, and thus resource sharing b/w eMBB and eMTC should be also supported later or sooner. Therefore, it is up to gNB implementation to efficiently mitigate UL resource fragmentation. Sharp Y Same view with NordicSemi NEC Y CATT Y, mostly Since separate initial UL BWP will have impact on RACH resource sharing between non-RedCap UE and RedCap UE, in the sub-bullet, it should identify ＆possible RACH resource sharing between RedCap UE and non-RedCap UE＊ as an example in the ＆e.g.＊ bracket. Fujitsu Y Samsung Y OK with HUAWEI＊s proposal IDCC Y Nokia, NSB Y Also agree with Huawei＊s suggestion as in our view there is no coexistence issue even if there is PUSCH resource fragmentation, but of course it would be good to minimize such fragmentation when possible. CMCC Y OK with HUAWEI＊s proposal LG Y We support the main bullet. For the coexistence issues, especially for the PUSCH resource fragmentation, we also agree that minimizing such fragmentation is useful, but we also would like to be open for the solution that rely on network implementation/configuration. So, any strong wording in the sub-bullet is not preferred. Huawei＊s wording is fine for us. Ericsson Y We are also fine with Huawei＊s revision. FUTUREWEI Y Resource fragmentation is present in NR Rel-15 and Rel-16, as Qualcomm mentioned. Reusing existing solutions for PUCCH resource fragmentation is preferred first but low complexity solutions can be considered if existing solutions prove to be inadequate. The proposal should focus ONLY on the PUCCH resource fragmentation as a design principle or FFS. Intel Y (conditionally) Can accept with the removal of the FFS. We agree with QC and others that PUSCH fragmentation is nothing new in NR. While we can always strive to minimize impact from PUSCH fragmentation, there is no need to mandate spec-based solution at this point. FL2 Based on received responses, the following updated proposal can be considered, where only the sub-bullets have been changed. One response brought up possible RACH resource sharing between RedCap UE and non-RedCap UE as an example of a coexistence issue. This aspect can be brought up in connection to the aspects treated in Section 3.2. Two responses proposed that the specification shall ensure the same centre frequency for initial DL and UL BWPs in TDD. The FL proposal is that this proposal is further discussed and captured with an FFS in the updated proposal. This aspect should also be discussed for the non-initial BWPs in Section 4. High Priority Proposal 3.1-2a: * Working assumption: Both during and after initial access, for the scenario where the initial UL BWP for non-RedCap Ues is configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap Ues. o Strive for a mean to avoid or minimize the PUSCH resource fragmentation due to PUCCH transmission for the above case. o It is FFS whether/when the centre frequencies for initial DL and UL BWPs can be different in TDD. Qualcomm The updated proposal seems to prioritize resource fragmentation over the change of existing BWP operation/mechanism (FFS item). We think the centre frequencies for initial DL and UL BWPs should be aligned in TDD to avoid the undue spec impacts in RAN1/RAN2/RAN4, timeline changes, and potential increase of UE complexity and power consumption. DOCOMO Y vivo We are not fine with open the discussion on different centre frequencies between DL and UL BWPs for redcap Ues, we should conclude that the same principle as in Rel-15/16 is reused here, i.e. the same centre frequency is kept between DL and UL. China Telecom Y We are fine to keep it as FFS. The spec impacts for other WG RAN groups should be taken into consideration when trying to make consensus on the FFS. Xiaomi Same view with QC and vivo. The center frequency should be kept the same between DL BWP and UL BWP in TDD system. So, we suggest to update the second bullet as follow o The specification shall ensure the same center frequency in the initial BWP pair in TDD system LG Y If the first sub-bullet feels a bit strong for some companies, then we are also fine to put FFS for the first sub-bullet. Huawei, HiSi Y And also fine without FFS. CMCC We think the centre frequencies for initial DL and UL BWPs should be aligned in TDD to avoid the spec impacts such as BWP switching. Panasonic Y TCL Y NordicSemi Y, but It should be common understanding that R15/R16 behaviour is baseline, and FFS is whether R15/R16 TDD can be relaxed. OPPO Share similar views with Qualcomm, vivo, xiaomi and CMCC, the same principle as in Rel-15/16 is reused here, i.e. the same centre frequency shall be kept between DL and UL. Samsung Y Spreadtrum Y Sharp Y NEC Y Same view as LG. Lenovo, Motorola Mobility Y CATT Y ZTE, Sanechips Y Nokia, NSB Y Ericsson Y A few comments made a point that resource fragmentation is present in NR Rel-15 and Rel-16. We do agree that certain network configuration choices do result in PUSCH resource fragmentation in a Rel-15/16 network. However, a key point we want to make is that it is possible for an operator to avoid PUSCH resource fragmentation in a Rel-15/16 network if the operator carefully configures the BWP parameters and carefully choose the feature set it enables. We stress that it is of great importance for the RedCap WI to ensure the operators to continue to have the possibility of avoiding PUSCH resource fragmentation when the support of RedCap devices is enabled in the network. Otherwise, we see a great risk of RedCap being a feature that an operator may leave out on most carriers due to the consideration of PUSCH resource fragmentation. FUTUREWEI2 Y The first sub-bullet is a design goal, not really a requirement. For the second sub-bullet, because the specification impact to other WGs may be large, no changes to the baseline Rel. 15/16 behavior are necessary. FL3 Based on received responses, Proposal 3.1-1a and Proposal 3.1-2a have been combined into the following updated proposal, where the only changes are in the sub-bullets. High Priority Proposal 3.1-2b: * Both during and after initial access, the scenario where the initial UL BWP for non-RedCap Ues is configured to be wider than the maximum RedCap UE bandwidth is allowed. * Working assumption: Both during and after initial access, for the scenario where the initial UL BWP for non-RedCap Ues is configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap Ues. o FFS: how to avoid or minimize PUSCH resource fragmentation due to PUCCH transmission for the above case o FFS: how to avoid or minimize centre frequency retuning between initial DL and UL BWPs in TDD Intel Y Qualcomm We can live with this proposal and suggest to revise the second FFS item as: FFS: how to avoid or minimize centre frequency retuning between initial DL and initial UL BWPs in TDD Ericsson Y vivo Modification needed We are generally fine with the combined proposal, but suggest to revise the last FFS bullet as below * Both during and after initial access, the scenario where the initial UL BWP for non-RedCap Ues is configured to be wider than the maximum RedCap UE bandwidth is allowed. * Working assumption: Both during and after initial access, for the scenario where the initial UL BWP for non-RedCap Ues is configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap Ues. o FFS: how to avoid or minimize PUSCH resource fragmentation due to PUCCH transmission for the above case o FFS: how to avoid or minimize keep the same centre frequency retuning between initial DL and UL BWPs in TDD China Telecom Y FUTUREWEI3 Y Panasonic Y Another FFS (identified in RAN1#104-e) is whether the SIB-configured initial UL BWP for RedCap Ues can also be configured to be different from the SIB-configured initial UL BWP for non-RedCap Ues Agreements: * FFS whether or not to further introduce the following (e.g., for offloading purpose, for differentiation of RedCap vs. non RedCap Ues, for different BWP#0 configuration options, etc.) o Whether an additional CORESET can be configured for scheduling of RACH (msg2 & msg4)/Paging/SI messages for RedCap Ues o Whether the SIB-configured initial DL BWP for RedCap Ues can also be configured to be different from the SIB-configured initial DL BWP for non-RedCap Ues. o Whether the SIB-configured initial UL BWP for RedCap Ues can also be configured to be different from the SIB-configured initial UL BWP for non-RedCap Ues. Contribution [16] proposes that a separate initial UL BWP for RedCap can be considered even if the bandwidth of the initial UL BWP for non-RedCap does not exceed the maximum RedCap UE bandwidth. FL3 Medium Priority Question 3.2-3: * Should configuration of a SIB-configured initial UL BWP for RedCap Ues different from the SIB-configured initial UL BWP for non-RedCap Ues be supported even in case the bandwidth of the initial UL BWP for non-RedCap does not exceed the maximum RedCap UE bandwidth? Company Y/N Comments Spreadtrum Y If the separate initial UL BWP is supported in the scenario where the initial UL BWP for the non-RedCap UE is wider than the RedCap UE bandwidth. It can be naturally extended to the scenario where the initial UL BWP for the non-RedCap UE is no wider than the RedCap UE bandwidth. Fujitsu Y Agree a separate configuration of SIB based initial UL BWP for RedCap Ues can be a way for the purpose of offloading as well as differentiation of RedCap vs. non_RedCap Ues. Vivo Y If separate initial BWP for redcap is supported by specification, it is up to network configuration how to use it (e.g. for offloading purposes) and does not needs to be coupled with initial BWP size that has been configured for non-redcap Ues. Samsung Y If SIB-configured separated UL BWP for RedCap is supported, we don＊t see the reason to forbidden gNB to configured another UL BWP for RedCap UE. ZTE, Sanechips Y At least can be used for early identification of RedCap Intel Y This should be allowed 每 for instance, this can offer the cleanest option to support early indication of RedCap UE during Msg1 transmission. Qualcomm When the bandwidth of the initial UL BWP for non-RedCap UE does not exceed the maximum RedCap UE bandwidth, we don＊t see a strong motivation to configure a separate initial UL BWP for RedCap UE. However, we don＊t object to the proposal supporting separate initial UL BWP configuration in this scenario if that is the majority view of other companies. 3.2 RACH occasions RAN1#104-e made the following agreements related to RACH occasions: Agreements: * Study further how to enable/support that a RACH occasion associated with the best SSB falls within the RedCap UE bandwidth, with the following options: o Option 1: Proper RF-retuning for RedCap o Option 2: Separate initial UL BWP(s) for RedCap Ues o Option 3: gNB configuration (e.g., restrictions on existing PRACH configurations, or FDM-ed Ros, or always restricting the initial UL BWP to within RedCap UE bandwidth) o Option 4: Dedicated PRACH configurations (e.g., Ros) for RedCap Ues o Other options are not precluded Many contributions listed in the references discuss the options listed in the above-mentioned agreement. Many contributions identify important issues and foreseeable impacts concerning each of these options. A summary is given below. Additionally, many of the issues summarized in Section 3.1 are also relevant and should also be considered. Option 1: Proper RF-retuning for RedCap * Need longer time between PRACH and RAR (Msg2) [3, 13, 21, 26] * Negative impact on UE power consumption and complexity [11, 12] * For TDD operation, it would be needed that the centre frequency between DL and UL BWP is different. It requires the discussion whether it is allowed for the RedCap [25] * Need different interpretation of PRACH transmission or adjustment of initial UL BWP [26] Option 2: Separate initial UL BWP(s) for RedCap Ues * Resource fragmentation [3, 8, 32] * SIB1 related issues such as need additional indication (either implicitly or explicitly), heavier payload in SIB1, higher overhead, and specs impact [3, 8, 25, 26] * Whether there is one common initial UL BWP for all RedCap Ues or multiple ones [13, 21] * The initial UL BWP and the initial DL BWP may have different central frequencies for TDD [3, 13, 26, 32] * Whether dedicated PRACH configurations (e.g., Ros) for RedCap Ues can be configured [21, 28] * Increased gNB processing for PRACH [3] * Maintenance of two different initial UL BWPs [8] Option 3: gNB configuration (e.g., restrictions on existing PRACH configurations, or FDM-ed Ros, or always restricting the initial UL BWP to within RedCap UE bandwidth) * Negative impact on the non-RedCap UE. May increase random access collision [5, 7, 8, 12, 13, 26, 28] Option 4: Dedicated PRACH configurations (e.g., Ros) for RedCap Ues * This option consumes additional uplink resources and the resource utilization efficiency may degrade since Redcap UE and legacy UE cannot share the same PRACH resources. For popular TDD configuration such as DDDSU, this additional cost is non-negligible [8, 13] * Cannot fully resolve the issue [5] * Less flexible than Option 2 [7] * May complicate gNB＊s resource allocation [3, 13] * Increase the overhead and gNB PRACH processing load [3] * gNB would always configure dedicated Ros even for a very small number of RedCap Ues [3] * Need additional indication (either implicitly or explicitly) [26] * Separate PRACH configurations for RedCap Ues can be supported by specification regardless whether where the bandwidth of initial UL BWP for non-RedCap Ues is no wider than the maximum RedCap UE bandwidth [21] In addition to the above 4 options, two new options are mentioned. * Separate initial UL BWP with multiple locations (start PRB) for RedCap Ues can well enable/support that a RACH occasion associated with the best SSB falls within the RedCap UE bandwidth [5] * Whether the associated RO is within the UE bandwidth is a consideration for SSB selection. Whether the associated RO is within the UE bandwidth is a consideration for RO selection [15] Considering these options are coupled with the options for the initial UL BWP, the FL suggests we come back to the down-selection of these options after the down-selection of the options for the initial UL BWP. 3.3 PUCCH/PUSCH during initial access RAN1#104-e made the following agreements related to PUCCH/PUSCH during initial access: Agreements: * Study further whether and how to enable/support that PUCCH (for Msg4/[MsgB] HARQ feedback) and/or PUSCH (for Msg3/[MsgA]) transmissions fall within the RedCap UE bandwidth during initial access, with the following options: o Option 1: Proper RF-retuning for RedCap (if feasible) o Option 2: Separate initial UL BWP(s) for RedCap * FFS more than one starting PRB position o Option 3: Separate PUCCH/Msg3/[MsgA] PUSCH configuration/indication or a different interpretation for the same configuration/indication for RedCap (e.g., disabled frequency hopping or different frequency hopping) o Option 4: gNB configuration (e.g., always restricting the initial UL BWP to within RedCap UE bandwidth, or restrictions on the frequency location and the amount of scheduled resource for Msg4/[MsgB] HARQ feedback and Msg3/[MsgA] PUSCH) * As an example, with restrictions on the frequency location and the amount of scheduled resource for Msg4/[MsgB] HARQ feedback and Msg3/[MsgA] PUSCH, when the initial UL BWP is the same for RedCap and non-RedCap Ues, the PUCCH (for Msg4/[MsgB] HARQ feedback) and PUSCH (for Msg3/[MsgA]) are within the RedCap UE bandwidth o Other options are not precluded Many contributions listed in the references discuss the options listed in the above-mentioned agreement. Many contributions identify important issues and foreseeable impacts concerning each of these options. A summary is given below. Option 1: Proper RF-retuning for RedCap (if feasible) * Impact on frequency hopping. May need longer time between 1st and 2nd hops, or may not be feasible [22, 26, 28] * Reduce the demodulation performance of PUSCH [10, 22] * Performance loss for PUCCH, especially for short duration PUCCH. PUCCH enhancements need to be introduced for RedCap Ues [3, 8, 10] * Negative impact on UE power consumption and complexity [11, 12] * The number of occasions of RF retuning is too large [7] * Early identification is desirable [10] * Need clarification regarding whether the fast frequency retuning capability is a reasonable assumption for (all) the RedCap Ues [21] * Issues foreseen when the RedCap Ues have to perform frequency hopping between two hops within a slot [21] * For TDD operation, it would be needed that the centre frequency between DL and UL BWP is different. It requires the discussion whether it is allowed for the RedCap [25] Option 2: Separate initial UL BWP(s) for RedCap * Resource fragmentation [3, 21, 26, 32] * SIB1 related issues such as need additional indication (either implicitly or explicitly), heavier payload in SIB1, higher overhead, and specs impact [8, 25, 26] * May require different center frequencies for initial UL BWP and DL BWP in TDD [3, 32] * Maintenance of two different initial UL BWPs [8] Option 3: Separate PUCCH/Msg3/[MsgA] PUSCH configuration/indication or a different interpretation for the same configuration/indication for RedCap (e.g., disabled frequency hopping or different frequency hopping) * Less flexible than Option 2 [7] * For PUCCH for Msg4, different configuration/indication/interpretation is needed [8] * Early identification is needed [10] * Specification impact [10, 12] * Need additional indication (either implicit or explicit) [26] * Fragmentation of PUSCH resources for non-RedCap Ues [26] * A new hopping pattern for RedCap Ues may be defined [28] Option 4: gNB configuration (e.g., always restricting the initial UL BWP to within RedCap UE bandwidth, or restrictions on the frequency location and the amount of scheduled resource for Msg4/[MsgB] HARQ feedback and Msg3/[MsgA] PUSCH) * Negative impact on the non-RedCap Ues. Limited configuration for non-RedCap Ues [7, 8, 12, 26, 28] * PUSCH resource fragmentation [3, 5, 32] * Decrease network capacity [5] Considering these options are coupled with the options for the initial UL BWP, the FL suggests we come back to the down-selection of these options after the down-selection of the options for the initial UL BWP. 4 Non-initial BWP For non-initial BWP operation, we have the following working assumption based on RAN1#104bis-e: Working assumption: * A RedCap UE cannot be configured with a non-initial (DL or UL) BWP (i.e., a BWP with a non-zero index) wider than the maximum bandwidth of the RedCap UE. o At least for FR1, FG 6-1 (※Basic BWP operation with restriction§ as described in TR 38.822) is used as a starting point for the RedCap UE type capability. Contributions generally agree with the main bullet in the working assumption stating that a RedCap UE cannot be configured with a non-initial (DL or UL) BWP wider than the maximum bandwidth of the RedCap UE [3, 4, 5, 6, 7, 9, 10, 13, 14, 17, 18, 21]. FL1 High Priority Proposal 4-1: Confirm the main bullet of the RAN1#104bis-e working assumption, i.e.: * A RedCap UE cannot be configured with a non-initial (DL or UL) BWP (i.e., a BWP with a non-zero index) wider than the maximum bandwidth of the RedCap UE. Company Y/N Comments Huawei, HiSi Y Qualcomm Y Xiaomi Y ZTE, Sanechips Y vivo Y OPPO Y NordicSemi N The sub-bullet of WA should be confirmed along. To Proposal 4-1, we are ready to object. Spreadtrum Y It is natural and the basic design principle for dedicated RRC configured BWP. Sharp Y NEC Y CATT Y Fujitsu Y IDCC Y Nokia, NSB Y CMCC Y LG Y Ericsson Y FUTUREWEI Y Intel Y FL2 Based on the received responses, the same proposal can be considered again. High Priority Proposal 4-1: Confirm the main bullet of the RAN1#104bis-e working assumption, i.e.: * A RedCap UE cannot be configured with a non-initial (DL or UL) BWP (i.e., a BWP with a non-zero index) wider than the maximum bandwidth of the RedCap UE. Qualcomm Y DOCOMO Y vivo Y China Telecom Y Xiaomi Y LG Y Huawei, HiSi Y CMCC Y Panasonic Y TCL Y NordicSemi N We do not see a reason why sub-bullet should be left out. There were no technical issues found for sub-bullet. Some companies prefer to mandate optional capabilities, but those are anyway FFS. OPPO Y Spreadtrum Y Sharp Y NEC Y Lenovo, Motorola Mobility Y CATT Y ZTE, Sanechips Y Nokia, NSB Y Ericsson Y FUTUREWEI2 Y FL3 Based on the received responses, the following updated proposal (based on the response from Nordic Semiconductor) can be considered. High Priority Proposal 4-1: Confirm the RAN1#104bis-e working assumption, i.e.: * A RedCap UE cannot be configured with a non-initial (DL or UL) BWP (i.e., a BWP with a non-zero index) wider than the maximum bandwidth of the RedCap UE. o At least for FR1, FG 6-1 (※Basic BWP operation with restriction§ as described in TR 38.822) is used as a starting point for the RedCap UE type capability. Intel Y Qualcomm Y Ericsson We prefer to leave out the sub-bullet as we are not sure if the formulation ※FG 6-1 (※Basic BWP operation with restriction§ as described in TR 38.822) is used as a starting point§ means FG 6-1a is excluded. Vivo Y China Telecom Y Panasonic Y Regarding the sub-bullet in the working assumptions related to FG 6-x for BWP operation for the RedCap UE type capability, there are several views and considerations discussed in the contributions. A few contributions [6, 13, 14, 17, 18] indicate that this working assumption (as it is) can be confirmed while several other contributions [3, 5, 10, 16, 21, 31] further discuss relevant features for the RedCap UE type capability. Specifically, two issues related to SSB/CORESET #0 multiplexing and non-initial UL/DL BWPs in TDD are discussed in these contributions. Issue #1: SSB/CORESET #0 multiplexing: Based on FG 6-1 ※Basic BWP operation with restriction§, it is mandatory for the non-RedCap Ues to support BWP with bandwidth restriction, i.e., an RRC configured DL BWP includes CORESET #0 and SSB. However, RedCap Ues are not able to simultaneously receive SSB and CORESET #0 for one special SSB/CORESET #0 multiplexing pattern in FR2, namely pattern 2 for 240 kHz SSB and 120 kHz PDCCH SCS (TS 38. 213, Table 13-10, indexes 6 and 7) [3, 5, 16, 21]. Issue #2: Non-initial UL/DL BWPs in TDD: In TDD scenarios, if the UL BWP and DL BWP should have the same centre frequency and the RedCap UL BWP does not contain CORESET #0, the DL BWP also does not contain CORESET #0. Therefore, due to the RedCap bandwidth limitation particularly in FR1, a non-initial DL BWP for RedCap Ues may or may not contain CORESET #0 [3, 10]. Several contributions [3, 5, 31] indicate that RedCap Ues should support FG 6-1a ※BWP operation without restriction on BW of BWP(s)§, implying that an RRC-configured DL BWP does not need to contain both SSB and CORESET #0. In addition, [31] discuss that a RedCap UE not having SSB in an active BWP need to support FG 1-5a for RSRP/RSRQ measurements of serving cell based on CSI-RS. Meanwhile, two contributions [16, 21] prefer not to have the special SSB/CORESET #0 configurations in cells supporting RedCap Ues to avoid the need for FG 6-1a. Some relevant proposals and observations from the contributions are summarized below: * Contribution [3] proposes that RedCap Ues support FG 6-1a ※BWP operation without restriction on BW of BWP(s)§, implying that an RRC-configured DL BWP does not need to contain both SSB and CORESET #0. * Contribution [3] furthermore proposes that in TDD, a non-initial DL BWP for RedCap Ues may or may not contain CORESET #0. * Contribution [5] proposes that UE feature 6-1a ※BWP operation without restriction on BW of BWPs§ should be supported mandatorily for RedCap Ues. * Contribution [31] argues that RedCap UE not having SSB in active BWP would need to support at least the following optional features: o FG 6-1a including at least synchronization based purely on TRS, o RSRP/RSRQ measurements of serving cell based on CSI-RS (FG 1-5a). * Contribution [31] furthermore proposes that as part of the optional feature support (i.e. FG 6-1a) a UE may support active BWP not comprising a SSB and expresses that this would require changes to synchronization procedures of current implementations, to support synchronization based purely on TRS, and support RRM RSRP/RSRQ measurements based on CSI-RS without SSB in the BWP (FG 1-5a) as well. * Contribution [21] suggests to discuss whether the RedCap UE may assume the bandwidth of the CORESET #0 and SSB does not exceed the maximum RedCap UE bandwidth and expresses a preference to put some restrictions on the possible SSB/CORESET #0 multiplexing pattern in FR2. * Contribution [16] considers that FG 6-1a implies that frequency retuning based reception between SSB and CORESET #0 the impact on RedCap UE operations may be significant and that not supporting these few configurations in FR2 in cells supporting RedCap Ues may not impose a significant practical constraint. * Contribution [10] proposes that separate initial BWP that does not contain CORESET #0 should be an optional capability for RedCap Ues and furthermore adds that with FG 6-x, separate initial BWP may not contain CORESET #0, and that in TDD, when separate initial UL BWP that does not contain CORESET #0 is configured, separate initial DL BWP also does not contain CORESET #0. Considering the above views on both issues related to SSB/CORESET #0 multiplexing and TDD UL/DL BWPs for non-initial BWP operations, the FL proposes the following questions: FL3 Medium Priority Question 4-2: * Should RedCap Ues support FG 6-1a (※BWP operation without restriction on BW of BWP(s)§ as described in TR 38.822) as a mandatory feature in addition to FG 6-1 (※Basic BWP operation with restriction§)? Please provide a motivation for your answer. Company Y/N Comments vivo N FG 6-1a is optional in Rel-15/16 and has not been implemented so far by non-redcap Ues to our knowledge. Therefore FG 6-1a should not be made mandatory for redcap Ues, in the redcap design we should consider FG 6-1 as the mandatory capability. Intel FG 6-1a should be further categorized as to whether the overall BW (including the active DL BWP, SSB, and CORESET #0) is within max RedCap UE BW or may exceed max RedCap UE BW. For the first case, the FG would be similar to that for non-RedCap Ues, but not so if the overall BW can exceed RedCap UE＊s max RF BW. Qualcomm N This question is also related to FL3 Medium Priority Question 2.3-2 To avoid the mandatory support for FG 6-1a, we think SSB needs to be transmitted in the initial DL BWP separately configured for RedCap UE. FL3 Medium Priority Question 4-3: * What other features (if any) than FG 6-1 and FG 6-1a (if supported) should be supported by RedCap regarding the BWP operation? Please provide a motivation for your answer. Company Comments vivo We do not have such an example in mind, but would be open to discuss if anything is needed for redcap Ues. Intel See response to FL3 Medium Priority Question 4-2 Qualcomm We share the same view as Vivo. 5 RF switching time In the previous meeting, RAN1#104bis-e, no consensus could be reached regarding whether an LS should be sent to RAN4 for their input on RF switching time. The discussion was captured in [35] and a draft LS with the following LS text was provided in [36]. Overall description RAN1 has discussed the RedCap WI objective on ※Reduced maximum UE bandwidth§ and would like to ask RAN4 whether it would be feasible to maintain the same RF switching times for RedCap Ues as currently specified for non-RedCap Ues or even reduce the RF switching times for RedCap Ues under the following assumptions with manageable impacts (to e.g. device cost, power consumption, and specifications): * The RF switching takes place between two frequency locations with different centre frequencies. * The maximum UE RF bandwidth is 20 MHz for FR1 and 100 MHz for FR2, and the frequency change is up to 80 MHz for FR1 and up to 300 MHz for FR2. * The RF bandwidth, SCS, QCL, and RRC configuration can be assumed to be the same before and after the RF switching, i.e. it is only the centre frequency that changes. * The RF switching may take place during initial access or after initial access. Actions To RAN4: ACTION: RAN1 respectfully asks RAN4 to provide feedback on the question above on RF switching time. Discussions on this aspect are summarized below. * Several contributions [3, 5, 11, 13, 14, 16, 20, 22, 25] indicate their support of sending an LS or the drafted LS to RAN4 to seek for their inputs on reasonable RF switching delays for potential new BWP switching mechanisms (e.g. fast BWP switching, virtual BWP switching, new BWP switching within a BWP group). The main purpose of sending an/the LS is to confirm the feasibility of BWP switching times, help to identify RAN1 specification impacts, assess the feasibility and challenges in supporting specific scenarios (e.g. where puncturing is applied or an active DL BWP may not include SSB and/or CORESET #0) and/or progress on down selection of the open issues discussed in Section 6. * Nevertheless, as discussed in Section 6, contribution [11] states that the (virtual) BWP switching, is only necessary for FR2. In contribution [20], it further indicates that manageable impacts (to e.g. device cost, power consumption and specifications) should be assumed. Moreover, contributions [4, 25] propose that ※Retuning of a BWP§ shall be stated in the LS if it＊s agreed to be sent. And contribution [25] indicates that the current 100 kHz raster would not allow fast BWP switching because of the time required to retune the synthesizer and discussion on frequency position limitation on RF retuning shall be discussed first and added in the LS. * Contributions [7, 12] argue that fast BWP switching or symbol-level RF retuning gap would increase power consumption, UE complexity for RedCap Ues and would have negative impacts on Ues data rate, cancel the frequency diversity gain consider the time-domain resource overhead, and/or could affect the network performance for coexistence between RedCap and non-RedCap Ues. Contribution [12] further remarks that there is no need to increase RAN4＊s workload before RAN1 reaches consensus on fast BWP switching. * A few contributions [6, 7, 9, 11, 12, 21] argue that supports of new BWP hopping/retuning beyond the existing BWP switching methods are not necessary for RedCap Ues for both FR1 and FR2 or for FR1 and the current specified BWP switching delay is sufficient. Contributions [6, 12] nevertheless propose RAN1 to send an LS to confirm with RAN4 whether Rel-15/16 BWP switching delay requirements can be reused for RedCap Ues e.g. due to RedCap Ues reduced maximum UE bandwidth. FL1 High Priority Question 5-1: * Companies are invited to comment on the need to send an LS on RF switching time to RAN4 and to provide text proposals on potential updates of the LS text in [36] (if necessary). Company Comments Huawei, HiSi Agree with the need. TP is suggested considering that the intention is to inquire the possibility of keeping/reducing the delay used for BWP switching for non-RedCap Ues, rather than reducing the pure RF switching delay in our understanding. Overall description RAN1 has discussed the RedCap WI objective on ※Reduced maximum UE bandwidth§ and would like to ask RAN4 whether it would be feasible to maintain the same RF switching delaytimes for RedCap Ues as currently specified for BWP switch delay for non-RedCap Ues or even reduce the RF switching delaytimes for RedCap Ues under the following assumptions with manageable impacts (to e.g. device cost, power consumption, and specifications): * The switching include RF switching takes place between two frequency locations with different centre frequencies. * The maximum UE RF bandwidth is 20 MHz for FR1 and 100 MHz for FR2, and the frequency change is up to 80 MHz for FR1 and up to 300 MHz for FR2. * The RF bandwidth, SCS, QCL, and RRC configuration can be assumed to be the same before and after the RF switching, i.e. it is only the centre frequency that changes. * The switching include RF switching may take place during initial access or after initial access. Actions To RAN4: ACTION: RAN1 respectfully asks RAN4 to provide feedback on the question above on RF switching time. ZTE, Sanechips If send LS to RAN4, RAN1 would like to ask RAN4 whether existing BWP switching time for non-RedCap Ues is sufficient for RedCap Ues. Fast BWP switching is a higher capability beyond legacy NR Ues which is not aligned with the target of RedCap WID. Therefore, we don＊t agree to add reducing existing BWP switching time in the LS. Vivo Our view on this issue has not changed, i.e. we think the existing BWP framework should be reused for redcap Ues and do not see the need to reduce the BWP/RF switching/retuning time compared to Rel-15/16. However, we can accept an LS to RAN4 if the intent is to ask RAN4 whether they have any concern on reusing exsting BWP swtiching framework and switching delay requirements. RAN1 has discussed the RedCap WI objective on ※Reduced maximum UE bandwidth§. It is RAN1 understanding that existing Rel-15/16 BWP swtiching framework and related requirement can be reused for redcap Ues. RAN1 would like to ask whether there is any concern from RAN4 perspective.. it would be feasible to maintain the same RF switching times for RedCap Ues as currently specified for non-RedCap Ues or even reduce the RF switching times for RedCap Ues under the following assumptions with manageable impacts (to e.g. device cost, power consumption, and specifications): * The RF switching takes place between two frequency locations with different centre frequencies. * The maximum UE RF bandwidth is 20 MHz for FR1 and 100 MHz for FR2, and the frequency change is up to 80 MHz for FR1 and up to 300 MHz for FR2. * The RF bandwidth, SCS, QCL, and RRC configuration can be assumed to be the same before and after the RF switching, i.e. it is only the centre frequency that changes. * The RF switching may take place during initial access or after initial access. OPPO Agree with the need. NordicSemi We prefer original FL proposal and not OK with Huawei changes. There is no need to bother RAN4 about BWP switching delay at all. We just want to find out that if UE keeps the same BWP configuration and changes only RF centre frequency, then what is the RF retuning delay. Spreadtrum During initial access, if the above working assumptions are agreed that the RedCap UE is not expected to operate in BWP wider than the RedCap UE bandwidth, there is no scenario for RF switching dynamically and RF switching time is unnecessary to be discussed. After initial access, there is only one scenario for RF switching dynamically, i.e. BWP switching. Therefore, RF switching in the above LS should be interpreted as BWP switching. RF switching in the above LS should be changed to BWP switching. In addition, we do not support a new RF operation different from BWP switching. CATT We don＊t think it is essential to pursue faster BWP switching time＃ But we are fine to ask for RAN4＊s feedback on the timing, since it provides guidance on the feasibility of RF retuning in out-of-range issues of RO and Msg3 PUSCH/PUCCH for Msg4. Samsung We think LS is needed and helpful. However, it seems like there are different understanding within the group. Some companies think this LS nothing related to BWP switching but only RF retuning time. But some other companies expect RAN 4 to confirm that faster BWP switching is helpful. Some clarifications will be helpful. We think at least for some cases, e.g., UL/DL (e.g., if centre frequency are different for TDD), or RF retuning (e.g., if we allow UE to operate in wider BW), RF retuning time is needed (without considering PDCCH decoding time). Besides, we＊d like to see whether PDCCH based BWP switching can be helpful, e.g., adding PDCCH decoding time. LG We have a similar view with CATT. We think the existing BWP framework should be assumed. From our perspective, sending LS to RAN4 asking anything about the BWP switching delay would not help making a progress in RAN1 discussion. However, we can live with the latest draft version above if the intention is to know the RF switching delay to check feasibility of RF switching solution that is under discussion. We don＊t prefer the modification from Huawei. Qualcomm We have different views for FR1 and FR2. Therefore, we cannot agree to the LS as it is, if it does not differentiate FR1 and FR2. For FR1, our view does not change and there is no need to introduce a RF/BWP switching mechanism different from NR R15/16, which leads to undue spec impacts, increase of UE complexity and power consumption. Compared with non-RedCap UE, RedCap UE is less sensitive to latency and it does not need to pursue a faster timeline. As long as RedCap UE needs to transmit on UL and receive on DL, dedicated RRC configurations are needed for PUCCH/PUSCH/SRS/ PDCCH/PDSCH/CSI-RS/TRS. The BWP-specific RRC parameters need to be updated/adapted with the change of center frequency, even though there is no change in the SCS and BW. Therefore, the assumption that ※RRC configuration§ stays the same before and after RF/BWP switching does not hold in general. Based on the status of RAN1#105 meeting, the motivation to send such an LS to RAN4 become weaker since the majority companies agreed with the following proposal/working assumption: * Both during and after initial access, for the scenario where the initial UL BWP for non-RedCap Ues is configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap Ues. o The specifications shall ensure coexistence with non-RedCap Ues (e.g. avoiding or minimizing PUSCH resource fragmentation), if a separate initial UL BWP for RedCap Ues is configured. In addition, compared with the solution of intra-BWP frequency hopping without RF retuning, the LLS results in FR1 indicated the gain of BWP hopping outside max UE BW is marginal (or leads to performance losses due to the need for a retuning gap). This makes the motivation/benefits to study RF/BWP switching even weaker. For FR2, due to beamforming at both gNB and UE, in addition to smaller cells, the delay spread may be smaller compared to FR1 leading to a flatter channel and hence may benefit from frequency hopping more. Hence, we are supportive of sending an LS to RAN4 provided it is related to FR2 only. The LS should contain the following aspects: 1. What would be the BWP switching time compared to the Rel-15/16 defined DCI-based BWP switching, if the following is assumed? a. The switches are preconfigured (timer-based), i.e., not DCI-based b. The exact same configuration is assumed for the BWP before and after the switch (e.g., RF bandwidth, SCS, QCL, and RRC configuration), i.e. it is only the center frequency that changes. 2. Is there any frequency switching range that the BWP switching assumed in 1-a and 1-b can be faster than some other frequency switching range? I.e., is the switching faster if the source and target BWP frequencies are within a certain range (what is this range?) a. The switching range studied should cover up to 400 MHz b. In case the NW is capable of more than 1 CC (e.g., 2CC), the range should cover UE switches within a CC and across different CCs (from NW perspective since UE does not support CA) Ericsson We also think that an LS is needed and helpful. RAN4 feedback on the RF switching time is needed for determining suitable BWP solutions for RedCap, as captured in Sections 2, 3, 4, and 6 of this FL summary. We are mainly interested in getting RAN4＊s view on the switching delay of RF switching between two frequency locations with different centre frequencies, including a TDD scenario where one frequency location is the center frequency of the DL BWP and the other is the center frequency of the UL BWP. FUTUREWEI The information can be helpful for further guidance. As in our contribution, if a LS is agreed for a retuning of a BWP, retuning of a BWP should be stated in the LS Intel As last time, we see the benefit in sending the LS to RAN4, and the version from end of RAN1 #104bis-E should be considered as the starting point. FL2 Please continue to discuss the following question, taking the responses above into account. High Priority Question 5-1: * Companies are invited to comment on the need to send an LS on RF switching time to RAN4 and to provide text proposals on potential updates of the LS text in [36] (if necessary). Qualcomm Thanks for the efforts of FL. Regarding the need to send an LS to RAN4, our view is the same as before. That is, we don＊t agree to send such an LS as it is. We are supportive of sending an LS to RAN4 provided it is related to FR2 only. DOCOMO We think RAN4 feedback is quite helpful for the discussion related to RF switching between different center frequencies in this AI. Considering the remaining WG meetings, we need to send an LS as soon as possible. Vivo We would be fine with the following text if there is a strong desire to send the LS. RAN1 has discussed the RedCap WI objective on ※Reduced maximum UE bandwidth§. It is RAN1 understanding that existing Rel-15/16 BWP swtiching framework and related requirement can be reused for redcap Ues. RAN1 would like to ask whether there is any concern from RAN4 perspective. China Telecom We think it is urgent needed for RAN1 to send the LS to ask RAN4 feedback. LG We still think the existing BWP framework should be assumed for RedCap Ues. In that sense, sending LS to RAN4 and getting input from them is not essential. However, as we said earlier, we can live with the latest draft version above if the intention is to know the RF switching delay to check feasibility of RF switching solution that is under discussion. Huawei. HiSi To NordicSemi/LG: If the intention is to only check the RF retuning/switching delay within a single BWP which is roughly 140us (2OS) already, there is certainly no room to change and the LS is already assuming RedCap Ues sharing the same BWP even with larger BW than RedCap UE max BW, which I don＊t think agreeable to many others. Another issue may be worthwhile of note is that the existing BWP switching delay applies for the case of switching occurring within UE max channel BW, so not the same as RedCap BWP switching. We are also willing to revise the texts from vivo as below RAN1 has discussed the RedCap WI objective on ※Reduced maximum UE bandwidth§. It is RAN1 understanding that existing Rel-15/16 BWP swtiching framework and related requirement can be reused for RedCap Ues at least for some cases, e.g. the UE supports two BWPs and the center frequency change among the two BWPs is within UE max bandwitdth. RAN1 would like to ask what could be the switcing delay for other cases, including at least one scenario that assume whether there is any concern from RAN4 perspective.. it would be feasible to maintain the same RF switching times for RedCap Ues as currently specified for non-RedCap Ues or even reduce the RF switching times for RedCap Ues under the following assumptions with manageable impacts (to e.g. device cost, power consumption, and specifications): * The RF switching takes place between two frequency locations with different centre frequencies. * The maximum UE RF bandwidth is 20 MHz for FR1 and 100 MHz for FR2, and the frequency change is up to 80 MHz for FR1 and up to 300 MHz for FR2. * Tthe RF bandwidth, SCS, QCL, and RRC configuration for the corresponding BWP can be assumed to be the same before and after the RF switching, i.e. it is only the centre frequency that changes. * The RF switching may take place during initial access or after initial access. Other assumptions/cases can be fedback based on RAN4 discussion. Panasonic We are basically supportive to send the LS as RAN4 guidance would be beneficial for RAN1 discussion on ※proper RF retuning§ for initial UL BWP operation. We still think fast BWP switching is beneficial for frequency resource flexibility. The conditions raised in the LS would reduce the complexity of BWP switching. Besides, The limitation of number of candidates of BWP center frequency would be beneficial to reduce switching delay and complexity further. Then we propose to ask RAN4 if it is feasible. NordicSemi We do not understand based on what grounds companies block LS to RAN4. We want to ask simple question which is in expertise of RAN4. This would be useful input to facilitate further BWP discussion in RAN1. Response to Huawei: Fine, but then if BWP size and configurations within BWP do not change than UE needs to do only RF retuning based on BWPI. We would be fine to support adaptive BWP switching as mandatory, if BWP configurations do not change. Otherwise, we can follow R15 BWP as optional capa. OPPO It is urgent to send the LS to RAN4. Agree with uawei＊s version. Samsung We see some proposals that requires RF retuning under discussing, e.g., dedicated BWP for initial access. At least in our understanding, the same SSB and COREST #0 is used for RedCap and non-Redcap UE will be shared, and then the dedicated iBWP will be configured by SIB. The dedicated iBWP may be located in different location of CORESET #0. If so, we think at least, RAN 4 need to provide some input on the RF retuning time. Spreadtrum If the above working assumptions are agreed that the RedCap UE is not expected to operate in BWP wider than the RedCap UE bandwidth, there is no scenario for dynamic RF switching different from dynamic BWP switching. RF switching in LS should be updated as BWP switching. Regarding DL/UL switching time, we do not know why the new DL/UL switching time should be supported by the RedCap UE. CATT We can agree to send the LS. From our view, there are different interests among companies (e.g. BWP switching delay between different BWPs, RF switching delay if the centra frequency of DL BWP and UL BWP are different＃). If the LS is to be send, we should either include all interested cases, or do some down-selection first. ZTE, Sanechips If send LS to RAN4, RAN1 to ask RAN4 whether existing BWP switching time for non-RedCap Ues is sufficient for RedCap Ues. Fast BWP switching is a higher capability beyond legacy NR Ues which is not aligned with the target of RedCap WID. No need to ask reducing existing BWP switching time in the LS. Ericsson We suggest further revision based on Vivo＊s and Huawei＊s revisions. RAN1 has discussed the RedCap WI objective on ※Reduced maximum UE bandwidth§. It is RAN1 understanding that existing Rel-15/16 BWP switching framework and related requirement can be reused for RedCap Ues at least for some cases, e.g. the UE supports two BWPs and the center frequency change among the two BWPs is within UE max bandwitdth. For these cases, RAN1 would like RAN4 to confirm whether it is feasible to maintain the same BWP switching delays for RedCap Ues as currently specified for non-RedCap Ues. Furthremore, RAN1 would like to ask RAN4 what could be the switcing delay for FR1 and FR2 be for other potential cases, including at least one scenario that assume whether there is any concern from RAN4 perspective.. it would be feasible to maintain the same RF switching times for RedCap Ues as currently specified for non-RedCap Ues or even reduce the RF switching times for RedCap Ues under the following assumptions with manageable impacts (to e.g. device cost, power consumption, and specifications): * The RF switching takes place between two frequency locations with different centre frequencies o Including cases such as UL/DL center frequencies are different in a TDD scenario * The maximum UE RF bandwidth is 20 MHz for FR1 and 100 MHz for FR2, and the frequency change is up to 80 MHz for FR1 and up to 300 MHz for FR2. o Are there any switching ranges that could be faster compared to some other switching ranges? If any, please states the frequency ranges for both FR1 and FR2. * Tthe RF bandwidth, SCS, QCL, and RRC configuration for the corresponding BWP can be assumed to be the same before and after the RF switching, i.e. it is only the centre frequency that changes. For this case, it may be viewed as BWP retuning. * The RF switching may take place during initial access or after initial access. * The RF switching is not triggered by DCI. Other assumptions/cases can be fedback based on RAN4 discussion. FUTUREWEI2 If we agree to send an LS, the modifications suggested by Huawei go towards addressing our comments about capturing retuning/switching of a BWP in the LS Based on the received responses to Question 5-1 above, the following updated draft LS text can be considered. Overall description RAN1 has discussed the RedCap WI objective on ※Reduced maximum UE bandwidth§. It is RAN1＊s understanding that the existing Rel-15/16 BWP switching framework and related requirements can be reused for RedCap Ues at least for some cases, e.g. that the UE supports two BWPs and the center frequency changes among the two BWPs. For these cases, RAN1 would like RAN4 to confirm whether it is feasible to maintain the same BWP switching delays for RedCap Ues as currently specified for non-RedCap Ues. Furthermore, RAN1 would like to ask RAN4 what the switching delay for FR1 and FR2 could be for other potential cases, including at least one scenario based on the following assumptions: * The RF switching takes place between two frequency locations with different centre frequencies. o Including cases such that the UL/DL center frequencies are different in a TDD scenario * The maximum UE RF bandwidth is 20 MHz for FR1 and 100 MHz for FR2. o Are there any switching ranges that could be faster compared to some other switching ranges? If any, please state the frequency ranges for both FR1 and FR2. * The RF bandwidth, SCS, QCL, and RRC configuration for the corresponding BWP can be the same before and after the RF switching, i.e. it is only the centre frequency that changes. For this case, the RF switching may be viewed as BWP retuning. * The RF switching may take place during initial access or after initial access. * The RF switching is not triggered by DCI. Other assumptions/cases can be fed back based on RAN4 discussion. Actions To RAN4: ACTION: RAN1 respectfully asks RAN4 to provide feedback on the question above on RF switching time. FL3 High Priority Proposal 5-2: * Send an LS on RF switching time to RAN4 with the updated LS text above. Company Y/N Comments Intel Y Just a question for clarification 每 is it correct that, in the following bullet ※BW retuning§ is suggested as a shorthand to describe the preceding conditions in the bullet? Or there is something more to it? * The RF bandwidth, SCS, QCL, and RRC configuration for the corresponding BWP can be the same before and after the RF switching, i.e. it is only the centre frequency that changes. For this case, the RF switching may be viewed as BWP retuning. Qualcomm N, if the LS does not differentiate FR1 and FR2 Thanks again for the efforts of FL ?? For FR1, our view does not change and we think the existing Rel-15/16 BWP mechanism/framework (switching, configuration, timeline and related UE capabilities) is sufficient. Having said that, we are supportive of Vivo＊s proposal as follows: * For FR1, it is RAN1 understanding that existing Rel-15/16 BWP switching framework and related requirement can be reused for RedCap Ues. RAN1 would like to ask whether there is any concern from RAN4 perspective for FR1. For FR2, we are supportive of sending an LS to RAN4, which should include the following updates: Furthermore, RAN1 would like to ask RAN4 what the switching delay for FR2 could be for other potential cases, including at least one scenario based on the following assumptions:? * The RF switching takes place between two frequency locations with different centre frequencies.? * Including cases such that the UL/DL center frequencies are different in a TDD scenario? * The maximum UE RF bandwidth is 100 MHz for FR2.? * Are there any switching ranges that could be faster compared to some other switching ranges? If any, please state the frequency ranges for FR2.? * The switching range studied can cover up to 400 MHz * The RF bandwidth, SCS, QCL, and RRC configuration for the corresponding BWP can be the same before and after the RF switching, i.e. it is only the centre frequency that changes. For this case, the RF switching may be viewed as BWP retuning.? * The RF switching may take place during initial access or after initial access.? * The RF switching is preconfigured and is not triggered by DCI.? Ericsson Y vivo N The BWP framework and requirement in Rel-15/16 are the baseline for redcap Ues unless RAN1 has consensus to change them. So far it becomes much more clear that new RF retuning/switching behaviour is not necessary for redcap given large majority of companies agree that separate initial BWP not exceeding redcap UE BW capability can be configured. Furthermore, it is not proper to discuss faster BWP switching for redcap Ues that non-redcap Ues. Considering such situation, we do not understand what is the foundation of the many open questions to RAN4 listed in the 2nd paragraph and what the proponents want to achieve, thus we can NOT agree to those. We can NOT agree to have different treatment for FR1 and FR2 as proposed by QC either, as we do not see the fundamental difference for reduced BW operation in FR1 and FR2. As proposed before, we can agree to the following text to RAN4 RAN1 has discussed the RedCap WI objective on ※Reduced maximum UE bandwidth§. It is RAN1 understanding that existing Rel-15/16 BWP swtiching framework and related requirement can be reused for redcap Ues. RAN1 would like to ask whether there is any concern from RAN4 perspective. China Telecom Y Panasonic Y with addition We propose to ask RAN4 the switching delay with the condition added below. It is because we think there would be an effect to switching delay by just to change the offset frequency using multiplier/divider while keeping the same onfiguration of PLL. * The RF switching takes place between two frequency locations with different centre frequencies. o Including cases such that the UL/DL center frequencies are different in a TDD scenario o Including cases such that the UE may assume the locations are selected from fewer number of candidates but not any ruster currently required 6 BWP switching In RAN1#104bis-e, there was some discussion related to BWP switching, BWP hopping, and BWP retuning, see [35]. This is further discussed in several RAN1#105-e contributions, as summarized below. * Several contributions propose that some new BWP switching, hopping, or retuning mechanism is studied: [5, 11, 13, 16, 20, 22, 25]. Reduced BWP switching time may, for example, be enabled by imposing restrictions on that only the center frequency is changed, while retaining one or more of subcarrier spacing, BWP size, QCL properties, and other common RRC configuration parameters, and/or constraining the number of possible frequency locations. Feasibility of this may depend on RAN4 input on RF switching time, see Section 5. * Some contributions argue that the current switching mechanisms are sufficient [6, 9, 21]. * One contribution [7] argues that fast BWP switching/frequency hopping should be discussed only in the context of achieving coverage recovery, and then whether switching/hopping is prioritized compared to other schemes. * One contribution [11] suggests to introduce a ※virtual narrow BWP hopping§, however only for FR2, whereas one contribution [3] suggests that if any new BWP switching, hopping, or retuning mechanism is introduced in the specification, it may be used in any frequency band, regardless of the frequency range. * One contribution [11] suggests introducing a new mechanism for transitioning a UE to a narrow BWP after initial access, where the switching mechanism may be implicit or initiated/requested by the UE. FL questions/proposals related to these aspects will be added and treated once aspects raised in other related sections of this FL summary have seen further progress. 7 Other aspects RRM measurements: RRM measurement aspects were brought up in some contributions. Two contributions [11, 33] mention that it is beneficial to have a DL BWP configured for a RedCap UE containing an SSB for measurement. This may be transmitted on or off the sync raster. One contribution [5] instead proposes to rely on RF retuning between different 20 MHz (in FR1) regions for obtaining RRM measurements to avoid the overhead associated with additional SSBs. SRS and CSI measurements: In [20] it is suggested to consider supporting SRS transmissions or CSI measurement/report for link adaptation outside active BWP. Also, Sub-band CSI reporting is suggested as a means of reflecting the reduced RedCap UE bandwidth. In [5] it is suggested to further study CSI measurement/reporting over frequency resources wider than the maximum bandwidth of RedCap UEs. Potential SUL support: In [29, 34], it is suggested that SUL is supported for RedCap UEs. The WID [1] notes that ※This WI focuses on SA mode and single connectivity with operation in a single band at a time§, which seems to suggest that SUL support may not be in the current WI scope. Since this question is under discussion in RAN4, the FL suggestion is to await the outcome of the RAN4 discussion, to avoid parallel discussions in different working groups. References [1] RP-210918 Revised WID on support of reduced capability NR devices Nokia, Ericsson [2] R1-2104027 RAN1 agreements for Rel-17 NR RedCap Rapporteur (Ericsson) [3] R1-2104179 Reduced maximum UE bandwidth for RedCap Ericsson [4] R1-2104188 Discussion on Bandwidth Reduction for RedCap UEs FUTUREWEI [5] R1-2104283 Reduced maximum UE bandwidth Huawei, HiSilicon [6] R1-2104365 Discussion on reduced maximum UE bandwidth vivo, Guangdong Genius [7] R1-2104428 Discussion on reduced maximum UE bandwidth for RedCap Spreadtrum Communications [8] R1-2104526 Discussion on reduced maximum UE bandwidth CATT [9] R1-2104543 Aspects related to reduced maximum UE bandwidth Nokia, Nokia Shanghai Bell [10] R1-2104616 Discussion on reduced maximum UE bandwidth CMCC [11] R1-2104677 BW Reduction for RedCap UE Qualcomm Incorporated [12] R1-2104710 Bandwidth reduction for reduced capability NR devices ZTE, Sanechips [13] R1-2104782 Discussion on reduced UE bandwidth OPPO [14] R1-2104851 Discussion on reduced maximum UE bandwidth for RedCap China Telecom [15] R1-2104881 Discussion on reduced maximum UE bandwidth TCL Communication Ltd. [16] R1-2104911 On reduced max UE bandwidth for RedCap Intel Corporation [17] R1-2105072 Reduced maximum UE band width for RedCap UEs DENSO CORPORATION [18] R1-2105110 On reduced maximum UE bandwidth for Redcap Apple [19] R1-2105217 Reduced maximum UE bandwidth for RedCap Lenovo, Motorola Mobility [20] R1-2105983 (Inbox) Bandwidth Reduction for RedCap UEs (revision of R1-2105316) Samsung [21] R1-2105429 Aspects related to the reduced maximum UE bandwidth of RedCap LG Electronics [22] R1-2105567 Discussion on the reduced maximum UE bandwidth for RedCap Xiaomi [23] R1-2105593 Discussion on aspects related to reduced maximum UE bandwidth NEC [24] R1-2105635 Discussion on reduced maximum UE bandwidth Sharp [25] R1-2105679 Aspects related to reduced maximum UE bandwidth Panasonic Corporation [26] R1-2105703 Discussion on reduced maximum UE bandwidth for RedCap NTT DOCOMO, INC. [27] R1-2105736 On?reduced maximum bandwidth for RedCap UEs MediaTek Inc. [28] R1-2105746 Reduced maximum bandwidth for RedCap UEs InterDigital, Inc. [29] R1-2105751 Discussion on reduced maximum UE bandwidth China Unicom [30] R1-2105800 Discussion on aspects related to reduced maximum UE bandwidth ASUSTEK COMPUTER (SHANGHAI) [31] R1-2105882 On aspects related to reduced maximum UE BW Nordic Semiconductor ASA [32] R1-2104184 Ensuring coexistence between RedCap and non-RedCap UEs Ericsson, Deutsche Telekom, NTT DOCOMO, Softbank, Telecom Italia, Telstra, Verizon Wireless, Vodafone [33] R1-2104370 Discussion on reduced capability signaling vivo, Guangdong Genius [34] R1-2105535 On RedCap UL transmission Huawei, HiSilicon [35] R1-2103944 FL summary #4 on reduced maximum UE bandwidth for RedCap Moderator (Ericsson) [36] R1-2104046 Draft LS on RF switching time for RedCap UE Ericsson