3GPP TSG-RAN WG1 Meeting #107-e Draft R1- 2112499 e-Meeting, 11th 每 19th November 2021 Agenda Item: 8.6.1.1 Title: FL summary #3 on reduced maximum UE bandwidth for RedCap Source: Moderator (Ericsson) Document for: Discussion, Decision 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 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 are furthermore tagged FL6. The FLS for the earlier rounds of the discussion can be found in [40] 每 [41]. Follow the naming convention in this example: RedCapBwFLS3-v000.docx RedCapBwFLS3-v001-CompanyA.docx RedCapBwFLS3-v002-CompanyA-CompanyB.docx RedCapBwFLS3-v003-CompanyB-CompanyC.docx If needed, you may ※lock§ a spreadsheet file for 30 minutes by creating a checkout file, as in this example: Assume CompanyC wants to update RedCapBwFLS3-v002-CompanyA-CompanyB.docx. CompanyC uploads an empty file named RedCapBwFLS3-v003-CompanyB-CompanyC.checkout CompanyC checks that no one else has created a checkout file simultaneously, and if there is a collision, CompanyC tries to coordinate with the company who made the other checkout (see, e.g., contact list below). CompanyC then has 30 minutes to upload RedCapBwFLS3-v003-CompanyB-CompanyC.docx If no update is uploaded in 30 minutes, other companies can ignore the checkout file. Note that the file timestamps on the server are in UTC time. In file names, please use the hyphen character (not the underline character) and include ＆v＊ in front of the version number, as in the examples above and in line with the general recommendation (see slide 10 in R1-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. FL6 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 Xiaomi Qin MU muqin@xiaomi.com MediaTek Mohammed Al-Imari mohammed.al-imari@mediatek.com LG Electronics Jay KIM Jaehyung.kim@lge.com FUTUREWEI Vip Desai vipul.desai@futurewei.com Ericsson Sandeep Narayanan Kadan Veedu sandeep.narayanan.kadan.veedu@ericsson.com Nokia Rapeepat Ratasuk rapeepat.ratasuk@nokia-bell-labs.com NEC Takahiro Sasaki takahiro.sasaki@nec.com OPPO Weijie xu xuweijie@oppo.com Spreadtrum Huayu Zhou huayu.zhou@unisoc.com Apple Hong He hhe5@apple.com China Telecom Jing Guo guojing6@chinatelecom.cn Samsung Feifei Sun feifei.sun@samsung.com Vodafone Diogo Martins diogo.martins@vodafone.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. Xiaomi Option 1 MediaTek Option 1 LGE Option 1 FUTUREWEI clarification We want to ensure any agreements for proposal 4-2a are not complicated by this proposal. For TDD alignment (question 4-2a), several companies are supportive of 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. In this case, we are unclear if there is an additional separate initial UL BWP that is center frequency aligned to the separate initial DL BWP but it is not used for random access. If this is possible, then it seems there are up to two separate initial UL BWPs. We note that only one separate initial UL BWP is active at a time. Ericsson Option 1 is preferred In our view, the motivation for configuring two initial UL BWPs for RedCap is not clear. In general, configuring two initial UL BWPs for RedCap UEs makes the coexistence of RedCap and non-RedCap more complicated. It can potentially have the following drawbacks: 1) PUSCH resource fragmentation (e.g., when the two initial UL BWPs are configured as in the figure below), 2) May need corresponding DL BWP configuration in TDD (in case center frequency alignment is preferred), 3) May increase overhead and reduce spectral/energy efficiency. Regarding RO sharing between RedCap and non-RedCap, it is not necessary to share (or configure) all 8 FDM-ed ROs if the total BW of ROs exceeds the RedCap UE BW. Furthermore, sufficient capacity can still be achieved with less than 8 FDM-ed RACH occasions (e.g., 4 FDM-ed RACH occasions) and multiplexing in the time domain can be used to increase PRACH capacity if needed. Nokia, NSB Option 1 NEC Option 1 Lenovo, Motorola Mobility Option 1 FL2 Based on the received responses, the following proposal can be considered. High Priority Proposal 2-1b: In Rel-17, up to 1 separate initial UL BWP for RedCap can be configured. OPPO Option 2 If separate initial UL BWP is used for cover the ROs that span outside of 20MHz, or it is used to cover PUCCH resources, at least 2 initial UL BWP are needed. So we support option 2. Vivo Y Fine with the proposal. Apple Y Support the proposal China Telecom Y We are fine with up to 1 separate initial UL BWP for Rel-17 RedCap. Multiple separate initial UL BWPs can be further discussed in Rel-18. NEC Y Panasonic Y Samsung Y We think option 2 might be beneficial, while option 1 has no issue to work. Considering this is the last meeting, and for the sake of progress, we are fine with option 1. CATT Y For progress. DOCOMO Y LGE Y IDCC Y MediaTek Y Vodafone Y OK CMCC Y Nordic Y Xiaomi Y ZTE, Sanechips Y FUTUREWEI Y Can accept with the understanding that it does not prevent later agreement of versions of question 4-2a Intel Y Nokia, NSB Y Ericsson Y Qualcomm Y FL5 The following agreement was endorsed via email 16th November 2021: Agreement: In Rel-17, up to 1 separate initial UL BWP for RedCap can be configured. 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. Xiaomi We prefer to discuss this proposal later when there is outcome of the feasibility of NCD-SSB MediaTek N We prefer to wait until the discussion on the NCD-SSB is progressed. LGE Y It is up to network 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. FUTUREWEI In our understanding, there are many combinations of MIB-configured CORESET#0, SIB-configured DL BWP (for non-RedCap UEs), and separate initial DL BWP (e.g., proposal 3-2a). Then include active/idle/inactive states, and during initial access. The nested working assumptions do not address all these combinations. We should return to this proposal once other questions are resolved. Ericsson Y, with minor changes The possibility of configuring a separate initial DL BWP for RedCap should be supported for both FR1 and FR2. The last sub-bullet could be applicable for both FR1 and FR2. It could be clarified that ※It§ in the last sub-bullet refers to frequency domain location and bandwidth. Therefore, we propose he following clarification: Working assumption: The locationAndBandwidth applies at least after initial access for FR1 and FR2 when MIB configured CORESET#0 is included Nokia, NSB Y We also suggest the following modifications 每 It can be used during initial access at least when MIB configured CORESET#0 is not included It applies at least after initial access for FR1 when MIB configured CORESET#0 is included NEC Y Lenovo, Motorola Mobility Y We are fine to confirm this WA. When/how the separate initial DL BWP is used for initial access and when/how to use it after initial access depends on discussions for other questions. FL2 Based on the received responses, the following updated proposal can be considered, where the working assumption for the main body is confirmed, and the working assumption in the first sub-bullet is modified, and the working assumption in the last sub-bullet is reverted. The working assumption in the first sub-bullet can be revisited after the proposals in Section 5 (※SSB transmission§) have seen further progress. High Priority Proposal 3-1b: The working assumptions related to the separate initial DL BWPs for RedCap are replaced with the following agreement and working assumption: Working assumption: For both FR1 and FR2, 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 OPPO Y vivo Suggest to wait Whether a separate initial BWP can be used after initial access depends on the discussion of NCD-SSB, therefore suggest to keep the main bullet as working assumption and confirm it later. Spreadtrum Y Apple N We can be ok to confirm the original working assumption without any change. However, the modified version is NOT ok for us due to the following reasons: The original working assumption for ＆during initial access＊ covers two cases, Case 1: Initial DL BWP includes MIB configured CORESET #0 Case 2: Initial DL BWP does not include MIB configured CORESET #0 For case 1, initial DL BWP obviously can be used during initial access. For case 2, we are willing to compromise to use initial DL BWP during initial access due to less frequent event of initial access procedure. Therefore, we cannot understand the logic behind to support Case 2 but leave Case 1 as FFS. Instead, the original working assumption should be confirmed to cover both Case 1 and Case 2. On the 2nd working assumption, this is the core part of this set of sentences to limit that initial DL BWP for Redcap can be used after initial access on condition that MIB-configured CORESET is included in it. Since CORESET#0 also covers CD-SSB, this working assumption ensures that initial DL BWP can be used after initial access only for the case that it covers CD-SSB. If it would be removed and keeping the 2nd sub-bullet only i.e., ＆It can be used after initial access＊, it essentially means that UE is required to support initial DL BWP after initial access even it does not include CORESET#0 and not cover CD-SSB, which is exactly what we debated last meeting and why we added the last sub-bullet. This definitely should NOT be removed. China Telecom Y We are fine to confirm this working assumption for both FR1 and FR2. NEC Y Panasonic Y Samsung Y with modification In our understanding, this proposal only covers a general case for separate iDL BWP, i.e, when iDL BWP for non-RedCap is larger than max BW of RedCap UE. Therefore, it is good to clarify it a little bit. For both FR1 and FR2, for a cell that allows a RedCap UE to access, network can configure a separate initial DL BWP for RedCap UEs in SIB at least when initial DL BWP for non-RedCap UEs is wider than maximum RedCap UE bandwith. CATT Y Also OK to comeback after more progress on SSB issues in Section 5 is achieved. DOCOMO Y IDCC Y MediaTek N Should wait until the discussion on the NCD-SSB is progressed. CMCC Y Nordic N We cannot support offloading without NCD-SSB. Xiaomi N Firstly, we share similar view with vivo and MTK . The WA should be confirmed until there is conclusion for the feasibility of NCD-SSB Secondly, we prefer to keep the last bullet. ZTE, Sanechips Y Further, remove ＆at least when MIB configured CORESET#0 is not included. ＊ is also acceptable for us. FUTUREWEI Y Intel Y If it helps, we could add an FFS to the bullet on ※use after initial access§ if companies are concerned regarding presence of NCD-SSB, etc. The working assumptions related to the separate initial DL BWPs for RedCap are replaced with the following agreement and working assumption: Working assumption: For both FR1 and FR2, 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. FFS: Details of how it may be used and conditions 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 Nokia, NSB Y We prefer not to revert/delete the last working assumption, but we can accept it. Ericsson Y Qualcomm N FL3 Aspects of this proposal have been merged into Proposals 5-1c and 5-2c. FL4 Based on the received responses above and in Section 5 of this document, the following updated proposal can be considered. Discussion about cases where CD-SSB and/or CORESET#0 are not included in the separate initial DL BWP can continue in Section 5 of this document. High Priority Proposal 3-1c: The RAN1#106bis-e working assumptions related to the separate initial DL BWPs for RedCap are replaced with the following agreement: For both FR1 and FR2, for a cell that allows a RedCap UE to access, network can configure a separate initial DL BWP for RedCap UEs in SIB. At least the case when the separate initial DL BWP includes CD-SSB and the entire CORESET#0 is supported. Working assumption: It can be used during initial access at least when MIB configured CORESET#0 is not included. It can be used in idle/inactive mode (including paging) and during and 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. HW, HiSi Y CATT Partially Y Two comments: (1) Any condition for usage for paging in 2nd sub-bullet? Is it subjected to the case of the 1st sub-bullet, i.e. when separate initial DL BWP contains entire CORESET#0 and CD-SSB? (2) The condition of usage of during initial access seems captured in the last note of FL proposal 5-1d. We are fine to continue related discussion there (if any). Intel We can accept this as a new proposal and NOT as a replacement of the earlier WA. It is not very clear how much it helps since it only addresses the relatively corner case when a separate initial DL BWP is configured for RedCap but includes both CD-SSB and entire CORESET #0, but can accept this if it helps us move forward. However, the original WA (copied below for convenience) from last meeting also included the case when CD-SSB/CORESET #0 are not included in entirety within the separate initial DL BWP, and this, should not be overturned with Proposal 3-1c. 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 For instance, the above states as a WA that a separate initial DL BWP can be used during initial access, regardless of inclusion of CD-SSB and CORESET #0. Thus, if we are to agree to Proposal 3-1c, we should at least modify it to clarify that it does not revert the original WA, but only updates for the case when the separate initial DL BWP includes CD-SSB and entire CORESET #0. FUTUREWEI Y vivo Y with some modifications It is OK to make this agreement although the usefulness is not clear as commented by Intel. Huawei＊s comment (1) is valid, probably we can merge the 1st sub-bullet to the main bullet so that the scope of the entire proposal becomes clear. Qualcomm Y Sharp Y but We have similar view with Intel. We should clarify that the 3rd sub-bullet is applied to not only the 1st sub-bullet case but the case that CD-SSB and CORESET #0 are not included in the separate initial DL BWP. Otherwise, we don＊t see any progress on this aspect. Xiaomi We prefer the original version And for the current version, we have the following comments For the first sub bullet, current version only covers the case when the separate initial DL BWP include the CD-SSB and entire CORESET#0. How about other case, e.g., the separate doesn＊t contain the CD-SSB and entire CORESET#0. We also need to address these cases, as they are the base for proposal 5-1d and proposal 5-2d For the second subbullet, actually we don＊t understand the motivation when a separate initial DL BWP contains CD-SSB and CORESET#0 and the RedCap still use the separate initial DL BWP rather than the MIB-configured initial DL BWP. In our understanding, this kind of configuration preclude the possibility of multiplexing the paging of RedCap and non-RedCap together. In addition, it seems the second subbulet is contradictory with the following bullet in Proposal 5-1d Note: If a separate SIB-configured initial DL BWP for RedCap UEs contains the entire CORESET#0, the RedCap UE shall use the bandwidth and location of the CORESET#0 in DL during initial access. OPPO Y Agree with intel＊s comments. This shall be a new agreement NEC Y DOCOMO Y Samsung Proposal 5-1d is still under discussion on whether paging can be transmitted on the separated iDL BWP when it does not contain CORESET #0 and SSB. We cannot agree on the second sub-bullet. Moreover, the second sub-bullet may have some conflict with the newly added note in proposal 5-1d, which propose to use CORESET #0 other than iDL BWP during initial access. Note in proposal 5-1d: Note: If a separate SIB-configured initial DL BWP for RedCap UEs contains the entire CORESET#0, the RedCap UE shall use the bandwidth and location of the CORESET#0 in DL during initial access. We suggest to update the proposal as When applicable, it can be used in idle/inactive mode (including If paging separate iDL BWP without SSB/CORESET #0 is supported) and during and after initial access. ZTE, Sanechips Y with modification Comment1: As mentioned by CATT and Intel, for the first sub-bullet and second sub-bullet, it is vague that whether the use case in the first sub-bullet is applied for the second sub-bullet, i.e., when ＆It can be used in idle/inactive mode (including paging) and during and after initial access.＊ happens, whether it is limited to the case ※when the separate initial DL BWP includes CD-SSB and the entire CORESET#0 is supported§. Therefore, it is suggested to remove the first sub-bullet or add some limitation for second sub-bullet. Comment2: Additionally, note that paging configuration issue is related to the SSB transmission. However, mandated NCD-SSB presence within the separate initial DL BWP in idle/inactive mode would cause additional NW overhead and massive specification efforts for RAN2. Besides, we see no explicit motivation for separate paging configuration within the separate initial DL BWP. Regarding the offloading purpose, the separate paging CSS can also be configured in CORESET#0 bandwidth. Therefore, considering SSB presence for paging issue is still in the discussion, the following modification is suggested: It can be used in idle/inactive mode (including paging) and during and after initial access. FFS: whether it can be used in idle/inactive mode for paging, if separate initial DL BWP does not contain the entire CORESET#0 Spreadtrum Y CMCC Y Ericsson Y The case in which the separate initial DL BWP contains both CD-SSB and CORESET #0 should be naturally supported. We are also fine with Intel＊s suggestion to clarity that this proposal does not revert the original WA. MediaTek Y with modification The 1st sub-bullet should be moved to the main bullet to make the scope of the proposal clear. FL5 The following agreement was endorsed in an online (GTW) session 16th November 2021: Agreement: For both FR1 and FR2, for a cell that allows a RedCap UE to access, network can configure a separate initial DL BWP for RedCap UEs in SIB. At least the case when the separate initial DL BWP includes CD-SSB and the entire CORESET#0 is supported It can be used in idle/inactive mode (including paging) and during and after initial access, when applicable It is no wider than the maximum RedCap UE bandwidth. This applies to both TDD and FDD (including FD FDD and HD FDD) cases. 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＊. Xiaomi N It is more flexible to leave NW decide whether configure a separate SIB-configured initial DL BWP for RedCap. If the separate SIB-configured initial DL BWP is not configured, then the RedCap could use the MIB-derived initial DL BWP when the initial DL BWP for non-RedCap is larger than RedCap＊s UE BW MediaTek If the separate iBWP is not configured, CORESET#0 BWP should be assumed by RedCap UEs. LGE N Share the view with Intel and Qualcomm. FUTUREWEI N A RedCap UE can use the MIB-configured CORESET#0 as its initial DL BWP during initial access if no SIB-configured initial BWP is configured. Ericsson N It is not necessary to always configure a separate SIB-configured initial DL BWP for RedCap if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. The RedCap UE uses the separate SIB-configured initial DL BWP (if configured), otherwise, it continues using the MIB-configured CORESET #0. Therefore, depending on the scenario, the MIB-configured CORESET #0 may be used as the initial DL BWP for RedCap. Note that, according to TS 38.213, it is not necessary to always configure an initial DL BWP in SIB1 (see below). If a UE is not provided initialDownlinkBWP, an initial DL BWP is defined by a location and number of contiguous PRBs, starting from a PRB with the lowest index and ending at a PRB with the highest index among PRBs of a CORESET for Type0-PDCCH CSS set, and a SCS and a cyclic prefix for PDCCH reception in the CORESET for Type0-PDCCH CSS set; otherwise, the initial DL BWP is provided by initialDownlinkBWP. Nokia, NSB N It is not necessary to always configure the separate initial DL BWP as the UE can use CORESET#0. NEC Y We are fine to use MIB-configured CORESET#0 if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. On the other hand, in such case, RedCap UE is barred according to RAN2 specifications as shown below. RAN1 should not discuss RAN2 specifications. We suggests RAN1 agrees to use MIB-configured CORESET#0 if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth while signalling details is up to RAN2. TS 38.331 5.2.2.4.2. 2> if the UE supports an uplink channel bandwidth with a maximum transmission bandwidth configuration (see TS 38.101-1 [15] and TS 38.101-2 [39]) which - is smaller than or equal to the carrierBandwidth (indicated in uplinkConfigCommon for the SCS of the initial uplink BWP), and which - is wider than or equal to the bandwidth of the initial uplink BWP, and 2> if the UE supports a downlink channel bandwidth with a maximum transmission bandwidth configuration (see TS 38.101-1 [15] and TS 38.101-2 [39]) which - is smaller than or equal to the carrierBandwidth (indicated in downlinkConfigCommon for the SCS of the initial downlink BWP), and which - is wider than or equal to the bandwidth of the initial downlink BWP: 2> else: 3> consider the cell as barred in accordance with TS 38.304 [20]; and 3> perform barring as if intraFreqReselection is set to notAllowed; Lenovo, Motorola Mobility Y A separate initial DL BWP is always configured when the SIB-configured initial DL BWP for non-RedCap UEs is wider than RedCap UE BW. The separate initial DL BWP can be configured to contain entire MIB-configured CORESET#0, in which case CORESET#0 is used during initial access (same as legacy). FL2 Most received responses do not think that a separate SIB-configured initial DL BWP for RedCap UEs always must be configured if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. Based on this, the following proposal can be considered. High Priority Proposal 3-2b: If a separate SIB-configured initial DL BWP for RedCap UEs is not configured when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, then the UE continues to use MIB-configured CORESET#0. OPPO Y Support Proposal 3-2b vivo Acceptable for sake of progress. Spreadtrum Y As many companies indicated, the problem is that SIB-configured ※locationAndBandwidth§ is automatically applicable for non-RedCap UEs after initial access, which is usually wider than CORESET#0. Apple Almost Yes. We suggest the following editorial change to make it more precise: If a separate SIB-configured initial DL BWP for RedCap UEs is not configured when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, then the Redcap UE continues to use MIB-configured CORESET#0. China Telecom Y In our understanding, it is no need to always configure separate SIB-configured initial DL BWP for RedCap UEs, when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. NEC Conditional If the proposal intends that MIB-configured CORESET#0 is automatically used by RedCap UE if the SIB-configured initial DL BWP for non-RedCap is larger than max. RedCap UE BW, we would not support the proposal as it conflicts with RAN2 specifications. If this does not imply signalling details (or if it is up to RAN2), we are fine with this proposal. Panasonic Y if the description is meant the network operation in principle. Our view is RedCap UE is not required to check " the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth" but RedCap UE just follows "a separate SIB-configured initial DL BWP for RedCap UEs is not configured" or not. So we support the proposal as the network operation but not support as RedCap UE behaviour. Our concern can be addressed by having the sub-bullet like following. If a separate SIB-configured initial DL BWP for RedCap UEs is not configured when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, then the RedCap UE continues to use MIB-configured CORESET#0. Note: RedCap UE just follows a separate SIB-configured initial DL BWP for RedCap UEs and not required to check whether the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. Samsung FFS We have some concerns to use CORESET #0 after initial access for the following aspects: Potential different center frequency of UL and DL for TDD, considering iUL might be seperated configured. In this case, we think PDCCH/PDSCH configuration for iDL BWP for non-redcap will be reused. However, the iDL BWP is different from CORESET #0. In order to make it work, it might lead to some restriction on the configurations, e.g., location of CORESETs. We think it is more clean to always configure a separate iDL BWP the iDL BWP for non-RedCap is larger than BW of RedCap. But of course, we need to further study the location, SSB transmission, and whether it can be used for during initial access. CATT Y Also fine with Apple＊s update. DOCOMO Y LGE The FL proposal is acceptable as a default behaviour, but the condition when the separate initial DL BWP may not be configured should be dependent on the parallel discussion on the center frequency alignment during initial access. IDCC Y MediaTek Y Vodafone Y Fine with Apple＊s update CMCC Y Nordic N Proposal is technical non-sense for BWP configuration Option 2 Xiaomi Y ZTE, Sanechips Y FUTUREWEI Y Fine with Apple＊s revision Intel Y @Nordic 每 for BWP configuration option 2, UE would be configured with initial DL BWP with locationAndBandwidth that is same as MIB-configured CORESET #0 as a UE-specific DL BWP configuration. There is nothing special about it. Again, in this case, the UE uses the rest of the configuration from iDL BWP configuration provided in SIB1 每 the only parameter determined differently is locationAndBandwidth. The latter parameter can even be perfectly aligned with MIB-indicated CORESET #0 when RedCap UE is provided with ※separate initial DL BWP§, then we have exact same configuration as what is described in the proposal. We also support the update from Apple. Nokia, NSB Y OK with update from Apple Ericsson Y This is a natural behaviour for the UE. For legacy UEs, if a separate initial DL BWP is not configured, the UE uses CORESET #0 as its default initial DL BWP. We are also fine with Apple＊s update. The decision could also made in RAN2. Qualcomm Y Support Apple＊s update FL3 Based on the received responses, the following updated proposal can be considered. Regarding the note proposed by Panasonic, the FL＊s understanding is that such a note may prevent RedCap UEs from using an initial DL BWP for non-RedCap UEs that is no wider than the maximum RedCap UE bandwidth, which is perhaps not the intention. High Priority Proposal 3-2c: If a separate SIB-configured initial DL BWP for RedCap UEs is not configured when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, then the RedCap UE continues to use at least the locationAndBandwidth of the MIB-configured CORESET#0. Signaling details are up to RAN2. vivo Acceptable for sake of progress. Qualcomm Y Spreadtrum Y The IE locationAndBandwidth for the SIB1-reconfigured initial DL BWP for non-RedCap UE may or may not wider than the max RedCap UE bandwidth, although it is assumed to be definitely wider than CORESET#0 in the R15 discussion context. We are fine for the current version that the RedCap UE should check ※the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth§. But, Panasonic＊s suggestion is also OK to ease the RedCap UE implementation. Anyway, we are fine for the signalling details are up to RAN2. NEC Y Xiaomi Partially Y In 38.213, initial DL BWP is defined as follows If a UE is not provided initialDownlinkBWP, an initial DL BWP is defined by a location and number of contiguous PRBs, starting from a PRB with the lowest index and ending at a PRB with the highest index among PRBs of a CORESET for Type0-PDCCH CSS set, and a SCS and a cyclic prefix for PDCCH reception in the CORESET for Type0-PDCCH CSS set; otherwise, the initial DL BWP is provided by initialDownlinkBWP. According to the description, the definition of initial DL BWP contains the locationAndBandwidth, SCS and the CP. In this case we think other parameters than locationAndBandwidth e.g., SCS and CP should be clarified as well. So we suggest the following update If a separate SIB-configured initial DL BWP for RedCap UEs is not configured when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, then the RedCap UE continues to use at least the locationAndBandwidth ㄛ SCS and cyclic prefix of the MIB-configured CORESET#0. Signaling details are up to RAN2. CATT Y OPPO Y but Agree with xiaomi thatit seem not so clear with ※at least the locationAndBandwidth of the§ Sharp Y We are generally OK with the FL proposal but some clarification may be needed. We think even in this case, the RedCap UE is still required to check the locationAndBandwidth in the SIB. For example, if a common CORESET is configured in the initial DL BWP, the RedCap UE would also apply the locationAndBandwidth to determine the frequency position of the common CORESET. Therefore, it should be clarified that FL proposal is not for the use of the parameter ※locationAndBandwidth§ but only for the frequency position of initial DL BWP. We think ※location and bandwidth of MIB-configured CORESET#0§ is more appropriate than ※locationAndBandwidth of the MIB-configured CORESET#0§ though it is anyway up to RAN2. Nordic Y Also fine with SCS and CP Huawei, HiSi Y Panasonic Y Thank you FL for the comments. Now we see the intention of the proposal. Besides, we support Xiaomi＊s update. MediaTek Y CMCC Y Samsung We understand the intention is to use frequency range of CORESET #0, and we can accept this for the sake of progress. However, in our understanding, SIB configured iDL BWP currently is not an optional IE in 331. That is, a network has to configure iDL BWP. Therefore, we still think there is no issue to always ask gNB to configure a iDL BWP no wider than RedCap BW. But we think RAN 2 can resolve it. DOCOMO Y ZTE, Sanechips Y We are fine with the update from Xiaomi. Additionally, from our understanding, all the parameters related to CORESET0, including the signalling for CSS for legacy non-RedCap UE also can be reused. Moreover, whether a separate signaling for RedCap specific CSS configured in CORESET0 is supported can be further discussed. Lenovo, Motorola Mobility Y Xiaomi＊s version is fine with us. FUTUREWEI Y The phrase ※locationAndBandwidth§ should be ※location and bandwidth§ based on clause 12 of 38.213. Nokia, NSB Y OK with update from Xiaomi LGE Fine for the sake of progress. IDCC Y Ericsson Y Agree with Xiaomi to add SCS and CP as well. Intel Y Fine with the updates from Xiaomi. FL4 Based on the received responses, the following updated proposal can be considered. High Priority Proposal 3-2d: If a separate SIB-configured initial DL BWP for RedCap UEs is not configured when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, then the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. Signaling details are up to RAN2. HW, HiSi Y CATT Y Intel Y FUTUREWEI Y vivo Fine for the sake of progress. Qualcomm Y Support proposal Sharp Y Xiaomi Y OPPO Y NEC Y DOCOMO Y Samsung When separate initial UL BWP is configured, it may require UE RF retuning between UL and DL during RA, which is what we want to avoid. Therefore, we still think separate iDL BWP should always be configured in this case. But if this is majority view, we can be fine for the sake of progress, by adding some constrain as: If a separate SIB-configured initial DL BWP for RedCap UEs is not configured when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, then the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. Redcap UE does not expect RF retuning during RA Signaling details are up to RAN2. ZTE, Sanechips Y Spreadtrum Y For ※the initial DL BWP for non-RedCap UEs§ and ※the MIB-configured CORESET#0§, the SCS and the CP length may be the same. For the SCS, 38.331 states they are the same. subcarrierSpacing Subcarrier spacing to be used in this BWP for all channels and reference signals unless explicitly configured elsewhere. Corresponds to subcarrier spacing according to TS 38.211 [16], table 4.2-1. The value kHz15 corresponds to ?=0, value kHz30 corresponds to ?=1, and so on. Only the values 15 kHz, 30 kHz, or 60 kHz (FR1), and 60 kHz or 120 kHz (FR2) are applicable. For the initial DL BWP this field has the same value as the field subCarrierSpacingCommon in MIB of the same serving cell. For the CP length, due to no 60kHz SCS for the initial DL BWP for non-RedCap UEs and the MIB-configured CORESET#0, there is no ECP for both. cyclicPrefix Indicates whether to use the extended cyclic prefix for this bandwidth part. If not set, the UE uses the normal cyclic prefix. Normal CP is supported for all subcarrier spacings and slot formats. Extended CP is supported only for 60 kHz subcarrier spacing. (see TS 38.211 [16], clause 4.2) Therefore, the SCS and the CP length may not be mentioned necessarily, but it is also OK to be re-addressed in the agreement. CMCC Y Ericsson Y MediaTek Y Vodafone Y FL5 Based on the received responses, the following proposal can be considered again. High Priority Proposal 3-2d: If a separate SIB-configured initial DL BWP for RedCap UEs is not configured when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, then the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. Signaling details are up to RAN2. CATT Y Intel Y FUTUREWEI Y HW, HiSi Y DOCOMO Y Nordic Y Panasonic Y CMCC Y Samsung With proposed change Same comment as last round. ??????? If a separate SIB-configured initial DL BWP for RedCap UEs is not configured when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, then the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. o?? Redcap UE does not expect RF retuning during RA o?? Signaling details are up to RAN2. vivo More discussion is needed to better understand the consequence (what is allowed, what is not allowed) if High Priority Proposal 3-2d is combined with the other proposal High Priority Proposal 4-1c as below High Priority Proposal 4-1c: For TDD, at least if there is separate initial DL BWP configured for RedCap, the center frequency of the MIB-configured CORESET#0 and the initial UL BWP may or may not be aligned for RedCap UEs. As commented over email, if the center frequencies between CORESET#0 and initial UL BWP is not aligned and if RedCap UE is not provided a separate SIB-configured initial DL BWP, do we expect that UE to continue use such misaligned BWP#0 DL and UL after initial access? We think this should not be allowed as it violates the Rel-15 assumption for TDD. Therefore propose to explicitly exclude such case by adding a sub-bullet. If a separate SIB-configured initial DL BWP for RedCap UEs is not configured when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, then the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. This is only applicable when the center frequencies between CORESET#0 and initial UL BWP for RedCap UE are aligned. Signaling details are up to RAN2. OPPO Same view as vivo. ZTE, Sanechips Y Sharp Y Ericsson Y Lenovo, Motorola Mobility We have similar concern with vivo. If the main bullet targets for both TDD and FDD, there should be ※For TDD§ in the added sub-bullet from vivo, as such If a separate SIB-configured initial DL BWP for RedCap UEs is not configured when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, then the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. For TDD, this is only applicable when the center frequencies between CORESET#0 and initial UL BWP for RedCap UE are aligned. Signaling details are up to RAN2. NEC Y Nokia, NSB Y IDCC Y FL6 Based on the received responses above and on the RAN1 email reflector, the following updated proposal can be considered. High Priority Proposal 3-2e: If a separate SIB-configured initial DL BWP for RedCap UEs is not configured when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, then the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. For TDD, RedCap UE does not expect RF retuning during random access. Signaling details are up to RAN2. Qualcomm Y MediaTek2 As this BWP can be used after initial access, there is no need to have different centre frequencies between CORESET#0 BWP and the UL BWP. Thus, we support the addition from rom vivo: This is only applicable when the center frequencies between CORESET#0 and initial UL BWP for RedCap UE are aligned. FUTUREWEI We are fine for the proposal without the TDD bullet. If we do need to go the way of a bullet on TDD, we would suggest something more similar to current specification language to say that in this case MIB-configured CORESET#0 and initial UL BWP are aligned, not that RF retuning is not expected. Based on the email discussions, it is unclear if the proposal is applicable to multiplexing patterns 2 and 3 in FR2. In this case the MIB-configured CORESET#0 does not include CD-SSB. A UE may have to retune to receive a CD-SSB. Ericsson See comments When a separate initial DL BWP is not configured (e.g., not needed for UL/DL center frequency alignment), CORESET #0 can be confined within the UL BWP in TDD (although the center of CORESET #0 may not be aligned with UL BWP). Then there is no need for re-tuning. The sub-bullet may implies that CORESET #0 and initial UL BWP must have the same center frequency. In the case above, a proper implementation at the UE will not require the UE to do retuning if the span of UL BWP and CORESET#0 is less than max RedCap UE BW. Therefore, we propose the following update: If a separate SIB-configured initial DL BWP for RedCap UEs is not configured when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, then the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. For TDD, RedCap UE does not expect RF retuning during random access. This does not mandate center frequency alignment between CORESET#0 and initial UL BWP for RedCap UEs during random access. Signaling details are up to RAN2. Apple We do not see the need of the bullet ＆For TDD, RedCap UE does not expect RF retuning during random access.＊. It is up to UE implementation where DC tone is placed. Based on the location of DC tone, UE may or may not perform RF retuning. The main proposal is enough, focusing on whether supports using CORESET#0 if the central frequency of CORESET#0 is not aligned with initial UL BWP. As commented in email thread, we are ok to support this during initial access but have concern on RRC_CONNECTED state. We therefore suggest the following revises: Revised High Priority Proposal 3-2e: If a separate SIB-configured initial DL BWP for RedCap UEs is not configured when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, then the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0 during initial access. For TDD, RedCap UE does not expect RF retuning during random access. Signaling details are up to RAN2. CATT Y If avoiding RF retuning is the main reason to mandate center frequency alignment, we really do not see much difference between the following two cases. Case 1: CORESET#0 and iUL BWP not align, within the max UE BW. Case 2: CORESET#0 and iUL BWP not align, within the max UE BW, and there is an iDL BWP aligns center frequency with iUL. In both cases, a RedCap UE is always able to find a stuitable center frequency, and RF retuning is always avoided. If the new note is not clear enough, can we: (1) consider the following modification: For TDD, RedCap UE expects CORESET#0 and (separate) initial UL BWP are contained within the maximum RedCap UE bandwidth, and is not required to perform does not expect RF retuning during and after random access within the same BWP pair. (2) or just delete it as suggested by Apple Intel Y We are also fine with the updates from Ericsson. @Apple, the sub-bullet may be fine since it just says ※UE does not expect ＃§; certainly, it can be up to UE implementation on where to place the DC tone, and whether it wants to perform RF retuning between DL and UL, but from the perspective of specifications, UE would not be required to perform RF retuning in this case between DL and UL. Samsung Y First of all, our first preference is to ALWAYS configure a separate iDL BWP for RedCap. In TS 38.331, iDL BWP is not optional in Rel-15. I know in 213 there is ※if iDL BWP is not configured..., else...§. But RAN 2 made the final call. Secondly, we still think the design principle is to avoid RF retune but not mandate CORESET 0 has the same centre frequency of iUL BWP. So, we can accept the current proposal from FL, or the modification for Ericsson, as second preference. We also understand UE vendors concern on implementation. And can be flexible to their proposal: center frequencies of COREST 0 and iUL BWP is aligned, for the sake of progress. The thing we cannot live with it: UE needs to retune during RACH. If UE can retune, we don＊t know why we debated on whether SSB is needed in separate iDL BWP, or even why we need separate iDL BWP. vivo N The added red bullet is not clear, even thought the CORESET#0 BW is confined within the UL BW, it is still possible that by some UE implementation RF retuning is required, this is similar as what Apple commented we believe. Therefore we should spell out clearly what exactly the configuration constraint and in our view the cleanest way is to say ※center frequencies between CORESET#0 and initial UL BWP for RedCap UE are aligned.§. As discussed in the email, there should not be a big issue from gNB side as such restriction can be relaxed if gNB can provide sepreate initial DL BWP configuration by SIB. The alternative proposal by Apple (restrict the main bulle to during initial access ) might work but on the other hand it does not provide clear picture on what to do for CONNECTED mode. Does it mean that UE expect that separate initial DL BWP configuration will be provided in order to enter the CONNECTED mode? If there is no consensus on how to avoid UE RF retuning, we would strongly sugges that separate initial DL BWP shall be mandatorily configured by gNB for RedCap UEs, if the initial DL BWP for non-RedCap UE is larger than the RedCap UE BW. This follows the same principle for UL initial BWP and we will not have any issue to solve in this case. 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 Xiaomi Y MediaTek Y LGE We think the last sub-bullet imposes an unnecessary restriction. There should be the cases where the separate SIB-configured initial DL BWP contains CSS for random access or paging as well as the entire CORESET#0 in which case offloading can still be achieved. FUTUREWEI N The last sub-sub-bullet is not needed Ericsson Y We are also fine with removing the last sub-bullet. 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. Nokia, NSB Y NEC Y We are fine with the proposal but ※and at least one CSS§ would not be needed. It can be left for the network configuration though if no CSS would be meaningless. Lenovo, Motorola Mobility Y We prefer to add a sub-bullet for the case when the separate initial DL BWP does not contain MIB-configured CORESET#0, 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. If it does not contain the entire CORESET#0, the RedCap UEs can still use the bandwidth and location of the CORESET#0 during initial access. FL2 Based on the received responses, the following updated proposal can be considered. The removed sub-sub-bullet can be considered again in a later proposal if desired. High Priority Proposal 3-3b: 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. OPPO Y Support Proposal 3-3b vivo Y Spreadtrum Y We are fine to remove the last sub-bullet. It seems having no impact to UE behavior at least for PDSCH frequency-domain resource allocation during initial access [38.214]: For a PDSCH scheduled with a DCI format 1_0 in any type of PDCCH common search space, regardless of which bandwidth part is the active bandwidth part, RB numbering starts from the lowest RB of the CORESET in which the DCI was received; otherwise RB numbering starts from the lowest RB in the determined downlink bandwidth part. Apple We can be ok with this Proposal. We share Qualcomm view above that: Without additional agreement, Redcap UE expects gNB to deliver SIB in an on-demand manner and there is NO UE autonomous BWP switching for CSS monitoring on CORESET#0 that is outside of Redcap-dedicated initial DL BWP. China Telecom Y We support FL proposal. NEC Y Panasonic Y Samsung FFS We think it is too early to agree on the iDL BWP ※may not§ contain CORESET #0 part, without selecting between two options. It is fine with the first sub-bullet only and remove the second sub-bullet. CATT N As mentioned before, the last sub-sub-bullet is not only because it follows the current NR principle, but also it is essential for co-existence when early indication of RedCap is done during Msg3 but not Msg1 (i.e. RO and preambles are shared). In this case, the gNB does not know there is a RedCap UE sending Msg1, but can only assume all the UEs (including non-RedCap UE and RedCap UE) are using the same bandwidth and location of CORESET#0 for Msg2 reception (i.e. following legacy mechanism), until Msg3 is received. DOCOMO Y LGE Y We support High Priority Proposal 3-3b. IDCC Y MediaTek Y as WA This should be WA as the possibility of having separate initial DL BWP without CORESET#0 and CD-SSB will depend on the discussion of NCD-SSB. CMCC Y Nordic N same comment as last time Xiaomi N We share similar view with CATT. If the last bullet is deleted, it preclude the possibility of multiplexing RAR of RedCap and non-RedCap together, that is not spectral efficient. In addition, that would mandate the early indication in Msg.1. ZTE, Sanechips Y FUTUREWEI This proposal and proposal 3-1b are very similar. They should be treated together Intel Y Nokia, NSB We prefer to keep the last sub-bullet. Ericsson Y We have some sympathy for the point raised by CATT and Xiaomi and think that it needs further discussion, but perhaps it can be addressed in a separate proposal. Qualcomm N Regardless NCD-SSB is transmitted or not in the SIB-configured initial DL BWP for RedCap UE, there are issues if the initial DL BWP of RedCap UE contains CORESET/CSS for RA but not paging. As we know, an idle UE needs to monitor paging and the CBRA of an idle UE may take a long while to finish. If the CORESET/CSS for RA and paging are in different BWPs, can NW ensure: the CSS sets for RA and paging do not overlap in time, and there is sufficient gap for BWP switching between CSS sets for RA and paging? If not, the RedCap UE may miss paging and/or msg2/4/B. Will such consequences be acceptable to NW? FL3 If needed, we can come back to this proposal once Proposals 5-1c and 5-2c have progressed further. 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. FL3 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 Qualcomm B For the sake of signaling overhead reduction in SIB, quantization for the BW of initial DL BWP (e.g. pre-defined values 24/48/96 PRBs) is preferred. vivo No strong preference. Xiaomi B If the separate initial DL BWP is configured by SIB1, limit the supported bandwidth to relieve the capacity limitation in SIB1 CATT A Assuming separate initial DL BWP will be used after initial access anyway, legacy operation is preferred. Nordic B Agree with QC, it could be determined by BW of CORESET#0A (if supported) or CommonCORESET Dedicated RRC could then provide full BW of BWP? Huawei, HiSi A This may require early indication of Msg1 enabled, while allow more resource available. Panasonic B Option B would be beneficial for the complexity reduction in the RedCap UE. Samsung Bandwidth configuration A. CORESET in iDL BWP B. Same as legacy. We think this may depend on when separate iDL BWP is configured, which BW shall be used for CSS scheduling. If a CORESET BW is used for SI/P/TC RNTI, as well as C-RNTI in corresponding CSS, as legacy using CORESET #0 BW, to reduce the DCI overhead and ensure the PDCCH coverage in CSS, there is no need to restrict the iDL BWP for RedCap. That is, iDL BWP for RedCap can be any value, which can be used for connected mode USS. In short, we suggest to discuss the BW to be used for CSS in iDL BWP first and then come back to this issue. To ensure the PDCCH coverage in idle/inactive mode, we slightly prefer to reuse current design, i.e., restrict the scheduling of a DCI in CSS to a CORESET BW, but allowing iDL BWP without restriction, for USS. Moreover, in current specification, start RB and bandwidth of a BWP are configured by RIV. It＊s better to reuse the same method for indicating separate initial DL BWP, which support all bandwidth values. And leave it to network configuration. ZTE, Sanechips A In the current specifications, the bandwidth for the configured initial DL BWP in SIB1 is not limited. The capacity limitation in SIB1 and complexity issue are not observed. Moreover, any bandwidth limitation on the separate initial DL BWP is detrimental to efficient resource utilization and gNB scheduling flexibility. FUTUREWEI A Legacy operation is preferred Nokia, NSB A Since the initial DL BWP can be used after initial access, we prefer to support all possible BW as per legacy operation. LGE A Prefer Option A unless an issue on the SIB1 size is identified. Can also comeback upon request from RAN2. IDCC A Ericsson A Option A is preferred as it provides more flexibility (due to the reasons provided by CATT and Nokia). Option A is also better choice in FR2. Intel Like Samsung, we suggest Option A (following legacy BWP locationAndBandwidth configuration) for initial DL BWP configuration, while the CORESET to map any common control (※commonCORESET§) in separate initial DL BWP is restricted to MIB-configured CORESET #0 sizes (24/48/96 PRBs). On the other hand, if the ※commonCORESET§ is restricted to be same size as the separate initial DL BWP (similar to MIB-configured CORESET #0 and initial DL BWP before RRC connection), then Option A. FL4 Based on the received responses, the following proposal can be considered. Medium Priority Proposal 3-4b: For a separate initial DL BWP for RedCap UEs, 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). HW, HiSi It may not be strictly true that the initial DL BWP can have a e.g. smaller size than CORESET#0. If there is complexity benefit with using limited set of sizes we are also fine. CATT Y To clarify, this proposal only means there is no restriction on configuration of locationAndBandwidth for separate initial DL BWP from specification point of view (except for <= max RedCap UE bandwidth). There may be other implicit limit on the configurable bandwidth of a DL BWP in current NR, e.g., a DL BWP should be no less than 6PRB, since this is the granularity of CCE. But we assume this is another story. Intel Y FUTUREWEI Y vivo Y Qualcomm We can live with this proposal, if it is the majority view in RAN1 and there is no concern in RAN2 for the signaling overhead of SIB Sharp Y Xiaomi We can accept the proposal for progress OPPO Y NEC Y DOCOMO Y Samsung Fine for sake of progress. We＊d like to further study whether restrict the BW for the DL transmission before initial access to the BW of ※common CORESET§ as in legacy. ZTE, Sanechips Y CMCC Y Ericsson Y The bandwidth and location of a SIB-configured initial DL BWP is determined based on a resource indicator value (RIV) provided in IE locationAndBandwidth in the BWP configuration (starting PRB and number of contiguous PRBs of the BWP determines the RIV value). For non-RedCap UEs the size of the BWP can be up to the maximum UE bandwidth. Similarly, 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). This provides a better configuration flexibility. MediaTek Y Vodafone Y FL5 Based on the received responses, the same proposal can be considered again. High Priority Proposal 3-4c: For a separate initial DL BWP for RedCap UEs, 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). CATT Y Intel Y FUTUREWEI Y HW, HiSi Y DOCOMO Y Nordic N I hope also legacy DCI format principles are followed For a separate initial DL BWP for RedCap UEs, 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). Reception of DCI formats in CSS follows legacy behavior DCI format depends on size of CORESET#0 Resource allocation starts at first PRB of CORESET where DCI format has been received Panasonic Y CMCC Y Samsung We are also general fine with Nordic＊s proposal, with changing CORESET #0 to ※a common CORESET§ since we support the case that the separate iDL BWP doesn＊t contain the entire MIB configured CORESET #0. For a separate initial DL BWP for RedCap UEs, 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). Reception of DCI formats in CSS follows legacy behavior DCI format depends on size of the common CORESET CORESET#0 Resource allocation starts at first PRB of CORESET where DCI format has been received vivo Y OPPO Y ZTE, Sanechips Y Sharp Y Ericsson Y Lenovo, Motorola Mobility Y NEC Y Nokia, NSB Y IDCC Y FL6 Based on the received responses, the following updated proposal can be considered. High Priority Proposal 3-4d: For a separate initial DL BWP for RedCap UEs, 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). Reception of DCI formats in CSS follows legacy behavior. DCI format depends on size of the common CORESET. Resource allocation starts at first PRB of CORESET where DCI format has been received. Qualcomm We agree with the first sub-bullet on FDRA of the separate initial DL BWP. For the second sub-bullet, it is unclear to us why the DCI formats should depend on the size of the common CORESET. Perhaps the proposal is about AL or the DCI field size for FDRA (which depends on ) ? FUTUREWEI N Because the size of a CORESET is a multiple of 6 RBs and the location of the first RB of a CORESET is also a multiple of 6, the size of the CORESET may be smaller than the size of the separate initial DL BWP. If the separate initial DL BWP were used after initial access, some RBs cannot be used when receiving PDSCH scheduled by the DCIs in the CSS. Another issue is that the size of the separate initial DL BWP can be smaller than the initial UL BWP. It implies that some RBs cannot be used in the UL. If the intent of the bullets is to restrict DL scheduling during parts of the idle/inactive states, then a rephrase is needed. Ericsson See comments We are fine with the newly added sub-bullets when the separate initial DL BWP contains the entire CORESET#0. However, if the separate initial DL BWP does not contain the entire CORESET#0, it is not clear to us why the FDRA should be based on common CORESET. It would be good if the proponents could clarify. A minor update: DCI format size depends on size of the common CORESET. Apple We have similar question as Ericsson. Especially, we are wondering why the configured initial DL BWP is NOT used, instead of Common CORESET. Do we limit the number of Common CORESET is ＆1＊ only? Note that the situation of Redcap-specific initial DL BWP is different with legacy case. In legacy, COREST#0 size is used for FDRA of DCI format 1_0 because it is also used to schedule SIB information. However, for Redcap initial DL BWP, the size is part of configuration and has been known by UE after reading the SIB1 information, which can be used for FDRA determination to schedule other broadcast message. Using the size of Recap-dedicated initial DL BWP can also address the problem pointed out by Futurewei in my understanding. Unless problem is identified, we prefer the following: High Priority Proposal 3-4d: For a separate initial DL BWP for RedCap UEs, 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). Reception of DCI formats in CSS follows legacy behavior. DCI format size depends on size of the common CORESET the separate initial DL BWP for Redcap UEs. Resource allocation starts at the first PRB of the separate initial DL BWP for Redcap UEs.CORESET where DCI format has been received. CATT Y We think the current version is generally fine and aligns with current spec (38.212 as attached). - Determine DCI format 1_0 monitored in a common search space according to clause 7.3.1.2.1 where is given by - the size of CORESET 0 if CORESET 0 is configured for the cell; and - the size of initial DL bandwidth part if CORESET 0 is not configured for the cell. If it is not clear enough, we suggest the following modification. Reception of DCI formats in CSS follows legacy behavior. DCI format depends on size of the common CORESET, if provided. Otherwise, depends on the size of separate initial DL BWP. Resource allocation starts at first PRB of CORESET where DCI format has been received. We think the last bullet can be deleted, since the meaning of is clear in current spec. Intel We are fine with the first part. For the second new part about DCI formats, we have similar view as others above, that DCI format size and FDRA reference should follow the separate initial DL BWP. We can discuss further on the relationship between the ※common CORESET§ and separate initial DL BWP, i.e., if they must have the same BW or common CORESET may be strictly smaller than the separate initial DL BWP, and if we decide with the former option (same BW), then the above would degenerate to ※common CORESET§ automatically. vivo Agree with the point made by Qualcomm, Ericsson, Apple, CATT. We think Apple＊s revision looks good. Samsung Y We support Ericsson＊s modification. There motivation of the second sub-bullet is to reuse current DCI format size determination and size alignement, and all the related procedure. Without this, in order to receive the DCI format 0_x in any CSS, iDL BWP shall be always contained by all the UEs. For example, there is no issue to receive Msg 3 retx/Msg 4 even in connected mode as long as the RRC configured DL BWP contains the common CORESET in (separate) iDL BWP if we follow the current design (i.e. agree on the second sub-bullet). If the whole BWP of seperate iDL BWP is used for DCI in CSS, there is no way for UE to use it in the example of the following figure. @ CATT, if there is no common CORESET, why we configure the separate iDL BWP? 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. Xiaomi We think we need to put a condition for this proposal, when there is separate initial DL BWP configured for RedCap, then it is OK to support different center frequency between the MIB-configured CORESET#0 and initial UL BWP. But on the other hand, if there is no separate initial DL BWP and RedCap would use the MIB-configured CORESET#0 both during and after initial access, in this case, the center frequency of MIB-configured CORESET#0 MUST have the same center frequency with initial UL BWP. We propose the following update: If there is separate initial DL BWP configured for RedCap, the center frequency of the MIB-configured CORESET#0 and the initial UL BWP may or may not be aligned for RedCap in TDD case MediaTek N We agree with comments from Intel. Due to the difference in the supported BW between RedCap and non-RedCap UEs, the same principle can＊t be applied. For non-RedCap UE, if the center frequencies of MIB-BW and the UL iBWP are not aligned, it doesn＊t imply that the UE will require re-tuning between UL and DL (because the total BW of UL & DL BWPs is still less than the UE supported BW). On the other hand, if the center frequencies of MIB-BW and the UL iBWP are not aligned and the total BW (of the MIB BW and the UL iBWP) is larger than the UE BW, this implies re-tuning. FUTUREWEI Y with clarification We agree with several companies that for FDD, the MIB-configured CORESET#0 and initial UL BWP do not have to be aligned in a relative sense. For TDD, there are several scenarios where the MIB-configured CORESET#0 is not aligned to the initial UL BWP (see proposal 4-2a): (1) when a separate initial DL BWP contains a MIB-configured CORESET#0; (2) when a separate initial DL BWP does not contain a MIB-configured CORESET#0 but the separate initial DL BWP is aligned to the separate initial DL BWP. Ericsson Y This is the existing case for legacy UEs as well. For example, we can have the following configuration where the center of CORESET #0 and initial UL BWP are not the same: It is also good to clarify that the proposal is for the TDD case, as pointed out by other above. Nokia, NSB Y NEC Y We assume this only applies in TDD. Lenovo, Motorola Mobility Y We share same view that in legacy, the MIB-configured CORESET#0 and the initial UL BWP may or may not center frequency aligned. RedCap UEs should follow this principle. FL2 Based on the received responses, the following updated proposal can be considered. Note that there is already a RAN1#106bis-e agreement that ※For TDD, center frequencies are assumed to be the same for the initial DL and UL BWPs used during random access for RedCap UEs§, so it does not seem to be necessary to update this proposal to address that aspect. High Priority Proposal 4-1b: For TDD, the center frequency of the MIB-configured CORESET#0 and the initial UL BWP may or may not be aligned for RedCap UEs. This corresponds to legacy behavior. OPPO Share similar understanding with intel/MTK/xiaomi. In addition, as discussed in our contribution, TDD channel reciprocity can＊t be guaranteed any more thus there would be performance loss for the TDD system if different centre frequencies are used for initial DL BWP and the initial UL BWP. This will degrade the system performance. So, we shall consider whether the pains really could cover the gains. Vivo We are fine with the proposal for progress. Spreadtrum Yes, but we are not sure about whether it is the legacy behavior and whether the figure shown by E/// is valid for the legacy UE. It was discussed in RAN1#95 in R15 [R1-1813988], but there was no consensus and no spec update, so we understand the alignment is still in the spec. In the RAN1#95 discussion [R1-1812183], HW shown the alignment and misalignment both. According to the current spec, we think the spec supports the left figure. Therefore, we suggest removing the sub-bullet currently. This corresponds to legacy behavior. China Telecom Y We support to add ※for TDD§ in FL proposal. NEC Y Samsung Y CATT Y DOCOMO We are generally fine with the proposal but share the similar view with Spreadtrum. We are not sure whether it is valid when the center frequencies of MIB-configured CORESET#0 and initial UL BWP are not aligned. Thus, we agree to remove the sub-bullet as Spreadtrum suggested. MediaTek N We can agree on having different center frequencies (between CORESET#0 and UL iBWP) if the total BW is not larger than the RedCap UE BW. This illustrated in the figure below. However, we don＊t agree on having different center frequencies (between CORESET#0 and UL iBWP) if the total BW is larger than the RedCap UE BW, as illustrated in the example below. This will require RF re-tuning between CORESET#0 and UL iBWP. CMCC Y Nordic N Same comment as before, CORESET#0 must be within BW of initial UL BWP Xiaomi N If we understand correctly, the legacy behavior mainly refers to the following agreement Agreements in RAN1#94: For Pcell, the initial DL BWP can be configured in SIB1 to be the same as or different with the initial DL BWP as initially defined by CORESET#0 The initial DL BWP configured in SIB1 includes the bandwidth of CORESET#0 If the initial DL BWP configured by SIB1 is different with the initial DL BWP as initially defined by CORESET#0, the configuration of the initial DL BWP configured by SIB1 is applicable after the initial access Therefore, the condition of center frequency misalignment between MIB-configured CORESET#0 and initial UL BWP is a SIB-configured initial DL BWP. Considering this point, we suggest the following update If there is separate initial DL BWP configured for RedCap, For TDD, the center frequency of the MIB-configured CORESET#0 and the initial UL BWP may or may not be aligned for RedCap UEs. This corresponds to legacy behavior. ZTE, Sanechips Y FUTUREWEI Y The subbullet on legacy behavior is unclear and is not needed Intel N Same reasons as before. First of all, it seems ※legacy behavior§ itself is unclear. Secondly, it is not clear if with the proposal we also need to define RF retuning gaps to allow the UE to switch between CORESET #0 and initial UL BWP. If gaps are not defined, it＊d be good to understand how UE can retune w/o any provisioned gaps in such cases, while it needs center frequency alignment between the iDL BWP and iUL BWP only if iDL BWP does NOT include CD-SSB and MIB-configured CORESET #0. In fact, given that we have agreed on center frequency alignment for TDD between iDL and iUL BWPs used for random access, we do not see a need for the proposal in the first place. Nokia, NSB Y Ericsson Y We are also fine with Xiaomi＊s update to the proposal. Qualcomm The proposal does not mention whether or not the initial DL BWP of RedCap UE contains MIB-configured CORESET#0. In our view, the configuration of separate initial UL BWP is also a main reason for the center frequency misalignment in TDD. Therefore, we suggest to clarify the FL proposal as the following: For TDD, if there is a separate initial UL and/or DL BWP configured for RedCap UE, and the initial DL BWP of RedCap UE contains the entire MIB-configured CORESET#0, the center frequency of the MIB-configured CORESET#0 and the initial UL BWP of RedCap UE may or may not be aligned for RedCap UEs. FL3 Note that there is already a RAN1#106bis-e agreement that ※For TDD, center frequencies are assumed to be the same for the initial DL and UL BWPs used during random access for RedCap UEs§ and that ※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§, so it does not seem to be necessary to update this proposal to address that aspect. Regarding Spreadtrum＊s comment, please note the following Conclusion from RAN1#98: For unpaired spectrum, the center frequencies of CORESET#0 and the initial DL/UL BWP configured by SIB1 can be the same or different. This does not change the following RAN1 agreement Agreements in RAN1#94: For Pcell, the initial DL BWP can be configured in SIB1 to be the same as or different with the initial DL BWP as initially defined by CORESET#0 The initial DL BWP configured in SIB1 includes the bandwidth of CORESET#0 If the initial DL BWP configured by SIB1 is different with the initial DL BWP as initially defined by CORESET#0, the configuration of the initial DL BWP configured by SIB1 is applicable after the initial access Based on the received responses, the following updated proposal can be considered. High Priority Proposal 4-1c: For TDD, if there is separate initial DL BWP configured for RedCap, the center frequency of the MIB-configured CORESET#0 and the initial UL BWP may or may not be aligned for RedCap UEs. This corresponds to legacy behavior. Vivo Y Qualcomm Y Spreadtrum Y We appreciate FL pointing out that there was a conclusion for misalignment b/w CORESET#0 and the SIB-reconfigured initial DL BWP for non-RedCap UE. We check RAN1#98 discussion. From the FL summary at that time, it seems 38.213 spec says the non-RedCap UE applies the wide bandwidth once locationAndBandwidth is configured by SIB1, which is different from 38.331. According to previous agreements and TS 38.331, for determination of initial DL BWP, there is condition applied according to reception of RRCSetup/RRCResume/RRCReestablishment. However in current TS 38.213, PHY procedures use unconditional language to apply the IE, i.e. if a UE is provided RRC parameter initialDownlinkBWP, initial DL BWP is provided by the parameter. The procedure for applying the RRC parameter is not reflected. However, the conclusion after RAN1#98 discussion is keeping the current spec text in 38.213. It is fine for the non-RedCap UE to apply the wider BWP than CORESET#0 once SIB1 reconfigures, but it may not be fine for the RedCap UE. The RF retuning in random access may be required, which may not be the legacy UE (non-RedCap UE) behavior. However, for the sake of progress, we can live with the current proposal. NEC Y Xiaomi Y CATT Y OPPO Y but If the intention is that the centre frequencies of the separate initial DL BWP configured for RedCap and the initial UL BWP are already the same (following RAN1#106bis-e agreement), the above proposal seems not needed. Sharp Y Nordic Y Huawei, HiSi Almost The red part in the main bullet can be clarified as if there is separate initial DL BWP configured for RedCap without containing the entire CORESET#0 Panasonic Y MediaTek Clarification is needed: Does the ※separate initial DL BWP configured for RedCap§ contain CORESET#0 or not? If it does not contain CORESET#0, then the center frequency of the MIB-configured CORESET#0 and the initial UL BWP will not be aligned anyway. So, saying ※may or may not be aligned§ doesn＊t seem correct. CMCC Y For TDD, if separate initial DL BWP is not configured for RedCap, initial DL BWP defined by CORESET#0 is used during initial access. In this case, it is possible the center frequency of CORESET#0 and the initial UL BWP is not aligned. Should we discuss this case in this proposal? Samsung Y DOCOMO Y, with clarification We can support this proposal generally. This proposal should include the case when separate initial DL BWP is not configured but separate initial UL BWP is configured, thus we suggest updating with the following modification: For TDD, if there is separate initial DL and/or UL BWP configured for RedCap, the center frequency of the MIB-configured CORESET#0 and the initial UL BWP may or may not be aligned for RedCap UEs. This corresponds to legacy behavior. ZTE, Sanechips Y Lenovo, Motorola Mobility Y The UE can still use MIB configured CORESET#0 for random access when separate initial DL BWP is configured. FUTUREWEI Y Nokia, NSB Y IDCC Y Ericsson Y Agree with Docomo to add ※and/or UL§. We note that the initial DL BWP can still contain the entire CORESET #0, but CORESET #0 may not be in the center of the initial DL BWP. Then the initial UL/DL BWPs center frequencies are aligned but CORESET #0 center frequency is not aligned with that of the initial UL BWP: Intel Y, but＃ Fine with the latest version from the FL. However, with the addition of ※and/or UL§, it is not clear if only separate initial UL BWP is configured, but not MIB-configured CORESET #0 is still used for DL, then if center frequencies for CORESET #0 and separate initial UL BWP is not aligned, then is UE expected to perform RF retuning between DL and UL during random access? FL4 Based on the received responses, the following updated proposal can be considered. Companies are invited to comment on the case when a separate initial DL BWP is not configured. High Priority Proposal 4-1c: For TDD, at least if there is separate initial DL BWP configured for RedCap, 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 CATT Y Fine with the case when separate initial DL BWP is configured. Try to understand better on the newly added ＆at least＊. According to FL Proposal 3-2d, if separate initial DL BWP is NOT configured, the RedCap UE may continuous to use CORESET#0 after initial access. In this case: (1) The center frequency of CORESET#0 and initial UL BWP (for RedCap) may not align (still legacy behavior). (2) Meanwhile, CORESET#0 and initial UL BWP should be contained within the maximum RedCap UE bandwidth, so the RedCap UE does NOT need to perform RF retuning between DL and UL BWP in the same BWP pair. Eventually, the misalignment of center frequency in (1), if any, should be small enough. If this is the motivation of adding ＆at least＊, then we would be fine. Intel Y We can accept this with the understanding that, in this case, random access related DL reception is configured in the separate initial DL BWP for RedCap UEs. Further, we＊d like to highlight that the example from Ericsson, while possible, may be somewhat of a corner case. It may be less practical to have a separate initial DL BWP configured for RedCap UEs that is much bigger than and includes COREST #0, with relative locations as in the example figure. FUTUREWEI Y vivo Y Qualcomm Y Minor suggestion for editorial changes of the proposal: For TDD, at least if there is a separate initial DL BWP configured for RedCap, the center frequencyies of the MIB-configured CORESET#0 and the initial UL BWP may or may not be aligned for RedCap UEs. Sharp Y We have similar view with CATT. For ※at least§, even when the separate initial DL BWP is not configured, it should be clarified that the RedCap UE does not perform RF retuning between downlink and uplink. Xiaomi Y Fine with QC＊s update OPPO Y With same understanding as intel. NEC Y DOCOMO In our view, for the center frequency misalignment between the MIB-configured CORESET#0 and the initial UL BWP, two possible BWP configuration should be considered in this proposal. One is that both separate initial DL and UL BWP are configured for RedCap UEs, and the other is that the separate initial DL BWP is NOT configured but separate initial UL BWP is configured for RedCap UE. Thus, we prefer to update as follows to make it clear (with a minor wording update in blue): For TDD, at least if there is separate initial DL and/or UL BWP configured for RedCap UEs, the center frequency of the MIB-configured CORESET#0 and the initial UL BWP may or may not be aligned for RedCap UEs. Samsung Y Fine with proposal 4-1c. Besides, a question for Qc, why there are multiple frequencies of CORESET #0? We don＊t agree to change to ※frequencies§. For the question from FL: ※Companies are invited to comment on the case when a separate initial DL BWP is not configured.§ㄛ Please find our comments below: Case A: when separate initial DL BWP for RedCap UE is not configured (if we agreed on proposal 3-2d without any change), and initial DL BWP bandwidth for non-RedCap UE is larger than RedCap UE capability, based on proposal 3-2d, then bandwidth of CORESET0 may be used for idle/inactive/during initial access. In this case, we think UE RF retuning between CORESET #0 and iUL BWP (assuming iUL BWP is separated configured for RedCap) shall be avoid as well. Case B: If the separate iDL BWP for Redcap is not configured and the iDL BWP for non-RedCap is not wider than RedCap BW. In this case, Redcap and non-RedCap UEs can share same iDL/iUL BWP, and the center frequency of iDL/iUL BWP is aligned, while the MIB-configured CORESET #0 may or may not aligned for iUL BWP, based on Rel-15 spec. Considering all three cases (especially case A and Case B that iDL BWP is not configured), we suggest to agree the following proposal: For TDD, when separate initial DL BWP is not configured for RedCap UE, the center frequency of the MIB-configured CORESET#0 and the initial UL BWP may or may not be aligned for RedCap UEs. Redcap UE does not expect RF retuning if there is no separate iDL BWP configured for Redcap UE ( i.e., when RedCap UE use CORESET #0 as iDL BWP frequency range.) ZTE, Sanechips Y When a separate initial DL BWP is NOT configured, the center frequency of the MIB-configured CORESET#0 and the initial UL BWP may or may not be aligned for RedCap UEs. Specifically, the case that a separate initial DL BWP is not configured means that the initial DL BWP for RedCap UEs is defined as the MIB-configured CORESET#0. In this case, 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 CORESET#0 is restricted to be placed at the carrier edge for aligning UL/DL center frequencies, which is detrimental to network scheduling flexibility. Spreadtrum Y CMCC Y For ※at least§, when the separate initial DL BWP is not configured, it is possible CORESET#0 is in the middle of carrier, separate initial UL BWP is at edge of carrier to reduce UL fragment. Ericsson Y MediaTek Our clarification question from last round of discussion is not answered yet. Does the ※separate initial DL BWP configured for RedCap§ contain CORESET#0 or not? If the separate DL iBWP does NOT contain CORESET#0, then the center frequency of the MIB-configured CORESET#0 and the initial UL BWP will not be aligned anyway. So, saying ※may or may not be aligned§ is misleading. If the separate DL iBWP contains CORESET#0, then we are fine with the center frequency of the MIB-configured CORESET#0 and the initial UL BWP to be misaligned. FL5 Based on the received responses, the same proposal can be considered again. High Priority Proposal 4-1c: For TDD, at least if there is separate initial DL BWP configured for RedCap, the center frequency of the MIB-configured CORESET#0 and the initial UL BWP may or may not be aligned for RedCap UEs. CATT Y Intel Y FUTUREWEI Y HW, HiSi Y DOCOMO Y We are fine with the proposal but the following wording is more comfortable for us as commented before: For TDD, at least if there is separate initial DL and/or UL BWP configured for RedCap UEs, the center frequency of the MIB-configured CORESET#0 and the initial UL BWP may or may not be aligned for RedCap UEs. Nordic Y, with clarification High Priority Proposal 4-1c: For TDD, at least if there is separate initial DL BWP configured for RedCap, the center frequency of the MIB-configured CORESET#0 and the initial UL BWP may or may not be aligned for RedCap UEs. Note: above separate initial DL BWP and initial UL BWP are aligned in center frequency as per previous agreement Panasonic Y CMCC Y Samsung Y vivo As commented over email, we would like to also agree on the followings together to make the whole picture clear. For TDD, 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, center frequencies are assumed to be the same for the initial DL BWP and initial UL BWP are after initial access for RedCap UEs. OPPO Share same view with vivo. ZTE, Sanechips Y We are also fine with DOCOMO＊s update. Sharp Y Ericsson Y Regarding MediaTek＊s comment in the previous round: ※If the separate DL iBWP does NOT contain CORESET#0, then the center frequency of the MIB-configured CORESET#0 and the initial UL BWP will not be aligned anyway. So, saying ※may or may not be aligned§ is misleading.§ Even in this case, there can be some special configurations in which the initial DL BWP does not contain the entire CORESET #0 but there is center frequency alignment between CORESET #0 and initial UL BWP. For example, in the figure below, where the size of MIB-configured CORESET #0 is larger the RedCap SIB-configured initial DL BWP (e.g., small DL BWP for power saving), we can have center frequency alignment between CORESET#0 and the initial UL/DL BWPs. Although such configurations are not common, they are still possible when the separate initial DL BWP for RedCap does not need to contain the entire MIB-configured CORESET#0. Therefore, we think that having ※may or may not be aligned§ in the proposal will cover all possible cases. Lenovo, Motorola Mobility Y Also fine with the updates from Nordic. NEC Y Nokia, NSB Y IDCC Y FL6 Based on the received responses, an updated proposal can be considered, which modifies the following RAN1#106bis-e agreement. Note that the updated proposal covers both FR1 and FR2. 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. High Priority Proposal 4-1d: For TDD, at least if there is separate initial DL BWP configured for RedCap UEs, the center frequency of the MIB-configured CORESET#0 and the initial UL BWP may or may not be aligned for RedCap UEs. For TDD, 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, center frequencies are assumed to be the same for the initial DL BWP and initial UL BWP are after initial access for RedCap UEs. Qualcomm Y Editorial change for the 2nd sub-bullet For TDD, center frequencies are assumed to be the same for the initial DL BWP and initial UL BWP are after initial access for RedCap UEs. MediaTek N The intention of the first bullet in the proposal is still not clear to us. We need to split it into: Separate initial DL BWP containes the entire CORESET#0 Separate initial DL BWP does not containe the entire CORESET#0 We support the last two bullets, which in our understing they aim to complete RAN1#106bis-e agreement mentioned above. FUTUREWEI Y Ericsson See comments 2nd bullet: In our understanding, this bullet implies that center frequencies for the initial DL (if it includes CD-SSB and the entire CORESET#0) and UL BWPs used during random access for RedCap UEs are not necessarily the same. Therefore, for clarity, we propose the following update: For TDD, 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. Otherwise (if it includes CD-SSB and the entire CORESET#0), the center frequencies are not necessarily the same. 3rd bullet: The frequency domain location and bandwidth of the initial DL BWP and UL BWP will be the same during and after initial access. Therefore, if the center frequency is different during initial access (as per the 2nd bullet), the center frequency will also be different after initial access. Therefore, we propose the following update: For TDD, center frequencies are assumed to be the same for the initial DL BWP DL (if it does not include CD-SSB and the entire CORESET#0) and initial UL BWP are used after initial access for RedCap UEs. Otherwise (if it includes CD-SSB and the entire CORESET#0), the center frequencies are not necessarily the same. Apple See comment We support the 2nd and 3rd proposals to align the initial DL and UL BWP during and all initial access, if they are configured for Redcap UEs. We do NOT see the need of modification from Ericsson to limit the alignment of initial DL/UL BWP for the case that it does not include CD-SSB and CORESET0. On the 1st bullet, we share views from MTK. To avoid overlapping with 2nd and 3rd propsoals, we suggest the following modification: For TDD, at least if there is separate initial DL BWP configured for RedCap UEs that includes CD-SSB, the center frequency of the MIB-configured CORESET#0 and the initial UL BWP may or may not be aligned for RedCap UEs. CATT Y Fine with the current one. For the case of relationship between CORESET#0 and initial UL BWP, we can discuss in Proposal 3-2e. Intel Y We are mostly fine with the FL proposal. For the first bullet, we are not sure if the modification from Apple is necessary, since the idea is that if separate initial DL BWP configured for RedCap, it would be to align the center frequencies of this separate initial DL BWP and the (separate) initial UL BWP, and in such a case, the center frequency of MIB-configured CORESET #0 and (separate) initial UL BWP need not be aligned, and this should hold true regardless of inclusion of CD-SSB within the separate initial DL BWP. For the changes suggested by Ericsson for the second bullet, we understand that it could follow from the observation that it may be sufficient that UE is not required to perform RF retuning between MIB-configured CORESET #0 and initial UL BWP for random access, but if UE is provided with a separate initial DL BWP that includes CD-SSB and CORESET #0, then it would still be most reasonable to align center frequencies between the entire separate initial DL BWP and the initial UL BWP. We don＊t think the update from Ericsson for the third bullet are accurate since after initial access, the UE has to operate/receive in the entire DL BWP, and thus, it is necessary to align center frequencies of the DL and UL BWPs, regardless of whether or not CD-SSB and entire CORESET #0 are included within the initial DL BWP. Samsung2 The proposals are not very helpful We like understand why one iDL BWP needs to be align with multiple UL BWPs during RACH? For TDD, 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. If the concern is from RACH in conncet mode, we think there is no issue for the following cases in RRC configured DL and UL BWP, as long as it contains common CORESET range of iDL BWP, if we follow same rule for DCI size determination and FDRA for PDSCH. For TDD, center frequencies are assumed to be the same for the initial DL BWP and initial UL BWP are after initial access for RedCap UEs. This one is also not clear, if we allow the case to use COREST 0 as the frequency range for RedCap when there is no iDL BWP for Redcap and iDL BWP for non-Redcap has wider BW. We think the motivation of the whole proposal is to Clarify that center frequencies of CORESET #0 and iUL BWP may or may not be different., as legacy Declare that for TDD, UL and DL BWP with the same bwp-id has the same center frequencies, as legacy We think the following is sufficient as a conclusion: Proposed conclusion: In case of TDD, a BWP-pair (UL BWP and DL BWP with the same bwp-Id) must have the same center frequency (same as legacy) There is no need to declare MIB-configured CORESET 0 may or may not have same center frequency or not. Proposal 3-2e should address the potential other case. vivo Y Fine with Qualcomm＊s editorial change. Ericsson＊s change on the 2nd and 3rd bullet are problematic, especially the change on the 3rd bullet, which is not acceptable as it violates the TDD frequency alignement at the UE after initial access. 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 Xiaomi Y We can live with this proposal for progress MediaTek N It is not clear to us why a UE that can support different center frequencies in the second bullet-point is not able to do so for the first bullet-point! It will be good to get some technical clarification on how these two cases are different from UE implementation perspective. We support the modified proposal from Intel. FUTUREWEI Y Ericsson Y, with minor changes By supporting different center frequencies for initial UL/DL BWPs for RedCap in TDD, the initial DL BWP can always contain CD-SSB/CORESET#0/SIB (at least in FR1). Also, note that the initial BWPs can be used in all RRC states. We propose the following update: 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 at least 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 at least during random access for RedCap UEs. Nokia, NSB Y NEC Y Lenovo, Motorola Mobility Y We understand the initial DL BWP in the second bullet is most the one defined by MIB-Configured CORESET#0. FL2 A large majority of the received responses support the proposal as is. Two responses propose to replace ※during random access§ either with ※until Msg4§ or with ※at least during random access§. Two responses propose to modify the proposal to say that ※For FR1, for TDD, the center frequencies are assumed to be the same for the initial DL and UL BWPs used during random access for RedCap UEs§, but this was already agreed in RAN1#106bis-e, with some FFSs, and this proposal is an attempt to address the FFSs. Based on the received responses, the same proposal can be considered again. High Priority Proposal 4-2b: 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. OPPO Y We can live with this proposal for sake of progress. vivo We are fine with the proposal for progress. Apple Y Although we understand the concerns from some vendors on the power consumption and complexity, we can compromise to accept this, which provides certain level of flexibility for gNB to avoid NCD-SSB always transmission in case initial UL BWP has to be pushed to the cell-edge to mitigate the PUSCH resource fragment problem. The associated power consumption at Redcap UE maybe doable as the misalignment is limited to ＆during random access＊ only. China Telecom Y We are fine with FL proposal. NEC Y Samsung We understand that in R15 the center freq of CORESET #0 and iUL BWP may not be the same. However, we think the center frequency of iDL configured in SIB and iUL are the same. Besides, we like to clarify the when combining with the agreement in RAN 1 #106b, which is the correct understanding: Interpretation #1: If iDL BWP is configured and includes CD-SSB and entire CORESET #0, the center frequency of iDL BWP is assumed to be the same with iUL BWP. In this case, UE will use CORESET #0 frequency range for DL reception during initial access. Interpretation #2: If iDL BWP is configured and includes CD-SSB and entire CORESET #0, the center frequency of iDL BWP can be different from iUL BWP. Agreement: [38.213] 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. Before we are sure to be able to down select one option over the other, we suggest to keep the door open to potential support RF retuning during initial access. For the first bullet, we suggest the following change: 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, if it is supported) and UL BWPs used during random access for RedCap UEs. CATT Y Also fine with Samsung＊s update as it is a safer and robust version. DOCOMO Y LGE N We share the same view with Intel. MediaTek N We don＊t agree with the second bullet point. Please see our explanation in the response to ※Proposal 4-1b§. CMCC Y Nordic N we cannot accept different center frequencies after MSG4 Lenovo, Motorola Mobility We share similar view Nordic. Despite RA procedure, the initial DL BWP and UL BWP should have same center frequency for RedCap UEs, no matter the initial DL BWP and UL BWP are separate configured or not. For RA procedure, the initial DL BWP and UL BWP might or might have same center frequency. If the initial DL BWPs defined by MIB-configured CORESET#0 is used for DL, the center frequency can be different between initial DL BWP and initial UL BWP. If the separate initial DL BWP is used, the center frequency should be same with the initial UL BWP. Xiaomi Y We can live with proposal for progress ZTE, Sanechips Y Intel N It is true that with our earlier suggestion (copied below), the proposal appears very similar to the earlier agreement, but not quite. 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. In fact, the above also answers the ※FFS§ points from RAN1 #106bis-e meeting and specifically says that presence of CD-SSB/CORESET #0 does NOT affect the center frequency alignment between iDL and iUL BWPs. Nokia, NSB Y Ericsson Y Qualcomm Y FL3 We can come back to this topic later once other topics have progressed further. 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 Xiaomi Y MediaTek N Please see our response to ※Proposal 4-2a§. We can support the modified proposal from Intel. FUTUREWEI Y with comments It is not clear to us that this proposal applies to multiplexing patterns 2 and 3 without additional effort, suggest adding ※at least for mux pattern 1§. Ericsson By supporting different center frequencies for initial UL/DL BWPs for RedCap in TDD, the initial DL BWP can always contain CD-SSB/CORESET#0/SIB in FR2, except for a few special cases of multiplexing pattern 2. RedCap UEs are not able to simultaneously receive SSB and CORESET #0 for one special CORESET #0/SSB multiplexing pattern in FR2, namely pattern 2 for 240 kHz SSB and 120 kHz PDCCH SCS. Based on (TS 38. 213, Table 13-10), only the cases listed in table below result in a total bandwidth larger than 100 MHz (around 126-128 MHz) which exceed the RedCap UE bandwidth in FR2. In the table, kssb is the number of subcarriers indicating SSB offset from the PRB grid. Therefore, in this case the DL BWP cannot contain both SSB and CORESET #0. We agree with the proposal for SSB/CORESET#0 multiplexing pattern 1 (if ※at least§ is added before ※random access§, as we suggested for the FR1 case). For patterns 2 and 3, the following update can be considered: 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 at least 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 at least during random access for RedCap UEs. Nokia, NSB Y NEC Y FL2 Based on the received responses, the following proposal can be considered. Companies are encouraged to provide input on how to treat multiplexing patterns 2 and 3 in the Comments field. High Priority Proposal 4-3b: For FR2, at least for SSB and CORESET#0 multiplexing pattern 1, 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. OPPO Y vivo Y Apple Y China Telecom Y NEC Y Samsung We understand that in R15 the center freq of CORESET #0 and iUL BWP may not be the same. However, we think the center frequency of iDL configured in SIB and iUL are the same. Besides, we like to clarify the when combining with the agreement in RAN 1 #106b, which is the correct understanding: Interpretation #1: If iDL BWP is configured and includes CD-SSB and entire CORESET #0, the center frequency of iDL BWP is assumed to be the same with iUL BWP. In this case, UE will use CORESET #0 frequency range for DL reception during initial access. Interpretation #2: If iDL BWP is configured and includes CD-SSB and entire CORESET #0, the center frequency of iDL BWP can be different from iUL BWP. Agreement: [38.213] 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. Before we are sure to be able to down select one option over the other, we suggest to keep the door open to potential support RF retuning during initial access. For the first bullet, we suggest the following change: For FR2, at least for SSB and CORESET#0 multiplexing pattern 1, 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, if it is supported) 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. CATT Y Also fine with Samsung＊s update as since is a safer and robust version. DOCOMO Y LGE We support the modification from Intel. MediaTek N We don＊t agree with the second bullet point. Please see our explanation in the response to ※Proposal 4-1b§. CMCC Y Nordic N we cannot accept different center frequencies after MSG4 ZTE, Sanechips Y FUTUREWEI Y Intel N Same reasons as cited in response to Proposals 4-1b and 4-2b. We do not see how presence of CD-SSB/CORESET #0 makes a difference to UE＊s handling of RF retuning between iDL/iUL BWPs such that the UE would not need any retuning gaps even when the UE may need to perform RF retuning beyond its max UE BW. Nokia, NSB Y Ericsson Y In FR2, at least for SSB/CORESET #0 multiplexing pattern 1 (where SSB and CORESET #0 are TDMed), the same proposal as that of FR1 holds. For SSB/CORESET #0 multiplexing pattern 1, if the DL BWP covers the entire CORESET #0, then it also covers the SSB. For SSB/CORESET #0 multiplexing patterns 2 and 3, since SSB and CORESET #0 are FDMed, covering the entire CORESET #0 does not necessarily imply that SSB is also covered. However, if different center frequencies for initial UL/DL BWPs are supported, then the initial DL BWP can typically be configured (with proper location and bandwidth) such that it contains both CD-SSB and CORESET #0. There are a few exceptions, which are listed in our reply to Question 4-3a above. For patterns 2 and 3, if a clarification is desired, the following can be considered: For FR2, for SSB and CORESET#0 multiplexing patterns 2 and 3, For TDD, the center frequencies are assumed to be the same for the initial DL (if it does not include both 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 both CD-SSB and the entire CORESET#0) and UL BWPs used during random access for RedCap UEs. Or equivalently: For FR2, for SSB and CORESET#0 multiplexing patterns 2 and 3, If the initial DL BWP used during random access for RedCap UEs includes CD-SSB and the entire CORESET#0, The center frequencies can be different for the initial DL and UL BWPs. Otherwise, The center frequencies are assumed to be the same for the initial DL and UL BWPs. FL3 We can come back to this topic later once other topics have progressed further. 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 replied to the LS from RAN1 in [39]: 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 Answer In connected mode, current RRC signalling allows configuring SSB-based RRM measurements on any (CD or NCD) SSB. For RLM, BFD, link recovery, RO selection, mobility, i.e., assuming that here ※mobility§ refers to the frequency indicated in FrequencyInfoDL in HO command, in TCI-states or for any other functionality (other than RRM measurements), current RRC signalling does not use NCD-SSB, however from signalling standpoint it would be feasible to inform the UE about an NCD-SSB which it shall use instead of the CD-SSB. In idle/inactive mode it would be feasible to inform UEs about an NCD-SSB from signalling standpoint. 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 and using NCD-SSB for measurements and cell (re-)selection would still require the UE to re-tune to the CORESET#0 for reading SIBs. RAN2 has different views on whether impact on specifications due to using NCD-SSB instead of CD-SSB for serving and non-serving cell measurements for idle/inactive mode, would be substantial or not and could not conclude the discussion due to limited time. 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 Answer From signalling perspective, it is feasible to inform UEs in idle, inactive and/or connected mode about an NCD-SSB. However, it is up to RAN1 and RAN4 to decide whether it is possible to use an NCD-SSB as QCL source and spatial relation. Question 3 [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 Answer According to the current RRC specification, PCIs indicated by NCD-SSB and CD-SSB may either be same or different if both NCD-SSB and CD-SSB are transmitted by the same serving cell. However, RAN2 thinks that PCIs indicated by NCD-SSB and CD-SSB should be configured as same if both NCD-SSB and CD-SSB are transmitted by the same serving cell, even though this may limit network configuration. 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 Answer 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 NCD-SSB may either be same or different from those of CD-SSB, if both NCD-SSB and CD-SSB are transmitted on the serving cell. RAN2 thinks that those parameters can only be configured differently when needed to avoid further consideration required to investigate the impact on signalling and procedures, also considering input from RAN4 on periodicity in their LS in R4-2120327. 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 Answer RAN2 could not reach consensus on whether it is necessary to introduce configuration limitations for NCD-SSB. Some companies think that NCD-SSB should not be on the sync raster and/or periodicity of NCD-SSB should be equal to or larger than that of CD-SSB whereas others think that there seems to be no need to have any limitations for configuration, other than PCI as mentioned above, or even if it is so this should be up to RAN1/4 to decide. 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 Answer Use of CSI-RS for cell and beam RLM and measurements is already supported from RAN2 signalling standpoint. Use of CSI-RS for such measurements is optional UE capability. Regarding UE re-tuning to CD-SSB and CORESET#0; it is possible for the network to allow the UE to use gaps for intra-frequency measurements however whether those gaps are needed or feasible is up to RAN4 to decide. 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 Answer From RAN2 standpoint, it is already possible for a RedCap UE to retune to a CD-SSB rather than using an NCD-SSB of larger periodicity. However, it is up to RAN1/4 to judge whether it is preferable to retune to a CD-SSB or to configure an NCD-SSB with a periodicity comparable to that of CD-SSB. Question 8 [RAN2/4] any other potential impacts identified by RAN2/4 on support NCD-SSB for measurement Answer There may be more potential impact due to the use of NCD-SSB instead of CD-SSB. This reply LS captures what RAN2 has identified at this point in time, but more discussion is needed for further consideration. 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. 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. Xiaomi Preferred: Option 2 Acceptable: Option 2 MediaTek 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 only 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. Also, if it is problematic to have NCD-SSB in the separate initial DL BWP that is configured for paging in idle mode, RAN1 can adopt the option of not having separate initial DL BWP configured for idle mode. There is no need for offloading for UEs in idle mode. LGE Preferred: Option 2 Acceptable: Option 2. FUTUREWEI Preferred: Depends on LS answers. Acceptable: Both Ericsson Preferred: Option 1 Acceptable: Option 2 Option 2 is acceptable as a compromise. We are also fine with not using separate initial DL BWP for paging, i.e., initial DL BWP is only available once the random access is initiated in idle and inactive states. Nokia, NSB Preferred: Option 1 Acceptable: Option 2 NEC Depends on LS responses. Lenovo, Motorola Mobility Preferred: Option 1 Acceptable: Option 2 FL2 Slightly more than third of the received responses (7/18) prefer Option 1. Slightly less than half (8/18) prefer Option 2, and an additional few (2/18) replied that they prefer modified versions of Option 2. Slightly more than a third (7/18) replied that they can accept Option 1. A majority (12/18) can accept Option 2, and an additional third (6/18) replied that they can accept various modified versions of Option 2. A third (6/18) expressed that they would be OK with not supporting paging in a separate initial DL BWP if it would be considered infeasible for some reason. Based on the received responses, the following proposal based on Option 2 can be considered. High Priority Proposal 5-1b: 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. Working assumption: 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), A basic RedCap UE expects it to contain NCD-SSB for serving cell [FFS: or CSI-RS or measurement gap configuration] but not CORESET#0/SIB. Working assumption: A RedCap UE can in addition optionally support operation based on CSI-RS instead of SSB in it. Working assumption: A RedCap UE can in addition optionally support operation without SSB or CSI-RS in it (RAN4 can decide a minimum measurement gap configuration if needed). 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 Company Y/N Comments OPPO Partially Y We are generally fine with the proposal. But the word ※basic§ mean? Does it mean the mandatory UE feature? vivo Generally fine with updates Based on the RAN4 LS (R4-2120327), the feasibility of using CSI-RS as alternative to SSB was not confirmed (no conclusion in RAN4), and CSI-RS cannot be used alone, meaning UE has to use CD-SSB (if NCD-SSB is not provided in the RRC configured active BWP) for timing adjustment and neighbor cell RRM which requires RF retuning anyway. Therefore it is not clear how much benefit would CSI-RS bring in this case. Consider the unclear benefit and amount of specification work required, we suggest to remove CSI-RS, i.e. updated as the following Updated proposal: 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. Working assumption: 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), A basic RedCap UE expects it to contain NCD-SSB for serving cell [FFS: or CSI-RS or measurement gap configuration] but not CORESET#0/SIB. Working assumption: A RedCap UE can in addition optionally support operation based on CSI-RS instead of SSB in it. Working assumption: A RedCap UE can in addition optionally support operation without SSB or CSI-RS in it (RAN4 can decide a minimum measurement gap configuration if needed). 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 Spreadtrum Y Does ※basic§ mean the baseline capability to support BWP operation? Apple Almost Y We support vivo＊s comment to remove the CSI-RS. Similar comment as OPPO to make ＆basic＊ clear. As one example: Introducing a new UE feature for Redcap to indicate whether it supports an active BWP without SSB. A basic RedCap UE not supporting Feature-X expects NCD-SSB in the active BWP for serving cell [FFS: or CSI-RS or measurement gap configuration] but not CORESET#0/SIB. ＃＃ NEC Share view with vivo. Panasonic Almost Y Share the view from vivo and Apple modification. Samsung N This is not acceptable for us. We need to discuss more details for option 2. For example, what NCD-SSB can be used for, RRM? RLF? BFD? Hand over? and how. Moreover, we suggest another option which basically reuse current procedure for iDL BWP, and further discuss separate iDL BWP in the future. Preferred, Option 1 Acceptable: only support the separate iDL BWP that contains CD-SSB and reuse CORESET #0 BW as legacy. CATT N If we have to compromise to Option 2, only if: (1) At least keep CSI-RS as an optional capability. (2) Remove the requirement of SSB if configured with paging CSS, or simply state that paging CSS is not configured in this case (if separate initial DL BWP does not contain CD-SSB) Otherwise, we prefer to only support the case where separate initial DL BWP must contain CORESET#0 (and SSB) DOCOMO We support to take option 2 as baseline. We still have a concern on the NCD-SSB transmission from NW overhead perspective. However, for the sake of progress, we can compromise to support the proposal that NCD-SSB can be transmitted in the RRC-configured active DL BWP in connected mode if it does not include CD-SSB and the entire CORESET#0. On the other hand, for the separate initial DL BWP, we would like to avoid NCD-SSB transmission. Considering the possible traffic pattern for RedCap UE such as infrequent communication, idle/inactive mode can be the dominant state over connected mode. If NW is forced to transmit NCD-SSB for idle/inactive mode UE, the overhead can be considerable. Therefore, we suggest transmitting NCD-SSB only in RRC connected mode. For the support of CSI-RS as captured in working assumption, we share the vivo＊s update. LGE Y (with modification) We are generally fine with the updates, but we think the two newly added working assumptions for the RRC-configured active DL BWP in connected mode should be removed. For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0), A basic RedCap UE expects it to contain NCD-SSB for serving cell [FFS: or CSI-RS or measurement gap configuration] but not CORESET#0/SIB. Working assumption: A RedCap UE can in addition optionally support operation based on CSI-RS instead of SSB in it. Working assumption: A RedCap UE can in addition optionally support operation without SSB or CSI-RS in it (RAN4 can decide a minimum measurement gap configuration if needed). Those two newly added working assumptions can be discussed separately as additional features. FL RAN2#116-e has replied to the LS from RAN1 in [39]. The reply is inserted earlier in this section. IDCC Y We are ok with the updated proposal. MediaTek Y with modifications We share the same view as vivo regarding the WA on CSI-RS. RAN4 response is that there is no confirmation on whether CSI-RS is a feasible alternative of SSB. 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. Hence, the RRM must be based on SSB (NCD-SSB in the active DL BWP or by re-tuning to the CD-SSB). So, the following WA should be removed: ※Working assumption: A RedCap UE can in addition optionally support operation based on CSI-RS instead of SSB in it.§ Given that the FFS on ※BWP#0 configuration option 1§ has been removed from updated proposal, the second bullet need to be updated to cover ※BWP#0 configuration option 1§, i.e. having the following modification: ※For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0),§ We can accept the second WA assumption as a compromise: ※Working assumption: A RedCap UE can in addition optionally support operation without SSB or CSI-RS in it (RAN4 can decide a minimum measurement gap configuration if needed)§ Vodafone Similar view as DOCOMO on the NW overhead caused by NCD-SSB transmission in idle/inactive mode. On the other hand we think measurements based on CSI-RS should be kept as optional capability as RAN4 has not reached consensus in questions 6, 7 and 8 of the reply LS CMCC The wording ＆basic＊ needs clarification. For the sake of progress, we can compromise to Option 2, but we want to keep CSI-RS as an optional capability, whether CSI-RS can replace SSB can be discussed further. Nordic We support VIVO wording Xiaomi As commented by OPPO, more clarification on the ＆basic＊ is needed And We support vivo＊s comment to remove the CSI-RS ZTE, Sanechips N Similar as Samsung and CATT, we still have the concern on the use of NCD-SSB. whether any specific conditions for NCD-SSB feasibility is still not clear, which may cause the NW more complicated and have the impact on the system robust. Currently, many usages of NCD-SSB is not supported by RAN2. There would have a big impact on the spec. The applicability of CSI-RS is supported by legacy NR. This should not be precluded in connected mode. Based on the current situation, there are lots of concern on the usage of NCD-SSB. It would be a big risk for the system and UE to mandate the NCD-SSB in connected mode and also for paging. So it is preferred that the use of NCD-SSB should not be always expected for paging and connected mode. Also, the gNB can configure the NCD-SSB or CSI-RS based on UE capability in connected mode. Intel Y Also fine with the updates from vivo. Nokia, NSB Y We can accept the proposal. Agree with others that the term basic is not clear, so suggest to remove it. Ericsson Y We are fine with not supporting paging in the separate initial DL BWP (when it does not include SSB/CORESET#0/SIB). We share CMCC＊s view that CSI-RS can be kept as an optional capability (and let RAN4 consider further whether it can replace SSB in connected mode). Qualcomm N Regardless SSB is transmitted or not in the SIB-configured separate initial DL BWP for RedCap UE, we think it is problematic for both NW and UE, if the initial DL BWP of RedCap UE contains CORESET/CSS for RA but not paging. As we know, an idle UE needs to monitor paging and the CBRA of an idle UE may take a long while to finish. If the CORESET/CSS for RA and paging are in different BWPs, can NW ensure: the CSS sets for RA and paging do not overlap in time, and there is sufficient gap for BWP switching of RedCap UE between CSS sets for RA and paging? If not, the RedCap UE may miss paging and/or msg2/4/B. Will such consequences be acceptable to NW? FL3 Proposal 5-1b was discussed during an online (GTW) session on Friday 12th November. Based on the online discussion and comments received on the RAN1 email reflector, the following updated proposal can be considered, where aspects from Proposal 3-1b have also been incorporated in the proposal. High Priority Proposal 5-1c: For FR1, For a cell that allows a RedCap UE to access, network can configure a separate initial DL 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. For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, 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. Working assumption:?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), A basic RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. A RedCap UE supporting only mandatory FG 6-1 expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. Working assumption:?A RedCap UE can in addition optionally support operation based on CSI-RS instead of SSB in it. Working assumption:?A RedCap UE can in addition optionally support operation without SSB or CSI-RS in it (RAN4 can decide a minimum measurement gap configuration if needed). 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. vivo Modification Regarding the 2nd working assumption, it is clear from RAN4 LS that CSI-RS cannot work alone, UE still has to rely SSB for proper operation. Therefore, UE supporting the 2nd working assumption will still suffer from frequent RF retuning for SSB processing if this is acceptable for some UE implementation, why not implementing the 3nd working assumption directly since such a UE can do frequent RF retuning anyway and in such case there is no need for additional CSI-RS transmission which reduces the system overhead. However, considering the spirit of compromise, we can live with the optional support of UE operation based on CSI-RS. But we should make it clear that this does not change what RAN4 is currently assuming, i.e. CSI-RS cannot work standalone. We think a note should be added to clarify this. Working assumption:?A RedCap UE can in addition optionally support operation based on CSI-RS instead of SSB in it. Note: This does not mean CSI-RS can be used as a standalone mechanism. Qualcomm For a SIB-configured RedCap-specific initial DL BWP which does not include CD-SSB and the entire CORESET#0, if CORESET/CSS is configured for RA while not for paging, we think the potential spec impacts are non-trivial for RAN2 and RAN4, regardless NCD-SSB is transmitted or not within the RedCap-specific initial DL BWP. RAN1 should send an LS to RAN2 and RAN4, to check the feasibility/spec impacts of such configurations for RA and paging. For RRC-configured active DL BWP, we support the note added by Vivo. Besides, we＊d like to suggest the following change for the 1st sub-bullet to make the description more accurate, considering the RedCap UE supporting FG 6-1 can optionally support a RRC-configured active DL BWP with NCD-SSB but without CORESET#0: For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0), A RedCap UE supporting only mandatory FG 6-1 but not optional FG 6-1a expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. Spreadtrum Y NEC According to response from RAN2 and RAN4, we are not sure if ※aspects from Proposal 3-1b§ is feasible for now. FG 6-1 may need update for RedCap UE. Xiaomi Firstly, we support vivo＊s revision and OK with QC＊s update Secondly, we have comment on the last working assumption. Since operation without CSI-RS is the baseline capability. So A RedCap UE MUST support operation without CSI-RS other than optionally support. Thus we suggest to delete the CSI-RS in this working assumption Working assumption:?A RedCap UE can in addition optionally support operation without SSB or CSI-RS in it (RAN4 can decide a minimum measurement gap configuration if needed). CATT Regarding to the newly added part, we would like to point out again (never get reply for our technical concern) that use of separate initial DL BWP for during initial access is conditional 每 only if it does not contain entire CORESET#0. Otherwise, separate initial DL BWP is mandating early indication in Msg1 (see discussion in Proposal 3-3b). Regarding to NCD-SSB for paging, we can observed from RAN2＊s reply that NCD-SSB can only replace CD-SSB in connected mode. RAN2 cannot guarantee the same use of CD-SSB and NCD-SSB in idle/inactive mode. Hence, the feasibility of using NCD-SSB for paging is not confirmed by RAN2. The first working assumption should be changed to: Working assumption:?If it is configured for paging, RedCap UE does not expects it to contain NCD-SSB for serving cell but not SSB/CORESET#0/SIB. or, simply conclude from one of the following alternatives: Alt 1: CSS for paging can NOT be configured in separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0), Alt 2: Separate initial DL BWP must contain CD-SSB if it is configured with CSS for paging. Regarding to the NCD-SSB in RRC connected mode, we are trying to find a middle ground. It may be considerable if we can handle the UE capability as a ＆must report＊ one, just similar to the capability report for processing time, i.e. the RedCap UE is required to report whether it supports operating in an active DL BWP with or without SSB. If not support (as reported), then the RedCap UE expects NCD-SSB. Regarding to the CSI-RS issue, RAN4＊s reply only confirms that it cannot be use standalone only for RRM measurement case. But according to our understanding, in many other cases, e.g. serving cell measurement, CSI-RS can be used standalone as a QCL source. We think it is reasonable to keep CSI-RS as optional capability, and for RRM it is acceptable to use RF retuning to CD-SSB. We suggest the following modification: Working assumption:?A RedCap UE can in addition optionally support operation (except for standalone use for RRM measurement) based on CSI-RS instead of SSB in it. OPPO Fine with vivo, Qualcomm and xiaomi＊s update Sharp Y We are also OK with the modification on capability by QC. Vodafone Reading RAN4＊s reply on the CSI-RS there is no mention that the CSI-RS ※cannot be used§ only as standalone, it only states that they ※are not used as a standalone mechanism§, thus it reads as the specification current status, not as precluding its usage. So, in our opinion, keeping the optional support operation based on CSI-RS seems reasonable. Nordic Nordic suggested edits Since Idle mode paging was controversial, we could agree in RAN1 at least for Connected mode paging based on LS A RedCap UE supporting only mandatory FG 6-1 expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. Note: UE supporting FG28-y does not need to support RLM/RLF/RRM based on NCD-SSB Working assumption:? FG28-x A RedCap UE can in addition optionally support operation based on CSI-RS instead of SSB in it. Working assumption:?FG28-y A RedCap UE can in addition optionally support operation without SSB or CSI-RS in it (RAN4 can decide a minimum measurement gap configuration if needed). Huawei, HiSi We consider a clearer version for the real implementation of separate DL BWP can be considered as below. The consideration for the proposal includes: there is no reason to force a UE having existing capability of FG6-1a to additionally support new procedure based on NCD-SSB for serving cell purpose (instead of for CA purpose) If we want to let the market choose then it should be put in a fair level without discouraging one of NCD-SSB and FG6-1a Given some critical aspects are being discussed in RAN2/RAN4 which has close relation with the use of NCD-SSB, we do not accept to adopt NCD-SSB in risk of being used only for the case that NCD-SSB has completely the same properties as CD-SSB in terms of periodicities, Tx power, QCL etc, since the overhead, network energy is not acceptable to us in that case. For example, if test cases are to be defined later for NCD-SSB, it must include the scenario of larger periodicity of NCD-SSB. Suggested proposal can be: For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0), A RedCap UE shall mandatorily report its support of either or both from {NCD-SSB, operation of BWP without SSB}. RAN2/RAN4 shall complete the specification/requirement work for the case of NCD-SSB has larger periodicity, lower Tx power than CD-SSB No additional spec impact from RAN1 is needed for introducing NCD-SSB, e.g. additional mapping between NCD-SSB and RO Was for CSI-RS/measurement gap is not consistent with existing UE capability or not clear. FG 1-7 (CSI-RS for RLM) is mandatory, FG 2-51 (CSI-RS for tracking) is mandatory with capability, FG 2-50 is mandatory without capability signaling and measurement gap pattern 0/1 is mandatory without capability signaling. We want to also remind that it may not be possible to use NCD-SSB as a standalone approach since the LS indicates. So given the below does not say anything implying this is a standalone approach (since ※in addition§), it can be clarified as Working assumption:?A RedCap UE can in addition optionally support relevant operation based on CSI-RS and/or measurement gap by reporting existing optional capabilities instead of SSB in it. Given RAN2/RAN4 is discussing other aspects and especially there is risk that some aspect may not be able to complete, the above, if agreed, should be sent to RAN2/RAN4 and states that RAN2/RAN4 can decide whether to support some of the items based on their progress. Panasonic Y Update from vivo and Qualcomm is OK. MediaTek Clarification is needed. By removing the following FFS from proposal ※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§, what is the common understanding now? Is the UE expects SSB transmission in the separate initial DL BWP when it is used in connected mode? We are fine with the revisions from vivo and Xiaomi. CMCC Y The main concern of an active DL BWP without SSB is that UE may have to re-tune to BWP with SSB for kinds of measurements, especially for L1 measurements, which is more frequent, resulting in higher power consumption. While CSI-RS has already be supported for RRM, RLM, Beam management, and confirmed by RAN2 LS reply, as an optional capability, so UE power consumption can be reduced with CSI-RS. We don＊t understand why it can not be supported as an optional capability if it can resolve the concern? We propose to keep the WA about CSI-RS. If additional concern is that it can not be used standalone, it can be used combined with RF retuning as in measurement gap. Since measurement gap is anyway needed for inter-frequency RRM measurement, and? CSI-RS can be used together with measurement gap for RLM, beam managements as optional capability to save UE power. And the following modified version can be considered as compromise or fine with vivo＊s modification. Working assumption: A RedCap UE can in addition optionally support operation based on CSI-RS instead of SSB in it. Working assumption: A RedCap UE can in addition optionally support operation without SSB or CSI-RS in it, RedCap UE expects CSI-RS or measurement gap to be configured in it for measurement. RAN4 can decide a minimum measurement gap configuration if needed. ? For paging on separate initial DL BWP, we think it should be configurable by gNB regardless of whether it is configured for random access or not. And for the UE capability about NCD-SSB, we also think what CATT proposes is a good compromise: UE can report a capability indicates that it support an RRC-configured active DL BWP in connected mode with or without SSB. Samsung For the connected mode part, firstly, we suggest the following changes: because there is still a case that the separate iDL BWP contains CD-SSB but not the entire CORESET #0 A RedCap UE supporting only mandatory FG 6-1 expects it to contain (CD-/NCD-) SSB for serving cell but not CORESET#0/SIB. Besides, for RedCap UE operates in a BWP without SSB or CSI-RS, we like to make it as agreement instead of working assumption. We think this is current optional feature FG 6-1a. Working assumption:?A RedCap UE can in addition optionally support operation without SSB or CSI-RS in it as FG 6-1a (RAN4 can decide a minimum measurement gap configuration if needed). Moreover, CSI-RS based RLM is mandatory feature (with capability signalling though). We would like to clarify that it will be mandatory features with no change. We like to further clarify that, the above wording means that, if a UE can support other features, e.g., FG 6-1a, it doesn＊t have to support NCD-SSB in connected mode. If this is true, we wonder for such RedCap, whether NCD-SSB in iDL BWP in inactive/idle for paging shall be mandatory supported? => We still suggest to keep paging in COREST #0 as legacy other than making it as WA. Lastly, we also share similar view with Huawei that RAN 2/4 can decide what function/features to support depends on their progress. So, the agreement is from RAN 1 perspective. DOCOMO As we commented before, we are fine to support that RedCap UE expects NCD-SSB in the RRC-configured active DL BWP as a compromise. Furthermore, while we have a concern on overhead caused by NCD-SSB transmission for RedCap UE in idle/inactive mode, we can accept the working assumption that the separate initial DL BWP is expected to contain NCD-SSB if it is configured for paging in idle/inactive mode for the sake of progress. Regarding the support of CSI-RS based operation instead of SSB for RedCap UE in connected mode captured as working assumption, we are fine to remove it if NCD-SSB reception would be the mandatory capability with separate initial DL BWP when it does not contain CD-SSB. To summarize, we can accept this proposal and the following modification can be considered (revision in red): For FR1, For a cell that allows a RedCap UE to access, network can configure a separate initial DL 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. For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, 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. Working assumption:?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), A basic RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. A RedCap UE supporting only mandatory FG 6-1 expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. Working assumption:?A RedCap UE can in addition optionally support operation based on CSI-RS instead of SSB in it. Working assumption:?A RedCap UE can in addition optionally support operation without SSB or CSI-RS in it (RAN4 can decide a minimum measurement gap configuration if needed). 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. ZTE, Sanechips We have two comments regarding the idle/inactive mode and connected mode. Comment 1: According to the RAN2 reply 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 and using NCD-SSB for measurements and cell (re-)selection would still require the UE to re-tune to the CORESET#0 for reading SIBs. RAN2 has different views on whether impact on specifications due to using NCD-SSB instead of CD-SSB for serving and non-serving cell measurements for idle/inactive mode, would be substantial or not and could not conclude the discussion due to limited time. When paging is configured for separate initial DL BWP, retuning to CORESET0 for reading SIBs can not be avoided in idle/inactive mode and mandated SSB presence in idle/inactive mode would cause the NW overhead and massive specification efforts for RAN2. Therefore, SSB is not necessary to be present in the separate initial DL BWP. Additionally, the motivation of separate paging configured in separate initial DL BWP in idle/inactive mode is offloading and there is no center frequency alignment and resource fragmentation issue observed. However, separate paging can also be configured in CORESET0 bandwidth. Given this, separate paging configured in separate initial DL BWP in idle/inactive mode is not also necessary. Based on the above analysis, the following options should be considered: 1st preference: Working assumption:?If it is configured for paging, RedCap UE does NOT expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. 2nd preference for progress: Working assumption:?If it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. Separate paging configured in separate initial DL BWP in idle/inactive mode is not supported. Comment2: For the RRC-configured active DL BWP in connected mode, the situation is optional NCD-SSB support is almost agreed in the online discussion. Considering the Huawei＊ version is more clear, we suggest to add the corresponding modification as the starting point. Lenovo, Motorola Mobility Y Also fine with the revisions from vivo and Qualcomm. Nokia, NSB Y Fine with Qualcomm＊s suggestion LGE Update from vivo, QC and Xiaomi is preferred. IDCC Y Ericsson Y From the network point-of-view, we would not like a more capable UE to put additional constraints on the network. More specifically, it is not desired to mandate the network to provide measurements gaps to allow the UE to retune to the location of CD-SSB, instead of simply using the NCD-SSB when it is contained within the active DL BWP. Agree with NEC that FG 6-1 needs to be updated for RedCap. Currently, FG 6-1 requires both SSB and CORESET #0 to be within the RRC-configured DL BWP. Hence, there is a need for a new FG or modified FG 6-1 for which the RRC-configured DL BWP contains SSB but not CORESET #0. Intel Y We are also fine with the suggestion from QC. A few points to highlight: On paging in separate initial DL BWP, it should NOT be precluded. While it is true that this is not supported today (there is no separate initial DL BWP today!), but we do not expect prohibitive amount of spec or gNB/UE efforts to support such. On support of NCD-SSB in connected mode, this should be the baseline capability 每 from a UE＊s perspective we fail to see how using NCD-SSB brings forth any fundamental changes to T-F tracking and measurements compared to doing such on CD-SSB. On the CSI-RS and measurement-gaps related options for connected mode, we think these could actually be merged. Even with CSI-RS in the active DL BWP, it may still be beneficial to enhance the measurement gap configurations (subject to RAN4) for RedCap UEs to perform RF retuning and receive the CD-SSB, when the latter is not included within the active DL BWP. FL4 Based on the received responses, the following updated proposal can be considered. The case when CD-SSB and CORESET#0 are included in the separate initial DL BWP is addressed in Proposal 3-1c. High Priority Proposal 5-1d: For FR1, For a cell that allows a RedCap UE to access, network can configure a separate initial DL 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. For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, 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. Working assumption:?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) from RAN1 perspective, A RedCap UE supporting only mandatory FG 6-1 (but not optional FG 6-1a) expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. Working assumption: A RedCap UE can in addition optionally support relevant operation (except for standalone use for RRM measurement) based on CSI-RS and/or measurement gap by reporting existing optional capabilities. Working assumption: A RedCap UE can in addition optionally support operation without SSB or CSI-RS in it (RAN4 can decide a minimum measurement gap configuration if needed). 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. Note: If a separate SIB-configured initial DL BWP for RedCap UEs contains the entire CORESET#0, the RedCap UE shall use the bandwidth and location of the CORESET#0 in DL during initial access. HW, HiSi N The following does not exist anymore given the proposal in 3-1c 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. Working assumption:?If it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. Comparing the FL formulation of the following A RedCap UE supporting only mandatory FG 6-1 (but not optional FG 6-1a) expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. W.r.t. the proposal from our side, A RedCap UE shall mandatorily report its support of either or both from {NCD-SSB, operation of BWP without SSB}. The proposal from FL does not seem to allow a UE support both BWP without SSB and NCD-SSB, while our proposal clearly allows this. On other aspects, we do not see difference except that the FL proposal explicitly takes FG6-1a as optional 每 which discourages it to be used in field. However, the reason/concern is not clear 每 a gNB does not have to provide measurement gaps (as a separate mandatory feature) if it does not use that BWP or if a UE reports otherwise. We also do not think NCD can be directly mandated, which was previously used for a UE supporting CA case每 meaning the UE is advanced to be able to handle two chains for SSB based measurement simultaneously, for both CD-SSB and NCD-SSB. Furthermore, we are strongly concerned by the adoption of NCD-SSB at this stage prior to further RAN2/RAN4 assessment. If any consensus in Ran1 for NCD-SSB is pursued, certain requirements or restrictions on its periodicities/Tx power etc, should be accommodated in a proper way. If NCD-SSB is adopted, periodicity/Tx power is configurable by network without further UE capability restriction RAN2/RAN4 shall complete the specification/requirement work for the case of NCD-SSB has larger periodicity, lower Tx power than CD-SSB No additional spec impact from RAN1 is needed for introducing NCD-SSB, e.g. additional mapping between NCD-SSB and RO CATT Partially Y For use of paging in this case (i.e. not containing entire CORESET#0), we really see less benefit to use NCD-SSB: The feasibility of using NCD-SSB in idle/inactive mode is not justified by RAN2. It is confirmed that the RedCap UE will still have to perform RF retuning to CORESET#0, e.g. for SIB reading. No significant power difference considering the DRX/paging cycle. Great effort is needed in RAN2 normative work. Our first preference is the RedCap UE does not expect NCD-SSB here. And second preference is paging cannot be configured in this case (but it can be configured if separate initial DL BWP contains CORESET#0). For RRC-configured active DL BWP, seems several companies (including us) are proposing a middle ground, i.e. ＆A RedCap UE shall mandatorily report its support of either one or both of {NCD-SSB, operation of BWP without SSB}, but not defining mandatory capability＊. We think it is considerable, since the UE vendors are still free to use NCD-SSB in their products. All they need to do is just report their preference during UE capability report. Fine to add the last note to address the technical issue originally from Proposal 3-3 (with sufficient discussion we believe), avoid hindering the co-existence scenario and ruining the use case of early indication in Msg3. Intel Almost As mentioned in context of Proposal 3-1c, now, Proposal 3-1c does not talk at all about the case when the separate initial DL BWP does not include CD-SSB and CORESET #0 in entirety. Thus, we think the first few deleted bullets (copied below) from this proposal (Proposal 5-1d) should be kept. For FR1, For a cell that allows a RedCap UE to access, network can configure a separate initial DL 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. On ※mandating§ support of NCD-SSB, as mentioned before, the current formulation is consistent with basic expected behavior from RedCap UEs, and ※support of NCD-SSB§ in the context of RedCap should not be mixed with the Rel-15 use-case. We are open to minimizing spec impact for introducing NCD-SSB, and thus, adopting similar configuration as CD-SSB, that is also consistent with RAN2/4 feedback, would be the most reasonable option. On the comments from CATT on paging and NCD-SSB in idle mode, UE does not need to read SIB each time it monitors for paging, but it needs to receive at least one SSB for each paging cycle before paging monitoring. Thus, having NCD-SSB in separate initial DL BWP when paging is configured in separate initial DL BWP does help with UE power consumption. For RedCap UEs, other aspects being similar, idle mode power consumption should not degrade from that for non-RedCap UEs. We still do not see ※great efforts§ for RAN2 to enable NCD-SSB in separate initial DL BWP in idle/inactive modes when paging is configured. vivo Almost We are generally fine except that we are not sure if the existing capability signaling (or combination of them) can be reused to indicate the UE support of CSI-RS operation on the separate initial DL BWP. Introducing new FGs for CSI-RS based operation on separate initial DL BWP might also be considered. Suggest to keep FFS for the capability signaling details for now. suggested revision as below. Working assumption: A RedCap UE can in addition optionally support relevant operation (except for standalone use for RRM measurement) based on CSI-RS and/or measurement gap by reporting existing optional capabilities. FFS details of capability signaling @Huawei, given the RAN4 reply ※RAN4 has no conclusions on whether CSI-RS is a feasible alternative of SSB in the non-initial BWP of RedCap UE.§ We do not think it is agreeable to support the case with CSI-RS but without any SSB (CD-SSB or NCD-SSB) on the separate initial DL BWP. Qualcomm Almost Support proposal on the RRC-configured active DL BWP for RedCap UE. Also fine with the update suggested by Vivo. For initial DL BWP configurations, we can live with the proposal with the following notes: For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, 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. Note In idle/inactive mode, RAN1 assumes a RedCap UE performing RACH in the separate initial DL BWP is NOT required to monitor paging CSS and measure CD-SSB of serving cell by retuning. It is up to RAN2/RAN4 to evaluate whether this configuration has significant impacts on the procedure and requirements of random access procedures for RedCap UEs and confirm its feasibility Working assumption:?If it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. Note RAN1 assumes intra-frequency cell re-selection is purely based on the measurements for CD-SSB of the serving cell and neighbour cells. It is up to RAN2/RAN4 to confirm RAN1＊s working assumption, and define the corresponding procedures and requirements for RedCap UE if RAN1＊s working assumption is deemed feasible. HW, HiSi Follow up @Intel Could you explain what the basic expected behavior a RedCap UE is and what is the mentioned R15 use case? On ※mandating§ support of NCD-SSB, as mentioned before, the current formulation is consistent with basic expected behavior from RedCap UEs, and ※support of NCD-SSB§ in the context of RedCap should not be mixed with the Rel-15 use-case. Could you explain how RAN4 recommend/imply to adopt similar configurations between NCD-SSB and CD-SSB? We are open to minimizing spec impact for introducing NCD-SSB, and thus, adopting similar configuration as CD-SSB, that is also consistent with RAN2/4 feedback, would be the most reasonable option. @vivo Our comments clarified that the bullet for CSI-RS is in addition optionally report for relevant operations as existing approach, which was attempting to address the concern of using CSI-RS alone for RRM. Xiaomi Since there is no agreement supports configuring a separate initial DL BWP which doesn＊t contain CD-SSB and entire CORESET#0, so the first subbullet should be kept (same view with Intel) We are also trying to understand bullet related to CSI-RS. In our understanding the ealisti operation based CSI-RS is not crystral clear. Does that mean FG 1-4, FG 1-5, FG1-6 ,... which are optionally supported by non-RedCap. If the bullet refers to thses cases, we think maybe there is no need to discuss it here. It could be discussed in the UE capability section. Or does that mean FG 1-7, FG 2-51,... which are ealistic for non-RedCap. If this bullet refers to these cases, we are OK to discuss it here and fine with vivo＊s update. For the last Note bullet, we proposed to add SCS and CP with the same reason for Proposal 4-1c. In addition, we think this part is a part of potential agreement rather than explanation. So we suggest to remove the word of ＆Note＊ OPPO almost We are generally fine with the proposal. A few comments: It is not clear what does ※support relevant operation (except for standalone use for RRM measurement) based on CSI-RS§ mean? The 1st bullet can be kept there Vivo2 @Huawei, I think the following sub-bullet is for the basic RedCap UEs, which does not support CSI-RS based measurement operation, such UE shall expect NCD-SSB, which seems clear. A RedCap UE supporting only mandatory FG 6-1 (but not optional FG 6-1a) expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. And you point on CSI-RS seems more relevant to the next sub-bullet about CSI-RS, and for such ※advanced§ UEs, whether SSB is still required depends on CSI-RS can work standalone or not, at least for now RAN4 said CSI-RS cannot work standalone for RRM measurement. Therefore I think there is no issue on the framework of the current FL proposal. @Qualcomm, we are fine with the notes under the rando access bullet, but the notes under paging bullet is not needed. Whether and how to use NCD-SSB or CD-SSB for intra-frequency RRM measurement and cell re-selection in IDLE/INACTIVE modes should be discussed and decided in RAN2 or RAN4. It is not proper to make any assumption in RAN1. NEC We do not object the proposal but are not sure if RAN1 can make progress without confirmation by RAN2/RAN4 on NCD-SSB. Maybe it would be preferable to make the whole proposal as working assumption. HW, HiSi Follow up02 @vivo Ok, thanks for clarification. We do not have problem on CSI-RS part except for response to your previous following-up. What we has problem is NCD-SSB as a basic feature 每 this requires some discussion or conditions if we want it to be affordable from network point of view, especially, gNB shall be able to configure it possibly with larger periodicity and lower Tx power (if needed) without other UE capability restriction. Mandating those always same as CD-SSB is not ealistic. Vivo3 @Huawei, Thanks for the clarification. From our perspective, we are fine to add restriction that ND-SSB periodicity is larger than the CD-SSB. Hopefully this can address Huawei＊s concern. Regarding Tx power, based on RAN2/4 reply, there seems no need to put any restriction on Tx power of NCD-SSB (i.e. it can be the same or different from CD-SSB), as long as the Tx power of NCD-SSB can be signaled to the UE. DOCOMO Y We can accept this FL＊s proposal as compromise. We are also fine with vivo＊s suggestion that the signaling detail for support of CSI-RS based operation is captured as FFS. Samsung Regarding paging in idle mode, we see several companies raised concerns to support it. As pointed out by ZTE, RAN 2 had several concerns to support NCD-SSB for idle/inactive mode. From RAN 1 perspective, NCD-SSB and CD-SSB may lead to different measurement result. IDLE mode mobility may have some issue. E.g., the measurement result of CD-SSB and NCD-SSB may not be the same. The motivation to support paging on separate iDL BWP is not as strong as for RACH, which require UL/DL center frequency alignment during RACH procedure, while paging only has DL without paired UL. To support paging on separate iDL BWP, it means paging for Redcap and non-Redcap cannot be multiplexed in same PDSCH, which increase the system overhead. And updating the paging BWP requires SI update. To support NCD-SSB, it has to provide signaling in SIB for UE in IDLE mode. @Qualcomm, from your proposed note for paging, if cell-(re)selection is based on CD-SSB, why there is a need for NCD-SSB for paging in the separate iDL BWP? For paging in separate iDL BWP, we are fine with either no NCD-SSB, or not support paging in the separate iDL BWP. Besides, we have concerns to make it as WA in RAN 1, which may give an impression to RAN 2 that RAN 1 think this is beneficial or needed for RedCap, while the situation is RAN 1 may not make consensus. For connected mode, as we commented in previous round, we think there is a case that it could be CD-SSB. Therefore, we want to remove ※NCD-※ for the first sub-bullet. Or add (CD-/NCD-) there. On the other hand, from RAN 1 perspective, we don＊t have to differentia it is a CD- or NCD- SSB. Moreover, we can simplify the whole thing as below. This will make FG 6-1 clean and simple. For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, A RedCap UE supporting only mandatory FG 6-1 (but not optional FG 6-1a) expects it to contain (CD-/NCD-)SSB for serving cell but not CORESET#0/SIB. Besides, we support the following proposals from Huawei. If NCD-SSB is adopted, periodicity/Tx power is configurable by network without further UE capability restriction RAN2/RAN4 shall complete the specification/requirement work for the case of NCD-SSB has larger periodicity, lower Tx power than CD-SSB No additional spec impact from RAN1 is needed for introducing NCD-SSB, e.g. additional mapping between NCD-SSB and RO ZTE, Sanechips N If NCD-SSB could be not needed during the RACH procedure, the NCD-SSB is also not needed before UE capability report. After the UE reports the capabilities, gNB can configure the NCD-SSB or other reference signals according to the terminal capabilities. Therefore, we share the view as Huawei and CATT that A RedCap UE shall mandatorily report its support of either one or both of {NCD-SSB, operation of BWP without SSB}. As we proposed in the previous round, the configuration of paging within the separate initial DL BWP in idle/inactive mode may need further consideration by taking the potentially huge spec efforts and NW overhead brought by NCD-SSB into account. Therefore, we have the same preference with CATT for paging configuration. We prefer to remove the last Note as was done in Proposal 3-3b. Adding the note here as a whole package would cause this proposal hardly approved since it is quite controversial in the discussion of proposal Proposal 3-3b. Spreadtrum Y CMCC We also think a capability report method about whether UEs support BWP without SSB provides a good way out, such as HW suggested. Different kinds of RedCap devices have their flexibility to support NCD-SSB on its RRC configured BWP or rely on CSI-RS and/or measurement gap for relevant operation. Maybe the following modification can be considered. For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, A RedCap UE shall mandatorily report its support of either or both from the following, Operation with NCD-SSB: A RedCap UE supporting only mandatory FG 6-1 (but not optional FG 6-1a) expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. Operation without SSB:Working assumption: A RedCap UE support relevant operation (except for standalone use for RRM measurement) based on CSI-RS and/or measurement gap by reporting existing optional capabilities. The content in the brackets (except for standalone use for RRM measurement) is removed since the reply from RAN4 is that CSI-RS are not used as a standalone mechanism for RRM measurements and the existing requirements rely on the presence of SSB signals, while here this operation can rely on measurement gap as a supplement to CSI-RS for RRM measurements. Ericsson Y We support this proposal as a compromise. We are also fine with not mandating NCD-SSB for the paging case. MediaTek We preferred the original version where there was two Was (one for CSI-RS and one with re-tuning) because the feasibility of these two mechanisms is different. However, we can accept the proposal if the bullet on CSI-RS is a WA. Working assumption: A RedCap UE can in addition optionally support relevant operation (except for standalone use for RRM measurement) based on CSI-RS and/or measurement gap by reporting existing. Vodafone We share similar views as CMCC and HW, having flexibility on different RedCap devices and providing gNB with configuration control on the different features seems to be a reasonable approach for progress. We also need to take into account that some RAN2/RAN4 work is needed to specify requirements for the NCD-SSB as mentioned in HW first comment on this round FL5 The following agreement was endorsed in an online (GTW) session 16th November 2021: Agreement: For FR1, For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, 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. Note: RAN1 assumes REDCAP UE performing Random access in the separate DL BWP does not need to monitor paging in a BWP containing CORESET#0 Working assumption:?If it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB from RAN1 perspective For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, A RedCap UE supporting mandatory FG 6-1 (but not optional FG 6-1a) expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB A RedCap UE can indicate the following as optional capability: Not need NCD-SSB: A RedCap UE can in addition optionally support relevant operation based on for CSI-RS (working assumption) and/or FG 6-1a by reporting optional capabilities. 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. Note: If a separate SIB-configured initial DL BWP for RedCap UEs contains the entire CORESET#0, the RedCap UE shall use the bandwidth and location of the CORESET#0 in DL during initial access. Note: NCD-SSB periodicity is not required to be configured the same as that of CD-SSB Note: Periodicity of NCD-SSB shall be not less than periodicity of CD-SSB 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. Xiaomi Preferred: Option 2 Acceptable: Option 2 MediaTek Preferred: Option 2 with the following modifications Similar views as for FR1. LGE Preferred: Option 2 Acceptable: Option 2. FUTUREWEI Both FR1 and FR2 should have the same handling for multiplexing pattern 1. For multiplexing pattern 2 and 3, we are unclear about additional efforts when the CD-SSB is not in bandwidth of CORESET#0. Ericsson Preferred: Option 1 Acceptable: Option 2 (at least for multiplexing pattern 1). We are also fine with not using separate initial DL BWP for paging, i.e., initial DL BWP is only available once the random access is initiated in idle and inactive states. The overhead of additional SSB transmissions can be significant in FR2. In particular, in FR2 with analogue beamforming where up to 64 SSBs can be transmitted, the additional overhead can be over 21%. Due to such significant overhead, increased inter-cell interference, and reduced network energy/spectral efficiency, additional SSBs should not be transmitted in FR2. Therefore, we prefer Option 1 regarding the presence of SSBs in RedCap DL BWPs in FR2. For multiplexing patterns 2 and 3, RAN1 has already made the following conclusion. In our understanding, this conclusion implies that the UE has to do retuning to CD-SSB. 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. Nokia, NSB Preferred: Option 1 Acceptable: Option 2 NEC Depends on LS responses. Lenovo, Motorola Mobility Preferred: Option 1 Acceptable: Option 2 FL2 Most received responses express similar views for FR2 as for FR1, meaning that there is larger support for Option 2 than for Option 1, although some responses argue that the motivations for Option 1 are stronger for FR2 than for FR1. Some responses highlight that SSB and CORESET#0 multiplexing patterns 2 and 3 may require special attention, whereas multiplexing pattern 1 may be more straightforward. Based on the received responses, the following proposal for FR2 based on Option 2 can be considered. It is identical to the FR1 proposal (Proposal 5-1b) except for the main bullet. High Priority Proposal 5-2b: For FR1, following options: FR2, at least for SSB and CORESET#0 multiplexing pattern 1, 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. Working assumption: 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), A basic RedCap UE expects it to contain NCD-SSB for serving cell [FFS: or CSI-RS or measurement gap configuration] but not CORESET#0/SIB. Working assumption: A RedCap UE can in addition optionally support operation based on CSI-RS instead of SSB in it. Working assumption: A RedCap UE can in addition optionally support operation without SSB or CSI-RS in it (RAN4 can decide a minimum measurement gap configuration if needed). 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 Company Y/N Comments OPPO Same comment as the previous proposal. Vivo Generally fine with modifications Similar as for FR1, we suggest to remove CSI-RS from the proposal. Spreadtrum Y Samsung N This is not acceptable for us. We need to discuss more details for option 2. Moreover, we suggest another option which basically reuse current procedure for iDL BWP, and further discuss separate iDL BWP in the future. Preferred, Option 1 Acceptable: only support the separate iDL BWP that contains CD-SSB and reuse CORESET #0 BW as legacy. CATT N Same comment as the case in FR1. DOCOMO We have a similar view as FR1. LGE Y (with modification) Same comment as for the previous question. The two newly added working assumptions for the RRC-configured active DL BWP in connected mode should be removed. FL RAN2#116-e has replied to the LS from RAN1 in [39]. The reply is inserted earlier in this section. MediaTek Y with modifications Similar comments as the proposal for FR1. Vodafone Same as FR1 CMCC Same comment as the previous proposal. Nordic can be reused at least for Pattern 1 Xiaomi Same view as the case in FR1 ZTE, Sanechips N Similar as FR1. Moreover, the additional overhead for NCD-SSB transmission in FR2 would be more significant that in FR1. Intel Y Also can accept suggestion from vivo on CSI-RS. Nokia, NSB Y Same comment as the previous proposal for FR1. Ericsson Y The proposal can also apply to multiplexing patterns 2 and 3 if the note stating that ※if a separate initial/RRC configured DL BWP is configured to contain the entire CORESET#0, CD-SSB is expected by RedCap UE§ is modified somehow or simply modified. We are fine with not supporting paging in the separate initial DL BWP (when it does not include SSB/CORESET#0/SIB). We share CMCC＊s view that CSI-RS can be kept as an optional capability (and let RAN4 consider further whether it can replace SSB in connected mode). FL3 Based on the received responses, the following updated proposal for FR2 can be considered. It is identical to the corresponding FR1 proposal (Proposal 5-1c) except for the blue parts. High Priority Proposal 5-2c: For FR2, at least for SSB and CORESET#0 multiplexing pattern 1, For a cell that allows a RedCap UE to access, network can configure a separate initial DL 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. For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, 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. Working assumption:?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), A basic RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. A RedCap UE supporting only mandatory FG 6-1 expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. Working assumption:?A RedCap UE can in addition optionally support operation based on CSI-RS instead of SSB in it. Working assumption:?A RedCap UE can in addition optionally support operation without SSB or CSI-RS in it (RAN4 can decide a minimum measurement gap configuration if needed). 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. Vivo Modification Same comment as for FR1 proposal. We suggest the following clarification for the 2nd working assumption. Working assumption:?A RedCap UE can in addition optionally support operation based on CSI-RS instead of SSB in it. Note: This does not mean CSI-RS can be used as a standalone mechanism. Spreadtrum Y NEC Same comments as 5-1c. Xiaomi Firstly, we support vivo＊s revision Secondly, we have comment on the last working assumption. Since operation without CSI-RS is the baseline capability. So A RedCap UE MUST support operation without CSI-RS other than optionally support. Thus we suggest to delete the CSI-RS in this working assumption Working assumption:?A RedCap UE can in addition optionally support operation without SSB or CSI-RS in it (RAN4 can decide a minimum measurement gap configuration if needed). CATT Same comment as for FR1. OPPO Same comments as 5-1c. Sharp Same view as FR1 Vodafone Same as FR1 Nordic OK Panasonic Y Update from vivo is OK. MediaTek Same comments as for FR1 proposal. CMCC Same comments as 5-1c. Samsung See the comments in previous question. DOCOMO Same comment as proposal 5-1c. ZTE, Sanechips Same comment as FR1. Nokia, NSB Same as for FR1 LGE Same comment as in FR1. IDCC Y Ericsson Y Same comments as for FR1. Intel Y Same comments as for FR1. FL4 Based on the received responses, the following updated proposal for FR2 can be considered. It is identical to the corresponding FR1 proposal (Proposal 5-1d) except for the blue parts. The case when CD-SSB and CORESET#0 are included in the separate initial DL BWP is addressed in Proposal 3-1c. High Priority Proposal 5-2d: For FR2, For a cell that allows a RedCap UE to access, network can configure a separate initial DL 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. For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, 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. Working assumption:?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) from RAN1 perspective, A RedCap UE supporting only mandatory FG 6-1 (but not optional FG 6-1a) expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. Working assumption: A RedCap UE can in addition optionally support relevant operation (except for standalone use for RRM measurement) based on CSI-RS and/or measurement gap by reporting existing optional capabilities. Working assumption: A RedCap UE can in addition optionally support operation without SSB or CSI-RS in it (RAN4 can decide a minimum measurement gap configuration if needed). 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. Note: If a separate SIB-configured initial DL BWP for RedCap UEs contains the entire CORESET#0, the RedCap UE shall use the bandwidth and location of the CORESET#0 in DL during initial access. HW, HiSi N CATT Same comment as in FR1. Intel Almost As mentioned in context of Proposal 3-1c, now, Proposal 3-1c does not talk at all about the case when the separate initial DL BWP does not include CD-SSB and CORESET #0 in entirety. Thus, we would actually prefer to keep the first few deleted bullets (copied below) from this proposal (Proposal 5-2d). Not sure if these were controversial. For FR2, For a cell that allows a RedCap UE to access, network can configure a separate initial DL 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. vivo Almost Similar comments as to FR1 proposal: Suggest to keep FFS for the capability signaling details for now. suggested revision as below. Working assumption: A RedCap UE can in addition optionally support relevant operation (except for standalone use for RRM measurement) based on CSI-RS and/or measurement gap by reporting existing optional capabilities. FFS details of capability signaling Xiaomi Same comment with FR1 case OPPO Same comment with FR1 case NEC Same comment as 5-1d. DOCOMO Y Same comments as to FR1. Samsung See the comments in previous question. ZTE, Sanechips N Same as FR1. CMCC Y Same comments as to FR1. Ericsson Y We support this proposal as a compromise. We are also fine with not mandating NCD-SSB for the paging case. Vodafone Y Same as FR1 FL5 Based on the RAN1 agreement in the online (GTW) session 16th November 2021 for the FR1 case, the following updated proposal for FR2 can be considered. It is identical to the FR1 agreement except for the blue parts. High Priority Proposal 5-2f: For FR2, For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, 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. Note: RAN1 assumes REDCAP UE performing Random access in the separate DL BWP does not need to monitor paging in a BWP containing CORESET#0 Working assumption:?If it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB from RAN1 perspective For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, A RedCap UE supporting mandatory FG 6-1 (but not optional FG 6-1a) expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB A RedCap UE can indicate the following as optional capability: Not need NCD-SSB: A RedCap UE can in addition optionally support relevant operation based on for CSI-RS (working assumption) and/or FG 6-1a by reporting optional capabilities. 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. Note: If a separate SIB-configured initial DL BWP for RedCap UEs contains the entire CORESET#0, the RedCap UE shall use the bandwidth and location of the CORESET#0 in DL during initial access. Note: NCD-SSB periodicity is not required to be configured the same as that of CD-SSB Note: Periodicity of NCD-SSB shall be not less than periodicity of CD-SSB CATT Y Do we need to consider update to accommodate the cases: (1) A revise FG 6-1(FG 6-1R or something) definition by removing CORESET#0 in original FG 6-1. (2) Any difference due to pattern 2 and 3, when SSB and CORESET#0 are FDMed and exceed max RedCap UE BW. Minor editorial comment: based on for CSI-RS (working assumption) Intel Y We also support the first point raised by CATT 每 that adjustments or new FG for FG 6-1 is necessary to not expect CORESET #0 (also applicable for FR1). To the second point from CATT, our understanding is that the struck-out text quoted from the proposal is to address patterns 2 and 3? Note: if a separate initial/RRC configured DL BWP is configured to contain the entire CORESET#0, CD-SSB is expected by RedCap UE. FUTUREWEI Y Ok to consider any appropriate adjustments for FG6-1 HW, HiSi Y DOCOMO Y We are fine to replace FG6-1 to appropriate UE feature. Nordic Y Panasonic Y CMCC Y Fine to consider revised FG6-1. Samsung Y vivo Generally fine but The common understanding for handling FDM pattern 2 and 3 for SCS 240KHz (when CORESET#0 + SSB exceeds the UE BW) would need to be clarified. The consequence of deleting the bullet in blue is not very clear＃ OPPO Almost SSB and CORESET multiplexing pattern 1 is supported in FR2, in this case, the note in blue still make sense thus it shall not be removed and it can be changed as in the following: Note: For SSB and CORESET multiplexing pattern 1, if a separate initial/RRC configured DL BWP is configured to contain the entire CORESET#0, CD-SSB is expected by RedCap UE. ZTE, Sanechips For SSB/CORESET#0 multiplexing patterns 2 and 3 in FR2, the combined bandwidth of the CORESET#0 and SSB may exceed the maximum RedCap UE bandwidth. In this case, the separate initial DL BWP must not contain the CORESET0 and CD-SSB simultaneously. When the the separate initial DL BWP contains CD-SSB but not contain entire CORESET0, it is not reasonable that the UE expect another NCD-SSB based on the FL＊s proposal. Additionally, whether bandwidth of the CORESET#0 and SSB exceeding the maximum UE bandwidth is supported or not has not been decided. Therefore, it is suggested to add a FFS as following: For FR2, ...... FFS the case that combined bandwidth of the CORESET#0 and SSB exceeds the maximum UE bandwidth Sharp Y Ericsson Y Lenovo, Motorola Mobility Y NEC Y Nokia, NSB Y IDCC Y FL6 Regarding SSB and CORESET#0 multiplexing patterns 2 and 3, please note 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. Based on the received responses, the following updated proposal can be considered. It is identical to the corresponding FR1 agreement except for the blue parts. High Priority Proposal 5-2g: For FR2, For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, 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. Note: RAN1 assumes REDCAP UE performing Random access in the separate DL BWP does not need to monitor paging in a BWP containing CORESET#0 Working assumption:?If it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB from RAN1 perspective For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, A RedCap UE supporting mandatory FG 6-1 (but not optional FG 6-1a) expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB A RedCap UE can indicate the following as optional capability: Not need NCD-SSB: A RedCap UE can in addition optionally support relevant operation based on for CSI-RS (working assumption) and/or FG 6-1a by reporting optional capabilities. Note: For SSB and CORESET#0 multiplexing pattern 1, 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. Note: If a separate SIB-configured initial DL BWP for RedCap UEs contains the entire CORESET#0, the RedCap UE shall use the bandwidth and location of the CORESET#0 in DL during initial access. Note: NCD-SSB periodicity is not required to be configured the same as that of CD-SSB Note: Periodicity of NCD-SSB shall be not less than periodicity of CD-SSB Qualcomm Y For the separate initial DL BWP for RedCap UE, suggest to add a note to clarify the SSB used for RO selection, i.e. Note: If CORESET/CSS for RA is configured in the separate initial DL BWP with NCD-SSB and CORESET/CSS for paging (working assumption), RAN1 assumes RO selection of an idle/inactive RedCap UE will use the NCD-SSB QCL＊ed with the CORESET/CSS configured for RA of the RedCap UE. For the RRC-configured active DL BWP, if the NW does not transmit NCD-SSB, we think a L1 measurement gap (for CD-SSB outside the initial and RRC-configured active DL BWP) needs to be specified by RAN4 for RedCap UEs supporting FG 6-1a. Therefore, we suggest to add another note as follows: Note: It is up to RAN4 to define an L1 measurement gap for RedCap UEs which support FG 6-1a. MediaTek2 Y FUTUREWEI Y Ericsson Y Apple Y CATT Y Considering the limited time, we can accept the current version (although may not be perfect). Intel Y Fine with the suggested notes from Qualcomm. On the issue of multiplexing patterns 2 and 3, we tend to agree with vivo and ZTE that it would be good to clarify the expected UE behavior when CORESET#0 + CD-SSB exceeds max RedCap UE BW, including whether such cases are supported for RedCap. At least we would need to ensure a common understanding of the previous RAN1 conclusion quoted by the FL. Samsung Y Also fine with Qc＊s note although we prefer to make is as agreement or conclusion. vivo Y 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. MediaTek The FFS should be removed. LGE Share the view with vivo. The FFS in Option 2 should be removed. Ericsson N For BWP#0 configuration option 1, the use of initial DL BWP in connected mode for RedCap is quite limited from both functionality and power saving perspectives. Since the initial DL BWP is rarely used in the connected mode, there is no need to transmit additional SSBs. In this case, the potential impact on the RedCap UE if SSB is not present is small and the UE can rely on the RF-retuning to CD-SSB (which might be rarely needed). In our view, 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. FL2 In line with most received responses, the FFS has been removed in Proposals 5-1b and 5-2b. Qualcomm Regardless SSB is transmitted or not in the RedCap-specific initial DL BWP, it is problematic to configure CORESET/CSS for RA and paging of an idle RedCap UE in different BWPs, due to the potential collisions of PDCCH monitoring for RA and paging. If NW cannot ensure the CSS sets for RA and paging of an idle RedCap UE are not colliding in time, it is necessary to check with RAN2/4 regarding the feasibility and potential spec impacts of configuring CORESET/CSS for RA and paging in different BWPs. FL5 High Priority Question 5-3b: For BWP#0 configuration option 1, should the UE be able to expect SSB transmission in the separate initial DL BWP when it is used in connected mode? CATT N Prefer no SSB transmission, since it seems the separate initial DL BWP will not have big usage with BWP#0 configuration option 1. But open to hear other views if majority would like a unified rule for all DL BWP in RRC_CONNECTED mode. Intel As suggested the last time, we think BWP #0 configuration 1 need not be supported for RedCap UEs. The applicability of BWP #0 configuration 1 is low to none for RedCap UEs, which would be even less significant for separate initial DL BWP. Thus, another option could be to limit support of BWP #0 configuration 1 for RedCap UEs only when BWP #0 includes CD-SSB and the entire CORESET #0. HW, HiSi Not sure if this is still valid. As BWP#0 means the initial DL BWP which is shared also with non-RedCap UEs. Then it will contain CD-SSB anyway. For RedCap UE, if it refers to the separate initial DL BWP, it can be without SSB but can accept with dependence on UE capability report. DOCOMO N In our understanding, for BWP#0 configuration option 1, UE does not expect SSB transmission in the separate initial DL BWP but can expect in RRC-configured active DL BWP in RRC connected mode. Nordic Agree with Huawei, in configuration Option 1 CORESET#0 is included? CMCC N With BWP#0 configuration option 1, separate initial DL BWP may be used for fallback when timer expires. The operating time on separate initial DL BWP is limited. The necessity of presence of SSB is not strong. Samsung BWP#0 configuration option1 should be supported for RedCap UE, since For low capability UE only support one BWP, it benefits for it can configure another BWP If not support this configuration1 for RedCap, then only configuration2 will be used, which means BWP#0 is always RRC configured BWP. It will follow our agreement that RRC configured BWP (not contain SSB and entire CORESET#0) shall contains NCD-SSB for FG6-1UE. This will reduce the flexibility for network configuration. Consider the usage of option1 in RRC connected mode is limited, we prefer to follow ※separate initial DL BWP (no contains SSB and entire CORESET#0) ※agreementㄩ For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, 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. Including BWP#0 configuration option1 vivo Y A unified rule should be applied to all the BWP that is used in CONNECTED mode. How frequent a BWP#0 will be used during CONNECTED mode is determined by NW scheduling, but UE expectation/behavior should be the same with other BWP that is used in the CONNECTED mode. ZTE, Sanechips N For BWP#0 configuration option 1, there are two BWPs including initial DL BWP and RRC configured BWP. From our understanding, the SSB can be expected within the RRC configured BWP. Therefore, UE does not need to expect the SSB in the separate initial DL BWP. Ericsson N In principle, an initial DL BWP can also be used in connected mode. However, for BWP#0 configuration option 1, the initial DL BWP has a limited functionality as it does not have UE-specific configurations. Hence, UE typically switches to a non-initial RRC-configured DL BWP after initial access. Meanwhile, the initial BWP can act as a default BWP which can be used for the purpose of power saving after the initial access. However, for RedCap UEs the use of initial DL BWP in connected mode for power saving purposes is quite limited. This is because the RedCap initial DL BWP is almost as large as UE BW (e.g., 20 MHz in FR1), and thus the power saving gain by switching to the DL initial BWP is small. For non-RedCap UEs with a large BW (e.g., 100 MHz), the is more motivation to switch to a significantly smaller initial DL BWP for power saving. Therefore, the use of initial DL BWP (configuration option 1) in connected mode for RedCap is quite limited from both functionality and power saving perspectives. Since the initial DL BWP is rarely used in the connected mode, there is no need to mandate transmission of additional SSBs. In this case, the potential impact on the RedCap UE if SSB is not present is small and the UE can rely on the RF-retuning to CD-SSB. In our view, for BWP#0 configuration option 1, if the separate initial DL BWP is not configured for paging, then the UE does not expect SSB transmission in the separate initial DL BWP in RRC idle/inactive/connected states. NEC We are not sure what is the case ※when it is used in connected mode§ with BWP#0 configuration option 1. If we assume separate initial UL/DL BWP for RedCap are BWP#0 for RedCap UE as they would be configured by SIB1 with common configurations, e.g. paging and/or random access, BWP#1 which is only configured with dedicated configurations is usually used in CONNECTED with BWP#0 configuration option 1. BWP#0 is used only in case bwp-InactivityTimer expires in CONNECTED. Nokia, NSB N Similar views as other companies that SSB is not expected in the separate initial DL BWP FL6 Since the question seemed to cause some confusion, the following updated question can be considered (cf. TS 38.331 Annex B.2). High Priority Question 5-3c: Should the UE be able to expect SSB transmission in a non-RRC-configured active DL BWP when it is used in connected mode? Qualcomm No need to make such a conclusion for SSB transmission. It depends on the configuration of BWP#0 used by RedCap UEs in idle/inactive mode. MediaTek Y The same handling should be used in connected mode for all DL BWPs. For a RedCap UE with baseline capabilities, what will be the UE behavoure for BWP#0 in connected mode without SSB? Ericsson N For the same reason mentioned in the previous round. Apple Y We assume this proposal especially targets for the ＆BWP#0 configuration option 1＊. According to specification, it is possible to schedule unicast PDSCH by using fallback DCI 1_0 in RRC_Connected mode. As commented by vivo, we think a consistent rule should be applied, same as for RRC_CONNECTED BWP. If overhead is concern, it is always possible to configure Redcap-dedicated initial DL BWP to cover CD-SSB or switch UE to a RRC-configured UE-specific BWP. If ＆BWP#0 configuration option 1＊ is not so useful as commented by several companies, we are also fine to conclude as follows: A separate initial DL BWP (i.e. BWP#0) with configuration option 1 for Redcap is NOT applied after inital access. CATT N Prefer not mandating SSB. This case means the BWP#0 configuration option 1 in 38.331. With this use case, the RedCap UE is expected to mainly work in in RRC dedicated BWP (which will contain SSB as agreed). The separate initial DL BWP will be rarely used, as also explained by many other companies. Intel Y (if this case is supported) We still feel the simplest option would be to drop support of this case for RedCap. However, if we have to support such cases (i.e., equivalent of ※BWP #0 configuration 1§), then this means UE should expect to be kept on this ※non-RRC-configured active DL BWP§ in connected mode, and in this case, the consideration becomes similar to a dedicated RRC-configured DL BWP, and in such a case, UE should expect SSB unless it reports the optional capability of ※NCD-SSB not needed§ for a DL BWP w/o CD-SSB. vivo Y Same comment as in previous round. FL5 High Priority Question 5-4a: Companies are invited to comment on how to handle the following agreed working assumption (from RAN1 perspective) for separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) for FR1. Working assumption:?If it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. Company Comments CATT Send an LS to RAN2 and ask if it can be confirm by RAN2. If RAN2 confirms it is valid, so be it. Otherwise, the separate initial DL BWP can be configured with paging only if it contains CD-SSB. Intel No special handling necessary. It can be revisited if RAN2 (or RAN1 or RAN4) identifies any serious issue with the working assumption. As usual, RAN1 decisions relevant to RAN2 can be shared in an LS. FUTUREWEI Send an LS to RAN2 asking them if there are any concerns with this WA from a RAN2 perspective. HW, HiSi We are concerned to conclude this solely in RAN1. On one hand, it needs to involve RAN2 for final decision, mostly because the decision made in RAN1 may impose unclear risk on RAN2 according to their LS response. On the other hand, so far we do not have clear agreement to support a separate initial DL BWP without CD-SSB/CORESET#0 or at least the case for that remain to resolve some details. Having or not having this WA in RAN1 does not seem to have obvious spec impact, it would be safe to inquire RAN2 or let them take a decision - if deemed necessary, spec work can be done in maintenance phase for RAN1. The comments during the meeting were heavily on the need of NCD-SSB for power saving purpose. However, for IDLE/INACTIVE mode, the DRX cycle can be very large, thus the impact on UE power consumption can be small. Further, although it is understood that CSI-RS/TRS may require additional implementation efforts, it is at least one of the option that can be used especially for power saving purpose. The need of NCD-SSB for other measurement purpose can be significantly reduced in this case. Thus in our view, expectation of NCD-SSB is not necessary. In short, the WA is not needed and the need of that can be inquired with RAN2. DOCOMO We share the same view with CATT. Nordic This should be confirmed at least for RRC connected mode!!! For Idle, whether re-selection is supported in IDLE/Inactive on NCD-SSB is up to RAN2. However, if gNB configured paging outside CORESET#0, NCD-SSB should be present. We do not see any technical issues with Listening paging outside CORESET#0 in Idle/Inactive based on NCD-SSB and Doing re-selection within CORESET#0 CMCC It can be revisited if RAN2 has concern with the working assumption. Samsung We suggest to send an LS to RAN 2, ask RAN 2 to decide whether to support paging on the separate iDL BWP. If the proponent companies have concern, we can also say, NCD-SSB is needed for paging (This is our compromise! We don＊t believe NCD-SSB is needed for paging even now! ). We cannot live with asking them whether there is concern from RAN 2 to support it, as we said, the motivation to support this in RAN 1 is not strong enough, comparing of keeping paging in CORESET #0 together with non-Redcap, no additional power saving, not sure on offloading (multiplexing with non-Redcap in same PDSCH vs NCD-SSB and separate PDSCH for paging, it is hard to say which one has less ※load§). From RAN 1 perspective, we don＊t agree that this is always benefit to the system to be supported. The situation should be correctly reflect in the LS to RAN 2 other than giving RAN 2 the impression that RAN 1 believe this is beneficial. In short, our proposal to replace this working assumption: There is no consensus in RAN 1 on whether to support paging in the separate initial DL BWP if it does not include CD-SSB and the entire CORESET#0 for RedCap UE. Send RAN 2 LS, to ask RAN 2 to decide whether to support paging in the separate initial DL BWP if it does not include CD-SSB and the entire CORESET#0) for RedCap UE. From RAN 1 perspective, if paging on separated iDL BWP is supported (if it does not include CD-SSB and the entire CORESET#0), RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET #0/SIB @ Nordic If UE do cell (re-)selection based on CD-SSB, it means that UE has to monitor CD-SSB in every DRX cycle (I know there were some debates in GTW, but we still this is correct. As far as I know there is no such relaxation in NR, but supported in NB-IoT/eMTC (for stationary UEs)). In this case, we don＊t think there is a benefit for power saving, although it can work. Besides, we think paging should be discussed for IDLE/inactive first. We cannot go to connect mode directly. Based on our understanding, UE will only monitor paging whether the BWP contains CORESET #0 for paging in connected mode. If the RRC-configure BWP (contains NCD-SSB) doesn＊t contain CORESET for paging, CORESET/SS for paging is not configured via UE specific RRC signaling. Because from network side, paging is common for all the UEs. vivo Fine to send LS to RAN2, but in the LS the whole package agreement should be provided so that RAN2 can discuss based on latest RAN1 status. If RAN2 has any question or concern, they can inform RAN1 by LS reply, which is not limited to the working assumption. OPPO At current stage, we don＊t think any special handling is needed. We can wait for RAN2＊s progress on NCD-SSB. ZTE, Sanechips The precondition of confirming this WA should be that RAN2 agree to specify NCD-SSB for measurements (serving and non-serving cell) and cell (re-)selection in Rel-17. If RAN2 has no consensus to specify it, the NCD-SSB for paging in idle/inactive mode should not be expected. So, it is suggested to send LS to RAN2 and RAN1 should have the following conclusion to handle this issue in this meeting If RAN2 has no consensus to specify the NCD-SSB for measurements (serving and non-serving cell) and cell (re-)selection in Rel-17, the NCD-SSB for paging in idle/inactive mode should not be expected. Sharp Same view with other companies. We can send an LS to RAN2 on the applicability of the WA. Ericsson In case the separate initial DL BWP is used for both paging and random access, the UE can also rely on RF retuning to acquire a legacy CD-SSB. With proper configuration of DRX cycle (e.g., long DRX) and SMTC periodicity (e.g., small periodicity), the RedCap UE can have sufficient time and flexibility to acquire the legacy CD-SSB located outside its initial DL BWP. When such configuration is not feasible, additional an NCD-SSB is transmitted. In TDD, whether an additional NCD-SSB is transmitted in a separate initial DL BWP for RedCap, can be based on the following conditions: ? Additional NCD-SSBs may or may not be transmitted if DRX cycle ≡ T1 (e.g., 1280 ms) ? Additional NCD-SSBs may or may not be transmitted if SMTC periodicity ≒ T2 (e.g., 20 ms) ? Additional NCD-SSBs may or may not be transmitted if SMTC periodicity ≒ T3 and DRX cycle ≡ T4 (e.g., T3 = 40 ms, T4= 640 ms) ? Otherwise, additional NCD-SSBs are transmitted. NEC We see need for confirmation by RAN2. Nokia, NSB Fine to send LS to RAN2. In our view, there is no special handling needed in RAN1. FL6 Based on the received responses, the following proposal can be considered. High Priority Proposal 5-4b: Send an LS to RAN2 to inform them and ask for potential feedback on the following agreed working assumption for separate initial DL BWP. Working assumption:?If it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. Qualcomm If an LS is sent to RAN2, we think it should include RAN1＊s agreement and working assumption for the separate initial DL BWP configuration, i.e. RAN1 has discussed the separate initial DL BWP configuration for RedCap UE, which does not include CD-SSB and the entire CORESET#0. The following agreement and working assumption are made in RAN1: If the separate initial DL BWP 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. Note: RAN1 assumes an idle/inactive RedCap UE performing random access in the separate initial DL BWP does not need to monitor paging in another BWP containing CORESET#0. Working assumption:?If it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB from RAN1 perspective Note: If CORESET/CSS for RA and paging are configured in the separate initial DL BWP with NCD-SSB, RAN1 assumes RO selection of an idle/inactive RedCap UE will use the NCD-SSB QCL＊ed with the CORESET/CSS configured for RA of the RedCap UE. RAN1 respectfully asks RAN2 to provide feedback on RAN1＊s agreement and working assumption as above. FUTUREWEI Yes. The entire option 2 as agreed should also be included in the LS Ericsson Yes. Perhaps the LS can be sent to both RAN2 and RAN4. It would be good to add a bullet stating that no RAN1 specification impact is foreseen from this working assumption in order to avoid creating a RAN1 open issue as the RAN1 work is supposed to be completed in December. CATT Yes. In addition, like in previous RAN1 meetings, we are OK to send all RAN2-related agreements to RAN2 for their reference. And RAN1 should specifically mention this one for them to check with. Intel Assuming we would send an LS to RAN2/4 with relevant decisions from this meeting, we can share this decision as well, and ask RAN2/4 to provide feedback if they see any issues, but no need to send a dedicated LS only with this working assumption. At the minimum, the LS should share the all decisions related to CD-SSB/CORESET#0 and DL BWPs for full context. Samsung OK to send LS to RAN 2/4 to inform them the agreement/working assumption. However, we＊d like to ask RAN 2 to decide whether paging on separate iDL BWP is supported or not. Send an LS to RAN2 to inform them and ask RAN 2 to decide whether to support paging on separate initial DL BWP. vivo As we commented before, it is important to send the whole package agreement to RAN2 (maybe RAN4 as well) to provide the whole picture to them and ask for feedback/confirmation. 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: FL3 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. Nordic We still think UE should camp on MIB CORESET#0 in R17, unless RAN2 provides functionality for camping outside CORESET#0 IDCC Agree with Qualcomm. Ericsson In RRC idle/inactive state, RedCap UEs can rely on switching to CORESET #0 to acquire SI updates. However, this depends on the outcomes of 5-1c and 5-2c proposals. Intel No additional changes necessary. SI update information is conveyed via paging, and RedCap UE, in Idle/Inactive modes, is expected to monitor for paging according to configuration of Type 2 CSS in either MIB-configured CORESET#0 (default behavior) or in the separate initial DL BWP (when configured). FL5 High Priority Question 6-1b: What (if any) changes or clarifications are needed in order to support SI update for RedCap UEs in idle/inactive state? CATT We do not see necessary change for now. Intel To elaborate on our previous comment ＃ No additional changes necessary. SI update information is conveyed via paging, and RedCap UE, in Idle/Inactive modes, is expected to monitor for paging according to configuration of Type 2 CSS in either MIB-configured CORESET#0 (default behavior) or in the separate initial DL BWP (when configured). Upon receiving an SI update indication, RedCap UE acquires SIB1 and relevant SI messages either in the MIB-configured CORESET #0 or in separate initial DL BWP if PDCCH Types 0/0A CSS sets are configured in the separate initial DL BWP. HW, HiSi We expect paging monitoring should reply on CORESET#0. DOCOMO We agree with Intel. In RRC idle/inactive state, a UE monitors type-2 CSS for paging in either MIB-configured CORESET#0 or separate initial DL BWP if configured, and then acquires SIB1 and relevant SI messages if the UE receives SI update notification via paging. Nordic If paging is supported also SI update can be supported in common CORESET on separate Initial DL BWP in IDLE. Panasonic RedCap UEs in idle/inactive/connected state can receive SI update information in "Short Messages" in PDCCH using P-RNTI with paging procedure. Therefore, other spec change is not required. CMCC No additional changes. Samsung No need. Agree with most of the comments from other companies. vivo Agree with most of the comment above, no need. OPPO it is sufficient to follow the current procedure. ZTE, Sanechips The notification and reception of SI updates can follow the legacy methodology to minimize spec effort. For RedCap UEs in RRC_IDLE or in RRC_INACTIVE mode, the UEs shall monitor for SI updates notification in its own paging occasion. Upon notification of SI updates, RedCap UEs can switch to the MIB-configured CORESET#0 by RF retuning for the reception of system information if the separately SIB-configured initial DL BWP does not contain the entire CORESET#0. Sharp If a RedCap UE is not configured with Type 0/Type A PDCCH CSS sets in the separate initial DL BWP in idle/inactive mode, RedCap UEs needs to retune to CORESET#0 and use Type 0/Type A PDCCH CSS in SIB-configured initial DL BWP for SI update. The kind of RedCap UE behaviour for SI update in idle/inactive state is different from legacy UEs, which needs clarification in spec. Ericsson In RRC idle/inactive state, RedCap UEs can rely on switching to CORESET #0 to acquire SI updates. Note that, according to the current specifications, UEs in RRC idle or in RRC inactive shall monitor for SI change indication in its own paging occasion every DRX cycle. NEC No strong opinion but if a RedCap UE needs to retune to CORESET#0 for SI acquisition in case of SI update, it would be also reasonable monitoring paging is also performed on CORESET#0 in IDLE/INACTIVE. Nokia, NSB No additional change needed. IDCC Agree with Intel＊s comments. FL3 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. IDCC We think that both in idle and connect mode, the gNB can configure CSSs so that the UE can receive the SI updates in the new initial DL BWP. If the CSSs are not configured, then the UE uses CORESET#0. Nordic None, either gNB configured corresponding search-spaces to UE, or delivers over dedicated RRC LGE Share the same view with Nordic. Ericsson In RRC connected state, RedCap UEs can receive SI update via dedicated SI delivery or rely on paging DCI for SI update notification. Intel Same view as Nordic. FL5 High Priority Question 6-2b: What (if any) changes or clarifications are needed in order to support SI update for RedCap UEs in connected state? CATT We do not see necessary change for now. Intel Updating our previous comment ＃ As mentioned by Nordic, (1) SI updates can be acquired by the UE when one or both of the corresponding SS sets (PDCCH Type 2 CSS set for paging to receive SI update indication, and PDCCH Types 0/0A CSS sets for RMSI/OSI acquisition) are mapped to the active DL BWP or (2) SI updates can be provided to the UE via dedicated RRC signaling. As an additional detail to extend the Rel-15 behavior when separate initial DL BWP is configured for RedCap, for a RedCap UE provided with separate initial DL BWP, the PDCCH CSS sets for paging/RMSI/OSI may be mapped to MIB-configured CORESET #0 or CORESET in separate initial DL BWP (say, ※CORESET #0A§). Then the UE is expected to monitor the PDCCH MOs in the respective CORESET (MIB-configured CORESET #0 or ※CORESET #0A§ in separate initial DL BWP) if the corresponding CORESET bandwidth is included within the active DL BWP with the same SCS and CP. HW, HiSi None. DOCOMO We share the same view with Nordic. In RRC connected state, UE can acquire SI update which is notified via paging or dedicated RRC signaling. Nordic None Panasonic RedCap UEs in idle/inactive/connected state can receive SI update information in "Short Messages" in PDCCH using P-RNTI with paging procedure. Therefore, other spec change is not required. CMCC No additional changes. Samsung No need. Agree with most of the comments from other companies. Vivo No need OPPO No need ZTE, Sanechips None. The notification and reception of SI updates can follow the legacy methodology to minimize spec effort. For RedCap UEs in RRC_CONNECTED mode, if the active BWP for RedCap UEs overlaps with the initial BWP, or the active BWP has been configured with common search spaces for paging, SIB1 message and other system information (i.e., SIB2 and beyond), the RedCap UEs can be informed of the SI updates directly on that active BWP by monitoring paging at least once per modification period. If the active BWP has not been configured with search spaces for the reception of paging and SI updates, the network can provide system information through dedicated signaling using the RRCReconfiguration message. Ericsson In RRC connected state, RedCap UEs can receive SI update via dedicated SI delivery or rely on paging DCI for SI update notification. Also, up on receiving the paging DCI with SI update notification, the UE can retune to the location of CORESET#0 (if not contained within the active BWP) to acquire SIBx. However, retuning to CORESET#0 may lead to some interruption time. Note that such interruptions are expected to be quite infrequent (as SI updates are expected to be infrequent). We are also fine with leaving the decision on SI update in connected mode to RAN2. NEC None. Nokia, NSB No additional change needed. IDCC Agree with Intel＊s comments. 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. Xiaomi Firstly, we think reuse the existing equations for PUCCH PRB determination could be baseline. . Furthermore, to avoid resource fragment, only assigning PUCCH PRB at one edge of initial UL BWP is more desirable. Depending on different scenario, different equations should be taken to avoid PUCCH PRBs is located in distributed way within the BWP. As shown in the following figure, in case (A), it is better to take the equation to determine the PRB index. In case(B), it is better to take equation to determine the PRB index. Considering this point, NW can indicate which equation is used to determine the PRB index. LGE Striving for a minimum spec change is fine. We think the first frequency hop should be used during the entire PUCCH transmission when the intra-slot FH is disabled. FUTUREWEI It should be clarified whether 8 or 16 PUCCH resources are used for RedCap UEs. If 16 PUCCH resources are used, then whether the top or bottom of the BWP needs to be indicated. If 8 PUCCH resources are used, then legacy operation should be used. Ericsson General comment: It is desired to have all the 16 PUCCH resources (before dedicated PUCCH resource configuration) on one edge of the UL BWP. Furthermore, the NW should be able to choose which edge, e.g., based on an indication in SIB. In addition, it should be possible to configure separate PUCCH resource sets for RedCap and non-RedCap UEs, e.g., using different values for pucch-ResourceCommon. The frequency domain resource allocation for PUCCH before dedicated signaling with enabled PUCCH FH (i.e., two hops) is described in TS 38.213 (Section 9.2.1 PUCCH resource sets). This description needs to be updated for RedCap with the option of disabled PUCCH FH where only one frequency hop can be used. In addition, it needs to be specified which frequency hop (PRB) is used for PUCCH transmissions when the FH is disabled. In general, it is desired to have the PUCCH transmissions at the carrier edge to prevent the PUSCH resource fragmentation. Therefore, it is desired to use the PUCCH hop located at the carrier edge and disable the one which is in the middle of the carrier. It may also be beneficial to configure different sets of cell-specific PUCCH resources/parameters (using, for e.g., different indices in Table 9.2.1-1 of TS 38.213) for RedCap and non-RedCap UEs. More specific comment: the UE determines the PRB index of the PUCCH transmission which are located only on either higher edge or lower edge of its BWP (in one carrier edge). This can depend on the location of the BWP. The UE determines the PRB indices of the PUCCH transmission by using one of the following equations: , which is located at the lower edge of the RedCap UL BWP. , which is located at the higher edge of the RedCap UL BWP. Here, N_BWP^size is the size of RedCap UL BWP, is the total number of initial cyclic shift indexes in the set of initial cyclic shift indexes. Lenovo, Motorola Mobility Preferred: Option 1 Acceptable: Option 2 FL2 Based on the received responses, companies are invited to provide input on the following questions. High Priority Question 8-1b: When the frequency hopping for the RedCap PUCCH resources (for HARQ feedback for Msg4/MsgB) is deactivated, Should there be 8 or 16 PUCCH resources (i.e., what should be the range for the PUCCH resource index rPUCCH)? Should each PUCCH resource (corresponding to a PUCCH resource index rPUCCH) be mapped to 1 or 2 PRBs? Should the PUCCH resources be mapped to the same or different edges of the BWP? Do you have some suggested solutions, concerns or other comments? vivo Our answers to the questions are as below Q1: 16 PUCCH resources Q2: 1 PRB Q3: all PUCCH resources are mapped to same edge of the BWP, which can be either the lower edge or higher edge, configurable by NW. Q4: We have described the preferred solution in the reply of previous round. Apple On Q1: We think it is necessary to keep at least same PUCCH capacity for Redcap UEs i.e., 16 PUCCH resources. On Q2: Except unlicensed band, the PUCCH format 0 and format 1 are supported in legacy during initial access, which is single PRB in frequency domain. We do not see motivation to enhance it to multiple PRBs for Redcap, i.e., should keep single PRB. On Q3: Our view is that this is related to the number of initial UL BWP. If we only support one initial UL BWP, the PUCCH has to be centralized at one edge of CC. Panasonic O1: 16 PUCCH resources. Q2: Single PRB Q3: Yes. For example, PUCCH PRB with rPUCCH: 0-7 are mapped on lower edge of initial UL BWP for RedCap while PUCCH PRB with rPUCCH: 8-15 is mapped at higher edge Q4: As commented by Intel and Ericsson, using different values for pucch-ResourceCommon for Redcap UEs allow such operation. Samsung We prefer minimal changes of the spec other than optimization. On the other hand, we think this is for the case of separated iUL BWP, assuming all the UL parameters can be configured separately from iUL BWP for non-RedCap. This should give enough flexibility for network. CATT The principle is minimizing spec impact. Any optimization is not essential. Q1: Prefer 16 but can live with 8 (if 8 requires little spec impact) Q2: 1 PRB Q3: Prefer to be same edge, can live with different edges. Q4: It may not be easy to define ＆when separate initial UL BWP is at high/low edge＊ by spec. Using the location of 1st hop can be a baseline as suggested by DOCOMO. DOCOMO 16 PUCCH resources should be supported as per current specification, i.e., the PUCCH resource index should be the range of 0 to 15. We share the same view with Apple that it should be 1 PRB. It can be different depending on which edge of BWP the separate initial UL BWP is configured to align with. In our view, it is not preferable to indicate different PUCCH resource set index between RedCap and non-RedCap UE since it would interference each other with the PUCCH resources of the neighbor cells. LGE 16 PUCCH resources (same as in legacy) 1 PRBs (same as in legacy) Different edges of the initial UL BWP for RedCap (same mechanism as in legacy) The frequency resource for PUCCH transmission when the intra-slot FH is disabled is determined by the first frequency hop. Same mechanism to calculate the PRB index for the first frequency hop is reused. We think this is the solution with the minimum spec change. CMCC 1. We prefer 16 PUCCH resources. RedCap with disabled FH PUCCH and non-RedCap use different equations to determine their PRB index. 2 Each PUCCH resource can be mapped to 1 PRBs at one edge of BWP. 3. Different edges of the BWP. At which edge is indicated by SIB. The following equation suggested by Ericsson is fine to determine the PRB index. ,0<=rPUCCH<16, which is located at the lower edge of the RedCap UL BWP. ,0<=rPUCCH<16, which is located at the higher edge of the RedCap UL BWP. Nordic 16 2PRB can ensure that legacy PUCCH resource set table can be reused different edges should be supported 2PRB design can coexist with legacy UEs Xiaomi Q1: 16 Q2: 1 PRB Q3:different edges should be supported. And we also support Ericsson＊s proposal ZTE, Sanechips 16 PUCCH resources is preferred. If gNB confines 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. 1PRB. During the initial access, only PUCCH format 0/1 are used with 1PRB. So the background of this question seems to be not not clear to us. All PUCCH resources should be mapped to the same edge (either lower edge or upper edge) of the BWP which is up to the gNB. For simplicity, the location of PUCCH can be configured by gNB. Intel A total of 16 PUCCH resources One PRB. Different edges as legacy gNB can indicate the proper resource in a given slot to minimize any PUSCH resource fragmentation. Only difference from legacy is that when FH is disabled, UE uses the first hop location for entire PUCCH transmission. Nokia, NSB Q1: 16 PUCCH resources Q2: 1 PRB Q3: All PUCCH resources should be mapped to the same edge 每 up to gNB to configure which edge. Ericsson 1) It is desired to have all 16 PUCCH resources for a higher PUCCH capacity. 2) Similar to legacy connected-mode operation without PUCCH frequency hopping, each PUCCH transmission should be mapped to 1 PRB, not 2 PRBs. 3) In general, it is desired to have the PUCCH transmissions at the carrier edge to prevent the PUSCH resource fragmentation. Therefore, it is desired to use the PUCCH hop located at the carrier edge and disable the one which is in the middle of the carrier. Hence, the PUCCH resources be mapped to the same edge and the edge can be configured by gNB (since it may, e.g., depend on the location of the RedCap UL BWP with respect to non-RedCap UL BWP/carrier). 4) It might be worthwhile to consider allowing configuration of different PUCCH resource set indices for RedCap and non-RedCap (e.g., with more symbols in the RedCap case) in order to recover some of the potential PUCCH performance loss from reduced frequency diversity when frequency hopping is disabled for RedCap. Qualcomm Agree with the comments of DOCOMO. FL3 Based on the received responses, the following proposal can be considered. Companies are also invited to provide their view in the Comments field on how to map each PUCCH resource to a PRB. If the solutions may be different for the 8-resource and 16-resource cases, please describe both cases. High Priority Proposal 8-1c: When the frequency hopping for the RedCap PUCCH resources (for HARQ feedback for Msg4/MsgB) is deactivated, The UL BWP edge to which the PUCCH resources are mapped is configurable by the network. Each PUCCH resource is mapped to a single PRB. Company Y/N Comments vivo Y Our solution has been provided in the 1st round of discussion. Qualcomm Y We can live with this proposal for the sake of progress Xiaomi Y with modification We support the intension of the proposal. But for the first subbullet, more clarification is needed. It is difficult for spec to describe the first subbullet. we suggest to step further to make it clear. When the frequency hopping for the RedCap PUCCH resources (for HARQ feedback for Msg4/MsgB) is deactivated, The PUCCH PRB is determined by the equation of or . Network configures which equation is used for the PUCCH PRB determination The UL BWP edge to which the PUCCH resources are mapped is configurable by the network. Each PUCCH resource is mapped to a single PRB. CATT Y OK Sharp Y Nordic OK, but We are fine to go for 1PRB, however, then there should be configurable offset for RedCap, to ensure separate initial DL BWP can be configured flexibly by gNB avoid collision of legacy hopping resource and non-hopping resource to happen to be on the same PRB Something like what Xiaomi shows, but what Xiaomi equation does NOT include, it should be +Offset_RedCap or -Offset_Redcap. Update from Nordic When the frequency hopping for the RedCap PUCCH resources (for HARQ feedback for Msg4/MsgB) is deactivated, The UL BWP edge to which the PUCCH resources are mapped is configurable by the network, including configurable additional offset from edge. Each PUCCH resource is mapped to a single PRB. Huawei, HiSi Almost It should be possible up to gNB to configure the PUCCH resources in a manner similar to legacy UE specific PUCCH without hopping. When the frequency hopping for the RedCap PUCCH resources (for HARQ feedback for Msg4/MsgB) is deactivated, The UL BWP edge(s) to which the PUCCH resources are mapped is/are configurable by the network. Each PUCCH resource is mapped to a single PRB. Panasonic Y For more progress, clarification by Xiaomi is fine. Additional RB offset for RedCap by Nordic can also be considered. CMCC Y Samsung We think where the PUCCH resource should be configured by gNB, there is no need to restrict it has to be a UL BWP edge. We suggest the following changes: High Priority Proposal 8-1c: When the frequency hopping for the RedCap PUCCH resources (for HARQ feedback for Msg4/MsgB) is deactivated, The UL BWP edge to which The PRB for PUCCH resources are mapped is configurable by the network. Each PUCCH resource is mapped to a single PRB. DOCOMO Y If the lower edge of separate initial UL BWP for RedCap UE is aligned with that of initial UL BWP for non-RedCap UE, UE specific PRB offset should be indicated as follows: □RB■_"BWP" ^"offset" +?r_"PUCCH" ?N_CS ? If the higher edge of separate initial UL BWP for RedCap UE is aligned with that of initial UL BWP for non-RedCap UE, UE specific PRB offset should be indicated as follows: □N_"BWP" ^"size" -1-RB■_"BWP" ^"offset" -?((r_"PUCCH" -8))?N_CS ? ZTE, Sanechips Y Lenovo, Motorola Mobility Y FUTUREWEI Y Nokia, NSB Y LGE Y On how to map each PUCCH resource to a PRB, we think the legacy mechanism as described by DOCOMO above can be resused. IDCC Y Ericsson Y Assuming that 16 resources are supported, we are open to consider different ways to map 16 PUCCH resources 每 either all of them to one BWP edge (which is determined, e.g., by a SIB parameter) or half of them to one BWP edge and the other half to the other BWP edge. In the latter case, the gNB should be able to dynamically decide whether to use the resources on both or only one of the edges. The UE determines the PRB index of the PUCCH transmission which are located only on either higher edge or lower edge of its BWP (in one carrier edge). This can depend on the location of the BWP. The UE determines the PRB indies of the PUCCH transmission by using one of the following equations: , which is located at the lower edge of the RedCap UL BWP. , which is located at the higher edge of the RedCap UL BWP. , which is located at the lower edge of the RedCap UL BWP. , which is located at the higher edge of the RedCap UL BWP. Here, N_BWP^size is the size of RedCap UL BWP, is the total number of initial cyclic shift indexes in the set of initial cyclic shift indexes. As we mentioned in the previous round, it might be worthwhile to consider allowing configuration of different PUCCH resource set indices for RedCap and non-RedCap (e.g., with more symbols in the RedCap case) in order to recover some of the potential PUCCH performance loss from reduced frequency diversity when frequency hopping is disabled for RedCap. Intel Y An additional offset, suggested by Nordic, may not be necessary since can be provided separately for RedCap UEs as part of PUCCH resource configuration for the separate initial UL BWP for RedCap. We agree with the suggestion from Ericsson on ability to configure different PUCCH resources for RedCap vs. non-RedCap (e.g., more symbols for RedCap to compensate for lack of FH), and we expect this can be realized again via separate configuration of PUCCH resources in separate initial UL BWP for RedCap. FL4 Based on the received responses, the following proposal can be considered. High Priority Proposal 8-1d: When the frequency hopping for the RedCap PUCCH resources (for HARQ feedback for Msg4/MsgB) is deactivated, Each PUCCH resource is mapped to a single PRB. The UL BWP edge to which The PRB for PUCCH resources are mapped is configurable by the network. RedCap and non-RedCap can be configured with different PUCCH resource set indices (see TS 38.213 Table 9.2.1-1). HW, HiSi Previous version or We share the view with Ericsson and see the benefits of all possible PUCCH resource configurations as Ericsson listed, which does not impose UE complexity. The previous version with modifications is better in our view, since the current version could be unclear on what is the PRB - the first PRB or? As alternative, if the issue is clear enough to all, we think the cases explicitly listed in Ericsson＊s response can be captured in the proposal directly for discussion, and preferably leave each case to be configurable by network. We are also supportive to have different PUCCH resource set indices between RedCap and non-RedCap UEs. CATT Y in principle We are generally fine with the proposal. But we also think ＆The PRB for PUCCH resource is configurable by the network＊ is a little ambiguous and is more like a high-level one. We see several comments are proposing different detailed mechanisms, and all of them are aligned with this sub-bullet. Regarding to the mechanisms based on ＆high edge＊ or ＆low edge＊ judgement, technically they are correct and understandable during discussion. However, it is creating a problem on how to define and capture the concept of ＆high edge and low edge＊ in the spec. On the contrary, Nordic＊s method seems to be a safer choice to achieve the same goal, while introducing new concept is also avoid. Intel We are fine with the new third sub-bullet but not the updated second bullet. We tend to agree with HW that the second sub-bullet is now ambiguous, and thus, prefer the earlier version for the second sub-bullet. The UL BWP edge to which The PRB for PUCCH resources are mapped is configurable by the network. FUTUREWEI Similar comment that the earlier version of the proposal was more detailed vivo Agree with the comment and suggested revision from Intel. Qualcomm Y Suggest to include the following change for the 1st sub-bullet: Each PUCCH resource is mapped to a single PRB within the initial UL BWP of RedCap UE. Sharp We are OK on first and third bullets. On second bullet, as same as other companies, we think current description is a bit ambiguous and we prefer the previous version. Xiaomi If we can＊t reach on consensus on more detailed solution/equation for the PUCCH PRB determination at current stage, we prefer the original version or the version proposed by Intel DOCOMO Y with modification We are fine with the proposal in general. As commented before, we have some concern on the third sub-bullet in this proposal. For example, if RedCap and non-RedCap can be configured with different PUCCH resource set indices, the same time/frequency resource as the RedCap UE can be used for a non-RedCap UE of the neighbor cells and it may cause interference. Therefore, to avoid such case, we prefer to clarify as follows: When the frequency hopping for the RedCap PUCCH resources (for HARQ feedback for Msg4/MsgB) is deactivated, Each PUCCH resource is mapped to a single PRB. The UL BWP edge to which The PRB for PUCCH resources are mapped is configurable by the network. RedCap and non-RedCap can be configured with different or same PUCCH resource set indices (see TS 38.213 Table 9.2.1-1). Samsung Y We don＊t think there is a need to restrict the location of PUCCH resource. With full flexibility, gNB should fine a proper location for PUCCH transmission, to avoid the fragmentation of PUSCH. ZTE, Sanechips We prefer the previous version. CMCC For 2nd bullet, previous version seems better. Ericsson Y We are fine with DOCOMO＊s update to the 3rd sub-bullet. Before a dedicated RRC connection, the PUCCH configuration is provided in PUCCH-ConfigCommon. The information element (IE) PUCCH-ConfigCommon is used to configure the cell specific PUCCH parameters. PUCCH-ConfigCommon is part of BWP-UplinkCommon configuration. Therefore, by configuring a separate initial UL BWP RedCap, a different pucch-ResourceCommon can be configured for RedCap which can provide a different PUCCH resource set index than that of for non-RedCap UEs. According to TS 38.331: PUCCH-ConfigCommon information element. PUCCH-ConfigCommon ::= SEQUENCE { pucch-ResourceCommon INTEGER (0..15) OPTIONAL, -- Cond InitialBWP-Only pucch-GroupHopping ENUMERATED { neither, enable, disable }, hoppingId INTEGER (0..1023) OPTIONAL, -- Need R p0-nominal INTEGER (-202..24) OPTIONAL, -- Need R ... } Where pucch-ResourceCommon is an entry into a 16-row table (in TS 38.213 Table 9.2.1-1) where each row configures a set of cell-specific PUCCH resources/parameters. BWP-UplinkCommon information element -- ASN1START -- TAG-BWP-UPLINKCOMMON-START BWP-UplinkCommon ::= SEQUENCE { genericParameters BWP, rach-ConfigCommon SetupRelease { RACH-ConfigCommon } OPTIONAL, -- Need M pusch-ConfigCommon SetupRelease { PUSCH-ConfigCommon } OPTIONAL, -- Need M pucch-ConfigCommon SetupRelease { PUCCH-ConfigCommon } OPTIONAL, -- Need M ..., [[ rach-ConfigCommonIAB-r16 SetupRelease { RACH-ConfigCommon } OPTIONAL, -- Need M useInterlacePUCCH-PUSCH-r16 ENUMERATED {enabled} OPTIONAL, -- Need R msgA-ConfigCommon-r16 SetupRelease { MsgA-ConfigCommon-r16 } OPTIONAL -- Cond SpCellOnly2 ]] } FL5 Based on the received responses, the following proposal can be considered. High Priority Proposal 8-1e: When the frequency hopping for the RedCap PUCCH resources (for HARQ feedback for Msg4/MsgB) is deactivated, Each PUCCH resource is mapped to a single PRB. The PRB for What side of the UL BWP center frequency to which PUCCH resources are mapped is configurable by the network, including configurable additional offset from edge. RedCap and non-RedCap can be configured with the same or different PUCCH resource set indices (see TS 38.213 Table 9.2.1-1). CATT Y Intel We are not sure if the last part of the second sub-bullet is necessary. For example, the separate initial UL BWP for RedCap could be configured such that: when the ※lower edge PRBs§ are indicated, the lowest PRB of the separate initial UL BWP for RedCap is at the desired offset from the lowest PRB of the initial UL BWP for non-RedCap UEs, and when the ※upper edge PRBs§ are indicated, the highest indexed PRB of the separate initial UL BWP for RedCap is at the desired offset before the highest PRB of the initial UL BWP for non-RedCap UEs. That is, any ※additional offset§ can be realized by proper configuration of the bandwidth of the separate initial UL BWP for RedCap UEs. Thus, we suggest to modify the second sub-bullet as below: The PRB for What side of the UL BWP center frequency to which PUCCH resources are mapped is configurable by the network, including configurable additional offset from edge. FUTUREWEI Y HW, HiSi We want to alert that we shall have been towards the completion of R17 RedCap RAN1 with TP/RRC available. For the above case, it seems what companies want are clear and may be differed in small places, thus we suggest FL directly take equations that companies want to change for possible agreements. For example, if it is the case that all cases/edges/sides can be mapped with PUCCH resources (8 or 16) which is configurable, we could simply list those cases as proposal. The latest proposal is still a bit ambiguous, for example, what is the ※additional offset from edge§ - based on the figure from Nordic, the offset seems to be applied on top of the current offset in spec 每 which means it may not start from edge. Also, from RRC perspective, it would be good/better to have a set of offset values to agree on, and send to RAN2, if this offset is needed. We are also fine without the offset. DOCOMO Y Nordic Y @Intel, but proper configuration of BWP may result in configuration restrictions. We cannot accept such restrictions as those can cause deployment issues. Panasonic Y CMCC Y It is fine to configure which side of the UL BWP. Offset from edge can be determined by PUCCH resource set indices of RedCap and equations, or configurable by the network. Define specific equation is preferred. vivo Y ZTE, Sanechips The PUCCH resource sets in Table 9.2.1-1 of TS 38.213 and PRB offset (already exists) therein shall be reused to minimize spec impact. The following three aspects by gNB implementation can be used for handling interference between RedCap and non-RedCap: Different PUCCH resource set indices Separate initial UL BWP location Different PUCCH resource with index r_PUCCH=?(2□?n■_(CCE,0))/N_CCE ?+2??_PRI Therefore, additional offset is not needed and we suggest the following revision: The PRB for What side of the UL BWP center frequency to which PUCCH resources are mapped is configurable by the network, including configurable additional offset from edge. Sharp We have same view with Intel on the ＆additional offset＊ in the second sub-bullet. In addition to the proper configuration of locationAndBandwidth of the separate initial UL BWP as commented by the Intel, the gNB can also configure RedCap UEs a separate pucch-ResourceCommon with a different PRB offset to avoid PRB collision with non-RedCap UE. As in Table 9.2.1-1 in TS38.213, even for PUCCH configuration with same PUCCH format, first symbol and numbers of symbols, different PRB offsets are provided. Ericsson Y In our view, to have a minimum specification changes the existing equations for PRB index determination can be reused as much as possible. Depending on the desired edge of the UL BWP for RedCap PUCCH resources, the following equations can be considered for PRB index determination: Lower edge of UL BWP (PRBs with lower indices): If : the UE determines the PRB index of the PUCCH transmission as , which is located at the lower edge of the RedCap UL BWP. If : the UE determines the PRB index of the PUCCH transmission as , which is located at the lower edge of the RedCap UL BWP. Higher edge of UL BWP (PRBs with higher indices): If : the UE determines the PRB index of the PUCCH transmission as, which is located at the higher edge of the RedCap UL BWP. If : the UE determines the PRB index of the PUCCH transmission as , which is located at the higher edge of the RedCap UL BWP. where , N_BWP^size is the size of RedCap UL BWP, is the total number of initial cyclic shift indexes in the set of initial cyclic shift indexes. The RedCap non-FH PUCCH resources will be mapped to the same PRBs as the first hop for legacy PUCCH transmissions as long as rPUCCH is less than 8. The gNB can (dynamically) choose whether to only use the first 8, more backwards-compatible locations or also the next 8 locations. We would also be fine with mapping the RedCap non-FH PUCCH resources to different sides of the UL BWP as long as the first 8 PUCCH resources are mapped to one side and the next 8 PUCCH resources are mapped to the other side. In this case, the gNB can also (dynamically) choose whether to only use the first 8 locations (which are on the most desired side) or also use the 8 locations on the other side. Lenovo, Motorola Mobility Y Nokia, NSB Y IDCC Y FL6 Based on the received responses, the same proposal can be considered again. Regarding the part ※including configurable additional offset from edge§ in the second sub-bullet, is has been suggested that the PUCCH PRB position could be adjusted by adjusting the position of the separate initial UL BWP, but it has also been commented that such adjustment may cause undesired restriction of the BWP configuration for other channels. It has also been suggested that the PRB offset in the PUCCH resource set table (38.213 Table 9.2.1-1) can be used for separating RedCap and non-RedCap PUCCH transmissions, but the FL＊s understanding is that this PRB offset already serves another purpose (to avoid collision with PUCCH transmissions in neighbor cells). The detailed impacts on the equations can be determined during the CR drafting. High Priority Proposal 8-1e: When the frequency hopping for the RedCap PUCCH resources (for HARQ feedback for Msg4/MsgB) is deactivated, Each PUCCH resource is mapped to a single PRB. What side of the UL BWP center frequency to which PUCCH resources are mapped is configurable by the network, including configurable additional offset from edge. RedCap and non-RedCap can be configured with the same or different PUCCH resource set indices (see TS 38.213 Table 9.2.1-1). Qualcomm Y FUTUREWEI Y We share the view as other companies that potential modifications for specifications be captured. Ericsson Y Regarding the existing PRB offset in the PUCCH resource set table, please note that the different PRB offset values are already today potentially allocated to different sectors of base stations. For example, Format 1 with 10 symbols has 3 different offset values ({0, 2,4}), each can be used for a sector. CATT Y OK. We think thre is no big issue. We agree that there are some use cases for the offset. If the gNB thinks the Offset is not needed, it can just configure zero offset. Intel While we still think the impact to BWP configurations may not be significant, we can accept the proposal of additional offsets if this is the majority preference. On the equations shared by Ericsson, if all resources are to be mapped to one side, we are not sure if the (rPUCCH 每 8) terms are accurate, these should be w/o the ※- 8§ 每 e.g., as suggested in an earlier comment from Sharp 每 copied below: □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. In any case, this can be discussed further as next step. vivo Y For the equations, we have same question as Intel to Ericsson＊s proposal. We think the equations provided by Intel above is sufficient. 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. FL3 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 1 are 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 ?, 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. vivo N We think FL has fairly summarized the views from companies and the motivation behind. We share the majority of companies view that there is no strong need to introduce additional spec change for this issue. Xiaomi N In our view, this problem can be solved by proper network configuration. For example, different PRB can be configured for RedCap. According to the Table 9.2.1-1 of 38.213, PUCCH resources of non-RedCap occupy at most 4 PRBs on each edge of initial UL BWP, assuming 2 cyclic shifts are configured for PUCCH transmission. In this case, PRB offset of 4 can be configured for RedCap to avoid PRB overlapping. Thus, the current specification is sufficient to avoid the potential overlapping CATT N This is not new and already handled by gNB for current initial UL BWP and non-initial UL BWP. Sharp N We don＊t see the strong motivation to introduce spec change to multiplex on a same PRB between RedCap UEs and non-RedCap UEs. Nordic Y as expressed in previous question Huawei, HiSi Y We agree with DOCOMO. We have been discussed many for optimizing DL for e.g. offloading purpose during initial access while it is worthwhile to note that PUCCH is the bottleneck in terms of capability if RA procedure cannot be completed only when UE reaches Msg4. Samsung N Nokia, NSB N LGE N Expanding the PUCCH multiplexing capacity during initial access may be a useful feature in the end. But we don＊t think RedCap is the right place to discuss it especially at this late stage. IDCC N Ericsson N It is possible to avoid configuring FH and non-FH on the same time-frequency resources by proper configuration. For example, the PRB index and location of the UL BWP for RedCap can be properly configured to achieve this. Intel N FL5 Most received responses express that no specification changes are necessary to support multiplexing of non-FH and FH PUCCH transmissions in PUCCH resources. 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] R1-2112593 Reply LS on use of NCD-SSB for RedCap UE RAN4, ZTE [39] R1-2112599 Reply LS on the use of NCD-SSB instead of CD-SSB for RedCap UEs RAN2, Ericsson [40] R1-2112497 FL summary #1 on reduced maximum UE bandwidth for RedCap Moderator (Ericsson) [41] R1-2112498 FL summary #2 on reduced maximum UE bandwidth for RedCap Moderator (Ericsson)