3GPP TSG-RAN WG1 Meeting #106-e R1-21xxxxx e-Meeting, 16th 每 27th August 2021 Agenda Item: 8.6.1.1 Title: FL summary #3 on reduced maximum UE bandwidth for RedCap Source: Moderator (Ericsson) Document for: Discussion, Decision 1 Introduction This feature lead (FL) summary (FLS) concerns the Rel-17 work item (WI) for support of reduced capability (RedCap) NR devices [1]. Earlier RAN1 agreements for this WI are summarized in [2]. This document summarizes contributions [3] 每 [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 discussion, please comment on the issues tagged ＆FL3＊ before Thursday 19th August 04:00 UTC. Follow the naming convention in this example: * RedCapBwFLS3-v000.docx * RedCapBwFLS3-v001-CompanyA.docx * RedCapBwFLS3-v002-CompanyA-CompanyB.docx * RedCapBwFLS3-v003-CompanyB-CompanyC.docx If needed, you may ※lock§ the discussion document for 30 minutes by creating a checkout file, as in this example: * Assume CompanyC wants to update RedCapBwFLS3-v002-CompanyA-CompanyB.docx. * CompanyC uploads an empty file named RedCapBwFLS3-v003-CompanyB-CompanyC.checkout * CompanyC checks that no one else has created a checkout file simultaneously, and if there is a collision, CompanyC tries to coordinate with the company who made the other checkout (see, e.g., contact list in Annex). * CompanyC then has 30 minutes to upload RedCapBwFLS3-v003-CompanyB-CompanyC.docx * If no update is uploaded in 30 minutes, other companies can ignore the checkout file. * Note that the file timestamps on the server are in UTC time. In file names, please use the hyphen character (not the underline character) and include ＆v＊ in front of the version number, as in the examples above and in line with the general recommendation (see slide 10 in R1-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 Xiaomi Y Qualcomm Y Nordic Y LG Y NEC Y Panasonic Y Samsung Thanks for the modification. We can live with this for the sake of progress. But I＊d like to clarify our concern. There were some proposals to allow BWP hopping based on pre-defined rule or configuration, i.e. to increase decoding performance. For example, PDSCH floats to different frequency location outside than its RF BW, and assuming BWP hopping with it. We think comparing with wider BWP operation, i.e., UE retuning in a wider BWP, it is more complicated. On the other hands, we are open to discuss UE retuning to receive SSB and some other DL channels that not transmit on separate DL BWP. In this case, the frequency location of separate iDL BWP is not change time to time, but UE can retune to other frequency location to receive some DL channels. CATT Y Huawei, HiSilicon Y Spreadtrum Y ZTE, Sanechips Y Nokia, NSB Y Apple Y FFS in 3rd sub-bullet can be removed as it is purely a clarification for the main bullet. Intel Y Ericsson Y FUTUREWEI2 Y IDCC Y FL3 Based on the received comments, the same proposal (with no other changes than the removed change tracking) can be considered for endorsement. 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 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). CMCC Y CATT Y Nordic Y DOCOMO Y LG Y Nokia, NSB Y Ericsson Y FUTUREWEI3 Y TCL Y Intel Y China Telecom Y Qualcomm Y Lenovo, Motorola Mobility Y Sharp 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. Xiaomi Generally, we are OK with the principle. But we suggest the following update for the second sublet. The separate initial DL BWP for RedCap UEs includes configuration of CORESET and CSS at least for RACH. Qualcomm Suggested changes for FL2 proposal 2.2-3a : A separate initial DL BWP for RedCap UEs (if configured) can be used during the initial access. * For TDD operation, the center frequency for this separate initial DL BWP should be aligned with the center frequency of the initial UL BWP for RedCap UEs. * The separate initial DL BWP for RedCap UEs includes configuration of CORESET and CSS at least for RACH and paging. * FFS SSB transmission in this separate initial DL BWP. Nordic Y with condition 1) We agree with Vivo that first sub-bullet. Second sub-bullet is OK. 2) Next question is, can UE camp on such separate initial DL BWP? We prefer UE camping on CORESET#0 by MIB, UE retunes to separate Initial DL BWP to perform RACH and may stay there after MSG4 3) We can support this proposal only if UE can be guaranteed that it does not have to change size of DCI format 1_0 and 0_0. LG We prefer the proposal without the first bullet which is on the TDD. If the separate initial DL BWP is supported, then the usage should be up to the network unless there is a serious concern. NEC We can accept majority＊s view. The first sub-bullet seems unnecessary. We are not sure when MIB-configured initial DL BWP is reconfigured to a separate initial DL BWP. Panasonic Y Samsung Y We also agree with Vivo＊s comment. The first bullet can be considered as conclusion. We support to add paging for second bullet. CATT Need FFS We should not rush to an agreement without a clear picture of the separate initial DL BWP, especially in the situation that the motivation is not strong. According to R1-1813988, center frequency alignment is not a critical issue during the initial access, and the majority thinks RF retuning is enough to tackle the issue when the center frequency of CORESET#0 and initial UL BWP is not aligned. If we have to continue the discussion, we hope to reach some consensus on the following questions first (some of them are discussed in other proposals), and make every one understand the cost and risk, assuming the separate initial DL BWP can be used during the initial access: (1) Does the separate initial DL BWP must contain additional SSB, in addition to CORESET and CSS (for RACH)? If yes, what＊s the relationship between the additional SSB and the original SSB? If no, does it mean the RedCap UE should mandatory support FG 6-1a? Can we live with the answer ＆no＊? (2) Should the gNB transmit SIBx (other than SIB1) in the separate initial DL BWP? If yes, does it mean the gNB may be required to double the SIBx transmission (x>1)? (3) Should we restrict the bandwidth of the separate initial DL BWP? If no, does it mean the UE may decode different sizes of DCI format 1_0 before initial access (for reception of SIB1 in legacy initial DL BWP and Msg2/4 in separate initial DL BWP)? Huawei, HiSilicon N A separate initial DL BWP for offloading purpose can be optimization. The baseline is for TDD center frequency issue. To be specific, - Some/many companies consider the center frequency for UL and DL should be aligned 每 for this purpose, no need to configure CORESET and CSS, even no need for the BWP to containing SSB. - Some companies consider there is offloading benefit- if the separately configured BWP containing SSB, how much it could benefit from offloading since the available resource is still limited while the overall system overhead is actually increased. - If there is really offloading necessity, what＊s the issue with UE perform RF retuning to another BWP after reception of the legacy used SSB. The current proposal doesn＊t speak anything about SSB thus we don＊t understand, without UE RF retuning, how the UE can jump to another BWP after, assuming legacy SSB is read, for CORESET monitoring for example. If the assumption for the other side is the gNB has to send additional SSB - this won＊t be the possible way forward. Given this, we propose the following: During the initial access, * A separate initial DL BWP for RedCap UEs without BW containing SSB can be used/configured/defined o The center frequency for the initial DL BWP is the same as that for the initial UL BWP, for unpaired spectrum Spreadtrum Y Our 3 priorities are listed as follows: 1st priority: FG 6-1a is optional capability for RedCap UE: the separate initial DL BWP for RedCap UE contains SSB and CSS. The separate initial DL BWP and the separate initial UL BWP have the same center frequency. 2nd priority: FG 6-1a is optional capability for RedCap UE: RedCap UEs and non-RedCap UEs share the legacy initial DL BWP (the same frequency location as CORESET#0). The legacy initial DL BWP and the separate initial UL BWP can have different center frequencies. Compared to the mandatory capability of FG 6-1a, it may be more acceptable for UE implementation, since to support FG 6-1a RedCap UE should autonomously retune it RF timely (maybe once per paging cycle) when camping in the initial DL BWP. If the network vendor is unwilling to support the additional SSB in a carrier, we can compromise to this alternative. 3rd priority: FG 6-1a is mandatory capability for RedCap UE: the separate initial DL BWP for RedCap UE contains CSS. The separate initial DL BWP and the separate initial UL BWP have the same center frequency. ZTE, Sanechips Y The separate initial DL BWP also can include configuration of CORESET and CSS for paging. Nokia, NSB We prefer to use legacy procedure during initial access. We think RF retuning is fine during initial access and there is no need to align the DL and UL center frequency. Also considering that the initial DL BWP may need to contain SSB, CORESET, CSS, SIBs if we are to use it for initial access, we don＊t think this is good design. Apple As commented in 1st round, we support main bullet assuming if some CSS can be configured in the separate initial DL BWP, they can be leveraged for offloading purpose. It should be noted that ＆offloading＊ is not related to ＆overhead＊. As usual, offloading scheme is aiming to reduce PDCCH blocking rate by providing additional CORESET/BWP such that UEs are NOT limited within the MIB-configured CORESET#0 BW. We also have recommendation, similar as CATT, regarding the order to proceed the discussions. In our view, there are certain correlations among the open issues, and it may be reasonable starting from the most basic one and then down the road to others. Hence, the following was suggested to discuss in order. * For TDD, whether central frequency of the initial DL BWP and initial UL BWP should be always aligned? * What is the channel/signal(s) that should be included in the separate initial DL BWP if it does not include CD-SSB and/or CORESET#0? e.g., SSB, other CORESETs for CSS, etc. Focusing on proposal below, our views is: * 1st sub-bullet is not needed as commented by vivo. Typically, agreement focus on something that has specification impacts. Motivation/use case should not be in the agreement. * The sub-bullets start to discuss what signal/channels can be included in initial DL BWP. We think it is important to also add SSB herein to avoid misinterpretation that SSB is not included. Hence, we added 3rd sub-bullet (same as Proposal 2.2-6a below). o If FL still think decoupling these two proposals is better, we would like to first discuss and conclude proposal 2.2-6a. 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. * The separate initial DL BWP for RedCap UEs includes SSB transmission (Proposal 2.2-6a) o FFS: Suitable SSB periodicity considering impacts in terms of signaling overhead and performance Intel We are still not fully convinced on mandating center frequency alignment between DL and UL BWPs in Idle/Inactive modes and agree with vivo and others that the first sub-bullet is not necessary for agreement. @Huawei-HiSi: To the comment that CORESET/ SS set need not be configured in the separate initial DL BWP if configured for DL-UL center frequency alignment, we are wondering on what would be the expected UE behavior in the separate initial DL BWP if one is configured to align center frequency with initial UL BWP if the separate initial DL BWP does not have a CORESET/SS set configuration for PDCCH reception, etc.? Where does the UE receive in the DL in such a case after/before UL transmissions? Ericsson Y We are also OK without the first sub-bullet. FUTUREWEI2 The top level is fine. Similar comments as others about the first bullet. Need further discussion for the second bullet. IDCC Y FL3 Based on the received responses, the following updated proposal can be considered: High Priority Proposal 2.2-3b: 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 (FFS: and paging). CMCC Y CATT FFS We do not want to repeat our technical concerns in the previous round discussion, which do not get convincing reply so far. It is hard for us to accept this proposal. Why do we rush to such agreement? As a compromise, we suggest the following changing, to study the conditions first. High Priority Proposal 2.2-3b: Further study the conditions if Aa separate initial DL BWP for RedCap UEs (if configured) can be used during the initial access. * The separate initial DL BWP for RedCap UEs includes CORESET and CSS at least for RACH (FFS: and paging). o FFS if the separate initial DL BWP does not have to contain the entire CORESET#0 in this case * FFS the separate initial DL BWP must include SSB o If additional SSB is included, FFS the relationship with the cell-defined SSB * FFS whether SIBs can be transmit in the separate initial DL BWP. * FFS whether the bandwidth can be configured other than {24, 48, 96} PRBs, and FFS the relationship with the bandwidth of the MIB-derived CORESET#0. * FFS whether the center frequencies of the separated initial DL BWP and the separated initial UL BWP must be aligned. At least from our view, the above issue must be tackled first, to potentially enable initial access in a separate initial DL BWP. If we get clear answers, and the consensus are reached, we are fine to further conclude that the separate initial DL BWP can be used during the initial access. Nordic Y, with condition Our understanding is that current baseline is the following gNB may always place CORESET#0 to the edge of carrier in TDD and operate RedCap UE initial access there. If we do not agree on anything else then initial access for RedCap UEs is operated like above in R17. For more gNB flexibility on placement of CORESET#0 we are OK to agree on FL proposal 1) given that additional SSB is provided if separate initial DL BWP does not contain cell defining SSB 2) given that DCI format size of 1_0 and 0_0 in separate initial DL BWP is determined by CORESET#0 configured by MIB Finally, we agree that FFS points listed by CATT should be clarified DOCOMO Y LG Y Nokia, NSB Similar view as CATT that more discussion / clarification is needed. From Proposal 2.2-4b, we support the case that the initial DL BWP does not contain the entire CORESET#0. It also may not contain the SSB. It is better that we have some discussion on these points before we decide so we have clear understanding of how initial access will be done. Ericsson Y The FFSs mentioned in CATT＊s response are addressed in the subsequent sections. Depending on the scenario, the initial DL BWP s can be shared between RedCap and non-RedCap. Yet, the possibility of configuring a sperate initial DL BWP allows UL/DL TDD center frequency alignment when sharing initial DL BWPs between RedCap and non-RedCap is not feasible. Otherwise, the RedCap may need to support different center frequencies for initial DL/UL BWPs in TDD. This is also tightly related to Question 3.1-3. FUTUREWEI3 Some of the FFS points listed by CATT should be further examined TCL Y Intel It is true that most of the discussion points in CATT＊s updated proposal are aspects discussed in sequent sections. To make progress, perhaps we could condition the proposal on if separate initial DL BWP for RedCap UEs for use during initial access is agreed. Thus, something like could be considered: If use of a A separate initial DL BWP for RedCap UEs (if when configured) can be used during the initial access is supported, * The separate initial DL BWP for RedCap UEs includes configuration of CORESET and CSS at least for RACH (FFS: and paging). Also, @Nordic, we are not sure if it is possible to place the CORESET #0 anywhere in the BW (of 60 MHz in your example) if the initial DL BWP (for non-RedCap UEs) is intended to span the entire 60 MHz. If a larger initial DL BWP is configured in the SIB1 (for non-RedCap UEs), the center frequency for CORESET #0, the initial DL BWP by SIB1, and UL BWP #0 by SIB1 should be aligned. This seems to be violated in your example? China Telecom We support the main bullet in FL proposal. However, we think it would be better after the related FFSs are further clarified. Qualcomm N Our concerns/comments in the last round discussion were not addressed. Therefore, we cannot agree with this proposal as it is. Moreover, when the separately configured initial DL BWP (without SSB or CORESET0) is used by RedCap UE after initial access, it implies the mandatory support for FG 6-1a. FG 6-1a should be kept as an optional feature for RedCap UE. We are open to discuss the FFS items suggested by CATT, especially the transmission of a non-CD SSB in the separate initial DL BWP. Lenovo, Motorola Mobility Y Samsung Y Traffic offloading, and try to minimize the RF retuning (might not be avoid, CATT＊s comments on FR 2 SSB pattern 2/3) for TDD between UL and DL could be two motivations. If UL/DL center frequency alignment is not important, why we agreed on type 1 HD-FDD only? For TDD, if center frequency is not the same, it is leading to Type 2 HD-FDD UEs, which require RF retuning between UL and DL. To some companies comment, we think whether separate iDL BWP contains SSB can be discussed separated. Sharp Y 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 Xiaomi N * To us, the SIB-configured initial DL BWP is not clear enough. In our mind, at least the following two cases require separate initial DL BWP - Case 1: A separate initial DL BWP is configured at least for the purpose of center frequency alignment in TDD system. In this case, the separate initial DL BWP is used during initial access - Case 2: RedCap and Non-RedCap share the MIB-configured initial DL BWP during initial access, while SIB re-configure an initial DL BWP wider than RedCap＊s maximum UE bandwidth. In this case, a separate initial DL BWP is needed for RedCap. This is mainly used after initial access * For case 1 above, we think the separate initial DL BWP may not include the SSB and MIB-configured CORESET#0. Because the UL initial BWP may be configured at the edge of one CC. But for case 2, we think the entire MIB-configured CORESET#0 should be included * Furthermore, if we understanding correctly, there is no agreement saying that the initial DL BWP is configured by SIB and related issue is also discussed Proposal 2.2-2 Based on the consideration above, the would like to update the proposal as follows A separate SIB-configured initial DL BWP used during initial access for RedCap UEs does not need to contain the entire MIB-configured CORESET #0. Qualcomm Suggested changes for FL2 proposal: A separate SIB-configured initial DL BWP for RedCap UEs does not need to contain the entire MIB-configured CORESET #0, if CORESET and CSS for paging is configured for this initial DL BWP. Nordic Y LG Y If there is a concern on the ※SIB-configured§ part of the proposal, then removing the SIB-configured as suggested by Xiaomi is also acceptable to us. NEC Y We are OK with the proposal as it seems RAN1＊s common understanding that a separate initial UL BWP does not need to contain entire MIB-configured initial DL BWP. Panasonic Y Samsung Y CATT Y Though we are generally fine with this proposal, we think 2.2-3 should be prioritized (or jointly discussed together). Huawei, HiSilicon Almost Or A separate SIB-configured separate initial DL BWP for RedCap UEs does not need to may or may not contain the entire MIB-configured CORESET #0. Spreadtrum Y ZTE Y Nokia, NSB Y Apple N As commented in the 1st round, we want to have a full picture regarding the associated UE behavior for SIB reception for this configuration. * Alt.1: A Redcap UE is required to perform RF retuning for Type0/0A CSS monitoring * Alt.2: A Redcap UE does NOT monitor Type0/0A CSS if they are not configured in the separate initial DL BWP. (Rel-15/16 behavior) Intel Y To Apple＊s question on UE behavior, both Alt. 1 and Alt. 2 are feasible options, and Alt. 2 should be the ※baseline§ option, available since Rel-15. Ericsson Y We are also OK with Huawei＊s proposed modification. CORESET and CSS configurations can be discussed in Proposal 2.2-3a. FUTUREWEI2 Y IDCC Y FL3 Based on the received feedback, the following updated proposal can be considered: High Priority Proposal 2.2-4b: A separate SIB-configured separate initial DL BWP for RedCap UEs does not need to may or may not contain the entire MIB-configured CORESET #0. CMCC Y CATT Though we think it may be OK, we prefer to jointly consider this issue in revised 2.2-3b Nordic N We think that comment from Apple/Xiaomi should be addressed. Our assumption was also that UE is not allowed to camp on separate initial DL BWP that does not containing the entire MIB-configured CORESET. This should be captured in the proposal. DOCOMO Y LG Y Nokia, NSB Y Ericsson Y In this case, the location of the SIB-configured initial DL BWP is not constrained with the frequency location of CORESET #0 and, hence, there is flexibility in placing the initial DL BWP. For example, 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. Moreover, when the initial DL BWP does not contain the entire CORESET #0, it has more frequency resources that can be used for offloading purposes. Thus, this case can also be beneficial from offloading perspective. However, since the UE needs to rely on CORESET #0 at least for acquiring SIB1, it may need to switch to CORESET #0 when the initial DL BWP does not contain the entire CORESET #0. Note that after decoding MIB, the UE has the required information (e.g., CORESET #0 configuration) for acquiring SIB1. Therefore, SIB1 must be scheduled using CORESET #0 as it is not possible to configure a separate CORESET for SIB1 in the MIB which only has only 1 spare bit left. SIB1 also provides information about availability and scheduling (e.g., periodicity, SI-window size) of other SIBs (SIBx with x>1, e.g., SIB2, SIB3, etc.) which may or may not be scheduled using CORESET #0. Hence, if the SIB-configured initial DL BWP does not contain the entire CORESET #0, a RedCap UE may need to periodically switch to CORESET #0 for SIB1 (and potentially other SIBs) updates. We note that the UE may not be expected to monitor CORESET #0 for SIB updates frequently, and thus the potential RF retuning attempts are not expected to be frequent. FUTUREWEI3 Y TCL Y Intel Y China Telecom Y Qualcomm There is ambiguity in this proposal regarding the necessity of ※separate§ configuration. Therefore, we prefer to revise it as: High Priority Proposal 2.2-4b: If a separate initial DL BWP for RedCap UEs is configured in SIB, the BWP may or may not contain the entire MIB-configured CORESET #0, wherein the MIB, SIB and CORESET0 are shared between RedCap and non-RedCap UEs. Lenovo, Motorola Mobility Y Samsung Y To resolve apple＊s concern, we are open to add FFS: whether Type 0/0A CSS is support in the SIB-configured separate initial DL BWP. But we prefer to discuss SS on separate iDL BWP together with RAR and paging. Sharp 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. Xiaomi Y Qualcomm Y Nordic Y Could be clarified that the SSB is non-cell-defining LG Y NEC Y Panasonic Y We actually prefer Proposal 2.2-6 (before update) because of the high flexibility of SSB configuration. But we can accept the updated proposal as it may be useful to relieve the requirement of mandatory support of FG6-1a for a RedCap UE. Samsung N We don＊t see big issue to support FG 6-1a. As we commented before, for some SSB patterns for FR2, RedCap UE has to retune to monitor CORESET #0 after receiving SSB. We suggest to go back to original proposal. CATT As mentioned before, 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. We can jointly consider this question in 2.2-3. Huawei, HiSilicon N What＊s problem for UE perform RF retuning in e.g. slot level to the legacy SSB 每 this is the baseline. What＊s exactly the UE complexity? Are some companies assume there would be a RedCap UE always camp on a single location in a network? This is not a problem for eMBB UE since it has 100Mhz BW thus can always cover the carrier BW 每 but not for RedCap UE. Spreadtrum Y Our 3 priorities are listed as follows: 1st priority: FG 6-1a is optional capability for RedCap UE: the separate initial DL BWP for RedCap UE contains SSB and CSS. The separate initial DL BWP and the separate initial UL BWP have the same center frequency. It may means that the network should transmit SSB in the separate initial DL BWP. 2nd priority: FG 6-1a is optional capability for RedCap UE: RedCap UEs and non-RedCap UEs share the legacy initial DL BWP (the same frequency location as CORESET#0). The legacy initial DL BWP and the separate initial UL BWP can have different center frequencies. 3rd priority: FG 6-1a is mandatory capability for RedCap UE: the separate initial DL BWP for RedCap UE contains CSS. The separate initial DL BWP and the separate initial UL BWP have the same center frequency. ZTE, Sanechips N It is not supported to configure the additional SSB, which would bring the useless resource occupation in separate DL BWP, since the RedCap can retune to the legacy SSB if necessary. Nokia, NSB N We prefer that the gNB has the option to not configure SSB in the initial DL BWP. Apple Y We would like to prioritize discussion on this proposal over some earlier proposals as commented before. Regarding the complexity, of course it is increased due to the larger number of retuning operations for T/F tracking, RRM measurement etc., which involves both RF and baseband steps. On ＆RF retuning＊, we believe it is a real problem. That＊s at least one of reasons that motivated us to support a separate DL/UL BWP that does not exceed the Redcap max BW. Otherwise, we can always share the BWP of non-Redcap UE and force Redcap UEs to do RF retuning. We should avoid unnecessary RF retuning as much as possible to minimize the power consumption, which is critical for wearable devices. Intel Agree with Nordic that this should be clarified that this additional SSB would be a non-CD-SSB, and this aspect needs to be considered as part of the design of the next steps. Ericsson N We do not want to mandate gNB to always transmit additional SSB in the separate initial DL BWP. The UE can also rely on SSBs transmitted in the legacy BWP, or it can rely on other RSs (if present). The need for mandating additional SSB in the separate initial DL BWP is not clear to us. FUTUREWEI2 Unclear about the consistency of this proposal and proposal 2.2-4a. IDCC Y FL3 Based on the received responses, the following updated proposal can be considered. High Priority Proposal 2.2-6b: * For the case when a separate initial DL BWP for RedCap is configured, down select between the following options: o Option 1: SSB is always transmitted in the separate initial DL BWP. * FFS: suitable SSB periodicity considering impacts in terms of signaling overhead and performance o Option 2: SSB is not always transmitted in the separate initial DL BWP. * FFS: whether other RS is always transmitted in the separate initial DL BWP or whether the UE may need to rely on RF retuning to monitor SSB outside the separate initial DL BWP CMCC Regarding the overhead of transmitting SSB, we prefer option2. CATT Generally Y Though we think this proposal is generally fine, we prefer to jointly consider this issue in revised 2.2-3b Nordic N Option 1 is current situation; Option 2 can be FFS DOCOMO Y LG Y Option 1 is preferred. Nokia, NSB Y Our preference is option 2. Ericsson Y Our preference is Option 2. Regarding the FFS under Option 2, one possibility could be to consider CSI-RS/TRS transmissions (if SSB not present) in the separate initial DL BWP when the UE is in RRC_CONNECTED. Whereas, when the UE is in RRC_IDLE, the UE may need to rely on RF retuning to monitor SSB outside the separate initial DL BWP. In our view, RAN1 should send an LS to RAN4 requesting feedback on Option 1 and Option 2. FUTUREWEI Generally ok with the proposal TCL Y Prefer option 2 Intel N Depending on whether this initial DL BWP is also for use during idle/inactive modes or only for connected mode, the decision can be different, and thus, we may not be down-selecting from between these two options. Let＊s consider connected mode first. If it is agreed that RedCap UE always expects SSB in a UE-specifically configured DL BWP, then Opt 1 would be a rather reasonable choice to not define a second UE behavior only for separate initial DL BWP in connected mode. Now, if it is also agreed that separate initial DL BWP can be used in idle/inactive modes, then for such case, we don＊t see that SSB needs to be transmitted (even for UEs not capable of FG 6-1a) in the separate initial DL BWP for use when in idle/inactive mode 每 we can rely on RF retuning without impact to active DL BWP operations. Therefore, we need to clarify/separate the cases for use in connected vs. idle/inactive modes (if supported). Alternatively, for this proposal, it should be limited to only connected mode. China Telecom Y We are fine with FL proposal. We prefer Option 2 with taking overhead and performance into consideration. Qualcomm Y support option 1 only Lenovo, Motorola Mobility Y Samsung For option 2, we don＊t think FFS is needed. Current spec supports no SSB in a BWP. No need to open the discussion. We are fine if the FFS on option 2 is deleted, or change to ※FFS: whether the necessary spec change is needed and the details § Sharp Y 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 Xiaomi Y Qualcomm Y Nordic Y We prefer to clarify separate initial DL BWP before confirming WA on dedicated BWP LG Y NEC Y Panasonic Y Samsung For the sake of progress, we can live with this. Again, we assume BWP itself cannot float, but UE might be able to retune to other frequency range, for reading, e.g., SSB. CATT Y Huawei, HiSilicon Y ZTE, Sanechips Y Nokia, NSB Y Apple Y Intel Y Ericsson Y FUTUREWEI2 Y IDCC Y FL3 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. CMCC Y CATT Y Nordic Y DOCOMO Y LG Y Nokia, NSB Y Ericsson Y FUTUREWEI3 Y TCL Y Intel Y China Telecom Y Qualcomm Y Lenovo, Motorola Mobility Y Sharp 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 Xiaomi Y Qualcomm We can agree with this proposal if the last FFS bullet is removed: * FFS whether or not to additionally support the case when the centre frequency is different; if so, how to minimize centre frequency retuning Nordic Y Agree with QC LG Agree with QC NEC Agree with QC Panasonic Y Samsung For the sake of progress, we can live with this. Again, we assume BWP itself cannot float, but UE might be able to retune to other frequency range, for receiving, e.g., SSB. CATT Y Huawei, HiSilicon Y Spreadtrum Y ZTE, Sanechips Y Nokia, NSB Y We would like to keep the FFS to consider different center frequency Apple Agree with QC Intel Y To QC and others suggesting removal of the last sub-bullet, in our understanding, deleting the sub-bullet means that separate initial UL BWP can be configured only if the center frequency of the separate initial UL BWP is aligned with that of the initial DL BWP (that, by default, is the one defined by CORESET #0). It does not automatically imply configuration of a separate initial DL BWP to ensure center frequency alignment. Ericsson Y FUTUREWEI2 The first FFS is addressed with proposal 3.1-2a. There is no need to include here. IDCC Y FL3 Based on received responses, the same proposal can be considered again. Note that the FFSs are addressed by Proposal 3.1-2a and Proposal 3.1-3a. 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 CMCC Y CATT Y Nordic Y DOCOMO Y LG Y Nokia, NSB Y Ericsson Y FUTUREWEI3 Y For the sake of progress TCL Y Intel Y China Telecom Y Qualcomm Our concerns/comments regarding the center frequency alignment of UL/DL BWPs in TDD operation were not addressed. Some additional comments on ※PUSCH resource fragmentation§: * Compared to PUSCH peak data rate enhancements, coverage enhancements for PUSCH/PUCCH are bigger concerns of 3GPP community up to NR R17. * For coverage limited UE, it will not be allocated with a wide BW when DFT-s-OFDM waveform is configured for PUSCH. Therefore, it is difficult to understand the concerns for ※PUSCH resource fragmentation§ when DFT-s-OFDM waveform is used. * HARQ feedback to msg4/msgB is dynamic transmission scheduled by NW. NW is able to avoid the collision (if any) between dynamic PUCCH and PUSCH, as in NR R15 and R16. * For non-RedCap UEs with UL peak data rate KPI (if any), NW/scheduler can consider at least the following solutions other than ※contiguous FDRA for a single UE§: o higher MCS o more spatial layers o CA o rate matching or puncturing Lenovo, Motorola Mobility Y Sharp 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 Xiaomi Y Qualcomm We are ok to support this proposal, if the following sub-bullet is added: 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. * In TDD operation, this separate initial UL BWP is aligned with the initial DL BWP of RedCap UE at the center frequency. Nordic Y, perhaps would be good to add FFS on which intra-slot hop is disabled. LG We prefer modification from vivo in the 1st round or remove the ※via SIB§ from the FL2 proposal. We are supportive of the turning off the frequency hopping, but we are not convinced at the moment if it has to be always signaled via SIB, or doesn＊t even need to be signaled in some cases, e.g., if it is a separate initial UL BWP for RedCap UEs. NEC Y Panasonic Y Samsung Y CATT Y in principle Can we add an FFS on the frequency position of PUCCH in this case? If the position of non-hopping PUCCH resource set is always at the edge of the separate initial UL BWP, it seems either (1) the edge of separate initial UL BWP can never reach the same edge of the original initial UL BWP; or (2) it may happen that non-hopping PUCCH of RedCap UE overlap with hopped PUCCH of non-RedCap UE. Huawei, HiSilicon Almost In case a separate initial UL BWP is configured for RedCap UEs, it is supported that the network can enable/disable intra-slot PUCCH frequency hopping within the separate initial UL BWP for HARQ feedback for Msg4/MsgB for RedCap UEs via SIB. Spreadtrum Y ZTE, Sanechips Y Nokia, NSB Y We are fine with the FL proposal. We do not support Qualcomm＊s suggestion to add the sub-bullet on center frequency alignment. Apple We prefer QUALCOMM＊s revision, i.e., putting Proposal 3.1-3a below together with Proposal 3.1-2a to discuss. Intel Y (pls. see comments) This is under the assumption that ※via SIB§ also includes the option of separate PUCCH resource set configuration as part of separate initial UL BWP configuration, and not necessarily an independent bit-field in a SIB. We also do not see the need to add any bullets on DL-UL center-frequency alignment to this proposal. Ericsson Y The network should be given such an option so that it can minimize PUSCH resource fragmentation should it prefers to maximize the UL peak user data rate KPI. It should be noted that having this option does not mean that the network always disables the 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 also OK with Huawei＊s proposed modification. Regarding frequency position of PUCCH as mentioned by CATT, we think it can be left to gNB implementation (or can be an FFS). FUTUREWEI2 Y in principle Clarification that the hopping is within the separate initial UL BWP, and which hop is disabled in needed Since several companies expressed concern about the potential performance loss with hopping disabled, perhaps the network can disable hopping as needed instead of always disabling. IDCC Y FL3 Based on the received responses, the following updated proposal can be considered: High Priority Proposal 3.1-2b: In case a separate initial UL BWP is configured for RedCap UEs, it is supported that the network can enable/disable intra-slot PUCCH frequency hopping within the separate initial UL BWP for HARQ feedback for Msg4/MsgB for RedCap UEs via SIB. CMCC Y CATT Y in principle We prefer to add an ＆FFS the frequency position of PUCCH＊ , to see if disabling the hopping of PUCCH is enough to alleviate the resource fragmentation. Intuitively, current mechanism may put strict limit to initial UL BWP configuration, as shown in the figures provided in the previous round discussion. Nordic Y DOCOMO Y LG Y Nokia, NSB Y Ericsson Y FUTUREWEI3 Y Similar comment about the consideration of the network disabling hopping as needed instead of always disabling hopping TCL Y Intel Y China Telecom Y Qualcomm Our concerns/comments regarding the center frequency alignment of UL/DL BWPs were not addressed, which is closely related to the separate configuration of initial UL BWP in TDD. Compared to PUSCH data rate enhancements, coverage enhancements for PUSCH/PUCCH are bigger concerns up to NR R17. For coverage limited UE, it will not be allocated with a wide BW when DFT-s-OFDM waveform is configured. Therefore, it is difficult to understand the concerns for§ PUSCH resource fragmentation§ when DFT-s-OFDM waveform is used. For non-RedCap UEs with UL peak data rate KPI (if any), NW/scheduler can consider at least the following solutions other than ※contiguous FDRA on a wide band§: 1) higher MCS 2) more spatial layers 3) CA 4) rate matching or puncturing Therefore, the necessity to disable intra-slot FH for PUCCH is not well justified. Lenovo, Motorola Mobility Y Samsung We＊d like to understand the motivation to delete ※via SIB§. We cannot accept this if the door is open to dynamic indication to disable FH, which is over optimized. Sharp 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. Xiaomi Partial Y We support same center frequency between DL/UL BWP in TDD. But As we commented in previous round, we think we＊d better discuss the center frequency alignment in DL/UL BWP in TDD and whether contain MIB-configured CORESET#0 separately. If the majority think there is a need to discuss them together, we would like update the proposal as follows the center frequencies for initial UL/DL BWPs in TDD are the same, and the initial DL BWP configured for the purpose of center frequency alignment in TDD does not necessarily contain MIB-configured CORESET #0. Qualcomm Partially Y Suggested change for FL2 proposal: For RedCap UE, 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, if CORESET and CSS for paging is configured for this initial DL BWP. Nordic Y Note that CORESET#0 does not need to be aligned in center frequency with initial UL BWP in legacy, but active initial DL BWP must LG Y If the initial DL BWP is intended for the MIB-configured initial DL BWP, then we don＊t need any agreement on that. In that sense, adding clarification wording as suggested by DOCOMO seems better. NEC Y We don＊t well understand relationship between this and last FFS point of proposal 3.1-1 as shown below * FFS whether or not to additionally support the case when the centre frequency is different; if so, how to minimize centre frequency retuning Samsung We can live with it if this is the majority view. CATT Prefer that: The center frequencies for initial UL BWP and the initial DL BWP (defined by CORESET#0) can be different during the initial access. The center frequencies for initial UL BWP and the initial DL BWP (configured by SIB) remain the same after the initial access. Huawei, HiSilicon Y for the former The latter part is duplicated with a previous proposal thus prefer to clarify why it is here. ZTE, Sanechips This issue is overlapping with the following one : 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. So it is suggested to remove the later part. Nokia, NSB Our preference is that the center frequency in TDD can be different, at least during initial access. Apple Our preference is modified Opt.2 below. * Option 2: The center frequencies for initial UL/DL BWPs are the same, and the initial DL BWP does not necessarily contain CORESET #0. On the highlighted context, we are not sure why we need to add it here as it is duplicated with Proposal 2.2-4a as pointed out by ZTE. As commented over there, if it is kept here, we want to understand what the UE behavior for this is. Without new agreement, the legacy behavior is that UE does not monitor Type0/0A for this separate initial DL BWP. Intel Same view as Nokia 每 at least when in Idle/inactive modes, it is not necessary to align DL-UL center frequencies. 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 MIB-configured CORESET #0 bandwidth. FUTUREWEI2 The second part of the proposal is similar to proposal 2.2-4a FL3 Based on the received responses, the following updated proposal can be considered: High Priority Proposal 3.1-3b: * At least after initial access, the center frequencies for separate initial UL/DL BWPs for RedCap UEs in TDD are the same, and the separate initial DL BWP does not necessarily contain MIB-configured CORESET #0. o FFS: during initial access CMCC Y CATT Y OK for progress Nordic N We do not support change to current restriction, i.e. 3.1-3a DOCOMO Y LG Y Nokia, NSB We can accept this to make progress Ericsson Y FUTUREWEI3 Y in principle As several companies mentioned, the center frequencies can be different during initial access. TCL Y Intel Y Can accept this for progress. China Telecom Y We are fine with FL proposal. Qualcomm N This proposal is for RRC connected UE. Therefore, ※the separate initial DL BWP does not necessarily contain MIB-configured CORESET #0§ is related to FG 6-1a. The discussion of center frequency alignment of DL/UL BWPs in TDD can be, and should be de-coupled from FG 6-1a. Lenovo, Motorola Mobility Y Some suggestions 1) the latter sentence overlaps with 2.2-4b, can be deleted 2) the word ※separate§ can be deleted, since no matter if the initial DL BWP is separate or not, it shall be co-centered with initial UL BWP after initial access During initial access, the center frequency of initial DL BWP (defined by CORESET#0) and initial UL BWP are not necessarily the same. This is also what TDD is using in legacy. Samsung Y Sharp Y 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 Xiaomi Y Qualcomm Y Nordic Y Note that CORESET#0 does not need to be aligned in center frequency with initial UL BWP in legacy, but active initial DL BWP must LG Y NEC Y Panasonic Y CATT We think AI 8.6.2 is not going to discuss any potential frequency domain issue or new SSB-to-RO mapping issue. Prefer to discuss here. Huawei, HiSilicon N Same comments as before Spreadtrum Y ZTE, Sanechips Y Nokia, NSB Y Apple Y Intel Y Ericsson Y Also fine without the 2nd sub-bullet. FUTUREWEI2 How to share ROs is related to the initial UL BWP and should be discussed here, not in 8.6.2 FL3 Based on received responses, the original proposal can be considered again, i.e.: High Priority Proposal 3.2-1: Confirm the following 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. CMCC Y CATT Y Though we are fine to confirm the WA, we think the issues raised before by Huawei, OPPO and CATT still needs further discussion. Nordic Y DOCOMO Y LG Y Nokia, NSB Y Ericsson Y FUTUREWEI3 Y We need to discuss how to ensure that the shared resources are within BWP used during initial access TCL Y Intel Y China Telecom Y Qualcomm Y Lenovo, Motorola Mobility Y Sharp 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. Xiaomi N We are OK with that the RRC-configured non-initial BWP doesn＊t contain ※MIB-configured§ CORESET#0 and cell-defined SSB. But we are not OK with UE mandatorily support BWP without SSB. So, we＊d like to propose a way forward as compromise * 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 MIB-configured CORESET#0 or cell-defined SSB. - The active UE-specific RRC configured DL BWP and one or both of cell-defined SSB and MIB-configured 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. * UEs support FG 6-1ax as an optional capability with the following clarification - UE-specific RRC configured BWP may not include (cell-defined or additional) SSB Qualcomm N For UE-specific RRC configured DL BWP, FG 6-1a is supported as an optional feature for R17 RedCap UE in FR1. Nordic N Since initial DL BWP may be used as dedicated/user-specific BWP in BWP option 2, we do not see difference to 2.2.-6 per se. And fully agree with comments from VIVO. LG N Even if it was there in the original proposal, but the current wording in the second bullet seems to be misleading rather than further clarifying it. It seems to allow that the bandwidth of the active UE-specific RRC configured DL BWP can exceed the max RedCap UE bandwidth in some cases. Frankly speaking, the second bullet is not needed if we can＊t come up with a better wording. NEC N Agree with Qualcomm. Panasonic As CMCC mentioned, the discussion on Proposal 2.2-6a is related. Samsung Y We suggest to discuss this proposal together with proposal 2.2-6a. If UE support F6-1a as mandatory, we don＊t see the point to agree on proposal 2.2-6a. 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 CATT Y Otherwise the concern raised by Ericsson seems never be tackled. Huawei, HiSilicon Y And, prefer companies to explain what exactly the UE complexity is. Spreadtrum N Our 3 priorities are listed as follows: 1st priority: FG 6-1a is optional capability for RedCap UE: the separate initial DL BWP for RedCap UE contains SSB and CSS. The separate initial DL BWP and the separate initial UL BWP have the same center frequency. 2nd priority: FG 6-1a is optional capability for RedCap UE: RedCap UEs and non-RedCap UEs share the legacy initial DL BWP (the same frequency location as CORESET#0). The legacy initial DL BWP and the separate initial UL BWP can have different center frequencies. 3rd priority: FG 6-1a is mandatory capability for RedCap UE: the separate initial DL BWP for RedCap UE contains CSS. The separate initial DL BWP and the separate initial UL BWP have the same center frequency. UE should timely switch RF outside the active BWP for T/F tracking with SSB and RRM measurement at least for serving cell with SSB. ZTE,Sanechips This proposal is related to the discussion of the following two issues. If SSB and MIB-configured CORESET0 not transmitted in initial DL BWP are agreed, we are OK to mandate 6-1a, otherwise, keep it optional. 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. FFS: suitable SSB periodicity considering impacts in terms of signaling overhead and performance 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. Nokia, NSB Y We prefer that RedCap UE supports FG 6-1a so that configured DL BWP does not have to contain SSB. Apple N Same comments as in 1st round. Intel Y Just because a feature is optional for non-RedCap UEs is not a sufficient reason that it cannot be mandatory for a RedCap UE. It should be clear that the handling would need to be different for RedCap UE (as compared to non-RedCap UE) as should be clear from the FFS bullet. It would be more constructive to understand why RedCap UE should not support FG 6-1a if means to enable the UE to perform T-F tracking, measurements, and common control reception are addressed for RedCap UEs. It would be extremely inefficient if everything needs to be duplicated in active DL BWP for RedCap UEs. Ericsson Y FL3 Based on received responses, we can come back to this issue after Proposal 2.2-6b has seen some progress. 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) [44] R1-2108268 FL summary #2 on reduced maximum UE bandwidth for RedCap Moderator (Ericsson)