3GPP TSG-RAN WG1 Meeting #105-e R1-21xxxxx e-Meeting, 10th – 27th May 2021 Agenda Item: 8.6.2 Title: FL summary #2 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] – [25] submitted to agenda item 8.6.2 and relevant parts of contributions [26] – [30] submitted to agenda item 8.6.3 and captures the following email discussion for the RedCap WI. [105-e-NR-R17-RedCap-05] Email discussion regarding RAN1 aspects for RAN2-led features – Shinya (DoCoMo) * 1st check point: 5/21 * 2nd check point: 5/25 * Final check: 5/27 The issues in this document are tagged and colour coded with High priority or Medium priority. In this round of the discussion, companies are requested to provide comments on the proposals and questions tagged FL3. Follow the naming convention in this example: * RedCapR2ledFLS2-v000.docx * RedCapR2ledFLS2-v001-CompanyA.docx * RedCapR2ledFLS2-v002-CompanyA-CompanyB.docx * RedCapR2ledFLS2-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 RedCapR2ledFLS2-v002-CompanyA-CompanyB.docx. * CompanyC uploads an empty file named RedCapR2ledFLS2-v003-CompanyB-CompanyC.checkout * CompanyC then has 30 minutes to upload RedCapR2ledFLS2-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-2104152), 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. 2 Definition of RedCap UE type The WID [31] 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. As stated in the above objective and also mentioned in a number of contributions [1, 3, 14, 15, 22], only one RedCap UE type will be specified in this WI. However, several contributions [12, 13, 16] propose to define more than one RedCap UE types. One contribution [12] proposes to define two UE types for FR1 and at least one UE type for FR2 with use case/RedCap UE type orientated RedCap UEs features. One contribution [16] proposes to define two stage definition/identification of UE type, i.e., initial UE type identified by a first identification (e.g. PRACH/Msg1) and later signalling (e.g. Msg5 or capability signalling) refine/change the UE type and its parameters. Question 2-1: * According to the WID, will only one RedCap UE type be defined? If not, please provide your interpretation of the WID and the reason why we need more than one RedCap UE types. Company Y/N Comments ZTE, Sanechips Y One RedCap UE type for each FR Huawei, HiSi Crystal clear that only one RedCap UE type is supported according to the WID Sharp Y vivo Y We are not sure what is the meaning of per FR2 redcap type, some clarification may be needed. LG Y According to the WID, it is clear to specify one RedCap UE type. CATT Y One UE type is enough, as clearly stated in the WID. NordicSemi Y For us, TYPE means that a set of baseline reduced capabilities is defined, one for FR1 and one for FR2. On the other hand, TYPE is not interconnected with Early indication of subset of RedCap UEs that e.g. may need MSG3 repetitions. We should not bias TYPE with early indication discussion per se. Nokia, NSB Y In our view, the WID clearly states that 1 type is defined. Whilst we support the option of the additional early indication of the #RX antennas, we feel that to honour the WID and minimize market fragmentation, we should be able to define a RedCap UE by a minimum set of mandatory capabilities (excluding #RX antennas). As such, regardless of early indication of #RX antennas, we think that early identification of RedCap UE type should associate the mandatory capabilities with the RedCap UE without requiring separate capability reporting. Ericsson Y FUTUREWEI Y This is clear from the WID. No discussion or agreement is needed in RAN1 on type, that was the point of agreeing to just one type. You are either RedCap or not. So the proposal for two RedCap Types in FR1 is out of scope. The RAN1 focus of this agenda should be on Early Identification, where we already agreed that the possibility of learning the number of RX antennas early is within the WID scope and is studied further in RAN1. If agreed there is still only one RedCap type. Intel Y NEC Y TCL Y FL2 As per chair’s guidance, it is clear from WID that only one RedCap UE type will be defined, and we don’t need to continue the discussion. Many contributions [1, 3, 4, 6, 9, 14, 15, 17, 22] discuss how to define the RedCap UE type. Several contributions propose to define the RedCap UE type based on one of the following options captured in TR38.875. Some contributions [6, 9] support Option 2 while some others [1, 3, 6] support Option 4. In addition, one contribution [17] propose that the definition of RedCap UE type only includes minimum set of capabilities that the network needs to know during initial access. One contribution [4] propose 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 [4] suggest that UE declaration of RedCap/non-RedCap is band-specific. At least for RedCap UE identification, explicit definition of RedCap UE type(s) is needed. Pending conclusions on the reduced complexity features (as described in clauses 7 and 12) and RedCap UE identification (as described in clause 11), the definition of the RedCap UE types can be based on one of: - Option 1: All the reduced capabilities recommended at the end of the RedCap study - Option 2: Only include the reduced capabilities that the network needs to know during initial access, if any. - Option 3: All the recommended reduced capabilities as well as recommended power saving features - Option 4: The corresponding minimum set of the reduced capabilities that one RedCap UE type shall mandatorily support Medium Priority Question 2-2: * Can RedCap UE type be defined based on one of the following options? If not, please provide your view how it should be defined. o Option 1: All the reduced capabilities recommended at the end of the RedCap study o Option 2: Only include the reduced capabilities that the network needs to know during initial access, if any. o Option 3: All the recommended reduced capabilities as well as recommended power saving features o Option 4: The corresponding minimum set of the reduced capabilities that one RedCap UE type shall mandatorily support Company Y/N Comments Huawei, HiSi Option 2 or 4. Spreadtrum Y From the perspective of RAN1, option 2 is enough. But from the perspective of RAN2, option 4 is preferred. LG Y We can define the RedCap UE type based on one of the options captured in TR38.875 Nokia, NSB Y Given the WID stating support for only one RedCap type, we feel that this implies option 4. Therefore, the RedCap UE type automatically identifies the mandatory capabilities, while the other capabilities are identified either through early indication (#RX antennas) or UE capability reporting. If early indication is not configured, UE capability reporting identifies both the mandatory capabilities for RedCap UE as well as other optional capabilities. FUTUREWEI Y This list of options was agreed in the study phase. No need to make further agreement now, we can later directly work on the FG design. We may not need to further focus on “type” at all since we agreed to just one type. I.e., we may have just one basic FG for RedCap (or one per FR), and then a set of other dependent FGs that handle any necessary differences with non-RedCap (e.g., since 256QAM is optional we may need capability signaling for it) or between RedCap devices (e.g., number of RX or MIMO layers). Other signaling is assumed to be as non-RedCap. TCL Option 2 or 4. Qualcomm Y CMCC Y Among the reduced capabilities, • Reduced number of UE Rx/Tx antennas: 1Rx or 2Rx; • Reduced UE bandwidth: the maximum UE bandwidth is 20 MHz for FR1 and 100 MHz for FR2; • Half-duplex FDD: HD-FDD type A with the minimum specification impact (Note that FD-FDD and TDD are also supported); • Relaxed maximum number of MIMO layers: the number of MIMO layers is naturally supported for RedCap UEs with reduced number of Tx/Rx. • Relaxed maximum modulation order: support of 256QAM in DL is optional (instead of mandatory) for an FR1 RedCap UE. We think those differentiate RedCap and non-RedCap devices can be included in the RedCap UE type definition. For example, the first two will bring some coexistence influence for RedCap UEs, and some specific gNB implement handling or specs enhancements is needed, such as early identification. In other words, the network may need to know them during initial access, therefore, the first two reduced capabilities need to be included in the definition of the RedCap UE types. While for the third one, both full-duplex and half-duplex FDD are supported for RedCap devices, and according to the TR, section 7.4.4, no coexistence issue is justified for Type A due to its faster UL-to-DL switching capability. Therefore, it doesn’t need to be included in RedCap UE type definition. For the fourth one, MIMO layer is related to the number of UE Rx/Tx antennas, once the reduced number of UE Rx/Tx antenna is included in the UE type definition, there is no need to include the number of MIMO layers. The last one, relaxed maximum modulation order will not affect the initial access procedure. So option 2 may include Reduced UE bandwidth and Reduced number of UE Rx/Tx antennas. Option 4 may include above all reduced capabilities with mandatory supported value. Both option2 and option4 can be supported, and slightly prefer option2. Samsung Y Capabilities should be discussed one by one. Only essential minimum capabilities should be defined. China Telecom Y We prefer Option 2 or Option 4. ZTE, Sanechips Option 4 FL3 Please provide your view if not yet provided Several contributions [1, 3, 9, 14, 15, 17, 22] discuss the capabilities included in the definition of the RedCap UE type. Many of them [1, 3, 14, 15, 17, 22] suggest that Maximum UE bandwidth (i.e., 20MHz for FR1 and 100MHz for FR2) is included. One contribution [1] suggests that the capabilities of minimum number of Rx branches (1Rx only), maximum number of DL MIMO layers (1 for 1 Rx, 2 for 2Rx), maximum modulation order (64QAM), duplex operation (HD-FDD and TDD) are also included. One contribution [9] suggests that the capability of minimum number of Rx branches of 1Rx or 2Rx is included. In addition, One contribution [17] suggests that the capability of highest MCS is included. Medium Priority Question 2-3: * Which reduced capability should be included in the definition of RedCap UE type? Company Comments Huawei, HiSi UE max bandwidth is key differentiation factor between RedCap UEs and non-RedCap UEs, in both spec and implementation wise. Spreadtrum Maximum UE bandwidth (i.e., 20MHz for FR1 and 100MHz for FR2) and the minimum number of Rx branches (1Rx only) should be included at least. As Tx-Rx switching time for HD-FDD is under discussion in RAN4, the output may impact whether the current timeline of initial access still works for HD-FDD. The necessity of including HD-FDD depends on the output of RAN4. LG The maximum UE bandwidth should be included. Nokia, NSB Assuming an option 4 based definition of the “1 RedCap type”, we feel the minimum set of capabilities include: BW support Minimum #RX antennas support (additional antenna support can be indicated by the UE Capability and/or early indication) 64 QAM support (256 support can be indicated in the UE Capability report) HD-FDD should be assumed until UE indication related to this capability in the UE Capability report FUTUREWEI Suggest we don’t discuss “type” any more. If needed, we can start to discuss the RedCap FG structure and the contents of the basic FG for FR1 and FR2. TCL The maximum UE bandwidth and the duplex operation should be included. Qualcomm The details of UE capability/feature specification for RedCap devices can be discussed at the end of this WI, which should include both L1 and L2. CMCC According to agreements in RAN1#103e, 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, and we also think reduced number of Rx branches can also be included in the type definition since it helps gNB’s implementation during initial access. Samsung Maximum UE bandwidth should be included. China Telecom We think the UE complexity reduction features in RedCap WID should be included in the definition of RedCap UE type, at least maximum UE bandwidth and minimum number of Rx branches. ZTE, Sanechips At least maximum UE bandwidth FL3 Please provide your view if not yet provided One contribution [11] propose that discussion of definition of RedCap UE type in RAN1 should wait until after progress is made in RAN2 and RAN1 has decision on early identification. Medium Priority Question 2-4: * Should RAN1 wait the discussion of definition of RedCap UE type until some progress is made in RAN2 and RAN1 has decision on early identification? If yes, please provide your view when we can resume RAN1 discussion. Company Y/N Comments ZTE, Sanechips Y Resume at least RAN1 has decision on which capabilities should be early identified Huawei, HiSi N RAN1 is also tasked as per WID for discussion. Actually, RAN2 is expecting RAN1 input Agreement in RAN2#111-e: The number of device types should be minimised, to reduce market fragmentation, and introduced only where essential to control UE accesses and differentiate them from legacy R15/R16 and non-Redcap R17 UEs, (e.g. number of Tx/Rx antennas, maximum supportable BW, etc.). The exact composition of the set of L1 capabilities of the device type can be discussed by RAN1 Sharp N We propose to discuss it first in RAN1. We think this RAN1 decision does not limit RAN2 discussion. If there is any issue identified by RAN2, we can come back. vivo Y We prefer to see some RAN2 progress before RAN1 discussion, to avoid duplicated/redundant effort. LG Both RAN1 and RAN2 could discuss definition of RedCap UE type with their own expertise. CATT RAN1 can discuss definition of RedCap type parallel with RAN2. NordicSemi N RAN1 has good competence about which RAN1 capabilities shall be reduced, this is what in the end makes RedCap UE type. Nokia, NSB N RAN1 can at least provide recommendations to RAN2 Ericsson N We think it could be beneficial for RAN1 to give guidance to RAN2 on what RedCap UE L1 capabilities are not allowed for RedCap UEs, and vice-versa. FUTUREWEI Suggest we focus on Early Identification this meeting in RAN1. Intel Explicitly precluding discussions in RAN1 on UE type definition may not be necessary at this point. NEC N As mentioned by Huawei, RAN1 can discuss the set of L1 capabilities. FL2 As per chair’s guidance in GTW session, discussion topics in Section 2 can be deprioritized in this RAN1 meeting. The priority of Question 2-4 is changed to medium. But companies are welcomed to provide their view if not yet provided. Qualcomm N Thanks for the update of FL. We think RAN1 can discuss early indication of RedCap UE type, which is related to the support of BW reduction in L1. CMCC N L1 capabilities can be discussed in RAN1. vivo Y Huawei, HiSi Y As commented during GTW that RAN1 input is still useful. I think at least we can agree on the Max UE bandwidth is included. Other capabilities can be further discussed. We don’t need to complete all details altogether. This also helps RAN2 progress of signaling design. Samsung N RAN1 and RAN2 work can proceed in parallel while sharing the progress. Xiaomi We share the same view with CMCC, HW and Samsung, RAN1 still can continue the discussion on the L1 capabilities. As commented by HW, at least max UE bandwidth can be included in the UE type definition. Spreadtrum Suggest focusing on early indication in this meeting. China Telecom N We think RAN1 can start to discuss the definition of RedCap UE type and other aspects related to RAN1, with taking RedCap WI progress into consideration. Nokia, NSB N Share similar view to Qualcomm/Samsung/China Telecom Ericsson Similar view as others above. A few contributions [1, 6] discuss constraining of reduced capabilities. One contribution [1] proposes to achieve the functionality by disallowing some UE capabilities for RedCap and non-RedCap UEs, respectively, while the detailed signalling is up to RAN2. One contribution [6] proposes to deter to RAN2. Medium Priority Question 2-5: * Should RAN1 discuss constraining of reduced capabilities? If yes, please provide your view what should be discussed in RAN1. Company Y/N Comments ZTE, Sanechips N Can be handled in RAN2 only Huawei, HiSi Rather than “should”, Can may be more proper RAN1 can discuss but we currently don’t see what needs to be constrained according to the WID, except for those explicitly given by WID, i.e. CA/DC related capabilities and a larger BW than the agreed Max UE bandwidth. Can review this when more features are clear or RAN1 to have a high level guidance. Sharp We should wait until Redcap functionalities become stable. vivo N It should be discussed in RAN2. Spreadtrum N It is up to RAN2. LG RAN1 could defer discussion on such constraint. Whether to discuss such constraint in RAN2 seems up to RAN2. CATT N It should be discussed by RAN2. NordicSemi Y RAN1 reduced capabilities should be discussed in RAN1. Nokia, NSB Y Support the constraining of certain capabilities as this will: (a) minimise market fragmentation (b) simplify network and specification support Ericsson N For other aspects of this WI objective than to define the physical layer aspects of the RedCap UE type, RAN1 can assume that RAN2 will lead the work. FUTUREWEI Mostly N The WID is clear that: “changes to capability signalling are specified only if necessary.” This means that we focus only on necessary changes to signaling, since by default whatever can be supported by non-RedCap can also be supported by RedCap. The WID only excludes “carrier aggregation, dual connectivity and wider bandwidths”. We specifically do not need to revisit each and every FG for Rel-15/16 and rediscuss to see whether RedCap supports it or not. This not only reduces our work, but also allows for product differentiation and avoids 3GPP making marketing decisions. It also avoids “he said/ she said” sort of discussions where one company says they plan to do something in their RedCap device and another (who doesn’t plan to implement it) says they do not like it as it may be too expensive. Our focus should therefore be on areas therefore related to the agreed reduced capabilities, as well as any truly necessary changes to existing capabilities (which is not clear now). For example, if there are big spec changes to get the FG to work then it may have to be deferred to a later release. Intel This can be discussed later when UE capabilities for RedCap are discussed if anything particular in RAN1 needs to be considered. Otherwise, this could be primarily addressed by RAN2. OPPO N The reduced capabilities can be addressed in RAN2. FL2 As per chair’s guidance in GTW session, discussion topics in Section 2 can be deprioritized in this RAN1 meeting. The priority of Question 2-5 is changed to medium. But companies are welcomed to provide their view if not yet provided. Qualcomm N Thanks for the update of FL. We think constraining of reduced capabilities is in the scope of upper layer discussion. CMCC N It is better handled by RAN2. vivo It should be discussed in RAN2. Samsung N This can be discussed after the functionalities are further defined. RAN2 can handle this task. China Telecom N We agree with that constraining of reduced capabilities is preferred to be handled in RAN2. Nokia, NSB Given guidance in GTW, this should be discussed by RAN2 Ericsson This topic should be discussed in RAN2 3 Early indication of RedCap UEs The WID [31] 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] Note that potential early indication of the number of Rx branches, which is discussed in many contributions [3, 4, 5, 6, 7, 8, 9, 11, 12, 13, 14, 17, 21, 25], will be discussed in AI8.4.1.2. Many contributions [1, 2, 3, 4, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 18, 20, 21, 22, 23, 24, 25] support the early indication of RedCap UEs in Msg1, and some of them [1, 3, 6, 7, 20, 23] also suggest that the indication is configurable (e.g., via SIB1 [3]). However, there are divergent views on the detailed solution to differentiate RedCap UEs from non-RedCap UEs, such as via separate initial UL BWP [9, 11, 14, 15, 22], separate PRACH resource [3, 7, 9, 14, 25] or PRACH preamble partitioning [1, 3, 7, 10, 11, 14, 15, 22], as it is related to the discussion whether initial UL BWP for RedCap UEs is the same as that for non-RedCap UEs or not in AI8.6.1.1. A number of contributions [1, 3, 8, 9, 18, 21] support the early indication of RedCap UEs in Msg3, and one of them [1] also suggests that it is up to RAN2 whether the indication is configurable or not. Also, a number of contributions [1, 3, 8, 9, 18, 21] suggest that the indication is configurable between Msg1 and Msg3 (and also MsgA [18]). FL1 High Priority Proposal 3-1: * For 4-step RACH, support the early indication of RedCap UEs at least in Msg1. o FFS whether/how to support early indication of RedCap UEs in Msg3 in addition to Msg1. o FFS detail, e.g.: * separate initial UL BWP * separate PRACH resource * PRACH preamble partitioning Company Y/N Comments ZTE, Sanechips Y Huawei, HiSi We think we can first agree on the configurability of early identification then to see whether to support one of Msg1 and Msg3, or both. Sharp N It should be noted that, early identification of RedCap UE type during Msg1 may cause some problems, such as the reduction of the PRACH user capability (for both RedCap and non-RedCap UEs) and the increase of UL overhead, due to the further separation of PRACH resources. In some scenarios, Msg1-based indication is not needed. For example, the RedCap UEs and non-RedCap UEs share the same initial UL/DL BWP, and the gNB does not separately configure DL parameters (e.g., different PDCCH search spaces) depending on the UE type in the Msg2/Msg4 transmissions, and moreover the gNB does not separately configure UL parameters (e.g., frequency hopping and enabling CE) depending on the UE type in the Msg3 transmission. Therefore, it is more reasonable to allow Msg1-based early identification configurable by the gNB depending on the scenarios, while keeping Msg3-based early identification as a mandatory function. vivo N Specifying duplicated functionality (MSG1 and MSG3 based early indication) is highly undesirable, as it causes additional implementation burden and fragmentation in the real deployment. Therefore, we shall make a down-selection between MSG1 and MSG. Spreadtrum Y We agree with the proposal with some modification. o FFS whether/how to support early indication of RedCap UEs in Msg3 in addition to Msg1 if early indication in Msg1 is not configured. LG Y CATT Y, mostly For the main bullet, maybe ‘in Msg1’ can be changed to ‘during Msg1’ to make it clearer. For the sub-bullets, we think identification in Msg3 only achieves very small gain but brings unnecessary specification impact. Prefer not to have the 1st FFS, or as suggested by vivo, making down-selection between Msg1 and Msg3. NordicSemi If separate initial UL BWP is configured for RedCap UEs, then it is MSG1. If separate initial UL BWP is not configured, then MSG3 can be considered, if there is some benefit seen from network point of view. Our understanding has been that network would like to know how to schedule MSG3 and for that early indication in MSG1 is needed. Nokia, NSB Y We support early indication in Msg1. For the 1st FFS, we see no real value in the support of early indication using Msg3. Ericsson Y, with modifications It should be clarified that Msg1 indication is configurable. We can accept the following proposal as a working assumption. Whether the working assumption can be confirmed will depend on the outcome of the Msg3 discussion (which will largely take place in RAN2). * Working assumption: For 4-step RACH, support the early indication of RedCap UEs at least in Msg1. o Note: the early indication in Msg1 is configurable. o FFS whether/how to support early indication of RedCap UEs in Msg3 in addition to Msg1. o FFS detail, e.g.: * separate initial UL BWP * separate PRACH resource * PRACH preamble partitioning FUTUREWEI Y Similar view as Nokia Intel Y Same view as Nokia and FTW. NEC Y We are fine with Ericsson’s version. OPPO Y We support the early indication in Msg1, including configurable or not. The earlier indication in Msg3 can be applied if Msg1 is not configured. TCL Y FL2 Based on the input from companies and the discussion in the GTW session, the proposal is updated as follows: * Proposal is changed to Proposed working assumption based on the above comment from Ericsson * “indication” is adopted based on the statement in WID * FFS is put in the 1st sub-sub-bullet * Examples in the last sub-bullet are deleted based on the comment from Qualcomm in the GTW session High Priority Proposed working assumption 3-1: * For 4-step RACH, support the early indication of RedCap UEs at least in Msg1. o The early indication in Msg 1 can be configurd to be enabled/disabled * FFS How to support enable/disable the early indication o FFS whether/how to support early indication of RedCap UEs in Msg3 in addition to Msg1 * If supported, the intention is to configure to use one of them o FFS details how to support the indication, e.g.: * separate initial UL BWP * separate PRACH resource * PRACH preamble partitioning Qualcomm Y We support the updated working assumption. CMCC Y Msg.1 can provide more benefit than Msg.3. However, indication in Msg1 by separate PRACH resources(when the same initial UL BWP is shared) can result in potential reduction in PRACH user capacity, which may limit the practical application of the scheme, so we prefer to support early indication in Msg1 and Msg3, and gNB can configure which one is used. NEC Y We support the updated proposal 3-1. vivo N As discussed online, we have strong concern on further consideration of MSG3 based early indication in addition to MSG1 due to duplicated functionality, and much less benefit of MSG3, and UE implementation burdens, and such concern was shared by majority of companies (11 if we remember correctly). We appreciate if FL can take such aspect into consideration for the proposal. To answer CMCC’s question, yes PRACH resource congestion might be a concern in some scenarios, but that is exactly the reason why majority of companies support the configurability of separate initial UL BWP for redcap UEs, and if such case, MSG 1 based early indication is automatically given, there is no need to support MSG3 based indication additionally. Huawei, HiSi Y Samsung The overhead for configuring PRACH resources or partitioning of ROs can be substantial and indication in Msg3 would be preferred. Indication in Msg1 would be beneficial for resource configuration of Msg2/3/4 for RedCap and non-RedCap UEs, however if needed existing schemes to improve DL coverage for RedCap UEs during initial access, such as TB scaling, can be used. Depending on the cell load and UE coverage it is useful for the network to have the flexibility to configure the indication in Msg1 or in Msg3. We support a configurable indication in Msg1 and in Msg3. Xiaomi Y CATT Y, but Prefer not to have discussion of Msg3. No surprising benefit is observed on top of indication by Msg1. Minor revision: o The early indication in Msg1 can be configured to be enabled/disabled Panasonic Y We support the working assumption 3-1. Regarding the 2nd FFS point, the complex part of the discussion (how to indicate RedCap UE in current Msg3 payload using reserved bit and so on) is RAN2. RAN1 may determine the preference of Msg3 indication but the final decision should be RAN2. Our view the gain to use it from Msg3 is very limited as only useful until UE capability is known. Therefore, our view is not required to be supported in Msg3. TCL Y Spreadtrum We prefer the version captured in the Chair’s notes: * For 4-step RACH, support the early indication/identification of RedCap UEs at least in Msg1. o The early indication in Msg 1 can be configurd to be enabled/disabled * How to support enable/disable the early indication o FFS whether/how to support early indication of RedCap UEs in Msg3 in addition to Msg1 * If supported, the intention is to configure to use one of them o FFS details, e.g.: * separate initial UL BWP * separate PRACH resource * PRACH preamble partitioning China Telecom We suggest to keep the last FFS details in Proposed working assumption 3-1 for further discussion. Lenovo, Motorola Mobility Y We support this working assumption. Whether to support early indication in Msg3 can be decided in RAN2. ZTE, Sanechips Y Whether/how to support early indication of RedCap UEs in Msg3 can be determined in RAN2 Nokia, NSB Y Generally support the Proposed WA. Minor comments: (1) Agreed with typo corrections from CATT (2) We would like to reiterate our view, that we see “additional” support of Msg3 as unnecessary. FUTUREWEI2 Y If it is a working assumption, Msg 3 should be removed. If an agreement, can keep an FFS on Msg 3. LG We prefer to keep the last FFS details in Proposed working assumption 3-1. The three options on Msg1 are useful for future discussion. OPPO Y Ericsson Y, with modifications We thank the FL for updating the proposal. Regarding the FFS on Msg3 indication, whether Msg3 indication is configurable (i.e., can be enabled/disabled) or non-configurable (i.e., always present) will depend on the solution that RAN2 would introduce to carry out Msg3 indication. For example, if RAN2 agrees to use a RedCap-specific CCCH LCID (similar to how LTE Cat-0 is indicated), which does not consume any additional bits in Msg3, then it is reasonable to always provide the Msg3 indication, regardless of whether Msg1 indication is enabled or not. Furthermore, when the UE comes from RRC_INACTIVE, the Msg3 indication comes “for free” since gNB can determine the full UE capabilities from the UE context retrieved using the I-RNTI in Msg3. Based on these considerations, we propose the following update. High Priority Proposed working assumption 3-1: * For 4-step RACH, support the early indication of RedCap UEs at least in Msg1. o The early indication in Msg 1 can be configured to be enabled/disabled * FFS How to support enable/disable the early indication o FFS whether/how to support early indication of RedCap UEs in Msg3 in addition to Msg1 * If supported, the intention is to configure to use one of them o FFS details how to support the indication, e.g.: * separate initial UL BWP * separate PRACH resource * PRACH preamble partitioning Regarding the concerns raised by some companies on the usefulness of Msg3 indication, in our view, there can be scenarios where Msg1 indication cannot be enabled, e.g. because it would lead to excessive PRACH partitioning, for example, due to enabling of another feature (CovEnh/SDT/slicing/…) that also needs Msg1 indication. In these scenarios, it can be still beneficial to support Msg3 indication due to the following reasons: * If supported, to disable PUCCH FH in response to Msg4 for RedCap UEs in order to minimize PUSCH resource fragmentation for non-RedCap UEs. * To have the possibility of RRC rejection of RedCap UEs in Msg4, and/or to have prioritization of non-RedCap UEs compared to Redcap UEs, e.g., in contention resolution. Note that these possibilities are also listed by RAN2 in TR 38.875 (Section 11.1.1). Sharp Y, with modifications We agree with CMCC’s comment. If Msg1 is not configured for early indication, Msg3 can be used. In addition, “If supported, the intention is to configure to use one of them” can be removed since Msg3 configurability or format should be discussed in RAN2. Intel Similar view as vivo – prefer to remove the bullets for Msg3. For the potential benefits mentioned by Ericsson, - for the first motivation, separate initial UL BWPs would be the way to go anyway for this use-case (we do not see a need to support UL BWP larger than max RedCap UE BW for a RedCap UE). Then, if UL BWP is separate, anyway the UE can be identified; and - for the second motivation, this can be up to RAN2 and they can decide to introduce additional solutions (in any case, solution for indication during Msg3 transmission should be discussed in RAN2). On top of this, the working assumption leaves room for any further adjustments if needed.. FL3 Based on the comment provided so far, the proposal is updated as follows: • Msg3 part is divided to a separate proposal, as there are divergent views on Msg3 while majority support of Msg1 at least > The sub-bullet is removed based on the comment from Ericsson • Typos are corrected • The last sub-bullet is returned back to original one based on the request from several companies. Moderator believes it is not a showstopper. High Priority Proposed working assumption 3-1: * 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 whether/how to support early indication of RedCap UEs in Msg3 in addition to Msg1 * If supported, the intention is to configure to use one of them o FFS details e.g.: * separate initial UL BWP * separate PRACH resource * PRACH preamble partitioning High Priority Proposal 3-1a: * For 4-step RACH, FFS whether/how to support early indication of RedCap UEs in Msg3 in addition to Msg1 o If supported, the intention is to configure to use one of them Please provide your view on the updated Proposed working assumption 3-1 and High Priority Proposal 3-1a, respectively. A few contributions [17, 18, 23] support the early indication of RedCap UEs in MsgA and one of them [23] also suggests that the indication is configurable. One contribution [1] suggest that RAN1 discusses whether coverage recovery for MsgB is necessary or not as it should be clarified to select whether the early indication is done in the preamble part or the PUSCH part of MsgA. Also, one contribution [1] suggest that the discussion for 4-step RACH is prioritized. Medium Priority Question 3-2: * Do we support 2-step RACH for RedCap UEs? If yes, please provide your view which aspects we should study/specify dedicated to 2-step RACH (i.e., delta from 4-step RACH). Company Y/N Comments LG Y We are generally fine to support 2-step RACH for RedCap UEs. However, how to support 2-step RACH for RedCap UEs could be discussed later after RAN2 makes decision on 4-step RACH. Nokia, NSB Y Details can be discussed later, e.g., based on whether a separate initial UL BWP is supported for RedCap UEs. FUTUREWEI 2-step RACH should be examined only after the issues for 4-step RACH are resolved as time permits. OPPO Y The aspects can be discussed in RAN2. Qualcomm Y 2-step RACH can be supported as an optional UE feature. It is up to NW to configure the 2-step RACH resources and RACH type selection procedure for RedCap devices. In addition, 2-step RACH based SDT can be supported by RedCap devices for power saving and signaling overhead reduction. Panasonic - The discussion for 4-step RACH should be prioritized as RedCap UEs would not be latency sensitive usage. TCL Y We support 2-step RACH for Redcap UES. But 2-step RACH should be a low priority. China Telecom We are open to discuss 2-step RACH for RedCap UEs. Lenovo, Motorola Mobility Y In our view, the aspects of e.g., early identification in MsgA preamble or MsgA PUSCH, preamble to PRU mapping, etc. should be studied. ZTE, Sanechips Y Details can be discussed later FL3 Please provide your view if not yet provided A number of contributions [6, 14, 17, 21, 27] suggest that CovEnh UE is taken into account for the early indication. One contribution [23] proposes that UE is identified as RedCap during UE capability reporting If early indication is not configured. Medium Priority Question 3-3: * Do we need to take CovEnh UE into account for the early indication of RedCap UEs? If yes, please provide your view how to proceed the specification work (e.g., RedCap WI and CovEnh WI can discuss it separately, or only one of them should discuss it with taking the other’s aspect into account). Company Y/N Comments Spreadtrum Y As RACH partitioning is being proposed in several Rel-17 WIs (RedCap, Coverage enhancements, Slicing, SDT), RAN2 has decide to open a common AI for RACH partitioning. In our opinion, RAN1 should take CovEnh WI’s aspect into account for RedCap WI. LG Y We are fine to take CovEnh UE into account for the early indication of RedCap UEs. In our view, RedCap WI can discuss the early indication of RedCap UEs taking into account the aspect of CovEnh WI, noting the following note in RedCap WID: • Uplink coverage enhancement solutions specified in the NR Coverage Enhancement WI (NR_cov_enh) shall be assumed to be available also to RedCap UEs by default (with small modifications for RedCap UEs if found necessary). Nokia, NSB N We only need to consider differentiation between RedCap UE and non RedCap UE in the RedCap WI. Any further aspects related to coverage enhancement capability should be considered in the CovEnh WI. FUTUREWEI We can use / (modify, if necessary) the features for UL coverage enhancement as needed. OPPO Y It is FFS which features for UL coverage enhancement should be available also to RedCap UE with and without modification. Qualcomm If msg1 based early indication is supported for RedCap devices, NW can derive the TA/RTT information from msg1, which is helpful for coverage recovery of msg2/msg3. By default, RedCap UE is expected to re-use the R17 solution for CovEnh, and it is not necessary to further differentiate whether or not RedCap UE supports CovEnh on UL. Samsung N The early indication is to differentiate RedCap UEs from non-RedCap UEs. Features specified in CovEnh can be available for RedCap UEs. Panasonic Y RedCap WI and CovEnh WI can discuss it separately for now for early identification discussion. At some point of time, RedCap WI takes into account the decision in CovEnh WI especially "Type A PUSCH repetitions for Msg3" China Telecom Y We think it needs to take CovEnh UE into account for the early indication of RedCap UEs. ZTE, Sanechips Y We want to clarify whether all RedCap UEs need to do Msg3 coverage enhancement. If only partial RedCap UEs need Msg3 coverage enhancement, early identification in Msg1 should be considered. FL3 Please provide your view if not yet provided 4 System information indication The WID [31] 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 [1, 14, 18] suggest that this topic is not considered in RAN1. One contribution [6] suggests that RAN1 can try to reach high level consensus on signaling design and inform the conclusions to RAN2 for discussion/decision if RAN1 discusses this topic ahead of RAN2. Also, another contribution [13] suggests that RAN1 can study and make down-selection for the options of system information indication with considering RAN2 further progress. FL1 High Priority Question 4-1: * Should RAN1 discuss system information indication for access control? If yes, please provide your view what should be discussed in RAN1. Company Y/N Comments ZTE, Sanechips Y Early indication of access control before SIB1 should be discussed in RAN1. Consider to carry early indication of access control in DCI scheduling SIB1 by using the reserved bit(s). Huawei, HiSi Y RAN1 is explicitly tasked as per WID. Early access control is good for power consumption, and there is only 1 spare bit in MIB. Some companies propose to restrict the accessing in DCI scheduling SIB1, which is also related to RAN1 and can be informed to RAN2 when necessary. Sharp N We can leave it up to RAN2. vivo N This is clearly an RAN2 topic, RAN1 discuss can be triggered by RAN2, if needed. LG Y One of the solutions is that DCI scheduling SIB1 includes system information indication. The solution based on DCI could be discussed in RAN1 e.g. after high-level discussion in RAN2. Furthermore, the system information indication involves the performance issue of 1 Rx RedCap UEs, which may also have dependency on the NR operating band to which the RedCap is trying to access. All this aspects can better be discussed in RAN1. CATT N Tend to discuss in RAN2. It is a RAN2 leading feature. If RAN1 discuss access control ahead of RAN2, RAN1 should not reach detailed information design without RAN2’s confirm, but can try to reach high level consensus (e.g. pros and cons for different design) and inform the conclusions to RAN2 for discussion/decision. NordicSemi N This is in RAN2 competence Nokia, NSB Y Yes – we feel that RAN1 should discuss the options (e.g. using SIB1 DCI reserved bits) and at least provide recommendations to RAN2. Ericsson N FUTUREWEI RAN2 is the lead WG, if we discuss here it should focus on some more specific RAN1 solution Intel N Should be left to RAN2. NEC N OPPO N This is mainly RAN2 issue. We can further check whether there is RAN1 impacts based on RAN2’s conclusion. FL2 Please provide your view if not yet provided Qualcomm Access control is (mainly) in the scope of RAN2. However, RAN1 can study the PHY aspects of SI transmission after the decision/agreement on access control is made by RAN2. CMCC Y RAN1 can discuss whether earlier indication for access control is needed before SIB1, if the conclusion is no, then it can be left to RAN2. Samsung N RAN2 can discuss this. Xiaomi Y We think the option of SIB-DCI based indication has RAN1 impact and we can discuss it in RAN1 Panasonic N This can be determined purely within RAN2 and no impact to RAN1 specification. Spreadtrum This topic is highly related to both RAN1 and RAN2 groups. A joint RAN1&RAN2 GTW meeting or e-mail discussion is highly recommended to avoid misunderstanding between two WGs and unnecessary back and forth. China Telecom N We agree with that it leaves for RAN2 to discuss system information indication for access control. Lenovo, Motorola Mobility N Should be up to RAN2 decision. Nokia, NSB Y Similar view to Xiaomi Ericsson N This is a RAN2 issue. FL3 Based on the comments provided so far, following proposal is made: High Priority Proposal 4-1: * For system information indication of access control for RedCap UEs, o FFS: Whether it is needed before SIB1 o FFS: Indication in DCI scheduling SIB1 o FFS: Performance dependency of RedCap UEs with 1Rx branch on the operating band Please provide your view on each of FFS. Especially, proponent companies are encouraged to provide the motivation for better understanding among companies. A number of contributions [3, 7, 9, 10, 17, 19, 23, 29] discuss what kind of system information indication is necessary. Several contributions [3, 9, 19, 23] propose the indication whether NW supports RedCap UEs accessing or not. Some other contributions [3, 7, 9, 10, 17, 19] propose the access control specific to RedCap UEs with 1Rx or 2Rx. Another contribution [9] suggests that the NW broadcasts the priority level of RedCap devices that to be served. Another contribution [17] propose a scheme restricting RedCap UEs with poor channel conditions from accessing the network. Another contribution [29] suggests that gNB can deprioritize RedCap UEs e.g. with 1-Rx capability by configuring lower RACH opportunity. A number of contributions [3, 7, 9, 10, 11, 13, 19, 20, 23, 30] discuss how to indicate the system information as follows: • PBCH: [9], [20] • DCI associated with SIB1: [3, 7, 9, 11, 13, 19, 20] • SIB1: [9, 10, 13, 30] > Reuse existing SIB1 to incorporate the new system information for RedCap [30] > When the existing SIB1 is extended to incorporate the new IE for RedCap, consider the following options to improve the power efficiency during system information updating [30] * 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 • RA procedure: [9] • Explicit indication in SI: [23] 5 Necessary updates of UE capabilities and RRC parameters The WID [31] 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] A few contributions [22, 26, 27, 28] discuss whether/how current UE capabilities and RRC parameters should be updated. One contribution [28] suggests that RAN1 discuss which features are supported to satisfy the basic requirements (latency, reliability, complexity and for longer battery life) for RedCap UE, and remaining features are not supported by default. However, there would be another interpretation that current definition of mandatory/optional support of UE capabilities in TS38.306 is reused for RedCap UEs by default unless any update is identified, e.g., maxNumberMIMO-LayersPDSCH as discussed below. One contribution [26] suggests that at least for the features that are mandatory without capability signalling for non-RedCap UEs, the RedCap UEs support mandatorily with the same value. Medium Priority Question 5-1: * Which of the following alternatives should we assume to discuss the necessary updates of UE capabilities? o Alt-1: Identify the UE capabilities to satisfy the basic requirements for RedCap UE, where remaining UE capabilities are not supported by default o Alt-2: Current definition of mandatory/optional support of UE capabilities in TS38.306 is reused for RedCap UEs by default unless any update is identified o Alt-3: Any others (please provide the detail assumption if you prefer this) Company Comments Spreadtrum Alt-1. We suggest starting which capabilities should be supported by RedCap UE earlier as there are only 3 meetings left in RAN1 and 2 meetings left in RAN2. LG We slightly prefer Alt-2. But, both Alt-1 and Alt-2 would work. Nokia, NSB. To be consistent with our response to 2-2 (Option 4), we prefer Alt-1. FUTUREWEI The WID is clear that: “changes to capability signalling are specified only if necessary.” This means that we focus only on necessary changes to signaling, since by default whatever can be supported by non-RedCap can also be supported by RedCap. We therefore do not agree to Alt 1 as it is against the WID. The WID only excludes “carrier aggregation, dual connectivity and wider bandwidths”. We specifically do not need to revisit each and every FG for Rel-15/16 and rediscuss to see whether RedCap supports it or not. This not only reduces our work, but also allows for product differentiation and avoids 3GPP making marketing decisions. It also avoids “he said/ she said” sort of discussions where one company says they plan to do something in their RedCap device and another (who doesn’t plan to implement it) says they do not like it as it may be too expensive. We can and should spend our time on whether some FGs should be mandatory for RedCap, or any necessary modifications. Companies may need time till next meeting to suggest e.g. mandatory sets of features for RedCap. Qualcomm In general, we agree with the comments of Futurewei. Samsung Agree with Futurewei Panasonic We support the view expressed by FUTUREWEI. ZTE, Sanechips Alt-1 Regarding “The existing UE capability framework is used; changes to capability signalling are specified only if necessary”, we don’t think it means features should be supported by default. Considering that the lower capability of RedCap UEs, the motivation to support the features beyond the basic requirements is not clear. Remaining UE capabilities are not supported by default. Whether to support should be discussed case by case. OPPO Alt-2 is fine for us. FL3 Please provide your view if not yet provided Following capabilities are pointed out by some contributions that update is necessary: • maxNumberMIMO-LayersPDSCH: Optional [26], add a new value [22] • pdsch-256QAM-FR1: Optional [26] • csi-RS-RLM: Optional [26] • oneFL-DMRS-TwoAdditionalDMRS-UL: Not necessary [26] • spatialBundlingHARQ-ACK: Not necessary [26] • additionalActiveTCI-StatePDCCH/additionalActiveSpatialRelationPUCCH: Optional [26] • Capabilities related to the carrier aggregation, dual connectivity: do not support [26] • Capabilities related to power saving: FFS whether RedCap UEs mandatorily support [26][27] • Capabilities related to the processing timeline: Use the same value as the one for non-RedCap UEs [26] One contribution [27] mentions the cost of RedCap UE may be further reduced by reducing the maximum value of parameters. 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 [19] > If CORESET0 can be shared by REDCAP UEs and normal 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) [19] > REDCAP specific RACH resources can be configured for gNB to transmit on-demand SI message References [1] R1-2104183 RAN1 aspects for RAN2-led features for RedCap Ericsson [2] R1-2104191 Discussion on the Identification of RedCap UEs FUTUREWEI [3] R1-2104287 RAN1 aspects of RedCap UE type and identification Huawei, HiSilicon [4] R1-2104369 Higher layer support for RedCap vivo, Guangdong Genius [5] R1-2104431 Discussion on early indication for RedCap UE Spreadtrum Communications [6] R1-2104530 Discussion on higher layer support of RedCap CATT [7] R1-2104546 Higher layer support of Reduced Capability NR Devices Nokia, Nokia Shanghai Bell [8] R1-2104562 Design consideration for Higher layer support of RedCap Sierra Wireless, S.A. [9] R1-2104620 Discussion on higher layer support of RedCap UE CMCC [10] R1-2104681 Cross Layer Design Considerations for RedCap Device Qualcomm Incorporated [11] R1-2104714 Higher layer support of Reduced Capability NR devices ZTE, Sanechips [12] R1-2104785 Mechanism in higher&PHY layer for Reduced Capability NR Devices OPPO [13] R1-2104853 Discussion on RAN1 aspects for RAN2-led features for RedCap China Telecom [14] R1-2104915 On RedCap UE types: Definition, access control, and identification Intel Corporation [15] R1-2105115 On Higher Layer Support of Redcap Devices Apple [16] R1-2105173 UE identification of redcap devices Sony [17] R1-2105220 UE identification and access control for RedCap Lenovo, Motorola Mobility [18] R1-2105320 RAN1 aspects for RAN2-led features for RedCap Samsung [19] R1-2105432 RAN1 aspects for RAN2-led features for RedCap LG Electronics [20] R1-2105571 Discussion on the early indication and access control Xiaomi [21] R1-2105638 RAN1 aspects for RAN2-led features for RedCap Sharp [22] R1-2105707 Discussion on RAN1 aspects for RAN2-led features for RedCap NTT DOCOMO, INC. [23] R1-2105749 Identification and restriction of RedCap UEs InterDigital, Inc. [24] R1-2105876 Discussion on higher layer support of Redcap UE WILUS Inc. [25] R1-2105885 On RedCap UE early identification Nordic Semiconductor ASA [26] R1-2104370 Discussion on reduced capability signaling vivo, Guangdong Genius [27] R1-2104531 Views on remaining issues of RedCap CATT [28] R1-2104715 NR UE features for RedCap ZTE, Sanechips [29] R1-2105433 Discussion on other aspects of RedCap LG Electronics [30] R1-2105572 Discussion on the transmission of system information for RedCap Xiaomi [31] RP-210918 Revised WID on support of reduced capability NR devices Nokia, Ericsson