3GPP TSG-RAN WG1 Meeting #108-e Draft R1-2202529 e-Meeting, 21st February 每 3rd March 2022 Agenda Item: 8.6.1.1 Title: FL summary #2 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] 每 [27] submitted to agenda item 8.6.1.1 and relevant parts of contributions [28] 每 [35] submitted to other agenda items and captures this email discussion on reduced maximum UE bandwidth: [108-e-R17-RedCap-01] Email discussion for maintenance on aspects related to reduced maximum UE bandwidth 每 Johan (Ericsson) 1st check point: February 25 Final check point: March 3 According to the latest WI status report, the following remaining details pertaining to reduced UE bandwidth are expected to be addressed during CR/maintenance phase in Q1 2022: Clarification of UE behavior when separate initial DL BWP is not configured Presence of SSB transmission in separate initial DL BWP in connected mode for BWP#0 configuration option 1 Remaining details of common PUCCH resource determination If needed, address RAN2/RAN4 feedback on RAN1 working assumptions on DL BWP operation (see R1-2112802) 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 FL3. The first FLS in this discussion can be found in [42]. Follow the naming convention in this example: RedCapBwFLS1-v000.docx RedCapBwFLS1-v001-CompanyA.docx RedCapBwFLS1-v002-CompanyA-CompanyB.docx RedCapBwFLS1-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 RedCapBwFLS1-v002-CompanyA-CompanyB.docx. CompanyC uploads an empty file named RedCapBwFLS1-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 RedCapBwFLS1-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-2200852), 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. FL3 Question 1-1a: Please consider entering contact info below for the points of contact for this email discussion. Company Point of contact Email address vivo Xueming Pan panxueming@vivo.com Nordic Karol Schober karol.schober@nordicsemi.no Spreadtrum Huayu Zhou huayu.zhou@unisoc.com FUTUREWEI Vip Desai vipul.desai@futurewei.com Qualcomm Jing Lei leijing@qti.qualcomm.com Intel Debdeep Chatterjee debdeep.chatterjee@intel.com Ericsson Sandeep Narayanan Kadan Veedu sandeep.narayanan.kadan.veedu@ericsson.com Nokia, NSB Rapeepat Ratasuk rapeepat.ratasuk@nokia-bell-labs.com CATT Yongqiang FEI feiyongqiang@catt.cn Xiaomi Qin MU muqin@xiaomi.com China Telecom Jing Guo guojing6@chinatelecom.cn NEC Takahiro Sasaki takahiro.sasaki@nec.com Sharp Hiroki Takahashi takahashi.hiroki@sharp.co.jp NTT DOCOMO Mayuko Okano mayuko.okano@docomo-lab.com Lenovo Yuantao Zhang zhangyt18@lenovo.com Samsung Feifei Sun Feifei.sun@samsung.com LGE Jay KIM jaehyung.kim@lge.com ZTE Youjun Hu hu.youjun1@zte.com.cn MediaTek Chiou-Wei Tsai cw.tsai@mediatek.com CMCC Lijie Hu hulijie@chinamobile.com Apple Hong He hhe5@apple.com Separate initial DL BWP One of the FFSs identified in RAN1#106-bis-e is whether the separate RedCap initial DL BWP is always configured if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth: For a cell that allows a RedCap UE to access, network can configure a separate initial DL BWP for RedCap UEs in SIB. FFS: It is always configured if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. Regarding the configuration of a separate initial DL BWP for RedCap when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, the contributions express different views. Few contributions [13, 16, 21, 22, 27] indicate that, considering the UE complexity and specification impacts, the separate initial DL BWP for RedCap should be always configured if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. [13] points out that it needs to be carefully studied that whether to support that the RedCap UE can continue using the location/bandwidth/SCS of CORESET#0 for the initial DL BWP. Meanwhile, several contributions [6, 8, 9, 10, 18, 19, 23, 24, 26, 28] 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 can continue using the MIB-configured CORESET#0 (e.g., its location, bandwidth, SCS, and cyclic prefix). In this case, for TDD, the center frequencies between CORESET#0 and the initial UL BWP for RedCap can be different as long as the total bandwidth of the two is not larger than the RedCap maximum UE bandwidth. Moreover, several contributions [10, 23, 24] mention that, in TDD, the center frequency of CORESET#0 and the initial UL BWP are not necessarily aligned but the total bandwidth of the two is not larger than the RedCap maximum UE bandwidth. Some additional views are expressed as follows: [8]: 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. [16]: A separate initial DL BWP is always configured for RedCap if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. [19]: 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 CORESET#0 is defined as separate initial DL BWP. CORESET#0 can be used during and after initial access. [22]: For a cell that allows RedCap UEs to access, a separate SIB-configured initial DL BWP for RedCap UEs shall always be configured if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UEs bandwidth. [23]: For TDD, the center frequencies between CORESET#0 and the initial UL BWP for RedCap can be different as long as the total bandwidth of the two is not larger than the RedCap maximum UE bandwidth. Otherwise, they are the same. [31]: Support configuration of CORESET#0A in separate initial DL BWP CORESET#0A has same properties as CORESET#0 in terms of size and length FFS: first PRB of CORESET#0A in separate initial DL BWP. Based on the above views, the following proposal related to the RedCap separate initial DL BWP can be considered. FL1 High Priority Proposal 2-1: For the case that the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, down-select between the following two options during RAN1#108-e: Option 1: A separate initial DL BWP is configured for RedCap if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. Otherwise, the UE shall consider the cell as barred. Option 2: The RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. For TDD, the center frequencies of the MIB-configured CORESET#0 and the initial UL BWP are not necessarily aligned, but the total frequency span of MIB-configured CORESET#0 and the initial UL BWP does not exceed the RedCap UE maximum bandwidth. Company Y/N Preferred option (if any) Comments vivo Option 1 (1st preference) Option 2 is also fine with modification For Option 2, even for now the RRC_CONNECTED non-RedCap UE does not support the non-aligned center frequency between DL and UL BWP. Therefore we cannot agree with Option 2 as is, since it will break the legacy rule for center-frequency alignment between DL and UL BWP with the same ID We are fine with proposal 2 if following modification is made: Option 2: The RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. For TDD, the center frequencies of the MIB-configured CORESET#0 and the initial UL BWP needs to be are not necessarily aligned, but the total frequency span of MIB-configured CORESET#0 and the initial UL BWP does not exceed the RedCap UE maximum bandwidth. Otherwise, RedCap UE expects to be configured with separate initial DL BWP Nordic Option 1 As commented, in legacy initial DL BWP is always configured in SIB1. We do not understand why RedCap initial DL BWP should be handled otherwise. Option 1 would automatically also resolve center-frequency issue. There are at least 3 sub-options for Option 2 for TDD Option 2-1 the total frequency span of MIB-configured CORESET#0 and the initial UL BWP does not exceed the RedCap UE maximum bandwidth. Option 2-2: CORESET#0 is within BW of initial UL BWP Option 2-3: CORESET#0 and initial UL BWP is center-frequency aligned, otherwise RedCap UE expects to be configured with separate initial DL BWP We would be fine with Option 2-2 and 2-3 Spreadtrum Prefer Option 1, but can live with Option 2 if it is the majority view and have the modification Option 1 is more simple way to avoid the ※continue-to-use§ mechanism, which is lack of flexibility. For Option 2, if the RedCap UE continues to use the location/bandwidth/＃ of CORESET#0, e.g. during random access, the RedCap UE needs to perform RF retuning for DL/UL switch, when the center frequencies of CORESET#0 and the initial UL BWP are not aligned. It is not complexity and power efficient. Therefore, we share the similar modification as vivo. FUTUREWEI Option 1 and option 2 with modifications Option 1 is straightforward for the UE and eliminates checking by the UE. Option 2 can reduce the signaling overhead, especially if the network chooses not to configure a separate initial DL BWP. We are open to consider options including those mentioned by Nordic and vivo Qualcomm Either Option 1 or Option 2 is fine Intel Prefer Option 2, but ＃ We support Option 2. There is no need to mandate SIB1 signalling when it can be avoided. For most typical deployments in the initial phases when connection density of RedCap UEs is not very large, having the RedCap UEs use CORESET#0 is an desirable option that should be supported efficiently 每 i.e., by not mandating unnecessary overhead from SIB1 (which is already rather large). We should not couple the discussion on DL BWP configuration and center frequency decision. These should be decoupled. For instance, the main issue in this proposal also applies to FDD where the question of center frequency alignment is moot. Even for non-RedCap UEs, there is no requirement on center frequency alignment between CORESET#0 and initial UL BWP. However, there are requirements on alignment defined for BWPs with same BWP index in TDD. So, the details on center frequency alignment in TDD and related requirements/expectations can be discussed and defined separately. Ericsson Y Option 1 Option 1 is the most straightforward solution from specification point-of-view. Option 2 would necessitate specifying yet another UE behavior during initial access and time-consuming discussions related to center-frequency alignment between initial DL BWP defined by MIB-configured CORESET#0 and initial UL BWP during random access. Nokia, NSB Option 2 In our understanding, there is no need to always configure a separate initial DL BWP for RedCap if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth configure. The UE can use CORESET#0 during and after initial access. Therefore, we＊d like to keep this flexibility. LGE Y Option 2 Option 2 is useful in the case where the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth and no separate initial DL BWP is needed, i.e., the MIB-configured CORESET#0 is intended to be used as the initial DL BWP for both non-RedCap and RedCap UEs. In this case, Option 1 still requires the signaling overhead. FL2 Based on the discussion in the online (GTW) session on Monday 21st February, the following updated proposal can be considered. High Priority Proposal 2-1a: For the case that the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, down-select between the following two options during RAN1#108-e: Option 1: A separate initial DL BWP is always configured for RedCap if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. Otherwise, the UE shall consider the cell as barred. Option 2: If a separate initial DL BWP is not configured for RedCap, the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. For TDD, the center frequencies of the MIB-configured CORESET#0 and the initial UL BWP are not necessarily aligned, but the total frequency span of MIB-configured CORESET#0 and the initial UL BWP does not exceed the RedCap UE maximum bandwidth. Qualcomm Y CATT Y Option 2 With Option 2, separate initial DL BWP can still be configured. If configured, then it should be used; if not configured, the CORESET#0 is reused. Xiaomi In our view, there is no need to down-select between these two options. Our first preference is not to mandate the separate initial DL BWP and also guarantee the center frequency alignment in TDD system. E.g., with the following update for option 2 Option 2: If a separate initial DL BWP is not configured for RedCap, the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. For TDD, the center frequencies of the MIB-configured CORESET#0 and the initial UL BWP are not necessarily aligned, but the total frequency span of MIB-configured CORESET#0 and the initial UL BWP does not exceed the RedCap UE maximum bandwidth. But if the majority are OK with this proposal, we can accept it for progress and we prefer option 1 to option 2. vivo Based on the previous round of discussion, we think the following compromised proposal can also be considered for down-selection. (modified a bit for better clarity) Option 3: If a separate initial DL BWP is not configured for RedCap, 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 of the MIB-configured CORESET#0 and the initial UL BWP are aligned If the center frequencies of the MIB-configured CORESET#0 and the initial UL BWP are NOT aligned, RedCap UE expects to be configured with separate initial DL BWP And we would be fine with either option 1 or option3, but not option 2. China Telecom In our understanding, the separate initial DL BWP can be configured for RedCap if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, but not be mandatory. And we can use Option 2 with flexibility and simplification. The center frequency alignment in TDD system is another controversial topic, and it would be hardly to achieve the consistent agreement. Panasonic Y Prefer Option 1. Other than at least "the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0" needs to be agreed for option 2 with the consideration to avoid the overlap with the initial DL BWP for non-RedCap UEs are necessary. The gain in our understanding is signaling optimization if it is sent in SIB1. A separate initial DL BWP case needs to be supported at the end in whatever SIB is used. We don't think to support option 2 is essential correction for the maintenance phase. NEC Y Option 1 Option 1 reuses existing specifications. Removed sub-bullet point of option 1 should be up to RAN2. Sharp Y Option 2 We are OK to down-select from current 2 options of the FL2 proposal. Since option 1 requires additional signalling overhead, we are supportive with option 2 if the center frequency alignment is stable as it is in the FL proposal. NTT DOCOMO Y Option 2 We share the same view as proponents of Option 2 that it is beneficial in terms of signaling overhead reduction and we don＊t see the need that a separate initial DL BWP is always configured for RedCap UE when the initial DL BWP for non-RedCap UE is larger than the maximum BW of RedCap UE. For the sub-bullet in Option 2, we can be flexible on the center frequency alignment of the initial UL BWP and CORESET#0 and/or whether the separate initial UL BWP and CORESET#0 can span larger BW than RedCap UE＊s BW, i.e., RF retuning is required or not. Lenovo Y Option 1 Option 1 is more straightforward and is a common solution for both TDD and FDD. Samsung Y We cannot agree on Xiaomi＊s modification, i.e., we don＊t want to open the door to RF retuning for RedCap UE in TDD. On the other hand, if companies do not want to explicit say that center frequencies of CORESET #0 vs UL BWP, we think it is sufficient to only keep the second part of option 2. We are also fine with original version. Option 2: If a separate initial DL BWP is not configured for RedCap, the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. For TDD, the center frequencies of the MIB-configured CORESET#0 and the initial UL BWP are not necessarily aligned, but the total frequency span of MIB-configured CORESET#0 and the initial UL BWP does not exceed the RedCap UE maximum bandwidth. For option 3, we don＊t see the need to further restrict the center frequency of CORESET #0 and UL BWP, but won＊t object it if this is the majorities＊ view. LGE Y Our preference is Option 2. The Option 2 is more flexible and has the advantage of signaling overhead in the case where sharing the MIB-configured CORESET#0 is intended when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. It would be unfortunate if we cannot agree on Option 2 because of the controversy on sub-bullet of Option 2 on the center frequency alignment. The sub-bullet of Option 2 as proposed in the FL proposal is preferred, but there is room for compromise for us on the sub-bullet of Option 2. Huawei, HiSilicon Y if without the sub-bullet under option 2 - what is the concern of the potential RF retuning for only once (or at least not frequent) during initial access even if the span across corset#0 and UL BWP exceed the max UE BW is not convincing. Also it is very straightforward that if the configured DL BWP is to be used, a UE expect this DL BWP has aligned center frequency with UL while if the corset#0 is to be used, it does not matter where is the configured DL BWP. ZTE, Sanechips Option2 with removing the subbullet. The center frequencies alignment issue is an independent issue, i.e., option1 also need to discuss it. Therefore, it is suggest to remove the subbullet for option2 and discuss it separately. Based on above, the following is proposed High Priority Proposal 2-1a: For the case that the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, down-select between the following two options during RAN1#108-e: Option 1: A separate initial DL BWP is always configured for RedCap if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. Otherwise, the UE shall consider the cell as barred. Option 2: If a separate initial DL BWP is not configured for RedCap, the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. We prefer Option 2 since it can save SIB1 signalling overhead by avoiding mandatory separate BWP configuration. Moreover, if MIB-configured CORESET#0 is aligned with initial UL BWP, there is no need to configure the separate initial DL BWP. If there is no consensus in RAN1, the determination of Option 1 and Option 2 can be left to RAN2 decision, especially for the cell barring issue. Spreadtrum2 Y Our preference is Option 1. In our view, the Cons of Option 1 are mainly the signaling overhead, but it was mentioned by some companies that SIBx may be used for RedCap configuration, in which the signaling overhead is not issue. The Cons of Option 2 are mainly the misalignment b/w CORESET#0 and the separate initial UL BWP. We don＊t think it can be postponed for discussion, since it is critical for RedCap UE in terms of RF retuning during random access. And companies have some restrictions to avoid the RF retuning, and the restrictions are controversial in companies＊ view. Even if we have the consensus on the restrictions and NW follows it, it is highly possible that the separate initial UL BWP is placed at the center of carrier for alignment, which is not welcome by NW vendors. It is almost common understanding that NW vendor would like to place CORESET#0 (SSB) in the center of carrier, and place the separate initial DL BWP (if configured) close to the edge of carrier to avoid the PUSCH fragmentations. From UE perspective, we share the similar view as E/// that there could be ※another UE behavior§, because it is common understanding that typically RedCap UE may receive SIB/paging in CORESET#0 and receive RAR in the separate initial DL BWP close to the edge of carrier. E/// and QC have some figures to show this typical UE behavior, and with this behavior RedCap UE only needs one RF retuning for random access, e.g. (Scheme-1 in RP-213046, QC) The current restriction in Option 2 will cause new UE behavior, i.e. open RF to cover the combined BW of CORESET#0 and the separate initial UL BWP. Furthermore, we are curious about the signaling design aspect. The separate initial DL BWP for RedCap UEs may have the IE like: DownlinkConfigCommonRedCapSIB ::= SEQUENCE { initialDownlinkBWP BWP-DownlinkCommonRedCap, bcch-Config BCCH-Config, pcch-Config PCCH-Config, ... } BWP-DownlinkCommonRedCap ::= SEQUENCE { genericParameters BWP, OPTIONAL, -- Need M pdcch-ConfigCommon SetupRelease { PDCCH-ConfigCommon } OPTIONAL, -- Need M pdsch-ConfigCommon SetupRelease { PDSCH-ConfigCommon } OPTIONAL, -- Need M ... } If we have concern on the signaling overhead of BWP, RAN2 can add something on the default value for it without any RAN1 spec impact, e.g. ※If BWP parameter is not configured, the location, bandwidth, SCS, and cyclic prefix of the BWP can be equal to CORESET#0§. Why do we need the large RAN1 spec impact to save RAN2 signaling overhead? We also propose Option 4 based on Option 1: Option 4: A separate initial DL BWP is always configured for RedCap if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. Otherwise, the UE shall consider the cell as barred. Note: It is up to RAN2 to reduce the signaling overhead of the separate initial DL BWP, e.g. if BWP parameter is not configured, the RedCap UE continues to use the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0 MediaTek It seems center frequency alignment is not a concern with Option 1. As our concern is that UE may have to perform RF retuning for DL reception and UL transmission (for example during random access), we would like to hear from the group some more details about Option 1 in this aspect. For Option 1, when a SIB-configured initial DL BWP is provided to RedCap, Does the center frequency align between the initial DL and UL BWPs, regardless of whether or not it includes the entire CORESET#0? If the common understanding is yes, then it should be captured to Option 1. If it does not include the entire CORESET#0, does UE need to monitor CORESET#0 during initial access including random access? CMCC Y Our preference is Option 2. We prefer gNB is not mandated to configure separate initial DL BWP for RedCap so that gNB can remain flexibility of configuration. For the sub-bullet of Option2, the center frequencies of CORESET#0 and the initial UL BWP to be not necessarily aligned but within RedCap UE maximum bandwidth can avoid retuning and remain some flexibility of the location of CORESET0, which is fine to us. To make Option2 more clear, we suggest the following modification. Option 2: A separate initial DL BWP is configurable for RedCap, If a separate initial DL BWP is not configured for RedCap, the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. For TDD, the center frequencies of the MIB-configured CORESET#0 and the initial UL BWP are not necessarily aligned, but the total frequency span of MIB-configured CORESET#0 and the initial UL BWP does not exceed the RedCap UE maximum bandwidth. Spreadtrum3 In response to MTK (thanks for MTK, since we can clearly understand each side). For Option 1, when a SIB-configured initial DL BWP is provided to RedCap, Does the center frequency align between the initial DL and UL BWPs, regardless of whether or not it includes the entire CORESET#0? If the common understanding is yes, then it should be captured to Option 1. [SPRD]: It is our understanding. We have proposal in our contribution: For TDD, center frequencies are the same for the initial DL and UL BWP during random access for RedCap UEs, no matter whether or not it includes CD-SSB and the entire CORESET#0 or not. We think it is the critical issue on top of some others. If it does not include the entire CORESET#0, does UE need to monitor CORESET#0 during initial access including random access? [SPRD]: In our understanding, UE does not need to monitor CORESET#0 during random access. Paging is outside, so SI update is not possible (SIBx is also outside). 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. Nordic Option 1 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 } Just to note, as per current 38.331 separate initial DL BWP, if configured to overlap with CORESET#0, separate initial DL BWP would require only 16bit + [3bit SCS], because pdcch-ConfigCommon pdsch-ConfigCommon from legacy initial DL BWP can be reused. 16bits will not make much difference in SIB1 coverage, if any at all. This is not a reason for technical objections. We support Xiaomi and VIVO wordings, when it comes to center frequency alignment. Ericsson Y Option 1 Option 1 is straightforward and prevents significant specification impacts and potentially additional UE complexity/power consumption. Moreover, in TDD, cases in which CORESET#0 can be potentially used as initial DL BWP are not common. This is because in this case CORESET#0 can be used only if it is placed close to the carrier edge where initial UL BWP is located, which may not always be feasible. Intel Option 2/ 2A/ 3 We can accept the FL proposal as well as the version with Option 3 from Vivo included. As discussed during the previous GTW call, the issue of center frequency between initial DL BWP based on CORESET#0 and UL BWPs needs resolution for idle/inactive operations (even when SIB1-indicated initial DL BWP for non-RedCap UEs does NOT exceed RedCap UE max BW) and the resolution the group reaches for each case can apply on top of the main bullet of Options 2 or 3. We are also open to update Option 2 to make it similar to Option 3 as: Option 2A: If a separate initial DL BWP is not configured for RedCap, 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 of the MIB-configured CORESET#0 and the initial UL BWP are not necessarily aligned, but the total frequency span of MIB-configured CORESET#0 and the initial UL BWP does not exceed the RedCap UE maximum bandwidth. If the total frequency span of MIB-configured CORESET#0 and the initial UL BWP exceeds the RedCap UE maximum bandwidth, RedCap UE expects to be configured with separate initial DL BWP To Nordic＊s comment on value in SIB1 OH savings 每 SIB1 size has been a concern since before Rel-17. Now, we are dealing with larger payload due to RedCap-specific configurations while UE DL reception performance for RedCap gets worse considering reduced UE capabilities. Thus, a bit more careful and responsible design on RAN1 part would certainly be desirable, especially when the additional OH can be saved without any issue. To Huawei＊s comment ※what is the concern of the potential RF retuning for only once (or at least not frequent) during initial access even if the span across corset#0 and UL BWP exceed the max UE BW is not convincing§ 每 on the need for restrictions on center frequency for TDD in idle/inactive states, if UE is expected to perform RF retuning between the DL BWP and UL BWP that are associated with random access, it would be necessary to discuss switching times/gaps between the different messages in UL and DL, including between Msg1 Tx and monitoring for Msg2, Msg3 Tx to monitoring for Msg3 reTx or Msg4 scheduling, etc., which to us would not be desirable to pursue at this stage due to even more spec efforts in RAN1 and RAN4. Thus, it matters even if the UE needs to retune only once if such retuning is subject to specified tight timelines as are defined for random access. SONY Y Option 1 Agree with Ericsson that option 1 is straightforward and prevents significant specification impacts. Given that we are in the maintenance phase of Rel-17, option 1 would be our preferred approach. Spreadtrum4 We have modification for our proposal Option 4 to avoid misunderstanding. Option 4: A separate initial DL BWP is always configured for RedCap if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. Otherwise, the UE shall consider the cell as barred. Higher layer parameter BWP may or may not be configured. If the BWP is not configured, the RedCap UE continues to use the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. For TDD, the total frequency span of MIB-configured CORESET#0 and the initial UL BWP does not exceed the RedCap UE maximum bandwidth. Actually, current Option 4 and Option 2 are not different in essence. The tiny difference is the place of optionality. It is not so controversial now. For Option 4, the possible IE of the separated initial DL BWP could be: DownlinkConfigCommonRedCapSIB ::= SEQUENCE { initialDownlinkBWP BWP-DownlinkCommonRedCap, ... } BWP-DownlinkCommonRedCap ::= SEQUENCE { genericParameters BWP, OPTIONAL, -- Need M pdcch-ConfigCommon SetupRelease { PDCCH-ConfigCommon } OPTIONAL, -- Need M pdsch-ConfigCommon SetupRelease { PDSCH-ConfigCommon } OPTIONAL, -- Need M ... } For Option 2, the possible IE of the separated initial DL BWP could be: DownlinkConfigCommonRedCapSIB ::= SEQUENCE { initialDownlinkBWP BWP-DownlinkCommonRedCap, OPTIONAL, -- Need M ... } BWP-DownlinkCommonRedCap ::= SEQUENCE { genericParameters BWP, pdcch-ConfigCommon SetupRelease { PDCCH-ConfigCommon } OPTIONAL, -- Need M pdsch-ConfigCommon SetupRelease { PDSCH-ConfigCommon } OPTIONAL, -- Need M ... } By the way, we share the similar view as Intel on the RF retuning for only once during initial access. And we share the similar view as some other UE vendors＊ view, e.g. MTK, that center frequency alignment b/w DL and UL should apply for all cases for RedCap UEs similar as that for non-RedCap UEs. It seems that anything on center frequency alignment is not captured in draft of R17 38.213 for now. If no update, does it mean RedCap UEs follow center frequency alignment in R16 38.213? If the answer is yes, we can live with it. IDCC Option 1 We prefer Option 1 but we are also fine with modifications from Vivo or their proposed option 3. FL3 Among the received responses, there is a larger support for Option 1 than for Option 2. Several responses proposed modifications of the options, and many responses discussed the potential benefits and drawbacks of the different options in terms of center frequency alignment and signaling overhead. Some responses expressing support for Option 2 expressed different preferences regarding the need for center frequency alignment between CORESET#0 and the initial UL BWP in TDD. One response indicated that the signaling overhead difference between the options may be quite small (~16 bits). Based on the received responses, the following updated proposal can be considered. Companies are requested to indicate their ＆Preferred option＊ and ＆Acceptable option(s)＊. High Priority Proposal 2-1b: For the case that the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, down-select between the following options during RAN1#108-e: Option 1: A separate initial DL BWP is always configured for RedCap if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. Option 2a: If a separate initial DL BWP is not configured for RedCap, the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. For TDD, the center frequencies of the MIB-configured CORESET#0 and the initial UL BWP are not necessarily aligned, but the total frequency span of MIB-configured CORESET#0 and the initial UL BWP does not exceed the RedCap UE maximum bandwidth. Option 2b: If a separate initial DL BWP is not configured for RedCap, the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. For TDD, the center frequencies of the MIB-configured CORESET#0 and the initial UL BWP are not necessarily aligned, but the total frequency span of MIB-configured CORESET#0 and the initial UL BWP does not exceed the RedCap UE maximum bandwidth. Company Preferred option Acceptable option(s) Comments Qualcomm Option 1, Option 2a, 2b Vivo＊s proposal in last round also looks fine to us vivo Option 1 Option 2b Option 2a is not acceptable, as it will break the center frequency alignment principle between TDD DL and UL BWP with the same ID for CONNECTED mode UEs since Rel-15. Suggest the following revision to option 2b to remove the unnecessary restriction that MIB-configured CORSET#0 and initial UL BWP has to be always center-frequency alignment, and if not aligned, network must provide a initial DL BWP configuration. Option 2b: If a separate initial DL BWP is not configured for RedCap, the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. For TDD, it is only applicable when the center frequencies of the MIB-configured CORESET#0 and the initial UL BWP are not necessarily aligned, but the total frequency span of MIB-configured CORESET#0 and the initial UL BWP does not exceed the RedCap UE maximum bandwidth. Spreadtrum5 Option 1 or Option 4 TBD Option 1 is our first preference. We also support the proposed Option 4 for compromise b/w Option 1 and 2. Option 4: A separate initial DL BWP is always configured for RedCap if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. Higher layer parameter BWP may or may not be configured. If the BWP is not configured, the RedCap UE continues to use the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0. For TDD, the total frequency span of MIB-configured CORESET#0 and the initial UL BWP does not exceed the RedCap UE maximum bandwidth, or the center frequencies of the MIB-configured CORESET#0 and the initial UL BWP are not necessarily aligned. Apple Opt.1 Opt.2b Same concerns as vivo on Opt.2a. Support the revised opt.2b from vivo. DOCOMO Opt.2a Opt.2b, Opt.1 Our preference is still option 2 not to mandate gNB to configure separate initial DL BWP from signaling overhead reduction perspective. If the concerns of option 2 is RF retuning between separate initial UL BWP and CORESET#0, we would like to note that both option 2a and option 2b don＊t require RF retuning. Furthermore, we can accept center frequency alignment of separate initial UL BWP and CORESET#0 while we don＊t see the need to restrict them to always be aligned. However, it was pointed out that the overhead would not be considerable, thus, we can accept option 1 if majority of companies support it. Sharp Opt.2a Opt.1, Opt.2b As same reason as 1st round (Signalling overhead), our 1st preference is Option 2a. Several contributions [6, 18, 19, 22, 27] also discuss aspects related to reception of DCI Format 1_0 for RedCap. In particular, when a separate initial DL BWP is configured for RedCap, clarification is needed for the DCI size determination in a CSS. Contributions [18, 19, 22, 27] propose that the size determination for DCI Format 1_0 should be based on the size of CORESET #0. In [6], it is proposed to down-select two options: Option 1: it is determined by the size of CORESET 0, and Option 2: it is determined by the size of the separate initial DL BWP. FL1 Medium Priority Proposal 2-2: For RedCap UE reception of DCI format 1_0 in a CSS: DCI size always depends on size of CORESET#0. Resource allocation starts at first PRB of CORESET where DCI format has been received Company Y/N Comments vivo Y Nordic Y We assume, this should be a Conclusion, as no spec change needed. FUTUREWEI Before a decision is made, we should consider some implications of DCI size bullet. If a separate initial DL BWP is provided, then its size must be at least the size of CORESET#0. A network implementation may want to consider a different size for the separate initial DL BWP. Another point is the RB alignment for a CORESET (starting at multiple of 6 RBs). It may not be possible to ensure RB alignment, TDD center frequency alignment and size. Qualcomm Y Intel Y Ericsson Y Nokia, NSB Y LGE Y FL2 The online (GTW) session on Monday 21st February made the following conclusion: Conclusion: For RedCap UE reception of DCI format 1_0 in a CSS: DCI size always depends on size of CORESET#0. Resource allocation starts at first PRB of CORESET where DCI format has been received SSB for BWP#0 configuration option 1 in connected mode Another open issue is related to presence of SSB in a separate initial DL BWP when used in connected mode for BWP#0 configuration option 1. Several contributions argue that for BWP#0 configuration option 1, the use of initial DL BWP in connected mode is very limited from functionality and power saving point of view [9, 16, 19]. Also, these contributions indicate that based on RAN2 feedback, NCD-SSB is not provided for the initial DL BWP. Therefore, several contributions propose that, for BWP#0 configuration option 1, the UE does not expect SSB in the separate initial DL BWP that is configured for random access when it is used in connected mode [9, 10, 16, 19, 24]. In [12], it is noted that BWP#0 configuration option 1 can be supported for RedCap UE irrespective of the presence of CD-SSB and entire CORESET#0 in a separate initial DL BWP. Contribution [5] mentions that a RedCap UE can use BWP#0 option 1 in the connected state if the RedCap UE is configured with a separate initial DL BWP that contains CORESET#0/SSB. However, one contribution [17] argues that a RedCap UE can expect to be provided with NCD-SSB transmission in the separate initial DL BWP. Based on the above views, the following proposal can be considered: FL1/FL2 High Priority Proposal 3-1: For BWP#0 configuration option 1, if the separate initial DL BWP is used in connected mode and it is only used for random access, the UE does not expect it to always contain SSB. Company Y/N Comments vivo N Firstly, we need to have a decision whether to allow BWP#0 configuration option 1 for the initial DL BWP configuration. From our perspective, we do not see the benefits/motivation to support BWP#0 configuration option 1 to configure the separate initial DL BWP, using BWP#0 configuration option 2 might be sufficient. Even if BWP#0 configuration option 1 is allowed for separate initial DL BWP configuration, it is not clear to us how to capture the proposal 3-1 into specification, as to our understanding it is hard to define a BWP in connected mode ※only used for random access purpose§, i.e. to prevent other scheduling beyond random access. Nordic Y, but If this would be the case for short time until UE gets dedicated RRC, we would be fine. Otherwise, UE not supporting optional capabilities would be in trouble. Spreadtrum Maybe N We are not sure whether or not RAN1 should have the further agreement on it. The previous agreement has such meaning already, and in spec 38.213, ※during random access§ is written as ※monitoring Type1-PDCCH§ which is also fine for connected mode. 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. Qualcomm N First of all, it is necessary to clarify the relationship between RedCap-specific DL BWP#0 configured by option 1 and the separate initial DL BWP of idle/inactive RedCap UE. If the separate initial DL BWP of RedCap UE does not contain the entire CORESET#0 and Type-2 PDCCH CSS, an idle/inactive RedCap UE does not need to monitor paging when performing random access in the separate initial DL BWP. However, whether or not the separate initial DL BWP contains SSB depends on the BWP configuration. If DL BWP#0 configured by option 1 includes the entire initial DL BWP separately configured for idle/inactive RedCap UE, the following examples indicate BWP#0 contain CD-SSB or NCD-SSB. Intel N Similar concerns as Vivo 每 it is not clear how ※only used for random access procedure§ or the case mentioned by Nordic ※If this would be the case for short time ＃§ can be specified or enforced. Once the RRC connection is setup, the UE may simply be kept on this BWP for connected mode operations by the gNB. In such a case, the UE without optional capability to operate without SSB in (RRC configured) DL BWP cannot function since the basic challenge for the UE＊s inability is same as for a RRC-configured DL BWP in this case. Thus, we think for BWP#0 configuration option 1, UE can expect NCD-SSB if CD-SSB is not included. Alternatively, we are also fine with the suggestion from Vivo to preclude use of BWP#0 configuration option 1 for BWP#0 for RedCap UEs. Ericsson Y The proposal is consistent with the UE behavior in idle/inactive mode. If the UE does not expect SSB while performing random access in idle/inactive mode, the UE should not expect it while performing random access in connected mode. The proposal could be modified as follows for more clarity: FR1 and FR2 For BWP#0 configuration option 1, if the separate initial DL BWP, which does not include CD-SSB, is used in connected mode and it is only used for random access, the UE does not expect it to always contain SSB. Note that after initial access the use of initial BWP is not very likely for BWP#0 configuration option 1, as the UE typically operates on a non-initial BWP (e.g., BWP#1). However, in some cases, the UE may fallback to BWP#0 for performing random access. Nokia, NSB Y Our view is that the if the BWP is only used for random access, then there is no need for the BWP to contain SSB. Our view is that the use case for BWP#0 configuration option 1 in connected mode is very limited. Likely UE will be switched to RRC-configured BWP later on. LGE Y CATT Y Just to remind that, in BWP#0 configuration option 1, only SIB1 configuration is applied in initial DL BWP. There is no UE-dedicated RRC configuration in the initial DL BWP. Meanwhile, NCD-SSB can only be indicated via UE-dedicated RRC signaling. As RAN2 is not going to pursue NCD-SSB in IDLE mode, configuring NCD-SSB in initial DL BWP will be contradictory to the definition of BWP#0 configuration option 1 itself. Xiaomi N We have similar view with vivo. And we are also not clear how to guarantee this initial DL BWP is only used for RACH. In addition, the initial DL BWP configured via BWP#0 configuration option 1 can also be used as default BWP for BWP switch when default BWP ID is not explicitly configured. Then in this case, at least NCD-SSB is expected. vivo2 N About Ericsson＊s comments for the following ※However, in some cases, the UE may fallback to BWP#0 for performing random access.§ It is not possible that the BWP#0 configured by configuration option 1 for a connected UE is only used for RACH based on following spec in TS 38.213 If a UE is provided - one or more search space sets by corresponding one or more of searchSpaceZero, searchSpaceSIB1, searchSpaceOtherSystemInformation, pagingSearchSpace, ra-SearchSpace, and - a C-RNTI, an MCS-C-RNTI, or a CS-RNTI the UE monitors PDCCH candidates for DCI format 0_0 and DCI format 1_0 with CRC scrambled by the C-RNTI, the MCS-C-RNTI, or the CS-RNTI in the one or more search space sets in a slot where the UE monitors PDCCH candidates for at least a DCI format 0_0 or a DCI format 1_0 with CRC scrambled by SI-RNTI, RA-RNTI, MsgB-RNTI, or P-RNTI. Panasonic Y NEC N For BWP#0 configuration option 1, we don＊t consider the proposed case exists where an initial BWP (assumed to be BWP#0) is used in CONNECTED. In our understanding, a separate initial BWP is not an active BWP and would not be used in connected for BWP#0 configuration option 1. It would be BWP#0 configuration option 2 to use a separate initial DL BWP in connected. Sharp Y We share same view with Nokia, NSB. RedCap UEs basically operate in dedicated BWP in connected mode and the use case of BWP#0 configuration option 1 is limited. NTT DOCOMO Y We support the updated proposal by Ericsson. Lenovo Y Samsung Y Similar view as Ericsson and Nokia Regarding on vivo＊s comment, we don＊t think it is necessary/mandatory for NW to provide other SS than SS for RAR in BWP #0. Huawei, HiSilicon Y It is written in spec already that the BWP#0 with option 1 can only be used with limited manner as in 331 for example because the UE does not have any dedicated configuration to monitor other PDCCHs or other UE specific functions, thus it can only be used for random access. Function wise it is the same as an initial DL BWP in idle state. TS38.331, Clause B.2 For option #1: ＃ the BWP#0 is not considered to be an RRC-configured BWP, i.e. UE only supporting one BWP can still be configured with BWP#1 in addition to BWP#0 when using this configuration. The BWP#0 can still be used even if it does not have the dedicated configuration, albeit in a more limited manner since only the SIB1-defined configurations are available. For example, only DCI format 1_0 can be used with BWP#0 without dedicated configuration, so changing to another BWP requires RRCReconfiguration since DCI format 1_0 doesn't support DCI-based switching. ZTE, Sanechips Y From our understanding, one search space is possible to be configured in the separate initial DL BWP. And the the update from Ericsson is fine with us. If only short-time transmission is on the separate initial DL BWP which does not contain CD-SSB, we are OK to support. Spreadtrum2 N With further check, it seems that BWP#0 configuration Option 1 means the a bit higher UE complexity, since 38.331 said ※UE only supporting one BWP can still be configured with BWP#1 in addition to BWP#0 when using this configuration§. Thus, BWP#0 configuration Option 1 may not be supported by RedCap UE necessarily. We suggest listing the two Alternatives for this proposal to reflect the current situations. Down-select the alternatives: Alt-1: For BWP#0 configuration option 1, if the separate initial DL BWP is used in connected mode and it is only used for random access, the UE does not expect it to always contain SSB. Alt-2: BWP#0 configuration option 1 is not supported by RedCap UEs. As UE vendor, we slightly prefer Alt-2 but are open for NW flexibility. MediaTek Y if spec supports In principle, we support FL＊s proposal so that the case without SSB can be limited to a separate initial DL BWP via BWP#0 configuration option 1 and it is configured for RACH only. But if it is not clear to the group whether the specification supports to configured a BWP for RACH only as vivo has pointed out, we prefer vivo＊s proposal that BWP#0 configuration option 1 is not used for the separate initial DL BWP. We think FL1/FL2 High Priority Question 3-2 below can be discussed together with this proposal for completeness. CMCC Y Similar view as CATT, since RedCap does not expect NCD-SSB in idle/inactive mode when separate initial DL BWP is configured for RACH but not paging, NCD-SSB is not configured in SIB. In connected mode, based in definition of BWP#0 configuration option 1, there is no way to configure NCD-SSB in separate initial DL BWP since there is no UE-dedicated RRC configuration. FUTUREWEI Y This behavior is consistent with the separate initial DL BWP during initial access Intel2 N We continue to share the same concerns voiced by vivo2. There is nothing in the specs that can guarantee that UE is only scheduled for random access and not kept in the BWP#0 in RRC connected state. To CATT/CMCC＊s comments on apparent contradiction with RAN2 decisions. We do not think so. RAN2 decisions do NOT mean that configuration of NCD-SSB for separate initial DL BWP cannot be indicated via SIB signaling 每 the decision is regarding the expectation of NCD-SSB for paging monitoring in idle/inactive modes. IDCC We have the same concern as Vivo. How can we restrict the BWP to random access only? FL3 One received response points out that the case under discussion may already be supported by the specification. Consider the following specification text from TS 38.213 V17.0.0 clause 17.1: For an initial DL BWP provided by initialDownlinkBWP in DownlinkConfigCommonRedCapSIB, if a UE monitors PDCCH according to a Type1-PDCCH CSS set and does not monitor PDCCH according to Type2-PDCCH CSS set, the UE assumes that the initial DL BWP does not include SS/PBCH blocks or the CORESET with index 0. The above specification text indicates that a RedCap UE monitoring Type1-PDCCH (RA) CSS but not Type2-PDCCH (Paging) CSS does not expect SSB/CORESET#0. High Priority Question 3-1a: Considering the above specification text, is some specification change required regarding the SSB presence in a separate initial DL BWP used by a RedCap UE in connected mode for BWP#0 configuration option 1? If yes, please describe the required changes in the Comments field. Qualcomm As we commented before, the separate initial DL BWP configured for RA but not for paging can include CD-SSB actually (please see the illustration below). Therefore, the 213 spec text in V17.0.0 can be updated as follows: For an initial DL BWP provided by initialDownlinkBWP in DownlinkConfigCommonRedCapSIB, if a UE monitors PDCCH according to a Type1-PDCCH CSS set and does not monitor PDCCH according to Type2-PDCCH CSS set and if the initial DL BWP does not contain SS/PBCH blocks indicated by ssb-PositionsInBurst in SIB1 or in ServingCellConfigCommon, the UE assumes that the initial DL BWP does not include SS/PBCH blocks or the CORESET with index 0. vivo From our understanding, the quoted spec text was intended to describe the IDLE/INACTIVE mode UE behavior, i.e. the following part of agreement made in RAN#107e (copied below). However, here we are discussing the CONNECTED mode UE behavior, which is a separate issue. 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. Spreadtrum5 Agree with QC and vivo for interpretation of the agreement. As most of UE vendors we don＊t like BWP#0 configuration Option 1. There are two alternatives for now. The current spec seems supporting Alt-1, but most UE vendors would not support Alt-1. Down-select the two alternatives: Alt-1: For BWP#0 configuration option 1, if the separate initial DL BWP is used in connected mode and it is only used for random access, the UE does not expect it to always contain SSB. Alt-2: BWP#0 configuration option 1 is not supported by RedCap UEs. Apple We have same understanding as vivo regarding the quoted spec context, i.e., it is for RRC_IDLE and RRC_INACTIVE UEs to implement the previous agreement highlighted by vivo. What we are discussing here is for RRC_CONNECTED UEs after completing the initial access procedure. DOCOMO N Sharp N FL1/FL2 High Priority Question 3-2: For BWP#0 configuration option 1, should it be supported to use the separate initial DL BWP in connected mode for other purposes than random access? If the answer is yes, please comment in the Comments field on whether the UE should expect it to always contain SSB. Company Y/N Comments vivo Firstly, we need to have a decision whether to allow BWP#0 configuration option 1 for the initial DL BWP configuration. From our perspective, we do not see the benefits/motivation to support BWP#0 configuration option 1 to configure the separate initial DL BWP, using BWP#0 configuration option 2 might be sufficient. Even if BWP#0 configuration option 1 is allowed for separate initial DL BWP configuration, it is not clear to us how to capture the proposal 3-1 into specification, as to our understanding it is hard to define a BWP in connected mode ※only used for random access purpose§, or ※for other purposes than random access§. Nordic N BWP#0 in Option 1 is used in legacy only until UE gets dedicated RRC. So clearly not meant for RRC connected mode. Spreadtrum Maybe N For connected mode, gNB can also configure the CSS in the UE-specific DL BWP. For BWP#0 configuration Option 1, if gNB configures the CSS (SIB/paging) in the separate initial BWP, RedCap UE should retune RF to monitor the CSS outside the active DL BWP, no matter the separate initial DL BWP contains SSB or not. Indeed, from the RAN plenary conclusion: Scheme 1 (i.e. UE in IDLE and INACTIVE monitors paging in an initial BWP associated with CD-SSB) is adopted for further work in Rel-17. Scheme 2 (i.e. UE in IDLE and INACTIVE monitors paging in an initial BWP associated with NCD-SSB) is not considered further in Rel-17. RAN2 should work on the assumption that the cell reselection measurements and cell ranking are performed based on measurements on the CD-SSB. This applies for intra- and inter-frequency measurements, and for IDLE and INACTIVE states. it seems more feasible that RedCap UE should receive SIB/paging in CORESET#0. Therefore, we think for BWP#0 configuration Option 1, RedCap UE should receive SIB/paging in CORESET#0, although we share the similar view as vivo that gNB should avoid such power inefficient configuration for UE. Qualcomm FFS This issue has lower priority than other discussion points. Intel Y As responded to Proposal 3-1, in this case is supported, UE can expect presence of SSB in the DL BWP. @Nordic - We are not sure if there is anything in the specifications that enforce that a UE cannot be scheduled in BWP#0 after RRC connection setup if option 1 is used. It is up to gNB choice if the UE is to remain in BWP#0 for option 1 even after RRC connection setup. Ericsson Y In principle (as in legacy), for BWP#0 configuration option 1, an initial DL BWP can also be used in connected mode albeit with a limited functionality as it does not have UE-specific configurations. Also, the initial BWP can act as a default BWP which can be used for the purpose of power saving after the initial access (i.e., in connected mode). As per RAN1 agreements, the UE expects SSB if the initial DL BWP is used for paging. Nokia, NSB Y Our view is that the use case for BWP#0 configuration option 1 in connected mode is very limited. Likely UE will be switched to RRC-configured BWP later on. However, we believe it should still be possible to use this in connected mode. However, if it is used for connected mode then the BWP should contain SSB. LGE Not sure if we need to restrict the usage of the separate initial DL BWP in connected mode to the random access only for BWP#0 configuration option 1. Also not sure if this discussion will lead to any specification impact. But, we are open for further discussion during this meeting. CATT FFS We do not see too much use cases but open to discuss. For BWP#0 configuration option 1, only SIB1 configuration can be applied, hence Type 3 CSS and USS are not considered: Possible use may include paging in CONNECTED mode, or transmission of RRC configurations/UE capability report in a short period. Xiaomi Y Can also be used as default BWP for BWP switch when default BWP ID is not explicitly configured. vivo2 Based on above companies＊ comments, seems the majority share the views that BWP#0 configuration option 1 in connected mode is very limited and the UE should be switched to RRC-configured BWP once connection is established. If so, it is reasonable to exclude the atypical configuration that using BWP#0 configuration option 1 to configure the separate initial DL BWP for RedCap UEs. Panasonic Y The UE should expect it to always contain SSB if the paging PDCCH is configured for the BWP. NEC Same comments as above. Sharp Y We don＊t need to exclude the use case of BWP#0 configuration option 1 in connected mode for other purpose. Then if paging is configured for the BWP#0, SSB should be contained within the BWP#0. NTT DOCOMO Y We share the same view with Intel, Ericsson and Nokia that an initial DL BWP can be used in connected mode even for BWP#0 configuration option 1. Regarding the presence of SSB, in our understanding, if a separate initial DL BWP with BWP#0 configuration option 1 is used in RRC connected mode and it does not include CD-SSB, a UE cannot expect SSB transmission in the initial DL BWP since the UE does not have dedicated configuration regarding SSB reception with the initial DL BWP. Lenovo Y We have similar view with DOCOMO. Samsung We don＊t see the potential spec changes for this issue. We think current agreement works. Huawei, HiSilicon We don＊t see how to work for other purposes but open to hear. For now with limited spec impact in mind, we think it＊s Ok to not open too many possibilities. Also, for companies that are not clear the use of BWP#0 with option 1 and/or proposing to preclude this case for RedCap, we would appreciate if you can share your view to the discussion over thread [108-e-NR-CRs-16] assuming you also agree this would not be used in real site even for R15. ZTE, Sanechips Y To avoid frequent BWP switching or RRC reconfiguration, short-time transmission can be supported in the BWP#0, including RRC configuration, UE capability report. Spreadtrum2 N Again, we think BWP#0 configuration Option 1 has a bit higher UE complexity. And we agree QC to postpone the discussion on BWP#0 configuration Option 1, since BWP#0 configuration Option 1 is not the must and CSS only in the initial DL BWP is not the must. The worst thing is only gNB has to use BWP#0 configuration Option 2 or configure CSS in the active DL BWP in connected mode. In this sense, this issue is also not critical. We suggest listing the two Alternatives for this proposal to reflect the current situations. Down-select the alternatives: Alt-1: For BWP#0 configuration option 1, if the separate initial DL BWP is used in connected mode and it is used for other purposes than random access, the RedCap UE expects it to always contain SSB. Alt-2: BWP#0 configuration option 1 is not supported by RedCap UEs. As UE vendor, we slightly prefer Alt-2 but are open for NW flexibility. By the way, Alt-1 is related to High Priority Proposal 4-1a. MediaTek We understand that the current spec (for legacy UE) does not prevent initial BWP configured by BWP#0 configuration option 1 from being used in connected mode. However, in principle, we would like to minimize the number of cases that UE cannot expect SSB on its BWP at least in connected mode. Proposal: For a separate initial DL BWP configured by BWP#0 configuration option 1, Alt-1: RedCap UE does not expect it is used in connected mode for other purposes than random access. Alt-2: RedCap UE expects SSB presence if it is used in connected for other purposes than random access As we mentioned, this can be discussed with FL1/FL2 High Priority Proposal 3-1. CMCC Y RedCap may be scheduled in separate iDL BWP based on SIB1-defined configuration when the number of non-initial RRC-configured DL BWP is less than 4. RedCap may use separate iDL BWP as default BWP. Thus, the use of separate iDL BWP is not limited to only for RACH, the use of BWP#0 configuration option 1 for RedCap UEs in connected mode should not be precluded. Regarding SSB in separate iDL BWP, when separate iDL BWP contains CD-SSB, there is no problem. When separate iDL BWP does not contain CD-SSB, it is not necessary to mandate transmission of additional SSB, besides, the UE does not have dedicated RRC configuration for NCD-SSB with BWP#0 configuration option 1. FUTUREWEI In our understanding, there are two types of separate initial DL BWP: one with CORESET#0/CD-SSB and another with neither CORESET#0 nor SSB. For the former, the separate initial DL BWP has a SSB and that BWP can be used for BWP#0 option 1 (like legacy). For the latter, it seems an SSB is needed for use besides RACH (e.g. paging) IDCC Y FL3 This topic can be revisited later in this meeting once other topics have seen further progress. Update of RAN1 working assumptions on DL BWP operation The remaining working assumptions from RAN1#107e are as follows for FR1. There are similar working assumptions for FR2. 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 ? Regarding use of NCD-SSB in idle mode operation, RAN#94-e made the following agreement [36]. Scheme 1 (i.e., UE in IDLE and INACTIVE monitors paging in an initial BWP associated with CD-SSB) is adopted for further work in Rel-17. Scheme 2 (i.e., UE in IDLE and INACTIVE monitors paging in an initial BWP associated with NCD-SSB) is not considered further in Rel-17. RAN2 provided feedback [38] on the RAN1 working assumption on use of CSI-RS in DL BWPs for RedCap UEs [37]: Regarding the following working assumption for FR1 and FR2 related to an RRC-configured active DL BWP in connected mode: ※A RedCap UE can in addition optionally support relevant operation based on CSI-RS§ The use of CSI-RS for cell/beam RLM and measurements is supported from RAN2 signalling standpoint as indicated earlier. RAN4 has informed RAN2 and RAN1 that CSI-RS cannot be used as a standalone mechanism for RRM measurements and existing requirements rely on the presence of SSB signals, in their reply LS provided in R4-2120327. RAN2 does not intend to introduce a new mechanism that would enable a RedCap UE to perform CSI-RS based RRM measurements and think that it is up to RAN4 to decide whether RAN1 working assumption regarding the use of CSI-RS in connected mode is acceptable based on the information provided above. RAN4 provided feedback [41] on the RAN1 working assumption on use of CSI-RS in DL BWPs for RedCap UEs [37]: 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 that supports FG 6-1a but NOT support CSI-RS based L3 measurement operates in the BWP the UE can support RLM, BFD, CBD and L1 RSRP measurement based on CSI-RS if UE reports the corresponding capabilities. the UE can support SSB based L3 measurement but cannot support CSI-RS based L3 measurement. A RedCap UE that supports FG 6-1a and CSI-RS based L3 measurement operates in the BWP the UE can support RLM, BFD, CBD and L1 RSRP measurement based on CSI-RS if UE reports the corresponding capabilities. the UE can support both SSB based L3 measurement and CSI-RS based L3 measurement with associated SSB. RAN4 will not define CSI-RS L3 based measurement requirements for Redcap 1RX UE in Rel-17. For serving cell timing related requirements, RAN4 will not define requirements based on CSI-RS in Rel-17. In addition, regarding NCD-SSB properties, RAN4 provided the following feedback [40]: It is RAN4 assumption that NCD-SSB is ＆QCL＊-ed with CD-SSB when the NCD-SSB and CD-SSB shares the same SSB index. Based on the received feedbacks, several contributions [5, 13, 15, 16, 17, 19, 23] propose to update the above working assumptions identified in RAN1#107e. In particular, it is proposed to remove (do not confirm) the working assumption about paging considering that in Rel-17 RedCap UE in idle/inactive mode monitors paging only in an initial BWP associated with CD-SSB. Also, a few contributions [5, 15, 16, 23] indicate that the working assumption regarding ※Not need NCD-SSB§ may need to be revised considering that CSI-RS is not used as a standalone mechanism for RRM measurements in Rel-17. However, two contributions [10, 19] propose to confirm the working assumption about ※Not need NCD-SSB§. Some other presented views are summarized below: [15]: Operation based on CSI-RS in an active BWP without either CD-SSB or NCD-SSB should not be considered in Rel-17 because RAN4 will not define requirement for it in Rel-17. [27]: Do not confirm the working assumption about CSI-RS and focus only on design of capability FG 6-1 by means of retuning gaps. [29]: The time offset of each NCD-SSB is explicitly configurable by the network, which could be different from that of CD-SSB in the same network. [29]: For a RedCap UE, at most one SSB can be configured within its active BWP. [30]: It is up to UE implementation about whether to receive the SIB when the UE retunes to CORESET0 and retunes back to separate initial UL BWP for RSRP measurement due to msg1/A retransmission. [33]: When initial DL BWP is shared or separate initial DL BWP contains legacy initial DL BWP, additional RedCap specific paging and RAR search space are supported. [35]: It is proposed update the description and figures corresponding to BWP#0 configuration for RedCap UEs in RAN2 specifications. Some contributions discuss UE capability aspects (something which is also discussed under agenda item 8.16.6): [7]: Legacy behavior shall be followed that the RedCap UE can support CSI-RS based L3 measurement with associated SSB and RLM, BFD, CBD, L1 RSRP measurement based on CSI-RS if UE reports the corresponding capabilities. [12]: It is not necessary to either specify RedCap UE dedicated UE capability signaling or update existing UE features in the current specification which indicate the support of CSI-RS based operation for L3 measurement, RLM, BFD, CBD and L1 RSRP measurement. [13]: Remove ※CORESET#0§ or add a note in FG 6-1/6-1a/6-2/6-3/6-4. The note is ※For RedCap UE, CORESET#0 here means CORESET#0 or CORESET of CSS§. [23]: FG 1-5 (※CSI-RS based RRM measurement without associated SS-block§) is not applicable to RedCap UE. FG 1-4 (※CSI-RS based RRM measurement with associated SS-block§) is not applicable to RedCap UE and add a new UE feature group(s) for RedCap UE to report its support for CSI-RS based RRM measurement with associated SSB. The new UE feature group(s) is to be discussed in AI 8.16.6. FG 6-1a is a prerequisite for the new UE feature group(s). Based on the above views, the following can be considered. FL1 High Priority Proposal 4-1: Replace the working assumption from RAN1#107e ※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§ with the following note based on the RAN plenary agreement [36]: Note (for FR1 and FR2): In Rel-17, a RedCap UE in idle/inactive mode monitors paging only in an initial BWP associated with CD-SSB. Company Y/N Comments vivo Y Nordic Y We agree that paging in separate initial BWP is supported in RRC connected. Wording could be updated/simplified as follows: Note (for FR1 and FR2): In Rel-17, above applies only for RRC connected state. Spreadtrum Y FUTUREWEI Y Qualcomm Y Intel Y Ericsson Y The note could be modified as follows: Note (for FR1 and FR2): In Rel-17, a RedCap UE in idle/inactive mode monitors paging only in an initial BWP (default or RedCap-specific) associated with CD-SSB. Nokia, NSB Y LGE Y FL2 The RAN1 working assumption concerns paging in any RRC state. For idle/inactive mode, RAN2#116bis-e has already made the following agreement: A RedCap UE in idle/inactive mode monitors paging only in an initial BWP (default or RedCap specific) associated with CD-SSB and performs cell (re-)selection and measurements on the CD-SSB Based on the discussion in the online (GTW) session on Monday 21st February, the following updated proposal can be considered, which replaces the RAN1 working assumption with a proposed RAN1 agreement for connected mode only. High Priority Proposal 4-1a: Replace the working assumption from RAN1#107e ※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§ with the following agreement: For FR1, For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, For 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 FR2, For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, For connected mode, if it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. Qualcomm Y CATT Not sure whether this has relationship with BWP#0 configuration option. As far as we expect, BWP#0 configuration option 1 cannot configure any UE-dedicated RRC configuration (e.g. NCD-SSB). Does this proposal mean if separate initial DL BWP is BWP#0 configuration option 1, it shall not be configured for paging in connected mode? Xiaomi Y vivo Y China Telecom We think this proposal should be aligned with High Priority Proposal 3-1and High Priority Proposal 3-2 to avoid ambiguity. Panasonic Y NEC Y Sharp Y NTT DOCOMO Y Samsung N For connected mode paging reception, we wonder if there is a need to transmit paging in a separate (initial) DL BWP. Currently, there may have a case that no paging in active BWP. Since the SCS of the active BWP may not be the same as CORESET #0, it somehow requires RF processing for switching, which is similar as current situation for RedCap. Therefore, we think there is no need to NCD-SSB and paging in separate initial DL BWP in connected mode. If we need some agreements to replace the WA, we suggest the following proposal instead. If it is configured for paging for RRC_CONNECTED mode, RedCap UEs follow the same rule as legacy UEs. LGE Have a similar question to CATT. If the new FL proposal (Proposal 4-1a) is valid only for the BWP#0 configuration option 2, then we wonder if the second bullet on the RRC-configured active DL BWP in connected mode already covers the mandatory NCD-SSB transmission. Huawei, HiSilicon Y ZTE, Sanechips N If paging is configured in the separate initial DL BWP with NCD-SSB in the connected mode, in my understanding, during initial access, the separate initial DL BWP also should contain NCD-SSB, since the paging channel configuration would be changed because of one UE entering the connected mode. However, if the separate initial DL BWP does not include CD-SSB and the entire CORESET#0, this separate initial DL BWP is only used for RACH and the UE does not need to contain SSB. So, it is impossible that the separate initial DL BWP for RACH does not contain NCD-SSB during initial access, while this separate initial DL BWP contain NCD-SSB when the this UE enters the connected mode. It is also impossible that paging is configured in the CORESET#0 associated with SSB during initial access, while paging is configured in separate initial DL BWP with NCD-SSB after this UE enters the connected mode. If above understanding is right, the case in this proposal would not happen and it should not be supported. Spreadtrum2 Y CMCC With BWP configuration option2, for connected mode, no matter whether paging is configured in separate initial DL BWP, separate initial DL BWP is RRC configured BWP, NCD-SSB is expected in BWP. With BWP configuration option1, paging is not configured in separate initial DL BWP in idle/inactive mode when separate initial DL BWP does not contain CD-SSB. In connected mode, based in definition of BWP#0 configuration option 1, we wonder how to configure paging CSS in separate initial DL BWP when there is no UE-dedicated RRC configuration. Nordic Y Based on RAN guidance UE camps on CD-SSB. Since separate Initial DL BWP can be used in RRC connected, it may be re-configured (with sync) with paging SS after MSG4, we do not see any issue here. If RAN2 finds further optimizations necessary, they can agree. ServingCellConfigCommon The IE ServingCellConfigCommon is used to configure cell specific parameters of a UE's serving cell. The IE contains parameters which a UE would typically acquire from SSB, MIB or SIBs when accessing the cell from IDLE. With this IE, the network provides this information in dedicated signalling when configuring a UE with a SCells or with an additional cell group (SCG). It also provides it for SpCells (MCG and SCG) upon reconfiguration with sync. Ericsson See comments If the proposal were to be agreed, RAN1 is essentially agreeing to have the possibility to provide NCD-SSB-related information in SI. Considering that RAN2 has already agreed to provide configuration of NCD-SSB in a dedicated BWP (see agreement copied below), perhaps whether to support paging in connected on a separate initial BWP without CD-SSB can be decided in RAN2. RAN2#116bis-e In RRC connected mode NCD-SSB may be configured for a RedCap UE in dedicated DL BWP. Intel Y To respond to the questions/comments from CATT and LGE: this can apply even for BWP#0 option 1 as clarified in our response related to FL2 Proposal 3-1. Common RRC (SIB signaling) can be used to configure NCD-SSB in such a case as well. IDCC Y FL3 Based on the received responses, the following proposal can be considered, which replaces the RAN1 working assumption with a proposed RAN1 agreement for BWP#0 configuration option 2 and connected mode only. High Priority Proposal 4-1b: Replace the working assumption from RAN1#107e ※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§ with the following agreement: For FR1, For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, For BWP#0 configuration option 2, for 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 FR2, For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective, For BWP#0 configuration option 2, for connected mode, if it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB. Qualcomm Y vivo According to our understanding, BWP#0 configuration option 2 is also an RRC-configured BWP, therefore the updated proposal seems to be covered already by the agreement made in last meeting (as below). Or does it intend to say that RedCap UE always expect NCD-SSB regardless of its capability (FG6-1, or 6-1a), if paging monitoring is configured? 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. Spreadtrum5 Share the similar view as vivo. Apple Per TS 38.331, the BWP#0 configuration option 2 is treated as RRC-configured BWP and consequently has been covered by the agreement highlighted by vivo, i.e., presence of NCD-SSB depends on the support of FG 6-1 or FG 6-1A. Note sure about the intention of the new agreement. DOCOMO Y Sharp Y Based on the online (GTW) session for agenda item 8.16.6 (on the RedCap UE feature list) on Monday 21st February, the following proposal can be considered. FL2 High Priority Proposal 4-1-1: A RedCap UE supports NCD-SSB based operation (including NCD-SSB based measurements) in an RRC-configured DL BWP that does not include CD-SSB. Company Y/N Comments Qualcomm Y We support FL2 proposal. It has no conflict with RAN1#107 agreements for NCD-SSB in terms of RedCap UE＊s capability for SSB-based measurements. Moreover, the proposal is consistent with the reply LS from RAN2 and RAN4 on RedCap UE＊s use of NCD-SSB of serving cell in the RRC-configured DL BWP. CATT Open to hear more views. But our first impression is that this proposal mandates a RedCap UE to support NCD-SSB based operations. We are OK if the majority is fine with it. vivo Y China Telecom Y Panasonic Y NEC Y Sharp Y NTT DOCOMO Y Samsung We think it can be an optional feature, considering the potential support of FG 6-1a. LGE Y In our view, a RedCap UE shall at least support FG 6-1 as a baseline. If this is a common understanding, then what is proposed in the FL proposal should be a basic feature or a component of a basic FG. Huawei, HiSilicon Or modified by below to align with the previous agreements; RedCap UE supports NCD-SSB based operation (including NCD-SSB based measurements) in an RRC-configured DL BWP that does not include CD-SSB if the UE does not indicate support of BWP without SSB. or nothing needs to be additionally agreed. ZTE, Sanechips We can wait for the RAN2 progress since it is in the discussion. Spreadtrum2 Y MediaTek Y We support FL＊s proposal. In fact, our perception of the previous agreement is more towards that all RedCap UEs expect SSB on an RRC-configured BWP, because in the following sub-bullet it says a RedCap UE can ※in addition optionally.§ But if this is different understand than the majority view, we are open to discuss. 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. CMCC Y Nordic Y ※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§ Even though UE supporting FG 6-1a does not require NCD-SSB, it still shall support NCD-SSB as per mandatory feature group FG 6-1, if gNB configures it with NCD-SSB but not with measuring gaps, every RedCap UE must function. This is why we have mandatory features. Ericsson Y It could be clarified that the feature is mandatory for RedCap UEs. Intel Y Same view as MTK and Nordic that it should be a mandatory capability following from the agreement in RAN1 #107-e. IDCC Y FL3 Based on the received responses, the following updated proposal can be considered. High Priority Proposal 4-1-1a: A RedCap UE supports NCD-SSB based operation (including NCD-SSB based measurements) as a mandatory feature in an RRC-configured DL BWP that does not include CD-SSB. Qualcomm Y vivo Y Spreadtrum5 Y DOCOMO Y Sharp Y FL1/FL2 High Priority Question 4-2: Given the feedback from RAN2 and RAN4, can the CSI-RS-related working assumption in the following bullet from the RAN1#107e agreement be confirmed as is? Please provide potential updates or other additional comments regarding CSI-RS-based operation as needed in the Comments field. 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. Company Y/N Comments vivo N Based on RAN4＊s feedback for CSI-based measurement that is always coupled with ※A RedCap UE that supports FG 6-1a [＃]§, it means CSI-RS cannot be used as a standalone method. Therefore, we propose if the WA needs to be confirmed in Rel-17, FG6-1a should be the prerequisite for RedCap UE supporting relevant operations based on CSI-RS. Following update is necessary. 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 if FG 6-1a is supported by reporting optional capabilities. Nordic N Based on the feedback from RAN2 and RAN4 and given this is maintenance. 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. Spreadtrum N Share the similar view as vivo. Qualcomm N It is unclear to us if FG 6-1a implies a legacy UE can measure SSB outside its dedicated DL BWP without a measurement gap. If the answer is ※yes§ for legacy UE, FG 6-1a does not apply to R17 RedCap UE due to BW reduction. Intel N We do not think that the WA can be confirmed based on feedback received from RAN2 and RAN4. The version from Nordic is preferred since use of CSI-RS in this context is mainly for measurements, and towards that, we already have separate optional UE capabilities since Rel-15 for CSI-RS-based L3 msmts, etc. Ericsson Y, but It is clear from the RAN2 and RAN4 replies that CSI-RS cannot be used a standalone mechanism for RRM measurements in Rel-17. Therefore, the UE should rely either on FG 6-1a only or on both FG 6-1a and CSI-RS for these measurements. We propose the following update: Not need NCD-SSB: A RedCap UE can in addition optionally support relevant operation based on for FG 6-1a or both CSI-RS (working assumption) and/or FG 6-1a by reporting optional capabilities. We are also fine with the update proposed by Vivo. Nokia, NSB We are OK with the proposal from vivo. LGE N Either not supporting the CSI-RS based operation or supporting it with existing capabilities is preferred. For the latter, it would be acceptable to us if some changes are made as suggested below. A RedCap UE can indicate the following as optional capability: Not need NCD-SSB: A RedCap UE supporting FG 6-1a can in addition optionally support relevant operation based on for CSI-RS (working assumption) and/or FG 6-1a by reporting optional capabilities. CATT update To make it more accurate, we can update the WA as ※based on FG 6-1a with supporting CSI-RS, or FG 6-1a without supporting CSI-RS§. Ericsson＊s version is fine to us. Xiaomi N We are OK with the update from vivo China Telecom We have the same view with vivo. NTT DOCOMO Y, but We support the updated proposal by vivo and Ericsson that according to RAN4 feedback, CSI-RS based operation can be optionally supported when UE supports FG6-1a. Lenovo N We are fine with the updates from vivo. Samsung Fine with the update from Ericsson. Huawei, HiSilicon Clarification It is OK for the purpose of operation of no-NCD-SSB that CSI-RS can be reported on top of a FG6-1a like FG to make the operation better, however it does not imply that CSI-RS related capabilities themselves can only be supported with 6-1a as pre-requisite. ZTE, Sanechips We are OK with the modification of adding the 6-1a as the precondition. No strong view for the text update above, and they looks similar and OK with us. MediaTek Based on our understanding of RAN2 and RAN4 reply LS, we think FG 6-1a should be a prerequisite. CSI-RS based RRM measurements, i.e FG 1-4 and 1-5, are not supported. We think the WA cannot be confirmed. The following proposal can be considered instead: A RedCap UE can indicate the following as optional capability: Not need NCD-SSB: A RedCap UE supporting FG 6-1a can in addition optionally support relevant operation based on for CSI-RS (working assumption) and/or FG 6-1a by reporting optional capabilities except for CSI-RS based RRM measurements. CMCC Y with modification We agree CSI-RS cannot be used as a standalone method and FG6-1a should be the prerequisite for RedCap UE supporting relevant operations based on CSI-RS Based on LS from RAN4, CSI-RS cannot be used as a standalone method for L3 measurement, RedCap needs to retune to receive associated SSB. But CSI-RS is a standalone method for L1 measurement and can reduce the frequency of retuning for SSB when there is no SSB within BWP. Thus, CSI-RS can be used combined with FG 6-1a. We prefer the update of Ericsson. FL3 Based on the received responses, the following proposal can be considered, which replaces the RAN1 working assumption with a proposed RAN1 agreement. High Priority Proposal 4-2a: Replace the working assumption from RAN1#107e ※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§ with the following agreement: For FR1, 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 CSI-RS (working assumption) and/or FG 6-1a by reporting optional capabilities FG 6-1a with supporting CSI-RS, or FG 6-1a without supporting CSI-RS. For FR2, 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 CSI-RS (working assumption) and/or FG 6-1a by reporting optional capabilities FG 6-1a with supporting CSI-RS, or FG 6-1a without supporting CSI-RS. Qualcomm We think this proposal can be further discussed after a clarification for RedCap UE＊s measurement gap needed for FG 6-1a. For the sake of progress, we can accept this proposal by adding a bracket to FG 6-1a and a FFS note for the measurement gap. vivo Y in general Given the UE feature discussion, we might introduce new FG for RedCap UE ※FG6-1a like§ operation, maybe it would be necessary to add a Note ※FG6-1a may be replaced by a new FG for RedCap UE if agreed in the UE feature session§ Apple We support the proposal from Qualcomm and Vivo, i.e., Add a note: ＆FG6-1a may be replaced by a new FG for RedCap UE if agreed in the UE feature session§ and keep FG 6-1a with bracket. Add ＆FFS on the measurement gap＊ for Recap UEs supporting [FG 6-1a] DOCOMO Y Sharp Y Based on the online (GTW) session for agenda item 8.16.6 (on the RedCap UE feature list) on Monday 21st February, the following question can be considered. FL2 High Priority Question 4-2-1: Should FG 6-1a apply for RedCap? If yes, what updates/clarifications are needed for FG 6-1a (e.g., regarding on measurement gaps)? If no, please comment on what other FG(s) may need to be defined in place of FG 6-1a. Company Y/N Comments Qualcomm If a RedCap UE can optionally support RRC-configured BWP without CORESET#0 and SSB AND needs a measurement gap for L1/L3 measurements of serving cell＊s SSB outside the SSB-less DL BWP , we think it is necessary to introduce a new RedCap-specific FG as such, to differentiate with FG 6-1a defined for non-RedCap UE. CATT We think FG 6-1a can be reused. Not sure if we need to couple measurement gap in FG 6-1a. We already have other FGs related to measurement gap, e.g. FG 4-x, FG 9-x. vivo Feedback from RAN4/2 for FG6-1a on whether the FG6-1a includes both cases with measurement gap and without measurement gap is beneficial. If it also includes the case that without measurement gap, we share QC＊s views that separate FG for RedCap is necessary. NTT DOCOMO In our understanding, there may exist two ways to support SSB-less DL BWP operation; update FG 6-1a or introduce new FG. We slightly prefer the latter one. Huawei, HiSilicon We are ok to define a new FG for BWP operation without SSB, to be clear without CD or NCD-SSB, and the default value if the FG is not reported would mean that the UE expects one of CD-SSB and NCD-SSB (if CD-SSB is not included in the BWP). If FG6-1a is reused it can be clarified that the SSB means neither CD-SSB nor NCD-SSB. ZTE, Sanechips Whether to define a separate FG can be up to the discussion of measurement gap. CMCC If FG6-1a does not include the case with measurement gap, FG 6-1a can be updated or introduce new FG. Nordic We could clarify in RAN1 spec that ※A RedCap UE supporting FG6-1a, if not provided with NCD-SSB in active BWP, expects to be configured with measurement gap for the cell.※ FUTUREWEI Open to reuse FG 6-1a if the modifications are minor or the introduce a new FG if modifications are extensive Ericsson Y With FG 6-1a, an RRC-configured DL BWP does not need to contain both SSB and CORESET#0. In this case: 1) UE may need to do re-tuning to acquire SSB and/or CORESET #0, or 2) UE can further open its RF BW to receive SSB/CORESET#0. Considering the limited BW of RedCap UEs, it is more likely to rely on the re-tuning option which requires defining measurement gaps. (Note that, the option of opening the RF BW should still be considered for RedCap since the bandwidth of SSB/CORESET#0 can also be relatively small depending on the configuration (e.g., CORESET#0 BW with 24 PRBs and 15 kHz SCS: 4.32 MHz)). Intel Y As such, we tend to agree on vivo＊s point that clarification from RAN2/RAN4 on assumption/no assumption on availability of msmt gaps would be helpful towards resolving this. It is not obvious on whether measurement gaps need to be mandated for this case for RedCap UEs. This is an optional capability and the situation is similar to non-RedCap UEs. For non-RedCap UEs, we do not specify any such UE expectation. Thus, our first preference would be to reuse FG 6-1a. IDCC Y FL3 Several of the received responses indicate that the support of operation without SSB in an RRC-configured active BWP could be part of FG 6-1a for RedCap UEs if the update of the FG 6-1a definition is small, but that a new FG should be defined if extensive updates are required. Therefore, the following question can be considered. High Priority Question 4-2-1a: Do RedCap UEs that support operation without SSB (and without CSI-RS) in an RRC-configured active BWP (e.g., FG 6-1a) require configured measurement gaps? Qualcomm Yes Due to BW reduction (e.g. from 100 MHz to 20 MHz in FR1), a RedCap UE cannot open its RF BW to support FG 6-1a without a measurement gap. vivo As confirmed by RAN4 LS, CSI-RS cannot work alone, therefore, even if UE supporting CSI-RS based measurement, it still requires measurement gap for CD-SSB if no SSB is available in the active BWP. So ※(and without CSI-RS)§ should be removed and the answer should be Yes (i.e. requires MG) Apple Yes The measurement GAP is simply caused by the reduced BW and Redcap UE cannot extend RF BW to cover CD-SSB as in legacy. Therefore, we think MG is required even for Redcap UE supporting FG6-1a to perform RRM measurement on CD-SSB. DOCOMO Y We share the same view with Qualcomm. ﹛﹛ Finally, RAN2 has discussed this scenario and how a RedCap UE performs RSRP measurements before Msg1 or MsgA retransmission on separate initial UL BWP and agreed on the following [39]: From RAN2 perspective, if a RedCap UE in idle/inactive mode is configured with a separate initial BWP associated with no SSB (CD or NCD) for RACH, it is up to UE implementation to perform new RSRP measurement in a DL BWP associated with CD-SSB before Msg1/A retransmission. FL1/FL2 Medium Priority Question 4-3: Does the RAN2 agreement regarding RSRP measurement before Msg1/MsgA retransmission require any updates of RAN1 specifications? If yes, please elaborate in the Comments field. Company Y/N Comments vivo N Nordic N FUTUREWEI N Qualcomm Y If RedCap UE needs to measure RSRP for RO re-selection (or RA type re-selection) before msg1/msgA retransmission, the following timeline requirements specified for non-RedCap UE in Clause 8.2 and 8.2A of TS 38.213 do not apply to RedCap UE. Therefore, a clarification for R17 RedCap UE＊s timeline of msg1/msgA retransmission needs to be included in 213 spec. Ericsson We think Qualcomm has a good point. However, RAN4 involvement may be needed to specify the new timeline requirement. LGE N CATT N vivo No We do not think timeline requirement is needed for following reasons: Based on RAN2＊s agreements, it is up to UE implementation to perform new RSRP measurement in a DL BWP associated with CD-SSB before Msg1/A retransmission, so, the UE does not need to measure the SSB before transmitting the PRACH; Even for normal UE, the timeline may not be sufficient to do the SSB measurement before the next PRACH transmission. The next RO selection is decided by the UE, by UE implementation, the gap between the SSB measurement and RO can ensure the sufficient retuning time. NTT DOCOMO We think the timeline for random access which is pointed out by Qualcomm may need to be discussed. Samsung Y Currently, higher layers of UE can indicate to the physical layer to transmit a PRACH, and if requested by higher layers, the UE is expected to transmit a PRACH no later than msec after the last symbol of the window, or the last symbol of the PDSCH reception. If RedCap UE needs to retune to default iDL BWP before PRACH retx, it may not able to meet the restriction. However, on the other hand, UE does not have to do RSRP measurement before Msg1/Msg A retx. We think this at least worth some RAN 1 discussion on whether the restriction of PRACH retx needs to be relaxed or not apply for RedCap UE when there is no CD-SSB in the separate iDL BWP in idle/inactive mode. Huawei, HiSilicon N We think the current RAN2 response already means, if there is any issue as concerned by QC on the timeline, it is up to UE implementation since the UE may also not perform re-selection/re-measure timely. ZTE, Sanechips N No update for msg1. However, similar as msg1, whether the UE behaviour for SSB measurement should be specified is needed to be clarified, when msg2 and msg4 overlaps with the SSB MediaTek Y We share a similar view with Qualcomm and Samsung that PRACH reTx timeline should be revisited based on RAN2＊s agreement. In fact, we support Alt1 from Samsung＊s contribution which is copied and edited below. With this proposal, the current requirement does not apply to RedCap UE. In our view, this is more aligned with RAN2＊s agreement. Proposal: RedCap UE does not follow current time restriction for PRACH re-transmission, i.e., N1+0.75 msec CMCC N It is up to UE implementation whether RSRP measurement is required before Msg1/MsgA retransmission. Intel N Same view as vivo in terms of interpretation of the RAN2 decision. Whether to measure on SSB before reTx and whether to use the earliest available RACH occasion (RO) is up to UE implementation. Further, note that in most typical cases, there may not even be an RO within NT,1 + 0.75 msec of the RAR window, etc. Our understanding of this timing is just to capture the earliest a UE may transmit RACH reTx considering PDSCH and MAC CE processing times assuming RO is available at the earliest opportunity. However, for actual operation, it would be up to UE implementation as explained by vivo. FL3 Most received responses see no need for a RAN1 specification update due to the RAN2 agreement regarding RSRP measurement before Msg1/MsgA retransmission. However, some responses see a need to clarify that a RedCap UE does not need to follow the current time restriction for PRACH retransmission (i.e., NT,1 + 0.75 msec). Based on this, the following proposal can be considered. Medium Priority Proposal 4-3a: If a RedCap UE in idle/inactive mode is configured with a separate initial DL BWP associated with no SSB (CD or NCD) for RACH, The RedCap UE does not need to follow current time restriction for PRACH retransmission, i.e., NT,1 + 0.75 msec. Qualcomm Y vivo N We do not see the need for such proposal at least for now. As explained by companies, ※NT,1 + 0.75 msec after RAR window§ should be understood as the earliest possible timing for PRACH (re)transmission, however, there could be different reasons that UEs cannot transmit PRACH immediately, e.g. no available RO, etc, even in legacy system. If there is different understanding on how to interpret the current spec, we might need to discuss in the CR session first. Apple Y Our understanding is that UE is required to meet the timing requirement in TS 38.213 if there is valid RO. In other words, the processing pipeline at the UE needs to prepare for this, which is challenging for Redcap UE due to additional retuning for measurement and causes additional delay. DOCOMO Y We share the same view as companies above. It was clarified by RAN2 that whether to measure SSB before PRACH retransmission is up to UE implementation and a RedCap UE may or may not be able to comply with the current time restriction for PRACH retransmission. Thus, whether a RedCap UE can follow the time restriction would be up to UE implementation. PUCCH resource determination From RAN1#107-e, we have the following agreement regarding RedCap PUCCH resources (for HARQ feedback for Msg4/MsgB): Agreement: 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[(s)] of the RedCap UL BWP center frequency to which PUCCH resources are mapped is[/are] configurable by the network, including SIB-configurable [additional] offset (with no more than [4] candidate values) using the existing equations for determining the PRB index of the PUCCH transmission as a starting point. 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). Several contributions [4, 5, 6, 7, 9, 10, 12, 14, 16, 17, 19, 20, 24, 26, 27, 28] provided their views on the PUCCH resource determination with disabled frequency hopping in terms of whether both edges of UL BWP can be used or all PUCCH resources are mapped to one edge, 2) maximum number of PUCCH resources, 3) additional PRB offset, and 4) explicit equations. Many of the contributions [5, 6, 7, 9, 10, 14, 16, 17, 19, 20, 24, 26, 27] propose that all PUCCH resources should be mapped to only one edge of the UL BWP considering the purpose of disabling PUCCH frequency hopping for minimizing the UL resource fragmentation. One contribution [4] supports also mapping the PUCCH resources to both edges of the UL BWP. Most of these contributions [4, 5, 6, 9, 14, 16, 17, 19, 24, 26] propose to support the maximum 16 PUCCH resources in case of disabled PUCCH frequency hopping to achieve a higher capacity compared to the case with 8 PUCCH resources. In addition, contributions are generally supportive of having additional PRB offsets for RedCap to avoid overlapping PUCCH resources. Contribution [27] proposes that additional offset values {0, 4, 6, 8} can be configured for RedCap default PUCCH resource set. Also, in [12], it is proposed that the candidate values are {2, 3, 4, 6} and if the field is absent, the RedCap UE assumes the value of 0. Based on the above views, the following proposal can be considered: FL1 High Priority Proposal 5-1: When the frequency hopping for the RedCap PUCCH resources (for HARQ feedback for Msg4/MsgB) is deactivated, All 16 PUCCH resources are mapped to one side, and it is SIB-configurable which side. The PRB index of the PUCCH transmission is determined using the existing equations as a starting point, with an additional PRB offset with 4 candidate values. One of the candidate values is zero. Company Y/N Comments vivo Y Nordic Y FUTUREWEI Y Qualcomm OK Intel Y Ericsson Y Nokia, NSB Y LGE Y (almost) For the additional PRB offset, we prefer to keep the number of candidate values in square bracket until we make a progress in the discussion in Question 5-2. We don＊t have to stick to 4 candidate values if it somehow limits the flexibility in the common PUCCH resource set configuration. FL2 The online (GTW) session on Monday 21st February made the following agreement. The candidate values are considered in Question 5-2. Agreement: When the frequency hopping for the RedCap PUCCH resources (for HARQ feedback for Msg4/MsgB) is deactivated, All 16 PUCCH resources are mapped to one side, and it is SIB-configurable which side. The PRB index of the PUCCH transmission is determined using the existing equations as a starting point, with an additional PRB offset with [4] candidate values. One of the candidate values is [zero]. ? FL1/FL2 High Priority Question 5-2: Companies are invited to comment on suitable candidate values for the additional PRB offset values. Company Comments vivo We slightly prefer the additional offset values are {0, 4, 6, 8} for better co-exist with legacy common PUCCH resources. Nordic As we contributed, {0,4,6,8} provides the best multiplexing with non-RedCap UE PUCCH FUTUREWEI The values of {0,4,6,8} seem reasonable Qualcomm OK with the proposal of Vivo and Nordic Intel Support {0, 4, 6, 8} as candidate PRB-offset values. Ericsson PRB offsets are useful to avoid overlapping between PUCCH transmissions from different sectors (e.g., 3 or 4 sectors) using the same PUCCH format. For example, the PRB offsets {0, 2, 4} avoid overlapping of PUCCH resources with index 4, 5, 6. For each of these indexes, 2 PRBs on each edge is used, so PRB offset values increases by value 2 ({0, 2, 4}). Index PUCCH format First symbol Number of symbols PRB offset Set of initial CS indexes 1 0 12 2 0 {0, 4, 8} 2 0 12 2 3 {0, 4, 8} 4 1 10 4 0 {0, 3, 6, 9} 5 1 10 4 2 {0, 3, 6, 9} 6 1 10 4 4 {0, 3, 6, 9} With disabled FH for RedCap, all PRBs will be located on one edge. In the above example, 4 PRBs will be on one edge. Therefore, to avoid overlap, the PRB offsets should be {0, 4, 8}. Similarly, for index 1 and 2 in the above table, 3 PRBs are allocated on each edge and PRB offsets are {0,3}. For RedCap with disabled FH, 6 PRBs will be located on one edge. Therefore, the offset values should be {0, 6}. The same argument is hold for other PUCCH indexes. Currently, the set of all fixed PRB offset values are {0, 2, 3, 4} (for index 15 there is also an additional offset ). For RedCap with disabled FH where all PRBs are mapped to one edge of UL BWP, the fixed PRB offset values should be doubled. Thus, we support values {0, 4, 6, 8} which are also proposed by companies above. Nokia, NSB No strong view, we are fine with {0, 4, 6, 8} CATT Current PUCCH resource allocation has a □RB■_"BWP" ^"offset" , mainly with a value set of {0, 2, 4}, if we do not consider the special values appear only once, i.e. 3 and □RB■_"BWP" ^"size" /4. Hence, the RB offset of RedCap PUCCH from BWP edge can be considered as {0, 2, 4}+{0, 2, 4}, i.e. {0,2,4,6,8}. It seems considerable to adopt {2,4,6,8} as 4 explicit configurable value, while the value is equal to 0 if the field is absent. If the field is mandated, we are fine with {0,4,6,8} Xiaomi We share the similar view with DOCOMO-san＊s comment during the GTW. When the configuration of additional PRB offset is absent, it implies the value of 0. Then, for the other additional PRB offset, we are fine with 4,6,8 Panasonic If ※additional PRB offset§ is described in the table for the non-FH PUCCH resource set (i.e., jointly specified with PUCCH format, symbol allocation etc.), we propose {0, 4, 6, 8}. If ※additional PRB offset§ is configured RRC parameter which is independent from such a table, {0, 4, 6, 8} or CATT/Xiaomi/DOCOMO＊s suggestion is fine. Sharp We are fine with {0, 4, 6, 8} NTT DOCOMO Firstly, it is unclear for us what is the common understanding on how to map 16 PUCCH resources in one side. According to the current specification, PUCCH resources for a PUCCH resource set is mapped as follows, e.g., PUCCH resource set index is 13; In the current specification, frequency hopping direction, UE-specific PRB offset and CS is indicated via 3 bit DCI and 1 bit from CCE index and 16 resources are mapped in one side. On the other hand, if FH is disabled for RedCap UE, PUCCH resources for a PUCCH resource set can be mapped as follows, e.g., for PUCCH resource set index 13; In our understanding, if FH is disabled for common PUCCH, there is only 8 resources in one side based on the current specification. Thus, we suggest to make it clear how to map 16 PUCCH resources in one side before we discuss the exact values of additional offset. In our view, it would be straightforward that PUCCH resources for the first hop in the current specification are used to map 16 PUCCH resources in one side as if FH is enabled with hopping distance is 0 as below; Secondly, we would like to clarify the starting point of the additional PRB offset for RedCap UE. According to the agreement above, the starting point is described as follow; The PRB index of the PUCCH transmission is determined using the existing equations as a starting point, with an additional PRB offset with [4] candidate values. In our understanding, the additional offset starts from the PRB index which is indicated by the existing equation, i.e., cell-specific PRB offset indicated by RMSI and UE-specific PRB offset indicated by DCI and CCE index. In other words, the additional offset does not start from the edge of separate initial UL BWP. Lenovo We are with {0,4,6,8} Samsung Fine with {0,4,6,8} Huawei, HiSilicon No strong opinion. ZTE, Sanechips We share the same view with Ericsson. [0,4,6,8] can be adopted. How to capture this can be to RAN2 discussion. CMCC We are fine with {0, 4, 6, 8} Intel2 While we are fine with the values of the ※additional PRB offset§ as indicated before, it seems necessary to clarify the interpretation of the following bullet from the GTW agreement: ?????????The PRB index of the PUCCH transmission is determined using the existing equations as a starting point, with an additional PRB offset with [4] candidate values. Our interpretation is that we use the following equations for lower and upper edge of the UL BWP: □RB■_"BWP" ^"offset" +?r_"PUCCH" ?N_CS ?; □N_"BWP" ^"size" -1-RB■_"BWP" ^"offset" -?r_"PUCCH" ?N_CS ? Where RBBWPoffset is the value: indicated as the ※additional PRB offset§ when configured, and is reused from Table 9.2.1-1 of TS38.213 when not configured. That is, the ※additional PRB offset§ replaces the offset from Table 9.2.1-1 for a given row, as against being an additive factor on top of RBBWPoffset. Further, it＊d also be good to clarify the determination of cyclic shifts in this case. In particular, the initial CS index can be determined as (rPUCCH mod NCS). IDCC We are ok with {0,4,6,8}. FL3 Most of the received responses support {0, 4, 6, 8} as the candidate PRB offset values. A few responses suggest that the range can include 4 non-zero values, e.g., {2, 4, 6, 8}, since the default value (when no parameter is signaled) can be 0. Some responses propose to clarify whether the additional PRB offset is added to the existing PRB offset or replaces it entirely. Based the received responses, the following proposal can be considered, where the intention is to down select between Options 1 and 2 later in RAN1#108-e. High Priority Proposal 5-2a: When frequency hopping for common PUCCH resources for RedCap is deactivated, When the additional PRB offset is configured, It replaces the legacy PRB offset (RBBWPoffset). It is counted from the edge of the separate initial UL BWP. Its range is {2, 4, 6, 8}. When the additional PRB offset is NOT configured, Option 1: The PRB offset is 0. Option 2: The legacy PRB offset (RBBWPoffset) is used. Down select between Options 1 and 2 in RAN1#108-e. Qualcomm Y For the situation that additional PRB offset is not configured for RedCap UE, we think the proposal of DOCOMO makes sense. Therefore, we prefer option 2. vivo Y We thought the additional PRB offset is added to the existing PRB offset, not to replace the existing one. But we are open to hear companies view on this. We prefer option 2. Apple Y Similar as Vivo, the additional PRB offset is relative to the existing PRB offset configured for normal UE for PUCCH transmission. On the case of no additional RB, option 2 is a nature consequence if we define that ＆the additional RB＊ is applied on top of legacy PRB offset. DOCOMO N According to the description in the current agreement ※All 16 PUCCH resources are mapped to one side§, it is still unclear how to map 16 resources in one side, i.e., how many PRBs are required for one PUCCH resource set. Depending on how to multiplex PUCCH resources (FDM, TDM, CS and/or OCC for PF1), we think the value range of additional PRB offset for RedCap UE would be different. For example, if the multiplexing with non-RedCap UE is not considered, the ※16§ resources can consist of 4 FDMed resources and 4 CS-multiplexed resources in the same time domain resource as we described before. For this case, one PUCCH resource set for RedCap UE requires 4 PRB in frequency domain to provide 16 PUCCH resources. For another example, the ※16§ resources can consist of 2 FDMed resources, 4 CS-multiplexed resources and 2 TDMed resources. For this case, one PUCCH resource set for RedCap UE requires 2 PRB in frequency domain to provide 16 PUCCH resources. Therefore, we would like to discuss how to map 16 resources in one side to clarify the agreement before we discuss the exact value range of additional PRB offset for RedCap UE. Sharp Y We prefer option 2 when the additional PRB offset is not configured. Regarding DOCOMO＊s comment, our understanding is 16PUCCH resources are FDMed with 4PRBs. Based on the online (GTW) session for agenda item 8.16.6 (on the RedCap UE feature list) on Monday 21st February, the following question can be considered. FL2 High Priority Question 5-3: Should it be supported to disable frequency hopping for common PUCCH resources for RedCap UEs in a shared initial UL BWP? Please provide your motivation in the Comments field. Company Y/N Comments Qualcomm N If RedCap UE and non-RedCap UE share the same initial UL BWP configuration, we don＊t think it is necessary to disable FH for common PUCCH resources. As a result, the utilization efficiency of cell-specific PUCCH resources can be optimized for all UE types. CATT N Legacy Rel-15/16 UEs mandates FH of common PUCCH in shared initial UL BWP. If RedCap UE shares initial UL BWP with legacy UEs, the most proper way is follow legacy behavior, i.e. mandates FH for common PUCCH. This provides better coexistence and allows inter-UE multiplexing. Xiaomi N Not necessary. Don＊t see the motivation to disable the FH in this case. vivo N Panasonic N In the shared initial UL BWP, the legacy behavior is enough. Sharp N PUCCH FH disabling is used to avoid PUSCH resource fragmentation by PUCCH resources in separate initial UL BWP. On the other hand, there is no additional PUSCH fragmentation issue on the shared initial UL BWP with RedCap UEs. Moreover, on the shared initial UL BWP, since RedCap UEs will share PUCCH resources with non-RedCap UEs, disabling of PUCCH FH will not work in the shared initial UL BWP NTT DOCOMO N Given that the motivation to support PUCCH FH disabling for common PUCCH is to avoid PUSCH fragmentation issue when a RedCap UE uses a separate initial UL BWP, we don＊t see any benefit to disable FH in a shared initial UL BWP. Lenovo N Samsung N We share similar view as Qualcomm. LGE N We agree with most of the comments above. In our view, we already narrowed down the support of disabling common PUCCH FH to the case where the separate initial UL BWP is configured. Huawei, HiSilicon N Seems not necessary since the scenario is likely that the BW of BWP for non-RedCap does not exceed RedCap UE max BW, thus no fragmentation. ZTE, Sanechips N We are OK to not support disabling frequency hopping in shared BWP. MediaTek N We don＊t see the motivation for disabling FH for RedCap in shared initial UL BWP, either. CMCC N There is no PUSCH fragment issue and enabling FH for common PUCCH guarantees multiplexing capacity of RedCap and non-RedCap UEs. Nordic N We do not see benefit to support FUTUREWEI N No benefit to support disabling of FH in shared initial UL BWP Ericsson N There does not seem to be any obvious benefit with disabling FH in a shared UL BWP. The main purpose for disabling FH is to minimize the UL resource fragmentation when configuring a small initial UL BWP within a larger UL BWP. With a shared initial UL BWP between RedCap and non-RedCap, many configurations can be shared for minimizing the signaling overhead. Intel N IDCC N FL3 Based the received responses, the following proposal can be considered. High Priority Proposal 5-3a: Disabling of frequency hopping for common PUCCH resources for RedCap UEs is only supported for separate (not shared) initial UL BWP. Qualcomm Y vivo Y Apple Y DOCOMO Y Sharp Y Other aspects The following other aspects not covered in the earlier sections of this document are discussed in some contributions. UL/DL center frequency in TDD: [6]: For TDD, the center frequencies are assumed to be the same for the initial DL BWP and initial UL BWP after initial access for RedCap UEs. [13]: For TDD, center frequencies are the same for the initial DL and UL BWP during random access for RedCap UEs, no matter whether or not it includes CD-SSB and the entire CORESET#0 or not. [21]: For TDD, the initial DL BWP for RedCap UEs (separate or default) shall be center frequency aligned with the initial UL BWP for RedCap UEs (separate or default) for both during initial access and after initial access. [23]: For TDD, center frequencies are the same for the initial DL and UL BWPs for RedCap UEs, regardless of whether the initial DL BWP contains CD-SSB and the entire CORESET#0. [27]: In TDD, initial UL BWP applicable to RedCap UEs is aligned in center frequency with initial DL BWP applicable to RedCap UEs. Multiplexing of FH and non-FH PUCCH: [4]: Two base sequences are generated and applied for a non-FH PUCCH with time-domain symbol allocation and frequency domain PRB allocation the same as that of an intra-slot FH PUCCH. [12]: 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 generate two base sequences for the PUCCH as if intra-slot frequency hopping is enabled for the PUCCH transmission. [17]: Multiplexing between non-FH and FH PUCCH from RedCap and non-RedCap UEs respectively is left up to gNB implementation. [18]: If intra-slot FH is disabled for Redcap and overlapped RBs are used for non-FH and FH PUCCH transmissions, the base sequence group/sequence hopping for PUCCH format 1 is determined based on value of ＆pucch-GroupHopping＊ IE configured for non-Redcap UE. RACH occasions: [4]: For the shared ROs scenario, only ROs which fall within separate initial UL BWP can be regarded as valid ROs for RedCap UEs and the mapping of SSB-to-RO can be separately configured for RedCap UEs. [10]: When ROs are shared, a separate mapping between RO and SSB for RedCap UE may be needed. Companies are invited to comment on whether any other critical issues (beside the ones covered in earlier sections) need to be resolved to conclude the Rel-17 RedCap WI. FL1/FL2 Medium Priority Question 6-1: Companies are invited to comment on whether any other critical issues (beside the ones covered in earlier sections) need to be resolved to conclude the Rel-17 RedCap WI. Company Comments vivo For the center-frequency alignment issue, we think the legacy principle should be maintained, i.e. a TDD UE assumes center-frequency alignment between DL BWP and UL BWP with the same BWP index. Nordic We believe it would be good to clarify what CORESET(s) can be configured in separate Initial DL BWP not containing CORESET#0 by MIB. If non-RedCap SIB1 shall be reused for RedCap, commonCORESET configuration requires more than 50bits, this is critically high. We believe there should be possibility for some simple CORESET configuration, be it called CORESET0A or something else. Spreadtrum NW can configure the separate initial DL BWP, no matter whether the separate initial DL BWP contains CD-SSB and the entire CORESET#0. We are not sure the current agreements (when combined) can imply it. If it can, we are fine for it. Similar as vivo, we think the center-frequency alignment b/w DL/UL BWP should be applied to all cases for RedCap UE. In the current agreements, there is a FFS for the case when the initial DL BWP does not include CD-SSB and the entire CORESET#0. Qualcomm Based on the replies from RAN2 and RAN4, we think it is necessary to: confirm that L1/L3 measurements based on NCD-SSB of serving cell are supported as mandatory capabilities of R17 RedCap UE and included as an additional component of FG 28-1 discuss the signaling aspects for NCD-SSB (with RAN1 impacts) in dedicated DL BWP of RedCap UE for example, whether or not the configuration/availability of NCD-SSB can follow a mechanism of SI plus RRC/DCI Intel The following issues (mentioned in our tdoc [17] although not listed above) needs to be addressed during this meeting: Center frequency alignment: Center frequency alignment between initial DL BWP and initial UL BWP for RedCap when the initial DL BWP includes CORESET#0 and CD-SSB. RAN1 specifications should capture the center frequency alignment between initial DL and UL BWPs when they are used for random access. The current text from Rel-15 in Subclause 12 of 38.213 is not sufficient as it only refers to BWPs with same index. With possibility of configuration of separate initial DL/UL BWPs, the Rel-15 text would be ambiguous as to how BWPs with same indices are identified in such a context. The details of NCD-SSB needs to be finalized following the feedback from RAN2/RAN4 so that they can be captured in the RAN1 specifications appropriately. RAN1 needs an agreement on configuration of CORESET in addition to ra-searchSpaceSet in separate initial DL BWP, including details of such CORESET configuration. Xiaomi As mentioned in our contribution R1-2201955, the following issues need discussion. The supported number of separate initial DL BWP: According to current agreement, it is possible that more than one separate initial DL BWP can be supported as shown in the following figure. But in our opinion, the motivation for such configuration is weak. To simplify the configuration and processing, it is desirable to support up to 1 separate initial DL BWP for RedCap Default BWP determination: In current NR system, once bwp-InactivityTimer associated with the active DL BWP expires, if the default BWP is explicitly configured via defaultDownlinkBWP-Id, UE perform BWP switching to the BWP indicated by the defaultDownlinkBWP-Id. Otherwise, UE would perform BWP switching to the initialDownlinkBWP. But for RedCap, here may be more than one initialDownlinkBWPs. For example, the original initialDownlinkBWP is mainly used for paging and SIB, and the separate initialDownlinkBWP is used for RACH. In this case, how to determine the target BWP for switching if default BWP is not explicitly configured via defaultDownlinkBWP-Id should be clarified. Sharp According to current description in 38.213 v17.0.0 as ※A UE can be provided a DL BWP by initialDownlinkBWP in DownlinkConfigCommonRedCapSIB, and an UL BWP by initialUplinkBWP in UplinkConfigCommonRedCapSIB.§, it is unclear when a separate initial DL BWP is applied to RedCap UEs as initial DL BWP when the separate initial DL BWP does not contain CORESET#0. For this case, we would like to clarify that the separate initial DL BWP should be applied to the RedCap UE upon initiating to perform the random access procedure. NTT DOCOMO The common PUCCH resources for RedCap UEs without FH and for non-RedCap UEs with FH can be FDMed with additional PRB offset for RedCap UE. However, such configuration may result UL throughput degradation which is not desired from system perspective. Therefore, we propose to support multiplexing common PUCCH resources with/without FH by cyclic shifts. More specifically, if FH of common PUCCH for RedCap UEs is disabled, UE generate two base sequences for the PUCCH as if intra-slot frequency hopping is enabled for the PUCCH transmission. Huawei, HiSilicon All the above MediaTek 1. How does UE determine its initial DL BWP from (a) SIB-configured initial DL BWP for RedCap, (b) SIB-configured initial DL BWP for non-RedCap, and (c) MIB-defined CORESET#0 for cases (1) initial access and random access, and (2) paging and SI update in Idle/Inactive mode? For (2), we are also ok with clarification on UE behavior. The approach with less specification is preferred. 2. Center frequency alignment between (1) initial DL and UL BWPs; and (2) CORESET#0 and initial UL BWP if Msg2/Msg4/MsgB reception is configured with CORESET#0 If UE has to perform RF retuning during random access, RAN1 should revisits RACH timeline requirements by taking RF retuning time into consideration. References [1] RP-211574 Revised WID on support of reduced capability NR devices Ericsson [2] R1-2112506 RAN1 agreements for Rel-17 NR RedCap Rapporteur (Ericsson) [3] R1-2112501 FL summary #5 on reduced maximum UE bandwidth for RedCap Moderator (Ericsson) [4] R1-2200917 Remaining issues on reduced maximum UE bandwidth Huawei, HiSilicon [5] R1-2200985 Remaining aspects of Bandwidth Reduction for RedCap UEs FUTUREWEI [6] R1-2201099 Remaining issues on reduced maximum UE bandwidth Vivo, Guangdong Genius [7] R1-2201136 Bandwidth reduction for reduced capability NR devices ZTE, Sanechips [8] R1-2201277 Remaining issues on reduced UE bandwidth OPPO [9] R1-2201367 Remaining issues on reduced maximum UE bandwidth CATT [10] R1-2201404 Aspects related to reduced maximum UE bandwidth Nokia, Nokia Shanghai Bell [11] R1-2201441 Remaining issues on reduced maximum UE bandwidth for RedCap China Telecom [12] R1-2201482 Remaining issues on reduced maximum UE bandwidth for RedCap NTT DOCOMO, INC. [13] R1-2201549 Discussion on aspects related to reduced maximum UE bandwidth Spreadtrum Communications [14] R1-2201590 Aspects related to reduced maximum UE bandwidth for RedCap Panasonic Corporation [15] R1-2201605 Remaining issues on BWP operation for RedCap NEC [16] R1-2201668 Reduced maximum UE bandwidth for RedCap Ericsson [17] R1-2201702 On reduced BW support for RedCap Intel Corporation [18] R1-2201775 Reduced maximum UE bandwidth for Redcap Apple [19] R1-2201861 Remaining issues of reduced maximum UE bandwidth CMCC [20] R1-2201955 Discussion on the remaining issues of reduced UE bandwidth for RedCap Xiaomi [21] R1-2201970 Reduced maximum UE bandwidth for RedCap Lenovo, Motorola Mobility [22] R1-2202020 UE complexity reduction Samsung [23] R1-2202061 On reduced bandwidth for NR RedCap UEs MediaTek Inc. [24] R1-2202192 Discussion on reduced maximum UE bandwidth Sharp [25] R1-2202250 Remaining issues on reduced maximum UE bandwidth InterDigital, Inc. [26] R1-2202344 Aspects related to the reduced maximum UE bandwidth of RedCap LG Electronics [27] R1-2202382 On aspects related to reduced maximum UE BW Nordic Semiconductor ASA [28] R1-2202146 Remaining Issues on UE Complexity Reduction Qualcomm Incorporated [29] R1-2200918 On RAN1 aspects of RAN2 led issues for RedCap Huawei, HiSilicon [30] R1-2201138 Higher layer support of Reduced Capability NR devices ZTE, Sanechips [31] R1-2202383 On RAN2 related aspects Nordic Semiconductor ASA [32] R1-2201864 Remaining issues of other aspects for RedCap UE CMCC [33] R1-2201892 Remaining aspects for RedCap ZTE, Sanechips [34] R1-2201958 Discussion on the fast BWP switching for RedCap Xiaomi [35] R1-2202419 On?RedCap UE BWP configuration Huawei, HiSilicon [36] RP-213689 Moderator＊s proposals from [94e-39-R17-RedCap-WI] Moderator (Intel) [37] R1-2112802 LS on use of NCD-SSB or CSI-RS in DL BWPs for RedCap UE RAN1, Ericsson [38] R1-2200876 Reply LS on the use of NCD-SSB or CSI-RS in DL BWPs for RedCap UEs RAN2, Ericsson [39] R1-2200877 LS on RSRP measurement before Msg1 or MsgA retransmission RAN2, Ericsson [40] R1-2200898 Reply LS on use of NCD-SSB for RedCap UE RAN4, ZTE [41] R1-2200904 Reply LS on use of NCD-SSB or CSI-RS in DL BWPs for RedCap UE RAN4, Vivo [42] R1-2202528 (Inbox) FL summary #1 on reduced maximum UE bandwidth for RedCap Moderator (Ericsson)