3GPP TSG-RAN WG1 Meeting #107-e Draft R1-2112497 e-Meeting, 11th 每 19th November 2021 Agenda Item: 8.6.1.1 Title: FL summary #1 on reduced maximum UE bandwidth for RedCap Source: Moderator (Ericsson) Document for: Discussion, Decision Introduction This feature lead (FL) summary (FLS) concerns the Rel-17 work item (WI) for support of reduced capability (RedCap) NR devices [1]. Earlier RAN1 agreements for this WI are summarized in [2]. The final FLS for this agenda item from the previous RAN1 meeting can be found in [3]. This document summarizes contributions [4] 每 [29] submitted to agenda item 8.6.1.1 and relevant parts of contributions [30] 每 [36] submitted to other agenda items and captures this email discussion on reduced maximum UE bandwidth: [107-e-NR-R17-RedCap-01] Email discussion regarding aspects related to reduced maximum UE bandwidth 每 Johan (Ericsson) 1st check point: November 15 Final check point: November 19 RAN1 is waiting for LS responses from RAN2 and RAN4 to an LS on NCD-SSB sent from RAN1#106bis-e [37]. This is discussed in Section 5 (※SSB transmission§) in this document. The issues in this document are tagged and color coded with High Priority or Medium Priority. The issues that are in the focus of this round of the discussion in this meeting are furthermore tagged FL1. Follow the naming convention in this example: RedCapBwFLS-v000.docx RedCapBwFLS-v001-CompanyA.docx RedCapBwFLS-v002-CompanyA-CompanyB.docx RedCapBwFLS-v003-CompanyB-CompanyC.docx If needed, you may ※lock§ a spreadsheet file for 30 minutes by creating a checkout file, as in this example: Assume CompanyC wants to update RedCapBwFLS-v002-CompanyA-CompanyB.docx. CompanyC uploads an empty file named RedCapBwFLS-v003-CompanyB-CompanyC.checkout CompanyC checks that no one else has created a checkout file simultaneously, and if there is a collision, CompanyC tries to coordinate with the company who made the other checkout (see, e.g., contact list below). CompanyC then has 30 minutes to upload RedCapBwFLS-v003-CompanyB-CompanyC.docx If no update is uploaded in 30 minutes, other companies can ignore the checkout file. Note that the file timestamps on the server are in UTC time. In file names, please use the hyphen character (not the underline character) and include ＆v＊ in front of the version number, as in the examples above and in line with the general recommendation (see slide 10 in R1-2110752), otherwise the sorting of the files will be messed up (which can only be fixed by the RAN1 secretary). To avoid excessive email load on the RAN1 email reflector, please note that there is NO need to send an info email to the reflector just to inform that you have uploaded a new version of this document. Companies are invited to enter the contact info in the table below. FL1 Question 1-1a: Please consider entering contact info below for the points of contact for this email discussion. Company Point of contact Email address Intel Corporation Debdeep Chatterjee debdeep.chatterjee@intel.com Qualcomm Jing Lei leijing@qti.qualcomm.com vivo Xueming Pan panxueming@vivo.com Huawei, HiSilicon Yi WANG wangyi6@huawei.com NTT DOCOMO Mayuko Okano mayuko.okano@docomo-lab.com Nordic Karol Schober karol.schober@nordicsemi.no Sharp Hiroki Takahashi takahashi.hiroki@sharp.co.jp Panasonic Shotaro Maki maki.shotaro@jp.panasonic.com ZTE Youjun Hu hu.youjun1@zte.com.cn CATT Yongqiang FEI feiyongqiang@catt.cn CMCC Lijie Hu hulijie@chinamobile.com Separate initial UL BWP RAN1#106bis-e [2] made the following agreement regarding separate initial UL BWP: Agreement: For a cell that allows a RedCap UE to access, network can configure a separate initial UL BWP for RedCap UEs in SIB It can be used both during and after initial access. It is no wider than the maximum RedCap UE bandwidth. It is always configured if the initial UL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth This applies to both TDD and FDD (including FD FDD and HD FDD) cases In RAN1#106bis-e [3], there was a discussion on whether up to 2 separate initial UL BWPs can also be configured for RedCap: High Priority Proposal 2.1-2d: It is FFS till RAN1#107-e whether up to 2 separate initial UL BWPs can also be configured. Several contributions [4, 8, 15, 16, 17, 28] indicate that only one separate initial UL BWP is configured for RedCap in Rel-17. These contributions argue that having more than one separate initial UL BWP for RedCap has a limited motivation while it results in PUSCH resource fragmentation, additional overhead, and complicated UL/DL BWP configuration especially when TDD centre frequency alignment is desired. However, a few contributions express that up to 2 initial UL BWPs should be configured for RedCap to be able to share 8 FDMed ROs between RedCap and non-RedCap UEs [5, 6, 12]. FL1 High Priority Question 2-1a: How many separate initial UL BWPs for RedCap can be configured? Option 1: Up to 1 separate initial UL BWP for RedCap can be configured. Option 2: Up to 2 separate initial UL BWPs for RedCap can be configured. Company Option (1/2) Comments Intel 1 Up to one separate initial UL BWP for RedCap is sufficient. It is not justified to introduce significant complications to the RedCap BWP framework with support of more than one separate initial UL BWP, only to support the case of max number of FDM-ed ROs in some configurations that may exceed max RedCap UE BW. The option of separately configuring ROs for RedCap UEs (that need not be shared with non-RedCap UEs and need not all be multiplexed via FDM as for non-RedCap UEs) in a separate initial UL BWP that is limited to within RedCap UE max BW is sufficient. The RedCap BWP framework is already far from having a stable design with consideration of a single separate initial UL BWP; extending this further for a corner case would not be a prudent choice. Qualcomm Option 1 vivo Option 1 For Rel-17, we are fine with supporting up to 1 separate initial UL BWP for RedCap. HW, HiSi 2 If a separate initial DL BWP is agreed to be used during initial access, then up to 2 separate initial UL BWP can be configured. Otherwise, one separate initial UL is fine. There is no single valid reason except for TDD centre frequency alignment for Msg4 PUCCH, to support a separate initial DL BWP. DOCOMO Option 1 Nordic Option 1 As mentioned before, if configured ROs are shared between RedCap and non-RedCap UE, all configured ROs must have same SCS and must be confined within BW of aRedCap UEs. Sharp Option 1 Panasonic Option 1 Our view is multiple separate initial UL BWP for RedCap would not be essential if ROs in separate initial UL BWP can be used instead of ROs in non-RedCap BWP. We propose to conclude that the network should be able to configure the RO configuration (1, 2 or 4 FDM) in one separate initial UL BWP for RedCap. ZTE, Sanechips Option 1 CATT Option 2(1st preference) Option 2 is our 1st preference to allow full flexibility for ROs for non-RedCap UE when ROs are shared. But we can compromise to Option 1 if it is the majority view. CMCC Option1 One separate initial UL BWP can deal with the RO issue. If one separate initial UL BWP cannot guarantee that every SSB index has its associated RO within it, shared RO should not be used, and dedicated ROs for RedCap are configured within the BWP. Separate initial DL BWP Related to configuring/defining a separate initial DL BWP for RedCap UEs, we have the following working assumption in RAN1#105-e [2]: Working assumption: At least for TDD, an initial DL BWP for RedCap UEs (which is not expected to exceed the maximum RedCap UE bandwidth) can be optionally configured/defined separately from the initial DL BWP for non-RedCap UEs at least after initial access FFS the details of the configuration/definition The configuration for a separately configured initial DL BWP for RedCap UEs is signaled in SIB. whether to support that separate initial DL BWP for RedCap UEs can include a configuration of CORESET and CSS(s) whether part of the configuration can be defined instead of signaled If a separate initial DL BWP for RedCap UEs is configured/defined, this separate initial DL BWP for RedCap UEs can be used at least after initial access (i.e., at least after RRC Setup, RRC Resume, or RRC Reestablishment). FFS during the initial access FFS: whether a separately configured initial DL BWP for RedCap UEs needs to contain the entire CORESET #0, and, if not, the RedCap UE behaviour for CORESET #0 monitoring FFS: supported bandwidths in the separate initial DL BWP FFS: whether additional SSB is transmitted in the separately configured initial DL BWP for RedCap UEs FFS: FDD case The working assumptions from RAN1#106bis-e [2] are as follows: Working Assumption: For a cell that allows a RedCap UE to access, network can configure a separate initial DL BWP for RedCap UEs in SIB. Working assumption: It can be used during initial access It can be used after initial access. It is no wider than the maximum RedCap UE bandwidth. FFS: It is always configured if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. This applies to both TDD and FDD (including FD FDD and HD FDD) cases. Working assumption: It applies at least after initial access for FR1 when MIB configured CORESET#0 is included The contributions generally agree that configuring/defining a separate initial DL BWP for RedCap UEs is beneficial for flexibility and/or offloading purposes and also it is needed in scenarios where non-RedCap initial DL BWP is larger than the RedCap UE bandwidth (e.g., [4, 8, 10, 14, 15, 16, 17, 22, 23, 24, 28, 29]). Moreover, most of the contributions propose to confirm the working assumptions from RAN1#106bis-e related to the configuration of a separate initial DL BWP for RedCap. It was also proposed that such configuration applies to both FR1 and FR2 [4]. Regarding ※FFS: It is always configured if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth§, the contributions express different views. Two contributions [17, 29] indicate that the separate initial DL BWP for RedCap is always configured if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. Meanwhile, several contributions [4, 10, 14, 15, 19, 24, 25] argue it is not necessary to always configure a separate initial DL BWP for RedCap. Specifically, if the separate initial DL BWP for RedCap UEs is not configured, then the RedCap UEs may assume the MIB-configured CORESET#0 bandwidth as the initial DL BWP: [15]: There is no need to mandate separate initial DL BWP configuration for RedCap when the SIB-configured BWP#0 is larger than the maximum RedCap UE bandwidth. [19]: If SIB1-configured initial DL BWP has a wider bandwidth than the maximum RedCap UE bandwidth and additional initial DL for RedCap UEs is not configured, a RedCap UE derives initial DL BWP corresponding to CORESET#0. [24]: If the separate initial DL BWP for RedCap UEs is not configured, then the RedCap UEs may assume the MIB-configured CORESET#0 bandwidth as the initial DL BWP. [25]: When the parameter on the separate initial DL BWP is absent, a RedCap UE use the BW of CORESET#0 or configuration of initial DL BWP for non-RedCap. Based on the above views, the following proposal and question related to the RedCap separate initial DL BWP can be considered. FL1 High Priority Proposal 3-1a: The following working assumptions related to the separate initial DL BWPs for RedCap are confirmed for both FR1 and FR2: Working Assumption: For a cell that allows a RedCap UE to access, network can configure a separate initial DL BWP for RedCap UEs in SIB. Working assumption: It can be used during initial access It can be used after initial access. It is no wider than the maximum RedCap UE bandwidth. This applies to both TDD and FDD (including FD FDD and HD FDD) cases. Working assumption: It applies at least after initial access for FR1 when MIB configured CORESET#0 is included Company Y/N Comments Intel Y (see comments) While we can confirm the working assumptions, the case not covered by the last working assumption needs to be addressed as well. To elaborate, if the initial DL BWP is used during initial access, e.g., if PDCCH Type 1 CSS for random access is configured in the separate initial DL BWP, but MIB-configured CORESET #0 is not included within the separate initial DL BWP, the RedCap UE should continue to receive DL in the separate initial DL BWP after RRC connection establishment (※after initial access§). Moreover, if any other PDCCH CSS (Types 0/0A/2) are (optionally) configured in the separate initial DL BWP, the RedCap UE can receive the corresponding common control in the separate initial DL BWP if the latter is included within its active DL BWP when in RRC_CONNECTED mode. Thus, if a separate initial DL BWP is configured to RedCap UE, it should be applicable for reception by RedCap UEs after initial access regardless of whether MIB-configured CORESET #0 is included or not. Qualcomm Y partially Since there is no consensus yet on the configuration of RedCap-specific initial DL BWP which does not include the entire MIB-configured CORESET#0, we suggest to agree on the following initial DL BWP configurations for RedCap UE first : For a cell that allows a RedCap UE to access in TDD or FDD, a RedCap UE can use a SIB-configured initial DL BWP during and after initial access, if the SIB-configured initial DL BWP is no wider than the max RedCap UE BW and includes both MIB-configured CORESET#0 as well as CD-SSB FFS: SIB-configured initial DL BWP for RedCap UE, which does not include the entire MIB-configured CORESET#0 and CD-SSB if a separate initial DL BWP is not configured for RedCap UE in SIB, RedCap UE shall use the MIB-configured CORESET#0 as the initial DL BWP during and after initial access vivo The feasibility of using the separate initial BWP during or after initial access highly depends on the outcome of the other discussion, i.e. NCD-SSB. Therefore, we think the WA should be reviewed/confirmed later. HW, HiSi We foresee many potential issues (as below) if a separate initial DL BWP is to be introduced: Impact on CN and design for PEI associated with CORESET other than #0, if power saving is desirable for RedCap UEs RF retuning/BWP switching time if separate initial DL BWP does not contain CORESET#0 Presence of (CD/NCD)-SSB/CSI-RS/TRS during/after initial access needs RAN2 input and how the UE know which BWP contains what before capability report It is also related to Proposal 3-3a discussing the motivation of the separate initial DL BWP. DOCOMO Y Nordic Y, but add note While we agree that UE can receive within CORESET#0 during initial access, it is up to RAN2 to design conditions under which parameter is configured. In our opinion it depends whether pdcch-ConfigCommon would be configured separately for RedCap UEs or not. Therefore, for sake of progress we could be fine if note is included Working Assumption: For a cell that allows a RedCap UE to access, network can configure a separate initial DL BWP for RedCap UEs in SIB. Working assumption: It can be used during initial access It can be used after initial access. It is no wider than the maximum RedCap UE bandwidth. This applies to both TDD and FDD (including FD FDD and HD FDD) cases. Working assumption: It applies at least after initial access for FR1 when MIB configured CORESET#0 is included Note: Whether it is always configured if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth is up to RAN2 Furthermore, we disagree with QC that CORESET#0 can be an active BWP after MSG4. In BWP configuration Option 1, gNB shall configure BWP#1 in our understanding. Sharp Y with modification The relation between 1st bullet, 2nd bullet and last bullet is a little complicated. We suggest confirming the working assumption with following modification. For a cell that allows a RedCap UE to access, network can configure a separate initial DL BWP for RedCap UEs in SIB. Working assumption: It can be used during initial access at least when MIB configured CORESET#0 is not included It can be used after initial access. It is no wider than the maximum RedCap UE bandwidth. This applies to both TDD and FDD (including FD FDD and HD FDD) cases. Working assumption: It applies at least after initial access for FR1 when MIB configured CORESET#0 is included Panasonic Y ZTE, Sanechips Y For the second working assumption, similar like the RRC configured BWP, the separate initial DL BWP can be used regardless of whether CORESET0 is included or not Working assumption: It applies at least after initial access for FR1 when MIB configured CORESET#0 is included CATT Partially We are OK to confirm the WA in the main body and the last sub-bullet. But for the 1st sub-bullet (especially for ＆during initial access＊), we think it is highly related to the outcome of relationship between separate initial DL BWP and SSB. Prefer to live it open for now. CMCC Y At least for TDD center frequency alignment and offloading purpose, and for simplifying BWP behavior when RRC configured initial DL BWP is larger than 20MHz, a separate initial DL BWP for RedCap UEs can be configured/defined. At least when separate initial DL BWP does not contain entire CORESET0 and contains RACH CSS or paging CSS, it can be used during initial access. FL1 High Priority Question 3-2a: Should a separate SIB-configured initial DL BWP for RedCap always be configured if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth? Company Y/N Comments Intel N The initial DL BWP for non-RedCap UEs, provided via SIB1, can be larger than max RedCap UE BW. If NOT configured with a separate initial DL BWP for RedCap, a RedCap UE ignores the ※locationAndBandwidth§ configuration for the initial DL BWP and continues to receive in the DL in the initial DL BWP defined by CORESET #0. Note that rest of the configuration for the initial DL BWP in SIB1 applies to RedCap UEs as when in Idle/Inactive modes. Qualcomm N By default, a RedCap UE can use the MIB-configured CORESET#0 as the initial DL BWP during and after initial access, if a separate initial DL BWP is not configured for RedCap UE in SIB vivo Y if the NW allows RedCap UEs access If a separate SIB-configured initial DL BWP for RedCap is NOT always configured when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, then for a RedCap UE after the initial access, in order to efficiently and flexibly support RedCap UEs, anyway a separate initial DL BWP need to be configured. Therefore, we did not identify any actual benefits to for RedCap UEs use CORESET#0 derived by MIB for both during and after initial access. This also follows the existing mechanism for the configuration for the non-RedCap UEs that the initial DL BWP should always be configured even the initial DL BWP confines the CORESET#0. In addition, always configuring a separate SIB-configured initial DL BWP for RedCap also aligns with the always configuring a separate initial UL BWP when the initial BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. HW, HiSi If it is agreed that can be used during initial access, then it can be configured depending on network. If not configured, CORESET#0 is reused. If configured, this separate initial DL BWP is used. DOCOMO N As commented by Intel and Qualcomm, MIB configured CORESET#0 BWP can be used as initial DL BWP during and after initial access for RedCap UE even if the initial DL BWP for non-RedCap UE is wider than the maximum RedCap UE BW. Nordic Y UE receives within MIB-configured CORESET#0 until MSG4, but BWP-DownlinkCommon has also other parameters than locationAndBandwidth. Furthermore, as you can see below initialDownlinkBWP is not Optional DownlinkConfigCommonSIB ::= SEQUENCE { frequencyInfoDL FrequencyInfoDL-SIB, initialDownlinkBWP BWP-DownlinkCommon, bcch-Config BCCH-Config, pcch-Config PCCH-Config, ... } BWP-DownlinkCommon ::= SEQUENCE { genericParameters BWP, pdcch-ConfigCommon SetupRelease { PDCCH-ConfigCommon } OPTIONAL, -- Need M pdsch-ConfigCommon SetupRelease { PDSCH-ConfigCommon } OPTIONAL, -- Need M ... } BWP ::= SEQUENCE { locationAndBandwidth INTEGER (0..37949), subcarrierSpacing SubcarrierSpacing, cyclicPrefix ENUMERATED { extended } OPTIONAL -- Need R } These aspects are in competence of RAN2. Sharp If BWP configuration for separate initial DL BWP is not provided and if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, a RedCap UE should follow the following current 38.331 principle except ※until after reception of RRCSetup/RRCResume/RRCReestablishment§ The UE applies the locationAndBandwidth upon reception of this field (e.g. to determine the frequency position of signals described in relation to this locationAndBandwidth) but it keeps CORESET#0 until after reception of RRCSetup/RRCResume/RRCReestablishment. On the other hand, if some BWP configuration (such as SS/CORESET configuration) for the separate initial DL BWP need to be provided, the BWP configuration for separate initial DL BWP including/or not including locationAndBandwidth should be provided. For simplification, we are also fine that a separate SIB-configured initial DL BWP for RedCap always be configured. Panasonic N We think it should be up to the network implementation whether to configure the separate SIB-configured initial DL BWP or not. If the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, and if separate SIB-configured initial DL BWP for RedCap is not configured, a RedCap UE can use MIB-configured CORESET #0 as initial DL BWP ZTE, Sanechips N It is not necessary to always configure a separately SIB-configured initial DL BWP for RedCap UEs if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. The following benefits can be observed. The NW has the flexibility to configure the separate initial DL BWP or not., e.g., no any other resources can be allocated for the separate initial DL BWP and/or the MIB-configured CORESET#0 is located at the carrier edge, in this case, using CORESET0 is the simplest way. Save the signalling overhead if the separate initial DL BWP is not configured in SIB1. CATT N In this case, the RedCap UE can use the bandwidth and location defined by CORESET#0 instead. CMCC Y In this case, it is necessary to support separate initial DL BWP to enable RedCap UE can work normally. To remain the flexibility of location of separate initial UL BWP, when it is at the edge of carrier, separate initial DL BWP can also be configured at the edge of carrier. When the center frequency of separate initial UL BWP is the same as CORESET0, CORESET0 can be defined as separate initial DL BWP. We suggest to modify ＆configured＊ in proposal as ＆configured/defined＊. Regarding the presence of CORESET#0 and other CORESETs/CSSs in the separate initial DL BWP: Based on the latest feature lead summary in RAN1#106bis-e [3], the following aspects are under discussion: High Priority Proposal 3.2-5-1a: For FR1, If a separate SIB-configured initial DL BWP for RedCap UEs is configured, It contains at least one CORESET and at least one CSS. It can be used both during and after initial access. FFS: However, if it contains the entire CORESET#0, the RedCap UE shall use the bandwidth and location of the CORESET#0 in DL during initial access. Many contributions propose that a separate SIB-configured initial DL BWP for RedCap (if configured) does not need to contain the entire CORESET#0 [4, 5, 10, 14, 15, 17, 19, 22, 24, 25]. Also, several contributions mention that the separate initial DL BWP for RedCap UEs can include a configuration of CORESETs and CSS(s) [4, 5, 8, 10, 12, 14, 16, 17, 21, 22, 23]. In addition, several contributions [4, 11, 23] mention that if the separate initial DL BWP contains the entire CORESET#0, the RedCap UE shall use the bandwidth and location of the CORESET#0 in DL during initial access. FL1 High Priority Proposal 3-3a: For FR1 and FR2, if a separate SIB-configured initial DL BWP for RedCap UEs is configured, It contains at least one CORESET and at least one CSS. It may or may not contain the entire MIB-configured CORESET#0. If it contains the entire CORESET#0, the RedCap UE shall use the bandwidth and location of the CORESET#0 in DL during initial access. Company Y/N Comments Intel Y Qualcomm FFS We can agree with this proposal, if clarifications are provided for the SSB and CSS configuration. Basically, we think a RedCap UE can support a SIB-configured initial DL BWP which does not contain the entire MIB-configured CORESET#0, as long as this initial DL BWP includes SSB (CD-SSB or NCD-SSB) and CSS for paging and RA. If the SIB-configured initial DL BWP does not include CSS for paging, UE operating in this initial DL BWP cannot get SI update and/or PWS notification during initial access. For UE complexity reduction and power saving, a RedCap UE shall not monitor CSS for SIB1/OSI periodically (for each period of SI modification) by autonomous BWP switching from the SIB-configured initial DL BWP to the MIB-configured CORESET#0. Such autonomous BWP switching is not supported in NR R15/16, which incurs extra complexity and power consumption of RedCap UE. vivo Y HW, HiSi N If the separate initial DL BWP is to be useful and used during initial access by being configured with at least one CORESET and CSS, the separate initial DL BWP can be used instead of the CORESET#0 only. The last sub-sub-bullet is not needed. One possible scenario can be a 20 MHz carrier configured with 5 MHz CORESET#0, which is not desirable to be changed per the access of RedCap UEs. In this case, the network has to use the entire separate initial DL BWP e.g. 20 MHz with (additional) CORESET/CSS for offloading if needed, which anyway will contain the CORESET#0. DOCOMO Y Nordic N Cannot agree on this separately without agreeing also Option 2 Sharp N We don＊t need to have the limitation in last sub-sub bullet. In Rel-17 RedCap, a separate (SIB-configured) initial DL BWP can be used during initial access and this principle is different from Rel-15/16 principle. Therefore, we think the separate initial DL BWP doesn＊t need to follow the Rel-15/16 principle. For the configuration simplicity, whether a RedCap UE use the bandwidth and location of the CORESET#0 or not should depends on only whether CSS/CORESET for the separate initial DL BWP is configured or not irrespective of the existence of CORESET#0 in the separate initial DL BWP. Panasonic Y ZTE, Sanechips If the separate initial DL BWP for RedCap UEs contains the MIB-configured CORESET#0, whether to use the separate initial DL BWP depends on the configuration of separate CSS. If separate CSS for RACH is configured within the separate initial DL BWP, RedCap UEs shall use the separate initial DL BWP during initial access for the purpose of offloading and minimizing impacts on legacy UEs. If separate CSS for RACH is not configured, RedCap UEs shall use the bandwidth and location of the CORESET#0 in DL during initial access to minimize spec effort. Therefore, we prefer to consider the following revision: It may or may not contain the entire MIB-configured CORESET#0. If it contains the entire CORESET#0 separate CSS for RACH is not configured, the RedCap UE shall use the bandwidth and location of the CORESET#0 in DL during initial access. CATT Y For the last sub-sub bullet, we think it is necessary. This is not only because it follows the current NR principle, but also it is still workable for the case when early indication of RedCap is done during Msg3 but not Msg1 (i.e. RO and preambles are shared). In this case, the gNB can only assume all the UEs (including non-RedCap UE and RedCap UE) are using the bandwidth and location of CORESET#0 for Msg2 reception (i.e. following legacy mechanism), until Msg3 is received. BTW, we think it is not reasonable to assume the gNB always prefers a poor configuration of bandwidth. CMCC Y Supported bandwidths in the separate initial DL BWP: There are only a few views on the supported bandwidth of the separate initial DL BWP: [4]: For RedCap UEs the bandwidth of the separate initial DL BWP can have any value up to the maximum UE bandwidth (i.e., 20 MHz in FR1 and 100 MHz in FR2). [7]: The supported bandwidths in the separate initial DL BWP for RedCap UEs can have any values up to the maximum UE bandwidth. [15]: If the separate initial DL BWP is configured by SIB1, limit the supported bandwidth to relieve the capacity limitation in SIB1. [16]: For RedCap UE being configured with separate initial DL/UL BWP, fallback DCI size for RedCap UE is determined by down-selected following alternatives: Alt 1: Fallback DCI size for RedCap UE is the same as legacy Rel-15/16 which is determined by CORESET#0. Alt 2: Fallback DCI size for RedCap UE can be determined by separate initial UL/DL BWP for RedCap UE. 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 bandwidths. Medium Priority Question 3-4a: For a separate initial DL BWP for RedCap UEs, what bandwidths should be supported? Option A: The supported bandwidths for the separate initial DL BWP for RedCap UEs can have any values up to the maximum UE bandwidth (as in legacy operation). Option B: The supported bandwidths for the separate initial DL BWP for RedCap UEs must be limited to a set of pre-defined values such as CORESET#0 bandwidths. Company Option (A/B) Comments BWP center frequency RAN1#106bis-e [2] made the following agreement related to center frequencies for DL/UL BWPs in TDD: Agreement: For FR1, For TDD, center frequencies are assumed to be the same for the initial DL (FFS: if it does not include CD-SSB and the entire CORESET#0) and UL BWPs used during random access for RedCap UEs. FFS: For Option 1 and Option 2, whether the case that the center frequencies are different is also supported, and whether RedCap UE can expect CD-SSB and CORESET#0 in this case For TDD, center frequencies are assumed to be the same for non-initial DL and UL BWPs with the same BWP id for a RedCap UE. Several contributions support/accept having the possibility of separate TDD center frequencies for initial UL/DL BWPs [4, 5, 7, 16, 17, 19, 22, 25, 26]. Moreover, these contributions mention that TDD center frequency alignment can depend on the scenario that whether the initial DL BWP contains SSB and/or CORESET#0. However, some other contributions indicate that the same center frequency is preferred to be maintained for initial UL/DL BWPs [12, 14, 15]. One contribution proposes to confirm that CORESET#0 does not need to be aligned in center frequency with (separate) initial UL BWP, for both BWP-configuration Option 1 and Option 2. [4]: With the support of separate center frequencies for initial UL/DL BWPs in TDD during initial access, all concerns regarding the PUSCH resource fragmentation and the presence of SSB and CORESET#0 within the initial DL BWP are resolved. [4]: For TDD, RAN 1 should down-select between the following cases for RedCap: Case 1: The center frequencies for initial UL/DL BWPs can be different, but the initial DL BWP always contains the CORESET#0 and SSB. Case 2: The center frequencies for initial UL/DL BWPs are always the same, but the initial DL BWP does not necessarily contain CORESET#0. [7]: The center frequencies are assumed to be the same for the initial DL (if it does not include CD-SSB and the entire CORESET#0) and UL BWPs used during random access for RedCap UEs. The center frequencies can be different for the initial DL (if it includes CD-SSB and the entire CORESET#0) and UL BWPs used during random access for RedCap UEs. [14]: For TDD, center frequencies are assumed to be the same for the initial DL BWP and initial UL BWP used during random access, regardless of whether the initial DL BWP includes CD-SSB and entire CORESET#0 or NOT. [15]: Assume the same center frequency for the initial DL and UL BWPs in all cases. [17]: For Option 1, the case that the center frequencies of initial BWPs are different is not supported. For Option 2, the case that the center frequencies of initial BWPs are different is supported, and RedCap UE can expect CD-SSB and CORESET#0 in this case. [19]: For initial DL/UL BWPs during initial access procedure, the RF-retuning latency and power consumption maybe acceptable from UE complexity perspective due to the less frequent operation and relaxed processing time requirement. [19]: Different central frequencies of separate initial DL/UL BWP during random access can be considered if separate initial DL BWP for RedCap includes CD-SSB and CORESET#0. [22]: For TDD, the center frequency can be different for the initial BWPs during random access. [25]: Support the case that center frequency for initial DL BWP including MIB configured CORESET#0 and separate initial UL BWP for RedCap UEs can be different. [25]: Center frequency should be assumed to be the same for initial DL BWP not including MIB configured CORESET#0 and separate initial UL BWP for RedCap UEs. [26]: For TDD, center frequencies are different for DL and UL BWPs with the same BWP id for RedCap UE. Based on the expressed views, the following proposal can be considered. FL1 High Priority Proposal 4-1a: The center frequency of the MIB-configured CORESET#0 and the initial UL BWP may or may not be aligned. Company Y/N Comments Intel N We suggest qualifying the proposal as below: For TDD, the center frequency of the MIB-configured CORESET#0 and the initial UL BWP may or may not be aligned: if the MIB-configured CORESET #0 and initial UL BWP do not span a bandwidth larger than maximum RedCap UE BW, or if the UE is provided with configuration of Type 1 PDCCH CSS for random access in a separate initial DL BWP with same center frequency as initial UL BWP. Without the above qualifiers, the proposal implies that RedCap UE should support RF retuning between initial DL and UL BWPs. In such a case, we need to revert the decision from last meeting for consistency - there would be no benefit in forcing NW to configure separate initial DL BWP to align center frequency with initial UL BWP for TDD. On the other hand, if center frequency between separate initial DL BWP and initial UL BWP are to be aligned when separate initial DL BWP does NOT include MIB-configured CORESET #0, it is not clear how the presence of MIB-configured CORESET #0 within the initial DL BWP affects handling of different center frequencies between DL and UL BWPs when these are used for random access. Qualcomm Y (w/ clarification) In FDD, the center frequencies of MIB-configured CORESET#0 and the initial UL BWP of RedCap UE are always not aligned. In TDD, the center frequencies of MIB-configured CORESET#0 and the initial UL BWP of RedCap UE may or may not be aligned. If the center frequencies are not aligned, early indication of RedCap UE type in msg1 or msgA PRACH (if 2-step RACH is supported) should be enabled by SIB. vivo Y with modifications Suggest modifying as below: The center frequency of the MIB-configured CORESET#0 and the initial UL BWP may or may not be aligned for RedCap UEs. HW, HiSi Y We think it is possible to be maintained as that in R15. DOCOMO Y As pointed out by Intel and Qualcomm, ※for TDD§ can be added for the clarification. Nordic Y with clarification Also could be clarified that in TDD CORESET#0 is within BW of initial UL BWP Panasonic Y ZTE, Sanechips Y For non-RedCap UEs in RRC_IDLE/INACTIVE state, the center frequency of the MIB-configured CORESET#0 and the initial UL BWP configured by SIB1 can be the same or different. To minimize spec effort, the principle for non-RedCap UEs in current NR spec should be followed with unaligned center frequency of the MIB-configured CORESET#0 and the initial UL BWP being allowed. Additionally, if the center frequency of the MIB-configured CORESET#0 and the initial UL BWP is kept aligned, then the separate initial DL/UL BWP configuration would be quite limited and the PUSCH resource fragmentation problem would be quite serious. CATT Y Also prefer to clarify that this is for TDD case. CMCC Y It is possible that separate initial UL BWP locates at edge of carrier to reduce PUSCH fragmentation, initial DL BWP defined by CORESET#0 is used during initial access to reduce overhead of NCD-SSB. FL1 High Priority Proposal 4-2a: For FR1, For TDD, the center frequencies are assumed to be the same for the initial DL (if it does not include CD-SSB and the entire CORESET#0) and UL BWPs used during random access for RedCap UEs. For TDD, the center frequencies can be different for the initial DL (if it includes CD-SSB and the entire CORESET#0) and UL BWPs used during random access for RedCap UEs. Company Y/N Comments Intel N As explained in response to Proposal 4-1a, the second sub-bullet is not acceptable as the two bullets are not consistent in terms of expectations from the UE. Presence of CD-SSB/CORESET #0 does NOT impact retuning behavior between DL and UL BWPs in relation to the respective center frequencies. We can accept the following version: For FR1, For TDD, the center frequencies are assumed to be the same for the initial DL (if it does not include CD-SSB and the entire CORESET#0) and UL BWPs used during random access for RedCap UEs. For TDD, the center frequencies can be different for the initial DL (if it includes CD-SSB and the entire CORESET#0) and UL BWPs used during random access for RedCap UEs. Qualcomm Y vivo Y We are fine with the proposal for progress. HW, HiSi Y We understand the first bullet is to offer something for RedCap UE if a separate initial DL BWP is to be useful for multiple purposes, and the second bullet is the legacy case as in R15. So we agree. DOCOMO Y Nordic Y, with clarification For FR1, For TDD, the center frequencies are assumed to be the same for the initial DL (if it does not include CD-SSB and the entire CORESET#0) and UL BWPs until MSG4. For TDD, the center frequencies can be different for the initial DL (if it includes CD-SSB and the entire CORESET#0) and UL BWPs until MSG4. Panasonic Y ZTE, Sanechips Y If the initial DL BWP for RedCap UEs is defined as the MIB-configured CORESET#0 or contains the entire CORESET#0, the center frequency of the initial DL BWP does not need to be aligned with that of the initial UL BWP located at the carrier edge. Otherwise, if TDD center frequencies alignment during initial access is mandatory, the configuration of the existing network needs to be modified that CD-SSB and CORESET#0 are restricted to be placed at the carrier edge for aligning UL/DL center frequencies, which is detrimental to network scheduling flexibility. If the separate initial DL BWP for RedCap UEs does not include CD-SSB and the entire CORESET#0, the separate initial DL BWP can be used during initial access for the purpose of offloading and center frequencies alignment. In this case, center frequencies can be kept aligned for the initial DL and UL BWPs used during random access for RedCap UEs in TDD. CATT Y Both the cases can be supported by spec. CMCC Y FL1 High Priority Question 4-3a: For FR2, can the following (which is copied from FR1 Proposal 4-2a) apply? For TDD, the center frequencies are assumed to be the same for the initial DL (if it does not include CD-SSB and the entire CORESET#0) and UL BWPs used during random access for RedCap UEs. For TDD, the center frequencies can be different for the initial DL (if it includes CD-SSB and the entire CORESET#0) and UL BWPs used during random access for RedCap UEs. If the answer to the question is different for different SSB/CORESET#0 multiplexing patterns, please elaborate in the Comments field. Company Y/N Comments Intel N We agree with the same handling for FR1 and FR2. We also support NOT optimizing for particular SSB/CORESET #0 patterns. However, for the same reasons as described in responses to Proposal 4-1a and Proposal 4-2a, we can accept the above proposal with the following modifications. For FR2, can the following (which is copied from FR1 Proposal 4-2a) apply? For TDD, the center frequencies are assumed to be the same for the initial DL (if it does not include CD-SSB and the entire CORESET#0) and UL BWPs used during random access for RedCap UEs. For TDD, the center frequencies can be different for the initial DL (if it includes CD-SSB and the entire CORESET#0) and UL BWPs used during random access for RedCap UEs. vivo Y HW, HiSi Y DOCOMO Y Nordic Y We support QC proposal Panasonic Y ZTE, Sanechips Y with modification In the proposal, the case, only CD-SSB or entire CORESET0 is included in the separate initial DL BWP, is missed. That means whether the center frequency should be aligned for the case is not captured. If CORESET0 and/or SSB is included in the initial DL BWP, center frequency alignment may not be guaranteed since the initial UL BWP for RedCap UEs is placed at the carrier edge to mitigate PUSCH resource fragmentation. Therefore, we suggest the following minor revision: For TDD, the center frequencies are assumed to be the same for the initial DL (if it does not include CD-SSB and the entire CORESET#0) and UL BWPs used during random access for RedCap UEs. For TDD, the center frequencies can be different for the initial DL (if it includes CD-SSB and/or the entire CORESET#0) and UL BWPs used during random access for RedCap UEs. CATT Y CMCC Y SSB transmission The contributions express views on transmission of additional SSBs in a separate initial DL BWP and RRC-configured DL BWP related to the following two options (Option 1 and Option 2) discussed in RAN1#106bis-e [3]. For FR1, following options: Option 1: For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0), RedCap UE does NOT expect it to contain SSB/CORESET#0/SIB. For an RRC-configured active DL BWP (if it does not include CD-SSB and the entire CORESET#0), RedCap UE does NOT expect it to contain SSB/CORESET#0/SIB. Option 2: For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0), If it is configured for random access while not for paging in idle/inactive mode, RedCap UE does NOT expect it to contain SSB/CORESET#0/SIB. FFS: For BWP#0 configuration option 1, whether the UE can expect SSB transmission in the separate initial DL BWP when it is used in connected mode. If it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0), RedCap UE expects it to contain NCD-SSB for serving cell [FFS: or CSI-RS or measurement gap configuration] but not CORESET#0/SIB. Note: if a separate initial/RRC configured DL BWP is configured to contain the entire CORESET#0, CD-SSB is expected by RedCap UE. Note: The network may choose to configure SSB or MIB-configured CORESET#0 or SIB1 to be within the respective DL BWP. FFS: For Option 1 and Option 2, whether RedCap UE can/cannot expect SSB under certain other conditions, e.g., for SSB monitoring periodicity (i.e., SMTC configuration) and DRX cycle FFS: Whether additional mechanism for SI update or how SI update notifications and/or SI updates are signaled to RedCap UEs FFS: FR2 case RAN1#106bis-e sent an LS [37] to RAN2 and RAN4 with the following questions related to SSB transmission: [RAN2/4] whether it is feasible to use NCD-SSB for serving and non-serving cell measurements for idle, inactive, and/or connected mode for all or some of RRM, RLM, BFD, link recovery, RO selection, mobility, time/frequency tracking and AGC [RAN2/4] whether it is feasible to use NCD-SSB as QCL source of other DL channels/signals and as spatial relation (for UL channels/signals) transmitted in idle, inactive, and/or connected mode in the initial/non-initial DL BWP of RedCap UE [RAN2] whether/when the PCIs indicated by the NCD-SSB and CD-SSB can be the same/different, if both NCD-SSB and CD-SSB are transmitted on the serving cell of RedCap UE [RAN2/4] whether/when periodicities and/or TX power and/or block indexes (provided by ssb-PositionsInBurst in SIB1 or in ServingCellConfigCommon) and/or QCL sources of NCD-SSB can be same/different from those of CD-SSB, if both NCD-SSB and CD-SSB are transmitted on the serving cell of RedCap UE [RAN2/4] whether it is necessary to introduce configuration limitations for NCD-SSB (e.g., regarding frequency locations, periodicity), e.g., to ensure coexistence with legacy UEs [RAN2/4] if CD-SSB is not transmitted in the non-initial DL BWP of RedCap UE, whether it is feasible to transmit periodic CSI-RS for UE to use as an alternative of SSB in the non-initial BWP of RedCap UE or rely on UE performing RF retuning as in measurement gap outside active BWP for BWP without SSB nor CORESET#0 operation [RAN2/4] whether it is feasible for a RedCap UE to retune to a CD-SSB rather than use an NCD-SSB of larger periodicity [RAN2/4] any other potential impacts identified by RAN2/4 on support NCD-SSB for measurement RAN2#116-e has yet to reply to the LS from RAN1 but has already confirmed the following understanding of the current situation (draft notes): RAN2 confirmed understanding of the current situation: (FFS if any of the following will be included in a reply LS to RAN1) 1. For idle/inactive UEs, the concept of non-cell-defining SSB (NCD-SSB) and the corresponding procedures, i.e., measurements, cell (re-)selection, do not exist in the current RAN2 specifications. 2. For idle/inactive UEs, using NCD-SSB for measurements and cell (re-)selection would still require the UE to re-tune to the CORESET#0 for reading SIBs. 3. In connected mode, current RRC signalling allows configuring SSB-based RRM measurements on any (CD- or NCD-) SSB, but it does not allow using an NCD-SSB for RLM, BFD, link recovery, RO selection, mobility (mobility here refers to the frequency indicated in FreqDLInfo in HO command), in TCI-states or for any other functionality (other than RRM measurements). 4. It would be feasible to inform IDLE, INACTIVE and CONNECTED UEs about a NCD-SSB, however it is up to RAN1 and RAN4 to decide whether it is possible to use a NCD-SSB as QCL source. 5. According to the current RRC specification, PCIs indicated by other SSB and CD-SSB may be either the same or different if both other SSB and CD-SSB are transmitted on the serving cell. 6. PCIs indicated by the NCD-SSB and CD-SSB should be configured as same if both NCD-SSB and CD-SSB are transmitted on the serving cell. 7. According to the current RRC specification, periodicities and/or TX power and/or block indexes (provided by ssb-PositionsInBurst in SIB1 or in ServingCellConfigCommon) and/or QCL sources of other SSB may be either the same or different from those of CD-SSB, if both other SSB and CD-SSB are transmitted on the serving cell. 8. Use of CSI-RS for cell and beam RLM and measurements is already supported from RAN2 signaling standpoint. RAN4#101-e has replied to the LS from RAN1 in [38]: Question 1 [RAN2/4] whether it is feasible to use NCD-SSB for serving and non-serving cell measurements for idle, inactive, and/or connected mode for all or some of RRM, RLM, BFD, link recovery, RO selection, mobility, time/frequency tracking and AGC RAN4 answer: It is feasible to use NCD-SSB for serving and non-serving cell measurements for idle, inactive, and/or connected mode for all or some of RRM, RLM, BFD, link recovery, RO selection, mobility, time/frequency tracking and AGC. RAN4 will further study for specific conditions when it is feasible to use NCD-SSB. It is RAN4 understanding that NCD-SSB measurements support may require additional signalling which is up to RAN2. Question 2 [RAN2/4] whether it is feasible to use NCD-SSB as QCL source of other DL channels/signals and as spatial relation (for UL channels/signals) transmitted in idle, inactive, and/or connected mode in the initial/non-initial DL BWP of RedCap UE RAN4 answer: Based on the given information from RAN1 and current RAN4 understanding, it is feasible to use NCD-SSB as QCL source of other DL channels/signals and as spatial relation (for UL channels/signals) transmitted in idle, inactive, and/or connected mode in the initial/non-initial DL BWP of RedCap UE, if the NCD-SSB is QCL＊ed with the CD-SSB of UE＊s serving cell. For the case when NCD-SSB is not QCL＊ed with the CD-SSB of UE＊s serving cell, RAN4 has not reached the conclusions and recommend RAN1 to make the decision. Question 4 [RAN2/4] whether/when periodicities and/or TX power and/or block indexes (provided by ssb-PositionsInBurst in SIB1 or in ServingCellConfigCommon) and/or QCL sources of NCD-SSB can be same/different from those of CD-SSB, if both NCD-SSB and CD-SSB are transmitted on the serving cell of RedCap UE RAN4 answer: It is RAN4 agreement that: Periodicities of NCD-SSB are up to network configuration and can be same or different from those of CD-SSB, if both NCD-SSB and CD-SSB are transmitted on the serving cell of RedCap UE. Periodicity of NCD-SSB shall be not less than periodicity of CD-SSB. TX power of NCD-SSB can be same or different from those of CD-SSB If TX power is different, then UE needs to be informed on the power difference between NCD-SSB and CD-SSB It is RAN4 understanding that if power boosting is used for CD-SSB then it may not be always possible to use the same TX power for NCD-SSB. Question 5 [RAN2/4] whether it is necessary to introduce configuration limitations for NCD-SSB (e.g., regarding frequency locations, periodicity), e.g., to ensure coexistence with legacy UEs RAN4 answer: RAN4 needs to further study this question and will provide an answer later if consensus can be achieved. Question 6 [RAN2/4] if CD-SSB is not transmitted in the non-initial DL BWP of RedCap UE, whether it is feasible to transmit periodic CSI-RS for UE to use as an alternative of SSB in the non-initial BWP of RedCap UE or rely on UE performing RF retuning as in measurement gap outside active BWP for BWP without SSB nor CORESET#0 operation RAN4 answer: RAN4 has no conclusions on whether CSI-RS is a feasible alternative of SSB in the non-initial BWP of RedCap UE. It is RAN4 understanding that CSI-RS are not used as a standalone mechanism for RRM measurements and the existing requirements rely on the presence of SSB signals. Whether to support CSI-RS as an alternative to SSB is up to RAN1 decision. Question 7 [RAN2/4] whether it is feasible for a RedCap UE to retune to a CD-SSB rather than use an NCD-SSB of larger periodicity RAN4 answer: RAN4 needs to further study this question and will provide an answer later if consensus can be achieved. Question 8 [RAN2/4] any other potential impacts identified by RAN2/4 on support NCD-SSB for measurement RAN4 answer: RAN4 needs to further study this question and will provide an answer later if consensus can be achieved. The majority of the contributions agree that at least for FR1, Option 2 can be a compromise regarding the presence of SSB in the DL BWPs [4, 7, 9, 12, 15, 17, 19, 21, 24, 25, 26, 27, 28, 29]. Meanwhile, a few contributions do not support mandatory transmission of additional SSBs and prefer Option 1 [5, 11, 18]. One contribution [4] points out the significant overhead of additional SSB transmissions in FR2 and propose to support Option 1 for FR2. Meanwhile, one contribution [25] indicates that Option 2 should be supported for FR1 and FR2. Two contributions [4, 5] mention that whether RedCap UE can/cannot expect SSB could be based on conditions such as SSB monitoring periodicity (i.e., SMTC configuration), DRX cycle, and measurement gap. Moreover, related to the use of CSI-RS or measurement gap configuration instead of NCD-SSB in connected mode, the following views are presented: [4]: It may not be always feasible to use CSI-RS and/or measurement gaps instead of NCD-SSB. [17]: CSI-RS can be an alternative of NCD-SSB and has benefit in reducing network overhead. [18]: CSI-RS is used for RLM/BFD if there is no SSB transmission in the DL BWP. [27]: At least in FR1, CSI-RS should NOT be used as an alternative to SSB in RRM/BFD. Given the tight timeline for the RAN1 work, the FL would like to ask the following question even though LS replies from RAN2 and RAN4 have not been received yet, since company positions may already have been affected by the preliminary assessments described above. FL1 High Priority Question 5-1a: For FR1, which option is preferred, and which options are acceptable to you? Option 1 (defined as in the text box in the beginning of this section of this document) Option 2 (defined as in the text box in the beginning of this section of this document) Other option (please describe in the Comments field) Company Comments Template Preferred: Option X Acceptable: Option X, Y Intel Preferred: Option 2 Acceptable: Option 2. Given the discussions so far, we think Option 2 offers the best compromise and it would not be worthwhile to bring back Option 1 again. The discussions so far in RAN2 and RAN4 clearly point towards fundamental feasibility of supporting Option 2. Although we acknowledge feasibility of Option 1, we do not think this would be the right way forward towards wrapping up the WI this meeting considering the prior discussions and the current situation in RAN1. Qualcomm Un-acceptable: Option 1 Preferred: Option 2 with the following modifications Option 2: For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0), If it is configured for random access while not for paging in idle/inactive mode, RedCap UE does NOT expect it to contain SSB/CORESET#0/SIB. FFS: For BWP#0 configuration option 1, whether the UE can expect SSB transmission in the separate initial DL BWP when it is used in connected mode. If it is configured for paging and random access, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0), RedCap UE expects it to contain NCD-SSB for serving cell [FFS: or CSI-RS or measurement gap configuration] but not CORESET#0/SIB. Acceptable: Option 2 with the following modifications Option 2: For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0), If it is configured for random access while not for paging in idle/inactive mode, RedCap UE does NOT expect it to contain SSB/CORESET#0/SIB. FFS: For BWP#0 configuration option 1, whether the UE can expect SSB transmission in the separate initial DL BWP when it is used in connected mode. If it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0), RedCap UE expects it to contain NCD-SSB for serving cell [FFS: or CSI-RS or measurement gap configuration] but not CORESET#0/SIB. vivo Preferred: Option 2. (Option 1 is NOT Acceptable for us) Note that RAN4 reply LS has been endorsed in R4-2120327, which confirmed the feasibility of using NCD-SSB. HW, HiSi Preferred: Option 1 Acceptable: depending on more understanding of NCD-SSB We expect there would be comments to prefer to wait for further progress from RAN2/RAN4 and appreciate the efforts from FL to facilitate the discussion while keep an eye on other WGs. From our side at this moment, NCD-SSB used for serving cell is not available, the spec impact and performance impact is unclear (RAN4 agreeable draft LS did not seem to answer any of the performance impact, so it is un-useful for RAN1 to make decision). Existing approach relying on CSI-RS/TRS and measurement gap should be assumed. We don＊t see any issue with Option 1 and we＊d like to understand the NCD-SSB from RAN1 perspective first (as RAN2 input is pending and RAN4 draft LS seems not so useful) 每 which should not be agreed as a black-box, considering: If a separate initial DL BWP can be configured with RA without SSB in IDLE, why it is an issue for paging given that DRX is typically more than 1s and PEI can be used to tell the UE to receive PO in the separate BWP without SSB with very less frequent times; If CSI-RS/TRS can be used for IDLE and INACTIVE and is expected by UE seeking for power consumption, can that be an alternative solution in most cases What is the performance difference between NCD-SSB with large periodicity and UE performing measurement with gap with large DRX cycle and/or sparse gap pattern With clear understanding of the above, NCD-SSB can be acceptable with the following principle: It is an optional feature and its properties in terms of periodicity, power, SSB block indexes in burst, the half frame of the SS burst set, QCL relation with CD-SSB are up to gNB configuration. Option 2 would requires modifications in alternatives: Do not support separate initial DL BWP in Rel-17 for IDLE/INACTIVE If supported and configured for IDLE/INACTIVE, a RedCap UE does not expect SSB transmission (irrespective of RA and/or Paging) For connected mode, one or neither of NCD-SSB and CSI-RS/TRS is expected depend on UE capability No additional RAN1 work for NCD-SSB, e.g. mapping between NCD-SSB and RO, collision handling, QCL association rule etc. DOCOMO Preferred: Option 2 with the following modification: For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0), If it is configured for random access while not for paging in idle/inactive mode, RedCap UE does NOT expect it to contain SSB/CORESET#0/SIB. FFS: For BWP#0 configuration option 1, whether the UE can expect SSB transmission in the separate initial DL BWP when it is used in connected mode. If it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0), RedCap UE expects measurement gap configuration, but does NOT expect it to contain SSB/CORESET#0/SIB. RedCap UE expects it to contain NCD-SSB for serving cell [FFS: or CSI-RS or measurement gap configuration] but not CORESET#0/SIB. Nordic Only Option 2 is acceptable Option 1 is unacceptable and reverting existing agreements We can accept Option 2 or variants of it. For example, if idle camping (including cell reselection) would require too much work in RAN2, in R17 we propose to support IDLE paging/reselection only on CORESET#0. Sharp Preferred: Option 2 Acceptable: Option 2 According the reply from RAN2/RAN4, NCD-SSB can be used for the separate initial DL BWP. At least for paging, (NCD-)SSB is needed and option 2 is preferred to perform paging on the separate initial DL BWP. Panasonic Preferred: Option 2 Acceptable: Option 2 ZTE, Sanechips Preferred: Option 1 Acceptable: Option 2 with modification Option 2: For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0), If it is configured for random access while not for paging in idle/inactive mode, RedCap UE does NOT expect it to contain SSB/CORESET#0/SIB. FFS: For BWP#0 configuration option 1, whether the UE can expect SSB transmission in the separate initial DL BWP when it is used in connected mode. If it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0), Whether RedCap UE expects it to contain NCD-SSB/CSI-RS/TRS/measurement gap for serving cell [FFS: or CSI-RS or measurement gap configuration]depends on UE capability but not CORESET#0/SIB. Note: No additional RAN1 work for NCD-SSB, e.g. mapping between NCD-SSB and RO, collision handling, QCL association rule etc. We agree the analysis from Huawei regarding option2. Additionally, from the RAN4 agreement cited by FL, whether any specific conditions for NCD-SSB feasibility is still not clear. From RAN2 discussion, the massive spec impacts are foreseen especially when NCD-SSB is introduced in idle/inactive mode. Therefore, NCD-SSB introduction is not preferred for us in idle/inactive mode. Moreover, in legacy NR spec, CSI-RS application also depends on the UE capability. From the gNB perspective, NCD-SSB/CSI-RS/TRS/measurement gap can be configured based on UE capability. Considering the limited TU and this is the last Rel-17 meeting for RedCap, it is not expected that additional RAN1 work is introduced by the NCD-SSB. FL RAN4#101-e has replied to the LS from RAN1 in [38]. The reply is inserted earlier in this section. CATT Preferred: Option 1 Acceptable: Option 2 but only without mandating SSB when separate initial DL BWP is configured with CSS for paging. CMCC Prefer:Option1 Acceptable: modified Option 2 Option 2: For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0), If it is configured for random access while not for paging in idle/inactive mode, RedCap UE does NOT expect it to contain SSB/CORESET#0/SIB. FFS: For BWP#0 configuration option 1, whether the UE can expect SSB transmission in the separate initial DL BWP when it is used in connected mode. If it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0), RedCap UE expects it to contain NCD-SSB or CSI-RS for serving cell but not CORESET#0/SIB. As our analysis in R1-2111613, based on spec, CSI-RS can be an alternative of NCD-SSB in active DL BWP for RRM/RLM/BFD measurement, RO mapping and QCL source/spatial relation purpose. Compared with configuring additional NCD-SSB in active DL BWP, the CSI-RS resource can always be configured by network, no additional overhead is needed. FL1 High Priority Question 5-2a: For FR2, which option is preferred, and which options are acceptable to you? Option 1 (defined as in the text box for FR1 in the beginning of this section of this document) Option 2 (defined as in the text box for FR1 in the beginning of this section of this document) Other option (please describe in the Comments field) Company Comments Template Preferred: Option X Acceptable: Option X, Y Intel Preferred: Option 2 Acceptable: Option 2. Same reasons as for FR1. vivo Preferred: Option 2. The same design principles should be applied to FR1 and FR2. HW, HiSi Similar handling as FR1. DOCOMO Preferred: Option 2 (with the same modification as Question 5-1a) Nordic we could agree Option 2 at least for Pattern 1 and continue discussion on Pattern 2 and Pattern 3 Sharp Preferred: Option 2 Acceptable: Option 2 Same view with FR1 Panasonic Preferred: Option 2 Acceptable: Option 2 We see more overhead by SSB burst in FR2 than FR1. But longer NCD-SSB periodicity can be configured to mitigate the overhead. ZTE, Sanechips Preferred: Option 1 As captured in TS 38.331, the network configures the locationAndBandwidth so that the initial downlink BWP contains the entire CORESET#0 of this serving cell in the frequency domain. It is possible that the initial DL BWP for legacy UEs does not contain SSB, especially for SSB/CORESET#0 multiplexing patterns 2 and 3 in FR2. Therefore, it is not necessary to have stringent SSB acquisition requirements in FR2 and RedCap UEs can switch to the legacy CD-SSB by RF retuning when needed. Besides, since up to 64 SSBs can be transmitted in one SSB burst, the additional overhead for NCD-SSB transmission in FR2 would be more significant that in FR1. As a result, we think that the transmission of SSB in the separate initial DL BWP for RedCap UEs is up to gNB configuration. The UE shall not always expect SSB transmission in the separate initial DL BWP in FR2. Acceptable: similar as FR1. FL RAN4#101-e has replied to the LS from RAN1 in [38]. The reply is inserted earlier in this section. CATT Preferred: Option 1 Acceptable: Option 2 but only without mandating SSB when separate initial DL BWP is configured with CSS for paging. CMCC Prefer:Option1 As mentioned by Ericsson, in FR2, up to 64 SSBs may need to be transmitted (i.e., one SSB per beam), the overhead of additional SSB is significant. Thus, we prefer RedCap UE does NOT expect SSB in DL BWP. For Option 2, we have also the following FFS pertaining to BWP#0 configuration option 1: For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0), If it is configured for random access while not for paging in idle/inactive mode, RedCap UE does NOT expect it to contain SSB/CORESET#0/SIB. FFS: For BWP#0 configuration option 1, whether the UE can expect SSB transmission in the separate initial DL BWP when it is used in connected mode. A few contributions provided views on the above FFS. Two contributions [4, 26] indicate that UE should not expect SSB for BWP#0 configuration option 1, while two other contributions [15, 28] mention that UE expects SSB transmission in the separate initial DL BWP when it is used in connected mode: [4]: For BWP#0 configuration option 1, the use of initial DL BWP in connected mode is quite limited from both functionality and power saving perspectives. [4]: For BWP#0 configuration option 1, if the separate initial DL BWP is configured for random access but not for paging, then the UE does not expect SSB transmission in the separate initial DL BWP in RRC idle/inactive/connected states. [15]: For BWP#0 configuration option 1, UE expect SSB transmission in the separate initial DL BWP when it is used in connected mode. [26]: RAN1 agrees on the support of Option 2 by removing FFS for BWP#0 configuration option 1, meaning that BWP#1 with dedicated RRC configuration which includes SSB reception related configuration would be used in connected mode. [28]: For connected mode operation, if UE can expect SSB configured in an RRC configured active BWP then so should be the case in the initial DL BWP configured by configuration option 1, too. FL1 High Priority Question 5-3a: Please provide your view on the following FFS in Option 2: For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0), If it is configured for random access while not for paging in idle/inactive mode, RedCap UE does NOT expect it to contain SSB/CORESET#0/SIB. FFS: For BWP#0 configuration option 1, whether the UE can expect SSB transmission in the separate initial DL BWP when it is used in connected mode. Company Y/N Comments Intel For BWP#0 configuration option 1 is not expected have much practical relevance for RedCap use-cases. Thus, to avoid long discussions on this issue that is likely a rather corner case, we propose that BWP #0 configuration option 1 is NOT supported for RedCap. Qualcomm N If the separate initial DL BWP of idle/inactive UE is not configured with CSS for paging, it is a configuration error since the RedCap UE cannot meet the requirements for SI update and PWS notification when operating in the initial DL BWP. If the separate initial DL BWP is configured for random access but does not include SSB, it cannot meet the timeline requirements for RACH (e.g. msg1 reTX after RAR window, Clause TS 38.213) if PRACH resource re-selection is needed based on the MAC procedure defined in Clause 5 of TS 38.321. Besides, the MG for SSB will impact the RAN4 spec for UL timing requirements and RACH test requirements. To summarize, we have the following observation on the potential spec impacts of SSB-less BWP configured with CSS for RA only: vivo The FFS should be removed. In current spec, same operation/procedure is used regardless of the BWP#0 configuration options. How the separate initial DL BWP is used for RedCap UEs in connected mode, it is already covered by the following bullets in option 2 (also regardless of the BWP#0 configuration options) For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0), RedCap UE expects it to contain NCD-SSB for serving cell [FFS: or CSI-RS or measurement gap configuration] but not CORESET#0/SIB. The Intel＊s proposal above, i.e. not considering BWP#0 configuration option 1 for redcap UEs, would also be fine with us. HW, HiSi There is no need for UE to expect SSB for option 1 in connected mode, which is exactly the same as a UE in initial access after reading CD-SSB and choose to perform RA in another BWP. DOCOMO Regardless of BWP#0 configuration option 1 or 2, RedCap UE does NOT expect SSB transmission in the separate initial DL BWP. Regarding the configuration related to SSB reception in RRC connected mode, for BWP#0 configuration option 1, BWP#1 can be configured for RedCap UE with dedicated configuration related to SSB reception. Nordic Y, but This would be acceptable only for BWP configuration option 1, where BWP#1 is configured after/in MSG4 and contains CD or NCD-SSB ZTE, Sanechips For BWP#0 configuration option 1, if the separate initial DL BWP is configured for random access while not for paging, RedCap UE does not expect SSB transmission in the separate initial DL BWP in RRC idle/inactive/connected states. In connected mode, the gNB can configure the BWP containing SSB for the UE based on UE capability. Therefore, there is no need to differentiate the connected mode and idle/inactive mode. The FFS could be removed. CATT We have similar views with DOCOMO. CMCC Similar view as Huawei, FFS can be removed. SI update mechanism Another FFS identified in RAN1#106bis-e [2] concerns whether additional mechanism for SI update is needed and how SI update notifications and/or SI updates are signalled to RedCap UEs. Several contributions [4, 7, 8, 19, 24, 27, 29] discuss that in RRC connected state when the RedCap DL BWP does not contain the entire CORESET#0, RedCap UEs rely on dedicated SI delivery. Also, notification of SI update can be provided via paging DCI if the DL BWP contains the paging CSS [4, 30]. For SI update in RRC idle/inactive state when the RedCap initial DL BWP does not contain the entire CORESET#0, RedCap UEs rely on switching to CORESET#0 to acquire SI updates [4, 8, 15, 27, 30]. Based on the expressed views, the following proposal can be considered: Medium Priority Question 6-1a: What (if any) changes or clarifications are needed in order to support SI update for RedCap UEs in idle/inactive state? Company Comments Qualcomm When an idle/inactive RedCap UE operates in a separate initial DL BWP which does not contain the entire CORESET#0, the RedCap UE is not expected to periodically monitor CD-SSB, searchSpaceSIB1 and searchSpaceOtherSystemInformation associated with CORESET#0 by autonomous BWP switching. If the separate initial DL BWP of idle/inactive UE is not configured with CSS for paging, it is a configuration error since the RedCap UE cannot meet the requirements for SI update and PWS notification defined in Clause 5.2.2.2.2 of TS 38.311 when operating in the initial DL BWP. Medium Priority Question 6-2a: What (if any) changes or clarifications are needed in order to support SI update for RedCap UEs in connected state? Company Comments Qualcomm When a RedCap UE operates in an RRC-configured DL BWP which does not contain the entire CORESET#0, the RedCap UE is not expected to periodically monitor CD-SSB, searchSpaceSIB1 and searchSpaceOtherSystemInformation associated with CORESET#0 by autonomous BWP switching. SI update for RedCap UE can be provided by serving cell via dedicated RRCReconfiguration message, or by paging PDCCH transmitted within the RRC-configured BWP of RedCap UE. Upon receiving a paging PDCCH for indication of SI update or PWS notification, Type-2 BWP switch delay specified in Table 8.6.2-1 of TS 38.133 can be defined for BWP switching of RedCap UE to/from CORESET#0. Proposal: If paging PDCCH is used to indicate SI update and/or PWS notification, RAN1 needs to send an LS to RAN4 to determine the interruption time for receiving PWS notification and/or SI update outside the RRC-configured DL BWP of RedCap UE. Upon receiving paging PDCCH for indication of SI update or PWS notification in the RRC-configured BWP without CSS for SIB1/OSI, Type-2 BWP switch delay specified in Table 8.6.2-1 of TS 38.133 can be defined for BWP switching of RedCap UE to/from CORESET#0. FGs for BWP operation RAN1#105-e [2] made the following agreement related to non-initial BWP operation: Agreements: Take the following as an agreement, revised from the RAN1#104bis-e working assumption: A RedCap UE cannot be configured with a non-initial (DL or UL) BWP (i.e., a BWP with a non-zero index) wider than the maximum bandwidth of the RedCap UE. At least for FR1, FG 6-1 (※Basic BWP operation with restriction§ as described in TR 38.822) is used as a starting point for the mandatory RedCap UE type capability. This does not preclude support of FG 6-1a (※BWP operation without restriction on BW of BWP(s)§ as described in TR 38.822) as a UE capability for RedCap UEs. Several contributions provide their views on non-initial BWP operation and in particular FG 6-1a ※BWP operation without restriction on BW of BWPs§. In some of the contributions, it is proposed to make FG 6-1a mandatory for RedCap [5, 10]. In some other contributions, it is proposed to have FG 6-1a as an optional feature for RedCap [24, 27]. Meanwhile, several contributions propose to have new or modified FGs for RedCap [4, 9, 11, 14, 19]: [4]: The RedCap UE should support a new FG for BWP operation where an RRC-configured DL BWP contains SSB but not CORESET#0. [9]: Define new capabilities like FG 6-1/6-1a/6-2/6-3/6-4 to consider SSB and CORESET of CSS presence in the UE-specific DL BWP. [11]: RedCap UE should support a modified FG 6-1a, in which CORESET#0 is removed from the original FG 6-1a. [14]: FGs 6-1 and 6-1a (at least FGs 6-1) should be adapted for RedCap UEs such that RedCap UEs mandatorily support operation in active DL BWPs that may not necessarily include CORESET#0. [19]: Introducing a new UE feature for RedCap to indicate whether it supports an active BWP configured with UE-specific search space (USS) without SSB, denoting as Feature-X. This can be discussed further (possibly as part of the UE capability discussion) once the related issues discussed in other sections of this document have progressed a bit further. PUCCH transmission Regarding PUCCH (for Msg4/[MsgB] HARQ feedback) transmissions during initial access, we have the following agreement and FFSs: Agreement: FFS: What specification changes (if any) are needed to support that the network can enable/disable intra-slot PUCCH frequency hopping (FH) within the separate initial UL BWP in the PUCCH resource for HARQ feedback for Msg4/MsgB for RedCap FFS: Whether any specification changes are needed and desired in order to support multiplexing of non-FH and FH PUCCH transmissions in PUCCH resources. Disabling frequency hopping: The contributions generally agree that specification changes are required to support disabling the PUCCH FH in the PUCCH resource for HARQ feedback for Msg4/MsgB for RedCap [4, 5, 7, 8, 11, 15, 21, 23, 24, 26, 27, 29]. In particular, it needs to be specified which hop or PRB index is used for RedCap PUCCH resources when the FH is disabled. In this case, different solutions might be possible. Therefore, companies are invited to provide their comments on the specification changes needed for determining PRB indices to be used for PUCCH resources. Based on the above views, the following question can be considered. FL1 High Priority Question 8-1a: Considering minimum specification changes, how should the PRB indices for RedCap PUCCH resources (for HARQ feedback for Msg4/MsgB) with disabled FH be determined? Company Comments Intel The cell-common PUCCH resources are provided as part of separate PUCCH-ConfigCommon in the separate initial UL BWP for RedCap. For a PUCCH resource, the PRB indices can be determined as before 每 with the exception that, when FH is disabled, the location of the first hop is used for the entire PUCCH duration. With dynamic PRI and slot offset/starting symbol indications, the gNB would have sufficient degrees of freedom to indicate PUCCH resources for HARQ-Ack feedback from RedCap UEs while minimizing PUSCH resource fragmentation. Qualcomm We are open for further discussion. Minimum spec change is preferred vivo To effectively resolve the PUSCH resource fragmentation issue for non-RedCap UEs, there are two points we need to address 1, All 16 PUCCH resources for Msg4/MsgB for RedCap UEs should be put at one edge of the separate initial UL BWP. 2, Depending on the relative location between the separate initial UL BWP for RedCap and initial UL BWP for non-RedCap UEs, the lower edge or higher edge of the separate initial UL BWP for the 16 PUCCH resources should be indicated. See figure 1 below Figure 1 PRB index determination for common PUCCH resources without FH By taking into above two points, we propose following: When intra-slot PUCCH frequency hopping within the separate initial UL BWP in the PUCCH resource for HARQ feedback for Msg4/MsgB for RedCap UEs is disabled, UE determines the PRB index of the PUCCH transmission as □RB■_"BWP" ^"offset" +?r_"PUCCH" ?N_CS ?, Where, the □RB■_"BWP" ^"offset" for PUCCH resource determination of HARQ feedback for Msg4/MsgB can be down-selected from following two options Option 1: Separately configured by the NW Option 2: Reuse the values in Table 9.1.1-1 of TS 38.213 and clarify that it is the PRB offset relative to either the lower edge or higher edge which is configured by SIB1 of the separate initial UL BWP. HW, HiSi The current mechanism about the disabled PUCCH is the baseline. To provide more PUCCH capacity, all 16 PUCCH resources can be concentrated on either side of BWP depending on the configuration, if provided. DOCOMO When intra-slot PUCCH frequency hopping within the separate initial UL BWP in the PUCCH resource for HARQ feedback for Msg4/MsgB for RedCap UEs is disabled, first hop should be used, i.e., UE determines the PRB index of the PUCCH transmission as follows: □RB■_"BWP" ^"offset" +?r_"PUCCH" ?N_CS ? if ?r_"PUCCH" ?8?=0 □N_"BWP" ^"size" -1-RB■_"BWP" ^"offset" -?((r_"PUCCH" -8))?N_CS ? if ?r_"PUCCH" ?8?=1 Nordic We prefer keeping the same structure of legacy PUCCH resources, but PRBs of different hops are back-to-back in frequency. This means, we need to only set PRB locations for fist hop and second hop differently in spec. To achieve this, spec-change should be minimal, and this solution allows also multiplexing with legacy UEs. Sharp For the PUCCH capacity when the FH is disabled, 16 PUCCH resources should be available as same as non-RedCap UEs. Then, to provide all 16 PUCCH resources on same edge in the separate initial UL BWP, the condition in the current spec ※If ?r_"PUCCH" ?8?=0 or 1§ should be removed. Instead, the network should indicate which side of separate initial UL BWP is used as PUCCH resource in SIB. □RB■_"BWP" ^"offset" +?r_"PUCCH" ?N_CS ? when PUCCH resources locate at the bottom side of the separate initial UL BWP □N_"BWP" ^"size" -1-RB■_"BWP" ^"offset" -?r_"PUCCH" ?N_CS ? when PUCCH resources locate at the top side of the separate initial UL BWP. Panasonic PUCCH resource for RedCap UE in (shared or separate) initial UL BWP can be configured in the similar way to legacy. When the FH is disabled, the PRB index determined for the first hop is used for non-FH PUCCH. The network can configure to use different PRBs between FH PUCCH and non-FH PUCCH. ZTE, Sanechips If both PRB indexes of the first hop and second hop are used for PUCCH transmissions without any restriction on the indicated for RedCap UEs, PUSCH resource fragmentation will inevitably be caused. Although gNB can confine the value of for RedCap UEs to avoid PUSCH resource fragmentation, it may reduce the number of available PUCCH resources and limit the location of PDCCH for Msg4/MsgB. Therefore, it is suggested that all 16 PUCCH resources can be allocated on the edge of BWP. CATT We think DOCOMO＊s proposal is a good starting point, at least when the separate initial UL BWP is configured at the low frequency edge. All 16 PUCCH resources can be used. Further modification is also considerable to allow the formula to be applied when separate initial UL BWP is configured at the high frequency edge (i.e. similar to Sharp＊s consideration) CMCC Between PRB index of two hop, the PRB index at one side of separate initial UL BWP is used. At lower side or higher side is indicated in SIB1. PUCCH multiplexing: The contributions express different views on multiplexing of non-FH and FH PUCCH transmissions in PUCCH resources. The majority of the contributions indicate that the multiplexing can be done by a proper configuration and avoiding overlap between time-frequency resources (e.g., using different PRBs) of non-FH and FH PUCCH transmissions [4, 7, 8, 11, 14, 15, 17, 21, 23, 25, 28]. In addition, it is mentioned that such multiplexing problem for non-FH and FH PUCCH transmissions is not a new issue as it already exists for non-RedCap UEs in connected mode. Therefore, there might not be a need for any enhancements or specification changes in order to support multiplexing of non-FH and FH PUCCH transmissions in PUCCH resources. However, a few contributions [5, 19, 26] argue that two base sequences should be used for non-FH PUCCH transmissions to support multiplexing of non-FH and FH PUCCH transmissions in the same PRB. Medium Priority Question 8-2a: Are any specification changes necessary in order to support multiplexing of non-FH and FH PUCCH transmissions in PUCCH resources? If yes, please elaborate in the Comments field. Company Y/N Comments DOCOMO Y We support two base sequences generation for non-FH PUCCH transmissions to ensure the multiplexing capacity for multiplexing of non-FH and FH PUCCH transmissions. It was argued that multiplexing of non-FH and FH PUCCH issue has been already exist for non-RedCap UE while we don＊t think so. For PUCCH before dedicated PUCCH configuration, only PF0 and 1are available, and PUCCH resources are multiplexed with TDM/FDM/CS. While TD-OCC is supported for PF1 in RRC connected mode, multiplexing with TD-OCC is not supported in practice for the PUCCH before PUCCH before dedicated configuration since only OCC index 0 is used according to the current specification. On the other hand, for PUCCH resources after dedicated PUCCH configuration, they can be configured more flexibly in time/frequency domain, and also TD/FD-OCC is available for PF 1/4, then the multiplexing capacity would be larger and multiplexed more flexibly than that before dedicated configuration. We believe that the multiplexing capacity for initial access procedure is important for the system considering RedCap UEs become widespread, thus, it should be supported to ensure the multiplexing capacity between RedCap UE and non-RedCap UE. Other issues In this section, companies are invited to bring up other issues relevant for the timely completion of the RAN1 part of the Rel-17 RedCap WI, if any. Medium Priority Question 9-1a: Companies are invited to bring up other issues relevant for the timely completion of the RAN1 part of the Rel-17 RedCap WI, if any. Company Comments Qualcomm Solutions consistent with the WI objectives of UE complexity reduction and have less spec impacts in RAN1/2/4 should be prioritized for R17 RedCap UE. References [1] RP-211574 Revised WID on support of reduced capability NR devices Ericsson [2] R1-2110669 RAN1 agreements for Rel-17 NR RedCap Rapporteur (Ericsson) [3] R1-2110381 FL summary #5 on reduced maximum UE bandwidth for RedCap Moderator (Ericsson) [4] R1-2110769 Reduced maximum UE bandwidth for RedCap Ericsson [5] R1-2110801 Reduced maximum UE bandwidth Huawei, HiSilicon [6] R1-2110892 Bandwidth Reduction for RedCap UEs FUTUREWEI [7] R1-2111019 Remaining issues on reduced maximum UE bandwidth Vivo, Guangdong Genius [8] R1-2111066 Bandwidth reduction for reduced capability NR devices ZTE, Sanechips [9] R1-2111101 Discussion on aspects related to reduced maximum UE bandwidth Spreadtrum Communications [10] R1-2111129 Bandwidth Reduction for Reduced Capability Devices Nokia, Nokia Shanghai Bell [11] R1-2111262 Discussion on reduced maximum UE bandwidth CATT [12] R1-2111322 Discussion on reduced UE bandwidth OPPO [13] R1-2111403 Discussion on reduced maximum UE bandwidth for RedCap Sony [14] R1-2111501 On reduced max UE BW for RedCap Intel Corporation [15] R1-2111578 Discussion on the remaining issues of reduced UE bandwidth for RedCap Xiaomi [16] R1-2111595 Discussion on aspects related to reduced maximum UE bandwidth ASUSTeK [17] R1-2111613 Discussion on reduced maximum UE bandwidth CMCC [18] R1-2111744 UE complexity reduction Samsung [19] R1-2111880 Reduced maximum UE bandwidth for RedCap Apple [20] R1-2111957 Discussion on BWP operation for RedCap NEC [21] R1-2111963 Discussion on reduced maximum bandwidth for RedCap UEs InterDigital, Inc. [22] R1-2112006 Reduced maximum UE bandwidth for RedCap Lenovo, Motorola Mobility [23] R1-2112015 Discussion on reduced maximum UE bandwidth Sharp [24] R1-2112056 Aspects related to the reduced maximum UE bandwidth of RedCap LG Electronics [25] R1-2112084 Aspects related to reduced maximum UE bandwidth for RedCap Panasonic Corporation [26] R1-2112113 Discussion on reduced maximum UE bandwidth for RedCap NTT DOCOMO, INC. [27] R1-2112223 BW Reduction for RedCap UE Qualcomm Incorporated [28] R1-2112283 On reduced maximum bandwidth for RedCap UEs MediaTek Inc. [29] R1-2112376 On aspects related to reduced maximum UE BW Nordic Semiconductor ASA [30] R1-2111132 On other aspects of RedCap Nokia, Nokia Shanghai Bell [31] R1-2111580 Discussion on the remaining issues of higher layer related topics for RedCap Xiaomi [32] R1-2111616 Discussion on other aspects of RedCap UE CMCC [33] R1-2111923 On RedCap UE RF retuning Huawei, HiSilicon [34] R1-2111966 Considerations for initial BWP for RedCap UEs InterDigital, Inc. [35] R1-2112007 RAN1 aspects for RAN2-led features for RedCap Lenovo, Motorola Mobility [36] R1-2112225 Cross Layer Design Considerations for RedCap Device Qualcomm Incorporated [37] R1-2110600 LS on use of NCD-SSB instead of CD-SSB for RedCap UE RAN1, Ericsson [38] R4-2120327 Reply LS on use of NCD-SSB for RedCap UE RAN4, ZTE