3GPP TSG-RAN WG1 Meeting #106bis-e R1-21xxxxx e-Meeting, 11th 每 19th October 2021 Agenda Item: 8.6.1.1 Title: FL summary #1 on reduced maximum UE bandwidth for RedCap Source: Moderator (Ericsson) Document for: Discussion, Decision 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]. The final FLS for this agenda item from the previous RAN1 meeting can be found in [3]. This document summarizes contributions [4] 每 [30] submitted to agenda item 8.6.1.1 and relevant parts of contributions [31] 每 [33] submitted to agenda item 8.6.3 and captures this email discussion on reduced maximum UE bandwidth: [106bis-e-NR-R17-RedCap-01] Email discussion regarding aspects related to reduced maximum UE bandwidth 每 Johan (Ericsson) 1st check point: October 14 Final check point: October 19 The issues in this document are tagged and color coded with High Priority or Medium Priority. The issues that are in the focus of this round of the discussion in this meeting are furthermore tagged FL1. Follow the naming convention in this example: RedCapBwFLS-v000.docx RedCapBwFLS-v001-CompanyA.docx RedCapBwFLS-v002-CompanyA-CompanyB.docx RedCapBwFLS-v003-CompanyB-CompanyC.docx If needed, you may ※lock§ a spreadsheet file for 30 minutes by creating a checkout file, as in this example: Assume CompanyC wants to update RedCapBwFLS-v002-CompanyA-CompanyB.docx. CompanyC uploads an empty file named RedCapBwFLS-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 below). CompanyC then has 30 minutes to upload RedCapBwFLS-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-2108693), 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. Companies are invited to enter the contact info in the table below. FL1 Question 1-1: 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 OPPO Weijie Xu xuweijie@oppo.com Nordic Karol Schober karol.schober@nordicsemi.no Huawei, HiSilicon Wang Yi wangyi6@huawei.com Initial UL BWP Separate initial UL BWP for RedCap RAN1#105-e made the following agreements related to initial UL BWP: Agreements: 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. FFS: whether/how to avoid or minimize PUSCH resource fragmentation due to PUCCH transmission for the above case 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 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. RO sharing between RedCap and non-RedCap is not precluded. Moreover, we have the following proposal from the latest FLS in RAN1#106-e [3]: Proposal: Confirm the following modified version of the working assumption from RAN1#105-e: 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. If a separate initial DL BWP is configured, the centre frequency is assumed to be the same for the separate initial DL BWP and the separate initial UL BWP in TDD. If a separate initial DL BWP is not configured, the centre frequency is assumed to be the same for the MIB-configured initial DL BWP and the separate initial UL BWP in TDD. FFS whether or not to additionally support the case when the center frequency is different between the separate initial UL BWP and the initial DL BWP, and, if so, how to minimize center frequency retuning Regarding the initial UL BWP configuration during and after initial access, many contributions agree with the main bullets of the working assumptions from RAN1#105-e [6, 7, 11, 12, 13, 15, 21, 24, 25, 27]. That is: (1) 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, and (2) 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. Also, as already agreed in RAN1#106-e, Ros can be dedicated for RedCap Ues or shared with non-RedCap Ues. Regarding RO sharing, the FL＊s understanding is that Ros can be fully or partially shared between RedCap and non-RedCap Ues. Based on expressed views and agreements in RAN1#105-e and RAN1#106-e, the following combined proposal regarding a separate initial UL BWP for RedCap can be considered. FL1 High Priority Proposal 2.1-1: Regarding a separate initial UL BWP for RedCap in 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. 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. Company Y/N Comments Qualcomm Y Clarification is needed for the 2nd bullet For the scenario where the initial UL BWP for non-RedCap Ues is not configured to be wider than the RedCap UE bandwidth, configuring/defining a separate initial UL BWP for RedCap Ues by SIB will increase the signaling overhead. Clarification/justification is preferred regarding when/how the RedCap-specific initial UL BWP is configured/defined. Vivo Y OPPO Y For shared RO scenario, when the span of RO bandwidth exceeds RedCap UE maximum bandwidth, how to configure/define a separate initial UL BWP for RedCap needs to be further discussed. Nordic Y Huawei, HiSilicon Y if with modifications Our understanding is that a single separate initial UL BWP with a single frequency location for use, does not resolve some of the issues raised during initial access for e.g. RO vs SSB, PUCCH transmission for Msg4 (see R1-2108753). Modified FL1 High Priority Proposal 2.1-1: Regarding a separate initial UL BWP for RedCap in 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. 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. FFS how the configuration/determination is applied, e.g. by BWP switching or RF retuning ZTE, Sanechips Y We are fine with the FL proposal. 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 still be configured for RedCap UEs for the purpose of scheduling flexibility and early identification of RedCap. TCL Y Fine with the FL proposal PUCCH frequency hopping Regarding PUCCH transmissions (for Msg4/MsgB HARQ feedback) during initial access, we have the following agreement and working assumption from RAN1#106-e: Agreements: In case a separate initial UL BWP is configured for RedCap UEs, it is supported that the network can enable/disable intra-slot PUCCH frequency hopping within the separate initial UL BWP in the PUCCH resource for HARQ feedback for Msg4/MsgB for RedCap UEs. Working assumption: The frequency hopping is enabled/disabled at least via SIB. Several contributions discuss the signalling solution for disabling/enabling the PUCCH resource for HARQ feedback for Msg4/MsgB for RedCap UEs. Most of these contributions indicate that the PUCCH frequency hopping should be enabled/disabled only via SIB and that it is not preferred to use DCI [6, 10, 14, 15, 16, 24, 28, 29]. However, two contributions propose to use DCI (in addition to SIB) for enabling/disabling the PUCCH frequency hopping [4, 5]. Based on the above majority views and for the sake of progress, the following proposal can be considered. FL1 High Priority Proposal 2.2-1: Replace the RAN#106-e agreement and working assumption with: In case a separate initial UL BWP is configured for RedCap UEs, it is supported that the network can enable/disable intra-slot PUCCH frequency hopping within the separate initial UL BWP in the PUCCH resource for HARQ feedback for Msg4/MsgB for RedCap UEs. The frequency hopping is enabled/disabled at least via SIB. Company Y/N Comments Qualcomm Y If the RedCap-specific initial UL BWP fully overlaps with the initial UL BWP of non-RedCap UE, we don＊t see a need to disable the intra-slot FH of PUCCH for RedCap UE, if the intra-slot FH of PUCCH for non-RedCap UE is still enabled. vivo Y OPPO Y Nordic Y, but It is not clear how would such disabling work. Could only half of PUCCH resources within Resource set be used? Huawei, HiSilicon FFS There is no numerical result providing any effective analysis explaining why the FH function for PUCCH should be controlled by SIB. On the other hand, we find that PUCCH performance is degraded and it would be strongly desirable that enhancement can be ready for that if PUCCH FH has to be disabled and this enhancement needs to be well controlled by network 每 in a dynamic way considering user channel conditions. Also, there would be marginal spec impact if this can be indicated by dynamic PDCCH scheduling Msg4/MsgB. Additionally, the frequency hopping across a large BW is beneficial and important for the common PUCCH performance. Further discussion on the potential support of this is proposed. Thirdly, the resource multiplexing issue with non-RedCap UEs may require some further discussion, as in Medium Priority Question 2.2-2 Thus the proposal should be revised as Modified FL1 High Priority Proposal 2.2-1: Replace the RAN#106-e agreement and working assumption with: In case a separate initial UL BWP is used configured for RedCap UEs, it is supported that the network can enable/disable intra-slot PUCCH frequency hopping within the separate initial UL BWP in the PUCCH resource for HARQ feedback for Msg4/MsgB for RedCap UEs. The frequency hopping is can be enabled/disabled at least via SIB and DCI scheduling Msg4/MsgB. FFS inter-slot PUCCH frequency hopping outside UE maximum bandwidth ZTE, Sanechips Y TCL Y Fine with the FL proposal Moreover, two contributions point out that when the PUCCH frequency hopping (FH) is disabled, the orthogonality between non-FH PUCCH and FH PUCCH transmissions needs to be ensured, e.g., by using two time-domain orthogonal cover codes (OCC) sequences. [4]: For PUCCH format 1, support PUCCH without frequency hopping to be transmitted with two OCC sequences (as stipulated for legacy FH PUCCH). [19]: When intra-slot PUCCH frequency hopping within the separate initial UL BWP in the PUCCH resource for HARQ feedback for Msg4/MsgB for RedCap UEs is disabled, UE generates two base sequences for the PUCCH as if intra-slot frequency hopping is enabled for the PUCCH transmission. Medium Priority Question 2.2-2: Are any standard changes desired in order to support multiplexing of non-FH and FH PUCCH transmissions in PUCCH resources for HARQ feedback for Msg4/MsgB? If yes, please elaborate. Company Y/N Comments Huawei, HiSilicon The issue for PUCCH format 1 in [4] applies to PUCCH after initial access, instead of for HARQ for Msg4/MsgB. Therefore the question can be modified like Modified Medium Priority Question 2.2-2 Are any standard changes desired in order to support multiplexing of non-FH and FH PUCCH transmissions in PUCCH resources for HARQ feedback for Msg4/MsgB? If yes, please elaborate. One contribution also points out that when FH is disabled within the separate initial UL BWP, it is not clear which PRB index is to be used for the PUCCH transmission [19]. The contribution proposes to use either PRB index of first hop or second hop depending on the indicated r_PUCCH. This proposal can be considered at a later stage after other more critical proposals have seen some progress. Initial and non-initial DL BWP Separate initial DL BWP RAN1#105-e agreed the following working assumption related to separate initial DL BWP: Working assumption: At least for TDD, an initial DL BWP for RedCap UEs (which is not expected to exceed the maximum RedCap UE bandwidth) can be optionally configured/defined separately from the initial DL BWP for non-RedCap UEs at least after initial access FFS the details of the configuration/definition The configuration for a separately configured initial DL BWP for RedCap UEs is signaled in SIB. whether to support that separate initial DL BWP for RedCap UEs can include a configuration of CORESET and CSS(s) whether part of the configuration can be defined instead of signaled If a separate initial DL BWP for RedCap UEs is configured/defined, this separate initial DL BWP for RedCap UEs can be used at least after initial access (i.e., at least after RRC Setup, RRC Resume, or RRC Reestablishment). FFS during the initial access 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 FFS: supported bandwidths in the separate initial DL BWP FFS: whether additional SSB is transmitted in the separately configured initial DL BWP for RedCap UEs FFS: FDD case Moreover, we have the following proposal from the latest FLS in RAN1#106-e [3]: Proposal: Regarding random access in idle/inactive mode in separate initial DL BWP for RedCap UEs in FR1, If a separate initial DL BWP for RedCap UEs is configured in FR1, is configured for random access, including CORESET/CSS for random access. If the separate initial DL BWP is configured for random access but not for paging, then the UE shall not expect SSB transmission in the separate initial DL BWP. Note: The network may configure SSB in this case. Regarding paging in idle/inactive mode in separate initial DL BWP for RedCap UEs in FR1, From RAN1 perspective, if a separate initial DL BWP for RedCap UEs is configured in FR1, it can be configured for paging, including CORESET/CSS for paging. FFS: If the separate initial DL BWP is configured for paging, then the UE [may expect / shall not expect] SSB transmission in the separate initial DL BWP. FFS: Note: The network may configure SSB in this case. Regarding CORESET#0 and SIB1 in idle/inactive/connected mode for RedCap UEs in FR1, If a separate initial DL BWP for RedCap UEs is configured in FR1, then the UE shall not expect it to contain MIB-configured CORESET#0 or SIB1. Note: The network may configure MIB-configured CORESET#0 or SIB1 to be within the separate initial DL BWP. If an RRC-configured DL BWP is configured in FR1, then the UE shall not expect it to contain MIB-configured CORESET#0 or SIB1. Note: The network may configure MIB-configured CORESET#0 or SIB1 to be within the RRC-configured DL BWP. In connected mode, the UE is not required to monitor CORESET#0 periodically for SI updates. FFS: How SI update notifications are indicated to RedCap UEs Regarding connected mode in an RRC-configured active DL BWP for a RedCap UE in FR1, Whether the UE can expect SSB transmission in the RRC-configured active DL BWP depends on its UE capabilities (e.g., whether it supports FG 6-1a or only FG 6-1). A UE not supporting operation without SSB transmission in the RRC-configured active DL BWP may expect SSB transmission in the RRC-configured active DL BWP. This corresponds to mandatory RedCap UE feature. A UE optionally supporting operation without SSB transmission in the RRC-configured active DL BWP shall not expect SSB transmission in the RRC-configured active DL BWP. This corresponds to optional RedCap UE feature. FFS: For BWP#0 configuration option 1, whether the UE can expect SSB transmission in the separate initial DL BWP when it is used in connected mode Note: According to 38.331 Annex B.2, BWP#0 is considered to be an RRC-configured BWP in BWP#0 configuration option 2 but not in BWP#0 configuration option 1. Most of the contributions (e.g., [4, 5, 6, 7, 11, 12, 13, 15, 16, 18, 24, 26, 27, 29]) agree that configuring/defining a separate initial DL BWP for RedCap UEs is beneficial for flexibility and offloading purposes and also it is needed in scenarios where non-RedCap initial DL BWP is larger than the RedCap UE bandwidth. In addition, several contributions indicate that the configuration for a separately configured initial DL BWP for RedCap UEs can be signaled in SIB [6, 11, 12, 15, 24, 26]. In addition, several contributions support that an initial DL BWP for RedCap UEs can be optionally configured/defined separately from the initial DL BWP for non-RedCap UEs in FDD as well [12, 18, 24, 27]. Although there are several FFSs that need to be addressed, there is a general agreement about the optional configuration of a separate initial DL BWP for RedCap. Therefore, the following proposal can be considered, with the understanding that the FFSs regarding various aspects including CORESET #0, CSSs and SSB will be discussed subsequently. FL1 High Priority Proposal 3.1-1: A separate initial DL BWP can be optionally configured/defined for RedCap UEs and it can be signaled in SIB. This applies to both TDD and FDD cases. Company Y/N Comments Qualcomm We can agree with this proposal, if the conditions/motivations for the separate initial DL BWP configuration are provided same as FL1 High Priority Proposal 2.1-1. vivo We would like to clarify that this separate initial DL BWP can be used both during and after the initial access, hence we suggest modifying as below A separate initial DL BWP can be optionally configured/defined for RedCap UEs both during and after initial access and it can be signaled in SIB. This applies to both TDD and FDD cases. OPPO Besides the purpose of offloading, this separate initial DL BWP is also important for alignments of centre frequency of initial DL BWP and initial UL BWP. Therefore, the configuration/definition shall consider both initial DL and initial UL BWP. Nordic We are generally fine, but since there are unresolved issues for the offloading case, we should confirm WA on for the case that we know works. A separate initial DL BWP can be optionally configured/defined for RedCap UEs and it can be signaled in SIB. This applies to both TDD and FDD cases. This applies at least for the case when CORESET#0 and CD-SSB is within the separate initial DL BWP Huawei, HiSilicon Y with modifications Similar question as UL on how this single separate initial DL BWP interacts with the legacy initial DL BWP, i.e. BWP switching or RF retuning among different frequency locations. Suggest to modify the proposal as Modified FL1 High Priority Proposal 3.1-1: A separate initial DL BWP can be optionally configured/defined for RedCap UEs and it can be signaled in SIB. This applies to both TDD and FDD cases. FFS how the configuration/determination is applied, e.g. by BWP switching or RF retuning ZTE, Sanechips Y We are fine with the FL proposal. A separate initial DL BWP should be configured if BW of the legacy initial DL BWP exceeds the maximum RedCap UE bandwidth. As with TDD, a separate initial DL BWP can also be configured in FDD mode, which provides greater scheduling flexibility in the case of PDCCH blocking due to excessive number of accessed RedCap UEs. Besides, the configuration of the separate initial DL BWP applies a unified BWP configuration design for TDD and FDD. TCL Y The question mentioned by Huawei needs further study Next, the FFSs related to the separate initial DL BWP for RedCap are discussed. CORESETs and CSSs in separate initial DL BWP for RedCap Many contributions propose that a separate SIB-configured initial DL BWP for RedCap (if configured) does not need to contain the entire CORESET #0 [4, 5, 6, 8, 10, 11, 16, 18, 26]. Also, several contributions mention that the separate initial DL BWP for RedCap UEs can include a configuration of CORESETs and CSS(s) [4, 6, 11, 12, 13, 16, 23, 24, 27, 29]. In addition, one contribution proposes to support paging on separate initial DL BWP [31]. One contribution proposes to down-select from either mandating the separate initial DL BWP to always overlap with CORESET#0 or introducing a RedCap-specific CORESET#0 where RedCap UEs monitors paging and SI, in order to avoid BWP switching [33]. If neither of these options are configured by the network, the contribution proposes to consider the cell as barred for RedCap UEs. FL1 High Priority Proposal 3.1-2: A separate SIB-configured initial DL BWP for RedCap UEs (if configured) does not need to contain the entire CORESET #0. FFS: which CORESET(s) and CSS(s) that must be configured for separate initial DL BWP Company Y/N Comments Qualcomm N Defining/configuring a separate initial DL BWP for RedCap UE does not necessarily mean CORESET#0 cannot be contained within this initial DL BWP. When the SIB1-configured initial DL BWP of non-RedCap UE is wider than the max BW of RedCap UE (shown by the figure below), a separate initial DL BWP should be configured/defined for RedCap UE. In this case, the RedCap-specific initial DL BWP can be MIB-configured CORESET#0, or a SIB-configured separate initial DL BWP containing CORESET#0. vivo Y Our understanding is that the FL proposal does not exclude the possibility to contain entire MIB-configured CORESET#0 within the separately configured initial DL BWP. OPPO Y Or to make it clear. It can be modified as: A separate SIB-configured initial DL BWP for RedCap UEs (if configured) does not need to necessarily contain the entire CORESET #0. FFS: which CORESET(s) and CSS(s) that must be configured for separate initial DL BWP Nordic N We are NOT OK to support offloading from CORESET#0 unless NCD-SSB is agreed to be guaranteed at least in RRC A separate SIB-configured initial DL BWP for RedCap UEs (if configured) does not need to contain the entire CORESET #0. FFS: which CORESET(s) and CSS(s) that must be configured for separate initial DL BWP Note: This does change the SSB part of the previous agreement that FG 6-1 is a baseline Huawei, HiSilicon Y with modifications A separate SIB-configured initial DL BWP for RedCap UEs (if configured) does not need to contain the entire CORESET #0. FFS: whether/which CORESET(s) and CSS(s) that must be configured for separate initial DL BWP ZTE, Sanechips Y We are fine with the FL proposal. Mandatory inclusion of CORESET#0 limits the frequency-domain location and configuration flexibility of the separate initial DL BWP for RedCap UEs, which is detrimental to efficient resource utilization and PDCCH blocking resolution. Besides, if the separate SIB-configured initial DL BWP for RedCap UEs contains the entire CORESET#0 located in the carrier middle, the separate initial UL BWP for RedCap UEs also has to be placed in the carrier middle for TDD center frequency alignment, which will aggravate the PUSCH resource fragmentation. The FFS bullet is overlapped with question 3.1-3. It is suggested to be removed. TCL Introducing a RedCap-specific CORESET#0 may be an option when the separate initial DL BWP does not contain the (legacy) CORESET#0 FL1 High Priority Question 3.1-3: For a separate initial DL BWP for RedCap, which of the following CSSs can/must be configured? Random access CSS Paging CSS Any other CSS? Company Which ones of 1/2/3 can be configured? Which ones of 1/2/3 must be configured? Comments Qualcomm 1, 2, 3 (e.g. CORESET/CSS associated with PEI and SDT) 1, 2 The RO of RedCap UE is expected to be contained within the initial UL BWP of RedCap UE. Therefore, the CSS for RA should be configured within the initial DL BWP of RedCap UE. When operating in the separate initial DL BWP, RedCap UE is expected to receive notification of SI update and/or ETWS. Therefore, paging CSS should be configured in the initial DL BWP of RedCap UE. In addition to RACH and paging, RedCap UE is expected to support small data transfer (SDT) for power saving and signaling overhead reduction. Besides, CSS for R17 PEI can be configured as well in the initial DL BWP of RedCap UE. vivo 1 Random access CSS 2 Paging CSS 3 SIB, PEI, SDT related CSS) 1 1 must be configured for a separately configured initial DL BWP. 2 is preferable to be configured, but if not configured, UE stays at legacy initial DL BWP for paging monitoring and switch to the separately configured initial DL BWP only when random access procedure is performed. 3 If PEI is configured, it is preferred to configure in the same DL BWP as paging CSS. OPPO 1 Random access CSS 2 Paging CSS 1 Random access CSS If separately configured initial DL BWP is used to align centre frequency of initial DL BWP and initial UL BWP, CSS for Random access CSS shall be configured. CSS for paging can also be configured for offloading. If not, legacy MIB -configured initial DL BWP can be reused. Nordic SIB1, OSI, RA, Paging, PEI If BWP shall be used for IDLE camping or SDT then SIB1, OSI, RA, Paging Otherwise, RA is enough Huawei, HiSilicon 1, 2 None The same as legacy that those are configurable ZTE, Sanechips 1 and 2 None For the purpose of offloading, mitigating the impacts on legacy UE during paging and RACH procedure, and keeping the center frequency alignment in TDD RACH procedure, random access and/or paging can be configured in the separate initial DL BWP. TCL 1,2 1 Same comments of OPPO Use of separate initial DL BWP during initial access If a separate initial DL BWP for RedCap UEs is configured/defined, the separate initial DL BWP for RedCap UEs can be used during initial access [4, 6, 10, 11, 15, 18, 22, 27]. Contribution [6] states that for RedCap UEs, the IE locationAndBandwidth specified in the initial DL BWP can be applied and used during the initial access. FL1 High Priority Proposal 3.1-4: A separate initial DL BWP for RedCap UEs (if configured) can be used during the initial access. Company Y/N Comments Qualcomm Y vivo See our comments for FL1 High Priority Proposal 3.1-1. OPPO Y If separately configured initial DL BWP is used to align centre frequency of initial DL BWP and initial UL BWP, CSS for Random access CSS shall be configured. Therefore, it can be used during initial access Nordic Y Huawei, HiSilicon Y ZTE, Sanechips Y Similar motivation with question 3.1-3. The relation between question 3.1-4 and 3.1-3 need clarification. TCL Y Initial UL/DL BWP center frequency in TDD Another key consideration is related to initial UL/DL BWP center frequency in TDD. Several contributions support/accept having the possibility of separate TDD center frequencies for initial UL/DL BWPs during initial access [4, 6, 10, 12, 19, 26]. However, some other contributions indicate that the same center frequency is preferred to be maintained for initial UL/DL BWPs [7, 14, 15, 25]. [4]: During initial access, the alignment of the center frequency can be left to UE implementation without required by specification. [6]: During initial access, frequency retuning between initial DL and UL BWPs center frequencies is not expected to be an issue as far as the UE implementation is concerned, given the relaxed required switching time between DL and UL during initial access. [6]: With the support of separate center frequencies for initial UL/DL BWPs in TDD during initial access, all concerns regarding the PUSCH resource fragmentation and the presence of SSB and CORESET #0 within the initial DL BWP are resolved. [8]: At least after initial access, the center frequencies for separate initial UL/DL BWPs for RedCap UEs in TDD are the same. FFS: during initial access [26]: For initial DL/UL BWPs during initial access procedure, the RF-retuning latency and power consumption maybe acceptable. [27]: During initial access, timeline relationship in Tx/Rx switching may need to take center frequency retuning into account if different center frequency between initial DL BWP and initial UL BWP is supported. [28]: Supporting initial DL/UL BWP pair with different center frequencies is specified as an optional capability for RedCap UE in TDD. Based on the expressed views, the following question can be considered. FL1 High Priority Question 3.1-5: Regarding the initial UL/DL BWPs center frequencies in TDD during initial access, can the following options be considered for down selection? If yes, please indicate your preferred option(s). If no, please elaborate in the Comments field. Option 1: During initial access, the center frequencies for initial UL/DL BWPs can be different, and the initial DL BWP always contain CORESET #0 and SSB. Option 2: During initial access, the center frequencies for initial UL/DL BWPs are the same, but the initial DL BWP does not always contain CORESET #0 and SSB. Company Y/N Option(s) Comments Qualcomm N Option 2 is not supported since it does not contain SSB Option 2 is not acceptable to us. Option 1 can be FFS if separate PRACH resources are configured for RedCap UE within the initial UL BWP of RedCap UE. Without early indication of RedCap UE type by msg1 or msgA preamble, NW cannot differentiate RedCap UE and non-RedCap UE. As a result, RedCap UE may receive an invalid grant which does not accommodate the center frequency change of DL/UL BWP. vivo It seems necessary to clarify the proposal here is about the center frequency alignment between the separately configured initial UL BWP and initial DL BWP for RedCap UEs, since there might be a case where UE works on the separately configured initial UL BWP while share the legacy initial DL BWP with non-redcap UEs. The SSB transmission issue does not need to be coupled with the center frequency alignment issue, and can be discussed separately as later sections (3.2 and 3.3). OPPO During initial access, the center frequencies for initial UL/DL BWPs shall be the same. Otherwise, it will complicate UE＊s implementation and the timing during initial access shall be reviesed. Nordic N Non of the options Option 3: During initial access in TDD, the center frequencies for initial UL and CORESET#0 can be different CORESET#0 is within BW of initial UL BWP Huawei, HiSilicon Y Opt 2 is preferred The issue of the centre frequency alignment and BWP with/without SSB should be decoupled. On one hand, even if the centre frequency of UL and DL is different during initial access, the DL efficiency and other impact on network due to BWP mandated with SSB exists after initial access. Whether they are kept or not after initial access require further discussion and thus it does not tackle the fundamental issue. On the other hand, supporting BWP without SSB from initial access can release the concern of BWP center frequency misalignment regardless of during and after initial access, and have minor spec impact and implementation impact to both gNB and UE. ZTE, Sanechips Y 2 The transmission of legacy SSB and CORESET#0 in the separate initial DL BWP for RedCap UEs is up to gNB configuration. Requiring that the separate initial DL BWP always contain SSB and CORESET#0 greatly limits its frequency-domain location and configuration flexibility, which is detrimental to efficient resource utilization and PDCCH blocking resolution. Besides, there is no strong motivation or necessity to mandate SSB transmission in the separate initial DL BWP. Furthermore, to obtain a unified design, TDD center frequency alignment should be ensured during initial access as after initial access. It is noted that BWP#0 (i.e. the initial BWP) has two possible configuration options, i.e. BWP#0 configuration option 1 and BWP#0 configuration option 2. From the UE capability point of view, BWP#0 under configuration option 2 is considered as an RRC-configured BWP. In this case, RedCap UEs supporting only one BWP cannot meet different TDD center frequency alignment requirements during and after initial access. Therefore, TDD center frequency alignment should be mandatory both during and after initial access. TCL Y Option 1 SSB transmissions In this section, expressed views on transmission of additional SSBs in a separate initial DL BWP (if configured) and RRC-configured DL BWP. Whether to transmit additional SSBs in a separate initial DL BWP for RedCap There are different views on whether an additional SSB is transmitted in the separate initial DL BWP for RedCap. Some contributions [4, 6, 11, 12, 14, 16, 32] argue that transmission of additional SSBs in a separate initial DL BWP for RedCap is not needed and can result in significant overhead and increased inter-cell interference. Some other contributions propose that additional SSB in the separate initial DL BWP should be transmitted [13, 15, 17, 20, 24]. Moreover, several contributions indicate that transmission of additional SSB depends on the scenario considering CSSs (random access or paging), initial UL/DL BWP centre frequencies in TDD, DRX cycle, and SSB periodicity [6, 7, 8, 9, 18, 22, 23, 25, 26]. In particular, a few contributions propose that additional SSB transmission is not needed when the separate initial DL BWP does not contain paging CSS [6, 7, 9, 18, 22, 25, 26]. [4]: Non-cell defining SSB as additional SSB would cause system performance degradation and significant implementation complexity to network, while does not ensure UE measurement performance. [6]: Whether the network configures an additional SSB to be transmitted in the separate initial DL BWP for RedCap should be based on the SSB monitoring periodicity (i.e., SMTC configuration) and the DRX cycle. [6]: If the separate initial DL BWP is only configured for random access, then the UE does not expect SSB transmission in the separate initial DL BWP. In this case, the network may or may not configure an SSB in the separate initial DL BWP for RedCap. [6]: By supporting different center frequencies for initial UL/DL BWPs for RedCap in TDD during initial access, the initial DL BWP can always contain CORESET#0 and SSB while minimizing the PUSCH resource fragmentation. [8]: The periodicity for additional non-CD SSB is configurable and up to 160ms, which is controlled by the network to reduce the overhead. [12]: The separately configured initial DL BWP for RedCap UEs does not need to contain SSB. [13]: For RedCap UE in RRC idle/inactive, whether the UE can expect SSB transmission in the separate initial DL BWP depends the measurement accuracy of SSB outside of separate initial DL BWP. [14]: The separate initial DL BWP under BWP#0 configuration option 2 should include SSB and CORESET#0. [16]: SSB is not transmitted in separate initial DL BWP if the separate initial DL BWP does not contain CORESET #0. [18]: A UE may NOT expect SSB to be always configured within the separate initial DL BWP if the separate initial DL BWP is only configured with PDCCH CSS Type 1 mapped to CORESET #0A. [20]: RedCap UE may always expect either CD-SSB in MIB-configured initial DL BWP or non-CD-SSB within the initial DL BWP for RedCap UE [26]: For a separate initial DL BWP configured with Type-1 CSS without paging monitoring, SSB may not be configured for the separate initial BWP. [26]: For a separate initial DL BWP configured with paging monitoring, a Redcap UE in RRC_IDLE/INACTIVE state expects SSB transmission in the separate initial BWP if the UE monitors for paging on it. [32]: There is no/negligible impact on UE complexity and battery life due to UE RF retuning to measure on CD-SSB. Also, transmitting additional SSBs would have significant impact on system complexity, network planning, network energy savings, network capacity, inter-cell DL interference, UE data experience, and specifications. FL1 High Priority Proposal 3.2-1: Regarding SSB transmission in a separate initial DL BWP for RedCap in idle/inactive mode: If the separate initial DL BWP is only configured for random access but not for paging, then the UE shall not expect SSB transmission in the separate initial DL BWP. Note: The network may or may not configure SSB in this case. FFS: SSB presence when the separate initial DL BWP is configured for paging Company Y/N Comments Qualcomm N Even if the separate initial DL BWP is configured for random access of RedCap UE, idle/inactive RedCap UE should get notification of SI update and ETWS by paging. When paging CSS is configured for idle/inactive UE in the separate initial DL BWP, SSB should be transmitted in the same DL BWP. Vivo We think this proposal should be address together with FL1 High Priority Proposal 3.2-3 and FL1 High Priority Question 3.3-1 as a package for compromise, it would be hard trying to agree it alone. OPPO Y For RAR reception ,there can be no SSB in this separate initial DL BWP. Nordic N Depends on whether BWP is meant for camping or not. If BWP contains paging, OSI, SIB1 -> SSB is guaranteed. Huawei, HiSilicon Y ZTE, Sanechips Y If the separate initial DL BWP is only configured for random access, the network may not configure SSB in the separate initial DL BWP. As with Rel-15/16 UEs, it is possible that the initial DL BWP does not contain SSB, especially for frequency-division multiplexing patterns 2 and 3 in FR2. Besides, RedCap UEs can switch to the MIB-configured initial DL BWP by RF retuning when needed to receive the legacy SSB. For the ＆Note＊, it seems to indicate that the additional SSB can be configured by the gNB. It is more appropriate to say ※The network can configure the separate initial DL BWP containing SSB or not in this case.§ FL1 High Priority Question 3.2-2: Regarding SSB transmission in a separate initial DL BWP for RedCap in idle/inactive mode: If the separate initial DL BWP is configured for paging, should the UE always be able to expect SSB transmission in the separate initial DL BWP? Company Y/N Comments Qualcomm Y SSB transmission is essential in the DL BWP configured with paging CSS vivo Y If SSB transmission is not available in the initial DL BWP where UE monitors paging, paging detection performance may be degraded and UE power consumption will be increased. From decoding performance perspective, as discussed in UE power saving WI, at least one SSB prior to each paging occasion in the high SINR case, and two or three SSB in some low SINR case are required for UE IDLE mode loop convergence / time-frequency tracking. From power consumption perspective, according to TR 38.840, the slot-average power level is 50 power units for BWP switching, additional power consumption per paging cycle caused by two times BWP switching to receive SSB and paging is at least (50 power unit) * (3 slot) * (2 times of BWP switching) = 300 power units for Type 2 BWP switching delay, which is much higher than the power used for receiving PDCCH + PDSCH of 120 power unit with 20MHz BW. In addition, the extra 300 power unit is the lower bound of the additional power consumption assuming no additional waiting time for SSB or paging PDCCH reception after the BWP switching. OPPO Y Ag ree with vivo＊s analysis. Paging in this separate initial DL BWP is for offloading. If there is no SSB transmitted in this separate initial DL BWP, paging will be monitored in the legacy MIB-configured initial DL BWP. Nordic Y Huawei, HiSilicon N but From gNB point of view, there is no fundamental difference for SSB reception prior to RAR or paging. The need for UE to perform SSB measurement during initial access for paging reception would not be frequent. For a UE being able to receive RAR without SSB, it is equivalent for UE to receive paging without SSB on the same BWP. From UE point of view, (see R1-2108753 and R1-2109752) the BWP with or without SSB differs from whether SSB is simultaneously processed with data within the same BWP - thus, operation without SSB is actually less complexity. Without SSB, UE perform RF retuning for SSB measurement. This is mandatory supported by measurement gap in R15. So no complexity aspect is concerned. Power consumption could be different however the impact is negligible (around 1%), based on the methodology in TR 38.840 and 50 power units for BWP switching. Thus, we don＊t see significant issue for UE not expecting SSB in this case either. However, as also said from last meeting, we are ok to compromise in this case that there is network restriction for gNB to configure related DRX/paging/measurement configurations, such that a UE is not required to measure SSB to an extent that they consider will have non-trivial impact on their devices implementations. ZTE, Sanechips N The transmission of legacy SSB in the separate initial DL BWP for RedCap UEs is up to gNB configuration. From the UE perspective, the UE shall not always expect SSB transmission in the separate initial DL BWP. For example, in TDD, to reduce the PUSCH resource fragmentation, for the case that the SSB is located on the edge of the system bandwidth, gNB can configure the separate initial DL BWP containing the legacy SSB; If SSB is located near to the center of the system bandwidth, gNB can configure no SSB in the separate initial DL BWP and the RedCap UE can retune to the MIB-configured initial DL BWP for the reception of legacy SSB. Whether to transmit additional SSBs in an RRC-configured DL BWP for RedCap For RRC-configured DL BWP (e.g., non-initial BWP), the contributions generally agree that transmission of additional SSBs depends on the UE capability [4, 6, 13, 23, 28, 29, 30]. Specifically, for RedCap UEs supporting FG 6-1a, the network may or may not transmit additional SSBs in an RRC-configured active DL BWP, while additional SSB is transmitted for UEs with only basic FG 6-1 capability. [6]: For RedCap UEs supporting FG 6-1a, the network may or may not transmit additional SSBs in an RRC-configured active DL BWP. [10]: If SSB is always required in any active BWP of a RedCap UE in RRC_CONNECTED state, the SSB issue will be a disaster to the network. [11]: To balance UE power saving and network overhead, the following alternatives can be considered: RedCap UEs support FG 6-1a, no additional SSB is configured, RedCap UEs rely on CSI-RS/TRS for RRM and sync. RedCap UEs support FG 6-1, the active DL BWPs overlap with CD-SSB, and the center frequency of DL BWP and UL BWP can be unaligned. RedCap UEs support FG 6-1, while the SSB for RRM/sync can be non-CD SSB with large periodicity. [14]: The measurement gap/TRS/CSI-RS can be considered to accommodate SSB reception and CORESET#0 monitoring in a scenario where SSB and CORESET#0 is not transmitted within the UE BW. [28]: If a RedCap UE operates in an RRC-configured DL BWP without SSB, it expects to receive periodic TRS/CSI-RS in the SSB-less BWP. [29]: Support offloading from MIB-CORESET#0/CD-SSB, if at least in RRC connected mode and in RedCap UE＊s active BWP, a RedCap UE with baseline capability may expect gNB to transmit an SSB within the active BWP. FL1 High Priority Proposal 3.2-3: Whether the UE can expect SSB transmission in the RRC-configured active DL BWP depends on its UE capabilities (e.g., whether it supports FG 6-1a or only FG 6-1). A UE not supporting operation without SSB transmission in the RRC-configured active DL BWP may expect SSB transmission in the RRC-configured active DL BWP. FFS: details of SSB configuration (e.g., cell-defining SSB, non-cell-defining SSB, SSB periodicity) A UE supporting operation without SSB transmission in the RRC-configured active DL BWP shall not expect SSB transmission in the RRC-configured active DL BWP. FFS: RedCap UE capability for BWP operation Only FG 6-1, FG 6-1a, or any new FG suitable for RedCap Company Y/N Comments Qualcomm N A UE not supporting operation without SSB transmission in the RRC-configured active DL BWP may expect SSB transmission in the RRC-configured active DL BWP. FG 6-1 is mandatory for RedCap UE in FR1 FG 6-1a is optional for RedCap UE in FR1 vivo N The current formulation is not agreeable. We suggest the following update. FL1 High Priority Proposal 3.2-3: Whether the UE can expect SSB transmission in the RRC-configured active DL BWP depends on its UE capabilities (e.g., whether it supports FG 6-1a or only FG 6-1). A UE not supporting operation without SSB transmission in the RRC-configured active DL BWP may expect SSB transmission in the RRC-configured active DL BWP. This corresponds to mandatory RedCap UE feature. FFS: details of SSB configuration (e.g., cell-defining SSB, non-cell-defining SSB, SSB periodicity) A UE supporting operation without SSB transmission in the RRC-configured active DL BWP shall not expect SSB transmission in the RRC-configured active DL BWP. This corresponds to optional RedCap UE feature. FFS: RedCap UE capability details for BWP operation Only FG 6-1, FG 6-1a, or any new FG suitable for RedCap OPPO Agree with vivo＊s revision. Nordic N VIVO wording is OK, plus typo ※expects§ Huawei, HiSilicon N We want to note that existing FG6-1 alone will not hold anymore anyway, if we agree to support a separate initial DL BWP without CORESET#0. We want to also clarify that the existing FG6-1a only concerns UE specific RRC configured BWP. In that sense, our understanding is that the current proposal concerns more about the UE specific configurations to specific UEs. A BWP configured from SIB and applied after initial access may be assumed without SSB, i.e. irrelevant to the FG6-1a. We are ok with the following Modified FL1 High Priority Proposal 3.2-3: Whether the UE can expect SSB transmission in the RRC-configured active DL BWP depends on its UE capabilities (e.g., whether it supports FG 6-1a or only FG 6-1). A UE not supporting operation without SSB transmission in the RRC-configured active DL BWP may expect SSB or CSI-RS transmission in the RRC-configured active DL BWP. FFS: details of SSB or CSI-RS configuration (e.g., cell-defining SSB, non-cell-defining SSB, SSB periodicity) A UE supporting operation without SSB transmission in the RRC-configured active DL BWP shall not expect SSB transmission in the RRC-configured active DL BWP. FFS: RedCap UE capability for BWP operation Only FG 6-1, FG 6-1a, or any new FG suitable for RedCap ZTE, Sanechips Y We are generally fine with the proposal. For the FFS in the first bullet, we may need to determine whether we should reuse the legacy SSB (including CD SSB and NCD SSB ) firstly or just define a new SSB. Therefore, the following modification is suggested. FFS: details of SSB transmission in the RRC-configured active DL BWP(e.g., legacy SSB, new-defined SSB) Non-initial DL BWP operation RAN1#105-e made the following agreement related to non-initial BWP operation: Agreements: Take the following as an agreement, revised from 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. 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 mandatory 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) as a UE capability for RedCap UEs. Several contributions provide their views on non-initial BWP operation and in particular FG 6-1a ※BWP operation without restriction on BW of BWPs§. In some of the contributions, it is proposed to make FG 6-1a mandatory for RedCap [4, 6, 10, 11, 12, 14, 27]. As discussed in these contributions, FG 6-1a is beneficial in three aspects: 1) for multiplexing of SSB/CORESET#0 that are beyond the UE maximum bandwidth, 2) to be able to place the UL BWP at the band edge in TDD where CORESET#0 may not be present, and 3) to reduce the overhead of requiring BWP to contain SSB. In some other contributions, it is proposed to have FG 6-1a as an optional feature for RedCap [24, 28, 29, 30]. Meanwhile, a few contributions propose to have new or modified FGs for RedCap [6, 7, 18, 26]. [6]: The RedCap UE should support FG 6-1a or at least its special case where an RRC-configured DL BWP contains SSB but not CORESET #0. [7]: Define new capabilities like FG 6-1/6-1a/6-2/6-3/6-4 to consider SSB and CORESET of CSS presence in the UE-specific DL BWP. [18]: FGs #6-1 and 6-1a (at least FGs #6-1) should be adapted for RedCap Ues such that RedCap Ues mandatorily support operation in active DL BWPs that may not necessarily include CORESET #0. [26]: Introducing a new UE feature for Redcap to indicate whether it supports an active BWP configured with UE-specific search space (USS) without SSB, denoting as Feature-X A UE not supporting Feature-X expects SSB transmission in the active DL BWP configured with USS. [28]: If RedCap UE supports FG 6-1a and operates in a RRC-configured DL BWP without SSB, it expects to receive: periodic TRS for time/frequency tracking dedicated RRC signalling for SI update dedicated BFR-CSIRS-RACH resource, if BFR-CSI-RS is configured in the active BWP [28]: If RedCap UE supports FG 6-1a and operates in an active DL BWP with SSB but without CORESET#0 (or CSS for RMSI/OSI), it expects to receive: periodic TRS for time/frequency tracking CORESET/CSS for paging, or dedicated RRC signalling for SI update if paging CSS is not configured dedicated BFR-CSIRS-RACH resource, if BFR-CSI-RS is configured in the active BWP [32]: Non-initial DL BWP can be configured for RedCap Ues in a location which does not contain CD-SSB and MIB-configured CORESET#0. FL1 High Priority Question 3.3-1: Should RedCap Ues support FG 6-1a as a mandatory feature? If yes, if some additional features or signaling need to be supported to facilitate this, please elaborate in the Comments field. Company Y/N Comments Qualcomm N Supporting FG 6-1a as mandatory feature is against the principle of UE complexity reduction for R17 RedCap WI vivo N ※supporting operation without SSB transmission in the RRC-configured active DL BWP§ shall be optional for RedCap Ues. OPPO N Supporting FG 6-1a as mandatory feature is against the principle of UE complexity reduction for R17 RedCap WI. Nordic N Huawei, HiSilicon Y There is no evident analysis why FG6-1a increases UE cost. There could be minor impact on UE power consumption however given the analysis in R1-2109752 we think that is negligible. Even with that, towards a balance we can compromise as proposed in Proposal 3.2-3. Preferably, the existing FG 6-1a can be mandatory for RedCap, or can be modified to address some concerns for mandating it, e.g. Adding CSI-RS for UE to expect, if a UE does not support BWP without SSB only, or Adding network configuration restriction in order to not mandating UE to retune too frequent, if companies can accept FG 6-1a as mandatory together with this restriction ZTE, Sanechips Y The separate initial DL BWP becomes UE-specific RRC configured under BWP#0 configuration option 2. In this case, if separate initial DL BWP without SSB or CORESET0 is configured, the RRC configured BWP without SSB or CORESET0 is also supported. Specifically, for traffic offloading and TDD center frequency alignment purposes, both the separate initial DL BWP and other UE-specific RRC configured non-initial BWPs do not necessarily contain CORESET#0. Furthermore, mandatory FG 6-1a allows frequency-domain locations of UE-specific RRC configured BWPs not to be restricted by SSB/CORESET#0, which helps to mitigate the PUSCH resource fragmentation problem. Therefore, we believe that RedCap UEs should support FG 6-1a as a mandatory feature if separate initial DL BWP without SSB can be configured. Consequently, FG 6-1 is not needed. FL1 High Priority Question 3.3-2: Should any new or modified FG be defined for RedCap BWP operation (e.g., RRC-configured DL BWP contains an SSB, but it does not contain CORESET #0)? Company Y/N Comments Qualcomm FFS vivo We prefer to introduce new FGs for RedCap UEs, e.g. one new FG for 6-1 like operation (but not necessarily contain MIB-configured CORESET#0), another new FG for 6-1a like operation. OPPO Y This is new FG May be named as 6-1＆ It can be ※supporting operation with SSB transmission but not necessarily contain MIB-configured CORESET#0§ Nordic If offloading from CORESET#0 is supported, then 6-1 must be updated, but no change to SSB part of 6-1 ZTE, Sanechips It depends on the discussion of other issues. If 6-1a is mandatory, then no any new or modified FG need to be defined. If 6-1a is optional, whether new or modified FG is needed depends on the other issues discussion, e.g., SSB presence and CORESET0 configuration in separate initial DL BWP. RF retuning and BWP switching In RAN1#105-e, no consensus could be reached regarding whether an LS should be sent to RAN4 for their input on RF switching time. Many aspects related to BWP switching for UL and/or DL BWPs, as well as for initial and/or non-initial BWPs are already accounted for in the previous sections. For example, issues related to initial UL/DL BWP center frequency in TDD, and issues related to SSB or CORESET #0 potentially not being transmitted in initial/non-initial BWP for RedCap. Depending on the outcome of previous sections on initial UL/DL BWPs, RF retuning and/or BWP switching aspects may need to be discussed. Also, one contribution proposes that RRC configuration based, DCI-based and timer-based BWP switching are supported by RedCap UEs [31]. FL1 High Priority Question 3.4-1: Is there a need to send an LS to RAN4 to ask for input on RF retuning and/or BWP switching? If yes, please elaborate in the Comments field. Company Y/N Comments Qualcomm FFS RF retuning/BWP switching faster than the timeline of non-RedCap UE should not be supported by R17 RedCap UE. Type-2 BWP switching delay is supported as a baseline capability for BWP switching of RedCap UE. Vivo Faster RF retuning and/or BWP switching is not essential features to finalize Rel-17 RedCap feature, therefore should not be pursued any further. If any communication with RAN4 is needed, we think RAN1 should make the assumption that existing BWP switching delay are reused for RedCap Ues and confirm such assumption with RAN4. OPPO Y Many issues related to BWP switching and RF retuning. For example, if there is no SSB in the separate initial DL BWP, the UE needs to get synchronization from the MIB-configured initial DL BWP. If there is no SSB in the active BWP, the UE may retune to the MIB-configured initial DL BWP for RRM measurement. Nordic N Huawei, HiSilicon Y FL has well described the issue/scenarios 每 similar comments as in [4]. There is no BWP switching during initial access in R15 and there is no baseline capability (one type is required to be reported in R15). Thus, this needs to be revisited for RedCap in order to support BWP operation with separate initial BWP. ZTE, Sanechips Y but The motivation of the LS is trying to ask RAN4 whether the legacy RF retuning and/or BWP switching can be reused, instead of any optimization of the switching time. TCL Y Same comments with Huawei References [1] RP-211574 Revised WID on support of reduced capability NR devices Ericsson [2] R1-2108271 RAN1 agreements for Rel-17 NR RedCap Rapporteur (Ericsson) [3] R1-2108632 FL summary #7 on reduced maximum UE bandwidth for RedCap Moderator (Ericsson) [4] R1-2108753 Reduced maximum UE bandwidth Huawei, HiSilicon [5] R1-2108802 Further discussion on Bandwidth Reduction for RedCap UEs FUTUREWEI [6] R1-2108820 Reduced maximum UE bandwidth for RedCap Ericsson [7] R1-2108913 Discussion on aspects related to reduced maximum UE bandwidth Spreadtrum Communications [8] R1-2108981 Discussion on reduced maximum UE bandwidth vivo, Guangdong Genius [9] R1-2109082 Discussion on reduced UE bandwidth OPPO [10] R1-2109230 Discussion on reduced maximum UE bandwidth CATT [11] R1-2109287 Discussion on reduced maximum UE bandwidth CMCC [12] R1-2109310 Bandwidth Reduction for Reduced Capability Devices Nokia, Nokia Shanghai Bell [13] R1-2109326 Reduced maximum UE bandwidth for RedCap Lenovo, Motorola Mobility [14] R1-2109332 Bandwidth reduction for reduced capability NR devices ZTE, Sanechips [15] R1-2109417 Discussion on the remaining issues of reduced UE bandwidth for RedCap Xiaomi [16] R1-2109496 UE complexity reduction Samsung [17] R1-2109573 On reduced maximum bandwidth for RedCap UEs MediaTek Inc. [18] R1-2109617 Support of reduced max UE BW for RedCap Intel Corporation [19] R1-2109685 Discussion on reduced maximum UE bandwidth for RedCap NTT DOCOMO, INC. [20] R1-2109759 Discussion on reduced maximum UE bandwidth for RedCap NEC [21] R1-2109796 Discussion on reduced maximum UE bandwidth for RedCap Sony [22] R1-2109841 Aspects related to reduced maximum UE bandwidth for RedCap Panasonic Corporation [23] R1-2109948 Discussion on reduced maximum bandwidth for RedCap UEs InterDigital, Inc. [24] R1-2109975 Aspects related to the reduced maximum UE bandwidth of RedCap LG Electronics [25] R1-2109996 Discussion on reduced maximum UE bandwidth Sharp [26] R1-2110040 Reduced maximum UE bandwidth for Redcap Apple [27] R1-2110105 Discussion on aspects related to reduced maximum UE bandwidth ASUSTeK [28] R1-2110193 BW Reduction for RedCap UE Qualcomm Incorporated [29] R1-2110279 On aspects related to reduced maximum UE BW Nordic Semiconductor ASA [30] R1-2110314 Reduced maximum UE bandwidth for RedCap DENSO CORPORATION [31] R1-2109291 Discussion other aspects of RedCap UE CMCC [32] R1-2109752 On RedCap UE RF retuning Huawei, HiSilicon [33] R1-2109951 Considerations for RedCap initial BWP InterDigital, Inc.