3GPP TSG-RAN WG1 Meeting #106-e	R1-210xxxx
e-Meeting, 16th ¨C 27th August 2021


Agenda Item:	8.6.2

Title:	[draft] FL summary #1 on RAN1 aspects for RAN2-led features for RedCap

Source:	Moderator (NTT DOCOMO, INC.)

Document for:	Discussion, Decision

1 Introduction
This document summarizes contributions [1] ¨C [26] submitted to agenda item 8.6.2 and relevant parts of contributions [27] ¨C [34] submitted to agenda item 8.6.3 and captures the following email discussion for the RedCap WI.
[106-e-NR-R17-RedCap-05] Email discussion regarding RAN1 aspects for RAN2-led features ¨C Shinya (DoCoMo)
* 1st check point: August 19
* 2nd check point: August 24
* Final check: August 27

The issues in this document are tagged and colour coded with High priority, Medium priority, or Low priority.
In this round of the discussion, companies are requested to provide comments on the proposals and questions tagged FL1.
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 RedCapR2ledFLS1-v002-CompanyA-CompanyB.docx.
* CompanyC uploads an empty file named RedCapR2ledFLS1-v003-CompanyB-CompanyC.checkout
* CompanyC then has 30 minutes to upload RedCapR2ledFLS1-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-2106403), 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 into the Annex.
2 Definition of RedCap UE type
The WID [35] has the following objective on the definition of RedCap UE type:
* Specify definition of one RedCap UE type including capabilities for RedCap UE identification and for constraining the use of those RedCap capabilities only for RedCap UEs, and preventing RedCap UEs from using capabilities not intended for RedCap UEs including at least carrier aggregation, dual connectivity and wider bandwidths. [RAN2, RAN1]
o The existing UE capability framework is used; changes to capability signalling are specified only if necessary.

Following working assumption/conclusion related to the definition of RedCap UE type were made at RAN1#105-e:
Working assumption:
* RedCap UE type is defined based on one of the following options
o Option 2: Only include the reduced capabilities that the network needs to know during initial access, if any.
o Option 4: The corresponding minimum set of the reduced capabilities that one RedCap UE type shall mandatorily support 
o FFS: details of the set of reduced capabilities
Conclusion:
* RAN1 postpones the discussion on constraining of reduced capabilities, and if deemed necessary, RAN1 can come back

Many contributions [2, 3, 4, 8, 9, 11, 12, 13, 14, 15, 16, 18, 19, 20, 22, 23, 24, 25] discuss the above working assumption. A few contributions such as [3] support Option 2 because Option 4 may cause underestimation on some RedCap UE capabilities. On the other hand, many of others [2, 8, 9, 11, 12, 13, 16, 20, 22, 23, 24, 25] support Option 4 because it shows ¡®what a RedCap UE should be¡¯ and includes Option 2, while Option 2 may vary depending on the configuration and deployment.  One contribution [4] suggests clarification is needed for these options. One contribution [11] suggests focusing on the basic FG structure. Another contribution [13] suggests waiting for RAN2 discussion. In addition, one contribution [15] propose another alternative that it includes the minimum set of mandatory UE capabilities that the NW can assume during initial access. Some contributions [1, 14, 18, 19] suggest directly defining the RedCap UE type by the maximum UE bandwidth (i.e., 20MHz for FR1 and 100MHz for FR2) which would fulfil both option 2 and option 4.   One contribution [3] proposes relative criterion(s) compared between the UE capability and cell operating parameters; at least the comparison on maximum channel bandwidth for a UE can support and a cell can operate (e.g. as specified in Table 5.3.5-1 for FR1 in TS 38.101-1 and Table 5.3.5-1 for FR2 in TS 38.101-2) should be used as one criterion. One contribution [3] suggest that UE declaration of RedCap/non-RedCap is band-specific. Note that following agreement was made RAN1#103-e and hence, maximum UE bandwidth is already included without any further agreements.
Agreements:
* If early identification during initial access is?supported, at least maximum supported UE BW during initial access is included in the set of L1 capabilities of the device type for RedCap early identification?
o Note: 20 MHz for FR1 and 100 MHz for FR2
o Identification of UEs optionally supporting bandwidths larger than 20 MHz in FR1 or larger than 100 MHz in FR2 after initial access, if supported,?is not supported by early identification during initial access
o FFS other L1 capabilities
o Note: This does not preclude the case where the early indication only indicates whether it is a Redcap UE or which type of the Redcap UEs if multiple UE types are defined

Given the situation, we can try to down-select to Option 4 having majority support with a note clarifying at least maximum supported UE BW is included. Whether/which other L1 capabilities are included is still FFS, and to be further discussed in Proposal 2-2 (i.e., no other L1 capabilities may be included).
Medium Priority Proposal 2-1:
* RedCap UE type is defined based on
o Option 4: The corresponding minimum set of the reduced capabilities that one RedCap UE type shall mandatorily support
o Note: At least maximum supported UE BW (20 MHz for FR1 and 100 MHz for FR2) is included
o FFS whether/which other L1 capabilities are included
Company
Y/N
Comments
Huawei, HiSilicon

It would be anyway necessary to review which exact capability is included, i.e. the FFS would be the next discussion point (i.e. Q2-2). Thus, we suggest to take Q 2-2 as next step of discussion prior to agreeing on Option 4.
OPPO
Y
The minimum set of the reduced capabilities that one RedCap UE type shall mandatorily support is FFS in Q2-2. 
CATT
Y

CMCC

We think the Note and FFS are sub bullet of option4, that is the reduced capabilities that one RedCap UE type shall mandatorily support at least including maximum supported UE BW, and others as FFS.
Nokia, NSB
Y

NEC
Y

Qualcomm
Y

FUTUREWEI
Y
RAN1 can start to design the basic feature group for FR1 and FR2 UEs
LG
Y


Regarding the FFS in the above working assumption, several contributions [1, 2, 3, 6, 8, 9, 11, 12, 14, 16, 22, 24] discuss the reduced capabilities included in the definition of the RedCap UE type. As mentioned above, maximum supported UE BW, which is suggested to be included in the definition by many of them [1, 2, 3, 6, 8, 11, 14, 16, 22, 24], is already agreed. Some contributions [2, 6, 16, 22, 24] suggest that the capabilities of minimum number of Rx branches (1 Rx branches) and maximum number of DL MIMO layers (1 layer) are included, while some others [8, 11] suggest that reduced number of Rx branches (either 1 or 2 Rx branches) and maximum number of DL MIMO layers (1 or 2 layers) are included. Some contributions [2, 6, 16, 22, 24] suggest that maximum DL modulation order (64QAM) is included. Some contributions [2, 6, 8, 22] suggest that duplex operation (HD-FDD and TDD) are also included. One contribution [9] suggests that following capabilities are included:
* Reduced baseline capability FG5-1 to max 8 HARQ processes
* No support of supplemental uplink and CBG 
* Mandatory support of dynamic repetition for PDSCH, PUCCH and PUSCH
Another contribution [12] suggests waiting for RAN2 discussion.
Given the situation, there would be no common understanding whether/which other L1 capabilities are included. Moderator suggests coming back to the following question 2-2 after Medium Priority Proposal 2-1 is converged.
Low Priority Question 2-2:
* Which reduced capabilities other than maximum supported UE BW should be included in the definition of RedCap UE type?
Company
Comments
Huawei, HiSilicon
Do not see strong need to include other items.
Nokia, NSB
The definition of the ¡°RedCap Type¡±, should provide sufficient information to enable the network to configure itself for the worst case RedCap device it can expect to handle before receipt of full UE capability information. 
In our view, this would include in addition to maximum BW support: 
* The minimum number of Rx branches/DL MIMO layers supported 
* The minimum DL modulation order supported
LG
The reduced number of Rx branches, the maximum number of DL MIMO layers, the maximum DL modulation order and duplex operation could be additionally included in the definition of RedCap UE type. Other reduced capabilities than those reduced capabilities seem not essential to be considered in definition of RedCap UE type.

3 Early indication of RedCap UEs
The WID [35] has the following objective on early indication of RedCap UEs:
* Specify functionality that will enable RedCap UEs to be explicitly identifiable to networks through an early indication in Msg1 and/or Msg3, and Msg A if supported, including the ability for the early indication to be configurable by the network. [RAN2, RAN1]

Following agreements/working assumption related to the definition of RedCap UE type were made at RAN1#105-e:
Working assumption:
* For 4-step RACH, support the early indication of RedCap UEs at least in Msg1.
o The early indication in Msg1 can be configured to be enabled/disabled
* FFS How to support enable/disable the early indication
o FFS details e.g.:
* separate initial UL BWP
* separate PRACH resource
* PRACH preamble partitioning
o FFS the possibility of supporting Msg3 for the early indication 
Agreement: (if the above working assumption is confirmed)
* Early indication of RedCap UEs in Msg1 can be enabled/disabled via SIB
Agreement:
* Support 2-step RACH for RedCap UEs as an optional feature
o FFS details of early indication in MsgA, e.g.:
* Separation of 2-step RACH resources or MsgA preambles
* Separation of initial UL BWP
* Using a new indication in MsgA PUSCH part
o Note: Discussion on 4-step RACH for early indication should be prioritised

Regarding early indication of RedCap UEs in Msg1, many contributions [1, 2, 4, 7, 9, 11, 12, 13, 15, 16, 18, 19, 21, 22, 23, 24, 26] suggest confirming the working assumption to support the early indication of RedCap UEs in Msg1. For the details, several companies support the indication through separate initial BWP, which is being discussed in AI8.6.1.1. However, as pointed out by some contributions such as [1], separate initial BWP itself cannot be used to indicate whether the UE is RedCap or not if PRACH resource is shared by initial UL BWP for non-RedCap UEs and separate initial UL BWP for RedCap UEs. Many contributions support separate RO [1, 2, 4, 5, 6, 8, 9, 13, 15, 16, 18, 19, 20, 21, 22, 23, 24, 25, 26] either for separate initial UL [2, 6, 8, 9, 16, 19, 21, 22, 23, 24] and/or shared initial UL BWP [4, 8, 9, 16, 19, 20, 21, 22, 23, 24]. Similarly, many contributions support separate PRACH preamble [1, 2, 4, 5, 6, 8, 13, 16, 18, 19, 20, 21, 22, 23, 24, 25] either for separate initial UL [2, 16, 24] and/or shared initial UL BWP [2, 4, 6, 16, 19, 20, 21, 22, 23, 24]. Therefore, as many contributions suggest, both of separate RO and separate PRACH preamble can be supported for Msg1 early indication from RAN1 perspective. Note that, as some contributions pointed out, RAN2 will discuss RACH indication and partitioning aspects common for multiple WIs such as SDT, CovEnh, RedCap, and RAN slicing in this RAN2 meeting. Therefore, moderator expects the relationship of early indication during initial access between RedCap and other features, which is raised by some contributions [2, 6, 8, 10], will be discussed in RAN2. In addition, a few contributions [2, 26] point out that it is necessary to address RA-RNTI overlapping issue caused by RO time/frequency configurations (see details in their contributions).
8.18	RACH indication and partitioning
Time budget: Equivalent to 0.5-1 TU
Tdoc Limitation: 1 tdocs
Expected to cover WIs SDT, CovEnh, RedCap, RAN slicing .. Initial discussion on what should be treated in common and what design could be common.   

FL1 High Priority Proposal 3-1:
Confirm the following working assumption with the modifications in red:
* For 4-step RACH, support the early indication of RedCap UEs at least in Msg1.
o The early indication in Msg1 can be configured to be enabled/disabled via SIB
* FFS how to support enable/disable the early indication
o FFS details e.g.: From RAN1 perspective, followings can be used for early indication 
* Both for shared initial UL BWP and separate initial UL BWP (if supported)
* separate PRACH resource
* PRACH preamble partitioning
* FFS: how to address RA-RNTI overlapping issue
o FFS the possibility of supporting Msg3 for the early indication 

Company
Y/N
Comments
vivo

For ¡°separate initial UL BWP¡± case, the following may not be needed?
* separate PRACH resource
* PRACH preamble partitioning
For ¡°FFS: how to address RA-RNTI overlapping issue¡±, we prefer to leave it to RAN2 for further study as there are multiple other use cases requiring PRACH resource partitioning currently under RAN2 discussion, a unified solution would be desirable, if justified. 
Huawei, HiSilicon
Y

OPPO
Y
The necessities of these issues can be identified in RAN1, and LS is sent to RAN2 for information. We are fine with the revised working assumptions.
CATT
Y

CMCC
Y

Nokia, NSB?
Y?
Slight wording improvement suggested:?
?
From the RAN1 perspective,?the following methods?can be used for early indication??
? Both for shared initial UL BWP and?for?separate initial UL BWP (if supported)?
* separate PRACH resource?
* PRACH preamble partitioning?
* FFS: how to address RA-RNTI overlapping issue
?
Sharp
Y 

Lenovo, Motorola Mobility
Y
For this bullet ¡°The early indication in Msg1 can be configured to be enabled/disabled via SIB.¡±, we don¡¯t think there should be an explicit signalling to enable/disable the early identification. The early identification is enabled if there are separate preambles configured for RedCap UEs. 

NEC
Y

Qualcomm
Y

We think ¡°separate PRACH resource¡± is general enough for msg1-based early indication of RedCap UE, since it can include  separate PRACH configuration index, separate ROs in separately configured initial UL BWP, or PRACH preamble partitioning on shared RO.

Besides, we are open to discuss in RAN1/2 how to address the RA-RNTI overlapping issues (if any).

FUTUREWEI
Y
Editorial: can the bullets be combined (using Nokia¡¯s proposed revision)?
¡°From the RAN1 perspective, the following methods can be used for early indication for shared initial UL BWP and for separate initial UL BWP (if supported)¡±
LG

We understand that separate PRACH resource or PRACH preamble partitioning can be used even for separate initial UL BWP. However, it could be also possible for gNB to configure separate initial UL BWP without separate PRACH resource and PRACH preamble partitioning. How to configure those options could be up to gNB implementation.

Regarding the FFS on the possibility of supporting Msg3 for the early indication, a number of contributions [1, 2, 4, 7, 9, 10, 13] support the early indication of RedCap UEs in Msg3 to avoid PRACH capacity reduction, which can be configured to be enabled/disabled by SIB [13], and suggest to send an LS to RAN2 [10], while some others [3, 5, 8, 12, 14, 18, 23, 25] do not support it because RedCap-specific handling cannot be applied before Msg3 and it is not necessary to specify duplicated functions. Given the situation and the detail of Msg3 indication would be mainly RAN2 matter, moderator suggests discussing whether/which scenarios the early indication in Msg 3 is worth specifying from RAN1 perspective and trying to send an LS to ask RAN2 to decide whether to support or not.
FL1 High Priority Question 3-2:
* For 4-step RACH, which scenarios is the early indication of RedCap UEs in Msg3 applicable from RAN1 perspective?
o Note: This question is aiming to identify the scenarios where early indication of RedCap UEs in Msg3 is applicable, and if identified, to send an LS to ask RAN2 to decide whether to support the early indication of RedCap UEs in Msg3 or not

Company
Comments
vivo
We do not see much benefit by specifying MSG 3 based early indication in addition to MSG1 based solution, and duplicated spec effort should be avoided as much as possible. 
We think the question should be aiming to identify the scenario where where early indication of RedCap UEs in Msg3 is applicable in addition to Msg 1¡­.
Huawei, HiSilicon
There has been several cases identified during the study phase and, e.g. when PARCH capacity is concerned. From our perspective Msg3 is also one of the options that specification shall support and up to network to configure. The detailed solution can be up to RAN2.
OPPO
Share the same view with Huawei. RAN2 is discussing how to support the indication of UE with multiple UE features through PRACH. The partitioning of PRACH resource and PRACH capacity are main concerned issues. For the early indication in Msg1, it is working assumption that it can be configured to be enabled/disabled via SIB. Network may disable early indication in Msg1 if the PRACH capacity is limited. In this case Msg3 can be configured to support early indication during initial access. 
CATT
We do not think identifying RedCap UE in Msg3 is very useful in 4-step RACH. 
It seems only happens when the PRACH resources and preambles are fully shared. But this also means that the gNB does not rely on early indication of RedCap for scheduling of Msg2 and Msg3 for RedCap, e.g. the initial DL/UL BWP are shared, and are both no larger than the maximum RedCap UE BW. It is natural that the gNB does not rely on early indication of RedCap for scheduling of Msg4, either. This, again, makes early indication in Msg3 unnecessary.
CMCC
When Msg.1 identification is disabled due to capacity consideration, gNB can configure early identification by Msg.3 for access control or proper scheduling.
Nokia, NSB?
Early identification of?RedCap?with Msg3 could help improve Msg4 feedback?in the absence of Msg1 early identification.?? We do not support a combined Msg1 and Msg3 early capability indication scheme.????
If the majority of RAN1 do not see sufficient benefit in supporting Msg3 early indication, we support a LS to RAN2, seeking their opinion on Msg3 early indication.?
Sharp
For scenario where both UL and DL initial BWPs are shared between RedCap UE and non-RedCap UEs, early indication of RedCap UEs in Msg3 can be applicable. In this scenario, there is no different scheduling handling of Msg2 unless gNB separates Type 1 CSS for RedCap UE from that for non-RedCap UE. Early indication of RedCap UEs in Msg3 can help to avoid additional PRACH resource configuration for RedCap if PRACH capacity is concerned.    
Lenovo, Motorola Mobility
From RAN1 point of view, we don¡¯t see strong motivation to have early identification in Msg3. 
NEC
In case msg3 is used for early indication, gNB cannot take into account of RedCap type until msg3 is successfully received. SO, in our opinion, early indication via msg3 is not so useful. A separate initial UL BWP/separate RACH resources, e.g. can also be used to mitigate over PRACH resource partitioning.
Qualcomm
We don¡¯t see much benefit to support early indication of RedCap UE type based on msg3 only, or by both msg1 and msg3.

We think msg1-based early indication should be supported for RedCap UE at least when:
1) initial DL/UL BWPs are separately configured for RedCap UE 
  and/or 
2) DL/UL coverage recovery are needed for msg2/msg3.

If msg1-based early indication is not supported but msg3-based early indication is supported, it suggests:
1) initial DL/UL BWPs are NOT separately configured for RedCap UE 
and
2) DL/UL coverage recovery are not needed for msg2/msg3
However, if RedCap UE is not configured with a separate initial UL BWP (msg1-based early indication is not supported), it is not necessary to disable the FH of PUCCH carrying HARQ feedback for msg4. Therefore, msg3-based early indication is not much useful for disabling FH of PUCCH during initial access. 

FUTUREWEI
While Msg1 is preferable for early identification (BW and/or whether to address DL performance), Msg3 provides an alternative when RACH resources are limited for Msg1. We also note that RAN2 should understand that Msg3 is up to them, we could just leave to them unless asked.

Regarding 2-step RACH, a number of contributions [1, 4, 8, 13, 18, 19, 34] support early indication in MsgA. Some of them [4, 8, 13, 18, 34] suggest Msg1/Msg3 indication for 4-step RACH is reused where applicable, such as Separate 2-step RACH resources, MsgA preambles or initial UL BWP. Some contributions [8, 13] support the indication in Msg A PUSCH part while one contribution [18] does not support it because it is infeasible when MsgA PUSCH may not be transmitted by the UE under certain conditions (e.g., when the MsgA PUSCH may be cancelled). In addition, some companies [2, 7] suggest postponing the discussion until 4-step RACH discussion is completed. Given the situation and based on the agreement in the last RAN1 meeting to prioritize 4-step RACH case, moderator suggest to come back 2-step RACH case when further progress is made for 4-step RACH case.
4 System information indication
The WID [35] has the following objective on system information indication:
* Specify a system information indication to indicate whether a RedCap UE can camp on the cell/frequency or not; it shall be possible for the indication to be specific to the number of Rx branches of the UE. [RAN2, RAN1] 

A few contributions [2, 8, 12] suggest that this topic is not considered further in RAN1 or RAN1 should wait for RAN2¡¯s further progress. As discussed in the last RAN1 meeting, a number of contributions [1, 6, 12 (can be studied), 16, 17, 23] support the access control specific to RedCap UEs with 1Rx or 2Rx via DCI associated with SIB1 based on the following RAN2 agreement, which would obtain power saving benefits by skipping SIB1 reading, while a few contributions [2, 18] do not support it because it would not lead to substantial power saving benefits but would require separate treatment from all other features for RedCap and may incur large specification impact in RAN2.
Agreements:
1. SIB1 (not MIB) indicates cell barring for 1 Rx branch and 2 Rx branches separately for RedCap UEs. Further details of the solution are FFS

Given the situation, moderator suggests trying to make conclusion on the following proposal which was discussed in the last RAN1 meeting.
Medium Priority Proposal 4-1:
* For system information indication of access control for RedCap UEs,
o FFS: Whether it is needed to have the indication in DCI scheduling SIB1

Company
Y/N
Comments
Huawei, HiSilicon
Y
Given RAN2 discussion/progress, RAN1 input seems necessary for this issue.
OPPO
Y
For DCI based indication of access control for RedCap UEs, RAN1 can discuss and make some decision on it.
CATT
N
As RAN2 is the leading group in cell access/barring, we think RAN1 should wait for RAN2¡¯s progress until the design/signaling is clear. If RAN2 needs RAN1s assistance, it can trigger LS to RAN1. 
CMCC
Y

Nokia, NSB?
Y?
We support the intention, however in our opinion the following wording is clearer?
?
Access control information for?RedCap?UEs is supported using System Information.?
FFS??? Whether the DCI scheduling SIB1 is used to support?RedCap?Access information.?
Lenovo, Motorola Mobility
N
Up to RAN2 decision.
NEC
N
We share the view of CATT and Lenovo/Motorola Mobility.
FUTUREWEI
N
Up to RAN2
LG
Y
The indication in DCI scheduling SIB1 seems beneficial for UE power saving.

A number of contributions discuss what kind of system information indication is necessary, which would be discussed in RAN2. One contribution [1] suggests the indication whether NW supports RedCap UEs accessing or not is necessary, and different cell selection/reselection time for 1Rx or 2Rx can be configured by gNB. Some other contributions [16, 17] propose the access control specific to RedCap UEs with 1Rx or 2Rx. Another contribution [31] suggests that gNB can deprioritize RedCap UEs e.g. with 1-Rx capability by configuring lower RACH opportunity.
5 Necessary updates of UE capabilities and RRC parameters
The WID [35] has the following objective on the necessary updates of UE capabilities and RRC parameters:
* Specify necessary updates of UE capabilities (38.306) and RRC parameters (38.331). [RAN2]

One contribution [6] suggests RAN1 starts the email discussion on the UE features for RedCap UEs after RAN1#106e-meeting considering that only a few meetings are left before the end of Rle-17 and we do not have enough TUs to discuss the massive features. It is moderator¡¯s understanding that Rel-17 UE feature discussion will start from RAN1#106bis-e meeting while the applicability of existing UE features to RedCap UEs can be discussed even before that, as we have done for some parts of them, such as basic BWP operation FG6-1, compact DCI, MCS/CQI tables, 2-step RACH, etc.
As discussed in the last RAN1 meeting, some contributions [11, 22] suggest agreeing on the following proposal, while some others [18, 29, 30] suggest further discussion on what features are applicable to RedCap UEs is necessary term by term. Another contribution [28] suggests all UE capabilities other than those related to carrier aggregation, dual connectivity and wider bandwidths can be supported by RedCap UE either as mandatory or as optional unless precluded by a specific RedCap feature. Some contributions [27, 29] also suggest RedCap UEs do not support the capabilities related to the carrier aggregation, dual connectivity, and wider bandwidths.
Medium Priority Proposal 5-1:
* For the necessary updates of UE capabilities, current definition of mandatory/optional support of L1 UE capabilities in TS38.306 is reused for RedCap UEs by default unless any update is identified
o Note: UE capabilities related to CA, DC and wider max UE bandwidth are not applicable to RedCap UEs

In addition, some contributions [27, 28, 29] suggest at least for the features that are mandatory without capability signalling for non-RedCap UEs, the RedCap UEs should support mandatorily with the same value. Following features are also discussed:
? maxNumberMIMO-LayersPDSCH: Optional [27, 28]
? pdsch-256QAM-FR1: Optional [27, 28]
? csi-RS-RLM, additionalActiveTCI-StatePDCCH/additionalActiveSpatialRelationPUCCH: Optional [27]
? oneFL-DMRS-TwoAdditionalDMRS-UL, spatialBundlingHARQ-ACK: Not necessary [27]
? Capabilities related to power saving: FFS whether RedCap UEs mandatorily support [27]
? Capabilities related to the processing timeline: Use the same value as the one for non-RedCap UEs [27]
? Capabilities related to the SUL: Not necessary [28], further discuss whether there are any additional issues in order to optionally support SUL for RedCap, e.g. switching time to be discussed in RAN4 [32]
? Rel-16 UE capabilities: FFS [28]
? FG 6-1a (BWP operation without restriction on BW of BWP(s)): mandatory [28]
Given the situation, we can try to agree on the following proposal modifying Proposal 5-1 in the last RAN1 meeting:
Medium Priority Proposal 5-1:
* For the necessary updates of UE capabilities, current definition of L1 UE capabilities mandatory without capability signaling in TS38.306 is reused for RedCap UEs by default unless any update is identified
o Note: UE capabilities related to CA, DC and wider max UE bandwidth are not applicable to RedCap UEs
o FFS: applicability of L1 UE capabilities mandatory/optional with capability signaling to RedCap UEs

Company
Y/N
Comments
CATT
Y in principle
It may be important to avoid duplicated work with RAN2. 
For information, RAN2 have the following agreements in the last meeting:
Agreements online:
1.	RAN2 Working Assumption: by default, all non-RedCap UE capabilities are applicable for RedCap UE, and therefore only for non-RedCap capabilities that are not appliable for RedCap UE, we clarify in the definitions for parameters in TS38.306, the value or feature is not applicable for RedCap UE
2.	We will have an email discussion until the next meeting to discuss which higher layer capabilities are not applicable for RedCap UEs (it could result in a draft 38.306 CR) and how to reflect the handling of RedCap specific capabilities (e.g. Maximum BW, Max Rx, MIMO-Layer, 256QAM, CA/DC, HD-FDD, etc)

Nokia, NSB
Y

FUTUREWEI

We support the better approach following what RAN2 is doing, which provides a default to avoid checking hundreds of capabilities one by one
LG
Y
We could also add:
¡®FFS: any update is needed in the current definition of L1 UE capabilities mandatory without capability signaling in TS38.306¡¯.

6 Other aspects
SI framework (other than system information indication in Section 4)
? Study a mechanism for scheduling new SIB1 (e.g. SIB1-R) used by REDCAP UEs [17]
> When CORESET0 is configured to be shared between RedCap UEs and non-RedCap UEs, the DCI format 1_0 with CRC scrambled by SI-RNTI can be used to schedule both legacy SIB1 and new SIB1-R.
? gNB may provide different configurations for transmissions of other SI for REDCAP UEs and non-REDCAP UEs. (e.g. AL or separate DL BWP) [17]
> REDCAP specific RACH resources can be configured for gNB to transmit on-demand SI message
? Reuse existing SIB1 to incorporate the new system information for RedCap [33]
> consider the following options to improve the power efficiency during system information updating 
* Option 1: Define separate systeminfoModification field in paging DCI.
* Option 2: Paging messages of RedCap devices and non-RedCap devices are not multiplexed in the same paging resource
Measurement related issues by reduced number of Rx branches [13]
? RedCap UEs specific RSRP thresholds are configured by gNB for SSB and UL carrier selection for performing random access
? Measurement related thresholds are configured specifically for RedCap UEs with reduced Rx branches number
? Send an LS to RAN2 to inform the above measurement related issues
Annex: Companies¡¯ point of contact
FL1 Question: 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
CATT
Yongqiang FEI
feiyongqiang@catt.cn
Lenovo, Motorola Mobility
Yuantao Zhang
zhangyt18@lenovo.com

References
[1]
R1-2106462
RAN1 aspects of RedCap UE type and identification
Huawei, HiSilicon
[2]
R1-2106567
RAN1 aspects for RAN2-led features for RedCap
Ericsson
[3]
R1-2106604
Higher layer support for RedCap
vivo, Guangdong Genius
[4]
R1-2106651
Higher layer support of Reduced Capability NR Devices
Nokia, Nokia Shanghai Bell
[5]
R1-2106707
Discussion on early indication for RedCap
Spreadtrum Communications
[6]
R1-2106845
Higher layer support of Reduced Capability NR devices
ZTE, Sanechips
[7]
R1-2106897
UE capability report and access barring for Redcap UE
Samsung
[8]
R1-2106981
Discussion on higher layer support of RedCap
CATT
[9]
R1-2107043
On RedCap UE early identification and UE type
Nordic Semiconductor ASA
[10]
R1-2107077
Design consideration for Higher layer support of RedCap
Sierra Wireless, S.A.
[11]
R1-2107090
Discussion on the Identification of RedCap UEs
FUTUREWEI
[12]
R1-2107130
Discussion on RAN1 aspects for RAN2-led features for RedCap
China Telecom
[13]
R1-2107252
Mechanism in higher&PHY layer for Reduced Capability NR Devices
OPPO
[14]
R1-2107302
RAN1 aspects for RAN2-led features for RedCap
NEC
[15]
R1-2107355
Cross Layer Design Considerations for RedCap Device
Qualcomm Incorporated
[16]
R1-2107412
Discussion on higher layer support of RedCap UE
CMCC
[17]
R1-2107451
RAN1 aspects for RAN2-led features for RedCap
LG Electronics
[18]
R1-2107598
On RAN1 aspects for RAN2-led objectives for RedCap
Intel Corporation
[19]
R1-2107749
On Higher Layer Support of Redcap Devices
Apple
[20]
R1-2107797
RAN1 aspects for RAN2-led features for RedCap
Sharp
[21]
R1-2107812
Identification and restriction of RedCap UEs
InterDigital, Inc.
[22]
R1-2107867
Discussion on RAN1 aspects for RAN2-led features for RedCap
NTT DOCOMO, INC.
[23]
R1-2107930
Discussion on the remaining issues of the higher layer related topics for RedCap
Xiaomi
[24]
R1-2107949
RAN1 aspects for RAN2-led features for RedCap
Lenovo, Motorola Mobility
[25]
R1-2108043
RAN1 aspects for RAN2-led features for RedCap
Panasonic Corporation
[26]
R1-2108156
Discussion on higher layer support of Redcap UE
WILUS Inc.
[27]
R1-2106605
Discussion on L1 reduced capability signaling
vivo, Guangdong Genius
[28]
R1-2106653
Discussion on RedCap UE capabilities
Nokia, Nokia Shanghai Bell
[29]
R1-2106846
NR UE features for RedCap
ZTE, Sanechips
[30]
R1-2106982
Views on remaining issues of RedCap
CATT
[31]
R1-2107452
Discussion on other aspects of RedCap
LG Electronics
[32]
R1-2107669
On RedCap UL transmission
Huawei, HiSilicon
[33]
R1-2107931
Discussion on the transmission of system information for RedCap
Xiaomi
[34]
R1-2108050
Considerations on 2-step RACH for RedCap
Lenovo, Motorola Mobility
[35]
RP-211574
Revised WID on support of reduced capability NR devices
Ericsson