3GPP TSG-RAN WG1 Meeting #108-e	Draft R1-2202529
e-Meeting, 21st February 每 3rd March 2022


Agenda Item:	8.6.1.1

Title:	FL summary #2 on reduced maximum UE bandwidth for RedCap

Source:	Moderator (Ericsson)

Document for:	Discussion, Decision

Introduction
This feature lead (FL) summary (FLS) concerns the Rel-17 work item (WI) for support of reduced capability (RedCap) NR devices [1]. Earlier RAN1 agreements for this WI are summarized in [2]. The final FLS for this agenda item from the previous RAN1 meeting can be found in [3].
This document summarizes contributions [4] 每 [27] submitted to agenda item 8.6.1.1 and relevant parts of contributions [28] 每 [35] submitted to other agenda items and captures this email discussion on reduced maximum UE bandwidth:
[108-e-R17-RedCap-01] Email discussion for maintenance on aspects related to reduced maximum UE bandwidth 每 Johan (Ericsson)
 1st check point: February 25
 Final check point: March 3

According to the latest WI status report, the following remaining details pertaining to reduced UE bandwidth are expected to be addressed during CR/maintenance phase in Q1 2022:
 Clarification of UE behavior when separate initial DL BWP is not configured
 Presence of SSB transmission in separate initial DL BWP in connected mode for BWP#0 configuration option 1
 Remaining details of common PUCCH resource determination
 If needed, address RAN2/RAN4 feedback on RAN1 working assumptions on DL BWP operation (see R1-2112802)

The issues in this document are tagged and color coded with High Priority or Medium Priority. The issues that are in the focus of this round of the discussion are furthermore tagged 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-2200852), otherwise the sorting of the files will be messed up (which can only be fixed by the RAN1 secretary).
To avoid excessive email load on the RAN1 email reflector, please note that there is NO need to send an info email to the reflector just to inform that you have uploaded a new version of this document. Companies are invited to enter the contact info in the table below.
FL2 Question 1-1a: Please consider entering contact info below for the points of contact for this email discussion.
Company
Point of contact
Email address
vivo
Xueming Pan
panxueming@vivo.com
Nordic 
Karol Schober
karol.schober@nordicsemi.no
Spreadtrum
Huayu Zhou
huayu.zhou@unisoc.com
FUTUREWEI
Vip Desai
vipul.desai@futurewei.com
Qualcomm
Jing Lei
leijing@qti.qualcomm.com
Intel
Debdeep Chatterjee
debdeep.chatterjee@intel.com
Ericsson
Sandeep Narayanan Kadan Veedu
sandeep.narayanan.kadan.veedu@ericsson.com
Nokia, NSB
Rapeepat Ratasuk
rapeepat.ratasuk@nokia-bell-labs.com
CATT
Yongqiang FEI
feiyongqiang@catt.cn

Separate initial DL BWP
One of the FFSs identified in RAN1#106-bis-e is whether the separate RedCap initial DL BWP is always configured if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth:
 For a cell that allows a RedCap UE to access, network can configure a separate initial DL BWP for RedCap UEs in SIB.
 FFS: It is always configured if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth.

Regarding the configuration of a separate initial DL BWP for RedCap when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, the contributions express different views. Few contributions [13, 16, 21, 22, 27] indicate that, considering the UE complexity and specification impacts, the separate initial DL BWP for RedCap should be always configured if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth. [13] points out that it needs to be carefully studied that whether to support that the RedCap UE can continue using the location/bandwidth/SCS of CORESET#0 for the initial DL BWP. Meanwhile, several contributions [6, 8, 9, 10, 18, 19, 23, 24, 26, 28] argue it is not necessary to always configure a separate initial DL BWP for RedCap. Specifically, if the separate initial DL BWP for RedCap UEs is not configured, then the RedCap UEs can continue using the MIB-configured CORESET#0 (e.g., its location, bandwidth, SCS, and cyclic prefix). In this case, for TDD, the center frequencies between CORESET#0 and the initial UL BWP for RedCap can be different as long as the total bandwidth of the two is not larger than the RedCap maximum UE bandwidth.
Moreover, several contributions [10, 23, 24] mention that, in TDD, the center frequency of CORESET#0 and the initial UL BWP are not necessarily aligned but the total bandwidth of the two is not larger than the RedCap maximum UE bandwidth.
Some additional views are expressed as follows:
 [8]: If a separate SIB-configured initial DL BWP for RedCap UEs is not configured when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, then the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0.
 [16]: A separate initial DL BWP is always configured for RedCap if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth.
 [19]: If a separate SIB-configured initial DL BWP for RedCap UEs is not configured when the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, then CORESET#0 is defined as separate initial DL BWP. CORESET#0 can be used during and after initial access.
 [22]: For a cell that allows RedCap UEs to access, a separate SIB-configured initial DL BWP for RedCap UEs shall always be configured if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UEs bandwidth.
 [23]: For TDD, the center frequencies between CORESET#0 and the initial UL BWP for RedCap can be different as long as the total bandwidth of the two is not larger than the RedCap maximum UE bandwidth. Otherwise, they are the same.
 [31]: Support configuration of CORESET#0A in separate initial DL BWP
 CORESET#0A has same properties as CORESET#0 in terms of size and length
 FFS: first PRB of CORESET#0A in separate initial DL BWP.
Based on the above views, the following proposal related to the RedCap separate initial DL BWP can be considered.
FL1 High Priority Proposal 2-1: For the case that the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, down-select between the following two options during RAN1#108-e:
 Option 1: A separate initial DL BWP is configured for RedCap if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth.
 Otherwise, the UE shall consider the cell as barred.
 Option 2: The RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0.
 For TDD, the center frequencies of the MIB-configured CORESET#0 and the initial UL BWP are not necessarily aligned, but the total frequency span of MIB-configured CORESET#0 and the initial UL BWP does not exceed the RedCap UE maximum bandwidth.
Company
Y/N
Preferred option (if any)
Comments
vivo

Option 1 (1st preference)
Option 2 is also fine with modification
For Option 2, even for now the RRC_CONNECTED non-RedCap UE does not support the non-aligned center frequency between DL and UL BWP. Therefore we cannot agree with Option 2 as is, since it will break the legacy rule for center-frequency alignment between DL and UL BWP with the same ID
We are fine with proposal 2 if following modification is made:
 Option 2: The RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0.
 For TDD, the center frequencies of the MIB-configured CORESET#0 and the initial UL BWP needs to be are not necessarily aligned, but the total frequency span of MIB-configured CORESET#0 and the initial UL BWP does not exceed the RedCap UE maximum bandwidth.
 Otherwise, RedCap UE expects to be configured with separate initial DL BWP 
Nordic

Option 1
As commented, in legacy initial DL BWP is always configured in SIB1. We do not understand why RedCap initial DL BWP should be handled otherwise. Option 1 would automatically also resolve center-frequency issue.

There are at least 3 sub-options for Option 2 for TDD


 Option 2-1 the total frequency span of MIB-configured CORESET#0 and the initial UL BWP does not exceed the RedCap UE maximum bandwidth.
 Option 2-2:  CORESET#0 is within BW of initial UL BWP
 Option 2-3: CORESET#0 and initial UL BWP is center-frequency aligned, otherwise RedCap UE expects to be configured with separate initial DL BWP

We would be fine with Option 2-2 and 2-3

Spreadtrum

Prefer Option 1, but can live with Option 2 if it is the majority view and have the modification
Option 1 is more simple way to avoid the ※continue-to-use§ mechanism, which is lack of flexibility.
For Option 2, if the RedCap UE continues to use the location/bandwidth/＃ of CORESET#0, e.g. during random access, the RedCap UE needs to perform RF retuning for DL/UL switch, when the center frequencies of CORESET#0 and the initial UL BWP are not aligned. It is not complexity and power efficient. Therefore, we share the similar modification as vivo.
FUTUREWEI

Option 1 and option 2 with modifications
Option 1 is straightforward for the UE and eliminates checking by the UE. Option 2 can reduce the signaling overhead, especially if the network chooses not to configure a separate initial DL BWP. We are open to consider options including those mentioned by Nordic and vivo 
Qualcomm


Either Option 1 or Option 2 is fine
Intel

Prefer Option 2, but ＃
We support Option 2. There is no need to mandate SIB1 signalling when it can be avoided. For most typical deployments in the initial phases when connection density of RedCap UEs is not very large, having the RedCap UEs use CORESET#0 is an desirable option that should be supported efficiently 每 i.e., by not mandating unnecessary overhead from SIB1 (which is already rather large).
We should not couple the discussion on DL BWP configuration and center frequency decision. These should be decoupled. For instance, the main issue in this proposal also applies to FDD where the question of center frequency alignment is moot.
Even for non-RedCap UEs, there is no requirement on center frequency alignment between CORESET#0 and initial UL BWP. However, there are requirements on alignment defined for BWPs with same BWP index in TDD. 
So, the details on center frequency alignment in TDD and related requirements/expectations can be discussed and defined separately.
Ericsson
Y
Option 1
Option 1 is the most straightforward solution from specification point-of-view. Option 2 would necessitate specifying yet another UE behavior during initial access and time-consuming discussions related to center-frequency alignment between initial DL BWP defined by MIB-configured CORESET#0 and initial UL BWP during random access. 
Nokia, NSB

Option 2
In our understanding, there is no need to always configure a separate initial DL BWP for RedCap if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth configure. The UE can use CORESET#0 during and after initial access. Therefore, we＊d like to keep this flexibility.
LGE
Y
Option 2
Option 2 is useful in the case where the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth and no separate initial DL BWP is needed, i.e., the MIB-configured CORESET#0 is intended to be used as the initial DL BWP for both non-RedCap and RedCap UEs. In this case, Option 1 still requires the signaling overhead.
FL2
Based on the discussion in the online (GTW) session on Monday 21st February, the following updated proposal can be considered.
High Priority Proposal 2-1a: For the case that the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth, down-select between the following two options during RAN1#108-e:
 Option 1: A separate initial DL BWP is always configured for RedCap if the initial DL BWP for non-RedCap UEs is wider than the maximum RedCap UE bandwidth.
 Otherwise, the UE shall consider the cell as barred.
 Option 2: If a separate initial DL BWP is not configured for RedCap, the RedCap UE continues to use at least the location, bandwidth, SCS, and cyclic prefix of the MIB-configured CORESET#0.
 For TDD, the center frequencies of the MIB-configured CORESET#0 and the initial UL BWP are not necessarily aligned, but the total frequency span of MIB-configured CORESET#0 and the initial UL BWP does not exceed the RedCap UE maximum bandwidth.
Qualcomm
Y


CATT
Y
Option 2
With Option 2, separate initial DL BWP can still be configured. If configured, then it should be used; if not configured, the CORESET#0 is reused.

Several contributions [6, 18, 19, 22, 27] also discuss aspects related to reception of DCI Format 1_0 for RedCap. In particular, when a separate initial DL BWP is configured for RedCap, clarification is needed for the DCI size determination in a CSS. Contributions [18, 19, 22, 27] propose that the size determination for DCI Format 1_0 should be based on the size of CORESET #0. In [6], it is proposed to down-select two options: Option 1: it is determined by the size of CORESET 0, and Option 2: it is determined by the size of the separate initial DL BWP.
FL1 Medium Priority Proposal 2-2: For RedCap UE reception of DCI format 1_0 in a CSS:
 DCI size always depends on size of CORESET#0.
 Resource allocation starts at first PRB of CORESET where DCI format has been received
Company
Y/N
Comments
vivo
Y

Nordic 
Y
We assume, this should be a Conclusion, as no spec change needed.
FUTUREWEI

Before a decision is made, we should consider some implications of DCI size bullet. If a separate initial DL BWP is provided, then its size must be at least the size of CORESET#0. A network implementation may want to consider a different size for the separate initial DL BWP. Another point is the RB alignment for a CORESET (starting at multiple of 6 RBs). It may not be possible to ensure RB alignment, TDD center frequency alignment and size.
Qualcomm
Y

Intel
Y

Ericsson
Y

Nokia, NSB
Y

LGE
Y

FL2
The online (GTW) session on Monday 21st February made the following conclusion:
Conclusion: For RedCap UE reception of DCI format 1_0 in a CSS:
 DCI size always depends on size of CORESET#0.
 Resource allocation starts at first PRB of CORESET where DCI format has been received

SSB for BWP#0 configuration option 1 in connected mode
Another open issue is related to presence of SSB in a separate initial DL BWP when used in connected mode for BWP#0 configuration option 1. Several contributions argue that for BWP#0 configuration option 1, the use of initial DL BWP in connected mode is very limited from functionality and power saving point of view [9, 16, 19]. Also, these contributions indicate that based on RAN2 feedback, NCD-SSB is not provided for the initial DL BWP. Therefore, several contributions propose that, for BWP#0 configuration option 1, the UE does not expect SSB in the separate initial DL BWP that is configured for random access when it is used in connected mode [9, 10, 16, 19, 24]. In [12], it is noted that BWP#0 configuration option 1 can be supported for RedCap UE irrespective of the presence of CD-SSB and entire CORESET#0 in a separate initial DL BWP. Contribution [5] mentions that a RedCap UE can use BWP#0 option 1 in the connected state if the RedCap UE is configured with a separate initial DL BWP that contains CORESET#0/SSB. However, one contribution [17] argues that a RedCap UE can expect to be provided with NCD-SSB transmission in the separate initial DL BWP.

Based on the above views, the following proposal can be considered:
FL1/FL2 High Priority Proposal 3-1: For BWP#0 configuration option 1, if the separate initial DL BWP is used in connected mode and it is only used for random access, the UE does not expect it to always contain SSB.
Company
Y/N
Comments
vivo
N
Firstly, we need to have a decision whether to allow BWP#0 configuration option 1 for the initial DL BWP configuration. From our perspective, we do not see the benefits/motivation to support BWP#0 configuration option 1 to configure the separate initial DL BWP, using BWP#0 configuration option 2 might be sufficient. 
Even if BWP#0 configuration option 1 is allowed for separate initial DL BWP configuration, it is not clear to us how to capture the proposal 3-1 into specification, as to our understanding it is hard to define a BWP in connected mode ※only used for random access purpose§, i.e. to prevent other scheduling beyond random access. 
Nordic
Y, but
If this would be the case for short time until UE gets dedicated RRC, we would be fine. Otherwise, UE not supporting optional capabilities would be in trouble.
Spreadtrum
Maybe N
We are not sure whether or not RAN1 should have the further agreement on it. The previous agreement has such meaning already, and in spec 38.213, ※during random access§ is written as ※monitoring Type1-PDCCH§ which is also fine for connected mode.
 For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective,
 If it is configured for random access while not for paging in idle/inactive mode, RedCap UE does NOT expect it to contain SSB/CORESET#0/SIB.
Qualcomm
N
First of all, it is necessary to clarify the relationship between RedCap-specific DL BWP#0 configured by option 1 and the separate initial DL BWP of idle/inactive RedCap UE. 
If the separate initial DL BWP of RedCap UE does not contain the entire CORESET#0 and Type-2 PDCCH CSS, an idle/inactive RedCap UE does not need to monitor paging when performing random access in the separate initial DL BWP. However, whether or not the separate initial DL BWP contains SSB depends on the BWP configuration. 
If DL BWP#0 configured by option 1 includes the entire initial DL BWP separately configured for idle/inactive RedCap UE, the following examples indicate BWP#0 contain CD-SSB or NCD-SSB.



Intel
N
Similar concerns as Vivo 每 it is not clear how ※only used for random access procedure§ or the case mentioned by Nordic ※If this would be the case for short time ＃§ can be specified or enforced. Once the RRC connection is setup, the UE may simply be kept on this BWP for connected mode operations by the gNB. In such a case, the UE without optional capability to operate without SSB in (RRC configured) DL BWP cannot function since the basic challenge for the UE＊s inability is same as for a RRC-configured DL BWP in this case.
Thus, we think for BWP#0 configuration option 1, UE can expect NCD-SSB if CD-SSB is not included. 
Alternatively, we are also fine with the suggestion from Vivo to preclude use of BWP#0 configuration option 1 for BWP#0 for RedCap UEs. 
Ericsson
Y
The proposal is consistent with the UE behavior in idle/inactive mode. If the UE does not expect SSB while performing random access in idle/inactive mode, the UE should not expect it while performing random access in connected mode.
The proposal could be modified as follows for more clarity:
FR1 and FR2
For BWP#0 configuration option 1, if the separate initial DL BWP, which does not include CD-SSB, is used in connected mode and it is only used for random access, the UE does not expect it to always contain SSB.
Note that after initial access the use of initial BWP is not very likely for BWP#0 configuration option 1, as the UE typically operates on a non-initial BWP (e.g., BWP#1). However, in some cases, the UE may fallback to BWP#0 for performing random access. 
Nokia, NSB
Y
Our view is that the if the BWP is only used for random access, then there is no need for the BWP to contain SSB.
Our view is that the use case for BWP#0 configuration option 1 in connected mode is very limited. Likely UE will be switched to RRC-configured BWP later on.
LGE
Y

CATT
Y
Just to remind that, in BWP#0 configuration option 1, only SIB1 configuration is applied in initial DL BWP. There is no UE-dedicated RRC configuration in the initial DL BWP. 
Meanwhile, NCD-SSB can only be indicated via UE-dedicated RRC signaling. As RAN2 is not going to pursue NCD-SSB in IDLE mode, configuring NCD-SSB in initial DL BWP will be contradictory to the definition of BWP#0 configuration option 1 itself.

FL1/FL2 High Priority Question 3-2: For BWP#0 configuration option 1, should it be supported to use the separate initial DL BWP in connected mode for other purposes than random access? If the answer is yes, please comment in the Comments field on whether the UE should expect it to always contain SSB.
Company
Y/N
Comments
vivo

Firstly, we need to have a decision whether to allow BWP#0 configuration option 1 for the initial DL BWP configuration. From our perspective, we do not see the benefits/motivation to support BWP#0 configuration option 1 to configure the separate initial DL BWP, using BWP#0 configuration option 2 might be sufficient. 
Even if BWP#0 configuration option 1 is allowed for separate initial DL BWP configuration, it is not clear to us how to capture the proposal 3-1 into specification, as to our understanding it is hard to define a BWP in connected mode ※only used for random access purpose§, or ※for other purposes than random access§. 
Nordic
N
BWP#0 in Option 1 is used in legacy only until UE gets dedicated RRC. So clearly not meant for RRC connected mode.
Spreadtrum
Maybe N
For connected mode, gNB can also configure the CSS in the UE-specific DL BWP. 
For BWP#0 configuration Option 1, if gNB configures the CSS (SIB/paging) in the separate initial BWP, RedCap UE should retune RF to monitor the CSS outside the active DL BWP, no matter the separate initial DL BWP contains SSB or not. Indeed, from the RAN plenary conclusion:
Scheme 1 (i.e. UE in IDLE and INACTIVE monitors paging in an initial BWP associated with CD-SSB) is adopted for further work in Rel-17. Scheme 2 (i.e. UE in IDLE and INACTIVE monitors paging in an initial BWP associated with NCD-SSB) is not considered further in Rel-17.
RAN2 should work on the assumption that the cell reselection measurements and cell ranking are performed based on measurements on the CD-SSB. This applies for intra- and inter-frequency measurements, and for IDLE and INACTIVE states.
it seems more feasible that RedCap UE should receive SIB/paging in CORESET#0. Therefore, we think for BWP#0 configuration Option 1, RedCap UE should receive SIB/paging in CORESET#0, although we share the similar view as vivo that gNB should avoid such power inefficient configuration for UE.
Qualcomm
FFS
This issue has lower priority than other discussion points.
Intel
Y
As responded to Proposal 3-1, in this case is supported, UE can expect presence of SSB in the DL BWP. 
@Nordic - We are not sure if there is anything in the specifications that enforce that a UE cannot be scheduled in BWP#0 after RRC connection setup if option 1 is used. It is up to gNB choice if the UE is to remain in BWP#0 for option 1 even after RRC connection setup.  
Ericsson
Y
In principle (as in legacy), for BWP#0 configuration option 1, an initial DL BWP can also be used in connected mode albeit with a limited functionality as it does not have UE-specific configurations.  Also, the initial BWP can act as a default BWP which can be used for the purpose of power saving after the initial access (i.e., in connected mode).  As per RAN1 agreements, the UE expects SSB if the initial DL BWP is used for paging.
Nokia, NSB
Y
Our view is that the use case for BWP#0 configuration option 1 in connected mode is very limited. Likely UE will be switched to RRC-configured BWP later on. However, we believe it should still be possible to use this in connected mode.
However, if it is used for connected mode then the BWP should contain SSB.
LGE

Not sure if we need to restrict the usage of the separate initial DL BWP in connected mode to the random access only for BWP#0 configuration option 1. Also not sure if this discussion will lead to any specification impact. But, we are open for further discussion during this meeting.
CATT
FFS
We do not see too much use cases but open to discuss. For BWP#0 configuration option 1, only SIB1 configuration can be applied, hence Type 3 CSS and USS are not considered:
Possible use may include paging in CONNECTED mode, or transmission of RRC configurations/UE capability report in a short period.
   
Update of RAN1 working assumptions on DL BWP operation
The remaining working assumptions from RAN1#107e are as follows for FR1. There are similar working assumptions for FR2.
Agreement:
 For FR1,
 For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective,
 If it is configured for random access while not for paging in idle/inactive mode, RedCap UE does NOT expect it to contain SSB/CORESET#0/SIB.
 Note: RAN1 assumes REDCAP UE performing Random access in the separate DL BWP does not need to monitor paging in a BWP containing CORESET#0
 Working assumption:?If it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB from RAN1 perspective
 For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective,
 A RedCap UE supporting mandatory FG 6-1 (but not optional FG 6-1a) expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB
 A RedCap UE can indicate the following as optional capability:
 Not need NCD-SSB: A RedCap UE can in addition optionally support relevant operation based on for CSI-RS (working assumption) and/or FG 6-1a by reporting optional capabilities.
 Note: if a separate initial/RRC configured DL BWP is configured to contain the entire CORESET#0, CD-SSB is expected by RedCap UE.
 Note: The network may choose to configure SSB or MIB-configured CORESET#0 or SIB1 to be within the respective DL BWP.
 Note: If a separate SIB-configured initial DL BWP for RedCap UEs contains the entire CORESET#0, the RedCap UE shall use the bandwidth and location of the CORESET#0 in DL during initial access.
 Note: NCD-SSB periodicity is not required to be configured the same as that of CD-SSB
 Note: Periodicity of NCD-SSB shall be not less than periodicity of CD-SSB
?

Regarding use of NCD-SSB in idle mode operation, RAN#94-e made the following agreement [36].
 Scheme 1 (i.e., UE in IDLE and INACTIVE monitors paging in an initial BWP associated with CD-SSB) is adopted for further work in Rel-17. 
 Scheme 2 (i.e., UE in IDLE and INACTIVE monitors paging in an initial BWP associated with NCD-SSB) is not considered further in Rel-17.

RAN2 provided feedback [38] on the RAN1 working assumption on use of CSI-RS in DL BWPs for RedCap UEs [37]:
Regarding the following working assumption for FR1 and FR2 related to an RRC-configured active DL BWP in connected mode: ※A RedCap UE can in addition optionally support relevant operation based on CSI-RS§
 The use of CSI-RS for cell/beam RLM and measurements is supported from RAN2 signalling standpoint as indicated earlier. RAN4 has informed RAN2 and RAN1 that CSI-RS cannot be used as a standalone mechanism for RRM measurements and existing requirements rely on the presence of SSB signals, in their reply LS provided in R4-2120327. RAN2 does not intend to introduce a new mechanism that would enable a RedCap UE to perform CSI-RS based RRM measurements and think that it is up to RAN4 to decide whether RAN1 working assumption regarding the use of CSI-RS in connected mode is acceptable based on the information provided above.

RAN4 provided feedback [41] on the RAN1 working assumption on use of CSI-RS in DL BWPs for RedCap UEs [37]:
For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0): 
 A RedCap UE that supports FG 6-1a but NOT support CSI-RS based L3 measurement operates in the BWP
 the UE can support RLM, BFD, CBD and L1 RSRP measurement based on CSI-RS if UE reports the corresponding capabilities.
 the UE can support SSB based L3 measurement but cannot support CSI-RS based L3 measurement.
 A RedCap UE that supports FG 6-1a and CSI-RS based L3 measurement operates in the BWP
 the UE can support RLM, BFD, CBD and L1 RSRP measurement based on CSI-RS if UE reports the corresponding capabilities.
 the UE can support both SSB based L3 measurement and CSI-RS based L3 measurement with associated SSB.
 RAN4 will not define CSI-RS L3 based measurement requirements for Redcap 1RX UE in Rel-17.
 For serving cell timing related requirements, RAN4 will not define requirements based on CSI-RS in Rel-17. 


In addition, regarding NCD-SSB properties, RAN4 provided the following feedback [40]:
 It is RAN4 assumption that NCD-SSB is ＆QCL＊-ed with CD-SSB when the NCD-SSB and CD-SSB shares the same SSB index.

Based on the received feedbacks, several contributions [5, 13, 15, 16, 17, 19, 23] propose to update the above working assumptions identified in RAN1#107e.  In particular, it is proposed to remove (do not confirm) the working assumption about paging considering that in Rel-17 RedCap UE in idle/inactive mode monitors paging only in an initial BWP associated with CD-SSB. Also, a few contributions [5, 15, 16, 23] indicate that the working assumption regarding ※Not need NCD-SSB§ may need to be revised considering that CSI-RS is not used as a standalone mechanism for RRM measurements in Rel-17. However, two contributions [10, 19] propose to confirm the working assumption about ※Not need NCD-SSB§.
Some other presented views are summarized below:
 [15]: Operation based on CSI-RS in an active BWP without either CD-SSB or NCD-SSB should not be considered in Rel-17 because RAN4 will not define requirement for it in Rel-17.
 [27]: Do not confirm the working assumption about CSI-RS and focus only on design of capability FG 6-1 by means of retuning gaps.
 [29]: The time offset of each NCD-SSB is explicitly configurable by the network, which could be different from that of CD-SSB in the same network.
 [29]: For a RedCap UE, at most one SSB can be configured within its active BWP.
 [30]: It is up to UE implementation about whether to receive the SIB when the UE retunes to CORESET0 and retunes back to separate initial UL BWP for RSRP measurement due to msg1/A retransmission.   
 [33]: When initial DL BWP is shared or separate initial DL BWP contains legacy initial DL BWP, additional RedCap specific paging and RAR search space are supported.
 [35]: It is proposed update the description and figures corresponding to BWP#0 configuration for RedCap UEs in RAN2 specifications.

Some contributions discuss UE capability aspects (something which is also discussed under agenda item 8.16.6):
 [7]: Legacy behavior shall be followed that the RedCap UE can support CSI-RS based L3 measurement with associated SSB and RLM, BFD, CBD, L1 RSRP measurement based on CSI-RS if UE reports the corresponding capabilities.
 [12]: It is not necessary to either specify RedCap UE dedicated UE capability signaling or update existing UE features in the current specification which indicate the support of CSI-RS based operation for L3 measurement, RLM, BFD, CBD and L1 RSRP measurement.
 [13]: Remove ※CORESET#0§ or add a note in FG 6-1/6-1a/6-2/6-3/6-4. The note is ※For RedCap UE, CORESET#0 here means CORESET#0 or CORESET of CSS§.
 [23]: 
 FG 1-5 (※CSI-RS based RRM measurement without associated SS-block§) is not applicable to RedCap UE.
 FG 1-4 (※CSI-RS based RRM measurement with associated SS-block§) is not applicable to RedCap UE and add a new UE feature group(s) for RedCap UE to report its support for CSI-RS based RRM measurement with associated SSB. 
 The new UE feature group(s) is to be discussed in AI 8.16.6.
 FG 6-1a is a prerequisite for the new UE feature group(s). 
Based on the above views, the following can be considered.
FL1 High Priority Proposal 4-1: Replace the working assumption from RAN1#107e ※Working assumption:?If it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB from RAN1 perspective§ with the following note based on the RAN plenary agreement [36]:
 Note (for FR1 and FR2): In Rel-17, a RedCap UE in idle/inactive mode monitors paging only in an initial BWP associated with CD-SSB.

Company
Y/N
Comments
vivo
Y

Nordic
Y
We agree that paging in separate initial BWP is supported in RRC connected.  Wording could be updated/simplified as follows:
Note (for FR1 and FR2): In Rel-17, above applies only for RRC connected state.
Spreadtrum
Y

FUTUREWEI
Y

Qualcomm
Y

Intel
Y

Ericsson
Y
The note could be modified as follows:
Note (for FR1 and FR2): In Rel-17, a RedCap UE in idle/inactive mode monitors paging only in an initial BWP (default or RedCap-specific) associated with CD-SSB.
Nokia, NSB
Y

LGE
Y

FL2
The RAN1 working assumption concerns paging in any RRC state. For idle/inactive mode, RAN2#116bis-e has already made the following agreement:
 A RedCap UE in idle/inactive mode monitors paging only in an initial BWP (default or RedCap specific) associated with CD-SSB and performs cell (re-)selection and measurements on the CD-SSB
Based on the discussion in the online (GTW) session on Monday 21st February, the following updated proposal can be considered, which replaces the RAN1 working assumption with a proposed RAN1 agreement for connected mode only.
High Priority Proposal 4-1a: Replace the working assumption from RAN1#107e ※Working assumption:?If it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB from RAN1 perspective§ with the following agreement:
 For FR1,
 For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective,
 For connected mode, if it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB.
 For FR2,
 For a separate initial DL BWP (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective,
 For connected mode, if it is configured for paging, RedCap UE expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB.

Qualcomm
Y

CATT

Not sure whether this has relationship with BWP#0 configuration option. As far as we expect, BWP#0 configuration option 1 cannot configure any UE-dedicated RRC configuration (e.g. NCD-SSB). Does this proposal mean if separate initial DL BWP is BWP#0 configuration option 1, it shall not be configured for paging in connected mode?

Based on the online (GTW) session for agenda item 8.16.6 (on the RedCap UE feature list) on Monday 21st February, the following proposal can be considered.
FL2 High Priority Proposal 4-1-1: A RedCap UE supports NCD-SSB based operation (including NCD-SSB based measurements) in an RRC-configured DL BWP that does not include CD-SSB.
Company
Y/N
Comments
Qualcomm
Y
We support FL2 proposal. It has no conflict with RAN1#107 agreements for NCD-SSB in terms of RedCap UE＊s capability for SSB-based measurements. Moreover, the proposal is consistent with the reply LS from RAN2 and RAN4 on RedCap UE＊s use of NCD-SSB of serving cell in the RRC-configured DL BWP.

CATT

Open to hear more views. But our first impression is that this proposal mandates a RedCap UE to support NCD-SSB based operations. We are OK if the majority is fine with it.




FL1/FL2 High Priority Question 4-2: Given the feedback from RAN2 and RAN4, can the CSI-RS-related working assumption in the following bullet from the RAN1#107e agreement be confirmed as is? Please provide potential updates or other additional comments regarding CSI-RS-based operation as needed in the Comments field.
 Not need NCD-SSB: A RedCap UE can in addition optionally support relevant operation based on for CSI-RS (working assumption) and/or FG 6-1a by reporting optional capabilities.

Company
Y/N
Comments
vivo
N
Based on RAN4＊s feedback for CSI-based measurement that is always coupled with ※A RedCap UE that supports FG 6-1a [＃]§, it means CSI-RS cannot be used as a standalone method. Therefore, we propose if the WA needs to be confirmed in Rel-17, FG6-1a should be the prerequisite for RedCap UE supporting relevant operations based on CSI-RS. Following update is necessary. 
 For an RRC-configured active DL BWP in connected mode (if it does not include CD-SSB and the entire CORESET#0) from RAN1 perspective,
 A RedCap UE supporting mandatory FG 6-1 (but not optional FG 6-1a) expects it to contain NCD-SSB for serving cell but not CORESET#0/SIB
 A RedCap UE can indicate the following as optional capability:
 Not need NCD-SSB: A RedCap UE can in addition optionally support relevant operation based on for CSI-RS (working assumption) and/or if FG 6-1a is supported by reporting optional capabilities.

Nordic
N
Based on the feedback from RAN2 and RAN4 and given this is maintenance.
 Not need NCD-SSB: A RedCap UE can in addition optionally support relevant operation based on for CSI-RS (working assumption) and/or FG 6-1a by reporting optional capabilities.

Spreadtrum
N
Share the similar view as vivo.
Qualcomm
N
It is unclear to us if FG 6-1a implies a legacy UE can measure SSB outside its dedicated DL BWP without a measurement gap. If the answer is ※yes§ for legacy UE, FG 6-1a does not apply to R17 RedCap UE due to BW reduction.
Intel
N
We do not think that the WA can be confirmed based on feedback received from RAN2 and RAN4. The version from Nordic is preferred since use of CSI-RS in this context is mainly for measurements, and towards that, we already have separate optional UE capabilities since Rel-15 for CSI-RS-based L3 msmts, etc.
Ericsson
Y, but
It is clear from the RAN2 and RAN4 replies that CSI-RS cannot be used a standalone mechanism for RRM measurements in Rel-17. Therefore, the UE should rely either on FG 6-1a only or on both FG 6-1a and CSI-RS for these measurements.  
We propose the following update:
Not need NCD-SSB: A RedCap UE can in addition optionally support relevant operation based on for FG 6-1a or both CSI-RS (working assumption) and/or FG 6-1a by reporting optional capabilities.
We are also fine with the update proposed by Vivo. 
Nokia, NSB

We are OK with the proposal from vivo.
LGE
N
Either not supporting the CSI-RS based operation or supporting it with existing capabilities is preferred. For the latter, it would be acceptable to us if some changes are made as suggested below.
 A RedCap UE can indicate the following as optional capability:
 Not need NCD-SSB: A RedCap UE supporting FG 6-1a can in addition optionally support relevant operation based on for CSI-RS (working assumption) and/or FG 6-1a by reporting optional capabilities.
CATT
update
To make it more accurate, we can update the WA as ※based on FG 6-1a with supporting CSI-RS, or FG 6-1a without supporting CSI-RS§.
Ericsson＊s version is fine to us.

Based on the online (GTW) session for agenda item 8.16.6 (on the RedCap UE feature list) on Monday 21st February, the following question can be considered.
FL2 High Priority Question 4-2-1: Should FG 6-1a apply for RedCap?
 If yes, what updates/clarifications are needed for FG 6-1a (e.g., regarding on measurement gaps)?
 If no, please comment on what other FG(s) may need to be defined in place of FG 6-1a.
Company
Y/N
Comments
Qualcomm

If a RedCap UE can optionally support RRC-configured BWP without CORESET#0 and SSB AND needs a measurement gap for L1/L3 measurements of serving cell＊s SSB outside the SSB-less DL BWP , we think it is necessary to introduce a new RedCap-specific FG as such, to differentiate with FG 6-1a defined for non-RedCap UE.
CATT

We think FG 6-1a can be reused. 
Not sure if we need to couple measurement gap in FG 6-1a. We already have other FGs related to measurement gap, e.g. FG 4-x, FG 9-x.




Finally, RAN2 has discussed this scenario and how a RedCap UE performs RSRP measurements before Msg1 or MsgA retransmission on separate initial UL BWP and agreed on the following [39]:
 From RAN2 perspective, if a RedCap UE in idle/inactive mode is configured with a separate initial BWP associated with no SSB (CD or NCD) for RACH, it is up to UE implementation to perform new RSRP measurement in a DL BWP associated with CD-SSB before Msg1/A retransmission.

FL1/FL2 Medium Priority Question 4-3: Does the RAN2 agreement regarding RSRP measurement before Msg1/MsgA retransmission require any updates of RAN1 specifications? If yes, please elaborate in the Comments field.
Company
Y/N
Comments
vivo
N

Nordic
N

FUTUREWEI
N

Qualcomm
Y
If RedCap UE needs to measure RSRP for RO re-selection (or RA type re-selection) before msg1/msgA retransmission, the following timeline requirements specified for non-RedCap UE in Clause 8.2 and 8.2A of TS 38.213 do not apply to RedCap UE.

Therefore, a clarification for R17 RedCap UE＊s timeline of msg1/msgA retransmission needs to be included in 213 spec.
Ericsson

We think Qualcomm has a good point. However, RAN4 involvement may be needed to specify the new timeline requirement. 
LGE
N

CATT
N


PUCCH resource determination
From RAN1#107-e, we have the following agreement regarding RedCap PUCCH resources (for HARQ feedback for Msg4/MsgB):
Agreement: 
 When the frequency hopping for the RedCap PUCCH resources (for HARQ feedback for Msg4/MsgB) is deactivated,
 Each PUCCH resource is mapped to a single PRB.
 What side[(s)] of the RedCap UL BWP center frequency to which PUCCH resources are mapped is[/are] configurable by the network, including SIB-configurable [additional] offset (with no more than [4] candidate values) using the existing equations for determining the PRB index of the PUCCH transmission as a starting point.
 RedCap and non-RedCap can be configured with the same or different PUCCH resource set indices (see TS 38.213 Table 9.2.1-1).

Several contributions [4, 5, 6, 7, 9, 10, 12, 14, 16, 17, 19, 20, 24, 26, 27, 28] provided their views on the PUCCH resource determination with disabled frequency hopping in terms of whether both edges of UL BWP can be used or all PUCCH resources are mapped to one edge, 2) maximum number of PUCCH resources, 3) additional PRB offset, and 4) explicit equations. 
Many of the contributions [5, 6, 7, 9, 10, 14, 16, 17, 19, 20, 24, 26, 27] propose that all PUCCH resources should be mapped to only one edge of the UL BWP considering the purpose of disabling PUCCH frequency hopping for minimizing the UL resource fragmentation. One contribution [4] supports also mapping the PUCCH resources to both edges of the UL BWP. 
Most of these contributions [4, 5, 6, 9, 14, 16, 17, 19, 24, 26] propose to support the maximum 16 PUCCH resources in case of disabled PUCCH frequency hopping to achieve a higher capacity compared to the case with 8 PUCCH resources. 
In addition, contributions are generally supportive of having additional PRB offsets for RedCap to avoid overlapping PUCCH resources. Contribution [27] proposes that additional offset values {0, 4, 6, 8} can be configured for RedCap default PUCCH resource set. Also, in [12], it is proposed that the candidate values are {2, 3, 4, 6} and if the field is absent, the RedCap UE assumes the value of 0.
Based on the above views, the following proposal can be considered:
FL1 High Priority Proposal 5-1: When the frequency hopping for the RedCap PUCCH resources (for HARQ feedback for Msg4/MsgB) is deactivated,
 All 16 PUCCH resources are mapped to one side, and it is SIB-configurable which side.
 The PRB index of the PUCCH transmission is determined using the existing equations as a starting point, with an additional PRB offset with 4 candidate values.
 One of the candidate values is zero.
Company
Y/N
Comments
vivo
Y

Nordic 
Y

FUTUREWEI
Y

Qualcomm
OK

Intel
Y

Ericsson
Y

Nokia, NSB
Y

LGE
Y (almost)
For the additional PRB offset, we prefer to keep the number of candidate values in square bracket until we make a progress in the discussion in Question 5-2. We don＊t have to stick to 4 candidate values if it somehow limits the flexibility in the common PUCCH resource set configuration.
FL2
The online (GTW) session on Monday 21st February made the following agreement. The candidate values are considered in Question 5-2.
Agreement:
When the frequency hopping for the RedCap PUCCH resources (for HARQ feedback for Msg4/MsgB) is deactivated,
??????????All 16 PUCCH resources are mapped to one side, and it is SIB-configurable which side.
??????????The PRB index of the PUCCH transmission is determined using the existing equations as a starting point, with an additional PRB offset with [4] candidate values.
o????One of the candidate values is [zero].
?



FL1/FL2 High Priority Question 5-2: Companies are invited to comment on suitable candidate values for the additional PRB offset values.
Company
Comments
vivo
We slightly prefer the additional offset values are {0, 4, 6, 8}for better co-exist with legacy common PUCCH resources. 
Nordic
As we contributed, {0,4,6,8} provides the best multiplexing with non-RedCap UE PUCCH
FUTUREWEI
The values of {0,4,6,8} seem reasonable
Qualcomm
OK with the proposal of Vivo and Nordic
Intel
Support {0, 4, 6, 8} as candidate PRB-offset values.
Ericsson
PRB offsets are useful to avoid overlapping between PUCCH transmissions from different sectors (e.g., 3 or 4 sectors) using the same PUCCH format. For example, the PRB offsets {0, 2, 4}avoid overlapping of PUCCH resources with index 4, 5, 6. For each of these indexes, 2 PRBs on each edge is used, so PRB offset values increases by value 2 ({0, 2, 4}). 
Index
PUCCH format
First symbol
Number of symbols
PRB offset 
Set of initial CS indexes
1
0
12
2
0
{0, 4, 8}
2
0
12
2
3
{0, 4, 8}
4
1
10
4
0
{0, 3, 6, 9}
5
1
10
4
2
{0, 3, 6, 9}
6
1
10
4
4
{0, 3, 6, 9}

With disabled FH for RedCap, all PRBs will be located on one edge. In the above example, 4 PRBs will be on one edge. Therefore, to avoid overlap, the PRB offsets should be {0, 4, 8}. 
Similarly, for index 1 and 2 in the above table, 3 PRBs are allocated on each edge and PRB offsets are {0,3}. For RedCap with disabled FH, 6 PRBs will be located on one edge. Therefore, the offset values should be {0, 6}. 
The same argument is hold for other PUCCH indexes.
Currently, the set of all fixed PRB offset values are {0, 2, 3, 4}(for index 15 there is also an additional offset ). For RedCap with disabled FH where all PRBs are mapped to one edge of UL BWP, the fixed PRB offset values should be doubled. Thus, we support values {0, 4, 6, 8} which are also proposed by companies above.
Nokia, NSB
No strong view, we are fine with {0, 4, 6, 8}
CATT
Current PUCCH resource allocation has a □RB■_"BWP" ^"offset"  , mainly with a value set of {0, 2, 4}, if we do not consider the special values appear only once, i.e. 3 and □RB■_"BWP" ^"size" /4. Hence, the RB offset of RedCap PUCCH from BWP edge can be considered as {0, 2, 4}+{0, 2, 4}, i.e. {0,2,4,6,8}. 
It seems considerable to adopt {2,4,6,8} as 4 explicit configurable value, while the value is equal to 0 if the field is absent. 
If the field is mandated, we are fine with {0,4,6,8}

Based on the online (GTW) session for agenda item 8.16.6 (on the RedCap UE feature list) on Monday 21st February, the following question can be considered.
FL2 High Priority Question 5-3: Should it be supported to disable frequency hopping for common PUCCH resources for RedCap UEs in a shared initial UL BWP? Please provide your motivation in the Comments field.
Company
Y/N
Comments
Qualcomm
N
If RedCap UE and non-RedCap UE share the same initial UL BWP configuration, we don＊t think it is necessary to disable FH for common PUCCH resources. As a result, the utilization efficiency of cell-specific PUCCH resources can be optimized for all UE types.
CATT
N
Legacy Rel-15/16 UEs mandates FH of common PUCCH in shared initial UL BWP. 
If RedCap UE shares initial UL BWP with legacy UEs, the most proper way is follow legacy behavior, i.e. mandates FH for common PUCCH. This provides better coexistence and allows inter-UE multiplexing.




Other aspects
The following other aspects not covered in the earlier sections of this document are discussed in some contributions.
UL/DL center frequency in TDD:
 [6]: For TDD, the center frequencies are assumed to be the same for the initial DL BWP and initial UL BWP after initial access for RedCap UEs.
 [13]: For TDD, center frequencies are the same for the initial DL and UL BWP during random access for RedCap UEs, no matter whether or not it includes CD-SSB and the entire CORESET#0 or not.
 [21]: For TDD, the initial DL BWP for RedCap UEs (separate or default) shall be center frequency aligned with the initial UL BWP for RedCap UEs (separate or default) for both during initial access and after initial access.
 [23]: For TDD, center frequencies are the same for the initial DL and UL BWPs for RedCap UEs, regardless of whether the initial DL BWP contains CD-SSB and the entire CORESET#0.
 [27]: In TDD, initial UL BWP applicable to RedCap UEs is aligned in center frequency with initial DL BWP applicable to RedCap UEs.
Multiplexing of FH and non-FH PUCCH:
 [4]: Two base sequences are generated and applied for a non-FH PUCCH with time-domain symbol allocation and frequency domain PRB allocation the same as that of an intra-slot FH PUCCH.
 [12]: When intra-slot PUCCH frequency hopping within the separate initial UL BWP in the PUCCH resource for HARQ feedback for Msg4/MsgB for RedCap UEs is disabled, UE generate two base sequences for the PUCCH as if intra-slot frequency hopping is enabled for the PUCCH transmission.
 [17]: Multiplexing between non-FH and FH PUCCH from RedCap and non-RedCap UEs respectively is left up to gNB implementation.
 [18]: If intra-slot FH is disabled for Redcap and overlapped RBs are used for non-FH and FH PUCCH transmissions, the base sequence group/sequence hopping for PUCCH format 1 is determined based on value of ＆pucch-GroupHopping＊ IE configured for non-Redcap UE.
RACH occasions:
 [4]: For the shared ROs scenario, only ROs which fall within separate initial UL BWP can be regarded as valid ROs for RedCap UEs and the mapping of SSB-to-RO can be separately configured for RedCap UEs.
 [10]: When ROs are shared, a separate mapping between RO and SSB for RedCap UE may be needed.
Companies are invited to comment on whether any other critical issues (beside the ones covered in earlier sections) need to be resolved to conclude the Rel-17 RedCap WI.
FL1/FL2 Medium Priority Question 6-1: Companies are invited to comment on whether any other critical issues (beside the ones covered in earlier sections) need to be resolved to conclude the Rel-17 RedCap WI.
Company
Comments
vivo
For the center-frequency alignment issue, we think the legacy principle should be maintained, i.e. a TDD UE assumes center-frequency alignment between DL BWP and UL BWP with the same BWP index. 
Nordic 
We believe it would be good to clarify what CORESET(s) can be configured in separate Initial DL BWP not containing CORESET#0 by MIB.  If non-RedCap SIB1 shall be reused for RedCap, commonCORESET configuration requires more than 50bits, this is critically high. We believe there should be possibility for some simple CORESET configuration, be it called CORESET0A or something else.
Spreadtrum
 NW can configure the separate initial DL BWP, no matter whether the separate initial DL BWP contains CD-SSB and the entire CORESET#0. We are not sure the current agreements (when combined) can imply it. If it can, we are fine for it.
 Similar as vivo, we think the center-frequency alignment b/w DL/UL BWP should be applied to all cases for RedCap UE. In the current agreements, there is a FFS for the case when the initial DL BWP does not include CD-SSB and the entire CORESET#0.
Qualcomm
Based on the replies from RAN2 and RAN4, we think it is necessary to:
 confirm that L1/L3 measurements based on NCD-SSB of serving cell are supported as mandatory capabilities of R17 RedCap UE and included as an additional component of FG 28-1
 discuss the signaling aspects for NCD-SSB (with RAN1 impacts) in dedicated DL BWP of RedCap UE
 for example, whether or not the configuration/availability of NCD-SSB can follow a mechanism of SI plus RRC/DCI
Intel
The following issues (mentioned in our tdoc [17] although not listed above) needs to be addressed during this meeting: 
 Center frequency alignment:
 Center frequency alignment between initial DL BWP and initial UL BWP for RedCap when the initial DL BWP includes CORESET#0 and CD-SSB.
 RAN1 specifications should capture the center frequency alignment between initial DL and UL BWPs when they are used for random access. The current text from Rel-15 in Subclause 12 of 38.213 is not sufficient as it only refers to BWPs with same index. With possibility of configuration of separate initial DL/UL BWPs, the Rel-15 text would be ambiguous as to how BWPs with same indices are identified in such a context.
 The details of NCD-SSB needs to be finalized following the feedback from RAN2/RAN4 so that they can be captured in the RAN1 specifications appropriately.
 RAN1 needs an agreement on configuration of CORESET in addition to ra-searchSpaceSet in separate initial DL BWP, including details of such CORESET configuration.



References
[1]
RP-211574
Revised WID on support of reduced capability NR devices
Ericsson
[2]
R1-2112506
RAN1 agreements for Rel-17 NR RedCap
Rapporteur (Ericsson)
[3]
R1-2112501
FL summary #5 on reduced maximum UE bandwidth for RedCap
Moderator (Ericsson)
[4]
R1-2200917
Remaining issues on reduced maximum UE bandwidth
Huawei, HiSilicon
[5]
R1-2200985
Remaining aspects of Bandwidth Reduction for RedCap UEs
FUTUREWEI
[6]
R1-2201099
Remaining issues on reduced maximum UE bandwidth
Vivo, Guangdong Genius
[7]
R1-2201136
Bandwidth reduction for reduced capability NR devices
ZTE, Sanechips
[8]
R1-2201277
Remaining issues on reduced UE bandwidth
OPPO
[9]
R1-2201367
Remaining issues on reduced maximum UE bandwidth
CATT
[10]
R1-2201404
Aspects related to reduced maximum UE bandwidth
Nokia, Nokia Shanghai Bell
[11]
R1-2201441
Remaining issues on reduced maximum UE bandwidth for RedCap
China Telecom
[12]
R1-2201482
Remaining issues on reduced maximum UE bandwidth for RedCap
NTT DOCOMO, INC.
[13]
R1-2201549
Discussion on aspects related to reduced maximum UE bandwidth
Spreadtrum Communications
[14]
R1-2201590
Aspects related to reduced maximum UE bandwidth for RedCap
Panasonic Corporation
[15]
R1-2201605
Remaining issues on BWP operation for RedCap
NEC
[16]
R1-2201668
Reduced maximum UE bandwidth for RedCap
Ericsson
[17]
R1-2201702
On reduced BW support for RedCap
Intel Corporation
[18]
R1-2201775
Reduced maximum UE bandwidth for Redcap
Apple
[19]
R1-2201861
Remaining issues of reduced maximum UE bandwidth
CMCC
[20]
R1-2201955
Discussion on the remaining issues of reduced UE bandwidth for RedCap
Xiaomi
[21]
R1-2201970
Reduced maximum UE bandwidth for RedCap
Lenovo, Motorola Mobility
[22]
R1-2202020
UE complexity reduction
Samsung
[23]
R1-2202061
On reduced bandwidth for NR RedCap UEs
MediaTek Inc.
[24]
R1-2202192
Discussion on reduced maximum UE bandwidth
Sharp
[25]
R1-2202250
Remaining issues on reduced maximum UE bandwidth
InterDigital, Inc.
[26]
R1-2202344
Aspects related to the reduced maximum UE bandwidth of RedCap
LG Electronics
[27]
R1-2202382
On aspects related to reduced maximum UE BW
Nordic Semiconductor ASA
[28]
R1-2202146
Remaining Issues on UE Complexity Reduction
Qualcomm Incorporated
[29]
R1-2200918
On RAN1 aspects of RAN2 led issues for RedCap
Huawei, HiSilicon
[30]
R1-2201138
Higher layer support of Reduced Capability NR devices
ZTE, Sanechips
[31]
R1-2202383
On RAN2 related aspects
Nordic Semiconductor ASA
[32]
R1-2201864
Remaining issues of other aspects for RedCap UE
CMCC
[33]
R1-2201892
Remaining aspects for RedCap
ZTE, Sanechips
[34]
R1-2201958
Discussion on the fast BWP switching for RedCap
Xiaomi
[35]
R1-2202419
On?RedCap UE BWP configuration
Huawei, HiSilicon
[36]
RP-213689
Moderator＊s proposals from [94e-39-R17-RedCap-WI]
Moderator (Intel)
[37]
R1-2112802
LS on use of NCD-SSB or CSI-RS in DL BWPs for RedCap UE
RAN1, Ericsson
[38]
R1-2200876
Reply LS on the use of NCD-SSB or CSI-RS in DL BWPs for RedCap UEs
RAN2, Ericsson
[39]
R1-2200877
LS on RSRP measurement before Msg1 or MsgA retransmission
RAN2, Ericsson
[40]
R1-2200898
Reply LS on use of NCD-SSB for RedCap UE
RAN4, ZTE
[41]
R1-2200904
Reply LS on use of NCD-SSB or CSI-RS in DL BWPs for RedCap UE
RAN4, Vivo