3GPP TSG-RAN WG1 Meeting #105-e R1-21xxxxx e-Meeting, 19th 每 27th May 2021 Agenda Item: 8.6.1.1 Title: FL summary #3 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 with High Priority or Medium Priority. In this round of the discussion, companies are requested to provide comments on the proposals and questions tagged FL4 before Monday 24th May 20:00 UTC. Follow the naming convention in this example: * RedCapBwFLS3-v000.docx * RedCapBwFLS3-v001-CompanyA.docx * RedCapBwFLS3-v002-CompanyA-CompanyB.docx * RedCapBwFLS3-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 RedCapBwFLS3-v002-CompanyA-CompanyB.docx. * CompanyC uploads an empty file named RedCapBwFLS3-v003-CompanyB-CompanyC.checkout * CompanyC checks that no one else has created a checkout file simultaneously, and if there is a collision, CompanyC tries to coordinate with the company who made the other checkout (see e.g. contact list in Annex). * CompanyC then has 30 minutes to upload RedCapBwFLS3-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 Xiaomi Y DOCOMO Y Huawei, HiSi Y ZTE, Sanechips Y Lenovo, Motorola Mobility Y NEC Y CATT Y OPPO Y Samsung N Again, we are not ready to confirm the WA. 1) It is not clear that how RedCap UE determinate it＊s initial DL BWP. 2) There are some proposal to design that a BWP can retuning within a wider bandwidth under the assumption that Redcap can not operate in a wider BWP bandwidth. If so, we want to have the chance to re-open the discussion on how to define the floating BWP or UE operation in a wider bandwidth. In this case, we don＊t see the urgent to confirm the WA. But on the other hand, we are fine to discuss with this working assumption. Spreadtrum Y NordicSemi N Unfortunately, our position does not change, there is still a lot of confusion on how this separate initial DL BWP suppose to work. We want to see some progress on this before confirming this WA. CMCC Y Nokia, NSB Y LG Y FL4 The FL recommendation is to revisit the working assumption in a future meeting. No further comments are requested on this proposal at this point. 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 Xiaomi We share similar view with QC that clarification on when the initial DL BWP for RedCap UEs should be separately configured 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. DOCOMO Y Huawei, HiSi Partially We don't know why offloading suddenly becomes a significant issue. We agree a separate DL BWP for TDD alignment purpose, there could be benefits for that but then a few following up issues need to be discussed as listed in the same questions we answered above&below. So our current assumption is that the below can be agreeable. * 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. The sub-bullets can be discussed together with 2.2-2a. As said we will be also ok to add detailed discussion points including (1) whether a separate CORESET#0 can be configured, and (2) if so, whether dedicated SSBs are required, and (3) if so, whether they are known to non-RedCap UEs or not, and (4) whether it can be disabled or not by network such that resolution of UL fragment issue is NOT at the cost of significant DL overhead by (5) e.g. assuming all RedCap UEs have the capability of work without SSB, or (6) proper BWP switching/retuning/hopping (whatever is called). ZTE, Sanechips Y A separate initial DL BWP can include an additional CORESET. But RedCap UEs should rely on CORESET #0 for SIB1 reception and additional CORESET in the separate initial DL BWP can be used for Msg2/Msg4 monitoring during initial access. Lenovo, Motorola Mobility Y For the FFS, we think if the separate initial DL BWPs for RedCap UEs contains legacy CORESET#0, then it will not be used during initial access for RedCap UEs, but is only used after initial access. The RedCap UEs＊ behaviour will be same with legacy UEs in this case, i.e., using CORESET#0 defined initial BWP during initial access. NEC Y CATT N 1) There is No issue of using legacy initial DL BWP during the initial access. 2) Off-loading motivation is not strong since it is not expected to have many RedCap UEs in the early release. 3) Off-loading efficiency is unclear and doubtful. On the other hand, complicated situations arise regarding to containing (or not) CORESET#0 and SSB, cell-specific signalling, centre frequency in TDD. OPPO Y But for the FFS, it is not clear how the separately configured initial DL BWP can contain CORESET 0? Samsung Y We have same understanding with Ericsson and vivo＊s point #1. In our mind, this separated initial DL BWP is configured in SIB. For vivo＊s point #2, we think this separated initial DL BWP does not needs to contain the entire CORESET #0. And we are fine to have FFS proposed by vivo. Spreadtrum Y We are fine for the current version. NordicSemi Partially We agree with Huawei＊s direction, i.e. listing open issues and discuss those, The possibility for offloading during initial access has the same value as offloading in RRC connected. If RedCap UE becomes a success, then there must be possibility to grow capacity for large number of RedCap UEs occurring. (1) whether a separate CORESET#0 can be configured, and Nordic: having separate CORESET#0 could simply re-use current NR implementation. Very minor spec changes, saying that if separate CORESET#0 is configured to RedCap, the CORESET#0 used for determination of DCI format size, VRB definition, ..... (2) if so, whether dedicated SSBs are required, and Nordic: this is good question, we believe that during initial access itself SSB perhaps not needed (initial access is short term procedure), but would be needed in RRC connected (3) if so, whether they are known to non-RedCap UEs or not, and Nordic: This would be in the same SIB1, non-RedCap UEs, so answer is yes (4) whether it can be disabled or not by network such that resolution of UL fragment issue is NOT at the cost of significant DL overhead by Nordic: Of course, this must be configurable. If very little RedCap UEs camping in the cell, there is no need for offloading. So this MUST be configurable by gNB (5) e.g. assuming all RedCap UEs have the capability of work without SSB, or Nordic: This is a question of making FG 6-1A mandatory. At least from our point of view this is non-preferred way to go. (6) proper BWP switching/retuning/hopping (whatever is called). Nordic: If multiple BWPs configurations would be guaranteed not to change. This would be a low-complex way to suppport RRC connected offloading for Reduced capability UEs and could be baseline/mandatory from our point of view. We are supportive. CMCC Y We think separated initial DL BWP is configured in SIB and can be used during initial access. The separated initial DL BWP may not contain the entire CORESET #0. FUTUREWEI4 N To follow up on some of the comments made in GTW: Among the reasons for not supporting, we do not believe in the offloading use case. But, to move forward, agreement can be at most a working assumption with at least clarifications to proposal * Include the restriction on the DL BWP. For example ※An initial DL BWP for RedCap UEs, which is not expected to exceed the maximum RedCap UE bandwidth, for use during initial access ＃§ * The proposal should replace the word with ※configured§ by ※configured/defined§. A low impact specification can used defined behavior in addition to configured behavior. We are also OK to specifically restrict it to be a possible solution for the TDD problem as vivo commented LG We think the intention of FFS is not clear. Other than the FFS, we would be okay. FL4 Based on the received responses to Proposal 2.1-2b and Question 2.1-3, the following updated proposal for a working assumption can be considered. Note that this section concerns the use of the initial DL BWP during the initial access. The use of the initial DL BWP after the initial access is discussed in Section 2.2. Furthermore, additional CORESET is a separate issue which is discussed in Section 2.3. High Priority Proposal 2.1-2c: * Working assumption: At least for TDD, an initial DL BWP for RedCap UEs (which is not expected to exceed the maximum RedCap UE bandwidth) 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 is signaled in SIB. 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, and, if not, the Redcap UE behaviour for CORESET #0 monitoring o FFS: whether part of the configuration can be defined instead of signaled o FFS: FDD case Qualcomm We suggest to revise the second sub-bullet as follows: o The configuration for a separately configured initial DL BWP for RedCap UEs can includes at least a CORESET/CSS configuration. and add another FFS bullet for SSB as follows: o FFS: whether SSB is transmitted in the separately configured initial DL BWP for RedCap UEs vivo Generally fine We are generally fine with intent of the proposal. We are supportive of Qualcomm＊s proposed revisions. DOCOMO We are generally wine with the proposal and also support the modification from Qualcomm for the 2nd sub-bullet. Regarding the 1st bullet, based on the comments from companies, we propose to modify ※SIB§ to ※SIB1§ China Telecom Y We are generally fine with FL proposal for progress, with leaving FFSs for further discussion. Panasonic Y CMCC Y ZTE, Sanechips Y For the second sub-bullet, if separately configured initial DL BWP includes entire CORESET #0, CORESET configuration may be not needed. OPPO Y Qualcomm＊s revision of the sub-bullet seems better. NEC Y Sharp Y We are OK with the proposal and also OK with Qualcomm＊s modification on second sub-bullet. 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. Xiaomi Case 1: Configuring initial DL BWP used during initial accessㄩIn this case, the initial DL BWP can be configured via SIB1 Case 2: Redcap share the same initial DL BWP with non-Redcap during initial access and need to determine a separate initial DL BWP used after initial access (e.g., the initial DL BWP configured via BWP#0 configuration option 1 is larger than Redcap＊s UE bandwidth), for this case, Redcap could determine the initial DL BWP used after initial access based on predefined rules, e.g., Redcap still use the MIB-configured initial DL BWP after initial access DOCOMO We share the same view with Ericsson Huawei, HiSi In SIB1 ZTE, Sanechips The bandwidth and frequency location of the separate initial DL BWP can be configured in SIB1. Lenovo, Motorola Mobility The configuration is provided in SIB1. NEC The legacy procedures apply as specified in section 12 of 38.213. If separate initial DL BWP is configured by SIB1, only difference would be initialDownlinkBWP for separate initial DL BWP for RedCap UE is provided by SIB1. CATT It can follow the legacy way: For the one during the initial access: derived from MIB. For the one after initial access: configured by SIB1. If not configured, use the one derived from MIB. OPPO The bandwidth and frequency location of the initial DL BWP for RedCap Ues can be provided by SIB1. Samsung * If initial DL BWP for non-RedCap UE is no wider than RedCap UE BW, RedCap UE can use the initial DL BWP for non-RedCap UE. * A separated initial DL BWP for RedCap can be configured in SIB. * If initial DL BWP configured for non-RedCap is wider than RedCap UE BW, * RedCap Ues can be configured with a separated initial DL BWP for RedCap in SIB, otherwise, CORESET #0 is used for initial DL BWP for RedCap UE. (until RedCap UE got a UE specific BWP) NoridicSemi By MIB CORESET#0 or SIB1 REDCAP-CORESET#0 for initial access By initial DL BWP configured in SIB1 after initial access This behaviour is consistent with BWP Option 1 and Option 2 in NR. CMCC We think separated initial DL BWP is configured in SIB1. FUTUREWEI4 There are possible ways to determine the bandwidth and frequency location * If no SIB configuration is provided, the legacy MIB-based procedures apply * If the SIB configuration for a DL BWP with a bandwidth no larger than the maximum RedCap UE BW is provided, the legacy procedure applies * If the SIB configuration for a DL BWP with a bandwidth larger than the maximum RedCap UE BW is provided, the RedCap UE can determine its bandwidth and location by defined rules in the standard * If supported and if the SIB configuration for a RedCap DL BWP with a bandwidth no larger than the maximum RedCap UE BW is provided, the RedCap UE applies the legacy procedures FL4 The received responses to Proposal 2.1-2b and Question 2.1-3 have been considered in the updated proposal in Proposal 2.1-2c above. 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) After the initial email discussion in RAN1#105-e captured in [37, 38], the following agreement was made in the GTW session on Friday 21st May: Agreements: Replace the RAN1#104bis-e working assumption with the following working assumption (for option 1) and working assumption (for option 2): * Working assumption: 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. 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 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. DOCOMO Y Also fine to wait until Proposal 2.1-2b is concluded Huawei, HiSi If the understanding is the applicability is after initial access, ok with the version. Otherwise, if the understanding is as vivo interpreted, we should stabilize the proposal in P2.1-2b first. FUTUREWEI comment is fine with us. ZTE, Sanechips Y Lenovo, Motorola Mobility Y NEC Y CATT N As pointed out by vivo, Futurewei, Xiaomi, this proposal depends on the outcome of Proposal 2.1-2b. It is unstable to use uncertain condition to further define a corresponding conclusion. OPPO Y Samsung We feel like to check this based on the outcome of 2.1-2b. Prefer vivo＊s comment. Spreadtrum Y NordicSemi Y We support CMCC Y Fine with vivo＊s updated proposal. LG N We have the same understanding with vivo. The separate initial DL BWP configured for RedCap Ues can be used during and after initial access. Vivo＊s modification is preferred. FL4 Based on the received responses, the following updated proposal for a working assumption can be considered. This proposal is assumed to be agreed after (or together with) Proposal 2.1-2c. High Priority Proposal 2.2-2b: (assumed to be agreed after Proposal 2.1-2c) * Working assumption: 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 Since SSB-based RRM/RLM measurements needed to be considered for RRC connected Ues and there is a working assumption on the support of FG 6-1 for RedCap UE in FR1, we suggest the following changes to this WA: Working assumption: 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) if the following conditions are satisfied: * a SSB is transmitted within this separately configured initial DL BWP * the center frequency of this initial DL BWP is aligned with the center frequency of the initial UL BWP of RedCap UE in TDD vivo We support the latest proposal above. DOCOMO We support the proposal China Telecom We support FL proposal. Panasonic We support FL proposal. CMCC We support FL proposal. ZTE, Sanechips We support FL proposal. OPPO We support FL proposal. NEC NEC supports the proposal. Sharp We support FL proposal. 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 Xiaomi OK to comeback later Huawei, HiSi Ok to come back later but our current view is concerned by additional CORESET for those use for the reasons given in previous questions. (1)A separate CORESERT might be considered and (2) in that case, SIB1 should be included as well, i.e. there is only one CORESET used during initial access. ZTE, Sanechips 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/Msg4/Paging for RedCap Ues should be configured within the separate initial DL BWP. CATT OK to wait for the conclusion in Proposal 2.1-2b. OPPO OK to come back later Samsung We suggest to agree on the basic assumptions first, e.g., whether separated iBWP can be separated configured, whether it can be outside of frequency range of CORESET #0. Then we come back. Spreadtrum It seems companies have different understanding for the ※additional CORESET§. It can be comeback later. NordicSemi Or it can be discussed together with Proposal 2.1.-2b LG Okay with the FL＊s suggestion. FL4 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. 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. Xiaomi Before we discuss this issue, we need to identify whether there is real traffic congestion problem. Up to now, we don＊t see concrete analysis to show there is critical traffic congestion. DOCOMO a) Confined within the separately configured initial DL BWP b) Paging and RA-related DL channels FFS for SSB and SIBx Huawei, HiSi We don＊t think DL offloading is a significant issue in Rel-17, at least far less critical than the issue of potential PUSCH fragmentation. Thus, during initial access, we don＊t prefer ※additional§ CORESET for the same RedCap Ues. We can discuss ※separate§ CORESET dedicated for RedCap Ues for TDD alignment purpose, and require further discussion on whether separate SSBs/SIB1 is required for RedCap Ues and if so, the spec impact in this case including whether those SSBs are known by non-RedCap Ues, and whether/how the RedCap Ues would switch its location from the shared CORESET#0 to this separately configured BWP containing the separate CORESET and whether/how gNB takes care of the switching time for e.g. RAR transmission. Lenovo, Motorola Mobility a) Configured in SIB1 and is within the dedicated intitial DL BWP b) SIBx other than SIB1, channels in RACH procedure, paging CATT To avoid unnecessary effort, we should wait for the outcome of Proposal 2.1-2a and 2.1-2b. But in general, we do not think congestion is a serious issue in Release 17. OPPO a) Configured in SIB1 b) SIBx other than SIB1, msg2/4 in RACH procedure, paging NordicSemi Possibility for offloading during and after initial access is important. CMCC a) Configured within the separate initial DL BWP for Redcap Ues, by SIB1. b) Paging, SIBx other than SIB1, MSG2/4, etc. Nokia, NSB We understand this to be for initial access and idle/inactive mode. If this is supported then, a) Configured in SIB1, confined in the initial DL BWP b) Paging, SIBx other than SIB1, Msg2/4 Ericsson a) The additional CORESET can be defined within a separate initial DL BWP for RedCap. b) The additional CORESET can be used for offloading Msg2, Msg4, paging and SI (other than SIB1) message transmissions, while CORESET #0 is used for scheduling SIB1. It should be noted that after decoding MIB, the UE has the required information (e.g., CORESET #0 configuration) for acquiring SIB1. Therefore, SIB1 must be scheduled using CORESET #0 as it is not possible to configure a separate CORESET for SIB1 in the MIB which has only 1 spare bit left. However, the CORESET in the potential separate initial DL BWP can be used for Msg2, Msg4, paging, and SIBx (with x>1, e.g., SIB2, SIB3, etc.) transmissions. FUTUREWEI4 As we stated, we did not agree on offloading. The traffic we evaluated in the study was not ※massive§. It is also unclear whether this ※additional CORESET§ is in the initial DL BWP for RedCap Ues or is it a separate initial BWP for RedCap Ues. LG a) In the separate initial DL BWP, configured in SIB1 b) Pagaing, Msg2/4, SIB1, SIBx FL4 The FL suggestion is to come back to this question (about possibility to configure an additional CORESET for offloading purposes for RedCap Ues) after the proposals in Section 2.1 have seen some further progress. 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. After the initial email discussion in RAN1#105-e captured in [37, 38], the following agreement was made in the GTW session on Friday 21st May: Agreements: * 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: whether/how to avoid or minimize PUSCH resource fragmentation due to PUCCH transmission for the above case o Support the case when the centre frequency is assumed to be the same for the initial DL and UL BWPs in TDD. * FFS whether or not to additionally support the case when the centre frequency is different; if so, how to minimize centre frequency retuning 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.1-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. Xiaomi We share the same view with QC that we don＊t see strong need. But we can live with it DOCOMO Y Huawei, HiSi Y If the separate UL BWP function is supported for whatever reason, it should be up to gNB configuration whether to also use it in other cases. Lenovo, Motorola Mobility For TDD, this might depend on if same centre frequency for DL and UL initial BWPs is always assumed for RedCap Ues. NEC Y CATT We do not see strong needs, since the initial UL BWP for non-RedCap UE is sufficient to serve RedCap UE in this case. However, under the premise that such initial UL BWP configuration is optionally configured when the bandwidth of the initial UL BWP for non-RedCap does not exceed the maximum RedCap UE bandwidth, we can live with it. OPPO Y Support such flexibility for the network and the UE. Spreadtrum Y Nordic Y It is up to gNB, if gNB wants to configure separate Ros it can use configure them in that RedCap UL BWP. This is clear second-order issue. CMCC Y Nokia, NSB Y Ericsson Y We think such an option can be beneficial in terms of adding flexibility to the network for configuring the initial BWPs appropriately, from both UE and network perspectives. FUTUREWEI4 This SIB-configuration is optional, and as such, ※optional§ should be added to the preamble. In addition, a proposed modification adds these two sub-bullets * Optional configuration of a SIB-configured initial UL BWP is not required for early identification * RO sharing between RedCap and non-RedCap is still allowed LG Y If separate initial UL BWP is supported for any reason, then there is no need to restrict the usage for it. It can be left for gNB decision. FL4 Based on received responses, the following proposal for a working assumption can be considered. One response proposed a sub-bullet saying that optional configuration of a SIB-configured initial UL BWP is not required for early identification. Early identification of RedCap Ues is treated under another agenda item (8.6.2), so the proposed sub-bullet is not included in this proposal, but there is no intention that this proposed working assumption should be a step in the direction that optional configuration of a SIB-configured initial UL BWP is required for early indication. Medium Priority Proposal 3.1-3a: * Working assumption: Both during and after initial access, even for the scenario where the initial UL BWP for non-RedCap Ues is not configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP can optionally be configured/defined for RedCap Ues. o RO sharing between RedCap and non-RedCap is not precluded. Qualcomm Y We can live with this proposal. Vivo Y DOCOMO Y China Telecom Y Panasonic Y CMCC Y ZTE, Sanechips Y OPPO Y NEC Y Sharp Y 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] The following agreement regarding initial UL BWP was made in the GTW session on Friday 21st May: Agreements: * 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: whether/how to avoid or minimize PUSCH resource fragmentation due to PUCCH transmission for the above case o Support the case when the centre frequency is assumed to be the same for the initial DL and UL BWPs in TDD. * FFS whether or not to additionally support the case when the centre frequency is different; if so, how to minimize centre frequency retuning FL4 Medium Priority Question 3.2-1: * Considering the RAN1#105-e agreements listed above regarding initial UL BWP, which option(s) for enabling/supporting that a RACH occasion associated with the best SSB falls within the RedCap UE bandwidth should still be considered? Company Option(s) Comments Qualcomm Options 2 and 4 We support Option 2 and Option 4, and they are not mutually exclusive in our view. On the other hand, we do NOT think Option 1 (RF retuning) should be pursued any further for this question. As shown in our Tdoc (R1-2104677) and the figure below, RF retuning alone cannot solve the issue that the ※selected RO§ is outside the initial UL BWP of RedCap UE. vivo Option 2 and 3 If gNB configures separate initial UL BWP for RedCap Ues, option 2 is used. Otherwise, option 3 can be used by gNB implementation. Option 2: Separate initial UL BWP(s) for RedCap Ues 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) DOCOMO Options 2/3/4 If separate initial UL BWP is configured, option 2 with option 4 (i.e., dedicated PRACH configurations for separate initial UL BWP) is the straightforward way. Otherwise, either option 3 or 4 is selected by gNB depending on whether early indication is necessary or not. Panasonic Options 2/4 If the WA of separate initial UL BWP is confirmed, option 2/4 (dedicated configuration within separate initial UL BWP) is sufficient. CMCC Option2 We prefer a unified solution to deal with RO and PUCCH/PUSCH issue. If separate initial UL BWP can be configured for RedCap UEs, RO and PUCCH/PUSCH naturally fall within the RedCap UE bandwidth. ZTE, Sanechips Option 2 /Option 4 Option 2 and/or Option 4 depending on the specific configurations OPPO Option 1+Option 2 At least for TDD case, initial UL BWP for RedCap UE shall be configured/defined with the same central frequency as that of initial DL BWP. Therefore, the initial UL BWP for RedCap UE shall be configured/defined in the centre of that for non-redcap UEs. When the RO is outside that of the configured/defined initial UL BWP, RF retuning is allowed. Therefore, option 1 and option 2 shall be together adopted. NEC Option 2 Option 4 Option 3 would be always possible if the network wants. Sharp Option 2 (+option4) We understand Option 2 includes dedicated PRACH configuration. 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] The following agreement regarding initial UL BWP was made in the GTW session on Friday 21st May: Agreements: * 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: whether/how to avoid or minimize PUSCH resource fragmentation due to PUCCH transmission for the above case o Support the case when the centre frequency is assumed to be the same for the initial DL and UL BWPs in TDD. * FFS whether or not to additionally support the case when the centre frequency is different; if so, how to minimize centre frequency retuning FL4 Medium Priority Question 3.3-1: * Considering the RAN1#105-e agreements listed above regarding initial UL BWP, which option(s) for enabling/supporting that PUCCH (for Msg4/[MsgB] HARQ feedback) and/or PUSCH (for Msg3/[MsgA]) transmissions fall within the RedCap UE bandwidth during initial access should still be considered? Company Option(s) Comments Qualcomm Option 2. Option 3 can be FFS We prefer a unified solution for Question 3.2-1 and Question 3.3-1. vivo Option 2 and Option 4 We prefer unified solution for RO and other channels. If separate initial UL BWP is configured for Redcap UEs, all the concerned channels (RO, PUCCH (for Msg4/[MsgB] HARQ feedback) and/or PUSCH (for Msg3/[MsgA]) ) can be transmitted within the separate initial UL BWP for Redcap Otherwise, NW should (by implementation) guarantee that those channels falls into the Redcap UE BW, i.e. Option 4. DOCOMO Options 2/3/4 We also prefer unified solution for RO and FH. If separate initial UL BWP is configured, option 2 with option 3 (i.e., dedicated PUCCH/PUSCH FH configuration for separate initial UL BWP) is the straightforward way. Otherwise, option 4. Panasonic Options 2/3 The same comment as one for the RO issue. If the WA of separate initial UL BWP is confirmed, option 2/3 (dedicated configuration within separate initial UL BWP) is sufficient. CMCC Option2 We prefer a unified solution to deal with RO and PUCCH/PUSCH issue. If separate initial UL BWP can be configured for RedCap UEs, RO and PUCCH/PUSCH naturally fall within the RedCap UE bandwidth. ZTE, Sanechips Option 2 If separate initial UL BWP can be configured for RedCap UEs, RO and PUCCH/PUSCH naturally fall within the RedCap UE bandwidth. OPPO Option 2 At least for TDD case, initial UL BWP for RedCap UE shall be configured/defined with the same central frequency as that of initial DL BWP. Therefore, the initial UL BWP for RedCap UE shall be configured/defined in the centre of that for non-redcap UEs. NEC Option 2/3 Sharp Option 2 Same view as other companies. Same solution should be applied with the RO case. 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-1a: 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 Xiaomi Y DOCOMO Y We can live with adding the sub-bullet assuming that it does not preclude the possibility of supporting any advanced BWP operations for RedCap UEs Huawei, HiSi Ok with main bullet. Indeed the sub-bullet now is being more involved in other related discussion. ZTE, Sanechips Y Lenovo, Motorola Mobility Y NEC Y CATT Y OPPO Y Spreadtrum Y NordicSemi Y starting point is clear, discussion on FG6-1a is FFS. There was same starting point e.g. for CQI Table 3 (this 10-5 BLER target) in previous discussion. R15/R16 is a starting point for RedCap. For DCM, this does not preclude discussion on additional FGs, but we stress that for RedCap UE, clear KPI of low complexity has been stated in WID. CMCC Y LG Y Don＊t think the sub-bullet provides any meaningful information. But, we can live with that for that reason. FL4 Based on the received responses and GTW discussion on Friday 21st May, the following updated proposal can be considered. High Priority Proposal 4-1b: Agree the following revised version of the 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. * This does not preclude support of FG 6-1a (※BWP operation without restriction on BW of BWP(s)§ as described in TR 38.822). Qualcomm We suggest to revise the last sub-bullet as follows: * This does not preclude support of FG 6-1a (※BWP operation without restriction on BW of BWP(s)§ as described in TR 38.822) as an optinal UE capability for RedCap UE. vivo We think the clarification added by Qualcomm is important. DOCOMO Y We support the proposal as it is and prefer to keep the discussion on mandatory/optional capability open as it is related to Medium Priority Question 4-2. China Telecom We are fine with Qualcomm＊s revised proposal. Panasonic Y CMCC Y ZTE, Sanechips We don＊t agree to add ※This does not preclude support of FG 6-1a (※BWP operation without restriction on BW of BWP(s)§ as described in TR 38.822).§ There is no need to further clarify ※used as a starting point§. OPPO Y NEC Y Sharp 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. DOCOMO As pointed out by Qualcomm, this question is related to FL3 Medium Priority Question 2.3-2. We can come back once further progress is made there. Huawei, HiSi Y Our preference is to make it, or a similar one with modification as Intel commented to be mandatory. Non-RedCap UE does not necessarily to support FG 6-1a since it has wider max UE bandwidth so as to cover SSB as needed; this is not the case for RedCap and more important, if not supported, a RedCap UE bandwidth has to always contain SSBs which leaves few resources to be available for data transmission. CATT If supporting FG 6-1a is as easy as winking for a RedCap UE, we would support it without hesitation. But the question is, supporting FG 6-1a is unlikely to be easy and may lead to non-negligible impact on UE implementation. NordicSemi N presence of SSB is an essential part of NR design. It keeps UE implementation low complex. Nokia, NSB Our preference is for RedCap UE to also support FG 6-1a so that we don＊t need to have SSB in all BWPs. Ericsson Y Agree with Intel, Huawei, and HiSilicon. For now, we think FG 6-1a (or something similar) should be at least included in the discussion and not precluded as a potential mandatory feature. We can revisit this question after the BWPs discussions (both DL and UL, and both initial and non-initial) have reached agreements. FUTUREWEI4 As companies noted, FG 6-1a is optional in Rel-15/16, and OK to consider if we want to make it mandatory. If more time is needed, suggest we come back next meeting. FL4 The FL recommendation is to revisit the working assumption in a future meeting. No further comments are requested on this question at this point. 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. DOCOMO We are not sure whether the question includes mandatory support only or both mandatory/optional support. If latter one, there is no reason not to optionally support FG6-2/6-3/6-4. Huawei, HiSi For our understanding - for the proponent of BWP switch framework, would multiple BWPs be required (as mandatory/optional)? CATT Not sure about the motivation here. Is it trying to identify some optional feature as ＆not supported by RedCap UE＊, or to identify some mandatory feature as ＆optional for RedCap UE＊? But we can comeback to this question any way in the later phase. NordicSemi We could consider support of 6-4 where multiple BWPs have same config, but different frequency location. BWP switching framework can be reused as it is. Ericsson No strong view. We can revisit this question after the BWPs discussions (both DL and UL, and both initial and non-initial) have reached agreements. FUTUREWEI4 We can consider features if they are needed for RedCap UE FL4 The FL recommendation is to revisit the working assumption in a future meeting. No further comments are requested on this question at this point. 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 Huawei＊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 configuration 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 DOCOMO Y Huawei, HiSi Y ZTE, Sanechips N As we commented before, fast BWP switching is a higher capability beyond legacy NR UEs which is not aligned with the target of RedCap WID. No need to include the second paragraph. We don＊t think we need to differentiate FR1 and FR2 in the LS. We propose the following: 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 existing BWP switching time for non-RedCap UEs is sufficient for RedCap UEs. Lenovo, Motorola Mobility Y CATT Y OPPO Y Samsung Y We are fine with this version. Besides, if we can identify some solutions that may requires RF retuning/BWP change, it will be very helpful to RAN4 to understand what is the intention from RAN 1. Spreadtrum N 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 changed to BWP switching. If RF switching is not changed to BWP switching, we support vivo＊s version. NordicSemi Y. modification to LS is needed It is fine to ask RAN4, but feasibility, everything is feasible if UE has enough flash and strong cpu. 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. The other part is OK, except why should we preclude R15/R16 BWP switching for that case, scheduling DCI should be covered as well. Ericsson We don＊t see why RAN1 cannot ask RAN4 for input related to both FR1 and FR2. In particular since some of the addressed scenarios, e.g. related to initial access, would apply regardless of the frequency region. Furthermore, contributions have shown potential frequency diversity gains by operation in narrow allocations/BWPs in both FR1 and FR2, so it would be interesting to get guidance from RAN4 regarding the feasibility and constraints for such use cases. It shall be noted that regardless of the feedback received from RAN4, this will not automatically result in any feature relying on (fast) RF retuning being specified in RAN1. We are okay with the proposed revision on the 5th bullet from Qualcomm. Based on the received responses to Proposal 5-2 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 whether the switching delay for FR1 and FR2 could be for other potential cases, including at least one scenario based on reduced under the following assumptions (either as a mandatory or an optional UE capability): * 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 raster currently required * The maximum UE RF bandwidth is 20 MHz for FR1 and 100 MHz for FR2. o 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 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 either triggered by DCI or preconfigured and 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. FL4 High Priority Proposal 5-2a: * Send an LS on RF switching time to RAN4 with the updated LS text above. Company Y/N Comments Qualcomm N, if no differentiation is made between FR1 and FR2 For FR1, our view does not change and we think the existing BWP mechanism/framework of NR R15/16 (switching, configuration, timeline and related UE capabilities) is sufficient for RedCap UE. For FR2, we are supportive of sending an LS to RAN4, provided the LS is for FR2 only. vivo N We are fine with the 1st paragraph, but not fine with the 2nd paragraph. For the 2nd paragraph, based on the agreement achieved so far and the potential FL4 proposals, it is very unclear about the justification of the case stated in each bullet/sub-bullet. We cannot ask RAN4 such many open questions based on the collected individual companies proposals on which RAN1 consensus cannot be reached. DOCOMO Y China Telecom Y It is urgent needed for RAN1 to send the LS to ask RAN4 feedback. Panasonic Y ZTE, Sanechips N We are fine to send the LS with only the first paragraph For the second paragraph, we can ask RAN4 the related issues until RAN1 has consensus on these issues. OPPO Y We are supportive to send the LS to RAN4. 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. Annex: Companies＊ point of contact FL4 Question: Please consider entering contact info below for the points of contact for this email discussion. Company Point of contact Email address Qualcomm Jing Lei leijing@qti.qualcomm.com vivo Xueming Pan panxueming@vivo.com DOCOMO Shinya Kumagai shinya.kumagai@docomo-lab.com China Telecom Jing Guo guojing6@chinatelecom.cn Panasonic Shotaro Maki maki.shotaro@jp.panasonic.com ZTE Huiying Fang Fang.huiying@zte.com.cn OPPO Weijie XU xuweijie@oppo.com NEC Takahiro SASAKI takahiro.sasaki@nec.com Sharp Hiroki Takahashi takahashi.hiroki@sharp.co.jp 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 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 [37] R1-2105999 (Inbox) FL summary #1 on reduced maximum UE bandwidth for RedCap Moderator (Ericsson) [38] R1-2106000 (Inbox) FL summary #2 on reduced maximum UE bandwidth for RedCap Moderator (Ericsson)