3GPP TSG-RAN WG1 Meeting #105-e R1-21xxxxx e-Meeting, 10th 每 27th May 2021 Agenda Item: 8.6.2 Title: FL summary #3 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 FL4. Follow the naming convention in this example: * RedCapR2ledFLS3-v000.docx * RedCapR2ledFLS3-v001-CompanyA.docx * RedCapR2ledFLS3-v002-CompanyA-CompanyB.docx * RedCapR2ledFLS3-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 RedCapR2ledFLS3-v002-CompanyA-CompanyB.docx. * CompanyC uploads an empty file named RedCapR2ledFLS3-v003-CompanyB-CompanyC.checkout * CompanyC then has 30 minutes to upload RedCapR2ledFLS3-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 vivo Option 2 or 4 Xiaomi Option 2 Lenovo, Motorola Mobility Opt.4 Ericsson Y Our preference is Option 4. We are also fine with the down-selection of Option 2 and Option 4 in RAN1#105-e. Further down-selection can be made in the next RAN1 meeting. We are OK with the current definition of Option 4. However, the following update to Option 4 can alternatively be considered for more clarity: The corresponding minimum set of the reduced capabilities that the network can assume before the network receives the UE capability signalling from the UE one RedCap UE type shall mandatorily support. NordicSemi Option 4 FL4 According to the comments provided so far, all companies think that RedCap UE type can be defined based on one of the listed options. Most of them support either Option 2 or 4. Also, as commented by FL4 in Medium Priority Question 2-4, it seems RAN2 is waiting for RAN1 progress on this topic. Therefore, we can try to agree following proposal with clarification from Ericsson. Medium Priority Proposal 2-2: * 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 (i.e., that the network can assume before the network receives the UE capability signalling from the UE) o FFS: details of the set of reduced capabilities Qualcomm Y We prefer option 4. vivo Y We are fine with Option 4 if down-selection is to be made in this meeting. TCL Y Support the proposal. CATT Y Prefer Option 4. We think the current WID already provides a good picture for L1 RedCap definition: * Maximum UE BW: 20 MHz for FR1, 100 MHz for FR2 * Number of Rx branches: 1 or 2 * Number of maximum DL MIMO layers: 1 or 2 (up to Rx#) * Maximum modulation order on DL and UL: 64QAM * Duplex mode: FDD, Type A HD-FDD, TDD We are open to discuss whether additional modification is needed. Can accept current proposal and discuss down-selection later. Huawei, HiSi Y And option 4 based on our view that only reduced BW is needed to be known. CMCC Y What the potential differences between the two options? Since option 2 is the reduced capabilities that the network needs to know during initial access and option 4 is the minimum set of the reduced capabilities that one RedCap UE type shall mandatorily support before network receives UE capability signaling. Since both of option 2 and option 4 need to assume a capability value during initial access for the RedCap once they are identified during Msg1. 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 vivo At least UE BW, possibly also #Rx. Duplex capability should not be included in the UE type. Xiaomi At least Maximum UE bandwidth. Lenovo, Motorola Mobility Maximum UE bandwidth Ericsson Answer to this question would depend on the outcome of the discussion on Q 2-2. Nevertheless, assuming Option 4 (or our modification to Option 4) is agreed, the minimum capabilities would include the following: Maximum UE BW: 20 MHz for FR1, and 100 MHz for FR2 Minimum number of Rx branches: 1 Supported number of DL MIMO layers: 1 Maximum modulation order: 64QAM Duplex operation: HD-FDD Type A If a RedCap UE has additional capabilities beyond the set of minimum capabilities, the UE can use existing capability signaling framework to convey such information. NordicSemi Starting point are mandatory capabilities of R15 further reduced for at least * 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) * Min required BW FL4 According to the comments provided so far, most of companies think that maximum UE bandwidth (i.e., 20MHz for FR1 and 100MHz for FR2) should be included in the definition of RedCap UE type. As pointed out by CMCC, we made the following agreement in previous RAN1 meeting, which is also captured in TR38.875. Therefore, moderator assumes maximum UE bandwidth is already included without any further 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 One company commented that this question would depend on the outcome of the discussion on Q 2-2. Indeed, there are still divergent views whether or not to include each of reduced capabilities other than maximum UE bandwidth. One company suggests not to discuss ※type§ any more. Therefore, moderator thinks this part is included in the last sub-bullet of Medium Priority Proposal 2-2 (i.e., ※FFS: details of the set of reduced capabilities§) and can be discussed together. Qualcomm Agree with the assessment of FL. vivo OK 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. FL4 According to the comments provided so far, majority companies think RAN1 can continue the discussion of definition of RedCap UE type. Also, as captured in R2-2106521, it seems RAN2 is waiting for RAN1 progress on this topic (see Discussion point 5), moderator suggests to continue RAN1 discussion. For your reference, following agreements were made in this RAN2 meeting so far. Working assumption: 1. Extend UE-NR-Capability using NCE to capture RedCap capabilities Agreements: 2. We will continue the discussion on which capability are applicable to RedCap UE (FFS if we need to have an exhaustive check) 3. At least for early identification there will be only one RedCap UE (no need to define separate RedCap UE types for FR1 and FR2) 4. It is up to the network how to prevent RedCap UEs from using radio capabilities not intended for RedCap UEs (no specification impact is foreseen at least in RAN2. FFS whether something is needed from SA2/CT1) Please provide your input to the related proposal (i.e, Medium Priority Proposal 2-2) Qualcomm Agree with the formulation of Proposal 2-2. From L1 perspective, the definition of RedCap UE type should be based on a minimum set of capabilities as follows: * Maximum UE BW: 20 MHz for FR1 or 100 MHz for FR2 * Minimum number of Rx branches: 1 * Supported number of DL MIMO layers: 1 * Maximum modulation order on DL and UL: 64QAM * Duplex mode: Type A HD-FDD or TDD vivo We are supportive on Qualcomm＊s proposal above mostly, but would like to keep FFS on duplex mode for FDD. We are not sure type A HD-FDD shall always be assumed from gNB perspective during the initial access which seems restrictive, especially if HD-FDD is not widely implemented in the field. FFS can be revisited based on the outcome of HD-FDD design. 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 FL4 According to the comments provided so far, most of companies think the discussion on constraining of reduced capabilities can defer to RAN2. Therefore, moderator suggests to defer to RAN2 for now, and if deemed necessary, RAN1 can come back. Companies can also provide whether following explicit conclusion is necessary or not. Medium Priority proposed conclusion 2-5: * RAN1 defers to RAN2 on constraining of reduced capabilities, and if deemed necessary, RAN1 can come back Qualcomm Y Agree with FL4 proposal as above vivo Y TCL Y CATT Y CMCC Y 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. Qualcomm Y partially We are ok with working assumption 3-1. On the other hand, we think Proposal 3-1a has lower priority than working assumption 3-1. Therefore, we suggest the following changes to 3-1a: Working Assumption 3-1a: * If 4-step RACH is selected by RedCap UEs and msg1 is not configured for early indication of RedCap UEs, FFS whether/how to support early indication in Msg3. On the other hand, if RedCap UE selects 2-step RACH instead of 4-step RACH (based on the relies to Question 3-2), how to facilitate early indication of RedCap UEs needs to be further discussed. Otherwise, RedCap UE has to resort to 4-step RACH for early indication. China Telecom Y We suggest to combine Proposed working assumption 3-1 and High Priority Proposal 3-1a together if needed. vivo We support Proposed working assumption 3-1. We do NOT support Proposal 3-1a: due to following reasons 1) The benefit is much less than MSG1 2) Increase UE complexity due to duplicated functionalities 3) RAN1 does not has the expertise to study or conclude on MSG3 based early indication. Companies are encouraged to discuss this issue in RAN2 if needed. CMCC Y For the sake of further progress and considering the limited benefit compared to capability report, we can accept to remove Msg3 or leave the above two FL3 proposals as it is. Sierra Wireless Y Huawei, HiSi Y for both ZTE, Sanechips Y with modification Fine with Proposed working assumption 3-1 For the sub-bullet of Proposal 3-1a, change ※If supported, the intention is to configure to use one of them§ to ※If supported, early indication in Msg3 can configured to be enabled/disabled.§ Samsung The indication in Msg3 is useful when the indication in Msg1 is disabled, and can allow gNB to configure a proper BWP for Redcap and non-RedCap UEs in Msg 4/5. Otherwise, gNB has to configure 20MHz bandwidth to all UEs or keep all UEs in the initial BWP until the capability report is received. This can increase the congestion in the initial BWP and/or UL resource fragmentation. Our preference is to consider the previous version of the proposal (not the two separate proposals) that includes also the possibility to configure the indication in Msg3. CATT Y partially We are ok with working assumption 3-1. Prefer not to have 3-1a, or clearly mark it with low priority, since identifying UEs during Msg3 seems not worthy compared to the complexity on UE implementation and specification impact. Xiaomi We are OK with working assumption 3-1 As for the necessity of early indication in Msg.3, we don＊t see strong need when there is Msg.1-based indication. If network want to get the UE type information beore BWP configuration, Msg.1-based indication can be configured . Generally, we think working assumption 3-1a is more like a RAN2 issue and RAN2 is discussing this issue as well. So we can leave it in RAN2 Sharp Y partially We agree with the use case of Msg3 indication provided by Samsung. We believe such use case is effective and it avoids unnecessary RACH resource fragmentation. Therefore, Msg3 indication should be supported. On the other hand, we are fine with the separated structure of 3-1 and 3-1a. As mentioned by Ericsson, Msg3 format will be discussed in RAN2, so we don＊t need to add ※if supported.....§ in the sub-bullet of 3-1a. Lenovo, Motorola Mobility Y Spreadtrum We agree with the main idea of working assumption 3-1. To make more clear for this working assumption especially for Msg.1, we make some revision as below: * For 4-step RACH, support the early indication of RedCap UEs at least in Msg1. o The early indication in Msg1 is configurable. 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 For Proposal 3-1a, we share the similar view as vivo. Firstly, duplicated functionality should be avoided. Secondly, the benefit of early indication in Msg3 is quite limited compared to Msg1. The justification is not convinced for the need of early indication in Msg3 even if early indication in Msg1 is not configured. LG Y with modification 3-1: We are fine with the updated proposal. 3-1a: We are generally fine with this proposal. However, whether/how to support early indication of RedCap UEs in Msg3 in addition to Msg1 seems up to RAN2. Thus, we could change to: High Priority Proposal 3-1a: * For 4-step RACH, FFS it is up to RAN2 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 Ericsson N We are not OK with the latest update. There is no reason to preclude or deprioritize Msg3 indication at this stage. Both Msg1 and Msg3 indications have their merits in different scenarios (c.f. our previous response). The NW should have the flexibility to choose a solution, depending on the scenario. As a possible way forward, we propose the following: 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 details e.g.: * separate initial UL BWP * separate PRACH resource * PRACH preamble partitioning o This does not preclude early indication of RedCap UEs in Msg3 in addition to Msg1. This version we could also accept as an agreement, rather than a WA. Panasonic Y Support working assumption 3-1. Proposal 3-1a is also fine but our current view is no need to use Msg3 as commented before. FL3 Following was agreed as working assumption in the 2nd GTW session: 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 Based on the above working assumption, following questions are provided to discuss each of the FFS parts. FL4 High Priority Question 3-1b: * What is your preferred solution how to enable/disable the early indication in Msg1 (e.g. via SIB1)? Company Comments Qualcomm To enable early indication in msg1, * dedicated/separate PRACH resource should be configured for RedCap UE by SI * 4-step RACH is configured for RedCap UE in its initial DL and initial UL BWPs by SI * the SI for RedCap UE can be mapped to SIB1 shared with non-RedCap UE, or transmitted in the initial DL BWP separately configured for RedCap UE Early indication in msg1 is disabled if NW does not configure dedicated PRACH resource for RedCap UE, or 4-step RACH procedure is not configured by RedCap UE. vivo MSG 1 based early indication can be enabled implicitly if separate initial UL BWP for redcap UEs is configured by SIB1 Otherwise if separate initial UL BWP for redcap UE is not configured by SIB1, MSG 1based early indication can be enabled by configuring separate PRACH resource for redcap UEs by SIB1. CATT Basically, we think the current handling of 2-step RACH can be referred to. If PRACH resource can be shared by RedCap and non-RedCap UE, our initial thinking is: - If separated PRACH resource for RedCap UE is configured in SIB1, early indication is enabled and done by PRACH resources. - Else, if PRACH resource is shared, then early indication is enabled and done by PRACH preamble division configured in SIB1. - Else, if nothing dedicated for RedCap during the initial access, then early indication is disabled. However, if down-selection between these options is concluded first, the above step may be changed. Huawei, HiSi Can be in SIB1. CMCC SIB1 can be used to configure separate PRACH resource or separate initial UL BWP, where dedicated PRACH resource is also configured. FL4 High Priority Question 3-1c: * What is your preferred solution how to support the early indication in Msg1 (e.g., separate initial UL BWP, separate PRACH resource, and PRACH preamble partitioning)? Company Comments FL4 Since it was agreed as working assumption in AI8.6.1.1 that separated initial UL BWP for RedCap UE is supported, companies can provide their views for the cases when separate initial UL BWP for RedCap UE is used or when shared initial UL BWP with non-RedCap UEs is used, respectively. Agreements: * Both during and after initial access, the scenario where the initial UL BWP for non-RedCap UEs is configured to be wider than the maximum RedCap UE bandwidth is allowed. * Working assumption: Both during and after initial access, for the scenario where the initial UL BWP for non-RedCap UEs is configured to be wider than the RedCap UE bandwidth, a separate initial UL BWP no wider than the RedCap UE maximum bandwidth is configured/defined for RedCap UEs. o FFS: whether/how to avoid or minimize PUSCH resource fragmentation due to PUCCH transmission for the above case o Support the case when the centre frequency is assumed to be the same for the initial DL and UL BWPs in TDD. * FFS whether or not to additionally support the case when the centre frequency is different; if so, how to minimize centre frequency retuning Qualcomm In our view, separate PRACH resource for RedCap UE can be configured in time/frequency/preamble sequence to enable early indication in Msg1. The three candidate options are not mutually exclusive, and a common solution could be based on separate/dedicated PRACH resource configuration in SI. vivo MSG 1 based early indication can be enabled implicitly if separate initial UL BWP for redcap UEs is configured by SIB1 Otherwise if separate initial UL BWP for redcap UE is not configured by SIB1, MSG 1based early indication can be enabled by configuring separate PRACH resource for redcap UEs by SIB1. TCL Separate PRACH resource CATT If separate initial UL BWP configuration means RedCap dedicated PRACH resources will be configured, then the early indication seems already achieved. Else, if separate initial UL BWP is not configured, then we can follow the 2-step RACH like handling as we just propose in Question 3-1b. But we are not sure, is it possible that even if a separate initial UL BWP is configured, the PRACH resource/configuration can still be shared by RedCap and non-RedCap UE. Huawei, HiSi Can supports all, with details up to gNB. CMCC When separate initial UL BWP is configured, all the PRACH resources and PRACH preamble are configured separately on this initial UL BWP. When initial UL BWP is shared by RedCap and non-RedCap UEs, both separate PRACH resource and separate preamble can be considered. FL4 High Priority Question 3-1d: * Should the discussion in RAN1 on the possibility of supporting Msg3 for the early indication be postponed until RAN2 makes further progress on the early indication in Msg3? Company Y/N Comments FL4 Based on the discussion in R2-2106522, RAN2 made following agreements: 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 2. The cell barring for RedCap UE is per cell (not per PLMN). 3. RedCap UE supports the Intra Frequency Reselection Indicator. 4. Either Msg1 and/or Msg3 early identification will be supported It seems RAN2 was waiting for RAN1 decision whether to support early indication in Msg1. Based on the working assumption we made in the 2nd GTW session, moderator assumes that RAN2 can further discuss the early indication. As discussed in High Priority Proposal 3-1, companies view on whether to support Msg3 is divergent in RAN1. Also, as commented by some companies, RAN2 would be proper WG to discuss Msg3 early identification. Qualcomm Y RAN1 should wait for RAN2＊s further progress. vivo Y Besides the usefulness of MSG3 based early indication can be argued, RAN1 does not have expertise to study or conclude on MSG3 based early indication. TCL Y CATT Y OK to defer to RAN2. Anyway, RAN2＊s view on usage of Msg3 is important. Huawei, HiSi No need to defer. RAN1 can provide input as needed. We support Msg3 as another gNB configuration choice. CMCC Y 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 vivo 2-step RACH could be beneficial for some redcap use cases for power saving purposes, however, we suggest it can be considered as lower priority than 4-step RACH. Huawei, HiSi Y There is benefit for RedCap to support 2step RACH while agree the work can start later. However, the design for 4-step RACH should consider compatibility for future discussion of 2step RACH (separate designs for the two are not desirable). Xiaomi It is better to consider it when there is some progress on the 4-step RACH Ericsson FFS Prefer to discuss early indication of RedCap UEs in 2-step RACH after making decision on 4-step RACH. NordicSemi Not sure it should be mandatory, could be optionally supported for HOs FL4 According to the comments provided so far, most of companies support 2-step RACH for RedCap UEs, while many of them think that its discussion is lower priority than 4-step RACH and thus details can be discussed later. Also, there is no concrete view whether mandatory or optionally support. Based on that, following proposal is made: Medium Priority Proposal 3-2: * Support 2-step RACH for RedCap UEs o FFS whether mandatory or optionally support 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 Qualcomm Y We can live this proposal. Regarding 2-step RACH, we think it can be supported as an optional UE feature in addition to 4-step RACH. vivo We think the support of 2-STEP RACH should be optional. Suggest the following revision. * Support 2-step RACH for RedCap UEs as an optional feature o FFS whether mandatory or optionally support 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 TCL Y CATT 1. To avoid useless/crossed discussion, we think decision on 4-step RACH design should be made first. Anyway, the 2-step RACH is not precluded with or without agreement currently. 2. If 2-step RACH is supported, we think it is an optional feature. No need to make it mandatory. Huawei, HiSi Can live with the proposal while we also consider it should be optional, if supported. CMCC Y We agree with vivo that it is an optional feature. 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 vivo N The early indication for UE type, and early indication for MSG3 repetition are orthogonal features, and taken care by Redcap WI and coverage WI, respectively. Eventually a redcap UE can indicate its request on MSG3 repetition to the NW based on the feature developed in Cov WI, we do not see a problem with such. Huawei, HiSi No strong view. Can be FFS whether there is need for finer differentiation. Samsung We are OK to discuss 2-step RACH. Xiaomi Y In our understanding, coverage enhancement for Msg.3 is needed for some Redcap devices especially considering the antenna efficiency loss. Furthermore, in the WID, it states that 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). Lenovo, Motorola Mobility Y CE WI agreed to have separated Msg1 to request Msg3 repetition. If in RedCap we agree to use Msg1 to early indicate the RedCap UEs, there seems to be aspects to be clarified for Msg1 partitioning. Ericsson Maybe We do not think there will be special handling for the particular combination of CovEnh and RedCap (compared to the combination of SDT and slicing). Therefore, RAN1 should strive for a common solution for all the Rel-17 features that needs Msg1 indication, including RedCap, CovEnh, SDT, and slicing. The same type of RACH partitioning used for Rel-16 2-step RACH can be a starting point (at least for the case w/o a separate initial UL BWP for RedCap UE). NordicSemi Y When CovEnh has more details on early identification, we can try to check how compatible the solutions are. FL4 Maybe the question from moderator was unclear. In ConEnh WI, coverage enhancement for Msg3 is being discussed. If gNB wants to use the feature, early indication whether the non-RedCap UE supports the coverage enhancement for Msg3 or not is necessary, similar to the early indication of RedCap UEs. Therefore, early indication whether RedCap UEs, non-RedCap UEs with CovEnh features, or non-RedCap UEs without CovEnh features may be necessary from system perspective. According to the comments provided so far, there is no clear majority view whether we need to take non-RedCap UEs with CovEnh feature into account for the early indication of RedCap UEs. Therefore, following proposal is made: Medium Priority Proposal 3-3: * For early indication of RedCap UEs, o FFS whether to take non-RedCap UEs with CovEnh feature into account separately from non-RedCap UEs without CovEnh features Qualcomm Y We can live with this proposal. vivo The updated proposal seems unclear to us. We think the following note from the WID should be sufficient enough, we will take the CovEnh feature into account by this note. * 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). TCL Y CATT Y CMCC Y 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. Qualcomm OK with this proposal * We don＊t think access control information is needed before SIB1. * Since access control is mainly a RAN2 issue, which is expected to be solved by the UAC framework of NR, we don＊t think indication in DCI scheduling SIB1 will be a preference of RAN2. We can check with RAN2 if needed. * We think the access control of RedCap UE can depend on the RX number and operating bands for FR1. The details can be investigated by RAN2, since it may involve additional considerations from upper layer and operators. China Telecom Y We support FL proposal as a staring point for further discussion. Vivo N This is a RAN2 topic, RAN1 discussion can be triggered by RAN2 at later stage, if needed. CMCC The second FFS seems to be a sub bullet for the first FFS. Indication in DCI scheduling SIB1 is one indication solution before SIB1. The third FFS is not so clear. Does it mean: whether the indication has dependency on number of Rx branches and operating band? Sierra Wireless N Should be up to RAN2 Huawei, HiSi Partially The 3rd point is not clear. Do not see spec impact based on such description and the feasibility is questionable. How network system information can take into account the 1Rx performance 每 e.g., it was known that 1Rx in a small device can have better antenna efficiency than 2Rx in the small device with same size, since the relative antenna distance for the latter is even smaller. ZTE, Sanechips Y For ＆FFS: Whether it is needed before SIB1, we think access control for RedCap UEs is needed before SIB1. In legacy NR, besides access control information carried in SIB, there also has one bit ＆cellBarred＊ field carried in MIB for access control. Access control indication in SIB will take much longer time for RedCap UEs to identify the accessible cells. Similar to legacy NE UEs, besides access control information carried in SIB, earlier indication of access control for RedCap UEs is beneficial for power saving of RedCap UEs. For ※FFS: Indication in DCI scheduling SIB1§, we support to carry the access control signaling for RedCap UEs in DCI scheduling SIB1. DCI format 1_0 with CRC scrambled by SI-RNTI in Type0 PDCCH has 15 bits reserved. If the access control signaling for reduced capability NR devices is carried in DCI scheduling SIB1 instead of SIB1, the reduced capability UE can stop the system information acquisition procedure once the reduced capability UE successfully decodes the DCI with restricted access signaling. Unnecessary SIB1 decoding can be avoided for the reduced capability NR devices. It is beneficial for UE＊s power saving. So, it is preferred to carry the access control signaling for RedCap UEs in DCI scheduling SIB1. The third FFS is not clear. CATT Partially From exchanging opinion＊s view, we can accept this proposal. The 3rd bullet seems related to the WID ＆it shall be possible for the indication to be specific to the number of Rx branches of the UE＊ but not sure what is going to be discussed from the current wording. But we still do not feel RAN1 is urgent to discuss this. Note that this is a RAN2 leading feature, and RAN2 is discussing the access control for RedCap now. Xiaomi The following is the RAN2 agreement about access control Agreement: 1. SIB1(not MIB) indicates cell baring for 1Rx branch and 2Rx branches separately for RedCap UEs. Further details of the solution are FFS We need to discuss this issue based on the new RAN2 agreement. Based on the explanation from RAN2 colleagues, SIB1 DCI based indication is not precluded. So RAN1 could continue the discussion with the focus on whether support SIB1 DCI based indication. Ericsson Based on the RAN2 agreements (copied in Xiaomi＊s response above), we propose the following update: * For system information indication of access control for RedCap UEs, o FFS: Whether it is needed to have the indication in DCI scheduling SIB1 before SIB1 o FFS: Indication in DCI scheduling SIB1 The third FFS is not clear to us. So, it should be either clarified or removed. Panasonic N The 1st and 3rd FFS points are RAN2 topics. If RAN2 suggested to use DCI, RAN1 should discuss 2nd FFS point. Our view is no need to discuss it if RAN2 does not suggest it. FUTUREWEI3 N More analysis is needed. Nokia, NSB FFS: Whether it is needed before SIB1 * It is not needed, but we believe it would be beneficial to the RedCap UE, by saving it time and energy attempting to decode SIB1 FFS: Indication in DCI scheduling SIB1 * Given the lack of spare MIB bit and availability of unused SIB1 DCI bits, we see this as the earliest and easiest way to indicate some form of access control to RedCap devices. FFS: Performance dependency of RedCap Ues with 1Rx branch on the operating band * Based on the findings of the TR study, RedCap UEs with 1 Rx may benefit from coverage enhancements to msg2 and beyond in certain scenarios. * Ideally, these enhancements should be applied from msg2 only and target specifically the sub-group of RedCap devices (1Rx) that need the enhancements, otherwise all RACH access messages may need to be over-configured (wasting resources). * We can envisage that some operators may want the option to restrict access to subsets of RedCap devices, e.g those with 1Rx, through indication in system information. NordicSemi N Access control should be discussed in RAN2. Intel We agree with the updates from Ericsson. The third sub-bullet is not clear to us either. FL4 Based on the comments provided so far, the proposal is updates as follows: ? 1st FFS is removed as the applicable solution before SIB1 would be the DCI scheduling SIB1 based on the RAN2 agreement as below, which is already included in the 2nd FFS ? 2nd FFS is updated based on the comment from Ericsson ? 3rd FFS is removed because of the concern from a number of companies. Proponant companies can try to clarify the motivation further 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: Whether it is needed to have the indication in DCI scheduling SIB1 o FFS: Performance dependency of RedCap Ues with 1Rx branch on the operating band For your reference, RAN2 made following agreement in this RAN2 meeting: Agreements: 5. 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 6. The cell barring for RedCap UE is per cell (not per PLMN). 7. RedCap UE supports the Intra Frequency Reselection Indicator. 8. Either Msg1 and/or Msg3 early identification will be supported Qualcomm Depends If RAN2＊s agreement is based on UAC/IE of SIB1, it is not necessary to pursue this proposal. vivo N Based on RAN2 agreement, to us, the meaning of ※SIB1 indicates§ refers to SIB1 content, not DCI scheduling SIB1. However, instead of arguing what is precluded/not precluded by a RAN2 agreement, it would be more efficient for companies to have more discussion in RAN2 and if there is a need for RAN1 to evaluate the feasibility/benefit of using indication in DCI scheduling SIB1, RAN2 should explicitly task RAN1 to do so. CATT N RAN2 is making progress on cell barring and detailed design. If there is any work for RAN1 to consider accordingly, RAN2 can trigger RAN1 to do so. Huawei, HiSi Y CMCC Y 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 Vivo We agree with FUTUREWEI and think alt-2 should be taken. Huawei, HiSi Agree with FUTUREWEI and Alt-2. Xiaomi We prefer Alt.2 Lenovo, Motorola Mobility Alt.2 Nokia, NSB Given the further discussion on the Alternatives, we can support Alt-2. Ericsson We prefer Alt-2. We have similar concerns as FUTUREWEI regarding Alt-1. NordicSemi Alt2. and any changes need to be agreed. Intel Alt 2, and agree with comments from Futurewei. Company Y/N Comments FL4 According to the comments provided so far, most of companies support Alt-2 in principle, and thus following proposal is made: Medium Priority Proposal 5-1: * For the necessary updates of UE capabilities, current definition of mandatory/optional support of UE capabilities in TS38.306 is reused for RedCap UEs by default unless any update is identified Qualcomm Y vivo Y TCL Y CATT Y Huawei, HiSi Almost The proposal should not include the ones that have been precluded by WID, i.e. CA, DC and wider max UE bandwidth. In addition, we are proposing BWP without SSB as a mandatory feature for RedCap. CMCC Y 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 7 Conclusions [TBD] Following agreements were made in [105-e-NR-R17-RedCap-05]: 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