3GPP TSG-RAN WG1 Meeting #106bis-e R1-21xxxxx e-Meeting, 11th 每 19th October 2021 Agenda Item: 8.6.1.1 Title: FL summary #1 on reduced maximum UE bandwidth for RedCap Source: Moderator (Ericsson) Document for: Discussion, Decision Introduction This feature lead (FL) summary (FLS) concerns the Rel-17 work item (WI) for support of reduced capability (RedCap) NR devices [1]. Earlier RAN1 agreements for this WI are summarized in [2]. The final FLS for this agenda item from the previous RAN1 meeting can be found in [3]. This document summarizes contributions [4] 每 [30] submitted to agenda item 8.6.1.1 and relevant parts of contributions [31] 每 [33] submitted to agenda item 8.6.3 and captures this email discussion on reduced maximum UE bandwidth: [106bis-e-NR-R17-RedCap-01] Email discussion regarding aspects related to reduced maximum UE bandwidth 每 Johan (Ericsson) 1st check point: October 14 Final check point: October 19 The issues in this document are tagged and color coded with High Priority or Medium Priority. The issues that are in the focus of this round of the discussion in this meeting are furthermore tagged FL2. 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-2108693), 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. FL2 Question 1-1: Please consider entering contact info below for the points of contact for this email discussion. Company Point of contact Email address Qualcomm Jing Lei leijing@qti.qualcomm.com Vivo Xueming Pan panxueming@vivo.com OPPO Weijie Xu xuweijie@oppo.com Nordic Karol Schober karol.schober@nordicsemi.no Huawei, HiSilicon Wang Yi wangyi6@huawei.com Xiaomi Qin MU muqin@xiaomi.com Panasonic Shotaro Maki maki.shotaro@jp.panasonic.com Sharp Hiroki Takahashi takahashi.hiroki@sharp.co.jp Lenovo Yuantao Zhang zhangyt18@lenovo.com Spreadtrum Huayu Zhou huayu.zhou@unisoc.com CATT Yongqiang FEI feiyongqiang@catt.cn Nokia Rapeepat Ratasuk rapeepat.ratasuk@nokia-bell-labs.com Ericsson Sandeep Narayanan Kadan Veedu sandeep.narayanan.kadan.veedu@ericsson.com Intel Corporation Debdeep Chatterjee debdeep.chatterjee@intel.com China Telecom Jing Guo guojing6@chinatelecom.cn DOCOMO Shinya Kumagai shinya.kumagai@docomo-lab.com FUTUREWEI Vip Desai vipul.desai@futurewei.com CMCC Lijie HU hulijie@chinamobile.com NEC Takahiro Sasaki takahiro.sasaki@nec.com LGE Jay KIM Jaehyung.kim@lge.com Samsung Feifei Sun feifei.sun@samsung.com MediaTek Mohammed Al-Imari Mohammed.Al-Imari@mediatek.com Initial UL BWP Separate initial UL BWP for RedCap RAN1#105-e made the following agreements related to initial UL BWP: Agreements: Working assumption: Both during and after initial access, for the scenario where the initial UL BWP for non-RedCap UEs is configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap UEs. FFS: whether/how to avoid or minimize PUSCH resource fragmentation due to PUCCH transmission for the above case Support the case when the centre frequency is assumed to be the same for the initial DL and UL BWPs in TDD. FFS whether or not to additionally support the case when the centre frequency is different; if so, how to minimize centre frequency retuning Working assumption: Both during and after initial access, even for the scenario where the initial UL BWP for non-RedCap UEs is not configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP can optionally be configured/defined for RedCap UEs. RO sharing between RedCap and non-RedCap is not precluded. Moreover, we have the following proposal from the latest FLS in RAN1#106-e [3]: Proposal: Confirm the following modified version of the working assumption from RAN1#105-e: Both during and after initial access, for the scenario where the initial UL BWP for non-RedCap UEs is configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap UEs. If a separate initial DL BWP is configured, the centre frequency is assumed to be the same for the separate initial DL BWP and the separate initial UL BWP in TDD. If a separate initial DL BWP is not configured, the centre frequency is assumed to be the same for the MIB-configured initial DL BWP and the separate initial UL BWP in TDD. FFS whether or not to additionally support the case when the center frequency is different between the separate initial UL BWP and the initial DL BWP, and, if so, how to minimize center frequency retuning Regarding the initial UL BWP configuration during and after initial access, many contributions agree with the main bullets of the working assumptions from RAN1#105-e [6, 7, 11, 12, 13, 15, 21, 24, 25, 27]. That is: (1) during and after initial access, for the scenario where the initial UL BWP for non-RedCap UEs is configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap UEs, and (2) during and after initial access, even for the scenario where the initial UL BWP for non-RedCap UEs is not configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP can optionally be configured/defined for RedCap UEs. Also, as already agreed in RAN1#106-e, ROs can be dedicated for RedCap UEs or shared with non-RedCap UEs. Regarding RO sharing, the FL＊s understanding is that ROs can be fully or partially shared between RedCap and non-RedCap UEs. Based on expressed views and agreements in RAN1#105-e and RAN1#106-e, the following combined proposal regarding a separate initial UL BWP for RedCap can be considered. FL1 High Priority Proposal 2.1-1: Regarding a separate initial UL BWP for RedCap in both during and after initial access: For the scenario where the initial UL BWP for non-RedCap UEs is configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap UEs. For the scenario where the initial UL BWP for non-RedCap UEs is not configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP can optionally be configured/defined for RedCap UEs. Company Y/N Comments Qualcomm Y Clarification is needed for the 2nd bullet For the scenario where the initial UL BWP for non-RedCap UEs is not configured to be wider than the RedCap UE bandwidth, configuring/defining a separate initial UL BWP for RedCap UEs by SIB will increase the signaling overhead. Clarification/justification is preferred regarding when/how the RedCap-specific initial UL BWP is configured/defined. Vivo Y OPPO Y For shared RO scenario, when the span of RO bandwidth exceeds RedCap UE maximum bandwidth, how to configure/define a separate initial UL BWP for RedCap needs to be further discussed. Nordic Y Huawei, HiSilicon Y if with modifications Our understanding is that a single separate initial UL BWP with a single frequency location for use, does not resolve some of the issues raised during initial access for e.g. RO vs SSB, PUCCH transmission for Msg4 (see R1-2108753). Modified Proposal 2.1-1: Regarding a separate initial UL BWP for RedCap in both during and after initial access: For the scenario where the initial UL BWP for non-RedCap UEs is configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap UEs. For the scenario where the initial UL BWP for non-RedCap UEs is not configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP can optionally be configured/defined for RedCap UEs. FFS how the configuration/determination is applied, e.g. by BWP switching or RF retuning ZTE, Sanechips Y We are fine with the FL proposal. Even for the scenario where the initial UL BWP for non-RedCap UEs is not configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP can still be configured for RedCap UEs for the purpose of scheduling flexibility and early identification of RedCap. TCL Y Fine with the FL proposal Xiaomi Y Panasonic Y On the first bullet, "for the scenario where the initial UL BWP for non-RedCap UEs is configured to be wider than the RedCap UE bandwidth", our understanding is it does not contain the case the cell is barred to RedCap UEs. Although we can live with the current wording, the scenario means the case the cell support RedCap UEs is our interpretation. Sharp Y Lenovo, Motorola Mobility Y Spreadtrum Y CATT Y Fine to agree on the ＆configured＊ case and FFS the ＆defined＊ case. Nordic Follow up I guess Yi has cited this agreement Agreement Confirm the following working assumption from RAN1#105-e regarding RACH occasions. For enabling/supporting that the RACH occasion (RO) associated with the best SSB falls within the RedCap UE bandwidth, support separate initial UL BWP for RedCap UEs (which is not expected to exceed the maximum RedCap UE bandwidth), and this separate initial UL BWP for RedCap includes ROs for RedCap UEs. Note: these ROs can be dedicated for RedCap UEs or shared with non-RedCap UEs. Above highlighted part clearly says that there are no RedCap ROs outside initial UL BWP. We do not see a need to reopen the discussion again with Huawei FFS. Nokia, NSB Y Our understanding is similar to Nordic that there are no RedCap ROs outside of the initial UL BWP. Ericsson There were discussions in the GTW session on whether the 2nd bullet should be removed or not. In our view, it is important to keep the 2nd bullet to have a more future-proof design (e.g., to handle congestion when the number of RedCap UEs increases) and to have more flexibility at the NW side on where to place the RedCap initial UL/DL BWP in the carrier. We propose the following shorter proposal: A separate initial UL BWP can be configured/defined for RedCap UEs and it can be signaled in SIB. This applies to both TDD and FDD cases. Intel Y We share similar understanding as Nordic and Nokia on ensuring all relevant ROs for RedCap are contained within the separate initial UL BWP. We also agree that we need to agree to the second sub-bullet explicitly for the reasons cited by Ericsson as well as to realize RedCap UE early identification, depending on gNB choice, regardless of whether UL BWP #0 for non-RedCap UEs is larger than 20 MHz or not. China Telecom We think the above scenarios in FL proposal can be combined together to make things simple. The separate initial UL BWP can optionally be configured/defined for RedCap UEs via SIB. The configuration details about initial UL BWP need more discussion and clarification, like ROs, SSB, CORESET#0. DOCOMO Y FUTUREWEI Y Ok with combining too. A minor wording suggestion (2 times) ※＃be wider than the RedCap UE maximum bandwidth ＃§ Note that we have a previous agreement in RAN1#106, For enabling/supporting that the RACH occasion (RO) associated with the best SSB falls within the RedCap UE bandwidth, support separate initial UL BWP for RedCap UEs (which is not expected to exceed the maximum RedCap UE bandwidth), and this separate initial UL BWP for RedCap includes ROs for RedCap UEs. Note: these ROs can be dedicated for RedCap UEs or shared with non-RedCap UEs. and it was confirmed on the GTW there is no intent to reverse this previous agreement and not allow RO sharing for RedCap UEs. CMCC Y In our understanding, the agreement copied by Nordic has two meanings, A separate initial UL BWP configured for RedCap UE has its own RO configuration, then a different SSB to RO mapping from non-RedCap UEs can be defined. In this case, these ROs can be dedicated for RedCap UEs as the note says. A separate initial UL BWP configured for RedCap UE shares the RO with non-RedCap UEs. And two sub-interpretation can be made, Interpretation 1: the bandwidth of all the FDMed ROs is larger than maximum bandwidth of RedCap UE. So different UEs have different initial UL BWP to make sure the shared ROs associated with its best SSB fall within its maximum bandwidth. As show in the following figure. Interpretation 2: The bandwidth of all the FDMed ROs is larger than maximum bandwidth of RedCap UE. RedCap UE shares a separate initial UL BWP, with part of the shared non-RedCap ROs in the BWP associated with all the SSBs, e.g. one RO is associated with more than one SSBs. The understanding about the shared RO needs to be aligned first. For the second sub-bullet, we share the same view as Ericsson and Intel, and think it is necessary to have such agreement. NEC Y In our understanding, RO needs to be configured within a separate initial UL BWP for RedCap UE. On the second bullet, we don＊t see much necessity to prohibit the case. LGE Y with modifications We prefer to remove the ※defined§ from the two bullets and create a third bullet for FFS on the ※defined§. Apple Y Thanks to Intel for clarification on the 2nd bullet. We now understand the use case, i.e., at least for early indication, allowing separate initial UL BWP provides flexibility to avoid RO/preamble split. Having said this, we are ok FL proposal to include both two bullets. On CMCC question, our interpretation of previous agreement is Interpretation 2. Samsung Suggest to remove ※defined§ and add ※at least§ before ※configured§. At least in our understanding, the motivation to support separated iDL BWP is to ensure the RO issue. i.e., configured a separate RO. In our understanding, the original Note on RO sharing is for gNB implementation. For example, gNB can configured same RO as for none-RedCap UE. For CMCC＊s question, our interpretation on the agreement (including the note) is neither 1 nor 2. But we think for sharing case, RO for non-RedCap shall fall into the separate iUL BWP for non-RedCap. However, RO for RedCap is separated configured in separate iUL BWP. Lenovo, Motorola Mobility Follow up Our memory is that this ※/defined§ was added for the possibility of determining the position of separate initial UL BWP in frequency domain implicitly, instead of explicit configuration. We are fine to keep it in the proposal. We are fine to have a shorter proposal as from Ericsson, or have both bullets in the proposal. Regarding the ROs in the separate initial UL BWP, our understanding is that the previous agreement does not preclude that the separate initial UL BWP does not contain ROs (and ROs are then shared with non-RedCap UEs). It supports this separate initial UL BWP for RedCap includes ROs for RedCap UEs. (but not says not to support separate initial UL BWP without ROs). Huawei, HiSilicon To Karol, Debdeep, Rapeepat, Feifei Thanks for the comments. It is NOT our intention to let RedCap UE operates outside an initial UL BWP. However, it is not clear to us how it works as a complete solution as FUTUREWEI and CMCC explained in case of Interpretation 2 of CMCC fig. (as some of you also agree with this interpretation; other interpretation has the same question) Specifically, The initial BWP for RedCap is configured first - gNB does not know which SSB is the best for an unknown UE A specific UE trying to access will measure SSB and find an RO with best measured SSB later 每 the RO may be e.g. RO6 in the above fig. It is not possible for gNB to predict which SSB is the best, as different UEs sharing the same SSB sets but in different conditions/reception beams in the above case Thus, One can restrict that only the ROs within the pre-configured BWP can be used, while once a UE measure a best SSB outside the BWP, it needs to re-select another SSB based on other rules - this is feasible but require further discussion, as against the current RACH framework; One can define a separate RO-SSB mapping such that the possible associated SSBs are all within the pre-configured BWP - this is feasible but require further discussion, as against the uniquely used RO-SSB mapping so far; One can restrict the possible gNB configurations such that the above case does not happen - this is also feasible while require further conclusion, although obviously is not good and against the previous agreements: it does not guarantee to enable the RO with best SSB, nor these ROs can be shared with non-RedCap UEs. The current proposal is in short incomplete. Whether/how to resolve this issue is not yet clearly carried out - instead of re-open. OPPO Thanks CMCC for the detailed interpretation. First of all, we think that shared RO case shall be allowed even if the bandwidth of the configured ROs exceed RedCap UE＊s maximum bandwidth. Secondly, both interpretation 1 and interpretation 2 shall be supported since the flexibility to configure RO for non-RedCap UE shall not be sacrificed. Then at least for interpretation 1, it shall be discussed how the initial UL BWP is derived for a RedCap UE. As Huawei pointed out, a RO is selected based on UE＊s best SSB, then the initial UL BWP shall include the RO selected by the UE. But on the other hand, the gNB is not clear which RO would be selected by the UE thus it is not possible for the gNB to configure the initial UL BWP for the UE. In order to align the understanding of UE and gNB on which initial UL BWP the UE will use during RACH procedure, it will make sense to set some rule that both UE and gNB has the same understanding. It is why we think here defined shall be kept there. FL2 Based on the received responses, the following updated proposal can be considered. A corresponding proposal for separate initial DL BWP is provided in Proposal 3.1-1a. A question on the number of separate initial UL BWPs has been added in Question 2.1-2. High Priority Proposal 2.1-1a: A separate initial UL BWP for RedCap UEs can be configured in SIB1. It can be used both during and after initial access. It is no wider than the maximum RedCap UE bandwidth. It is always configured if the initial UL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. This applies to both TDD and FDD cases. FFS whether part of the configuration is implicitly signaled vivo Fine in general Clarification on 3rd sub-bullet: Our understanding is that in case ※the initial UL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth.§ and the separate initial UL BWP is not configured, the cell does not support RedCap UE. Would be good to clarify on this. Nokia, NSB Y Qualcomm Y Nordic Y @Huawei, Futurewei and CMCC As you can see the note is sub-bullet of main bullet. This means that only if highlighted part is satisfied, then ROs can be shared between RedCap and non-RedCap UEs. For enabling/supporting that the RACH occasion (RO) associated with the best SSB falls within the RedCap UE bandwidth, support separate initial UL BWP for RedCap UEs (which is not expected to exceed the maximum RedCap UE bandwidth), and this separate initial UL BWP for RedCap includes ROs for RedCap UEs. Note: these ROs can be dedicated for RedCap UEs or shared with non-RedCap UEs. These ROs in separate Initial UL BWP shall be shared between ※all§ redcap UEs and ※all§ non-RedCap UEs. Therefore, the advertised case of 8 FD ROs > 20Mhz is not allowed according to the agreement . For such case, gNB shall configure separate ROs for RedCap UE in the separate initial UL BWP. Ericsson Y IDCC Y Intel Y Same understanding as elaborated by Nordic for the example of FDM-ed ROs spanning beyond max RedCap UE BW. Lenovo, Motorola Mobility Y FUTUREWEI2 Y NEC Y DOCOMO Y But it has been pointed out multiple times that RAN2 will decide which SIB is used. Better to replace ※SIB1§ in the main bullet to ※SIB§ RAN1#106-e made the following agreement: For enabling/supporting that the RACH occasion (RO) associated with the best SSB falls within the RedCap UE bandwidth, support separate initial UL BWP for RedCap UEs (which is not expected to exceed the maximum RedCap UE bandwidth), and this separate initial UL BWP for RedCap includes ROs for RedCap UEs. Note: these ROs can be dedicated for RedCap UEs or shared with non-RedCap UEs. Based on received responses to Proposal 2.1-1, it seems that different interpretations are possible for the above agreement. FL2 High Priority Question 2.1-2: Should it be possible to have more than one separate initial UL BWP for RedCap UEs? If yes, please elaborate on the purpose in the Comments field. Company Y/N Comments vivo Y For offloading purpose, if one separate initial UL BWP is not sufficient due to massive number of RedCap devices, more than one initial UL BWPs may be configured. Nokia, NSB N We are not supportive of having more than one separate initial UL BWP for RedCap. Even if offloading is necessary, UEs can be moved to separate active UL BWP after initial access. Qualcomm N Switching between multiple separate initial UL BWPs will complicate the procedures of RedCap UE during initial access and increase the signaling overhead. Nordic Y,but Could be considered for future releases. Nokia offloading works only with BWP Option 1, in our opinion, but could be sufficient. Ericsson N The case of ROs with best SSB falling outside RedCap BW is not common. The total frequency span of 8 FDM-ed RACH occasions is greater than 20 MHz in FR1 and 100 MHz in FR2 in the following configurations: ? Preamble Format 3 in FR1, L=839 (long preamble), 5 kHz SCS: total BW of 8 FDM-ed RACH occasions = 34.56 MHz ? FR1, L=139 (short preamble), 30 kHz SCS: total BW of 8 FDM-ed RACH occasions = 34.56 MHz ? FR2, L=139 (short preamble), 120 kHz SCS: total BW of 8 FDM-ed RACH occasions = 138.24 MHz Also, if needed, proper gNB configuration can resolve this issue. Although the flexibility of the network configuration for non-RedCap UE can be impacted, such impact is not significant and sufficient capacity can still be achieved with less than 8 FDM-ed RACH occasions (e.g., 4 FDM-ed RACH occasions). Also, multiplexing in the time domain can be used to increase PRACH capacity. Defining multiple initial UL BWP only for resolving RO-SSB related issue for special cases (mentioned above) is not efficient and it makes the coexistence of RedCap and non-RedCap more complicated. Specifically, it has negative impacts in terms of: 1) PUSCH resource fragmentation, 2) May need corresponding DL BWP configuration in TDD (in case center frequency alignment is preferred), 3) significant increase of overhead and reduced spectral/energy efficiency. IDCC N Intel N Share the views from Nokia on offloading and from Ericsson on the lack of need to optimize for the case of FDM-ed RACH occasions spanning larger than 20/100 MHz in FR1/FR2 respectively. Lenovo, Motorola Mobility N NEC Y DOCOMO N Both Interpretations 1 and 2 in CMCC＊s comment in Proposal 2.1-1 are possible based on the above agreement. However, it would be enough to configure only one separate initial UL BWP which contains ROs for RedCap UEs associated with all SSBs PUCCH frequency hopping Regarding PUCCH transmissions (for Msg4/MsgB HARQ feedback) during initial access, we have the following agreement and working assumption from RAN1#106-e: Agreements: In case a separate initial UL BWP is configured for RedCap UEs, it is supported that the network can enable/disable intra-slot PUCCH frequency hopping within the separate initial UL BWP in the PUCCH resource for HARQ feedback for Msg4/MsgB for RedCap UEs. Working assumption: The frequency hopping is enabled/disabled at least via SIB. Several contributions discuss the signalling solution for disabling/enabling the PUCCH resource for HARQ feedback for Msg4/MsgB for RedCap UEs. Most of these contributions indicate that the PUCCH frequency hopping should be enabled/disabled only via SIB and that it is not preferred to use DCI [6, 10, 14, 15, 16, 24, 28, 29]. However, two contributions propose to use DCI (in addition to SIB) for enabling/disabling the PUCCH frequency hopping [4, 5]. Based on the above majority views and for the sake of progress, the following proposal can be considered. FL1 High Priority Proposal 2.2-1: Replace the RAN#106-e agreement and working assumption with: In case a separate initial UL BWP is configured for RedCap UEs, it is supported that the network can enable/disable intra-slot PUCCH frequency hopping within the separate initial UL BWP in the PUCCH resource for HARQ feedback for Msg4/MsgB for RedCap UEs. The frequency hopping is enabled/disabled at least via SIB. Company Y/N Comments Qualcomm Y If the RedCap-specific initial UL BWP fully overlaps with the initial UL BWP of non-RedCap UE, we don＊t see a need to disable the intra-slot FH of PUCCH for RedCap UE, if the intra-slot FH of PUCCH for non-RedCap UE is still enabled. Vivo Y OPPO Y Nordic Y, but It is not clear how would such disabling work. Could only half of PUCCH resources within Resource set be used? Huawei, HiSilicon FFS There is no numerical result providing any effective analysis explaining why the FH function for PUCCH should be controlled by SIB. On the other hand, we find that PUCCH performance is degraded and it would be strongly desirable that enhancement can be ready for that if PUCCH FH has to be disabled and this enhancement needs to be well controlled by network 每 in a dynamic way considering user channel conditions. Also, there would be marginal spec impact if this can be indicated by dynamic PDCCH scheduling Msg4/MsgB. Additionally, the frequency hopping across a large BW is beneficial and important for the common PUCCH performance. Further discussion on the potential support of this is proposed. Thirdly, the resource multiplexing issue with non-RedCap UEs may require some further discussion, as in Question 2.2-2 Thus the proposal should be revised as Modified Proposal 2.2-1: Replace the RAN#106-e agreement and working assumption with: In case a separate initial UL BWP is used configured for RedCap UEs, it is supported that the network can enable/disable intra-slot PUCCH frequency hopping within the separate initial UL BWP in the PUCCH resource for HARQ feedback for Msg4/MsgB for RedCap UEs. The frequency hopping is can be enabled/disabled at least via SIB and DCI scheduling Msg4/MsgB. FFS inter-slot PUCCH frequency hopping outside UE maximum bandwidth ZTE, Sanechips Y TCL Y Fine with the FL proposal Xiaomi Y Panasonic Y Sharp Y Lenovo, Motorola Mobility Y Spreadtrum Y CATT Y FL1 The following agreement was made in the RAN1 online (GTW) session on Monday 11th October: Agreement: Confirm the working assumption: In case a separate initial UL BWP is configured for RedCap UEs, it is supported that the network can enable/disable intra-slot PUCCH frequency hopping within the separate initial UL BWP in the PUCCH resource for HARQ feedback for Msg4/MsgB for RedCap UEs. The frequency hopping is enabled/disabled at least via SIB. Moreover, two contributions point out that when the PUCCH frequency hopping (FH) is disabled, the orthogonality between non-FH PUCCH and FH PUCCH transmissions needs to be ensured, e.g., by using two time-domain orthogonal cover codes (OCC) sequences. [4]: For PUCCH format 1, support PUCCH without frequency hopping to be transmitted with two OCC sequences (as stipulated for legacy FH PUCCH). [19]: 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 generates two base sequences for the PUCCH as if intra-slot frequency hopping is enabled for the PUCCH transmission. Medium Priority Question 2.2-2: Are any standard changes desired in order to support multiplexing of non-FH and FH PUCCH transmissions in PUCCH resources for HARQ feedback for Msg4/MsgB? If yes, please elaborate. Company Y/N Comments Huawei, HiSilicon The issue for PUCCH format 1 in [4] applies to PUCCH after initial access, instead of for HARQ for Msg4/MsgB. Therefore the question can be modified like Modified Question 2.2-2 Are any standard changes desired in order to support multiplexing of non-FH and FH PUCCH transmissions in PUCCH resources for HARQ feedback for Msg4/MsgB? If yes, please elaborate. Panasonic When the configuration on PUCCH for Msg4/B is separate for RedCap and non-RedCap, our view is the PRB doesn＊t overlap with each other. In this case, no need to consider OCC sequence collision. For example, RedCap PUCCH can be configured in the PRBs adjacent to non-RedCap PUCCH resource so that PUSCH resource fragmentation is minimized Or, if it is necessary to overlap those PUCCH resources in frequency, it may be beneficial to generate two sequences to avoid sequence collision as proposed by [4, 19]. FUTUREWEI Companies should check to see whether orthogonality is preserved when hopping is disabled. In our understanding of 38.211 clause 6.3.2.4.1, the text appears to support no intra-slot frequency hopping. The current RRC parameter intraSlotFrequencyHopping is set to enable with the description ※Enabling intra-slot frequency hopping, applicable for all types of PUCCH formats. For long PUCCH over multiple slots, the intra and inter slot frequency hopping cannot be enabled at the same time for a UE. See TS 38.213 [13], clause 9.2.1.§ FL2 The question has been updated based on the above comment from Huawei/HiSilicon. Medium Priority Question 2.2-2a: Are any standard changes desired in order to support multiplexing of non-FH and FH PUCCH transmissions in PUCCH resources? If yes, please elaborate. vivo We agree with Panasonic that NW can configure PUCCHs for RedCap (FH disabled) and non-RedCap UEs (FH enabled) on non-overlapping RBs. Nordic Yes In our understanding for default PUCCH resources from pucch-ResourceCommon are used resources 0-7 have First-hop on left and First-hop on right resource 8-15 have First-hop on right and First-hop on left and resource 0/1/2＃ and resource 8/9/10.. use the same sequence. Now, when we disable hopping for pucch-ResrouceCommon , are all the resource mapped to First hop only, and how to distuquish resource 0 from 8? Is only half of resources used? But perhaps we are missing something, in any case this should be clarified. Intel No Not essential in our view 每 some multiplexing may be possible via proper assignment of PRBs to non-RedCap and RedCap UEs, etc., but for the most part, we expect the typical operation to follow as suggested by Panasonic and vivo. DOCOMO Y Of course it is possible to multiplex RedCap UEs w/o FH and non-RedCap UEs w/ FH in TDM/FDM manner. However, as pointed out by our contribution [19], if their PUCCHs are overlapped, they would interfere with each other irrespective of the applied CS, unlike the overlap between non-RedCap UEs. We try to address the issue on the degradation of the number of multiplexed UEs by CS caused by FH disabling. One contribution also points out that when FH is disabled within the separate initial UL BWP, it is not clear which PRB index is to be used for the PUCCH transmission [19]. The contribution proposes to use either PRB index of first hop or second hop depending on the indicated r_PUCCH. This proposal can be considered at a later stage after other more critical proposals have seen some progress. Initial and non-initial DL BWP Separate initial DL BWP RAN1#105-e agreed the following working assumption related to separate initial DL BWP: Working assumption: At least for TDD, an initial DL BWP for RedCap UEs (which is not expected to exceed the maximum RedCap UE bandwidth) can be optionally configured/defined separately from the initial DL BWP for non-RedCap UEs at least after initial access FFS the details of the configuration/definition The configuration for a separately configured initial DL BWP for RedCap UEs is signaled in SIB. whether to support that separate initial DL BWP for RedCap UEs can include a configuration of CORESET and CSS(s) whether part of the configuration can be defined instead of signaled If a separate initial DL BWP for RedCap UEs is configured/defined, this separate initial DL BWP for RedCap UEs can be used at least after initial access (i.e., at least after RRC Setup, RRC Resume, or RRC Reestablishment). FFS during the initial access FFS: whether a separately configured initial DL BWP for RedCap UEs needs to contain the entire CORESET #0, and, if not, the Redcap UE behaviour for CORESET #0 monitoring FFS: supported bandwidths in the separate initial DL BWP FFS: whether additional SSB is transmitted in the separately configured initial DL BWP for RedCap UEs FFS: FDD case Moreover, we have the following proposal from the latest FLS in RAN1#106-e [3]: Proposal: Regarding random access in idle/inactive mode in separate initial DL BWP for RedCap UEs in FR1, If a separate initial DL BWP for RedCap UEs is configured in FR1, is configured for random access, including CORESET/CSS for random access. If the separate initial DL BWP is configured for random access but not for paging, then the UE shall not expect SSB transmission in the separate initial DL BWP. Note: The network may configure SSB in this case. Regarding paging in idle/inactive mode in separate initial DL BWP for RedCap UEs in FR1, From RAN1 perspective, if a separate initial DL BWP for RedCap UEs is configured in FR1, it can be configured for paging, including CORESET/CSS for paging. FFS: If the separate initial DL BWP is configured for paging, then the UE [may expect / shall not expect] SSB transmission in the separate initial DL BWP. FFS: Note: The network may configure SSB in this case. Regarding CORESET#0 and SIB1 in idle/inactive/connected mode for RedCap UEs in FR1, If a separate initial DL BWP for RedCap UEs is configured in FR1, then the UE shall not expect it to contain MIB-configured CORESET#0 or SIB1. Note: The network may configure MIB-configured CORESET#0 or SIB1 to be within the separate initial DL BWP. If an RRC-configured DL BWP is configured in FR1, then the UE shall not expect it to contain MIB-configured CORESET#0 or SIB1. Note: The network may configure MIB-configured CORESET#0 or SIB1 to be within the RRC-configured DL BWP. In connected mode, the UE is not required to monitor CORESET#0 periodically for SI updates. FFS: How SI update notifications are indicated to RedCap UEs Regarding connected mode in an RRC-configured active DL BWP for a RedCap UE in FR1, Whether the UE can expect SSB transmission in the RRC-configured active DL BWP depends on its UE capabilities (e.g., whether it supports FG 6-1a or only FG 6-1). A UE not supporting operation without SSB transmission in the RRC-configured active DL BWP may expect SSB transmission in the RRC-configured active DL BWP. This corresponds to mandatory RedCap UE feature. A UE optionally supporting operation without SSB transmission in the RRC-configured active DL BWP shall not expect SSB transmission in the RRC-configured active DL BWP. This corresponds to optional RedCap UE feature. FFS: For BWP#0 configuration option 1, whether the UE can expect SSB transmission in the separate initial DL BWP when it is used in connected mode Note: According to 38.331 Annex B.2, BWP#0 is considered to be an RRC-configured BWP in BWP#0 configuration option 2 but not in BWP#0 configuration option 1. Most of the contributions (e.g., [4, 5, 6, 7, 11, 12, 13, 15, 16, 18, 24, 26, 27, 29]) agree that configuring/defining a separate initial DL BWP for RedCap UEs is beneficial for flexibility and offloading purposes and also it is needed in scenarios where non-RedCap initial DL BWP is larger than the RedCap UE bandwidth. In addition, several contributions indicate that the configuration for a separately configured initial DL BWP for RedCap UEs can be signaled in SIB [6, 11, 12, 15, 24, 26]. In addition, several contributions support that an initial DL BWP for RedCap UEs can be optionally configured/defined separately from the initial DL BWP for non-RedCap UEs in FDD as well [12, 18, 24, 27]. Although there are several FFSs that need to be addressed, there is a general agreement about the optional configuration of a separate initial DL BWP for RedCap. Therefore, the following proposal can be considered, with the understanding that the FFSs regarding various aspects including CORESET #0, CSSs and SSB will be discussed subsequently. FL1 High Priority Proposal 3.1-1: A separate initial DL BWP can be optionally configured/defined for RedCap UEs and it can be signaled in SIB. This applies to both TDD and FDD cases. Company Y/N Comments Qualcomm We can agree with this proposal, if the conditions/motivations for the separate initial DL BWP configuration are provided same as Proposal 2.1-1. vivo We would like to clarify that this separate initial DL BWP can be used both during and after the initial access, hence we suggest modifying as below A separate initial DL BWP can be optionally configured/defined for RedCap UEs both during and after initial access and it can be signaled in SIB. This applies to both TDD and FDD cases. OPPO Besides the purpose of offloading, this separate initial DL BWP is also important for alignments of centre frequency of initial DL BWP and initial UL BWP. Therefore, the configuration/definition shall consider both initial DL and initial UL BWP. Nordic We are generally fine, but since there are unresolved issues for the offloading case, we should confirm WA on for the case that we know works. A separate initial DL BWP can be optionally configured/defined for RedCap UEs and it can be signaled in SIB. This applies to both TDD and FDD cases. This applies at least for the case when CORESET#0 and CD-SSB is within the separate initial DL BWP Huawei, HiSilicon Y with modifications Similar question as UL on how this single separate initial DL BWP interacts with the legacy initial DL BWP, i.e. BWP switching or RF retuning among different frequency locations. Suggest to modify the proposal as Modified Proposal 3.1-1: A separate initial DL BWP can be optionally configured/defined for RedCap UEs and it can be signaled in SIB. This applies to both TDD and FDD cases. FFS how the configuration/determination is applied, e.g. by BWP switching or RF retuning ZTE, Sanechips Y We are fine with the FL proposal. A separate initial DL BWP should be configured if BW of the legacy initial DL BWP exceeds the maximum RedCap UE bandwidth. As with TDD, a separate initial DL BWP can also be configured in FDD mode, which provides greater scheduling flexibility in the case of PDCCH blocking due to excessive number of accessed RedCap UEs. Besides, the configuration of the separate initial DL BWP applies a unified BWP configuration design for TDD and FDD. TCL Y The question mentioned by Huawei needs further study Xiaomi The configuration of initial DL BWP should be discussed case by case. In some cases, the initial DL BWP should (rather than can be optionally) be configured for RedCap Case 1: when the SIB-configured initial DL BWP for non-RedCap is wider than RedCap＊s maximum UE BW, then separate initial DL BWP should be configured/defined for RedCap Case 2: in TDD, the separately configured initial UL BWP has different center frequency from the MIB-configured initial DL BWP, then separate initial DL BWP should be configured (NOTE: this case is also related to Question 3.1-5, we can touch this case after there is conclusion for Question 3.1-5) For the remaining cases, the separate initial DL BWP can be optionally configured/defined for RedCap Panasonic Y Sharp Y We are fine with the FL proposal. At least to support initial DL BWP with more than RedCap UE bandwidth for non-RedCap UEs, the separate initial DL BWP should be supported. Moreover, for TDD case, the separate initial DL BWP is needed for the center frequency alignment. Lenovo, Motorola Mobility Y Spreadtrum Y CATT Y At least for the case of ＆after initial access＊, and at least for the case when legacy SIB1-configured initial DL BWP is wider than the maximum RedCap UE BW, such separate initial DL BWP is needed. Nokia, NSB Y Ericsson Y We propose the following update to avoid confusion: A separate initial DL BWP can be optionally configured/defined for RedCap UEs and it can be signaled in SIB. This applies to both TDD and FDD cases. Intel Y China Telecom Y We are fine with FL proposal. And we think it could be used at least during initial access. DOCOMO Y FUTUREWEI Y If no agreement is reached on a separate initial DL BWP, a RedCap UE will have to use the MIB-configured CORESET#0 during initial access. While using the MIB-configured CORESET#0 works, it has many drawbacks for the network when considering RedCap UEs. To focus on at least initial access, the following modification is suggested A separate initial DL BWP can be optionally configured/defined for RedCap UEs for at least initial access and it can be signaled in SIB. CMCC Y Separate initial DL BWP can be configured for offloading or for center frequency alignment. NEC Y LGE Y Okay with the ※configured§, but seems to need clarifications for the ※defined§. Apple We think this should be discussed with other relevant proposals as part of package. Samsung For signaling the configuration, it needs be clarify if it＊s SIB1 or other SIBs. We think SIB1 is needed to get configuration for RACH process. Suggest to remove ※/defined§ and add ※at least§ before ※configured§ OPPO If this separate initial DL BWP is used to align the centre frequency of initial DL BWP and initial UL BWP, at least the centre frequency is defined by that of the initial UL BWP. MediaTek We should include the conditions for the separate DL BWP. We are fine with the updated proposal from Nordic. FL2 Based on the received responses to Proposal 3.1-1 and Proposal 3.1-4, the following updated proposal can be considered. A corresponding proposal for separate initial UL BWP is provided in Proposal 2.1-1a. High Priority Proposal 3.1-1a: A separate initial DL BWP for RedCap UEs can be configured in SIB1. It can be used both during and after initial access. It is no wider than the maximum RedCap UE bandwidth. It is always configured if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. This applies to both TDD and FDD cases. FFS whether part of the configuration is implicitly signaled vivo Fine in general Similar as for initial UL BWP, we would like to get clarification on 3rd sub-bullet. There seems to be different interpretation in case ※the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth§ and separate initial DL BWP is not configured. Interpretation#1: In such case, the cell does not support RedCap UEs. Interpretation#2: In such case, the cell can still support RedCap UEs and RedCap UEs uses initial DL BWP determined by CORESET#0 BW. Nokia, NSB Y Qualcomm Y Nordic N Same concern as in GTW. If this shall be agreement, then additional FFS is necessary High Priority Proposal 3.1-1a: A separate initial DL BWP for RedCap UEs can be configured in SIB1. It can be used both during and after initial access. It is no wider than the maximum RedCap UE bandwidth. It is always configured if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. This applies to both TDD and FDD cases. FFS whether part of the configuration is implicitly signaled FFS whether offloading from MIB-CORESET#0 and/or CD-SSB is supported Ericsson Y IDCC Y Intel Almost We are mostly fine with the updated version, except for the following bullet: It is always configured if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. In our understanding, the above is referring to ※initial DL BWP for non-RedCap UEs that is configured by SIB1§, and for such a case, NW should not be mandated to configure separate initial DL BWP if initial DL BWP for non-RedCap UEs as configured by SIB1 is larger than max RedCap UE BW. If separate initial DL BWP is not provided, in such a case, RedCap UEs can continue to operate in initial DL BWP defined by CORESET #0 (as obtained from MIB). Lenovo, Motorola Mobility Y in general For the first bullet, we prefer revision as below. It can be used after initial access. It can also be used during initial access in case it does not contain MIB-configured CORESET#0. Otherwise, MIB-configured CORESET#0 is used during initial access (same as legacy). FUTUREWEI2 Y in principle Additional clarification for the 3rd bullet: can the MIB-configured CORESET#0 be used for a RedCap UE when initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth? NEC Almost Regarding the first sub-bullet, if ※during initial access§ is intended ※random access§, we would be fine. There would be some FFS point in IDLE/INACTIVE as in FL2 High Priority Proposal 3.2-4. DOCOMO Y But it has been pointed out multiple times that RAN2 will decide which SIB is used. Better to replace ※SIB1§ in the main bullet to ※SIB§ Next, the FFSs related to the separate initial DL BWP for RedCap are discussed. CORESETs and CSSs in separate initial DL BWP for RedCap Many contributions propose that a separate SIB-configured initial DL BWP for RedCap (if configured) does not need to contain the entire CORESET #0 [4, 5, 6, 8, 10, 11, 16, 18, 26]. Also, several contributions mention that the separate initial DL BWP for RedCap UEs can include a configuration of CORESETs and CSS(s) [4, 6, 11, 12, 13, 16, 23, 24, 27, 29]. In addition, one contribution proposes to support paging on separate initial DL BWP [31]. One contribution proposes to down-select from either mandating the separate initial DL BWP to always overlap with CORESET#0 or introducing a RedCap-specific CORESET#0 where RedCap UEs monitors paging and SI, in order to avoid BWP switching [33]. If neither of these options are configured by the network, the contribution proposes to consider the cell as barred for RedCap UEs. FL1 High Priority Proposal 3.1-2: A separate SIB-configured initial DL BWP for RedCap UEs (if configured) does not need to contain the entire CORESET #0. FFS: which CORESET(s) and CSS(s) that must be configured for separate initial DL BWP Company Y/N Comments Qualcomm N Defining/configuring a separate initial DL BWP for RedCap UE does not necessarily mean CORESET#0 cannot be contained within this initial DL BWP. When the SIB1-configured initial DL BWP of non-RedCap UE is wider than the max BW of RedCap UE (shown by the figure below), a separate initial DL BWP should be configured/defined for RedCap UE. In this case, the RedCap-specific initial DL BWP can be MIB-configured CORESET#0, or a SIB-configured separate initial DL BWP containing CORESET#0. vivo Y Our understanding is that the FL proposal does not exclude the possibility to contain entire MIB-configured CORESET#0 within the separately configured initial DL BWP. OPPO Y Or to make it clear. It can be modified as: A separate SIB-configured initial DL BWP for RedCap UEs (if configured) does not need to necessarily contain the entire CORESET #0. FFS: which CORESET(s) and CSS(s) that must be configured for separate initial DL BWP Nordic N We are NOT OK to support offloading from CORESET#0 unless NCD-SSB is agreed to be guaranteed at least in RRC A separate SIB-configured initial DL BWP for RedCap UEs (if configured) does not need to contain the entire CORESET #0. FFS: which CORESET(s) and CSS(s) that must be configured for separate initial DL BWP Note: This does not change the previous agreement that SSB in active BWP is a baseline capability. Huawei, HiSilicon Y with modifications A separate SIB-configured initial DL BWP for RedCap UEs (if configured) does not need to contain the entire CORESET #0. FFS: whether/which CORESET(s) and CSS(s) that must be configured for separate initial DL BWP ZTE, Sanechips Y We are fine with the FL proposal. Mandatory inclusion of CORESET#0 limits the frequency-domain location and configuration flexibility of the separate initial DL BWP for RedCap UEs, which is detrimental to efficient resource utilization and PDCCH blocking resolution. Besides, if the separate SIB-configured initial DL BWP for RedCap UEs contains the entire CORESET#0 located in the carrier middle, the separate initial UL BWP for RedCap UEs also has to be placed in the carrier middle for TDD center frequency alignment, which will aggravate the PUSCH resource fragmentation. The FFS bullet is overlapped with question 3.1-3. It is suggested to be removed. TCL Introducing a RedCap-specific CORESET#0 may be an option when the separate initial DL BWP does not contain the (legacy) CORESET#0 Xiaomi Y We are fine with the FL proposal. Panasonic Y We suggest to clarify that the CORESET#0 here is MIB-configured one and not RedCap-specific CORESET#0. Then it can be described as ※~ not need to contain the entire MIB-configured CORESET #0§ Sharp Y One motivation to have the separate initial DL BWP is the center frequency alignment between initial DL/UL BWPs. Therefore, the position of separate initial DL BWP should be allowed to locate out of CORESET#0 to have flexibility to put the initial UL BWP on edge of the carrier. Lenovo, Motorola Mobility Y Spreadtrum Y CATT Y It should be clear that the separate initial DL BWP may still entire MIB-configured CORESET#0, which is not precluded by this proposal. Nokia, NSB Y We are fine with the proposal. Our understanding is that this does not preclude the case where the separate initial DL BWP contains CORESET#0. Ericsson Y We are also fine with updates from Oppo and Panasonic. Intel Y Fine to add the note from Nordic if it can help us move forward. China Telecom Y In our understanding, the separate SIB-configured initial DL BWP for RedCap UEs (if configured) does not need to contain the entire CORESET #0 for flexibility and offloading purpose. The configuration details about initial DL BWP need more discussion and clarification. DOCOMO Y FUTUREWEI Y CMCC Y Fine with Panasonic＊s modification. NEC Y To be clear a separate initial DL BWP may contain entire CORESET#0, it would be preferable to describe the proposal in more neutral way, e.g. A separate SIB-configured initial DL BWP for RedCap UEs may be configured either to contain or not to contain all RBs of the CORESET with index 0 configured by MIB. LGE Y Introducing CORESET#0 dedicated for RedCap or configuring CORESETs for supporting the equivalent functions of CORESET#0 can be considered. Samsung Y We share similar view as vivo. This doesn＊t mean separate initial DL BWP cannot contain CORESET #0. So, the case pointed out by Qualcomm is not excluded by this proposal. MediaTek N The issue of how to do RRM/RLM/synchronization (e.g. by requiring NCD-SSB) need to be addressed first. FL2 Based on the received responses to Proposal 3.1-2 and Question 3.1-3, the following updated proposal can be considered. High Priority Proposal 3.1-2a: A separate SIB-configured initial DL BWP for RedCap UEs (if configured) does not need to may be configured to either contain or not contain the entire MIB-configured CORESET #0. FFS: which CORESET(s) and CSS(s) that must be configured for separate initial DL BWP It is configured with at least one CORESET/CSS. vivo Y Nokia, NSB Y Qualcomm We can agree with this proposal if this separate SIB-configured initial DL BWP for RedCap UEs includes SSB and at least one CORESET/CSS Nordic N This is already addressed in 3.2-4 , and we are OK if agreed as part of Option 2 in 3.2-4, otherwise we do not support. MediaTek N The proposal can be acceptable if a NCD-SSB is configured on the DL BWP for RedCap UEs Ericsson Y IDCC Y Intel Y Lenovo, Motorola Mobility The last bullet is not clear enough (especially considering the diverse view of mandatory RA-SS in the separate initial DL BWP). We prefer to remove ※/CSS§ and revise as ※It is configured with at least one CORESET§. FUTUREWEI2 Clarification question: is the proposal for during initial access, after initial access, or both? NEC Y DOCOMO Y FL1 High Priority Question 3.1-3: For a separate initial DL BWP for RedCap, which of the following CSSs can/must be configured? Random access CSS Paging CSS Any other CSS? Company Which ones of 1/2/3 can be configured? Which ones of 1/2/3 must be configured? Comments Qualcomm 1, 2, 3 (e.g. CORESET/CSS associated with PEI and SDT) 1, 2 The RO of RedCap UE is expected to be contained within the initial UL BWP of RedCap UE. Therefore, the CSS for RA should be configured within the initial DL BWP of RedCap UE. When operating in the separate initial DL BWP, RedCap UE is expected to receive notification of SI update and/or ETWS. Therefore, paging CSS should be configured in the initial DL BWP of RedCap UE. In addition to RACH and paging, RedCap UE is expected to support small data transfer (SDT) for power saving and signaling overhead reduction. Besides, CSS for R17 PEI can be configured as well in the initial DL BWP of RedCap UE. vivo 1 Random access CSS 2 Paging CSS 3 SIB, PEI, SDT related CSS) 1 1 must be configured for a separately configured initial DL BWP. 2 is preferable to be configured, but if not configured, UE stays at legacy initial DL BWP for paging monitoring and switch to the separately configured initial DL BWP only when random access procedure is performed. 3 If PEI is configured, it is preferred to configure in the same DL BWP as paging CSS. OPPO 1 Random access CSS 2 Paging CSS 1 Random access CSS If separately configured initial DL BWP is used to align centre frequency of initial DL BWP and initial UL BWP, CSS for Random access CSS shall be configured. CSS for paging can also be configured for offloading. If not, legacy MIB -configured initial DL BWP can be reused. Nordic SIB1, OSI, RA, Paging, PEI If BWP shall be used for IDLE camping or SDT then SIB1, OSI, RA, Paging Otherwise, RA is enough Huawei, HiSilicon 1, 2 None The same as legacy that those are configurable ZTE, Sanechips 1 and 2 None For the purpose of offloading, mitigating the impacts on legacy UE during paging and RACH procedure, and keeping the center frequency alignment in TDD RACH procedure, random access and/or paging can be configured in the separate initial DL BWP. TCL 1,2 1 Same comments of OPPO Xiaomi 1,2,3 1 This proposal can be put lower priority. Before we discuss this issue, we should firstly decide the which RRC status the initial DL BWP can be applied for. Panasonic 1 and 2 We think random access CSS should be possible to be configured for off-loading of Msg2/4. We propose that paging CSS can be configured only when SSB (CD or non-CD) is also available in the separate initial DL BWP. Otherwise, paging CSS should not be configured but RedCap UE should follow CSS common with non-RedCap UEs. After a long sleep, the UE needs to be synchronized using SSB before the paging reception. It can be multiple SSBs depending on SINR conditions. If SSB is not available, the UE has to perform RF retuning to receive CD-SSB and then power consumption would increase. Sharp 1, 2, 3 1 For RedCap UEs in IDLE/INACTIVE state, it should be up to gNB configuration on whether configure RedCap UEs to monitor PDCCH for paging/SIB in CORESET#0 or in seperate initial DL BWP. On the other hand, Random access CSS should be configured if the separate initial DL BWP is needed. Lenovo, Motorola Mobility 1, 2 none RedCap UEs perform RA in separate initial DL BWP if RA-SS is configured in the separate initial DL BWP. Otherwise, RA is performed in the MIB-configured CORESET#0. RedCap UEs perform paging in separate initial DL BWP if paging-SS is configured in the separate initial DL BWP. Otherwise, paging is performed in the MIB-configured CORESET#0. Spreadtrum 1, 2, 3 (SDT related CSS which can be considered as RACH like) 1 We share the similar view as vivo. CATT 1, 2 none RedCap UE is always capable to use RACH CSS and Paging CSS in legacy initial DL BWP (defined by MIB-configured CORESET#0). None of the CSS ＆must be configured＊, but ＆can be optionally configured＊ for RedCap separately. Nokia, NSB 1, 2 none If the initial DL BWP contains CORESET#0, then this can be used for random access and paging. And also e.g. if random access CSS is not configured, then UE can still perform random access using CORESET#0. Ericsson RA, Paging, SIB1, OSI None Here we consider only idle/inactive states and Rel-15/16 features. Intel 1, 2, 3 (RMSI, OSI, PEI, SDT) None In terms of minimum configuration in separate initial DL BWP, we can compromise to mandate configuration of random access CSS (Type 1 CSS) for TDD for center-freq alignment between separate initial DL BWP and initial UL BWP in which UE is configured with ROs. DOCOMO 1, 2, 3 FUTUREWEI 1,2,3 1 If the separate initial DL BWP is used for the RACH procedure, then the RA CSS is needed CMCC 1,2,3 1 When separate initial DL BWP is configured to keep center frequency alignment with separate initial UL BWP, RACH CSS should be configured for corresponding downlink procedure, in this case, retuning during RACH between DL and UL BWP can be avoided. RRC idle/inactive UEs can monitoring paging PDCCH on initial DL BWP defined by CORESET#0, which is also used by non-RedCap UEs. NEC 1, 2, 3 (Type0- PDCCH CSS set, Type0A-PDCCH CSS set, etc.) None RedCap UE follows Rel-15 UE behavior on monitoring CSS sets LGE 1, 2, 3 None Similar view with Lenovo. The search spaces for SIB1, OSI can also be configured. Apple 1,2,3 None Agree with Lenovo/LGe. Samsung 1 RACH CSS 2 paging CSS 1. RACH CSS (if this separated can be used during initial access) 2. none (if this cannot be used during initial access) RACH CSS depends on whether this separated initial DL BWP can be used during initial access. For SIB, PEI, SDT related CSS, we need further study. we think SDT related CSS can be treated as for Random access. PEI related paging, we think it can be further discussed after the decision on paging CSS. MediaTek 1, 2, 3 1 FL2 About half of the received responses think that RA CSS must be configured for the separate initial DL BWP, and about half think that there is no particular CSS that must be configured. Some of the responses argue that RA CSS must be configured for initial UL/DL BWP center frequency alignment purpose. This aspect is treated in Proposal 3.1-5a. Based on the received responses, Proposal 3.1-2a has been updated to say that the separate initial DL BWP is configured with at least one CORESET/CSS. Use of separate initial DL BWP during initial access If a separate initial DL BWP for RedCap UEs is configured/defined, the separate initial DL BWP for RedCap UEs can be used during initial access [4, 6, 10, 11, 15, 18, 22, 27]. Contribution [6] states that for RedCap UEs, the IE locationAndBandwidth specified in the initial DL BWP can be applied and used during the initial access. FL1 High Priority Proposal 3.1-4: A separate initial DL BWP for RedCap UEs (if configured) can be used during the initial access. Company Y/N Comments Qualcomm Y vivo See our comments for Proposal 3.1-1. OPPO Y If separately configured initial DL BWP is used to align centre frequency of initial DL BWP and initial UL BWP, CSS for Random access CSS shall be configured. Therefore, it can be used during initial access Nordic Y Huawei, HiSilicon Y ZTE, Sanechips Y Similar motivation with question 3.1-3. The relation between question 3.1-4 and 3.1-3 need clarification. TCL Y Xiaomi This proposal depends on the output of whether center frequency should be aligned during initial access. If the answer is Yes, in some cases, a separate initial DL BWP MUST be used (rather than can be used ) during initial access Panasonic Y Sharp Y To avoid RF retuning during random access procedure in TDD, we prefer to use the separate initial DL BWP during the initial access. Lenovo, Motorola Mobility Y If RA-SS is configured in the separate initial DL BWP, the separate initial BWP can be used during initial access. Otherwise, it is not used during initial access and RedCap UEs use MIB-configured CORESET#0. Spreadtrum Y CATT FFS We would like to clarify that, this should be conditional: If separate initial DL BWP is configured and contains entire MIB-configured CORESET#0, the separate initial DL BWP is NOT be used during initial access. The RedCap UE shall use legacy initial DL BWP (defined by MIB-configured CORESET#0) during initial access. This is the fallback option, and is the same with current NR framework (imaging that no non-RedCap UE is in the network). Else, if separate initial DL BWP is configured but does NOT contain entire MIB-configured CORESET#0, the separate initial DL BWP can be used during initial access (when RACH CSS is configured in this separate initial DL BWP). Nokia, NSB Y Ericsson Y Intel Y The ※use§ during initial access depends on the PDCCH CCS types configured in the separate initial DL BWP. China Telecom Y We are fine with FL proposal. However, the configuration details about initial DL BWP need more discussion and clarification. DOCOMO Y FUTUREWEI Y CMCC Y At least it can be used for RACH related downlink transmission. NEC Conditionally Yes. If different center frequency of initial UL/DL BWP is supported during initial access in TDD, MIB-configured CORESET#0 can be used as in Rel-15 and we don＊t see much motivation to support this. Otherwise, Yes. It is also not clear for us whether RedCap UE uses MIB-configured CORESET#0 in IDLE/INACTIVE except RA. LGE Y The separate initial DL BWP for RedCap should be used during initial access to avoid RF retuning when an initial UL BWP for RedCap is configured with different center frequency from the MIB-configured CORESET#0 BWP in TDD. Apple Yes Samsung We can live with to make this as WA other than agreement, because we want to avoid a situation that there is no consensus on whether SSB can be transmitted or not. Besides, we think CATT＊s comment is valid and better to be clarified. MediaTek Y FL2 This proposal is merged with Proposal 3.1-1 into Proposal 3.1-1a. Initial UL/DL BWP center frequency in TDD Another key consideration is related to initial UL/DL BWP center frequency in TDD. Several contributions support/accept having the possibility of separate TDD center frequencies for initial UL/DL BWPs during initial access [4, 6, 10, 12, 19, 26]. However, some other contributions indicate that the same center frequency is preferred to be maintained for initial UL/DL BWPs [7, 14, 15, 25]. [4]: During initial access, the alignment of the center frequency can be left to UE implementation without required by specification. [6]: During initial access, frequency retuning between initial DL and UL BWPs center frequencies is not expected to be an issue as far as the UE implementation is concerned, given the relaxed required switching time between DL and UL during initial access. [6]: With the support of separate center frequencies for initial UL/DL BWPs in TDD during initial access, all concerns regarding the PUSCH resource fragmentation and the presence of SSB and CORESET #0 within the initial DL BWP are resolved. [8]: At least after initial access, the center frequencies for separate initial UL/DL BWPs for RedCap UEs in TDD are the same. FFS: during initial access [26]: For initial DL/UL BWPs during initial access procedure, the RF-retuning latency and power consumption maybe acceptable. [27]: During initial access, timeline relationship in Tx/Rx switching may need to take center frequency retuning into account if different center frequency between initial DL BWP and initial UL BWP is supported. [28]: Supporting initial DL/UL BWP pair with different center frequencies is specified as an optional capability for RedCap UE in TDD. Based on the expressed views, the following question can be considered. FL1 High Priority Question 3.1-5: Regarding the initial UL/DL BWPs center frequencies in TDD during initial access, can the following options be considered for down selection? If yes, please indicate your preferred option(s). If no, please elaborate in the Comments field. Option 1: During initial access, the center frequencies for initial UL/DL BWPs can be different, and the initial DL BWP always contain CORESET #0 and SSB. Option 2: During initial access, the center frequencies for initial UL/DL BWPs are the same, but the initial DL BWP does not always contain CORESET #0 and SSB. Company Y/N Option(s) Comments Qualcomm N Option 2 is not supported since it does not contain SSB Option 2 is not acceptable to us. Option 1 can be FFS if separate PRACH resources are configured for RedCap UE within the initial UL BWP of RedCap UE. Without early indication of RedCap UE type by msg1 or msgA preamble, NW cannot differentiate RedCap UE and non-RedCap UE. As a result, RedCap UE may receive an invalid grant which does not accommodate the center frequency change of DL/UL BWP. vivo It seems necessary to clarify the proposal here is about the center frequency alignment between the separately configured initial UL BWP and initial DL BWP for RedCap UEs, since there might be a case where UE works on the separately configured initial UL BWP while share the legacy initial DL BWP with non-redcap UEs. The SSB transmission issue does not need to be coupled with the center frequency alignment issue, and can be discussed separately as later sections (3.2 and 3.3). OPPO During initial access, the center frequencies for initial UL/DL BWPs shall be the same. Otherwise, it will complicate UE＊s implementation and the timing during initial access shall be reviesed. Nordic N Non of the options Option 3: During initial access in TDD, the center frequencies for initial UL and CORESET#0 can be different CORESET#0 is within BW of initial UL BWP Huawei, HiSilicon Y Opt 2 is preferred The issue of the centre frequency alignment and BWP with/without SSB should be decoupled. On one hand, even if the centre frequency of UL and DL is different during initial access, the DL efficiency and other impact on network due to BWP mandated with SSB exists after initial access. Whether they are kept or not after initial access require further discussion and thus it does not tackle the fundamental issue. On the other hand, supporting BWP without SSB from initial access can release the concern of BWP center frequency misalignment regardless of during and after initial access, and have minor spec impact and implementation impact to both gNB and UE. ZTE, Sanechips Y 2 The transmission of legacy SSB and CORESET#0 in the separate initial DL BWP for RedCap UEs is up to gNB configuration. Requiring that the separate initial DL BWP always contain SSB and CORESET#0 greatly limits its frequency-domain location and configuration flexibility, which is detrimental to efficient resource utilization and PDCCH blocking resolution. Besides, there is no strong motivation or necessity to mandate SSB transmission in the separate initial DL BWP. Furthermore, to obtain a unified design, TDD center frequency alignment should be ensured during initial access as after initial access. It is noted that BWP#0 (i.e. the initial BWP) has two possible configuration options, i.e. BWP#0 configuration option 1 and BWP#0 configuration option 2. From the UE capability point of view, BWP#0 under configuration option 2 is considered as an RRC-configured BWP. In this case, RedCap UEs supporting only one BWP cannot meet different TDD center frequency alignment requirements during and after initial access. Therefore, TDD center frequency alignment should be mandatory both during and after initial access. TCL Y Option 1 Xiaomi Same comment with vivo. Whether include SSB can be discussed separately. We could just focus on whether the center frequency of TDD should be aligned or not Panasonic Y We think both options can be supported. Option 1 is beneficial to reduce resource overhead by duplicated CD-SSB or PDCCH CSS. Option 2 is also beneficial to reduce the RF retuning by a RedCap UE between DL and UL center frequencies. Which option to configure is up to the gNB. Sharp Here, if ※CORESET #0 and SSB§ in the FL proposal means legacy CORESET#0 and legacy CD-SSB, we are basically OK with option 2 for RACH procedure during initial access. Regarding additional common CORESET and additional NCD-SSB, we can separately discuss. Lenovo, Motorola Mobility N During initial access, the center frequencies of initial DL/UL BWPs can be different if the separate initial DL BWP contains MIB-configured CORESET#0 (e.g., initial UL BWP in the carrier edge, but CORESET#0 not) During initial access, the center frequencies of initial DL/UL BWPs are the same if the separate initial DL BWP (with RA-SS) does not contain CORESET#0 and SSB. Spreadtrum Y CATT Seems both options are useful. Option 1 may be used when initial DL BWP is shared and used for initial random access of RedCap. Option 2 can be used when separate initial DL BWP is configured and is also used for initial random access of RedCap. If SSB is always required in the initial DL BWP during initial access, we prefer Option 1. Otherwise we are fine with both. Nokia, NSB We also share the view that the center frequency alignment can be considered separately from the SSB. Ericsson Y 1 and/or 2 We support both options. Intel Agree with vivo and others that the SSB and CORESET #0 issue should be decoupled from the DL-UL center frequency alignment issue. On the DL-UL center frequency alignment issue, our views are summarized as below: It is not necessary to align center frequencies between DL and UL during idle/inactive modes since the DL-UL switches (and vice versa) are not frequent. If the above is not acceptable, as compromise, we can accept to consider aligned center frequency between UL and DL between the initial UL BWP in which the RedCap UE transmits PRACH and the initial DL BWP in which it is expected to monitor for Type 1 PDCCH CSS for random access. (Please note that we just realized a typo in our tdoc R1-2109617 [18] for Proposal 1 where it should say PDCCH CSS Type 1 instead of ※CSS Type 2§: Proposal 1 (from R1-2109617 [18]): A RedCap UE may expect that, in RRC idle or inactive modes, initial UL BWP configured for RedCap UEs for PRACH or MsgA transmissions shares the same center frequency as the initial DL BWP in which the RedCap UE is expected to monitor for Type 12 PDCCH CSS candidates for monitoring as part of the random access procedure. China Telecom In our understanding, we support the center frequencies for initial UL/DL BWPs can be different in TDD at least during initial access. To achieve center frequencies alignment and offloading purpose, the initial DL BWP does not always contain CORESET #0 and SSB. DOCOMO Y Option 1 We think RAN1 needs to further discuss which scenarios/configurations Option 1 is applicable to, such as Shared initial DL/UL BWPs Shared initial DL BWP and separate initial UL BWP Separate initial DL/UL BWPs FUTUREWEI Y Opt. 2 is aligned with a separate initial DL BWP for initial access. CMCC N We also think both can be supported. Support option 1 can ensure SSB and CORESET#0 in initial DL BWP, but it cannot support downlink offloading. gNB can decide whether to configure a separate initial DL BWP different than CORESET#0 according to the resource utilization. NEC We prefer to discuss separately whether different center frequency of initial DL/UL BWP during initial access is supported in TDD. LGE N During initial access, we prefer the center frequencies for initial UL/DL BWPs to be the same, and the initial DL BWP needs to contain the SSB. Samsung We are fine to list separate option includes during initial access, CORESET 0 is used as initial DL BWP (as proposed by Nordic), with clarification on the initial DL BWP is SIB-configured. MediaTek N Option-1 will require re-tuning between UL and DL. Option-2 doesn＊t clarify if there is CSS in the separate DL BWP that can be used for initial access. We can accept Option-2 with the following modification: CSS Type 1 need to be configured in the DL iBWP NCD-SSB need be present in the DL BWP FL2 Based on the received responses to Proposal 3.1-5 and Question 3.1-3, the following updated proposal can be considered. High Priority Proposal 3.1-5a: Regarding the initial UL/DL BWPs center frequencies in TDD during random access, can the following options be considered for down selection? If yes, please indicate your preferred option(s). If no, please elaborate in the Comments field. Option 1: The center frequencies are NOT necessarily aligned for the initial UL BWP where the RedCap UE transmits PRACH and the initial DL BWP where the RedCap UE monitors RA CSS. Option 2: The center frequencies are always aligned for the initial UL BWP where the RedCap UE transmits PRACH and the initial DL BWP where the RedCap UE monitors RA CSS. vivo We prefer option 2, but can accept option 1 for initial access procedure, if it is supported by majority of companies. Nokia, NSB Y Option 1 Qualcomm We can accept Option 1 with additional condition on enabling early indication by msg1/msgA preamble Since center frequency change of DL/UL BWP requires RF retuning for both DL-to-UL switching and UL-to-DL switching, this is different from the DL/UL switching of Type-A HD-FDD. As a compromise, we can agree with Option 1 if RedCap UE is configured with separate PRACH resources to enable early indication by msg1/msgA PRACH. As a result, RedCap UE does not expect to monitor RAR(msg2) or get an invalid UL grant for msg3 before finishing the RF retuning for center frequency change of initial DL/UL BWP. Nordic Modified Option 2 This sub-bullet is the same as agreed in Rel 15 The center frequencies are always aligned for the initial UL BWP where the RedCap UE transmits PRACH and the initial DL BWP where the RedCap UE monitors RA CSS. MIB-CORESET#0 and initial UL BWP do not need to be aligned. Moreover, in our understanding irrespective of BWP Option 1 or Option 2 initial DL BWP is configured in SIB1. These fields are not optional. DownlinkConfigCommonSIB ::= SEQUENCE { frequencyInfoDL FrequencyInfoDL-SIB, initialDownlinkBWP BWP-DownlinkCommon, bcch-Config BCCH-Config, pcch-Config PCCH-Config, ... } BWP-DownlinkCommon ::= SEQUENCE { genericParameters BWP, pdcch-ConfigCommon SetupRelease { PDCCH-ConfigCommon } OPTIONAL, -- Need M pdsch-ConfigCommon SetupRelease { PDSCH-ConfigCommon } OPTIONAL, -- Need M ... } MediaTek Option-2 We don＊t support Option-1 as it will require re-tuning between UL and DL. Ericsson Y We prefer Option 1 With the support of separate center frequencies for initial UL/DL BWPs in TDD during initial access, many concerns regarding the PUSCH resource fragmentation and the presence of SSB and CORESET #0 within the initial DL BWP can be resolved. IDCC Y Option 1 We prefer Option 1 since it provides some advantages as mentioned by Ericsson. RF retuning during initial access is tolerable. Intel Y Option 1 Our first preference is Option 1. In general, we agree with QC that for Option 1, the UE should be accommodated with sufficient time for RF retuning between Msg1 Tx and Msg2 Rx, Msg2 Rx to Msg3 Tx, Msg3 Tx to Msg4 Rx, etc., and towards this, we should consult RAN4 on the assumptions on RF retuning time (which we expect to be within few OFDM symbols) between DL and UL. Lenovo, Motorola Mobility Y Option 1 FUTUREWEI2 Y Option 2 is preferred but also OK to discuss Option 1 as a possible compromise. NEC Y Either would be fine. One question for clarification. Does option 1 includes (or is equivalent to) the case MIB-configured CORESET#0 is used for RedCap UE during RA? DOCOMO Y Option 1 SSB transmissions In this section, expressed views on transmission of additional SSBs in a separate initial DL BWP (if configured) and RRC-configured DL BWP. Whether to transmit additional SSBs in a separate initial DL BWP for RedCap There are different views on whether an additional SSB is transmitted in the separate initial DL BWP for RedCap. Some contributions [4, 6, 11, 12, 14, 16, 32] argue that transmission of additional SSBs in a separate initial DL BWP for RedCap is not needed and can result in significant overhead and increased inter-cell interference. Some other contributions propose that additional SSB in the separate initial DL BWP should be transmitted [13, 15, 17, 20, 24]. Moreover, several contributions indicate that transmission of additional SSB depends on the scenario considering CSSs (random access or paging), initial UL/DL BWP centre frequencies in TDD, DRX cycle, and SSB periodicity [6, 7, 8, 9, 18, 22, 23, 25, 26]. In particular, a few contributions propose that additional SSB transmission is not needed when the separate initial DL BWP does not contain paging CSS [6, 7, 9, 18, 22, 25, 26]. [4]: Non-cell defining SSB as additional SSB would cause system performance degradation and significant implementation complexity to network, while does not ensure UE measurement performance. [6]: Whether the network configures an additional SSB to be transmitted in the separate initial DL BWP for RedCap should be based on the SSB monitoring periodicity (i.e., SMTC configuration) and the DRX cycle. [6]: If the separate initial DL BWP is only configured for random access, then the UE does not expect SSB transmission in the separate initial DL BWP. In this case, the network may or may not configure an SSB in the separate initial DL BWP for RedCap. [6]: By supporting different center frequencies for initial UL/DL BWPs for RedCap in TDD during initial access, the initial DL BWP can always contain CORESET#0 and SSB while minimizing the PUSCH resource fragmentation. [8]: The periodicity for additional non-CD SSB is configurable and up to 160ms, which is controlled by the network to reduce the overhead. [12]: The separately configured initial DL BWP for RedCap UEs does not need to contain SSB. [13]: For RedCap UE in RRC idle/inactive, whether the UE can expect SSB transmission in the separate initial DL BWP depends the measurement accuracy of SSB outside of separate initial DL BWP. [14]: The separate initial DL BWP under BWP#0 configuration option 2 should include SSB and CORESET#0. [16]: SSB is not transmitted in separate initial DL BWP if the separate initial DL BWP does not contain CORESET #0. [18]: A UE may NOT expect SSB to be always configured within the separate initial DL BWP if the separate initial DL BWP is only configured with PDCCH CSS Type 1 mapped to CORESET #0A. [20]: RedCap UE may always expect either CD-SSB in MIB-configured initial DL BWP or non-CD-SSB within the initial DL BWP for RedCap UE [26]: For a separate initial DL BWP configured with Type-1 CSS without paging monitoring, SSB may not be configured for the separate initial BWP. [26]: For a separate initial DL BWP configured with paging monitoring, a Redcap UE in RRC_IDLE/INACTIVE state expects SSB transmission in the separate initial BWP if the UE monitors for paging on it. [32]: There is no/negligible impact on UE complexity and battery life due to UE RF retuning to measure on CD-SSB. Also, transmitting additional SSBs would have significant impact on system complexity, network planning, network energy savings, network capacity, inter-cell DL interference, UE data experience, and specifications. FL1 High Priority Proposal 3.2-1: Regarding SSB transmission in a separate initial DL BWP for RedCap in idle/inactive mode: If the separate initial DL BWP is only configured for random access but not for paging, then the UE shall not expect SSB transmission in the separate initial DL BWP. Note: The network may or may not configure SSB in this case. FFS: SSB presence when the separate initial DL BWP is configured for paging Company Y/N Comments Qualcomm N Even if the separate initial DL BWP is configured for random access of RedCap UE, idle/inactive RedCap UE should get notification of SI update and ETWS by paging. When paging CSS is configured for idle/inactive UE in the separate initial DL BWP, SSB should be transmitted in the same DL BWP. Vivo We think this proposal should be address together with Proposal 3.2-3 and Question 3.3-1 as a package for compromise, it would be hard trying to agree it alone. OPPO Y For RAR reception ,there can be no SSB in this separate initial DL BWP. Nordic N Depends on whether BWP is meant for camping or not. If BWP contains paging, OSI, SIB1 -> SSB is guaranteed. Huawei, HiSilicon Y ZTE, Sanechips Y If the separate initial DL BWP is only configured for random access, the network may not configure SSB in the separate initial DL BWP. As with Rel-15/16 UEs, it is possible that the initial DL BWP does not contain SSB, especially for frequency-division multiplexing patterns 2 and 3 in FR2. Besides, RedCap UEs can switch to the MIB-configured initial DL BWP by RF retuning when needed to receive the legacy SSB. For the ＆Note＊, it seems to indicate that the additional SSB can be configured by the gNB. It is more appropriate to say ※The network can configure the separate initial DL BWP containing SSB or not in this case.§ Panasonic Y Sharp Y Lenovo, Motorola Mobility Y Spreadtrum We are open for SSB presence or not during RACH procedure, if it is helpful for progress. CATT Y The UE shall not expect SSB transmission in the separate initial DL BWP, no matter it is configured for random access and/or paging. Nokia, NSB Y Ericsson Y Intel Y China Telecom Y DOCOMO Y FUTUREWEI Y CMCC Y NEC FFS Maybe OK but we would like to clarify a point. Does this imply that in this case RedCap UE monitors SI and paging on MIB-configured CORESET#0 in IDLE/INACTIVE and accesses a separate initial DL BWP only for RA? This would depends on outcome of Proposal 3.1-4 LGE N When the separate initial DL BWP is configured for paging, then SSB shall be transmitted in the separate initial DL BWP. Apple This should be packed together with others, Question 3.2-2. Samsung We＊d like to clarify the meaning of the following note: i. Note: The network may or may not configure SSB in this case. Interpretation #1: Only for the case that the separate initial DL BWP contains CORESET #0, it ※configure§ SSB, which is the CD-SSB. Interpretation #2: network may configure SSB in connected mode. But UE in idle/inactive mode cannot read it. Interpretation #3: UE can work when there is no SSB configure and transmit in the separate iDL BWP. However, the specific supports the configuration of SSB in idle/inactive mode, e.g., in SIB. We cannot agree Interpretation #3. If the intention is for Interpretation #1, we want to update the Note to Note: The network may configure transmit SSB in this case, i.e., when the separate initial DL BWP contains the CD-SSB frequency range. Or replace it with Note: The network may configure MIB-configured CORESET#0 or SIB1 to be within the separate initial DL BWP. In addition, we want to modified the main bullet as At least for the case that If the separate initial DL BWP is only configured for random access but not for paging, then the UE shall not expect SSB transmission in the separate initial DL BWP. Moreover, we like to delete the last FFS on SSB presence for paging. Because we need to discuss whether paging on separate iDL BWP is supported or note first. We support paging in the separate iDL BWP, but we cannot live with SSB in the spate iDL BWP. Alternatively, it can be changed to FFS: whether/how paging can be configured in the separate initial DL BWP. FL2 See Proposal 3.2-4. FL1 High Priority Question 3.2-2: Regarding SSB transmission in a separate initial DL BWP for RedCap in idle/inactive mode: If the separate initial DL BWP is configured for paging, should the UE always be able to expect SSB transmission in the separate initial DL BWP? Company Y/N Comments Qualcomm Y SSB transmission is essential in the DL BWP configured with paging CSS vivo Y If SSB transmission is not available in the initial DL BWP where UE monitors paging, paging detection performance may be degraded and UE power consumption will be increased. From decoding performance perspective, as discussed in UE power saving WI, at least one SSB prior to each paging occasion in the high SINR case, and two or three SSB in some low SINR case are required for UE IDLE mode loop convergence / time-frequency tracking. From power consumption perspective, according to TR 38.840, the slot-average power level is 50 power units for BWP switching, additional power consumption per paging cycle caused by two times BWP switching to receive SSB and paging is at least (50 power unit) * (3 slot) * (2 times of BWP switching) = 300 power units for Type 2 BWP switching delay, which is much higher than the power used for receiving PDCCH + PDSCH of 120 power unit with 20MHz BW. In addition, the extra 300 power unit is the lower bound of the additional power consumption assuming no additional waiting time for SSB or paging PDCCH reception after the BWP switching. OPPO Y Agree with vivo＊s analysis. Paging in this separate initial DL BWP is for offloading. If there is no SSB transmitted in this separate initial DL BWP, paging will be monitored in the legacy MIB-configured initial DL BWP. Nordic Y Huawei, HiSilicon N but From gNB point of view, there is no fundamental difference for SSB reception prior to RAR or paging. The need for UE to perform SSB measurement during initial access for paging reception would not be frequent. For a UE being able to receive RAR without SSB, it is equivalent for UE to receive paging without SSB on the same BWP. From UE point of view, (see R1-2108753 and R1-2109752) the BWP with or without SSB differs from whether SSB is simultaneously processed with data within the same BWP - thus, operation without SSB is actually less complexity. Without SSB, UE perform RF retuning for SSB measurement. This is mandatory supported by measurement gap in R15. So no complexity aspect is concerned. Power consumption could be different however the impact is negligible (around 1%), based on the methodology in TR 38.840 and 50 power units for BWP switching. Thus, we don＊t see significant issue for UE not expecting SSB in this case either. However, as also said from last meeting, we are ok to compromise in this case that there is network restriction for gNB to configure related DRX/paging/measurement configurations, such that a UE is not required to measure SSB to an extent that they consider will have non-trivial impact on their devices implementations. ZTE, Sanechips N The transmission of legacy SSB in the separate initial DL BWP for RedCap UEs is up to gNB configuration. From the UE perspective, the UE shall not always expect SSB transmission in the separate initial DL BWP. For example, in TDD, to reduce the PUSCH resource fragmentation, for the case that the SSB is located on the edge of the system bandwidth, gNB can configure the separate initial DL BWP containing the legacy SSB; If SSB is located near to the center of the system bandwidth, gNB can configure no SSB in the separate initial DL BWP and the RedCap UE can retune to the MIB-configured initial DL BWP for the reception of legacy SSB. Xiaomi Y If there is no SSB in the separate initial DL BWP, RedCap will comp on the MIB-configured initial DL BWP Panasonic Y Sharp Y NCD-SSB should be transmitted in the separate initial DL BWP if the paging CSS in the separate initial DL BWP is configured for offloading purpose. Lenovo, Motorola Mobility It depends on if the measurement accuracy of SSB outside of separate initial DL BWP is accurate enough. Spreadtrum Y It is up to gNB implementation whether to configure paging CSS in the separate initial DL BWP. CATT N Nokia, NSB Our preference is also that SSB is not required for BWP used for paging, as we don＊t see strong need for the SSB in this case. However, we are fine to support the compromise from the last meeting where SSB is required for paging but not random access. Ericsson N If the separate initial DL BWP is also configured for paging, SSB is contained in the separate initial DL BWP depending on the configuration of the DRX cycle and SMTC periodicity. For example, if the periodicity of the DRX cycle is long, there is sufficient time and flexibility to acquire the legacy/CD-SSB located outside of its initial DL BWP. Also, in this case, there wouldn＊t be much impact to the UE power consumption (if at all). Therefore, depending on the SSB monitoring periodicity and the DRX cycle, additional SSBs are not required to be transmitted in the separate initial DL BWP for RedCap. The exact configuration of the DRX cycle and SMTC periodicity for which SSB shall/may not be present in the separate initial DL BWP can be decided in RAN4. We also suggest treating FR1 and FR2 cases separately. Intel Can accept While we don＊t think it may be strictly necessary, it can help UE power consumption reduction such that the UE can camp on the separate initial DL BWP when paging is configured in the separate initial DL BWP. In such a case, having (NCD) SSB in the separate initial DL BWP can be beneficial for UE to wake up periodically, perform sync and measurements, and monitor for potential paging. China Telecom N For paging, we think there is no need for UE to always expect SSB transmission in the separate initial DL BWP. DOCOMO Y FUTUREWEI Y CMCC N Share similar view with ZTE. If paging CSS is configured on separate initial DL BWP, UE can switch to CD-SSB before paging PDCCH for sync. NEC FFS Does this imply that in this case RedCap UE always camps on a separate initial DL BWP after cell search and RRM measurement is also performed on the separate initial DL BWP? In cell reselection, which SSB is used, namely CD-SSB or SSB on a separate initial DL BWP of neighboring cell? This would depends on outcome of Proposal 3.1-4 LGE Y We see there are power consumption and performance issues without the SSBs in the separate initial DL BWP for paging. Apple Y Samsung N As analyzed in some papers, power consumption is not an issue. We don＊t think there is any issue for UE to get time/freq tracking in CD-SSB outside of separate BWP and retune to the separate DL BWP for paging receiving. Otherwise, current BWP switching in NR cannot work (If UE requires time/frequency tracking in the same BWP with SSB). In addition, as pointed out in our paper, transmit/configure another SSB will cause huge impact on RAN 2, and may or may not feasible. Also, Idle mode TRS resources supported in Rel-17 PS can be used for synchronization/AGC for paging in the separate initial DL BWP. MediaTek Y FL2 See Proposal 3.2-4. Whether to transmit additional SSBs in an RRC-configured DL BWP for RedCap For RRC-configured DL BWP (e.g., non-initial BWP), the contributions generally agree that transmission of additional SSBs depends on the UE capability [4, 6, 13, 23, 28, 29, 30]. Specifically, for RedCap UEs supporting FG 6-1a, the network may or may not transmit additional SSBs in an RRC-configured active DL BWP, while additional SSB is transmitted for UEs with only basic FG 6-1 capability. [6]: For RedCap UEs supporting FG 6-1a, the network may or may not transmit additional SSBs in an RRC-configured active DL BWP. [10]: If SSB is always required in any active BWP of a RedCap UE in RRC_CONNECTED state, the SSB issue will be a disaster to the network. [11]: To balance UE power saving and network overhead, the following alternatives can be considered: RedCap UEs support FG 6-1a, no additional SSB is configured, RedCap UEs rely on CSI-RS/TRS for RRM and sync. RedCap UEs support FG 6-1, the active DL BWPs overlap with CD-SSB, and the center frequency of DL BWP and UL BWP can be unaligned. RedCap UEs support FG 6-1, while the SSB for RRM/sync can be non-CD SSB with large periodicity. [14]: The measurement gap/TRS/CSI-RS can be considered to accommodate SSB reception and CORESET#0 monitoring in a scenario where SSB and CORESET#0 is not transmitted within the UE BW. [28]: If a RedCap UE operates in an RRC-configured DL BWP without SSB, it expects to receive periodic TRS/CSI-RS in the SSB-less BWP. [29]: Support offloading from MIB-CORESET#0/CD-SSB, if at least in RRC connected mode and in RedCap UE＊s active BWP, a RedCap UE with baseline capability may expect gNB to transmit an SSB within the active BWP. FL1 High Priority Proposal 3.2-3: Whether the UE can expect SSB transmission in the RRC-configured active DL BWP depends on its UE capabilities (e.g., whether it supports FG 6-1a or only FG 6-1). A UE not supporting operation without SSB transmission in the RRC-configured active DL BWP may expect SSB transmission in the RRC-configured active DL BWP. FFS: details of SSB configuration (e.g., cell-defining SSB, non-cell-defining SSB, SSB periodicity) A UE supporting operation without SSB transmission in the RRC-configured active DL BWP shall not expect SSB transmission in the RRC-configured active DL BWP. FFS: RedCap UE capability for BWP operation Only FG 6-1, FG 6-1a, or any new FG suitable for RedCap Company Y/N Comments Qualcomm N A UE not supporting operation without SSB transmission in the RRC-configured active DL BWP may expect SSB transmission in the RRC-configured active DL BWP. FG 6-1 is mandatory for RedCap UE in FR1 FG 6-1a is optional for RedCap UE in FR1 vivo N The current formulation is not agreeable. We suggest the following update. Modified Proposal 3.2-3: Whether the UE can expect SSB transmission in the RRC-configured active DL BWP depends on its UE capabilities (e.g., whether it supports FG 6-1a or only FG 6-1). A UE not supporting operation without SSB transmission in the RRC-configured active DL BWP may expect SSB transmission in the RRC-configured active DL BWP. This corresponds to mandatory RedCap UE feature. FFS: details of SSB configuration (e.g., cell-defining SSB, non-cell-defining SSB, SSB periodicity) A UE supporting operation without SSB transmission in the RRC-configured active DL BWP shall not expect SSB transmission in the RRC-configured active DL BWP. This corresponds to optional RedCap UE feature. FFS: RedCap UE capability details for BWP operation Only FG 6-1, FG 6-1a, or any new FG suitable for RedCap OPPO Agree with vivo＊s revision. Nordic N VIVO wording is OK, plus typo ※expects§ Huawei, HiSilicon N We want to note that existing FG6-1 alone will not hold anymore anyway, if we agree to support a separate initial DL BWP without CORESET#0. We want to also clarify that the existing FG6-1a only concerns UE specific RRC configured BWP. In that sense, our understanding is that the current proposal concerns more about the UE specific configurations to specific UEs. A BWP configured from SIB and applied after initial access may be assumed without SSB, i.e. irrelevant to the FG6-1a. We are ok with the following Modified Proposal 3.2-3: Whether the UE can expect SSB transmission in the RRC-configured active DL BWP depends on its UE capabilities (e.g., whether it supports FG 6-1a or only FG 6-1). A UE not supporting operation without SSB transmission in the RRC-configured active DL BWP may expect SSB or CSI-RS transmission in the RRC-configured active DL BWP. FFS: details of SSB or CSI-RS configuration (e.g., cell-defining SSB, non-cell-defining SSB, SSB periodicity) A UE supporting operation without SSB transmission in the RRC-configured active DL BWP shall not expect SSB transmission in the RRC-configured active DL BWP. FFS: RedCap UE capability for BWP operation Only FG 6-1, FG 6-1a, or any new FG suitable for RedCap ZTE, Sanechips Y We are generally fine with the proposal. For the FFS in the first bullet, we may need to determine whether we should reuse the legacy SSB (including CD SSB and NCD SSB) firstly or just define a new SSB. Therefore, the following modification is suggested. FFS: details of SSB transmission in the RRC-configured active DL BWP (e.g., legacy SSB, new-defined SSB) Xiaomi We support vivo＊s version Panasonic N We are not so sure whether the proposal is to allow a RedCap UE supporting operation without SSB transmission in the RRC-configured active DL or it discuss to clarify the possibility of RedCap UE capability and SSB transmission handling. Our view is "a RedCap UE not supporting operation without SSB transmission in the RRC-configured active DL BWP" should not be allowed in the specification. Lenovo, Motorola Mobility This depends on if FG6-1a is mandatory for RedCap UEs or not. If FG6-1a is mandatory, seems the first bullet is not needed. Spreadtrum We support vivo＊s version. CATT Huawei＊s suggestion is OK for us. Nokia, NSB Y Ericsson N We support Huawei＊s revision. Intel Y, but ＃ We also agree with and would like to second the observation from Huawei that FG 6-1 and 6-1a would not apply directly, since CORESET #0 should not be coupled with this capability on SSB for RedCap UEs. China Telecom N We are fine with Huawei＊s suggestion. DOCOMO Y CMCC Fine with HuaWei＊s suggestion. NEC Y ※may§ will be fine for us. ※may§ allows UE whether it actually expects SSB or not. LGE We are fine with the FL proposal in general. Regarding the discussion on the mandatory/optional support of the BWP-related FGs, we think the FG 6-1 should be mandatory and the FG 6-1a is optional. Apple Support Vivo modification. We also share view that a new UE feature capability is needed to focus on SSB only without CORESET#0. We think this proposal should be discussed at first. Samsung For this proposal, we don＊t think new signaling of SSB configuration is needed. Current system has UEs support or not support FG6-1a. Therefore, we suggest to delete FFS: details of SSB configuration (e.g., cell-defining SSB, non-cell-defining SSB, SSB periodicity) In addition, we like to clarify the second bullet on the meaning of ※shall not expect§. Does this mean UE support operation without SSB can operate on a BWP with SSB transmission as well? If so, we suggest to change to ※does not§ other than ※shall not§. MediaTek N We are fine with vivo＊s update. FL2 See Proposal 3.2-4. Based on the received responses to Questions 3.2-1, 3.2-2, 3.2-3, 3.3-1 and 3.3-2, the following proposal can be considered. The responses received so far for Question 3.3-1, which concerns whether to make FG 6-1a mandatory for RedCap UEs, were split roughly 50/50. FL2 High Priority Proposal 3.2-4: For FR1, select one of the following options: Option 1: For separate initial DL BWP, RedCap UE does NOT expect it to contain CD-SSB or NCD-SSB or CORESET#0/SIB1. For RRC-configured active DL BWP, RedCap UE does NOT expect it to contain CD-SSB or NCD-SSB or CSI-RS or CORESET#0/SIB1. Option 2: For separate initial DL BWP configured for random access but not for paging, RedCap UE does NOT expect it to contain CD-SSB or NCD-SSB or CORESET#0/SIB1. For separate initial DL BWP configured for paging, RedCap UE expects it to contain CD-SSB or NCD-SSB but not CORESET#0/SIB1. For RRC-configured active DL BWP, RedCap UE expects it to contain CD-SSB or NCD-SSB or CSI-RS but not CORESET#0/SIB1. FFS: Whether RedCap UE can/cannot expect SSB under certain conditions for SSB monitoring periodicity (i.e., SMTC configuration) and DRX cycle Whether it is feasible to use NCD-SSB for serving cell measurement and QCL source How SI update notifications and/or SI updates are signaled to RedCap UEs FR2 case Note: In all these cases, the network may choose to configure SSB or MIB-configured CORESET#0 or SIB1 to be within the respective DL BWP. Company Y/N Option Comments vivo Option 2 For the FFS part: The motivation of 1st bullet under FFS needs to be clarified For the 2nd bullet, we think it should be feasible, and FFS should be mainly on what additional spec effort is needed to make it work It is not clear why the SI update issue (3rd bullet) is highlighted here Qualcomm N For separate initial DL BWP, RedCap UE expects it to contain SSB (CD-SSB or NCD-SSB) and CORESET/CSS for RA and paging For RRC-configured active DL BWP, RedCap UE with baseline capabilities expects it to contain SSB and CORESET/CSS for paging Nordic Option 2 Regarding NCD-SSB, we do not understand why it should not be feasible. NCD-SSB would provide the same burst as CD-SSB. Contains PSS and SSS. NCD-SSB MIB indicates that no SIB1 is broadcast. System update can be provided in dedicated manner, or if SIB1/ OSI SS is provided for RedCap UEs then broadcast can be used. MediaTek N The SSB and the CSS/CORESET for random access should be configured in the separate initial DL BWP. Ericsson Y We prefer Option 1. We can accept Option 2 as a compromise. We also propose to add cell selection/reselection in the 2nd bullet under FFS. As per TS 38.300, cell selection/reselection is always based on CD-SSB. @Vivo: Regarding 1st bullet under FFS, we copy our response from an earlier question below. If the separate initial DL BWP is also configured for paging, SSB is contained in the separate initial DL BWP depending on the configuration of the DRX cycle and SMTC periodicity. For example, if the periodicity of the DRX cycle is long, there is sufficient time and flexibility to acquire the legacy/CD-SSB located outside of its initial DL BWP. Also, in this case, there wouldn＊t be much impact to the UE power consumption (if at all). Therefore, depending on the SSB monitoring periodicity and the DRX cycle, additional SSBs are not required to be transmitted in the separate initial DL BWP for RedCap. The exact configuration of the DRX cycle and SMTC periodicity for which SSB shall/may not be present in the separate initial DL BWP can be decided in RAN4. IDCC Y Option 2 Agree with Nordic on the SI update comments. Intel Y Option 1 is preferred We can also accept Option 2 as a compromise. Agree with Nordic on mechanisms for SI update/delivery to RedCap UEs in connected mode. For UEs in idle/inactive modes, if separate initial DL BWP does not include CSS Types 0/0A, UE can rely on retuning to CORESET #0 in case it may need to reacquire any SI message. We do not see any issues with that for RRC_Idle/Inactive modes. FUTUREWEI2 Of these two options, prefer Option 2. Some clarifications on the FFS may be needed. NEC We would like to clarify whether this will invalidate Rel-15 specification ※Even though this field is only configured in the initial BWP (BWP#0) controlResourceSetZero can be used in search spaces configured in other DL BWP(s) than the initial DL BWP if the conditions defined in TS 38.213 [13], clause 10 are satisfied.§ [TS 38.331] Preference would be option 2 but the first bullet would depend on High Priority Proposal 3.1-5a We agree with Ericsson to add cell selection/reselection to FFS. DOCOMO We are fine with either option Some of the received responses to Question 3.4-1 mention that NCD-SSB may currently not be applicable for serving-cell measurements and as QCL source. FL2 High Priority Question 3.2-5: Is it feasible to use NCD-SSB (rather than CD-SSB) in Options 1 and 2 (in Proposal 3.2-4)? Please elaborate on your answer in the Comments field. Company Y/N Comments vivo Y Although it is true that by current specification, UE always use CD-SSB for serving cell measurement and QCL source. However, there is no feasibility issue to use NCD-SSB within the UE DL BWP for the purposes. Qualcomm Y Both NCD-SSB and CD-SSB can be used for RRM/RLM/LR, tracking loops and AGC setting. Compared with periodic CSI-RS/TRS, the overhead and NW cost to transmit NCD-SSB are smaller in most cases. To improve the energy/spectral efficiency of NW, NCD-SSB can be transmitted on-demand to RedCap UE based on request sent on msg1 (shown by the illustration below) Nordic Y Regarding NCD-SSB, we do not understand why it should not be feasible. NCD-SSB would provide the same burst as CD-SSB. Contains PSS and SSS. NCD-SSB MIB indicates that no SIB1 is broadcast. NCD-SSB may not be on synch raster. In our understanding, NCD-SSB is e.g. the SSB of Scell, and is QCL source and is used for RRM measurements Ericsson FFS The following aspects should be studied further: Whether it is feasible to use NCD-SSB for serving cell measurement and QCL source. The PCIs of CD-SSB and NCD-SSB need not be the same [TS 38.300] Cell selection/reselection in RRC_IDLE is always based on CD-SSBs [TS 38.300] Required RAN1/RAN2/RAN4 workload, if any. Intel Y In general, we think it should be feasible to support to use NCD-SSB for RRM purposes. It is acknowledged that today, we do not support serving cell measurements and cell selection/reselection in RRC_Idle based on NCD-SSB or as QCL source, but such can be defined by RAN2/RAN4. We do not see a fundamental issue as pointed out by Nordic/QC. NEC FFS Agree with Ericsson. DOCOMO Regarding serving cell measurement, we can send an LS to RAN2/RAN4 to ask the feasibility. Non-initial DL BWP operation RAN1#105-e made the following agreement related to non-initial BWP operation: Agreements: Take the following as an agreement, revised from the RAN1#104bis-e working assumption: A RedCap UE cannot be configured with a non-initial (DL or UL) BWP (i.e., a BWP with a non-zero index) wider than the maximum bandwidth of the RedCap UE. At least for FR1, FG 6-1 (※Basic BWP operation with restriction§ as described in TR 38.822) is used as a starting point for the mandatory RedCap UE type capability. This does not preclude support of FG 6-1a (※BWP operation without restriction on BW of BWP(s)§ as described in TR 38.822) as a UE capability for RedCap UEs. Several contributions provide their views on non-initial BWP operation and in particular FG 6-1a ※BWP operation without restriction on BW of BWPs§. In some of the contributions, it is proposed to make FG 6-1a mandatory for RedCap [4, 6, 10, 11, 12, 14, 27]. As discussed in these contributions, FG 6-1a is beneficial in three aspects: 1) for multiplexing of SSB/CORESET#0 that are beyond the UE maximum bandwidth, 2) to be able to place the UL BWP at the band edge in TDD where CORESET#0 may not be present, and 3) to reduce the overhead of requiring BWP to contain SSB. In some other contributions, it is proposed to have FG 6-1a as an optional feature for RedCap [24, 28, 29, 30]. Meanwhile, a few contributions propose to have new or modified FGs for RedCap [6, 7, 18, 26]. [6]: The RedCap UE should support FG 6-1a or at least its special case where an RRC-configured DL BWP contains SSB but not CORESET #0. [7]: Define new capabilities like FG 6-1/6-1a/6-2/6-3/6-4 to consider SSB and CORESET of CSS presence in the UE-specific DL BWP. [18]: FGs #6-1 and 6-1a (at least FGs #6-1) should be adapted for RedCap UEs such that RedCap UEs mandatorily support operation in active DL BWPs that may not necessarily include CORESET #0. [26]: Introducing a new UE feature for Redcap to indicate whether it supports an active BWP configured with UE-specific search space (USS) without SSB, denoting as Feature-X A UE not supporting Feature-X expects SSB transmission in the active DL BWP configured with USS. [28]: If RedCap UE supports FG 6-1a and operates in a RRC-configured DL BWP without SSB, it expects to receive: periodic TRS for time/frequency tracking dedicated RRC signalling for SI update dedicated BFR-CSIRS-RACH resource, if BFR-CSI-RS is configured in the active BWP [28]: If RedCap UE supports FG 6-1a and operates in an active DL BWP with SSB but without CORESET#0 (or CSS for RMSI/OSI), it expects to receive: periodic TRS for time/frequency tracking CORESET/CSS for paging, or dedicated RRC signalling for SI update if paging CSS is not configured dedicated BFR-CSIRS-RACH resource, if BFR-CSI-RS is configured in the active BWP [32]: Non-initial DL BWP can be configured for RedCap UEs in a location which does not contain CD-SSB and MIB-configured CORESET#0. FL1 High Priority Question 3.3-1: Should RedCap UEs support FG 6-1a as a mandatory feature? If yes, if some additional features or signaling need to be supported to facilitate this, please elaborate in the Comments field. Company Y/N Comments Qualcomm N Supporting FG 6-1a as mandatory feature is against the principle of UE complexity reduction for R17 RedCap WI vivo N ※supporting operation without SSB transmission in the RRC-configured active DL BWP§ shall be optional for RedCap UEs. OPPO N Supporting FG 6-1a as mandatory feature is against the principle of UE complexity reduction for R17 RedCap WI. Nordic N Huawei, HiSilicon Y There is no evident analysis why FG6-1a increases UE cost. There could be minor impact on UE power consumption however given the analysis in R1-2109752 we think that is negligible. Even with that, towards a balance we can compromise as proposed in Proposal 3.2-3. Preferably, the existing FG 6-1a can be mandatory for RedCap, or can be modified to address some concerns for mandating it, e.g. Adding CSI-RS for UE to expect, if a UE does not support BWP without SSB only, or Adding network configuration restriction in order to not mandating UE to retune too frequent, if companies can accept FG 6-1a as mandatory together with this restriction ZTE, Sanechips Y The separate initial DL BWP becomes UE-specific RRC configured under BWP#0 configuration option 2. In this case, if separate initial DL BWP without SSB or CORESET0 is configured, the RRC configured BWP without SSB or CORESET0 is also supported. Specifically, for traffic offloading and TDD center frequency alignment purposes, both the separate initial DL BWP and other UE-specific RRC configured non-initial BWPs do not necessarily contain CORESET#0. Furthermore, mandatory FG 6-1a allows frequency-domain locations of UE-specific RRC configured BWPs not to be restricted by SSB/CORESET#0, which helps to mitigate the PUSCH resource fragmentation problem. Therefore, we believe that RedCap UEs should support FG 6-1a as a mandatory feature if separate initial DL BWP without SSB can be configured. Consequently, FG 6-1 is not needed. Xiaomi N Panasonic Y Lenovo, Motorola Mobility Y We can accept FG6-1a is mandatory for RedCap UEs, since a separate initial DL BWP (if configured in cell edge) might not contain MIB-configured CORESET#0 already. Spreadtrum N CATT Y A modified FG 6-1a can be used, in which the RedCap UE shall be able to operate in an active initial DL BWP without SSB only (removing CORESET#0) Nokia, NSB Y Ericsson See comment The RedCap UE should support FG 6-1a or at least its special case where an RRC-configured DL BWP contains SSB but not CORESET #0. Intel See comment As mentioned in the response to the previous Question (Proposal 3.2-3), RedCap UE should at least mandatorily support operation wherein active DL BWP has SSB but does NOT include CORESET #0. China Telecom Y In our understanding, RedCap UEs can support FG 6-1a as a mandatory feature. Some RedCap-specific revisions on FG 6-1a can be made to clarify the details on the separate BWP configured/defined for RedCap UEs. DOCOMO This question can be discussed after some progress is made in Proposal 3.2-3 FUTUREWEI Y CMCC Y Since the active BWP may not contain CORESET#0, FG6-1 does not hold. Or a new FG that UE expect CSI-RS or NCD-SSB configurable by gNB. LGE N Same comment with QC and vivo. Apple N Samsung Y But we can be open to some other compromise proposal, e.g., if either SSB or CSI-RS. MediaTek N FL2 See Proposal 3.2-4. FL1 High Priority Question 3.3-2: Should any new or modified FG be defined for RedCap BWP operation (e.g., RRC-configured DL BWP contains an SSB, but it does not contain CORESET #0)? Company Y/N Comments Qualcomm FFS vivo We prefer to introduce new FGs for RedCap UEs, e.g. one new FG for 6-1 like operation (but not necessarily contain MIB-configured CORESET#0), another new FG for 6-1a like operation. OPPO Y This is new FG May be named as 6-1＆ It can be ※supporting operation with SSB transmission but not necessarily contain MIB-configured CORESET#0§ Nordic If offloading from CORESET#0 is supported, then 6-1 must be updated, but no change to SSB part of 6-1 ZTE, Sanechips It depends on the discussion of other issues. If 6-1a is mandatory, then no any new or modified FG need to be defined. If 6-1a is optional, whether new or modified FG is needed depends on the other issues discussion, e.g., SSB presence and CORESET0 configuration in separate initial DL BWP. Spreadtrum Y Ericsson See comment The RedCap UE should support FG 6-1a or at least its special case where an RRC-configured DL BWP contains SSB but not CORESET #0. Intel Y FGs 6-1 and 6-1a should be adapted/updated for RedCap such that they only consider expectation on SSB in RRC-configured active DL BWP, but not necessarily presence of CORESET #0. China Telecom Y Some RedCap-specific revisions on FG 6-1a or FG 6-1 can be made to clarify the details on the separate BWP configured/defined for RedCap UEs. And we are open to introduce new FG for RedCap UEs if indeed necessary. DOCOMO This question can be discussed after some progress is made in Proposal 3.2-3 CMCC Y Share the same view as ZTE. Our first preference is to mandatory support FG6-1a. The overhead can be high if SSB is always transmitted on active DL BWP of connected UEs, when such BWPs are not overlapped for offloading. For compromise, when A UE does not support operation without SSB transmission in the RRC-configured active DL BWP, the SSB it expects can be NCD-SSB with larger periodicity. LGE Not sure if it is needed. Can come back to this after the conclusion on the support of the existing FGs (6-1 and 6-1a). Apple Y Samsung Needs further clarification. Does this SSB means the CD-SSB or non-CD SSB for serving cell? FL2 See Proposal 3.2-4. RF retuning and BWP switching In RAN1#105-e, no consensus could be reached regarding whether an LS should be sent to RAN4 for their input on RF switching time. Many aspects related to BWP switching for UL and/or DL BWPs, as well as for initial and/or non-initial BWPs are already accounted for in the previous sections. For example, issues related to initial UL/DL BWP center frequency in TDD, and issues related to SSB or CORESET #0 potentially not being transmitted in initial/non-initial BWP for RedCap. Depending on the outcome of previous sections on initial UL/DL BWPs, RF retuning and/or BWP switching aspects may need to be discussed. Also, one contribution proposes that RRC configuration based, DCI-based and timer-based BWP switching are supported by RedCap UEs [31]. FL1 High Priority Question 3.4-1: Is there a need to send an LS to RAN4 to ask for input on RF retuning and/or BWP switching? If yes, please elaborate in the Comments field. Company Y/N Comments Qualcomm FFS RF retuning/BWP switching faster than the timeline of non-RedCap UE should not be supported by R17 RedCap UE. Type-2 BWP switching delay is supported as a baseline capability for BWP switching of RedCap UE. Vivo Faster RF retuning and/or BWP switching is not essential features to finalize Rel-17 RedCap feature, therefore should not be pursued any further. If any communication with RAN4 is needed, we think RAN1 should make the assumption that existing BWP switching delay are reused for RedCap UEs and confirm such assumption with RAN4. OPPO Y Many issues related to BWP switching and RF retuning. For example, if there is no SSB in the separate initial DL BWP, the UE needs to get synchronization from the MIB-configured initial DL BWP. If there is no SSB in the active BWP, the UE may retune to the MIB-configured initial DL BWP for RRM measurement. Nordic N Huawei, HiSilicon Y FL has well described the issue/scenarios 每 similar comments as in [4]. There is no BWP switching during initial access in R15 and there is no baseline capability (one type is required to be reported in R15). Thus, this needs to be revisited for RedCap in order to support BWP operation with separate initial BWP. ZTE, Sanechips Y but The motivation of the LS is trying to ask RAN4 whether the legacy RF retuning and/or BWP switching can be reused, instead of any optimization of the switching time. TCL Y Same comments with Huawei Panasonic There would be no need to ask for input on RF retuning and/or BWP switching except RAN1 agree to reduce the delay on them. Spreadtrum N Nokia, NSB N Ericsson Y We support sending LS to RAN4 regarding: Applicability of NCD-SSB for carrying out RAN4 procedures (RRM/RLM/LR). To our understanding, currently NCD-SSB cannot be used for serving cell measurements or as QCL sources. RF switching delay in scenarios where SSB and/or CORESET#0 are not contained within the RedCap DL BWP. Intel Y, but ＃ We＊d be supportive of an LS to RAN4, but rather to inform them of our decisions. In our view, the time to ask for inputs from RAN4 to guide our design itself is past. Thus, we can inform them based on our decisions and RAN4 can provide feedback if they say any significant issues with RAN1 design. This includes consideration of using NCD-SSB for serving cell RRM. China Telecom Y It would be good to send LS to RAN4 to ask for input on RF retuning and/or BWP switching for the sake of RedCap WI progress. DOCOMO This question can be discussed after some progress is made in previous sections CMCC Y Since center frequency unalignment is on table for discussion, and BWP switching for SSB is also under discussion, a LS can be send to RAN4. LGE N From our perspective, there is no consensus to further pursue RedCap-specific fast RF retuning or BWP switching. And there has been no consensus on the content of the LS either. Samsung FFS We need to identify the use case first. E.g., if a UE support different center frequency. FL2 See Proposal 3.2-5. References [1] RP-211574 Revised WID on support of reduced capability NR devices Ericsson [2] R1-2108271 RAN1 agreements for Rel-17 NR RedCap Rapporteur (Ericsson) [3] R1-2108632 FL summary #7 on reduced maximum UE bandwidth for RedCap Moderator (Ericsson) [4] R1-2108753 Reduced maximum UE bandwidth Huawei, HiSilicon [5] R1-2108802 Further discussion on Bandwidth Reduction for RedCap UEs FUTUREWEI [6] R1-2108820 Reduced maximum UE bandwidth for RedCap Ericsson [7] R1-2108913 Discussion on aspects related to reduced maximum UE bandwidth Spreadtrum Communications [8] R1-2108981 Discussion on reduced maximum UE bandwidth vivo, Guangdong Genius [9] R1-2109082 Discussion on reduced UE bandwidth OPPO [10] R1-2109230 Discussion on reduced maximum UE bandwidth CATT [11] R1-2109287 Discussion on reduced maximum UE bandwidth CMCC [12] R1-2109310 Bandwidth Reduction for Reduced Capability Devices Nokia, Nokia Shanghai Bell [13] R1-2109326 Reduced maximum UE bandwidth for RedCap Lenovo, Motorola Mobility [14] R1-2109332 Bandwidth reduction for reduced capability NR devices ZTE, Sanechips [15] R1-2109417 Discussion on the remaining issues of reduced UE bandwidth for RedCap Xiaomi [16] R1-2109496 UE complexity reduction Samsung [17] R1-2109573 On reduced maximum bandwidth for RedCap UEs MediaTek Inc. [18] R1-2110481 (Inbox) Support of reduced max UE BW for RedCap (update of R1-2109617) Intel Corporation [19] R1-2109685 Discussion on reduced maximum UE bandwidth for RedCap NTT DOCOMO, INC. [20] R1-2109759 Discussion on reduced maximum UE bandwidth for RedCap NEC [21] R1-2109796 Discussion on reduced maximum UE bandwidth for RedCap Sony [22] R1-2109841 Aspects related to reduced maximum UE bandwidth for RedCap Panasonic Corporation [23] R1-2109948 Discussion on reduced maximum bandwidth for RedCap UEs InterDigital, Inc. [24] R1-2109975 Aspects related to the reduced maximum UE bandwidth of RedCap LG Electronics [25] R1-2109996 Discussion on reduced maximum UE bandwidth Sharp [26] R1-2110040 Reduced maximum UE bandwidth for Redcap Apple [27] R1-2110105 Discussion on aspects related to reduced maximum UE bandwidth ASUSTeK [28] R1-2110193 BW Reduction for RedCap UE Qualcomm Incorporated [29] R1-2110279 On aspects related to reduced maximum UE BW Nordic Semiconductor ASA [30] R1-2110314 Reduced maximum UE bandwidth for RedCap DENSO CORPORATION [31] R1-2109291 Discussion other aspects of RedCap UE CMCC [32] R1-2109752 On RedCap UE RF retuning Huawei, HiSilicon [33] R1-2109951 Considerations for RedCap initial BWP InterDigital, Inc.