3GPP TSG-RAN WG1 Meeting #106-e R1-21xxxxx e-Meeting, 16th 每 27th August 2021 Agenda Item: 8.6.1.1 Title: FL summary #2 on reduced maximum UE bandwidth for RedCap Source: Moderator (Ericsson) Document for: Discussion, Decision 1 Introduction This feature lead (FL) summary (FLS) concerns the Rel-17 work item (WI) for support of reduced capability (RedCap) NR devices [1]. Earlier RAN1 agreements for this WI are summarized in [2]. This document summarizes contributions [3] 每 [29] submitted to agenda item 8.6.1.1 and relevant parts of contributions [30] 每 [40] submitted to agenda item 8.6.3 and captures this email discussion on reduced maximum UE bandwidth: [106-e-NR-R17-RedCap-01] Email discussion regarding aspects related to reduced maximum UE bandwidth 每 Johan (Ericsson) * 1st check point: August 19 * 2nd check point: August 24 * Final check: August 27 The final FLS from the previous RAN1 meeting and the draft LS that was discussed then can be found in [41] and [42]. The issues in this document are tagged and color coded with High Priority or Medium Priority. In this round of the email discussion, please comment on the issues tagged &FL2* before Tuesday 17th August 23:00 UTC. Follow the naming convention in this example: * RedCapBwFLS2-v000.docx * RedCapBwFLS2-v001-CompanyA.docx * RedCapBwFLS2-v002-CompanyA-CompanyB.docx * RedCapBwFLS2-v003-CompanyB-CompanyC.docx If needed, you may ※lock§ the discussion document for 30 minutes by creating a checkout file, as in this example: * Assume CompanyC wants to update RedCapBwFLS2-v002-CompanyA-CompanyB.docx. * CompanyC uploads an empty file named RedCapBwFLS2-v003-CompanyB-CompanyC.checkout * CompanyC 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 RedCapBwFLS2-v003-CompanyB-CompanyC.docx * If no update is uploaded in 30 minutes, other companies can ignore the checkout file. * Note that the file timestamps on the server are in UTC time. In file names, please use the hyphen character (not the underline character) and include &v* in front of the version number, as in the examples above and in line with the general recommendation (see slide 10 in R1-2106403), 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 during initial access, 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, 7, 9, 13, 15, 16, 19, 20, 22, 23, 24, 25, 26, 27, 28, 29]. Moreover, most of these contributions indicate that a separate initial DL BWP (i.e., with separate/additional location and bandwidth) can be configured for RedCap UEs. One contribution [10] argues that there is no need to introduce a separate initial DL BWP for RedCap UEs during the initial access. Another contribution [12] mentions that a description of a separate DL BWP is needed before any agreements are made. Note that further clarifications and discussions regarding the separate initial DL BWP for RedCap are provided in Section 2.2 of this FL document. FL1 High Priority Proposal 2.1-1: Confirm the following RAN1#104bis-e working assumption with removed FFS from the third sub-bullet: * 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, HiSilicon Y Xiaomi Y Qualcomm Y In TDD operation, the center frequencies of the initial DL BWP and the initial UL BWP of RedCap UE should be aligned, regardless the initial DL BWP of RedCap UE is configured by MIB or SIB. Panasonic Y TCL Y OPPO Y Samsung We like to understand that whether ※BWP§ has the same definition/configuration of R-15/16 BWP, or this is open to have optimization of other definition/configuration. Moreover, we*d like to clarify the intention of the first sub-bullet, if our understanding is correct, we*d like to further update the second bullet as: RedCap UEs and non-RedCap UEs can share the same MIB-configured initial DL BWP (including the bandwidth and location). vivo Y Nordic Y ZTE, Sanechips Y MediaTek Y CMCC Y Sharp Y NEC Y Lenovo, Motorola Mobility Y CATT Y Spreadtrum Y LG Y DOCOMO Y Nokia, NSB Y Ericsson Y FUTUREWEI Y Intel Y Apple Y IDCC Y China Telecom Y FL2 Based on the received comments, the following updated proposal can be considered: High Priority Proposal 2.1-1a: Replace the RAN1#104bis-e working assumption with the following agreement: * 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 RedCap UEs and non-RedCap UEs can share the same MIB-configured initial DL BWP (including the bandwidth and location). 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). Lenovo, Motorola Mobility Y vivo Y Although we did not see the need for the update, we are fine to accept the latest version. DOCOMO Y China Telecom Y We are fine with the updated FL proposal. CMCC Y 2.2 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 o 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 o 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 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: supported bandwidths in the separate initial DL BWP o FFS: whether additional SSB is transmitted in the separately configured initial DL BWP for RedCap UEs o FFS: FDD case As described in several contributions (e.g., [4, 5, 6, 8, 9, 16]), configuring/defining a separate initial DL BWP for RedCap UEs can be beneficial for flexibility and offloading purposes. However, there are several FFSs identified in RAN1#105-e which need to be discussed. The FL proposes to confirm the main working assumption from RAN1#105-e regarding the separate initial DL BWP while keeping the FFSs which will be addressed in subsequent proposals. FL1 High Priority Proposal 2.2-1: Confirm the above working assumption from RAN1#105-e regarding the separate initial DL BWP while keeping the FFSs. Company Y/N Comments Huawei, HiSilicon Y Xiaomi Generally, we are OK with the main bullet. But we think we could step further to make more progress. Since the main bullet mainly talks about the case after initial access, in this case, it is possible that the SIB- configured initial DL BWP is wider than RedCap*s bandwidth in both TDD and FDD. It is a common issue, so separate initial DL BWP can be considered for RedCap in both TDD and FDD. So we suggest to remove the ※at least in TDD§ in the main bullet * 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 Qualcomm Clarification is needed for the pre-requisites of configuring/defining such a DL BWP If the initial DL BWP is separately configured and can be used by all RedCap UEs after initial access, it has to include at least: * SSB * CORESET and CSS associated with msg2/msg4/msgB/WUS/paging * Periodic TRS Panasonic Y TCL Partial Y Agree with Xiaomi's comments. The separate initial DL BWP should be considered in both TDD and FDD, and "at least in TDD" should be removed from the main bullet. OPPO Y Also agree with xiaomi that this can also be applied for FDD case. vivo Y And we are fine with same solution for FDD case. Nordic We support Xiaomi update. We see benefit from having separate initial DL BWP also for FDD, it allows more flexible deployments without extra capabilities from UE side. Moreover, if specification is developed for TDD there is no extra work to support also for TDD. ZTE, Sanechips Y We are also OK to remove &at least for TDD* MediaTek Agree with Qualcomm that we need to identify clear choices before deciding on the support for them. If a separate initial DL BWP is configured for all RedCap UEs then at least it needs to be configured with CORESET and CSS for RACH/WUS/paging. CMCC Y Sharp Y NEC Y Lenovo, Motorola Mobility Y We also prefer to remove ※at least for TDD§ in the first bullet, and remove the last FFS, ※FFS: FDD case§. CATT Y in principle The FFS points may need further check and should not be agreed directly. Spreadtrum Y LG Y We are okay as it is. And we would be happier if the WA could also apply to the FDD case. DOCOMO Y Nokia, NSB Y We are fine to also extend this to FDD case as well. Ericsson Y We are also fine with removing ※at least for TDD§. FUTUREWEI Since many of the FFS are treated in other proposals, we can postpone discussion on this proposal until later Intel Y Also support extending this to FDD. Apple N We cannot leave a &blank check* for separate initial DL BWP configuration for Redcap. Otherwise, it may result in mandating FG 6_1A for Redcap UEs if no additional agreement/consensus would be made for FFS sub-bullets. We support Qualcomm proposal that at least SSB and CSS associated with Msg2/Ms4 should be added to the configured separate initial DL BWP if it does not cover CD-SSB and CORESET #0. IDCC Y We agree that SSB and CSS can be defined. But we are ok to leave it as FFS and come back later. China Telecom Y The remaining FFSs should be further checked and be revisited later. FL2 This proposal can be revisited once the proposals below regarding the FFSs have been addressed. Next, the FFSs related to the separate initial DL BWP for RedCap are discussed. Details of the configuration/definition Most of the contributions indicate that the configuration for a separately configured initial DL BWP for RedCap UEs can be signaled in SIB [4, 5, 6, 18, 22, 23, 26, 28]. Also, several contributions mention that the separate initial DL BWP for RedCap UEs can include a configuration of CORESET and CSS(s) [4, 5, 6, 24, 29]. Meanwhile, the detailed signaling solution for the configuration of the RedCap initial BWP is up to RAN2 [4, 16]. Medium Priority Proposal 2.2-2: The configuration for a separately configured initial DL BWP for RedCap UEs can be signaled in SIB. * The separate initial DL BWP for RedCap UEs can include configuration of CORESET and CSS(s). * Detailed signaling solution for configurations is up to RAN2. Company Y/N Comments 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, 20, 24, 25, 29]. Contribution [4] states that for RedCap UEs, the IE locationAndBandwidth specified in the initial DL BWP can be applied and used during the initial access. One contribution [17] mentions that, during initial access, RedCap and non-RedCap UEs share the SSB, CORESET#0, SIB1 and initial DL BWP. FL1 High Priority Proposal 2.2-3: A separate initial DL BWP for RedCap UEs (if configured) can be used during the initial access. Company Y/N Comments Huawei, HiSilicon Clarification needed Suggest the proposal is conditioned as ※Can be used for aligning the DL and UL center frequency during initial access for unpaired spectrum.§ If not agreeable, we suggest to firstly proceed with discussion on the following issue for DL during initial access: * Whether a RedCap UE can be assumed to be able to perform RF retuning (FFS by BWP switching/retuning/hopping) * As a baseline, without additional SSB, what needs to be supported if a RedCap UE is configured with an initial DL BWP without BW containing SSB Xiaomi Y Separate initial DL BWP during initial access should be supported at least in TDD system to achieve the center frequency alignment in DL BWP and UL BWP. In FDD system, it may be considered for the traffic offloading. Although we don*t see strong motivation, we are open to discuss it and live with it. Qualcomm If the initial DL BWP separately configured for RedCap UEs can be used during initial access, it has to include: * SSB * CORESET and CSS associated with msg2/msg4/msgB and SI update Panasonic Y TCL Y OPPO Y Yes. To avoid frequency retuning for TDD case, since initial UL BWP for RedCap UE may have different centre frequency of the initial DL BWP configured by MIB. Samsung We*d like to clarify that RACH can perform in initial DL BWP. And we*d like to FFS on whether paging can be transmitted on this separate initial DL BWP. If whether this contains SSB is the discussion point, we suggest to combine the discussion with proposal 2.2-6 and potentially 2.2-4. In our view, we think no need to always transmit SSB and no need to always contain the entire CORESET #0. vivo Y Nordic We believe the question should be formulated as the following Does separate initial DL BWP not overlapping with CORESET#0 by MIB support any of these? * Paging * Random access * System information * System information update We believe that all should be supported if separate initial DL BWP is not overlapping with CORESET#0 by MIB ZTE, Sanechips Y Separate DL initial BWP has benefits for the traffic offloading and help reduce the RF retuning for TDD. MediaTek Only in TDD In FDD we do not see a strong motivation for separate initial DL BWP during initial access. In TDD the motivation is center frequency alignment. At a minimum, configuration with CORESET and CSS for RACH should be required during initial access. CMCC Y Separate initial DL BWP for RedCap UEs can be configured based on the requirement for TDD center frequency alignment and offloading. During the initial access, when the number of RedCap UEs is large, partial RedCap UEs can be offloaded to separate initial DL BWP to relieve the data transmission pressure on initial DL BWP, such as msg2/4 scheduling and other data transmission before RRC connection. When the number of RedCap UEs is small, RedCap UEs can still use initial DL BWP. Sharp Y At least the case of same center frequency between initial DL BWP and initial UL BWP was supported. To align the center frequency with separate initial UL BWP for RedCap UEs during initial access, the separate initial DL BWP can also be applied during initial access. NEC Is it correct understanding MIB-configured initial DL BWP (=CORESET#0) is at least used for SIB1 reception regardless a separate initial DL BWP can be used during initial access? Lenovo, Motorola Mobility Y Based on configuration, the separate initial DL BWP can either contain CORESET#0, or contain an additional CORESET. CATT Need FFS The load during RACH is quite small, and the offloading purpose is not well justified for the initial access phase. Using separate initial DL BWP for RACH may double the cell-common signals (e.g. SSB, CORESET#0&Type1 CSS, SIBx), which causes DL resource burden and inter-cell interference, but achieves no much gain foreseen. It is quite unclear that, what the &separate initial DL BWP during initial access* will be like? Does it mean SSB, CORESET#0, Type1 CSS must be included? We should not hurry to an agreement without understanding the design. Spreadtrum Y For offloading of paging, RAR, etc. For alignment of center frequency of the separate initial DL/UL BWP. LG Y DOCOMO Y Nokia, NSB This needs further discussion as we understand that this separate initial DL BWP may not contain CORESET#0. The main motivation as we understand it is for center frequency alignment in TDD. In our view, RF retuning can be used such that center frequency alignment is not necessary. For offloading of RACH and Paging, we think that the load will be high enough to motivate using the initial DL BWP for initial access. Ericsson Y After receiving SIB1 from PDCCH and PDSCH in the MIB-configured initial DL BWP, the RedCap UE can switch to the separate SIB-configured initial DL BWP during the initial access. Such flexibility in the location of the initial DL BWP during initial access is beneficial for TDD UL/DL center frequency alignment (if preferred) when the initial UL BWP is located at the edge of the carrier to minimize the PUSCH resource fragmentation. Moreover, using a separate SIB configured initial DL BWP during initial access can be beneficial for offloading purposes. FUTUREWEI It is unclear what the contents of this initial DL BWP are and whether the separate DL BWP is needed for FDD Intel See comments Agree with some of the above comments that further discussions would be necessary to ascertain what kinds of ※uses§ are being envisaged. In particular, it is not clear what would the UE behavior be for the separate initial DL BWP? In which ways are the separate initial DL BWP used and does the separate initial DL BWP duplicate all channels/signals from the MIB-indicated initial DL BWP? We agree with Nokia that the motivation for center frequency alignment in TDD can already be addressed with RF retuning without incurring significant impact to either UE implementation or system performance, especially in context of Idle/Inactive modes and initial access. If motivated by common control offloading, then this needs to be considered explicitly since, again, the questions related to DL-UL center frequency alignment in TDD, etc. would need to be addressed. Apple Y This is beneficial for offloading purpose and can reduce PDCCH blocking rate as also discussed in AI 8.6.1.2. IDCC Y China Telecom Y We support the separate initial DL BWP for RedCap UEs can be used during the initial access for the offloading purpose. FL2 Based on the received responses, the following updated proposal can be considered: High Priority Proposal 2.2-3a: A separate initial DL BWP for RedCap UEs (if configured) can be used during the initial access. * This can be used at least for aligning the DL and UL center frequency during initial access in TDD. * The separate initial DL BWP for RedCap UEs includes configuration of CORESET and CSS at least for RACH. Lenovo Motorola Mobility Y Separate initial DL BWP (with an additional CORESET) is also beneficial for offloading. vivo We have some comment/concern on the newly added sub-bullets: The necessity of having the 1st sub-bullet included in the agreement is not clear, as usually we do not capture the justification/motivation as part of the technical enhancement for agreement. If such justification/motivation is to be captured, we would like to have a complete list including the motivation of RedCap UE offloading. For the 2nd sub-bullet, we think CORESET/CSS for paging should also be included, there seems to be no concern raised during the previous round of discussion. DOCOMO Y China Telecom We support the main bullet in FL proposal. However, the new added sub-bullets related alignment between UL and DL center frequency and configuration of CORESET and CSS need more discussion. We see no need to be added here. CMCC Y If separate initial DL BWP is configured, separate initial DL BWP can also be used for offloading when there exists requirement on offloading. Whether a separate SIB-configured initial DL BWP contains the entire CORESET #0 Most contributions propose that a separate SIB-configured initial DL BWP does not need to contain the entire CORESET #0 [4, 5, 6, 8, 15, 18, 20, 23, 24, 29]. One contribution [16] thinks that a separately configured initial DL BWP for RedCap UEs needs to contain the entire CORESET #0. FL1 High Priority Proposal 2.2-4: A separate SIB-configured initial DL BWP for RedCap UEs does not need to contain the entire CORESET #0. Contribution Y/N Comments Huawei, HiSilicon Clarification needed For unpaired spectrum during initial access, the separately SIB-configured DL BWP does not need to contain the entire CORESET#0 and any other CORESETs, i.e. the proposal does not imply the need of additional CORESET#0 for RedCap UEs. Xiaomi We think more discussion for the proposal is needed (1), Currently, how to configure or define the initial DL BWP is not decided. Furthermore, the configuration/definition manner may be different for the case of during initial access and after initial access (2) In addition, whether the initial DL BWP need to contain entire CORESET#0 may be different in different case. For example, if a separate DL BWP is configured/defined for the usage during initial access, in this case, we think this separate initial DL BWP is not necessary to contain CORESET#0. But if during the initial access, RedCap and non-RedCap share the same SSB, CORESET#0 and a separate initial DL BWP is needed for RedCap after initial access (e.g., SIB configure a wider initial BWP for non-RedCap), in this case, we think this configured/defined initial DL BWP should contain the CORESET#0 Considering there is still some instability in this proposal, we suggest to deprioritize this proposal and comeback it when the configuration of initial DL BWP is more stable. Qualcomm FFS This proposal has lower priority than 2.2-1 and 2.2-3. Panasonic Y We assume ※CORESET #0§ here is ※MIB-configured CORESET #0§ (but not the separate CORESET #0 dedicated for RedCap UEs). If not, clarification may be needed. In our view, it is up to gNB whether a separate SIB-configured initial DL BWP for RedCap UEs contains the entire MIB-configured CORESET #0. TCL Same view with Xiaomi and QC. Deprioritize the proposal. OPPO Y This BWP is configured by SIB for redcap UE. And it is agreed to be used after initial access and it may be used during initial access (depending on further agreements) Samsung Y Seems better to discuss together with proposal 2.2-3 vivo Y Nordic There has been huge ambiguity in contributions, there must be strict differentiation between CORESET#0 by MIB and Common CORESETs configured by pddch-ConfigCommon need for pdcch-ConfigCommon is depending on whether we support paging, SI, RACH, etc. ZTE, Sanechips Y Agree with the proposal. If the DL initial BWP must contain the entire CORESET0, it would cause the frequency location of DL initial BWP quite limited. The benefits for traffic offloading and RF retuning for TDD by separate initial DL BWP, would be limited by introducing this CORESET0 included in the DL initial BWP. MediaTek We share the same interpretation as Panasonic. We are not sure whether the _partial_ overlap with MIB-defined CORESET#0 (due to separate centre frequency or reduced bandwidth) is a relevant scenario, at least, during initial access. CMCC Y For offloading purpose, the separate initial DL BWP can avoid totally overlapping with CORESET#0, so it doesn*t need to contain the entire CORESET #0. Sharp Y NEC Isn*t it necessary in TDD MIB-configured initial DL BWP which would be used for SIB reception is within bandwidth of a separate initial UL BWP configured/defined for RedCap UE? Lenovo, Motorola Mobility Y Base on gNB configuration, the separate initial DL BWP can either contain CORESET#0, or an additional CORESET. CATT Y in general Similar understanding with Panasonic. To be more specific, we think the &CORESET#0* in the proposal means the original one derived from MIB, and does not mean a &shadow* or &mirror* or &same configuration* one, but with different frequency location. Assuming the separate initial DL BWP only applies after the initial access, it seems acceptable that the original CORESET#0 is not included entirely. Otherwise the location of separate initial DL BWP will be very limited. Spreadtrum Y LG Y DOCOMO Y Nokia, NSB Y Ericsson Y In a TDD scenario, with initial UL BWP being located at the edge of the carrier, the initial DL BWP can also be placed close to the edge of the carrier and be co-centered with the initial UL BWP. Since CORESET #0 may not be at the carrier edge, the initial DL BWP for RedCap may not cover the entire CORESET #0 bandwidth. If a separate SIB-configured initial DL BWP for RedCap UEs needs to contain the entire CORESET #0, the flexibility of this separate initial DL BWP is very limited, and so is its usefulness. FUTUREWEI Further clarification between the roles of CORESET#0 and other CORESET is needed with the separate SIB-configured initial DL BWP for RedCap UEs. For example, is the other CORESET used for the RACH procedure? Intel Y Although this proposal is somewhat tied to Proposal 2.2-3, we agree that mandating the separate initial DL BWP to contain the MIB-defined CORESET #0 would be too restrictive to be of much practical relevance for such a configuration. Apple This proposal is incomplete for us. Rel-15/16 already supports that a BWP does not include CORESET #0. In this case, UE is not required to monitor the corresponding CSS associated with CORESET#0 e.g., SIB. The additional discussion point should be: what are UE behaviors for initial DL BWP that does not contain the CORESET#0 e.g., monitoring SIB information. Is Redcap UE is mandated to switch by RF retuning to monitor SIB or does NOT require to monitor as in Rel-15/16? IDCC Y China Telecom Y We agree that there is no need to contain the entire CORESET#0 for the separated SIB-configured initial DL BWP. The entire CORESET#0 occupies frequency resources and may be harmful to offloading purposes. Due to no entire CORESET#0, it can use RF retuning to switch periodically or non-periodically to solve this problem. And the potential switching is not expected to be frequent. FL2 Based on the received feedback, the following updated proposal can be considered: High Priority Proposal 2.2-4a: A separate SIB-configured initial DL BWP for RedCap UEs does not need to contain the entire MIB-configured CORESET #0. Lenovo, Motorola Mobility Y vivo Y DOCOMO Y China Telecom Y We support FL proposal. CMCC Y Supported bandwidths in the separate initial DL BWP There are only a few views on the supported bandwidth of the separate initial DL BWP: * [5]: The supported bandwidths in the separate initial DL BWP for RedCap UEs should take following factors into account: CSS types supported in the separate initial DL BWP, UE*s complexity for DCI size determination for fallback DCI formats, and NW*s configuration flexibility and efficiency for resource usage. * [12]: If a separately initial BWP is supported, the possible bandwidths are among the bandwidths for CORESET#0 derived from the MIB. * [16]: Reuse the existing setting for deriving locationAndBandwidth with constraints on the ranges of the values. Based on the presented views, the bandwidth of a separate initial DL BWP can be either be flexible (i.e., various values up to the RedCap UE bandwidth) or limited to a set of pre-defined values such as CORESET #0 bandwidth. Since this topic are not discussed by many contributions and it will not affect the subsequent discussions, the FL suggests deprioritizing this topic. Medium Priority Proposal 2.2-5: The discussion on the supported bandwidths in the separate initial DL BWP for RedCap is not prioritized. Company Y/N Comments Nordic If this aspect is not taken into account, Nordic may not support separate initial DL BW not overlapping with CORESET#0 by MIB to be used during IDLE FL Based on the received feedback, the discussion on the supported bandwidths in the separate initial DL BWP for RedCap can be treated once the other proposals have seen some further progress. Whether to transmit additional SSB There are different views on whether an additional SSB is transmitted in the separate initial DL BWP for RedCap. Some contributions [3, 4, 6, 8, 9, 12] argue that transmission of additional SSBs in a separate initial DL BWP for RedCap may not be 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 [5, 11, 18, 22, 24, 26, 28]. * [4] discusses that whether the network configures an additional SSBs to be transmitted in the separate SIB-configured initial DL BWP for RedCap should be based on the SSB transmission periodicity and the DRX cycle. * [18] mentions that additional SSB can be transmitted in the separate initial DL BWP for RedCap UEs with a periodicity larger than CD SSB to reduce the overhead of gNB. * [19] discusses that Rel-15/16 supports configuration of additional SSB, which can also be used for RRM measurement by legacy UEs, and that optimization of SS-block for the purpose of RedCap UEs can be further studied. * [21] argues that if SSB may need to be duplicated in a RedCap UE*s active DL BWP, some means to avoid a false detection of the duplicated SSB by other UEs as a cell-defining SSB will be needed. FL1 High Priority Proposal 2.2-6: Transmission of additional SSBs in the separate initial DL BWP for RedCap can be configured by the network. * FFS: details of the configuration when additional SSBs are configured * FFS: details of the configuration when additional SSBs are not configured Company Y/N Comments Huawei, HiSilicon N We think using the same initial DL BWP for SSB reception and RF retuning of UEs as needed, is a simpler and more implementable solution. R15/R16 specifications also support RF retuning operations in e.g. BWP switching, SRS switching and Tx switching and they are commercially used for non-RedCap UEs already. We do not see the need to additionally configure the additional SSBs which cause unnecessary overhead, increase complexity for network planning, and require more handling of both UE and gNB for collision. Additional SSB is rarely commercially used in practically networks as its drawbacks held above. Xiaomi N This proposal is related to the capability of FG 6-1a (※BWP operation without restriction on BW of BWP(s)§. In Rel-15/16, the capability of is optional and this principle can be reused for RedCap Since initial DL BWP is also monitored by the RedCap UEs without capability of FG 6-1a, the separate initial DL BWP should include SSB to enable these devices to work. As this proposal is related to Question 4-1, we suggest to depriortize this proposal revisit it when there is conclusion for Question 4-1. Qualcomm Additional SSB should be transmitted in the separately configured initial DL BWP of RedCap UE, if the BWP does not contain the CD-SSB of non-RedCap UE Panasonic Y OPPO N If separate initial DL BWP is used and there is no RS, how the UE do RRM RLM/measurements? Frequent retuning shall be avoid for RedCap UE to save power consumption and reduce the complexity. Samsung We are general Ok with ※can be configured§. However, it might be better to change to the following, which, we think, is the key of this proposal. ? Support no additional SSBs transmission in the separate initial DL BWP for RedCap. vivo N As agreed that FG 6-1 is used as a starting point for the mandatory RedCap UE type capability. Therefore, we think additional SSB should be transmitted in the separate initial DL BWP for basic RedCap UEs. And the additional SSB does not needs to support initial access thus its transmission can be configured as sparse, e.g. up to 160ms periodicity, therefore no significant issue for NW overhead perspective. For RedCap UEs that optionally support FG 6-1a, transmission of additional SSBs in the separate initial DL BWP for RedCap can be configured by the network. In addition, it is not clear what the second FFS means. Nordic Y Non-cell defining SSB with large periodicity is MUST if separate initial DL BWP is allowed to be configured not to be overlapping with CORESET#0. ZTE, Sanechips Clarification, the difference between legacy additional SSB for NR and the additional SSB in the proposal, should be considered before conclusion. MediaTek Y Non-cell-defining SSB can be configured. Without it, FG 6-1a needs to be supported by the UE. CMCC Y If additional SSB is configured in separate initial DL BWP, the period of additional SSB should be larger than CD SSB, the additional SSB is non-CD SSB without scheduling of SIB1 to reduce payload of PBCH. If additional SSB is not configured, TRS based synchronization, RRM measurement via CSI-RS need to be performed in separate initial DL BWP. NEC If it is supported that a separate initial DL BWP for RedCap UE does not contain CD-SSB, additional SSB should be transmitted within the separate initial DL BWP. Lenovo, Motorola Mobility Clarification needed Need clarify whether this additional SSB is a cell defining SSB for RedCap or just for measurement. CATT We hope that, a gNB should not be forced to transmit SSB in the separate initial DL BWP. The DL resource cost is too large and inter-cell interference is not negligible. As mentioned in previous 2.2-3, the most robust solution is to share SSB, CORESET#0, SIB1 and initial DL BWP during initial access Spreadtrum Y DOCOMO Y We support either additional SSBs in the separate initial DL BWP or RedCap UEs supporting FG6-1a as a mandatory feature Nokia, NSB Our preference is for UE to support FG6-1a such that SSB needs not be configured in the separate initial DL BWP. Although of course additional SSB can be configured, it may be better to first consider whether UE can support FG6-1a such that additional SSB may not be needed. Ericsson Y We have similar view as Huawei regarding the overhead and the complexity. However, we are fine with the proposal as long as it is not mandatory for NW to transmit additional SSBs in the separate initial DL BWP. FUTUREWEI This is related to issue 4-1. They should be discussed together Intel Y, but While we can agree to configurability of additional SSBs in the separate initial DL BWP as we agree with the incurred OH/NW planning complexity from additional configurations for SSBs, the key message seems requirement on UE to operate in a separate initial DL BWP that may not have SSBs. In this regard, it may be considerable to spell it out and agree on this component (expectation from UE) as well to avoid misunderstandings down the road. Apple N The additional SSB &shall be* configured. Using &can be* means it is left for gNB scheduler and cannot address the power consumption and complexity concerns caused by frequent RF retuning operation, if it happens. Currently, SSB periodicity is configurable up to 160 ms and controlled by network. The SSB overhead should not be a real concern. IDCC Y The network can trade-off overhead vs. UE complexity and configure the non-CD-SSBs if needed. FL2 Based on the received responses, the following updated proposal can be considered, which attempts to consider that there are different views regarding the necessity of SSB transmission in the separate initial DL BWP for RedCap and its feasibility from signaling overhead point of view. High Priority Proposal 2.2-6a: * If a separate initial DL BWP for RedCap is configured, then SSB is transmitted in the separate initial DL BWP for RedCap. o FFS: suitable SSB periodicity considering impacts in terms of signaling overhead and performance Lenovo, Motorola Mobility Y vivo Y DOCOMO Can live with the proposal The separate initial DL BWP may or may not include CD-SSB. It should be clarified ※SSB§ in the proposal is not CD-SSB and the additional SSB has to be transmitted if the separate initial DL BWP for RedCap does not include CD-SSB China Telecom Y We support FL proposal. The suitable SSB periodicity should be decided with taking overhead and performance into consideration. CMCC Regarding the overhead of transmitting SSB, it is preferred that transmitting additional SSB in separate initial DL BWP is configurable by gNB. If additional SSB is configured, the additional SSB is non-CD SSB used for synchronization and RRM measurement, the period of additional SSB can be larger than CD SSB to reduce overhead. Separate initial DL BWP in FDD case 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 [6, 8, 9, 15, 16, 20, 21, 26, 27, 28, 29]. Medium Priority Proposal 2.2-7: An initial DL BWP for RedCap UEs can be optionally configured/defined separately from the initial DL BWP for non-RedCap UEs in FDD. Company Y/N Comments Lenovo, Motorola Mobility Suggest to add ※For both during initial access and after initial access§ at the beginning of the proposal. 2.3 Initial DL BWP after initial access RAN1#105-e agreed the following working assumption related to initial DL BWP after initial access: 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. Regarding the initial DL BWP after initial access, the working assumptions state that a RedCap UE is not expected to operate with an initial DL BWP wider than the maximum RedCap UE bandwidth for BWP#0 configuration option 1 and option 2. Most of the contributions [4, 5, 6, 7, 8, 12, 13, 15, 17, 18, 19, 20, 22] agree to confirm these working assumptions. FL1 High Priority Proposal 2.3-1: Confirm the following working assumptions from RAN1#105-e: * 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. * 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. Company Y/N Comments Huawei, HiSilicon Y Xiaomi Y Qualcomm Y Panasonic Y TCL Y OPPO Y Samsung Same comment as for proposal 2.1-1 We like to understand that whether ※BWP§ has the same definition/configuration of R-15/16 BWP, or this is open to have optimization of other definition/configuration. vivo Y Nordic Y ZTE, Sanechips Y MediaTek Y CMCC Y Sharp Y NEC Y Lenovo, Motorola Mobility Y CATT Y Spreadtrum Y LG Y DOCOMO Y Nokia, NSB Y Ericsson Y FUTUREWEI Y Intel Y Apple Y IDCC Y China Telecom Y FL2 Based on the received responses, the same proposal can be considered again: High Priority Proposal 2.3-1: Confirm the following working assumptions from RAN1#105-e: * 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. * 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. Lenovo, Motorola Mobility Y vivo Y DOCOMO Y China Telecom Y CMCC Y 3 Initial UL BWP 3.1 General RAN1#105-e made the following agreements related to initial UL BWP: 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 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. Regarding the initial UL BWP configuration during and after initial access, many contributions agree with the main bullets of the working assumptions (while keeping the FFSs) presented in RAN1#105-e [4, 12, 13, 14, 18, 19, 22, 26, 27]. One contribution [12] points out that the relationship between both working assumptions regarding separate initial UL BWP for RedCap UEs and RO sharing between RedCap and non-RedCap UEs must be clarified. Regarding RO sharing, the FL*s understanding is that ROs can be fully or partially shared between RedCap and non-RedCap UEs. Companies are encouraged to provide necessary clarifications if needed. FL1 High Priority Proposal 3.1-1: Confirm the following 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. 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 Company Y/N Comments Huawei, HiSilicon Y although We think it is more urgent to resolve the FFS. Xiaomi Y Qualcomm Partially ? 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 RedCap UE, center frequency should be the same for the initial DL and initial UL BWPs in TDD operation. ? Different center frequencies are NOT supported for the initial DL and initial UL BWPs in TDD. Panasonic Y TCL Y OPPO Y Samsung Same comment as for proposal 2.1-1 ? We like to understand that whether ※BWP§ has the same definition/configuration of R-15/16 BWP, or this is open to have optimization of other definition/configuration. vivo Y Nordic Y FFS should be removed ZTE, Sanechips Y CMCC Y Sharp Y NEC Y Lenovo, Motorola Mobility Y CATT Y Spreadtrum Y LG Y DOCOMO Y Nokia, NSB Y Ericsson Y FUTUREWEI Partially Further clarification about the proposal: it seems that whether/how to avoid PUSCH fragmentation is also applicable for the connected state, not only during initial access. Is that correct? Unlike initial access, the network can minimize fragmentation because the network knows the capabilities of the UE in the connected state Intel Y Apple Y IDCC Y China Telecom Y FL2 Based on received responses, the same proposal can be considered again: High Priority Proposal 3.1-1: Confirm the following 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. 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 Lenovo, Motorola Mobility Y vivo Y DOCOMO Y China Telecom Y CMCC Y There are two FFSs pertaining to configuring a separate initial UL BWP for RedCap UEs: Avoiding or minimizing PUSCH resource fragmentation One issue with separate initial UL BWP for RedCap and non-RedCap UEs is the potential PUSCH resource fragmentation due PUCCH transmissions. According to the WID, coexistence with non-RedCap UEs needs to be ensured. Therefore, while supporting RedCap UEs, it is essential to minimize the impact on non-RedCap UEs. Several contributions discuss that the potential PUSCH resource fragmentation can be minimized by placing the RedCap initial UL BWP at one edge of the carrier and/or disabling the PUCCH frequency hopping [3, 4, 8, 10, 17, 18, 22, 23, 24, 25]. In particular, the network should be allowed to disable the PUCCH frequency hopping for RedCap UEs during initial access (for Msg4/[MsgB] HARQ feedback) [4, 8, 10, 18, 21, 22, 23, 24, 25]. Some other views expressed in the contributions: * [4]: Without enhancing the existing BWP or PUCCH solutions, PUSCH resource fragmentation due to PUCCH transmissions from RedCap UEs may result in a significant reduction in UL peak user data rate KPI. * [12]: Disabling of frequency hopping can be further investigated. * [17]: UL resource fragmentation is a pre-existing issue for Rel-15/16 non-RedCap UEs. To support features and use cases introduced in NR Rel-16/17 (e.g., 2-step RACH, power saving, RedCap UE, coverage enhancement and SDT), it is desirable for NW to adopt a scalable and forward-compatible solution based on early indication of UE types/capabilities and adaptive resource configuration for PUCCH/PUSCH. * [28]: Specification changes to avoid/minimize PUSCH fragmentation are not required. FL1 High Priority Proposal 3.1-2: It is supported that the network can enable/disable PUCCH frequency hopping for HARQ feedback for Msg4/MsgB for RedCap UEs. Company Y/N Comments Huawei, HiSilicon Partially It would be good to clearly use intra- or inter-slot PUCCH frequency hopping in proposals Xiaomi Y Qualcomm FFS ? If the RedCap UE shares the initial UL BWP with non-RedCap UE, it is not necessary to disable the PUCCH FH of RedCap UE during initial access ? Reliability of HARQ feedback to msg4/msgB should be ensured during initial access Panasonic Y We accept the FL proposal to support further flexible operation, although we think PUSCH fragmentation can be mitigated by proper scheduling also. TCL Y OPPO Y See no strong reason to disable PUCCH frequency hopping Samsung We can live with this proposal. However, we*d like to ensure there is no over optimization for this feature. Therefore, we propose: ? It is supported that the network can enable/disable PUCCH frequency hopping for HARQ feedback for Msg4/MsgB for RedCap UEs via SIB. vivo We would like to clarify that enable/disable PUCCH frequency hopping for HARQ feedback for Msg4/MsgB is applied only for the case that separate initial UL BWP for RedCap is configured. Modified as following It is supported that the network can enable/disable PUCCH frequency hopping for HARQ feedback for Msg4/MsgB for RedCap UEs in case a separate initial UL BWP is configured for RedCap UEs. Nordic N We do not see need, but can live with majority view ZTE, Sanechips Y with modification Modify it as following: When the RedCap UE is identified by msg1/[msgA], the network can enable/disable PUCCH frequency hopping for HARQ feedback for Msg4/MsgB for RedCap UEs. CMCC Y Sharp Y NEC Y Lenovo, Motorola Mobility Same with Nordic, we can live with this proposal if it is supported by majority. CATT Y It should also be discussed whether the non-hopping PUCCH of RedCap UE is allowed to be multiplexed/overlapped with the hopping PUCCH of non-RedCap UE. Intuitively, such multiplexing/overlapping will lead to problem in detection. Spreadtrum Y LG Y DOCOMO Y Nokia, NSB Y Ericsson Y The network should be given such an option so that it can minimize PUSCH resource fragmentation should it prefer to maximize the UL peak user data rate KPI. It should be noted that having this option does not mean that the network always must disable PUCCH frequency hopping. In this case, the network will have the full flexibility for enabling or disabling PUCCH frequency hopping based on the scenario. We are fine to have it configured in SIB, as suggested by Samsung. FUTUREWEI Y Intel See comments Similar view as Qualcomm: - When RedCap UE shares initial UL BWP with non-RedCap UE, it is not necessary to disable FH for PUCCH w/ HARQ-ACK in response to Msg4/MsgB. Thus, the proposal should be limited to the scenario when RedCap UE is provided with separate initial UL BWP. - With FH disabling, PUCCH reliability needs to be addressed. In the context of separate initial UL BWP, this can be naturally realized via appropriate (separate) configuration of cell-common PUCCH resources in the separate initial UL BWP that may be different (e.g., different PUCCH durations) from cell-common PUCCH resources configured for non-RedCap UEs. This is yet another reason why FH should not be simply disabled for cell-common PUCCH resources while using the same configuration as non-RedCap UEs. Thus, we suggest to limit the proposal to the case of separate initial UL BWP, and further clarify with the PUCCH resource configuration with something as below: It is supported that the network can enable/disable PUCCH frequency hopping for HARQ feedback for Msg4/MsgB for RedCap UEs when provided with separate initial UL BWP. In this case, the UE is separately provided with pucch-ConfigCommon to indicate common PUCCH resources for the separate initial UL BWP, that may include only PUCCH resources without FH. Apple We prefer the modification from vivo and Samsung. IDCC Y Agree with ViVo. China Telecom We are fine with the modification from vivo. FL2 Based on the received responses, the following updated proposal can be considered: High Priority Proposal 3.1-2a: 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 for HARQ feedback for Msg4/MsgB for RedCap UEs via SIB. vivo Y DOCOMO Y China Telecom Y CMCC 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 having the possibility of separate center frequencies for initial UL/DL BWPs in TDD [4, 6, 8, 9, 10, 25, 27, 28]. In addition, [8] states that in case of different center frequencies, center frequency retuning can be minimized by optimized gNB configuration. However, some other contributions indicate that the same center frequency should be maintain for initial UL/DL BWP [5, 17, 18, 22, 26]. However, in this case, the initial DL BWP located at the edge may not contain CORESET #0 [4, 8, 20, 24, 29]. Based on the above discussions, the following can be considered. FL1 High Priority Question 3.1-3: Regarding the initial UL/DL BWPs center frequency in TDD, should the following options be considered for down selection? If so, please indicate your preferred option. * Option 1: The center frequencies for initial UL/DL BWPs can be different, and the initial DL BWP contains the entire CORESET #0. * Option 2: The center frequencies for initial UL/DL BWPs are the same, and the initial DL BWP does not necessarily contain CORESET #0. Company Y/N Comments Huawei, HiSilicon Opt2 As previously stated, the separately configured initial DL BWP does not need to contain any CORESETs including CORESET#0 - it is only for keeping the center frequency of UL and DL at UE side, such that no real overhead increment (due to additional CORESETs) to network and no change to UE implementation. There is no urgent need to take option 1 during initial access since the Tx-Rx is naturally TDMed such that UE has sufficient time for performing RF retuning. Xiaomi N Since whether support the same center frequency between initial DL BWP and UL BWP and whether include the entire CORESET#0 are two issues, we would like to decouple the discussion of these two issues. In addition, whether include the entire CORESET#0 is already discussed in Proposal 2.2-4 So, here we suggest only focus on whether support the same center frequency for DL/UL BWPs * Option 1: The center frequencies for initial UL/DL BWPs can be different, and the initial DL BWP contains the entire CORESET #0. * Option 2: The center frequencies for initial UL/DL BWPs are the same, and the initial DL BWP does not necessarily contain CORESET #0. For these two options, we prefer option 2 Qualcomm Opt 2 with modification Option 2: The center frequencies for initial UL/DL BWPs are the same in TDD operation Panasonic N We think the two issues below are separate discussion: - Whether the center frequencies for initial UL/DL can be different - Whether the separate initial DL BWP contains the entire (MIB-configured) CORESET #0 (as discussed in the Proposal 2.2-4) We think it is up to gNB whether the separate initial DL BWP contains the entire (MIB-configured) CORESET #0, even if the center frequencies for initial UL/DL BWPs can be different TCL Y Prefer Option 2. OPPO Option 2 Frequency retuning shall be avoid for RedCap UE for power saving and low UE complexity. Samsung We propose to also add option 3: * Option 3: The center frequencies for initial UL/DL BWPs can be different, and the initial DL BWP does not necessarily contain CORESET #0. Between option 1 and option 2, we prefer option 2. vivo Option 2 Option 2 is the default assumption for TDD operation since Rel-15 thus should be supported. The question should rather be whether option 1 is well justified in additional to option 2. Different center frequency for DL/U: BWPs in TDD is not supported even for non-RedCap UEs. Supporting it would increase UE complexity, increase UE power consumption, result in long interruption time due to RF retuning and lose the channel reciprocity gain. Hence, it should not be supported for RedCap UEs. Nordic N Option 2: The center frequencies for initial UL/DL BWPs are the same. gNB can operate according CASE1 as shown in our contribution R1-2107040. For off-loading can use also the other side of the wide carrier. ZTE, Sanechips N Similar with Xiaomi and Panasonic, we agree to decouple these two issues. Additionally, PUSCH fragmentation issue also has an impact on the initial UL BWP position, which would further affect the initial DL BWP position if DL/UL BWP have the same center frequency. MediaTek Opt-2 with modification Option 2: The center frequencies for initial UL/DL BWPs are the same in TDD operation CMCC We prefer option2. With center frequency alignment, the scheduling timeline of uplink and downlink switching does not exist. Separate initial DL BWP outside initial DL BWP provides additional benefit in offloading RedCap UEs. If center frequency for initial DL and UL BWP are not aligned, frequent RF retuning between initial DL BWP and initial UL BWP during initial access is required, and this will increase the complexity for RedCap devices. With RF retuning, the scheduling timeline of uplink and downlink switching needs to be studied. If different centre frequency is configured by the network side, all RedCap UEs are mandatory to support different centre frequency in TDD system, which increases the complexity of RedCap UEs. Based on the requirement for offloading, configuring option1 or option2 by gNB is also accepted. Sharp N We have same view with Xiaomi, Panasonic and ZTE/Sanechips. NEC N We share similar view as Xiaomi, Panasonic, ZTE/Sanechips and Sharp. We prefer to decouple the two aspects. Lenovo, Motorola Mobility N We think the issue should be separately discussed for the case of during initial access and after initial access. For the case of after initial access, we are fine to have always co-centered initial DL/UL BWPs. For the case of during initial access, it should be allowed to have not aligned initial DL/UL BWPs. CATT Prefer that: The center frequencies for initial UL/DL BWP can be different during the initial access. Prefer to share the initial DL BWP with non-RedCap UEs during initial access, and the entire original CORESET#0 (derived from MIB) is contained in the shared initial DL BWP naturally. RedCap UE only needs very few retuning during the RACH transmission, and does not require precise CSI. The center frequencies for initial UL/DL BWP may remain the same after the initial access. And such initial DL BWP (only applied after initial access) does not necessarily contain original CORESET#0 (derived from MIB). Spreadtrum Option 2 LG Option 2 We prefer the center frequencies of the initial UL/DL BWPs to be the same. We are okay with the Option 2, but also fine to discuss whether the initial DL BWP shall contain the CORESET#0 separately. DOCOMO Support either option If there is strong concern to Option 1 due to RF retuning, we are OK to down-select to Option 2. We don*t see the motivation not to contain the entire CORESET#0 if the center frequencies for initial UL/DL BWPs are different Nokia, NSB For us, the two issues do not need to be considered together. This question is also related to whether the initial DL BWP is used for initial access. Our preference is to not require center frequency alignment for TDD. Ericsson Y FUTUREWEI There are two discussions (center frequencies and CORESET#0). They should be discussed separately. Intel See comments We acknowledge the feasibility of both options as well as the third proposed by Samsung (although we do not quite see the relevance). However, we also share the views from Nokia that this proposal may be better considered once it is determined if the separate initial DL BWP applies before RRC connection. Apple We do NOT see the need of coupling &central frequency* with &contain CORESET#0*. Especially, &COREST0* was being discussed in initial DL BWP section with &Proposal 2.2-4*. Option 2: The center frequencies for initial UL/DL BWPs are the same, and the initial DL BWP does not necessarily contain CORESET #0. FL2 Based on the received responses, the following proposal can be considered: High Priority Proposal 3.1-3a: The center frequencies for initial UL/DL BWPs in TDD are the same, and the initial DL BWP does not necessarily contain MIB-configured CORESET #0. Lenovo, Motorola Mobility N We don't think it is beneficial to have always co-centered initial DL/UL BWPs for RedCap UEs during initial access. It should allow an initial UL BWP for RedCap UEs to be associated with the initial DL BWP defined by MIB configured CORESET#0 (i.e., CORESET#0 shared by RedCap and non-RedCap UEs) to reduce the control overhead. Jointly consider UE complexity reduction, control overhead reduction and the flexibility of offloading, the gNB is able to configure between 1) An initial UL BWP for RedCap UEs is associated the initial DL BWP defined by MIB configured CORESET#0, in which case the initial UL/DL BWPs might not be co-centered. 2) An initial UL BWP for RedCap UEs is associated with a separate initial DL BWP for RedCap UEs, in which case the initial UL/DL BWPs are co-centered. After initial access, the initial UL/DL BWPs should be co-centered. vivo Y It might be clearer to clarify the initial UL/DL BWPs includes both the MIB-configured initial BWP and separately configured initial BWP for RedCap UEs. DOCOMO Y We can live with the proposal, but better to clarify that ※separate initial DL BWP does not necessarily contain MIB-configured CORESET #0§. CMCC Y We agree to clarify the initial UL/DL BWPs also includes separate initial BWP for RedCap UEs. Medium Priority Proposal 3.1-4: Confirm the following working assumption from RAN1#105-e: * 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. Company Y/N Comments 3.2 RACH occasions RAN1#105-e made the following working assumption related RACH occasions: Working assumption: * For enabling/supporting that the RACH occasion (RO) associated with the best SSB falls within the RedCap UE bandwidth, support separate initial UL BWP for RedCap UEs (which is not expected to exceed the maximum RedCap UE bandwidth), and this separate initial UL BWP for RedCap includes ROs for RedCap UEs. o Note: these ROs can be dedicated for RedCap UEs or shared with non-RedCap UEs. Many contributions agree to confirm the working assumption from RAN1#105-e related to RACH occasions [4, 6, 7, 13, 18, 19, 20, 26]. Contribution [4] discusses that it is desired to share RACH resources are shared between RedCap and non-RedCap UEs. However, [12] states that before any agreements, the relationship between both working assumptions regarding separate initial UL BWP for RedCap UEs and RO sharing between RedCap and non-RedCap UEs must be clarified. Regarding RO sharing, the FL*s understanding is that ROs can be fully or partially shared between RedCap and non-RedCap UEs. Companies are encouraged to provide necessary clarifications if needed. Some other views on ROs expressed in the contributions: * [6]: In case of separate initial UL BWP for RedCap UEs, a separate mapping between ROs and SSBs may be needed when the ROs are shared with non-RedCap UEs. * [10]: When the ROs are shared by RedCap UE and normal UE, and if the set of ROs still exceed the maximum RedCap UE bandwidth, o The gNB can configure more than one RedCap-dedicated initial UL BWP candidates to cover all the ROs. o A RedCap UE should apply one of the candidates as its initial UL BWP based on its selected RO. FL1 High Priority Proposal 3.2-1: Confirm the above working assumption from RAN1#105-e regarding RACH occasions. Company Y/N Comments Huawei, HiSilicon N In our understanding, only when the initial UL BWP can have multiple frequency locations, the RO issue can be resolved. We suggest not to confirm the WA and to proceed how the separate initial UL BWP include ROs spanning BW larger than the RedCap UE bandwidth such that the best SSB is supported/selective. Xiaomi Y The initial UL BWP determined for the RO in this proposal should be the same for the initial UL BWP determined for the PUCCH and/or PUSCH (for Msg3/[MsgA]) transmissions in Proposal 3.3-1 Qualcomm Y Panasonic Y TCL Y OPPO Y But for the case when the bandwidth of RO exceeds RedCap UE bandwidth, how to determine the initial UL BWP shall be further discussed. Samsung Y With the understanding that initial UL BWP is configured as R-15/16 without further optimization. vivo Y Nordic Y In our understanding all ROs of non-RedCap UEs should be within separate initial UL BWP. If not clear from WA, this should be clarified. ZTE, Sanechips Y MediaTek Y CMCC Y Sharp Y NEC Y Lenovo, Motorola Mobility Y CATT Partly Y We think that if ROs are shared between RedCap and non-RedCap UEs, they are fully shared. Partial sharing of ROs may cause: (1) If the SSB-to-RO mapping remains the same, the RedCap UE cannot select the best RO with highest SSB RSRP. (2) If different SSB-to-RO mapping is configured for RedCap UE, the gNB will have to maintain different SSB-to-RO beam correspondence for RedCap UE and non-RedCap UE in the same RO, which will increase the difficultly in gNB reception and also the gNB complexity. This seems against the original purpose of sharing RO (to reduce gNB complexity). Can be discussed together with 3.1-4. Spreadtrum Y LG Y Okay to further discuss other solutions in addition to the solution based on a separate initial UL BWP. DOCOMO Y Nokia, NSB Y Ericsson Y FUTUREWEI From the description, the RO and initial UL BWP for non-RedCap UEs can share resources. This may cause resource conflicts between UL transmissions and ROs of non-RedCap UEs, especially if the RedCap UE uses the initial UL BWP in the connected state. From the UE perspective, ROs are momentary and can be treated separately if the ROs are associated with a BWP-id different from the DL/UL initial BWP-id. Intel Y Apple Y IDCC Y China Telecom Y FL2 Based on received responses, the following updated proposal can be considered: High Priority Proposal 3.2-1a: Confirm the following modified version of the working assumption from RAN1#105-e regarding RACH occasions. * For enabling/supporting that the RACH occasion (RO) associated with the best SSB falls within the RedCap UE bandwidth, support separate initial UL BWP for RedCap UEs (which is not expected to exceed the maximum RedCap UE bandwidth), and this separate initial UL BWP for RedCap includes ROs for RedCap UEs. o Note: these ROs can be dedicated for RedCap UEs or shared with non-RedCap UEs. o How to share ROs between RedCap and non-RedCap UEs can be discussed under AI 8.6.2. Lenovo, Motorola Mobility Y vivo Y Regarding how to share the ROs between RedCap UEs and non-RedCap UEs, our understanding is that RAN2 will have a joint discussion considering all the features that requiring RACH partitioning into account, it would be better to wait until the progress in RAN2 becomes clear. But we would be fine to have some discussion in AI 8.6.2 if some RAN1 centric discussion can be identified. DOCOMO Y China Telecom We generally support FL proposal. But we see no need to add the second sub-bullet here. How to share ROs between RedCap and non-RedCap UEs can be left for RAN2 discussion. CMCC Y 3.3 PUCCH/PUSCH during initial access RAN1#105-e made the following working assumption related to PUCCH/PUSCH during initial access: Working assumption: * 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, support separate initial UL BWP for RedCap UEs (which is not expected to exceed the maximum RedCap UE bandwidth). o FFS: whether/how the specification also supports separate PUCCH/Msg3/[MsgA] PUSCH configuration/indication or a different interpretation of the same configuration/indication for RedCap (e.g., disabled frequency hopping or different frequency hopping) Regarding the working assumption from RAN1#105-e related to PUCCH/PUSCH during initial access, contributions generally agree that a separate initial UL BWP can be configured for RedCap to ensure that PUCCH/PUSCH transmissions during initial access fall within the UE bandwidth. Regarding the FFS for a separate PUCCH/Msg3/[MsgA] PUSCH configuration/indication, several contributions [3, 4, 8, 10, 18, 21, 22, 23, 25, 24] indicate that the specifications should support the possibility of disabling the PUCCH frequency hopping during the initial access for RedCap UEs. Two contributions [10, 12] propose to have an FFS for PUCCH frequency hopping. Also, two other contributions [18, 20] do not support having a separate PUCCH/Msg3/[MsgA] PUSCH configuration/indication. It should be noted that this working assumption is related to the discussions on minimizing PUSCH resource fragmentation provided in Section 3.1. There are several contributions supporting the possibility of disabling the PUCCH frequency hopping during initial access for RedCap UEs which may require a different configuration/indication/interpretation for PUCCH (for Msg4/[MsgB] HARQ feedback). Some other views expressed in the contributions: * [10]: FFS the frequency hopping of RedCap PUCCH in the initial UL BWP can be disabled. * [10]: FFS the gNB shall always ensure that the location of the RedCap PUCCH resource set is included in the RedCap-dedicated initial UL BWP. * [12]: FFS for disabling frequency hopping can be further investigated * [18]: The specification doesn*t support separate PUCCH/Msg3/[MsgA] PUSCH configuration/indication or a different interpretation of the same configuration/indication for RedCap. * [20]: Confirm the following W.A. (For enabling/supporting that PUCCH) with removing the option of disabled frequency hopping. FL1 High Priority Proposal 3.3-1: Confirm the above working assumption from RAN1#105-e regarding PUCCH/PUSCH during initial access. Company Y/N Comments Huawei, HiSilicon N Similar comment - the unresolved FFS does not make the WA workable. Suggest to further discuss how specification supports separate UL configurations/indication associated with the same initial UL BWP. Xiaomi Y the initial UL BWP determined for the PUCCH and/or PUSCH (for Msg3/[MsgA]) transmissions in this proposal should be the same for the initial UL BWP determined for the RO in Proposal 3.2-1 Qualcomm Prefer to clarify the FFS part first Panasonic Y OPPO Y Samsung General Ok. But also like to clarify the definition/configuration of BWP as commented above. vivo Y Nordic Y And no need to discuss FFS further. ZTE, Sanechips Y CMCC Y Sharp Y NEC Y Lenovo, Motorola Mobility Y CATT Y in principle Can be discussed together with 3.1-2. Spreadtrum Y LG Y We see no issue to confirm the WA. After confirming the WA, we would like to further discuss the FFS part for alternative or additional solution. DOCOMO Y Nokia, NSB Y Ericsson Y In our view, the FFS is best addressed by Proposal 3.1-2 (if agreed). FUTUREWEI The FFS needs further clarification. For example, in Msg3, frequency hopping can be disabled. Is the intent a different hopping pattern? Intel Y We agree with other comments above that this proposal is connected to Proposal 3.1-2 and our suggestion to Proposal 3.1-2 essentially aims to address this FFS point in the current working assumption directly. Apple Y IDCC Y China Telecom Y FL2 From the received responses, the main bullet in the working assumption does not seem to be controversial, but some responses prefer to address the FFS together with Proposal 3.1-2. This issue can be postponed until the issue in Proposal 3.1-2a has seen further progress. 4 Non-initial BWP 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. 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 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 [3, 4, 6]. In addition, contributions discuss several benefits and aspects related o FG 6-1a: * [3]: This feature does not have any additional requirement on UE hardware; thus, it will not increase RedCap UE cost/complexity. * [4]: Support of FG 6-1a is beneficial for minimizing PUSCH resource fragmentation, and it allows supporting all SSB/CORESET #0 configurations. * [4]: Without supporting FG 6-1a in TDD, the UE must support having different center frequencies for non-initial UL/DL BWPs. * [29]: Non-initial DL BWP for RedCap UE with FG 6-1a BWP operation without restriction may improve frequency diversity gain for RedCap UE. One contribution [21] discusses two interpretations of FG6-1a which can be considered for RedCap and suggests having an FFS: * FG 6-1aa: o BW of UE-specific RRC configured BWP may not include BW of the CORESET#0 or SSB, but the active DL BWP and both of SSB and CORESET #0 are contained within the max RedCap UE BW. o This would be equivalent to FG 6-1a of Rel-15 for non-RedCap UEs. o FFS: Mandatory or optional for RedCap UEs * FG 6-1ab: o BW of UE-specific RRC configured BWP may not include BW of the CORESET#0 or SSB, and the active DL BWP and one or both of SSB and CORESET #0 may span a BW that exceeds the max RedCap UE BW. o This implies need for RF retuning to receive SSB and/or CORESET #0 outside of active DL BWP. Further, measurement gaps may need to be defined for SSB reception and/or SI acquisition if active DL BWP does not include SSB and/or CORESET #0. o FFS: whether RedCap UEs support FG 6-1ab in FR1. Meanwhile, one contribution [19] suggests discussing whether the RedCap UE may assume the bandwidth of the CORESET#0 and SSB does not exceed the maximum RedCap UE bandwidth so that FG 6-1a will not be needed. FL1 High Priority Question 4-1: Should RedCap UEs support FG 6-1a as a mandatory feature with the following clarification? * BW of UE-specific RRC configured BWP may not include BW of the CORESET#0 or SSB. * The active DL BWP and one or both of SSB and CORESET #0 may span a BW that exceeds the max RedCap UE BW. Company Y/N Comments Huawei, HiSilicon Almost The current FG 6-1a concerns UE-specific RRC configured BWP for data reception. If we can assume that for unpaired spectrum, the initial DL BWP is only used for center frequency alignment between UL and DL then the implementation can be easier for UE 每 i.e., the BW of UE-specific RRC separately configured initial DL BWP may not include BW of the CORESET#0 or SSB. This can be a dedicated FG for RedCap UE (due to RedCap specific issue), if companies concern taking FG6-1a as mandatory. Qualcomm Support of FG 6-1a should be optional for RedCap UE in RRC connected state. The initial DL BWP of RedCap UE (MIB or SIB configured) has to include SSB and CSS for msg2/msg4/msgB/SI update. Panasonic Y OPPO The active DL BWP shall not span a BW that exceeds the max RedCap UE BW. BW of UE-specific RRC configured BWP may not include BW of the CORESET#0. But SSB shall be included for ease of UE implementation. Samsung OK to support FG6-1a as mandatory feature. For FR 2, some SSB pattern might require retuning. vivo N With the clarification of the FG6-1a is for UE-specific RRC configured BWP, we do not see the reason to make it mandatory which is different for non-RedCap UEs. The drawbacks of supporting this FG as mandatory for RedCap UEs need to be highlighted, which is increased complexity, power consumption, long interruption due to measurement gap is required even for the RedCap UE to do the serving cell RRM/RLM measurement. About the benefits for supporting this FG as mandatory like minimizing PUSCH resource fragmentation, there are solutions like put the separate initial UL BWP at the cell edge and disabling the FH for MSG4 PUCCH etc. For supporting all SSB/CORESET #0 configurations, there was one conclusion made in 104 meeting that RAN1 does not consider acquisition time improvements for FR2 RedCap UEs with SSB and CORESET#0 multiplexing patterns 2 and 3 as part of this WI. The mentioned benefits is not justified for RedCap devices. Nordic N ZTE, Sanechips We can further discuss this after we have the conclusion of following proposal: FL1 High Priority Proposal 2.2-4: A separate SIB-configured initial DL BWP for RedCap UEs does not need to contain the entire CORESET #0. If the initial DL BWP must contain the entire CORESET0, then this feature does not need to be mandatory. Otherwise, it could be mandatory. MediaTek Keep FG 6-1as an optional feature for RedCap UEs. If a separate initial DL BWP is configured for use during/after initial access then include at least CORESET#0 and CSS associated with RACH/WUS/paging. CMCC If transmission of additional SSBs in the separate initial DL BWP for RedCap can be configured by the network, FG 6-1a is a mandatory feature for RedCap. Lenovo, Motorola Mobility We are fine to have FG6-1a as a mandatory feature for RedCap CATT We agree that supporting FG 6-1a is beneficial in transmission performance. But we are open to hear more views from UE vendors. Regarding to the interpretation of FG 6-1a, we tend to FG 6-1ab in [21]. In interpretation FG6-1aa, the configurable frequency range of DL/UL BWP of RedCap UE seems to be very limited. Spreadtrum N LG Same understanding as ZTE and CMCC. We can come back to this question at a later stage. DOCOMO Y As commented in Proposal 2.2-6, we support FG6-1a as a mandatory feature for RedCap UEs and also support the modification from Huawei Nokia, NSB Y Ericsson Y In our view, the RedCap UEs should mandatorily support FG 6-1a due to the following reasons: * To align the center frequency of non-initial UL/DL BWPs in TDD, when the UL BWP is placed close to the edge of the carrier to minimize PUSCH resource fragmentation. * To be able to support all SSB/CORESET#0 multiplexing patterns. If FG 6-1a is not supported, the RedCap UEs will not be able to support the following multiplexing pattern in FR2, as their combined BW exceeds the Redcap UE BW. Table 3: Cases that exceed RedCap UE bandwidth in FR2, {SS/PBCH block, PDCCH} SCS is {240, 120} kHz, multiplexing pattern 2. Index SS/PBCH block and CORESET multiplexing pattern Number of RBs Number of Symbols Offset (RBs) 6 2 48 1 -41 if kssb=0 -42 if kssb>0 7 2 48 1 49 FUTUREWEI It seems the bullet points of proposal are providing reasons for FG 6-1a and why it should be mandatory. As mentioned, it is related to proposal 2.2-6 Intel Almost We can agree to this proposal under the assumption that UE behavior will be defined to address impact to tracking and measurements and common control reception (e.g., whether it relies or retuning or measurement gaps, etc.). Perhaps it would be good to add a bullet as below: - FFS: Details of UE behavior related to sync/tracking, measurements, and common control reception when in a DL BWP without SSB and/or CORESET #0. Given that the overall BW can span beyond max RedCap UE BW, UE assumptions and behavior related to reception of common control or T-F tracking, and measurements need to be addressed and cannot be entirely left up to the UE. In this regard, the use case of supporting all SSB/CORESET #0 configurations in FR2 should also be identified as FFS since further discussions would be required to address the above-suggested FFS bullet. Also, this could apply to separate initial DL BWP as well and thus, we should not limit just to dedicated RRC-configured DL BWPs. At least an ※FFS§ to this effect would be necessary to capture the case for separate initial DL BWP. Apple N We can support separate initial DL BWP for Redcap without covering CD-SSB. However, additional SSB needs to be transmitted within the initial DL BWP with sparse density to avoid frequent RF retuning, which causes significant power consumption and complexity if initial DL/UL is also used after initial access. FL2 FL would like to point out that FG 6-1a concerns UE-specific RRC-configured non-initial BWP, whereas Proposal 2.2-6 concerns initial BWP. Companies are requested to comment on the following updated question: High Priority Question 4-1a: Should RedCap UEs support FG 6-1a as a mandatory feature with the following clarification? * BW of UE-specific RRC configured BWP may not include BW of the CORESET#0 or SSB. * The active UE-specific RRC configured DL BWP and one or both of SSB and CORESET #0 may span a BW that exceeds the max RedCap UE BW. * FFS: Details of UE behavior related to sync/tracking, measurements, and common control reception when in a DL BWP without SSB and/or CORESET #0. vivo N From UE perspective, supporting FG 6-1a for connected mode requires additional implementation effort, increased UE complexity and power consumption. Therefore we cannot agree to mandate FG 6-1a for RedCap UEs, the same handling as for non-RedCap UEs should be adopted, i.e. FG6-1 is mandatory and FG6-1a is optional. DOCOMO Y CMCC This depends on whether the additional SSB is always transmitted in the separate initial DL BWP. If transmission of additional SSB is configurable by the network, FG 6-1a is a mandatory feature for RedCap. A few contributions indicate that if FG 6-1a is supported, additional features might need to be also supported. [11] mentions synchronization based purely on TRS and RSRP/RSRQ measurements of serving cell based on CSI-RS (FG1-5a). [17] refers to periodic TRS and dedicated RRC signaling for SI update. * [11]: A RedCap UE not having SSB in active BWP would need to support at least 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 (FG1-5a). * [17]: If RedCap UE supports FG 6-1a and operates in an active DL BWP without CORESET0 or SSB, it expects to receive: o Periodic TRS for time/frequency tracking o Dedicated RRC signaling for SI update o Dedicated BFR-CSIRS-RACH resource, if BFR-CSI-RS is configured in the active BWP FL1 High Priority Question 4-2: Is there a need to support any other features or signaling related to non-initial BWP operation beyond FG 6-1a? Company Y/N Comments Huawei, HiSilicon As previously mentioned, the first reason for RedCap UEs to support a BWP BW without containing SSB can be for center frequency alignment purpose. In that case, a new FG similar as the current FG6-1a can be defined as mandatory. For other purpose, e.g. measurements, the legacy FG6-1a can remain and a measurement gap could be also configured for SS block based RRM measurement - i.e. other related features are not necessarily coupled. But we could be open for further discussion. Samsung Suggest to further discuss this issue later after other proposals are clearer. vivo We suggest to decide mandatory of optional support for FG6-1a first as in Question 4-1. Nordic Y There needs to be multiple dedicated carriers if dedicated BWP is not overlapping with initial BWP and if dynamic BWP switching is to be supported. ZTE, Sanechips This issue could be discussed with low priority. CATT Based on the interpretation of FG 6-1ab, RF retuning + measurement gap may be sufficient. LG We can come back to this question at a later stage. Low priority in term of urgency. Nokia, NSB We can revisit this issue later. Ericsson We can come back to this question after there are good progress for Question 3.1-3 and Question 4-1. FUTUREWEI We should come back to this later during the feature discussion. Intel Agree with other comments above that it would be prudent to come back to this once the earlier design aspects are clearer. China Telecom We are open to further discussion. FL2 This question can be postponed until later. 5 RF retuning and BWP switching Topics related to switching/hopping/retuning related to BWP operation has been discussed in contributions and during recent on-line meetings. Part of this discussion primarily is related to retuning timing, treated handled in Section 5.1 below, whereas more general aspects are treated in Section 5.2. 5.1 RF switching delay In the previous meeting, RAN1#105-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 [41] and a draft LS with the following LS text was provided in [42]. This LS text is included below for the reader*s convenience, with numbered paragraphs and sub-bullets added in red to facilitate further discussion. During the email discussion in RAN1#105-e, some contributions supported sending the LS, some contributions agreed to send only the first paragraph, one contribution wanted to make distinction between FR1 and FR2, and others opposed sending any LS on this topic. Overall description 1) 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, e.g., that the UE supports two BWPs and the centre frequency changes among the two BWPs. 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. 2) Furthermore, RAN1 would like to ask RAN4 whether the switching delay for FR1 and FR2 could be reduced under the following assumptions (either as a mandatory or an optional UE capability): a) The RF switching takes place between two frequency locations with different centre frequencies. o Including cases such that the UL/DL centre 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 b) 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. c) 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. d) The RF switching may take place during initial access or after initial access. e) 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. Note: The above does not imply that there is RAN1 consensus on related RF switching techniques. Actions To RAN4: ACTION: RAN1 respectfully asks RAN4 to provide feedback on the question above on RF switching time. Several contributions continue to propose sending an LS to RAN4 for providing input related to the RF switching time, with at least some of the items above included [3, 9, 13, 21]. One contribution [17] proposes to consider reduced switching time for FR2, based on RAN4 input, but not for FR1. Other contributions suggest not to introduce reduced retuning delays for RedCap [5, 6, 8, 15, 19], some of which propose to send an LS to RAN4 seeking confirmation to reuse of existing framework and/or timing. Others continue to explicitly object to sending an LS [7]. Contribution [3] proposes to discuss, in UE feature session, whether any modified guard period time for RF retuning can also be used by non-RedCap UEs. Contribution [17] proposes that for DCI based switching, RedCap UE should support Type-2 switching delay capability as a baseline. Medium Priority Question 5.1-1: Please indicate whether an LS shall be sent to RAN4, and if so, what paragraphs (1) and (2), and sub-bullets (a) to (e) can be included in the LS. Feel free to provide modified formulations and/or added sub-bullets if they may help progress the topic. Given the difficulty in reaching a consensus in the previous meeting, companies might need to consider changing some positions, for the sake of progress. Note that sending an LS does not imply that there is RAN1 consensus on related RF switching techniques. Company Y/N Comments 5.2 Other aspects of BWP switching and retuning 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 are addressed in Section 3.1, issues related to SSB potentially not being transmitted in initial/non-initial BWP for RedCap are treated in Sections 2.2 and 4. Some aspects specifically relevant for the BWP switching and/or retuning are listed below. BWP switching during initial access As noted in Section 3.1, several contributions support having different center frequencies for initial UL/DL BWPs, whereas other contributions oppose this. For the case when different center frequencies are supported, some contributions [4, 29] argue that the UL/DL timing can be configured such that enough time can be guaranteed to accommodate the UL/DL switch, and that this may need to be guaranteed by the standard. Though this is somewhat related to the discussion on RF switching delay in Section 5.1, the two issues can be discussed separately from each other, i.e., without suggesting any reduced switching time to address this scenario. Medium Priority Question 5.2-1: If a scenario with different center frequencies for initial UL/DL BWPs is supported in TDD, can the current specification and configuration options be used to guarantee that a UE is allowed enough time to perform the switching between UL and DL BWPs for a RedCap UE? If not, what specification changes are needed? Company Y/N Comments RF switching due to receiving SSB or monitoring CORESET#0 This issue is related to the discussions in Sections 2.2 and 4 on whether a separate SIB-configured initial DL BWP contains the entire CORESET #0 and/or SSB. Different views on support for switching to receive SSB (e.g., for RRM measurements) or monitoring CORESET#0 have been proposed. Some contributions propose introducing measurement gaps [6, 17, 19, 21, 22]. Other contributions mention that sufficient time gap shall be ensured [12], relaxations on UE transmission/reception requirements in connection with CORESET#0 monitoring and measurements [4], or in general that the infrequent switches shall be studied [20]. Contribution [3] suggests that this type of retuning shall be accomplished with efficient RF retuning, related to the reduced switching times in Section 5.1. Medium Priority Question 5.2-2: In a scenario where SSB and CORESET#0 is not transmitted within the UE BW, companies are encouraged to provide their views on how to accommodate SSB reception (e.g., for RRM measurements) and CORESET#0 monitoring with respect to, e.g., timing and mechanisms for the required retuning. Company Comments Other Several contributions discuss BWP hopping/retuning/switching, but these aspects are mostly already handled in the discussion in Section 5.1 above related to the potential LS sent to RAN4, especially hopping (etc.) under conditions listed in sub-bullets (a) to (e). Other contributions argue that the current switching mechanisms are sufficient. Contribution [26] suggests optimizing BWP framework to achieve frequency diversity. Contribution [17] suggests introducing ※virtual narrow BWP hopping§ as well as 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. However, these are proposed only for FR2. 6 Other aspects 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. Annex: Companies* point of contact FL1 Question: Please consider entering contact info below for the points of contact for this email discussion. Company Point of contact Email address Xiaomi Qin Mu muqin@xiaomi.com Panasonic Shotaro Maki maki.shotaro@jp.panasonic.com OPPO Weijie Xu xuweijie@oppo.com Samsung Feifei Sun Feifei.sun@samsung.com Vivo Xueming Pan panxueming@vivo.com Sharp Hiroki Takahashi takahashi.hiroki@sharp.co.jp CATT Yongqiang FEI feiyongqiang@catt.cn LG Jay KIM Jaehyung.kim@lge.com DOCOMO Shinya Kumagai shinya.kumagai@docomo-lab.com Nokia, NSB Rapeepat Ratasuk rapeepat.ratasuk@nokia-bell-labs.com Ericsson Sandeep Narayanan Kadan Veedu sandeep.narayanan.kadan.veedu@ericsson.com Intel Debdeep Chatterjee debdeep.chatterjee@intel.com Apple Hong He hhe5@apple.com China Telecom Jing Guo guojing6@chinatelecom.cn Lenovo, Motorola Mobility Yuantao Zhang zhangyt18@lenovo.com References [1] RP-211574 Revised WID on support of reduced capability NR devices Ericsson [2] R1-2106213 RAN1 agreements for Rel-17 NR RedCap Rapporteur (Ericsson) [3] R1-2106459 Reduced maximum UE bandwidth Huawei, HiSilicon [4] R1-2106563 Reduced maximum UE bandwidth for RedCap Ericsson [5] R1-2106601 Discussion on reduced maximum UE bandwidth vivo, Guangdong Genius [6] R1-2106648 UE Complexity Reduction aspects related to reduced maximum UE bandwidth Nokia, Nokia Shanghai Bell [7] R1-2106705 Discussion on aspects related to reduced maximum UE bandwidth Spreadtrum Communications [8] R1-2106841 Bandwidth reduction for reduced capability NR devices ZTE, Sanechips [9] R1-2106894 UE complexity reduction Samsung [10] R1-2106977 Discussion on reduced maximum UE bandwidth CATT [11] R1-2107040 On aspects related to reduced maximum UE BW Nordic Semiconductor ASA [12] R1-2107089 Discussion on Bandwidth Reduction for RedCap UEs FUTUREWEI [13] R1-2107128 Discussion on reduced maximum UE bandwidth for RedCap China Telecom [14] R1-2107197 Discussion on reduced maximum UE bandwidth TCL Communication Ltd. [15] R1-2107249 Discussion on reduced UE bandwidth OPPO [16] R1-2107300 Discussion on aspects related to reduced maximum UE bandwidth NEC [17] R1-2107351 BW Reduction for RedCap UE Qualcomm Incorporated [18] R1-2107408 Discussion on reduced maximum UE bandwidth CMCC [19] R1-2107448 Aspects related to the reduced maximum UE bandwidth of RedCap LG Electronics [20] R1-2107496 On reduced maximum bandwidth for RedCap UEs MediaTek Inc. [21] R1-2107596 On reduced BW support for RedCap Intel Corporation [22] R1-2107745 Reduced maximum UE bandwidth for Redcap Apple [23] R1-2107794 Discussion on reduced maximum UE bandwidth Sharp [24] R1-2107809 Reduced maximum bandwidth for RedCap UEs InterDigital, Inc. [25] R1-2107864 Discussion on reduced maximum UE bandwidth for RedCap NTT DOCOMO, INC. [26] R1-2107926 Discussion on the remaining issues of reduced maximum UE bandwidth for RedCap Xiaomi [27] R1-2107947 Reduced maximum UE bandwidth for RedCap Lenovo, Motorola Mobility [28] R1-2108041 Aspects related to reduced maximum UE bandwidth Panasonic Corporation [29] R1-2108060 Discussion on aspects related to reduced maximum UE bandwidth ASUSTeK [30] R1-2106568 Potential RedCap solutions for avoiding or minimizing PUSCH resource fragmentation Ericsson [31] R1-2106605 Discussion on L1 reduced capability signaling vivo, Guangdong Genius [32] R1-2106653 Discussion on RedCap UE capabilities Nokia, Nokia Shanghai Bell [33] R1-2106846 NR UE features for RedCap ZTE, Sanechips [34] R1-2106982 Views on remaining issues of RedCap CATT [35] R1-2107385 Discussion on scaling factor for RedCap Spreadtrum Communications, Apple, CEPRI [36] R1-2107413 Discussion other aspects of RedCap UE CMCC [37] R1-2107452 Discussion on other aspects of RedCap LG Electronics [38] R1-2107669 On RedCap UL transmission Huawei, HiSilicon [39] R1-2107931 Discussion on the transmission of system information for RedCap Xiaomi [40] R1-2108050 Considerations on 2-step RACH for RedCap Lenovo, Motorola Mobility [41] R1-2106002 FL summary #4 on reduced maximum UE bandwidth for RedCap Moderator (Ericsson) [42] R1-2106187 [Draft] LS on RF switching time for RedCap UE Ericsson [43] R1-2108267 FL summary #1 on reduced maximum UE bandwidth for RedCap Moderator (Ericsson)