3GPP TSG-RAN WG1 Meeting #106-e R1-21xxxxx e-Meeting, 16th 每 27th August 2021 Agenda Item: 8.6.1.1 Title: FL summary #5 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] 每 [44]. 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 issues tagged ＆FL8＊ before Wednesday 25th August 14:00 UTC. Follow the naming convention in this example: * RedCapBwFLS5-v000.docx * RedCapBwFLS5-v001-CompanyA.docx * RedCapBwFLS5-v002-CompanyA-CompanyB.docx * RedCapBwFLS5-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 RedCapBwFLS5-v002-CompanyA-CompanyB.docx. * CompanyC uploads an empty file named RedCapBwFLS5-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 RedCapBwFLS5-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). The following agreement was made in an online (GTW) session on Friday 20th August: Agreement: 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). 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. 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 Xiaomi Y Although there are some FFS points unsolved, to make progress, we tend to agree this proposal as a working assumption. As the FFS points listed by CATT, in our understanding, some of them are related to the motivation of supporting separate initial DL BWP while some of them are just related how the separate initial DL BWP work. In our view, we don＊t need to let all the FFS solved before we agree the proposal. Once the motivation of the separate initial DL BWP is confirmed e.g., the center frequency of DL/UL BWP must be aligned, then the proposal can be agreed. NEC We prefer to discuss Proposal 2.2-6b first, especially whether a RedCap UE supports retuning to SSB (assuming CD-SSB) outside of a separate initial DL BWP during initial access. If a RedCap UE can support retuning to SSB outside of a separate initial DL BWP, we don＊t see much necessity to use a separate initial DL BWP instead of MIB-configured initial DL BWP during initial access. It would not be prohibited by spec a RedCap UE would retune between MIB-configured initial DL BWP and a separate initial UL BWP. vivo Two comments: 1. Based on the inputs from 1st and 2nd round, there were multiple companies proposed to include CSS for paging and it seems no concern raised, we suggest to include paging in the proposal and delete the FFS. 2. It seems companies have different view on the implication of SSB availability in the separate initial DL BWP configured for RedCap UEs, our understanding is that the SSB issue will be decided separately (High Priority Proposal 2.2-6b) and there is no implication for that. Maybe some clarification from FL would be needed. Apple We shared the concerns raised by CATT as commented in previous round. If FL still think the current formulation of proposals are better, we suggest discussing the Proposal 2.2-6b first as also commented by NEC above. Our view is that addressing Proposal 2.2-6b would help solving other open issues. ZTE, Sanechips Y It is seen that Medium Priority Proposal 2.2-5, High Priority Proposal 2.2-6b, and High Priority Proposal 3.1-3b actually address most FFS raised by CATT. Moreover, if the BW of initial DL BWP for non-RedCap UE is larger than the RedCap UE bandwidth, a separate initial DL BWP is needed. Also, considering the motivation of offloading and reducing RF retuning for TDD, this separate initial DL BWP is required during/after RACH procedure. OPPO Y CSS for paging shall be configured in the additional initial DL BWP. FL4 Based on the received responses, the following updated proposal can be considered. High Priority Proposal 2.2-3c: If configuration of a separate initial DL BWP for RedCap UEs (if configured) is supported, it can be used during the initial access. * The separate initial DL BWP for RedCap UEs includes CORESET and CSS at least for RACH and paging. vivo Y Huawei, HiSilicon FFS We would appreciate more discussion and efforts placed for fundamentally controversial issue first, even though we may not object some proposal for optimization later, but those is not preferred to be prioritized for discussion given current situation. Our observation is that: - With addressing CATT＊s comments in FLS3, even if without separate CROESET/CSS, the system works. - Without understanding how additional SSB is available and addressing CATT comments, the system does not work 每 e.g. how UE know whether/where the additional SSB is. - Supporting additional SSB already implies that a UE MUST support RF retuning, which does not seem to impose additional spec impact and implementation impact. Qualcomm N Thanks FL for the update. FL4 proposal is better than the previous version, but the SSB transmission in this initial DL BWP is still not addressed. Suggestion: * To begin with, we can address the additional SSB transmission for FR1, since it was agreed to support FG 6-1 as a mandatoryR17 RedCap UE feature in FR1. * We can combine this proposal with Proposal 2.2-6c, or prioritize the discussion for Proposal 2.2.-6c. Samsung Y For IDLE mode, in current FR2, pattern 2/3, Redcap UE has to support No SSB in CORESET 0, i.e., iDL BWP. We don＊t see an issue for other cases. We think CATT＊s FFS are the thing we need to do, but can be decouple from this proposals. CATT FFS Thanks many companies for your patience and sharing your views. We understand that some on-gonging proposals are about the FFS raised by CATT. This is also where our concerns come from: company views are still quite split. Here the fact is that, the outcome of Medium Priority Proposal 2.2-5 (configurable set of bandwidth), High Priority Proposal 2.2-6b (SSB issue), High Priority Proposal 3.1-3b (center frequency issue), and some other points raised before, are likely be the premise of applying the separate initial DL BWP during the initial access. What if we rush to such agreement first, but reach consensus in the raised FFS part that not capable for initial access (at least to some companies)? Are we happy to overturn this ＆potential agreement＊? FL＊s update seems not help much. Prefer to defer this proposal until the above FFS parts (at least SSB, center frequency, SIB transmission) are clear, or consider the following version: High Priority Proposal 2.2-3c: If configuration of a separate initial DL BWP for RedCap UEs is supported, further study the conditions if it can be used during the initial access. * The separate initial DL BWP for RedCap UEs includes CORESET and CSS at least for RACH and paging. * 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 * 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 center frequencies of the separated initial DL BWP and the separated initial UL BWP must be aligned. It should not be difficult to draw a conclusion, as long as the FFS are clear. We remove one the FFS point on the value of configurable PRBs. It may be with lower priority, but we see that: * On the configurable bandwidth, currently the bandwidth of initial DL BWP during the initial access (CORESET#0) can only be {24, 48, 96} PRBs. This {24, 48, 96} PRBs will be used to determine the DCI size for FDRA field during initial access. However, there is no limit on the bandwidth of the initial DL BWP (SIB1-configured) after initial access. So: * Is there any issue if the BW of separate initial DL BWP can be other values other than {24, 48, 96}? E.g. 106 PRBs? (We hope no issue, but not sure) Even if the set is still {24, 48, 96}, is there any issue if different BW value from original initial DL BWP is configured? E.g. 96 PRBs for non-RedCap initial DL BWP but 48 PRBs for RedCap initial DL BWP during initial access. This may require the RedCap UE using different DCI size assumption before RRC_CONNECTED (96 PRB for receiving SIB1 and 48 PRB for receiving Msg2/4). (We hope no issue, but not sure) Spreadtrum Y If companies have concerns, it can be discuss more. For understanding each other＊s view clearly, we list our 3 priorities 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. Note for difference b/w FG 6-1a and RF retuning in a BWP wider than the RedCap UE bandwidth: - For RF retuning in a BWP wider than the RedCap UE bandwidth, the RedCap UE should dynamically retuning RF to cover the dynamic resource allocation and frequency hopping resource in symbol or slot level. There are many UE behaviors need to be checked referring to our contribution [R1-2106705]. - For FG 6-1a, the RedCap UE should retune RF to process SSB, e.g. T/F tracking and RRM measurement. - In our view, RF retuning in a BWP wider than the RedCap UE bandwidth is more complicated than FG 6-1a. Note for SSB/CORESET0 multiplexing patter 2/3: Although the initial DL BWP is not include SSB, the FR2 UE has the baseline channel BWP to cover the initial DL BWP and SSB both. In the FR2 UE implementation, it open the wide channel bandwidth to cover initial DL BWP and SSB both CMCC Y IDCC Y ZTE, Sanechips Y If Proposal 2.2-6b (SSB issue) and Proposal 3.1-3b (center frequency issue), are handled, the concerns for this proposal might be reduced. MediaTek Y Nordic N @Intel: where CORESET#0 is located does not matter as soon as it is inside initial DL BWP and BWPs are aligned. @CATT: Regarding separate initial DL BWP size, we are fine with any size satisfying 20MHz carrier BW, no need to limit as soon as DCI format size is based on CORESET#0 by MIB @FL: Our understanding is that separate initial DL BWP is supported (as WA) after initial access. We do not see any technical issue with it, as illustrated in the Figure we provided. So no reason to revert this WA. * In NR CORESET#0 must be within initial DL BWP on PCell * SSB must be After removing FFS this is what we have at the moment 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 * 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). Nokia, NSB Similar view as before that more discussion / clarification is needed before we can agree to this proposal. FUTUREWEI4 FFS As mentioned by other companies, other proposals are should first be addressed before coming back to this proposal DOCOMO Y NEC FFS We consider Nordic＊s comment is valid. Ericsson Y, with changes In RRC_CONNECTED, paging need not be in the initial DL BWP even for legacy UEs. In RRC_IDLE, we need to study further whether the RedCap UEs can also be paged in the MIB-configured initial DL BWP. Therefore, we prefer to keep the FFS related to paging. However, we are OK with the proposal if the following update is made: * The separate initial DL BWP for RedCap UEs includes CORESET and CSS at least for RACH and paging. * The separate initial DL BWP for RedCap UEs can be configured to include CORESET and CSS for paging. Intel N We can accept the sub-bullet (or the version from Ericsson), but NOT the main bullet. As Nordic pointed out, we already have WA on separate initial DL BWP for connected state. So, as commented the last time, the conditioning should be on ※if separate initial DL BWP for RedCap UEs is supported for use during initial access§ OPPO Y But we are wondering what is the relationship with the previous WA: 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 Lenovo, Motorola Mobitity We prefer more on 2.2-3b, which is clearer. FL5 This proposal has been merged into Proposal 2.2-4d. 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 Xiaomi Y Although there are some FFS points unsolved, to make progress, we tend to agree this proposal as a working assumption. As the FFS points listed by CATT, in our understanding, some of them are related to the motivation of supporting separate initial DL BWP while some of them are just related how the separate initial DL BWP work. In our view, we don＊t need to let all the FFS solved before we agree the proposal. Once the motivation of the separate initial DL BWP is confirmed e.g., the center frequency of DL/UL BWP must be aligned, then the proposal can be agreed. NEC We prefer to discuss Proposal 2.2-6b first, especially whether a RedCap UE supports retuning to SSB (assuming CD-SSB) outside of a separate initial DL BWP during initial access. If a RedCap UE can support retuning to SSB outside of a separate initial DL BWP, we don＊t see much necessity to use a separate initial DL BWP instead of MIB-configured initial DL BWP during initial access. It would not be prohibited by spec a RedCap UE would retune between MIB-configured initial DL BWP and a separate initial UL BWP. vivo Two comments: 1. Based on the inputs from 1st and 2nd round, there were multiple companies proposed to include CSS for paging and it seems no concern raised, we suggest to include paging in the proposal and delete the FFS. 2. It seems companies have different view on the implication of SSB availability in the separate initial DL BWP configured for RedCap UEs, our understanding is that the SSB issue will be decided separately (High Priority Proposal 2.2-6b) and there is no implication for that. Maybe some clarification from FL would be needed. Apple We shared the concerns raised by CATT as commented in previous round. If FL still think the current formulation of proposals are better, we suggest discussing the Proposal 2.2-6b first as also commented by NEC above. Our view is that addressing Proposal 2.2-6b would help solving other open issues. ZTE, Sanechips Y It is seen that Medium Priority Proposal 2.2-5,High Priority Proposal 2.2-6b, and High Priority Proposal 3.1-3b actually address most FFS raised by CATT. Moreover, if the BW of initial DL BWP for non-RedCap UE is larger than the RedCap UE bandwidth, a separate initial DL BWP is needed. Also, considering the motivation of offloading and reducing RF retuning for TDD, this separate initial DL BWP is required during/after RACH procedure. OPPO Y CSS for paging shall be configured in the additional initial DL BWP. FL4 Based on the received responses, the following updated proposal can be considered. High Priority Proposal 2.2-3c: If configuration of a separate initial DL BWP for RedCap UEs (if configured) is supported, it can be used during the initial access. * The separate initial DL BWP for RedCap UEs includes CORESET and CSS at least for RACH and paging. vivo Y Huawei, HiSilicon FFS We would appreciate more discussion and efforts placed for fundamentally controversial issue first, even though we may not object some proposal for optimization later, but those is not preferred to be prioritized for discussion given current situation. Our observation is that: - With addressing CATT＊s comments in FLS3, even if without separate CROESET/CSS, the system works. - Without understanding how additional SSB is available and addressing CATT comments, the system does not work 每 e.g. how UE know whether/where the additional SSB is. - Supporting additional SSB already implies that a UE MUST support RF retuning, which does not seem to impose additional spec impact and implementation impact. Qualcomm N Thanks FL for the update. FL4 proposal is better than the previous version, but the SSB transmission in this initial DL BWP is still not addressed. Suggestion: * To begin with, we can address the additional SSB transmission for FR1, since it was agreed to support FG 6-1 as a mandatoryR17 RedCap UE feature in FR1. * We can combine this proposal with Proposal 2.2-6c, or prioritize the discussion for Proposal 2.2.-6c. Samsung Y For IDLE mode, in current FR2, pattern 2/3, Redcap UE has to support No SSB in CORESET 0, i.e., iDL BWP. We don＊t see an issue for other cases. We think CATT＊s FFS are the thing we need to do, but can be decouple from this proposals. CATT FFS Thanks many companies for your patience and sharing your views. We understand that some on-gonging proposals are about the FFS raised by CATT. This is also where our concerns come from: company views are still quite split. Here the fact is that, the outcome of Medium Priority Proposal 2.2-5 (configurable set of bandwidth), High Priority Proposal 2.2-6b (SSB issue), High Priority Proposal 3.1-3b (center frequency issue), and some other points raised before, are likely be the premise of applying the separate initial DL BWP during the initial access. What if we rush to such agreement first, but reach consensus in the raised FFS part that not capable for initial access (at least to some companies)? Are we happy to overturn this ＆potential agreement＊? FL＊s update seems not help much. Prefer to defer this proposal until the above FFS parts (at least SSB, center frequency, SIB transmission) are clear, or consider the following version: High Priority Proposal 2.2-3c: If configuration of a separate initial DL BWP for RedCap UEs is supported, further study the conditions if it can be used during the initial access. * The separate initial DL BWP for RedCap UEs includes CORESET and CSS at least for RACH and paging. * 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 * 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 center frequencies of the separated initial DL BWP and the separated initial UL BWP must be aligned. It should not be difficult to draw a conclusion, as long as the FFS are clear. We remove one the FFS point on the value of configurable PRBs. It may be with lower priority, but we see that: * On the configurable bandwidth, currently the bandwidth of initial DL BWP during the initial access (CORESET#0) can only be {24, 48, 96} PRBs. This {24, 48, 96} PRBs will be used to determine the DCI size for FDRA field during initial access. However, there is no limit on the bandwidth of the initial DL BWP (SIB1-configured) after initial access. So: * Is there any issue if the BW of separate initial DL BWP can be other values other than {24, 48, 96}? E.g. 106 PRBs? (We hope no issue, but not sure) Even if the set is still {24, 48, 96}, is there any issue if different BW value from original initial DL BWP is configured? E.g. 96 PRBs for non-RedCap initial DL BWP but 48 PRBs for RedCap initial DL BWP during initial access. This may require the RedCap UE using different DCI size assumption before RRC_CONNECTED (96 PRB for receiving SIB1 and 48 PRB for receiving Msg2/4). (We hope no issue, but not sure) Spreadtrum Y If companies have concerns, it can be discuss more. For understanding each other＊s view clearly, we list our 3 priorities 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. Note for difference b/w FG 6-1a and RF retuning in a BWP wider than the RedCap UE bandwidth: - For RF retuning in a BWP wider than the RedCap UE bandwidth, the RedCap UE should dynamically retuning RF to cover the dynamic resource allocation and frequency hopping resource in symbol or slot level. There are many UE behaviors need to be checked referring to our contribution [R1-2106705]. - For FG 6-1a, the RedCap UE should retune RF to process SSB, e.g. T/F tracking and RRM measurement. - In our view, RF retuning in a BWP wider than the RedCap UE bandwidth is more complicated than FG 6-1a. Note for SSB/CORESET0 multiplexing patter 2/3: Although the initial DL BWP is not include SSB, the FR2 UE has the baseline channel BWP to cover the initial DL BWP and SSB both. In the FR2 UE implementation, it open the wide channel bandwidth to cover initial DL BWP and SSB both CMCC Y IDCC Y We see that several companies have concerns and would like to discuss further some other relevant aspects. We are ok with CATT＊s version as well. ZTE, Sanechips Y If Proposal 2.2-6b (SSB issue) and Proposal 3.1-3b (center frequency issue), are handled, the concerns for this proposal might be reduced. MediaTek 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 Xiaomi N Still, we repeat our comment as follows . * 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. Panasonic Y vivo ※May or may not§ could be interpret in a way that more RAN1 discussion is needed to conclude this issue. Suggest update to be consistent with text used in the other proposal High Priority Proposal 3.1-3b, as following 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 does not necessarily contain the entire MIB-configured CORESET #0. Apple N We do not want to repeat our earlier comment. Potential modification is as follows to capture UE behavior: Modified 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. * Alt.1: A Redcap UE is required to monitor search spaces in MIB-configured CORESET#0 if it is not within the SIB-configured separate initial DL BWP for Redcap UEs. * Alt.2: Reuse Rel-15/16 behavior and UE is not required to monitor search spaces in MIB-configured CORESET#0 if it is not within the SIB-configured separate initial DL BWP for Redcap UEs. ZTE, Sanechips Y If separate initial DL BWP does not contain COREET0 during initial access, this separate initial DL BWP still can be used after initial access. Therefore, the limitation ＆during initial access＊ for this proposal is not needed. OPPO Y FL4 Based on the received feedback, the following updated proposal can be considered. High Priority Proposal 2.2-4c: If a SIB-configured separate initial DL BWP for RedCap UEs is configured, it may or may does not necessarily contain the entire MIB-configured CORESET #0. Vivo Y Huawei, HiSilicon Y For progress. ※may or may not§ is the same as ※not necessarily§ - the ※may§ is more widely used in RAN1 agreements and even used in spec, I think - but fine if it makes the other side more comfortable. Qualcomm Is this initial DL BWP used during initial access, after initial access, or both? If this initial DL BWP is used after initial access, we think it is necessary to revise the first sentence of Proposal 2.2-4c as ※is optionally configured§. Samsung Y We don＊t think ※optionally§ is needed. The proposal only say if separate BWP is configured, it implies that there is a case that the separate BWP is not configured. CATT By reading the comments, we this proposal is more or less related to the question ＆whether the initial DL BWP can be used during the initial access＊. Companies seem to have different assumptions on this issue. Though we think it may be OK, we prefer to jointly consider this issue in FL proposal 2.2-3. Spreadtrum Y CMCC Y IDCC Y ZTE, Sanechips Y MediaTek Y Nordic Y, but It MUST contain at least RACH CSS and associated CORESET Nokia, NSB Y FUTUREWEI4 Y DOCOMO Y NEC Maybe OK. Ericsson We propose to capture non-initial DL BWP as well in the proposal. Intel Y OPPO Y LG Y FL5 Based on the received feedback, the following updated proposal can be considered, where parts of Proposal 2.2-3c have been incorporated. High Priority Proposal 2.2-4d: If a separate initial DL BWP for RedCap UEs is supported and configured, * It does not necessarily may or may not contain the entire MIB-configured CORESET #0. * It can be used during the initial access. * It includes CORESET and CSS at least for RACH (FFS: and paging). Huawei, HiSilicon FFS Thanks for the attempt. It is necessary to discuss those together. The below could be a set of proposals for further discussion, or we prefer the previous simpler one which has large amount of support. If a separate initial DL BWP for RedCap UEs is supported and configured, * It does not necessarily may or may not contain the entire MIB-configured CORESET #0. * It can be used configured without its BW containing SSB at least during the initial access. * It includes CORESET and CSS at least for RACH (FFS: and paging). Nordic N We do not understand why FL thinks that initial DL BWP is not supported. It is supported as Working assumption. High Priority Proposal 2.2-4d: If a separate initial DL BWP for RedCap UEs (current Working assumption) is configured, * It does not necessarily may or may not contain the entire MIB-configured CORESET #0. * It can be used during the initial access. * It includes CORESET and CSS at least for RACH (FFS: and paging). Furthermore, we disagree with Huawei. SSB aspect is a separate issue, and relates to currently agreed mandatory capability 6-1 and optional capability 6-1a. Agreement: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. Vivo N 1. ※If＃.supported§ in the main bullet is a big step back, should be removed, ※If＃configured§ is sufficient 2. For the FFS of paging CSS, we are fine with the Ericsson＊s update in the previous round, hope that can be agreeable. 3. We do not agree with Huawei about the yellow added part, we think we should put all the SSB related issues together in a package proposal. Updated version could be as following. If a separate initial DL BWP for RedCap UEs is supported and configured, * It does not necessarily may or may not contain the entire MIB-configured CORESET #0. * It can be used during the initial access. * It includes CORESET and CSS at least for RACH (FFS: and paging). * It can be configured to include CORESET and CSS for paging. Panasonic Y in principle For clarification, ※CORESET and CSS at least for RACH" should be changed to "at least CORESET containing a type-1 PDCCH CSS for RedCap§ CATT FFS The concerns originally raised in 2.2-3 are not tackled, and come here subsequently. But at least we have the chance to discuss 2.2-3 with CORESET#0 together. This is a good starting point we think. Prefer to reach consensus on the following 3 issues first, if the group try to agree ＆use the separate initial DL BWP during the initial access＊ * Whether must include SSB (after outcome of proposal 2.2-6) * Whether must align center frequencies of initial DL/UL BWP during initial access (after outcome of 3.1-3) * Whether must include CORESET#0 derived from MIB (seems no, according to the current wording, if consensus is reached) Though SIB transmission may also be important but we are fine to put it in a lower priority, so we delete it from the above list. DOCOMO Y Lenovo, Motorola Mobility N We could understand why FL has such condition ※if ＃.supported§ in the main bullet. We do have a working assumption to support separate initial BWP, but currently it is just for TDD, and FFS for FDD. However, as vivo commented, having ※if＃supported§ seems big step back. There is risk that the issue will be discussed again and again, which is of course not expected. We then see a need to firstly confirm the working assumption as in 2.2-1, but maybe a simple version such as just keeping the main bullet, and revise it to include FDD (as suggested in below). The FFS in the WA (in the sub-bullets) has been more or less handled by other proposals, therefore they could be removed. Working assumption: * At least for TDD and FDD, 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 With this, we could use the version from Nordic (which we support) and collect views. Intel N We still prefer NOT to agree to use of the separate initial DL BWP during initial access before we know some of the related details, esp. related to center-freq alignment and how the handling is unified or distinct from separate initial DL BWP after initial access or UE-specifically configured DL BWPs (as also commented by Ericsson in the previous round). The previous version seemed aggregable (acknowledge that it was a smaller step but may be that is what we can do as a first step) and something we could try again. FUTUREWEI5 FFS We preferred 2.2-4c. This proposal does attempt to describe the attributes of the separate initial DL BWP. Similar comment about using Type1-PDCCH CSS instead ※CSS at least for RACH§. CMCC Y TCL Y ※If＃.supported§ in the main bullet should be removed. NEC Y We share similar view as Intel. 2.2-4c would be OK for us. We are also not sure which DL BWP is used by RedCap UE in IDLE. Samsung Prefer Vivo＊s version. Xiaomi N Thanks for the FL＊s update. It seems the FL attempt to tackle the following issues in the proposal - Whether support separate DL BWP for the case during initial access, which highly depends on whether support the center frequency alignment in TDD - Whether include the MIB-configured CORESET#0 - Which CORESET/ SS should be included in the separate initial DL BWP But considering the situation for the case of during initial access and the case of after initial BWP is different, we think we＊d better to discuss these issues separately. The following are the issues we need to handle for different cases. * For the case during initial access (at least for the purpose of center frequency alignment in TDD) - Whether support the separate initial DL BWP, which is highly depends on the support of center frequency alignment in TDD - Whether include the MIB-configured COREST#0 - Whether include the SSB - Which CORESET/SS should be included * For the case after initial access (separate DL BWP is needed when the SIB-configured initial DL BWP for non-RedCap is wider than RedCap＊s UE BW) - Whether confirm the previous WA (separate initial DL is already supported for TDD as a WA) - The relationship between the separate DL BWP for RedCap used after initial access and the one used during initial access * Opt1: The separate initial DL BWP should be included in the initial DL BWP used during initial access. For this case, it implies the separate initial DL BWP will reuse the SSB and MIB-configured CORESET#0 used during initial access * Opt 2: The separate initial DL BWP used after initial access is NOT required to be overlapped with the one used during initial access . For this case, we can further discuss whether include the MIB-configured CORESET#0 /SSB and which CORSET/SS should be included. LG Y But, prefer to remove the ※supported and§ as commented by a few other companies. Ericsson Y We are fine with Vivo＊s revision (with some minor updates): If a separate initial DL BWP for RedCap UEs is supported and configured, * It does not necessarily may or may not contain the entire MIB-configured CORESET #0. * It can be used during the initial access. * It includes CORESET and CSS at least for RACH during initial access. (FFS: and paging). * It can be configured to include CORESET and CSS for paging. We may also consider replacing ※during the initial access§ by ※for RACH§ in the second bullet above for clarity. Note that the proposal is pending confirmation of the working assumption. ZTE, Sanechips Based on the vivo＊s version, since the initial DL BWP can also be used after initial access, a minor update is shown as following If a separate initial DL BWP for RedCap UEs is supported and configured, * It does not necessarily may or may not contain the entire MIB-configured CORESET #0. * It can be used during the initial access at least. * It includes CORESET and CSS at least for RACH (FFS: and paging). * It can be configured to include CORESET and CSS for paging. FL6 Based on the received feedback, the following updated proposal can be considered. Note that, if necessary, different proposals can be agreed together or in a particular order. High Priority Proposal 2.2-4e: * If a separate initial DL BWP for RedCap UEs (as per current working assumption) is configured, o It may or may not contain the entire MIB-configured CORESET #0. o It can be used at least for RACH during the initial access. o It includes at least CORESET and containing a type-1 PDCCH CSS for RedCap at least for RACH during initial access (FFS: and paging). o It can be configured to include CORESET and CSS for paging. Huawei, HiSilicon FFS We don＊t mind the main bullet is per WA or not 每 although it is actually not as the previous WA is for ※after initial access§, so some of the comments from others are not accurate. We also don＊t agree with SSB as a separate issue, the previous WA also explicitly indicate they are tightly related, and the baseline is CORESET#0 is always tied with SSB 每 if a MIB-configured CORESET#0 for some reason can be absent, we think it is the same as SSB. But, we could be ok to discuss this issue together with SSB as vivo concerned. We, unfortunately also disagree with the statement about FG 6-1 or 6-1a, they are on one hand for ※after initial access§ and on the other hand, not precluding 6-1a as a mandatory feature. 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 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 We think, the below seems to be a set of proposals for discussion: * If a separate initial DL BWP for RedCap UEs (as per current working assumption) is configured, o It may or may not contain the entire MIB-configured CORESET #0. o It can be used configured without its BW containing SSB at least during the initial access. o It can be used at least for RACH during the initial access. o It can be configured to includes at least CORESET and containing a type-1 PDCCH CSS for RedCap at least for RACH during initial access (FFS: and paging). o It can be configured to include CORESET and CSS for paging. Spreadtrum Y The current wording is general enough vivo Y The FL6 proposal looks fine. Regarding Huawei＊s comment about SSB, our understanding is that all the SSB issues will be addressed in another package proposals (including IDLE and CONNECTED modes) Nordic Y We would still prefer to clarify that DCI format 1_0 and 0_0 is still given by CORESET#0 by MIB in separate initial DL BWP IDCC Y We support this proposal. Nokia, NSB We still prefer not to use the initial DL BWP during initial access. However, we can live with this proposal if it is the majority view. FUTUREWEI6 Y Qualcomm To move forward, our suggestion is to split the proposal into different use cases based on whether or not the DL BWP can be used by RedCap UE during initial access For example, * If a separate initial DL BWP for RedCap UEs (as per current working assumption) is configured, which can be used during initial access and after initial access; o It may or may not contain the entire MIB-configured CORESET #0. o It includes at least CORESET/CSS for RACH and paging. o Additional SSB is transmitted in this DL BWP, if CD-SSB is not included * If a separate initial DL BWP for RedCap UEs (as per current working assumption) is configured, which cannot be used during initial access o It may or may not contain the entire MIB-configured CORESET #0. o It is configured to include periodic TRS, CORESET and CSS at least for paging. o UE is configured with intra-frequency measurement gap for SSB, if SSB is not transmitted in this DL BWP Ericsson Y, with minor changes We suggest the following update: High Priority Proposal 2.2-4e: * If a separate initial DL BWP for RedCap UEs (as per current working assumption) is configured, o It may or may not contain the entire MIB-configured CORESET #0. o It can be used at least for RACH during the initial access. o It includes at least CORESET and containing a type-1 PDCCH CSS for RedCap at least for RACH during initial access (FFS: and paging). o From RAN1 perspective, it can be configured to include CORESET and CSS for paging. Apple N For the case that initial DL BWP for Redcap devices does not include CORESET 0, our concern on the associated UE behaviour was not addressed without any reason. See detailed comment in the previous round. DOCOMO Y Lenovo, Motorola Mobility Y Intel Y (almost) Since the first bullet refers to the WA, it would only be apt to be consistent with the fact that the WA only has been made for use of separate initial DL BWP after initial access. Also, the third sub-bullet should have one level further indentation - under the second sub-bullet that talks about using the separate initial DL BWP during initial access. Thus, we would suggest the following revision and the indentation update to the latest version from Ericsson. High Priority Proposal 2.2-4e: * If a separate initial DL BWP for RedCap UEs (as per current working assumption) is configured, o It may or may not contain the entire MIB-configured CORESET #0. o It can be used at least for RACH during the initial access, if use of separate initial DL BWP during initial access is supported. * It includes at least CORESET and containing a type-1 PDCCH CSS for RedCap at least for RACH during initial access (FFS: and paging). o From RAN1 perspective, it can be configured to include CORESET and CSS for paging. OPPO Y We support the proposal CATT N We would appreciate if FL can explicitly handle ＆different proposals in a particular order＊. Specifically, we have already provided the suggested order as: Firstly Reach consensus on the following 3 issues: * Whether must include SSB for RRC_IDLE UE during initial access. * Whether must align center frequencies of initial DL/UL BWP during initial access * Whether must include CORESET#0 derived from MIB Secondly, conclude whether the separate initial DL BWP can be used during the initial access. We also prefer that SSB is NOT mandated in the separate initial DL BWP. Samsung Y Fine with Ericsson＆s update. @CATT, we think the questions you mentioned are valid and we are discussing them in separated proposal. Based on current discussion, it seems like the proposal can work, regardless of the answer to your questions. We think we can at least take this at least as WA. We also support SSB not mandated in the separate iDL BWP. ZTE, Sanechips Y with modification From our understanding, the second sub-bullet and third sub-bullet is somewhat overlapped for FL-6 proposal. Therefore, a minor update (indentation of third sub-bullet) based on Ericsson＊s version is provided. High Priority Proposal 2.2-4e: * If a separate initial DL BWP for RedCap UEs (as per current working assumption) is configured, o It may or may not contain the entire MIB-configured CORESET #0. o It can be used at least for RACH during the initial access. * It includes at least CORESET and containing a type-1 PDCCH CSS for RedCap at least for RACH during initial access (FFS: and paging). o From RAN1 perspective, it can be configured to include CORESET and CSS for paging. Additionally, regarding the SSB transmission in initial DL BWP, it can be discussed in other proposals. Panasonic Y in principle Thank you FL for clarifying CORESET and type1-PDCCH CSS. We suggest "for RACH" should be changed to "for random access procedure" as random access channel (Msg1) itself is not sent in DL. NEC Our preference would be to use CORESET#0 bandwidth configured by MIB during initial access but if it is majority＊s view, we can live with the proposal. We are OK with Intel＊s revision. Regarding monitoring paging on a separate initial DL BWP, we see need to consult with RAN2. RAN1 should not decide it. We have another question. According to the proposal if a RedCap UE would monitor paging on a separate initial DL BWP, would a RedCap UE retune to CORESET#0 configured by MIB for SIB acquisition? Xiaomi N Similar comments with previous round, the discussion should be separate for the case during initial access and the case after initial access. * If a separate initial DL BWP for RedCap UEs is configured to be used during initial access and after initial access; o It may or may not contain the entire MIB-configured CORESET #0. o It includes at least CORESET and containing a type-1 PDCCH CSS for RedCap at least for RACH during initial access (FFS: and paging). o It can be configured to include CORESET and CSS for paging. * If a separate initial DL BWP for RedCap UEs is configured, which is only used after initial access o FFS: the relationship with initial DL BWP used during initial access - Opt1: The separate initial DL BWP should contain the initial DL BWP used during initial access. - Opt 2: The separate initial DL BWP does NOT necessarily contain the initial DL BWP used during initial access For the case only used after initial access, we think the principle for the non-RedCap should be reused. For non-RedCap devices, if SIB reconfigure another wider initial DL BWP, it contains the MIB-configured initial DL BWP, Redcap should follow this principle as well. CMCC Y LG We prefer to the previous version with FFS for paging. Huawei, HiSilicon To reply @Intel (Very much sorry that I missed your previous questions in FL2＃.) @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? Huawei, HiSi: UE can just retune for transmitting UL purpose to another place while the DL which is associated with UL center frequency is automatically switched to that place as well, without need of reception of DL messages e.g. SSB, CORESETs. This is especially fine during initial access since the UL and DL messages are TDMed. FL7 Based on the received feedback, the following updated proposal can be considered. Note that, if necessary, different proposals can be agreed together or in a particular order. High Priority Proposal 2.2-4f: * If a separate initial DL BWP for RedCap UEs (as per current working assumption) is configured, o It may or may not contain the entire MIB-configured CORESET #0. o It can be used at least for RACH random access during the initial access. * It includes at least CORESET containing a type-1 PDCCH CSS for RedCap for RACH random access during initial access. o From RAN1 perspective, it can be configured to include CORESET and CSS for paging. FL8 Based on received responses, we can come back to this after other proposals have seen progress. 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 Xiaomi Y We prefer option 1 No matter this separate DL BWP is used for connected mode or idle/inactive mode, SSB should be included NEC If RedCap UE can retune to SSB (assuming CD-SSB) outside the separate initial DL BWP, we wonder why a separate initial DL BWP is needed/used for center frequency alignment between initial UL/DL BWP during initial access. Such a RedCap UE will be able to retune to MIB-configured initial DL BWP for DL reception during initial access. The specification does not seem to prohibit retuning between MIB-configured initial DL BWP and initial UL BWP. Panasonic Y vivo Agree with Nordic that Option 1 should be the baseline, and option 2 should be FFS. Apple Opt.1. ZTE, Sanechips Y According to the current NR spec, the additional SSB can be configured. Therefore, for us, option 2 is enough. For option 1, new introduced SSB transmission brings the overhead issue, which is not preferred. OPPO Y For a idle UE, how to provide other RS. For simplicity, we support option 1. FL4 Based on the received responses, the following updated proposal can be considered. High Priority Proposal 2.2-6c: * For the case when a separate initial DL BWP for RedCap is configured, o During initial access, * FFS: whether SSB is always transmitted in the separate initial DL BWP o After initial access, * SSB is always transmitted in the separate initial DL BWP. * FFS: suitable periodicity for additional SSB (if configured) considering impacts in terms of signaling overhead and performance vivo Thanks FL for the updated proposal. We would suggest to address all the SSB related controversial issues in a package proposal. The suggested update could be like the following. * For the case when a separate initial DL BWP for RedCap is configured, o During initial access, * FFS: whether SSB is always transmitted in the separate initial DL BWP o After initial access, * SSB is always transmitted in the separate initial DL BWP. * FFS: suitable periodicity for additional SSB (if configured) considering impacts in terms of signaling overhead and performance * After initial access, BW of UE-specific RRC configured BWP includes BW of SSB. o FFS: BW of UE-specific RRC configured BWP includes MIB-configured CORESET#0 Huawei, HiSilicon Prefer 2.2-6b We support to address the relevant issues together as vivo suggested, hence the current proposal does not fit. Within options in 2.2-6b, option 2 is preferred by us but at least both operations are on the table, so we don＊t see big issue. The current proposal makes no sense in 1) nothing is listed as an option for the case of during initial access, and 2) for the case of after initial access, the proposal is also inaccurate since even in current network for a UE supporting FG6-1a, no SSB is forced on its BWP. For the discussion regarding original 2.2-6b, we need to understand: Does a RedCap UE mandatorily support RF retuning? 1. The baseline strictly speaking, should be RedCap and non-RedCap UEs only to share the same SSB during initial access. Nothing needs to be changed 2. A small step further, to use a separate initial DL BWP at a different location, the UE firstly MUST support RF retuning (whatever by BWP switching/retuning) 3. with the UE already being able to support RF retuning, what＊s the problem for UE to support a BWP without SSB, and rely on retuning to original SSB. 4. Much more spec efforts and implement change on how to know whether/where is the additional SSB/ or even Other-CSS is needed. However point 3 does not need. 5. Even though we could further look into the configurability of additional CORESET/CSS, they are obviously optimization and is not preferred to be prioritized (even not over-optimized:) Lastly, we want to also emphasize that SSB is not only about overhead, much more cumbersome for network planning and may also cause severe inter-cell interference - many other UEs would be impacted and a RedCap UE won＊t really benefit from that. Qualcomm Thanks FL for the update. We don＊t quite understand the motivation of this proposal. If this separately configured initial DL BWP is used by RedCap UE during and after initial access, how come ※SSB is always transmitted in the separate initial DL BWP after initial access§ whereas ※SSB transmission during initial access§ needs FFS. As long as SSB is broadcast in the initial DL BWP, it is visible to RedCap UEs in all RRC states. To begin with, we can address the additional SSB transmission for FR1, since it was agreed to support FG 6-1 as a mandatory R17 RedCap UE feature in FR1. Samsung N We cannot agree on SSB is always transmitted in the separate initial DL BWP after initial access first. CATT N This version is a little confusing to us. Generally, the UE may probably prefer to measure SSB during the initial access. But after the initial access, if the UE reports supporting FG 6-1a (assuming this is optional), it may not require SSB to be included. But this update seems proposing an opposite assumption. Spreadtrum The additional SSB should be compromised by both UE vendor and NW vendor. It can be FFS. * For the case when a separate initial DL BWP for RedCap is configured, o During initial access, * FFS: whether SSB is always transmitted in the separate initial DL BWP o After initial access, * FFS: whether SSB is always transmitted in the separate initial DL BWP CMCC N During and after initial access, we prefer SSB in the separate initial DL BWP is configurable by gNB. IDCC N We agree that this is a little bit confusing. Why different behavior during and after initial access? ZTE, Sanechips N After initial access, it is not hoped that the separate initial DL BWP configuration should be always limited by SSB location, and additional SSB overhead always exist. Moreover, the resource occupation by additional SSB would further reduce the DL peak data rate and affect the resource scheduling especially for the HD-FDD RedCap UE. MediaTek We prefer mandating that SSB is broadcasted in the separate initial BWP, and we agree that the periodicity needs to be discussed with respect to Connected-mode operation only. Nordic N SSB is always transmitted in initial DL BWP. gNB cannot know UE capabilities during initial access. Nokia, NSB N We do not see the motivation to always transmit SSB in the separate initial DL BWP after initial access. FUTUREWEI4 This proposal is less clear than the previous version DOCOMO Maybe we can try previous version for now and further discuss for down-selection both for during/after initial access cases NEC FFS Looking at the discussions, we are not confident if a separate initial DL BWP is needed during initial access Ericsson N FR2 For legacy UEs, the MIB-configured initial DL BWP (CORESET#0) may not include SSB in FR2 (multiplexing patterns 2 and 3). For RedCap, we have the following conclusion from RAN1#104-e: Conclusion: 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 above conclusion implies that the RedCap UEs may need to do RF retuning to receive SSB outside of its (MIB-configured) initial DL BWP. Why should this be different when a separate initial DL BWP is configured? Therefore, we see no strong reason to support Proposal 2.2-6c for FR2, in either during initial access or after initial access. In FR2, the UE will need to rely on RF retuning to monitor SSB outside the separate initial DL BWP. FR1 * During initial access: OK with the FFS. In this case, in our view, the UE can rely on RF retuning to monitor SSB outside the separate initial DL BWP. We are also fine with leaving the decision to RAN4, e.g.: o Whether or not SSB is always transmitted in the separate initial DL BWP during initial access is up to RAN4. * After initial access: In RRC_CONNECTED, the UE will be in the RRC-configured non-initial DL BWP (assuming BWP #0 configuration option 1). We do not see a reason why the SSB should be transmitted in the initial DL BWP in this case. Intel Considering the discussion so far, at this point, it may be best to just have all cases as FFS as well as include the case of UE-specifically configured DL BWP in connected mode. OPPO Basically we are fine with the direction since it was agreed that support FG 6-1 as a mandatory R17 RedCap UE feature in FR1. But we also agree with vivo that all the cases shall be addressed together. Lenovo, Motorola Mobility We prefer more on 2.2-6b, with the clarification of SSB is NOT CD-SSB. FL5 Based on the received responses, the following question can be considered. High Priority Question 2.2-6d: * Companies are invited to suggest potential compromise proposals that can achieve an attractive trade-off between signaling overhead and performance when it comes to transmission of additional SSB in DL BWPs for RedCap UEs. o Consider the following options: * Option 1: SSB is always transmitted in the DL BWP. * Option 2: SSB is not always transmitted in the DL BWP. o Consider the following cases: * Separate initial & non-initial DL BWPs * Idle/inactive & connected mode * FR1 & FR2 Huawei, HiSilicon Y Thanks for the moderator efforts. We think this is higher priority than 2.2-4d. At minimum we think for a separate initial DL BWP at least during initial access, Option 2. Nordic N Baseline is that SSB is in every BWP, as part of mandatory FG6-1, if it would be simple to support SSB-less BWP in R15 it would not be an optional feature. The impact to UE implementation and complexity from 6-1a is too big to justify overhead optimizations. Moreover, as we shown (in Figure 1 of R1-2107040), gNB may server both RedCap and non-RedCap UE efficiently in TDD under cell-defining SSB, efficiently. Same applies to FFD. If UE supports 6-1a, then gNB may configure dedicated SSB-less BWP to the UE after MSG4. All works, nothing is broken. vivo We can consider the following proposal as compromise (for FR1) For IDLE/INACTIVE mode ? If separate initial DL BWP is configured for RedCap UEs, the SSB transmission in the separate initial DL BWP can be configurable by the NW * 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 For CONNECTED mode ? Mandatory feature for Redcap UEs: Each RRC-configured DL BWP includes SSB transmission * FFS: each RRC-configured DL BWP includes MIB-configured CORESET#0 ? Optional features for Redcap UEs: Each RRC-configured DL BWP may not include SSB transmission or MIB-configured CORESET#0 \ Panasonic Y CATT Thanks for the question. We think version 2.2-6b is a good starting point. Our suggestion will be: High Priority Proposal 2.2-6b-update: * For the case when a separate initial DL BWP for RedCap is configured, for FR1, o FFS whether SSB is always transmitted in the separate initial DL BWP, if the separate initial DL BWP can be used during initial access (i.e. for RRC_IDLE/RRC_INACTIVE UE) o FFS whether SSB is always transmitted in the separate initial DL BWP, if the separate initial DL BWP is NOT used during initial access (i.e. for RRC_CONNECTED UE) * FFS whether the same principle on SSB transmission is applied to UE-dedicated DL BWP * FFS whether the handling in FR2 is the same with FR1 Understand that there are still many FFS existing and perhaps not good enough. But since the situation is complicated as it is, this proposal deserves them. DOCOMO We support the proposals from vivo or CATT as the starting point for further discussion. Intel We can accept the version from CATT or, for more progress, the version from vivo, BUT with an FFS for the case of separate initial DL BWP for RedCap UEs in connected mode (seems missed in vivo＊s version). For references to separate initial DL BWP in idle/inactive, we also need to add a ※if supported§ phrase. FUTUREWEI5 This is a good starting point. Based on some of the comments in the FL summary, it seems there are several scenarios to consider for initial access (there are more) * For FDD, location of the initial UL BWP for RedCap UE when the initial UL BWP for nonRedCap UE > max BW RedCap UE * For FDD, location of the initial DL BWP for RedCap UE when the initial DL BWP for nonRedCap UE > max BW RedCap UE * For TDD, when RedCap UE initial DL BWP is CORESET#0, CORESET#0 is located near the edge of the channel and when the center frequencies of initial DL and UL BWPs are the same, there is chance the size of initial UL BWP cannot be as large as the max BW of RedCap UE * For TDD, if the initial DL BWP for RedCap UE is CORESET#0 and is near the center of initial DL BWP of a nonRedCap UE, when the center frequencies of initial DL and UL BWPs are the same, the location of the initial UL BWP is not at the edge of initial UL BWP for non-RedCap UE * For TDD, where to place initial UL and DL BWPs for RedCap UE when both initial UL and DL BWPs for non-RedCap UE > max BW RedCap UE Based on some of these scenarios for TDD during initial access, it may be preferrable to avoid transmitting the additional SSB. vivo＊s text for initial access is a reasonable start CMCC We prefer Option 2, SSB transmission in the separate initial DL BWP can be configurable by the NW. If additional SSB is configured, it can be shared in idle/inactive mode and connected mode. If CSS for paging and SI is supported in the separate initial DL BWP, additional SSB can be used for synchronization. If CSS for paging and SI is not supported in the separate initial DL BWP, it is unnecessary to configure additional SSB for RedCap UEs in idle/inactive mode. TCL support the proposal from CATT NEC We support CATT＊s version for further discussion Samsung Based on current discussion, we believe the direction of the discussion is not along a correct track, in the sense that we should not focus on network behavior of mandating transmission of SSB, but should focus on the UE behavior, and the motivation for extra SSB. For example, if the network didn＊t configure SSB based RRM for the UE, why the network always need to transmit an extra set of SSB. To be more precise, we suggest the following proposal from the UE perspective: Proposal: * For the case when a separate initial DL BWP for RedCap is configured, o If a RedCap UE is configured with a SSB for RRM measurement, the UE assumes the BW of the SSB is confined within the BW of the initial DL BWP for RedCap We would like to clarify the intention of this proposal: * From UE perspective, when the UE is operating within the initial DL BWP for RedCap, SSB based RRM can be performed within the BWP, so there is no issue with UE＊s complexity * From NW perspective, we target to allow flexibility on the need to transmit extra SSB. o NW can implement in a way that the initial DL BWP for RedCap already includes the cell-defining SSB, and no extra SSB is needed to be transmitted; o NW can implement in a way that the initial DL BWP for RedCap doesn＊t include the cell-defining SSB, and configures the UE to perform CSI-RS based RRM (i.e., no extra SSB is needed to be transmitted). o NW can implement in a way that the initial DL BWP for RedCap doesn＊t include the cell-defining SSB, and transmits another set of SSB for RRM measurement within the BWP. Whether this assumption is applicable to IDLE/CONNECTED mode, FR1/FR2, can be further discussed, but we would like to check whether this direction of discussion is acceptable by vendors from both sides. Xiaomi Generally, we are OK with FL＊s proposal It seems vivo is trying to describe the proposal from UE perspective and CATT is trying to describe the proposal from NW perspective. For these two proposal, we have the following consideration: * For vivo＊s proposal, similar comment with Intel the case of separate initial DL BWP used for RedCap in connected mode should be included. * In CATT＊s proposal, I am not sure whether the case in the second subbullet will happen. When one initial DL BWP is NOT used for the initial access, it seems this is the case that RedCap and non-RedCap share the same initial DL BWP during initial access and then a separate initial DL BWP is configured for the RedCap for the usage after initial access. But we think in this situation, this separately configured initial DL BWP should cover the initial DL BWP used during initial access, which is the same for non-RedCap. LG We can accept the proposal from CATT as a starting point for further discussion. Ericsson Following is our proposal: * FR1 o Separate initial DL BWP: * Idle/inactive mode[Note 1]: Option 2 * Connected mode[Note 1]: Option 2 o Non-initial DL BWP: * Idle/inactive: NA * Connected mode[Note 2]: Option 2, or Option 1 as a compromise provided that the non-initial DL BWP may or may not contain the entire MIB-configured CORESET#0 (and SIB) and with the following FFS: * FFS: suitable SSB periodicity considering impacts in terms of signaling overhead and performance * FR2 o Separate initial DL BWP: * Idle/inactive mode[Note 3]: Option 2 * Connected mode[Note 3]: Option 2 o Non-initial DL BWP: * Idle/inactive: NA * Connected mode[Note 4]: FFS Note 1 During idle/inactive mode, the separate initial DL BWP (paging is FFS) is used for only for RACH. In Connected mode, the RedCap UEs will operate in the RRC-configured BWP. The separate initial DL BWP in connected mode will only be used, for e.g., RACH in scenarios where ROs are not configured in the active non-initial UL BWP (in this case UE may switch to the initial UL/DL BWP). Therefore, we see no reason to mandate SSB transmission in the separate initial DL BWP, either during idle/inactive mode or during connected mode. It should be noted that the RedCap and non-RedCap UEs should share the same SSB and CORESET#0, at least until the configuration of separate initial DL BWP for RedCap UEs in SIB1. Note 2 In order to minimize PUSCH resource fragmentation, the non-initial UL BWP for RedCap will need to be placed at the carrier edge. Now, in order to align the center frequency, the non-initial DL BWP will also needs be placed near the carrier edge. Therefore, for RedCap UEs with 20 MHz BW, it may not be feasible to cover the entire CORESET#0 and SSB. Hence, FG 6-1a should be supported for efficient support of RedCap UEs in the network. However, as a compromise we are fine with Option 1 provided that the non-initial DL BWP may or may not contain the entire MIB-configured CORESET#0 (and SIB). Note that RF retuning to monitor CORESET#0 to acquire SI (e.g., SIB1) is not expected to be frequent. Note 3 In FR2, even for legacy UEs, the initial DL BWP does not necessarily contain SSB, for example, for SSB/CORESET#0 multiplexing pattern 2 and 3 in which SSB and CORESET#0 are FDMed. For RedCap, we have the following conclusion from RAN1#104-e: Conclusion: 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 above conclusion implies that the RedCap UEs may need to do RF retuning to receive SSB outside of its (MIB-configured) initial DL BWP. This behavior will be the same even when a separate initial DL BWP is configured in FR2. Note 4 RedCap UEs may not be able to simultaneously receive SSB and CORESET#0 for all configurations of SSB/CORESET#0 (for multiplexing pattern 2), as their total BW can exceed the RedCap UE BW in FR2. Therefore, a RedCap UE will not be able to use all SSB/CORESET#0 configuration, if FG 6-1a is not supported. ZTE, Sanechips Y with adding notes We are OK with the FL＊s suggestion at present stage. What we need to clarify is this additional SSB should not be the newly additional SSB for RedCap, since the additional SSB is already supported for non-RedCap UE and we will discuss it when come to UE features. It is suggested to add a note to differentiate these two different additional SSB. Additionally, for the CATT＊s version, seems no progress are achieved since all the bullets are FFS. To address the concerns for different companies, the following note can be added to make some progress High Priority Question 2.2-6d: * Companies are invited to suggest potential compromise proposals that can achieve an attractive trade-off between signaling overhead and performance when it comes to transmission of additional SSB in DL BWPs for RedCap UEs. o Consider the following options: * Option 1: SSB is always transmitted in the DL BWP. * Option 2: SSB is not always transmitted in the DL BWP. o Consider the following cases: * Separate initial & non-initial DL BWPs * Idle/inactive & connected mode * FR1 & FR2 Note 1: additional SSB include the R15/R16 additional SSB. Note 2: For each case, the option selection can be different or same. FL6 Based on the received responses, the following proposal can be considered. Note that, if necessary, different proposals can be agreed together or in a particular order. High Priority Proposal 2.2-6e: * For separate initial DL BWP for RedCap in FR1, o If CSS for Paging is supported and configured in the separate initial DL BWP, then SSB is always transmitted in the separate initial DL BWP. * FFS: suitable SSB periodicity considering impacts in terms of signaling overhead and performance o If only CSS for RACH is configured in the separate initial DL BWP, then SSB transmission in the separate initial DL BWP is configurable by the network. o FFS: FR2 case * For non-initial DL BWP for a RedCap UE in FR1, o SSB is always transmitted. * FFS: suitable SSB periodicity considering impacts in terms of signaling overhead and performance o The BWP may or may not contain the entire MIB-configured CORESET#0. o FFS: FR2 case Huawei, HiSilicon FFS We don＊t see any real UE complexity for performing RF retuning. We can understand the concern of UE power consumption, however consider it is up to gNB implementation/control, as other UE power saving features. We can also consider possible restriction of UE measurement for returning to the original SSB, if that is concerned by UE vendors. Spreadtrum Y We definitely welcome the additional SSB in the separate initial DL BWP or non-initial DL BWP. However, we fail to understand the restriction for the non-initial DL BWP (UE specific already), since in our view everything is legacy including capability reporting and gNB configuration. Maybe we miss something＃Anyway, we suggest the following revision. High Priority Proposal 2.2-6e: * For separate initial DL BWP for RedCap in FR1, o If CSS for Paging is supported and configured in the separate initial DL BWP, then SSB is always transmitted in the separate initial DL BWP. * FFS: suitable SSB periodicity considering impacts in terms of signaling overhead and performance o If only CSS for RACH is configured in the separate initial DL BWP, then SSB transmission in the separate initial DL BWP is configurable by the network. o FFS: FR2 case * For non-initial DL BWP for a RedCap UE in FR1, o SSB is always transmitted. * FFS: suitable SSB periodicity considering impacts in terms of signaling overhead and performance o The BWP may or may not contain the entire MIB-configured CORESET#0. o FFS: FR2 case vivo We think the latest FL6 proposals is a good direction for compromise. Question for confirm the understanding: The 1st bullet talks about initial-DL BWP for both IDLE and CONNECTED modes, the 2nd bullet talks about the RRC configured BWP in CONNECTED mode, correct? Nordic Regarding FR1, 1) RRC connected: initial DL BWP becomes dedicated in BWP configuration Option 2 and thus must contain SSB in any case (as part of current mandatory 6-1). Similarly, dedicated BWP contains SSB as part of 6-1. UE needs SSB, if periodicity of DRX is large and also for measuring serving cell for HO. Network not supporting HO would be bad system. Finally, SSB is QCL source of TYPE-C/D for TRS, not sure how it would be replaced. 2) IDLE/camping, UE needs to have SSB for cell reselection purpose 3) During initial access, UE could manage without SSB, but SSB is QCL source for PDCCH monitoring as well as PDSCH until MSG4. Performance may be impacted. 4) Finally, gNB can deploy RedCap and non-RedCap UE, by both sharing CORESET#0 by MIB. gNB may configure dedicated BWP without SSB if UE supports. We do not see any issue here. IDCC Y Nokia, NSB For the first sub-bullet, we are fine with the proposal for RACH but not sure whether there is major benefit to transmit for SSB for paging. We don＊t see issues with UE performing RF retuning during initial access. For the second sub-bullet, our preference is not to required SSB. FUTUREWEI6 Some clarity about separate initial DL BWP and initial DL BWP may be required based on your reply to FL5. In Note 1 ※During idle/inactive mode, the separate initial DL BWP (paging is FFS) is used for only for RACH. In Connected mode, the RedCap UEs will operate in the RRC-configured BWP. The separate initial DL BWP in connected mode will only be used, for e.g., RACH in scenarios where ROs are not configured in the active non-initial UL BWP (in this case UE may switch to the initial UL/DL BWP).§ In the proposal, it is unclear whether the separate initial DL BWP is used only for RACH. Qualcomm If the separate initial DL BWP can be used by RedCap UE during initial access, we think the SSB transmission is mandatory instead of configurable. Based on our calculation, the overhead of non-CD SSB transmission is low in the separate initial DL BWP. Assuming 100 MHz channel BW, DDDSU frame format in TDD, and 8 SSB beams/20 ms periodicity for non-CD SSB, the overhead is less than 1% of the DL resources. If the separate initial DL BWP cannot be used by RedCap UE during initial access, the DL BWP without SSB is related to the discussion of FG 6-1a, which is optionally supported by RedCap UE and can be treated in UE feature discussion. Ericsson Y, but We can accept this FL-6 proposal as a compromise. However, we have similar comment as Vivo. Whether the first bullet corresponds to RRC_IDLE or RRC_CONNECTED (or both) needs clarification. Apple We shared Qualcomm＊s comment on this. The key is that for any BWP that is potentially used in RRC_CONNECTED mode, the DL/UL RF retuning should be minimized as much as possible, regardless of initial BWP or UE-specific BWP. With this in mind: * Initial DL BWP: it can be used after RRC Connection completion i.e., RRC_CONNECTED mode. Therefore, even If ＆only CSS for RACH is configured in the separate initial DL BWP＊, SSB should be configured in initial BWP if initial BWP is used during RRC CONNECTED mode. o We also fail to understand why ＆Type1 CSS and Type-2 CSS＊ are selected as metric to determine whether SSB is mandated or not, instead of RRC states. * For UE-specific BWP: o The SSB should be mandated, and we support this bullet. DOCOMO We can live with the proposal for the sake of progress Lenovo, Motorola Mobility Y We are generally fine with this proposal. Intel N While we can see the possible logic behind this new characterization, it still tends to not acknowledge on whether the first part applies to only after initial access (as per current WA) or also during initial access. In this regard, the first part (for separate initial DL BWP) would need to be qualified further into the sub-cases, with proper conditioning on ※if the separate initial DL BWP can be used during initial access (i.e. for RRC_IDLE/RRC_INACTIVE UE)§. OPPO Y Support this proposal. CATT We have similar confusion with Apple why ＆Type1 CSS and Type-2 CSS＊ are selected as metric to determine whether SSB is mandated or not, instead of RRC states. In RRC_IDLE/INACTIVE mode, if a RedCap UE can finish RACH procedure without SSB in the separate initial DL BWP (e.g. by RF retuning), why can＊t it finish paging procedure without SSB in the separate initial DL BWP (e.g. by RF retuning again). We also prefer that SSB is NOT mandated in the separate initial DL BWP (i.e. for use in RRC_IDLE/INACTIVE). Samsung N We don＊t see the need to transmit SSB on separate iDL BWP when paging is transmitted. Paging is transmit a PDSCH to receive and there is no issue to receive it without SSB for sync. NB-IoT also support paging on non-anchor carrier without sync channel. There is no technical issue to support paging on separate BWP without SSB as well. vivo2 Additional comments 1) We think point made by Nordic/Apple and others about the initial DL BWP assumption (i.e. includes SSB or not) in CONNECTED mode is valid, which should be explicitly discussed. 2) @Samsung, UE need to process SSB (for AGC, sync, etc) in order to guarantee the paging decoding performance. Please refer to the agreed assumption made in PEI session of Rel-17 UE power saving, where it is assumed that at least 1 SSB is required before PO reception for good channel condition case, and up to 3 SSBs might be required before PO reception in some bad channel condition case. With this assumption in mind, if UE monitors Paging in the separate initial DL BWP, it will be very power consuming if the separate initial DL BWP does not contain SSBs and UE has to retune back to the MIB-configured initial BWP to process multiple SSBs and then switch back to the separate initial DL BWP for paging monitoring. However, some RF retuning during RACH procedure might be acceptable as RACH is a rare event compared to periodic paging monitoring. ZTE, Sanechips N We understand the RF retuning may have the impact on UE power. However, in connected mode for the RedCap UE, considering the RF retuning power consumption percentage in total power consumption is not large, the RF retuning may not have much impact on the UE. From our perspective, gNB should have the flexibility to determine whether SSB is transmitted in the non-initial DL BWP based on the UE capability report. Therefore, we do not agree the SSB should be always transmitted in the non-initial DL BWP and separate initial DL BWP. Panasonic Y in principle As commented above, we suggest "for RACH" should be changed to "for random access procedure" as random access channel (Msg1) itself is not sent in DL. NEC Regarding the first main bullet, it seems a RedCap UE may retune and use CD-SSB outside of a separate DL initial BWP for RedCap UE during initial access. And whether the separate initial DL BWP supports paging should be left for RAN2, in our opinion. Regarding the second main bullet, our preference would be to reuse existing specifications based on UE capabilities. Xiaomi We are confused about why the SSB configuration should depends on the configuration of CSS for paging or RACH. CMCC We think for non-initial DL BWP for a RedCap UE in FR1, SSB is configurable by network. LG We think the RF retuning should be minimized. So, we prefer the SSB to be always transmitted within the separate initial DL BWP. Huawei, HiSilicon Additional comments 1. Although the current proposal is for FR1, the potential issue for FR2 (TDD) would be worse as multiple Beams require more SSBs. Further, if a separate BWP is configured for offloading purpose, it is expected to have DL configurations including CORESET ect, otherwise there is no point to use only SSB for an empty BWP. The overhead should be calculated in a way that UE really work there, and with more loading occurs, multiple separate BWPs & SSBs would be subsequently required. 2. Want to note that 6-1a is optional for eMBB is because the eMBB UEs have higher cost due to 100MHz BW, thus does not necessarily to rely on additional SSB and can optinally retune (or not, since mostly the UE BW covers the carrier BW as well). Just due to now RedCap BW is limited, in return of the reduced cost from 100MHz to 20MHz, more RF retuning is necessary (similar to eMTC) - it does not impose additional complexity/cost. 3. If additional SSB is cell defined, it would also have impact on legacy UE for cell selection and suffer ICI; if the additional SSB is non-cell defined, it does not seem to be useful for RRM anyway. 4. In legacy, the non-cell defined additional SSB is not mandated either. 5. The frequency of UE retuning can be up to gNB control. We are open to consider means to reduce that, however, mandating SSBs would have impact on system performance (including both RedCap and non-RedCap UEs), which does not seem to be a good middle ground. The offloading need for paging is unclear. Our observation is that even in NB-IoT with much larger amount of connections, the maximum required paging resources is only a few ~MHz. A RedCap UE can still just legacy SSB. FL7 Based on the received responses, the following updated proposal can be considered. Note that, if necessary, different proposals can be agreed together or in a particular order. High Priority Proposal 2.2-6f: * For idle/inactive/connected mode in separate initial DL BWP for RedCap in FR1, o If CSS for Paging is supported and configured in the separate initial DL BWP, then SSB is always transmitted in the separate initial DL BWP. * FFS: suitable SSB periodicity considering impacts in terms of signaling overhead and performance o If only CSS for RACH random access is configured in the separate initial DL BWP, then SSB transmission in the separate initial DL BWP is configurable by the network. o FFS: FR2 case * For connected mode in non-initial DL BWP for a RedCap UE in FR1, o SSB is always transmitted if required by the UE capabilities. * FFS: suitable SSB periodicity considering impacts in terms of signaling overhead and performance o The BWP may or may not contain the entire MIB-configured CORESET#0. o FFS: FR2 case FL8 Based on received responses, we can come back to this after other proposals have seen progress. FL8 High Priority Question 2.2-6g: Regarding random access in idle/inactive mode in separate initial DL BWP for RedCap UEs in FR1: 1. Should configuration of random access be supported in idle/inactive mode in this BWP? 2. To be able to carry out random access, should the UE be able to expect SSB in idle/inactive mode in this BWP? 3. Other comments? Company Comments Example 1. Reply to question 1 2. Reply to question 2 3. Reply to question 3 Qualcomm 1) Yes. CORESET/CSS for RACH should be supported in the separate initial DL BWP for RedCap UEs in FR1, due to the requirements of RACH 2) Yes. To support RACH in the initial DL BWP, RedCap UEs in idle/inactive states need to measure SSB at least for RO selection, power control (for msg1/msg3/PUCCH), time/frequency tracking and RRM. Compared to non-RedCap UE, RedCap UE is expected to stay in idle/inactive states for longer time. The presence of SSB is critical for power saving of RedCap UE in idle/inactive state. 3) If the separate initial DL BWP is configured in SIB, it can be used by all RedCap UEs in all RRC states (idle/inactive/connected). Therefore, the presence of SSB in the separate initial DL BWP can be leveraged by all RedCap UEs in all RRC states. As a way forward, we support the following proposal for the separate initial DL BWP of RedCap UEs in FR1: Proposal: * If a separate initial DL BWP is configured in SIB, which can be used by RedCap UEs in all RRC states (idle/inactive/connected), the following configurations are expected for the SIB-configured initial DL BWP of RedCap UEs in idle/inactive states: o the initial DL BWP includes SSB o the initial DL BWP includes CORESET/CSS for RACH and paging o the initial DL BWP is aligned with the initial UL BWP of RedCap UE at center frequency in TDD Nordic 1) Yes, RACH SS should be always present in initial DL BWP on Pcell, as in legacy. Otherwise, UE does not receive RAR in this BWP, as per RAN2 spec 2) During initial access may not be needed vivo 1) Yes. And if not configured, UE does not monitor RAR in that DL BWP. 2) Having SSB included in the BWP will be beneficial for IDLE mode UE power consumption. But the related question is, do we expect that NW will configure a separate initial DL BWP for IDLE mode UEs and RACH purpose ONLY (i.e. no CONNECTED mode UEs use this DL BWP and no paging monitoring in this DL BWP)? Do we see such case as typical configuration or some kind of corner case? Some clarification from operator/NW vendor would be required. For the case where a separate DL BWP is used for both IDLE mode (RACH and Paging monitoring) and CONNECTED mode UEs, then it will be critical to have the SSB transmitted in the DL BWP. FUTUREWEI8 1) Yes. The separate initial DL BWP should support the CORESET for type 1 PDCCH CSS (RA-RNTI, MsgB-RNTI, TC-RNTI) 2) May not be necessary for initial access. If this separate initial DL BWP is configured by the SIB, then there is MIB-based CORESET#0 available, which has the SSB (for FR1). CATT (1) Depends on the trade-off. If the cost to support random access is too high, i.e. SSB must be contained, SIB1 will be additionally transmitted＃ then we prefer not to support random access in the separate initial DL BWP. And hence no configuration of random access is needed. On the contrary, if the cost is low (i.e. at least SSB and SIB1 is not always required), supporting random access in the separate initial DL BWP may be more acceptable to us. (2) No. RedCap UE can rely on RF retuning to receive SSB outside the separate initial DL BWP. It can perform SSB RSRP measurement, RO selection, sampling calibration before performing random access. This is workable since the beam of SSB and SSB-to-RO mapping is unlikely to change frequently, i.e. almost statically configured. (3) A most straightforward way is to support FG 6-1a, which will not require SSB within any DL BWP. This is considerable; otherwise RedCap seems cannot work properly in some configuration of pattern 2 of CORESET#0&Type0-CSS in FR2 scenario (see Question 4-1). Panasonic 1. Yes, configuration of CORESET/CSS for random access should be supported in idle/inactive mode in this BWP. This can relax the load of CSS for non-RedCap UEs. 2. It is not required to have SSB in this BWP. UE can retune to the CD-SSB. As the network decision, non CD-SSB can be sent in this BWP. FL8 High Priority Question 2.2-6h: Regarding paging monitoring in idle/inactive mode in separate initial DL BWP for RedCap UEs in FR1: 1. Should configuration of paging monitoring be supported in idle/inactive mode in this BWP? 2. To be able to carry out paging monitoring, should the UE be able to expect SSB in idle/inactive mode in this BWP? 3. Other comments? Company Comments Example 1. Reply to question 1 2. Reply to question 2 3. Reply to question 3 Qualcomm 1) Yes, the presence of CORESET/CSS for paging is necessary in the separate initial DL BWP shared by all idle/inactive RedCap UEs. 2) Yes, RedCap UEs in idle/inactive states need to measure SSB at least for time/frequency tracking and RRM. Compared to non-RedCap UE, RedCap UE is expected to stay in idle/inactive states for longer time. Therefore, the presence of SSB is critical for power saving of RedCap UE in idle/inactive state. 3) If the separate initial DL BWP is configured in SIB, it can be used by all RedCap UEs in all RRC states (idle/inactive/connected). Therefore, the presence of SSB in the separate initial DL BWP can be leveraged by all RedCap UEs in all RRC states. As a way forward, we support the following proposal for the separate initial DL BWP of RedCap UEs in FR1: Proposal: * If a separate initial DL BWP is configured in SIB, which can be used by RedCap UEs in all RRC states (idle/inactive/connected), the following configurations are expected for the SIB-configured initial DL BWP of RedCap UE in idle/inactive states: o the initial DL BWP includes SSB o the initial DL BWP includes CORESET/CSS for RACH and paging o the initial DL BWP is aligned with the initial UL BWP of RedCap UE at center frequency in TDD Nordic 1) Yes, paging SS should be provided on separate initial DL BWP on Pcell, by pdcch-ConfigCommon otherwise UE does not receive paging in this BWP. 2) In Idle, UE requires to read SSBs before every PO. Having cell-defining SSB and separate initial DL BWP at different frequencies, would lead to unnecessary retuning between two DL frequencies. In addition, UE＊s ability to receive paging would be degraded. vivo 1) Yes. And if not configured, UE does not monitor paging in that BWP. 2) SSB is essential for UE to decode Paging with reasonable performance. As discussed in the PEI design of UE power saving WI, the assumption is that UE needs to process at least one SSB prior to each paging occasion in the high SINR case, and in some low SINR case, up to three SSB may be required depending on UE implementation. Therefore SSB should be provided in the separate initial DL BWP configured with paging monitoring. FUTUREWEI8 1) It depends on whether the MIB-based CORESET#0 is configured to support a Type2-PDCCH CSS. If the MIB-based CORESET#0 is not configured to support a Type2-PDCCH CSS, then the UE should expect to support paging monitoring in this separate initial DL BWP 2) It depends on whether the MIB-based CORESET#0 is configured to support a Type2-PDCCH CSS. If the MIB-based CORESET#0 is not configured to support a Type2-PDCCH CSS, then the UE should expect to receive SSB in this separate initial DL BWP for power savings reasons. CATT (1) If random access can be supported, then paging may also be supported. And if so, CORESET and CSS for paging should be predefined (i.e. reuse that for RACH, the same as current spec) & explicitly configured. (2) NO. Similar to the RACH case, RedCap UE can rely on RF retuning to receive SSB outside the separate initial DL BWP. It can wake up a little earlier, and perform SSB RSRP measurement, PO (Paging Occasion) selection, sampling calibration＃ before receiving paging information, if needed. This is workable since the beam of SSB and SSB-to-PO mapping is unlikely to change frequently, i.e. almost statically configured. (3) A most straightforward way is to support FG 6-1a, which will not require SSB within any DL BWP. This is considerable; otherwise RedCap seems cannot work properly in some configuration of pattern 2 of CORESET#0&Type0-CSS in FR2 scenario (see Question 4-1). Panasonic 1. From RAN1 perspective, it is good to have the configuration of paging monitoring supported in idle/inactive mode in this BWP. On the other hand, we are not so fully sure whether PO (paging occasion) and UE_ID (5G-S-TMSI) can be managed well in RAN2 for RedCap UE specific PO. The final decision should be within RAN2. 2. If CORESET/CSS for paging is supported in this BWP, UE should be able to assume SSB is available in this BWP. For every DRX periodicity, UE needs to have AGC, coarse time/frequency synchronization and serving cell measurements using SSB in addition to paging reception. In addition, power saving WI are discussing to transmit other signals (PEI, TRS availability). If frequency retunes are required for SSB, the timing design becomes further complicated and wake-up time increases. Therefore, UE should be able to assume SSB is available in this BWP. If RAN1 or RAN2 conclude not to support CORESET/CSS for paging in this BWP, no need to send SSB. FL8 High Priority Question 2.2-6i: Regarding CORESET#0 and SIB1 in idle/inactive mode in separate initial DL BWP for RedCap UEs in FR1: 1. Should this BWP always contain entire CORESET#0 and SIB1 in idle/inactive mode? 2. Other comments? Company Comments Example 1. Reply to question 1 2. Reply to question 2 Qualcomm FFS Nordic 1) Does not have to, it should contain pdcch-ConfigCommon vivo Should the CORESET#0 be MIB-configured CORESET#0 to be more accurate? Based on this understanding our answer to question 1 is: not necessary. FUTUREWEI8 Not necessary CATT (1) For CORESET#0 (derived from MIB), we hope not. Otherwise, the frequency location of the separate initial DL BWP is quite restricted, i.e. largely overlapped with the original initial DL BWP. In this case, we prefer a simpler handling: just do not configure separate initial DL BWP (anyway, the separate initial DL BWP is optional). For SIB1, no, either. Do not find functionality issue not transmitting SIB1 in the separate initial DL BWP. And, doubling SIB1 is even more serious than doubling SSB, from view of potential resource waste. Note that, currently, each SSB with different index is mapped to each PDCCH monitoring candidate defined by CORESET#0&Type0-CSS, and each PDCCH monitoring candidate is carrying a SI-RNTI scrambled DCI to schedule SIB1. Hence, each SSB has a corresponding SIB1. So, the SIB1 is already repeated N times (assuming N SSB) in the current network within a SSB cycle. The network cannot afford doubling SIB1 transmission anymore. Panasonic 1. FFS. Connected mode should be concluded first as it has more limitations on when to receive SIBs. If connected mode concludes to contain entire MIB-configured CORESET#0 and SIB1 in this BWP, idle/inactive mode UEs can also use it. FL8 High Priority Question 2.2-6j: Regarding connected mode in the active DL BWP for a RedCap UE in FR1: 1. Should this BWP always contain entire CORESET#0 and SIB1 in connected mode? 2. Should the UE be able to expect SSB and/or periodic TRS and/or measurement gaps (which ones?) in connected mode in this BWP? 3. Any comments regarding whether and how to support random access and/or paging in connected mode in this BWP? 4. Are the answers to the questions same or different for BWP#0 configuration options 1 and 2? 5. Other comments? Company Comments Example 1. Reply to question 1 2. Reply to question 2 3. Reply to question 3 4. Reply to question 4 5. Reply to question 5 Qualcomm Since the active DL BWP configured by dedicated RRC is UE specific, it could be based on FG 6-1 (mandatory) or FG 6-1a (optional), similar to non-RedCap UE. To simply the discussion for 2.2-6j, we think the generic active DL BWP of RedCap UE can be separated from the SIB-configured initial DL BWP applicable to all RRC states of RedCap UEs. For the SIB-configured initial DL BWP applicable to RedCap UEs in RRC connected mode and the RRC-configured active DL BWP of RedCap UE which includes the SIB-configured separate initial DL BWP: 1) CORESET0 and SIB1 may or may not be included 2) SSB and periodical TRS should be included 3) CORESET/CSS for paging and RACH should be included (since the initial DL BWP can be used in RRC idle/inactive states as well) 4) We think the SIB configured separate initial DL BWP can be used by RedCap UEs in all RRC states 5) Since it is challenging to mandate SSB transmission in every active DL BWP of RedCap UEs, we can accept the following proposal as a compromise to address the concerns for resource fragmentation, overhead of SSB, UE power saving and traffic offloading: Propoal: If a separate initial DL and/or UL BWP is configured in SIB, which can be used by RedCap UEs in all RRC states (idle/inactive/connected), the following configurations are expected for the SIB-configured initial BWP(s) of RedCap UE: a. the initial DL BWP may or may not contain the entire MIB-configured CORESET#0 b. the initial DL BWP includes SSB c. the initial DL BWP includes CORESET/CSS for RACH and paging d. the initial DL BWP is aligned with the initial UL BWP at center frequency in TDD e. the initial UL BWP includes ROs applicable to RedCap UE Nordic 1) CORESET#0 by MIB is not necessary, but having separate CORESET#0 and/or CommonCORESET + TYPE0/0A/TYPE1/TYPE2 SS sets configured by pdcch-ConfigCommon is must on Pcell as per RAN2 specification, otherwise UE does not receive paging/RAR/SIBs in this BWP. This is how NR works. 2) SSB and TRS shall be present in active BWP. Measurement gaps for serving cell measurements outside of active BWP were discussed in R15 and not agreed, no need to rediscuss topic again. 3) gNB configures pdcch-ConfigCommon in active BWP on a Pcell, simple as that, no spec change needed. 4) No difference, also BWP#0 becomes dedicated BWP after MSG4. No difference between BWP#1/BWP#0 in Option1/Option2 If gNB wants offloading it shall provide full pdcch-ConfigCommon in active BWP on a Pcell. Otherwise, there is always possibility to configure DL BWP to overlap with CORESET#0 by MIB and cell-defining SSB. vivo 1) MIB-configured CORESET#0 is not necessary to be included in the CONNECTED mode active DL BWP. And agree with Nordic on the understanding of ※CommonCORESET + TYPE0/0A/TYPE1/TYPE2 SS§ 2) SSB is mandatory. TRS is mandatory. 3) If CORESET/CSS for Paging or RACH is configured in the DL BWP, UE can perform paging monitoring or RACH procedure. Otherwise, paging monitoring or RACH is not supported in the BWP 4) Same answer for BWP#0 configuration Option 1 and 2 FUTUREWEI8 1) To receive SIB1, CORESET#0 must support Type0-PDCCH CSS. If FG6-1 is supported (applicable to the UE-specific RRC configured BW), the answer is yes. If FG6-1a is supported, CORESET#0 does not have to be in BW. 2) If the UE only supports FG6-1, then yes. If the UE supports FG6-1a, the SSB does not have to be present in the BW. Periodic TRS (FG 2-50 mandatory without capability signaling) is supported. No for measurement gaps (FG4-4 optional with capability signaling). 3) The search spaces for paging and random access should be supported. 4) In our understanding, with option#1, the initial DL BWP becomes BWP#0. If a separate initial DL BWP is used, this separate initial DL BWP should meet the requirements of the connected state. With option#2, BWP#0 can be different than the (separate) initial DL BWP. CATT (1) Assuming initial access and paging is supported in separate initial DL BWP (using other CSS/CORESET), CORESET#0 (derived from MIB) and SIB1 are not always transmitted. (2) No. If FG 6-1a is mandated for RedCap, no need to always transmit SSB. On the other hand, even if FG 6-1a is not mandated for RedCap, the gNB should be able to configure RedCap UE with a dedicated DL BWP containing SSB (e.g. the original SSBs) for work. (3) Assuming random access and paging can be supported in the separate initial DL BWP during initial access (i.e. RRC_IDLE), we do not see big difference for the RRC_CONNECTED case. (4) In current NR, regardless of BWP#0 configuration options 1 or 2, the frequency location and bandwidth is still determined by SIB1, and the restriction on frequency is also the same, e.g. must contain CORESET#0. The only difference is whether UE-dedicated configuration is additionally configured or not. For the RedCap case, if the requirement of ＆containing CORESET#0＊ can be relaxed for both BWP#0 configuration options 1 and 2, seems no any different answers will be expected. (5) Having said so much, we can see that FG 6-1a is important to support, or simply clarify that RF retuning for SSB measurement/reception outside the active DL BWP is supported. Otherwise, if we really want offloading/addressing congestion issue in a 100MHz BW in FR1, a total number of 5 sets of SSB are required to transmitted (1 set for every 20MHz). Panasonic 1. Current our view is not required to have entire MIB-configured CORESET#0 and SIB1 in this BWP. 2. At least one among SSB, periodic TRS and measurement gaps should be available in this BWP. 3. If separate CORESET/CSS for random access and/or paging for RedCap are supported/configured in this BWP, UE stays in this BWP. If not, UE retunes to CORESET/CSS for random access and/or paging commonly used for RedCap/non-RedCap UEs. 4. FFS 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. The following agreement was made in an online (GTW) session on Friday 20th August: Agreement: 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. 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 Xiaomi Y Since the center frequency alignment issue is discussed in Question 3.1-3, the last FFS point can be removed NEC Y Panasonic Y vivo Agree with Xiaomi to remove the last FFS point. ZTE, Sanechips Y OPPO Y FL4 Based on the received responses, the following updated proposal can be considered, where the last FFS has been deleted to eliminate an overlap with Proposal 3.1-3c. (If necessary, this proposal can be treated together with Proposal 3.1-3c or in a specific order.) High Priority Proposal 3.1-1a: Confirm the following modified version of the working assumption from RAN1#105-e: * Both during and after initial access, for the scenario where the initial UL BWP for non-RedCap UEs is configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap UEs. 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 vivo Y Huawei, HiSilicon Y For progress. Qualcomm Y For the sake of progress Samsung Y For the sake of progress CATT Y Further discuss center frequency issue in 3.1-3. Spreadtrum Y CMCC Y IDCC Y ZTE, Sanechip Y For the sake of progress. MediaTek Y Nordic Y Nokia, NSB Y We prefer to keep the FFS. But for the sake of progress we can accept the FL＊s proposal. FUTUREWEI4 Y For the sake of progress. To make this the second sub-bullet similar to 3.1-3c, add o At least after initial access, Support the case when the centre frequency is assumed to be the same for the initial DL and UL BWPs in TDD. DOCOMO Y NEC Y Ericsson Y Intel Y, but To avoid misunderstandings down the road, we＊d like to clarify the following: The deletion of the FFS sub-bullet does NOT mean that separate initial DL BWP always needs to be configured to align with UL BWP #0. The bullet above it implies that we support configuration of separate UL BWP #0 for RedCap UEs IF the initial DL BWP has center freq aligned with the resulting separate UL BWP #0. Hope this is the common understanding here. OPPO Y Lenovo, Motorola Mobility Y Same view with Intel. LG Y For the clarification question from Intel, we would like to point out that what the main bullet says doesn＊t have be conditioned on whether the center frequency aligned or not. FL5 Based on the received responses, the following updated proposal can be considered, where the one FFS was deleted to eliminate an overlap with Proposal 3.1-3c, and a new FFS was added in order to address the above comment from Intel. (If necessary, this proposal can be treated together with Proposal 3.1-3c or in a specific order.) High Priority Proposal 3.1-1b: Confirm the following modified version of the working assumption from RAN1#105-e: * Both during and after initial access, for the scenario where the initial UL BWP for non-RedCap UEs is configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap UEs. 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 BWP and the separate initial 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 * FFS whether this initial DL BWP needs to be a separate initial DL BWP for RedCap or can be an initial DL BWP shared with non-RedCap Huawei, HiSilicon Y Nordic N We do not understand the new FFS from feature lead In TDD, initial DL BWP and UL BWP of the same index form a pair which has to have same center frequency. UL and DL BWPs are switched at the same time. I hope nobody wants to revert this very basic principle of NR. Therefore, in context of NR, the sub-bullet does not need any clarification. vivo We also think the newly added sub-bullet is unclear. Panasonic Now we are not sure whether the sub-bullet ※Support the case when＃§ is a condition of the main bullet or just a case allowed under the main bullet. If it is a condition, we propose to clarify like: ※Separate initial UL BWP is configured/defined when＃§ CATT Y Also fine to delete the latest FFS DOCOMO Y Lenovo, Motorola Mobility Y Intel We would like to clarify the intention of the new FFS based on our previous comment. Our understanding when we made the WA was that we support the case of separate initial UL BWP at least when the separate initial UL BWP has aligned center freq with initial DL BWP (in this case, as defined by CORESET #0), and in this case the "center-freq alignment rule" is satisfied and no separate initial DL BWP is needed. Hence, we had the FFS to capture whether to support the case when they may be different - and in such a case, options to minimize RF retuning would include configuration of?separate initial DL BWP for use during initial access as one option. ? Otherwise, we would not even be discussing whether separate initial DL BWP should always be configured to ensure center freq alignment with separate initial UL BWP (during and after initial access), e.g., related to Proposal 3.1-3/a/b/c/d. With the above background, we suggest to revise the new FFS to avoid ambiguity as follows: o Support the case when the centre frequency is assumed to be the same for the initial DL BWP and the separate initial UL BWPs in TDD, at least when the initial DL BWP is defined by MIB-indicated CORESET#0. * FFS whether or not to additionally support the case when the centre frequency is different; if so, how to minimize centre frequency retuning * FFS whether or not to additionally support the case when the center frequency is different between the separate initial UL BWP and the initial DL BWP defined by CORESET #0, if so, how to minimize center frequency retuning FUTUREWEI5 Y The new FFS may not be necessary (see WA from RAN#105) ※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§ CMCC Y NEC In our opinion, the new FFS does not seem necessary. Following revision would be suggested. o Support at least the case when the centre frequency is assumed to be the same for the initial DL BWP and the separate initial UL BWPs with the same BWP ID in TDD. Samsung Y We can live without the newly added FFS as well Xiaomi Y LG For the newly added FFS, our understanding on the initial DL BWP is the initial DL BWP shared with non-RedCap one if a separate initial DL BWP is not configured for RedCap, and the separate initial DL BWP is it is configured. Unless there are other interpretations on the initial DL BWP for RedCap UEs, we prefer to remove the newly added FFS as it doesn＊t seem to help. Ericsson Regarding the last FFS, it may not be possible to have a shared initial DL BWP for RedCap and non-RedCap and keep the same center frequency for UL/DL BWPs in TDD. Thus, to have the same UL/DL center frequency, a separate initial DL BWP at the carrier edge needs to be configured as well, as illustrated below. * Shared initial DL BWP but different initial UL BWPs for RedCap and non-RedCap: * Separate initial DL BWPs and separate initial UL BWPs for RedCap and non-RedCap: In our view, at least the following case should be supported: o Support the case when the centre frequency is assumed to be the same for the separate initial DL BWP and the separate initial UL BWPs in TDD. The FFS in Intel＊s comments should also be captured in the revised proposal. ZTE, Sanechips Y If we have the consensus that the separate DL/UL initial BWP can be configured independently, we can remove the new FFS, otherwise, it is better to keep the new FFS to avoid the confusion. FL6 Based on the received responses, the following updated proposal can be considered. Note that, if necessary, different proposals can be agreed together or in a particular order. High Priority Proposal 3.1-1c: Confirm the following modified version of the working assumption from RAN1#105-e: * Both during and after initial access, for the scenario where the initial UL BWP for non-RedCap UEs is configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap UEs. o FFS: whether/how to avoid or minimize PUSCH resource fragmentation due to PUCCH transmission for the above case o If a separate initial DL BWP is configured, the centre frequency is assumed to be the same for the separate initial DL BWP and the separate initial UL BWP in TDD. o Support the case when If a separate initial DL BWP is not configured, the centre frequency is assumed to be the same for the initial DL BWP and the separate initial UL BWP in TDD. * FFS whether this initial DL BWP needs to be a separate initial DL BWP for RedCap or can be an initial DL BWP shared with non-RedCap * FFS whether or not to additionally support the case when the center frequency is different between the separate initial UL BWP and the initial DL BWP, and, if so, how to minimize center frequency retuning Huawei, HiSilicon Y Spreadtrum Yes for the main bullet Before we decide the additional SSB and/or FG 6-1a optionality, we cannot draw conclusion of the alignment of center frequency b/w the separate DL BWP and the separate initial UL BWP, since it may imply that FG 6-1a is mandatory for UE. For understanding each other＊s view clearly, we list our 3 priorities 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. vivo Still, we would like to delete the last FFS bullet and keep the center frequency alignment for TDD in all the cases. We see this is part of the compromise for initial BWP issue, together with the configurable SSB in initial DL BWP (if paging CSS is not configured) as in Proposal 2.2-6e. Nordic Y Thanks FL for illustration (very good for discussion). We are fine to have Intel FFS. However, we believe that reasonable gNB would configure initial DL BWP as wide as the initial UL BWP, such it can be used without improved latency after MSG4 in BWP config Option 2. IDCC Y Nokia, NSB Y We support to have the FFS. FUTUREWEI6 Y We are fine to have Intel＊s FFS Qualcomm We think the last FFS bullet can be removed Ericsson Y Apple We prefer to remove the FFS bullet. DOCOMO Y Lenovo, Motorola Mobility Y We support to have the FFS. We prefer to revise back the wording as below, o Support the case when If a separate initial DL BWP is not configured, the centre frequency is assumed to be the same for the initial DL BWP and the separate initial UL BWP in TDD. Intel First, the ※infeasibility§ for the following example from Ericsson is understandable only if aligning RedCap PUCCH at edge of the carrier is considered as a mandatory design option for the gNB. We do not think that is always the case, especially if PUCCH FH can be disabled the impact to PUSCH fragmentation can be addressed rather effectively for the most part, making the following example feasible in many scenarios. The updated proposal seems to say that aligning center frequencies between DL and UL in Idle/inactive modes is the default, and the non-aligned case would be FFS. Effectively, this means that we are agreeing to mandate configuration of separate initial DL BWP before RRC connection to ensure alignment of DL and UL center frequency. However, we still do not think that the configuration should be mandated this way when the RF retuning-based operation works perfectly during initial access. At the minimum, agreeing to this proposal in isolation would not be acceptable to us, if we are running the risk of duplicating a lot of DL system OH in the separate initial DL BWP. OPPO We also prefer to remove the last FFS. For a normal NR UE, the centre frequency of DL and UL BWP is the same for TDD, there is no reason to have different centre frequency for RedCap UE in TDD case. CATT Y Considering that the views on centre frequency during initial access are still split, at least for now, we think it is fair to keep the FFS. Samsung Y Fine with or without FFS ZTE, Sanechips Y Panasonic Y NEC We consider the FFS bullet of the proposal a bit ambiguous about which initial DL BWP is concerned (CORESET#0 bandwidth or the legacy initial DL BWP?). Intel＊s version of FFS would be clearer. Xiaomi Prefer to remove the last FFS CMCC Y LG Y We prefer to remove the last FFS, but can live with it for the progress. FL7 Based on the received responses, the same proposal can be considered again. Note that, if necessary, different proposals can be agreed together or in a particular order. High Priority Proposal 3.1-1c: Confirm the following modified version of the working assumption from RAN1#105-e: * Both during and after initial access, for the scenario where the initial UL BWP for non-RedCap UEs is configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap UEs. o FFS: whether/how to avoid or minimize PUSCH resource fragmentation due to PUCCH transmission for the above case o If a separate initial DL BWP is configured, the centre frequency is assumed to be the same for the separate initial DL BWP and the separate initial UL BWP in TDD. o If a separate initial DL BWP is not configured, the centre frequency is assumed to be the same for the initial DL BWP and the separate initial UL BWP in TDD. * FFS whether or not to additionally support the case when the center frequency is different between the separate initial UL BWP and the initial DL BWP, and, if so, how to minimize center frequency retuning FL8 Based on received responses, we can come back to this after other proposals have seen progress. 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. The following agreement was made in an online (GTW) session on Tuesday 24th August: Agreement: * In case a separate initial UL BWP is configured for RedCap UEs, it is supported that the network can enable/disable intra-slot PUCCH frequency hopping within the separate initial UL BWP in the PUCCH resource for HARQ feedback for Msg4/MsgB for RedCap UEs. o Working assumption: The frequency hopping is enabled/disabled at least via SIB. 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 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 to make progress 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. NEC Y Panasonic Y in principle The intention to leave the latter sentence overlapping 2.2-4b is still unclear to us. vivo Qualcomm has a valid point: Not having MIB-configured CORESET#0 included in the active BWP in CONNECTED mode is not FG6-1, so it is related to the debate of FG6-1 and FG6-1a. Therefore suggest we only address the center frequency alignment issue in this proposal, i.e. * 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 Apple Same comment. We do not understand why the latter sentence is needed as it is covered by Proposal 2.2-4b already. ZTE, Sanechips Y but need clarification As mentioned before, the later part of this proposal is overlapping with the following question: 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, the clarification for keeping the later part is needed. OPPO Partially Y Agree with Vivo and QUALCOMM FL4 Based on the received responses, the following updated proposal can be considered, where the part about CORESET#0 has been deleted to eliminate an overlap with Proposal 2.2-4c. (If necessary, this proposal can be treated together with Proposal 2.2-4c or in a specific order.) High Priority Proposal 3.1-3c: * 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 vivo Y Huawei, HiSilicon Y Qualcomm Y Samsung Y CATT Y For moving forward. CMCC Y IDCC Y ZTE, Sanechips Y MediaTek Y Nordic N No need to change specification 38.213: For unpaired spectrum operation, a UE does not expect to receive a configuration where the center frequency for a DL BWP is different than the center frequency for an UL BWP when the BWP-Id of the DL BWP is same as the BWP-Id of the UL BWP. We are fine to keep it open as following The center frequencies for separate initial UL/DL BWPs for RedCap UEs in TDD are the same * FFS: different during initial access Nokia, NSB Y We can accept this to make progress FUTUREWEI4 Y The rewording of the FFS by Nordic should be applied: FFS: different during initial access DOCOMO Y NEC Y Fine with Nordic＊s version. Ericsson Yes, but The proposal should be treated after or together with Proposal 2.2-4c. Intel Y Can accept this for progress. OPPO Y Lenovo, Motorola Mobility Y On the other hand, we do think we need make a decision now for the FFS point. We have discussed this issue for so many meetings. LG Y FL5 Based on the received responses, the following updated proposal can be considered. (If necessary, this proposal can be treated together with Proposals 2.2-4c and 3.1-1b or in a specific order.) High Priority Proposal 3.1-3d: * At least after initial access, The center frequencies for separate initial UL/DL BWPs for RedCap UEs in TDD are the same (if supported and configured). o FFS: different during initial access Huawei, HiSilicon Y? Is the proposal to ask * At least after initial access, The center frequencies for separate initial UL/DL BWPs (if supported and configured) for RedCap UEs in TDD are the same. o FFS: they can be different during initial access Nordic Y,but same comment as in other proposal, support of configuration of separate initial DL BWP is agreed as WA. Not sure what is FL intention, here. Vivo N ※if supported§ should be removed Panasonic Support Huawei＊s update. CATT Y Fine with Huawei＊s version. DOCOMO Y Lenovo, Motorola Mobility N For the main bullet, we also think ※if supported§ shall be removed, pls. see also our comment for 2.2-4d. We think the FFS in current version does not reflect the concern clearly. It will mean ※FFS: different center frequencies for separate initial DL/UL BWPs during initial access§, while the concern in our understanding is whether we could have separate initial UL BWP associated with legacy MIB-configured initial DL BWP, which have different center frequencies. With this, we suggest following revisions: * At least after initial access, The center frequencies for separate initial UL/DL BWPs for RedCap UEs (if configured) in TDD are the same (if supported and configured). * FFS: The separate initial UL BWP can be associated with MIB-configured initial DL BWP, which have different center frequencies. And we support different center frequencies during initial access. Intel N This version does not seem very clear to us. In particular, this seems to imply that separate initial BWPs need to be always configured simultaneously, which we do not agree with. At this point, we can only accept the center freq- alignment requirement for after initial access. FUTUREWEI5 N The revision proposed by Lenovo is reasonable. We also support different center frequencies during initial access. CMCC Fine with vivo and Huawei＊s update. TCL Support Huawei＊s update. NEC We prefer Lenovo/Motorola Mobility＊s revision Samsung Fine with vivo and Huawei＊s update Xiaomi N ＆if supported＊ should be removed LG Prefer to remove the ※if supported§. Ericsson Y We are fine with Huawei＊s suggestion. However, we suggest merging this proposal with Proposal 3.1-1b ZTE, Sanechips Y If there exist the possibility to support different center frequencies during initial access, then ＆if supported＊ is required. If we agree to support the same center frequencies during/after initial access, then the ＆if supported＊ is not required. At present stage, it is better to keep the ＆if supported＊ FL6 This proposal has been replaced by Proposal 3.1-1c. 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. The following agreement was made in an online (GTW) session on Friday 20th August: Agreement: 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. 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 FUTUREWEI Vip Desai vipul.desai@futurewei.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) [44] R1-2108269 FL summary #3 on reduced maximum UE bandwidth for RedCap Moderator (Ericsson) [44] R1-2108270 FL summary #4 on reduced maximum UE bandwidth for RedCap Moderator (Ericsson)