RedCap Rel-17

 RAN1#101-e

8.3       Study on Support of Reduced Capability NR Devices

Please refer to RP-193238 for detailed scope of the SI

[101-e-NR-RedCap-Skeleton] – Johan (Ericsson)

Email discussion/approval of R1-2003288 till 6/1

R1-2003288        TR skeleton for Redcap  Ericsson

R1-2004993        Email discussion for TR skeleton for Study on support of reduced capability NR devices  Moderator (Ericsson)

Decision: As per email decision posted on June 3^rd, the latest skeleton is endorsed as version 0.0.1 in R1-2004962 as basis for futher work.

[101-e-NR-RedCap-01] – Johan (Ericsson)

Email discussion/approval (focusing on high-level topics/evaluation assumptions necessary to faciliate next step’s more concrete analysis/evaluations) till 6/1

R1-2004731        Email discussion for Study on support of reduced capability NR devices               Moderator (Ericsson)

Decision: As per GTW decision posted on June 2^nd,

Agreements:

·        For FR1, study at least 20MHz maximum UE bandwidth at least for initial access

o   Other bandwidths FFS

·        For FR2, study 50MHz and 100 MHz maximum UE bandwidth at least for initial access

o   Other bandwidths FFS

R1-2005048        Email discussion summary#2 for Study on support of reduced capability NR devices  Moderator (Ericsson)

Decision: As per email decision posted on June 6^th,

Agreements:

·        For safety related sensors, latency requirements apply to traffic initiated from RRC_CONNECTED.

·        Use the TR 36.888 methodology for UE cost/complexity evaluation as a starting point and determine what major updates are needed.

·        Include antenna parts at least in the cost/complexity breakdown for FR2.

·        Potential benefits in terms of reduced device size can be mentioned where applicable in the TR (e.g. in the section on reduced number of antennas), but the SI will not aim to quantify such benefits.

·        Reuse the power consumption models and scaling factors for FR1 and FR2 provided in TR 38.840 (sections 8.1.1, 8.1.2, 8.1.3) as appropriate.

·        Study the impact of BD and CCE limits reduction on power saving and PDCCH blocking probability (quantitatively) and impacts on latency and scheduling flexibility (at least qualitatively).

Update on 6/7, post e-Meeting additional email approval

[101-e-Post-NR-RedCap] – Johan (Ericsson)

Email discussion/approval focusing on remaining high-level topics/evaluation assumptions necessary to faciliate next step’s more concrete analysis/evaluations till 6/17

• Focusing on high priority proposals first, target 6/11 for early approvals
• Followed by medium priority/low priority proposals

8.3.1        Potential UE complexity reduction features

R1-2003289        Potential UE complexity reduction features for Redcap       Ericsson

·        Proposal 1: For FR1, a 20 MHz UE maximum bandwidth should be supported. One single type of Redcap UE with at least two different capabilities is considered, i.e., one low data rate services and another for high data rate services.

·        Proposal 2: For FR2, a 50 MHz UE maximum bandwidth should be supported.

·        Proposal 3: The scope of the objective to study a “Reduced number of UE RX/TX antennas“ includes a study of the reduction in number of receiver and transmitter branches.

·        Proposal 4: Redcap support for a single transmitter branch in FR1 is a suitable baseline assumption.

·        Proposal 5: Redcap support for 2 receiver branches in FR1 is a suitable baseline assumption.

·        Proposal 6: Support for a single receiver branch in FR1 for facilitating compact form factors deserves further discussion.

·        Proposal 7: Redcap support for a single transmitter branch in FR2 is a suitable baseline assumption.

·        Proposal 8: Redcap support for 2 receiver branches in FR2 is a suitable baseline assumption.

·        Proposal 9: Redcap support for radiated requirements corresponding to at least two antenna panels (i.e. same as reference implementation) is a suitable baseline assumption.

·        Proposal 10: For some stationary IoT devices radiated requirements corresponding to one antenna panel may be justified and further discussion on this relaxation is required in RAN1.

·        Proposal 11: RAN1 needs to study the expected losses in a Redcap UE to determine a suitable antenna panel gain, which can be associated to a number of antenna elements per panel to facilitate a discussion on antenna complexity reduction.

·        Proposal 12: RAN1 needs to consider if a reduced EIRP as a result of antenna gain reduction is in the scope of the Redcap SI, since EIRP is closely coupled to the implementation margins and the antenna design.

·        Proposal 13: Discuss further whether there is enough cost reduction benefit by enabling a single frequency generator HD-FDD device operating in an FDD band to motivate the associated performance loss and changes to specifications and scheduler implementations.

·        Proposal 14: If Type-B HD-FDD is introduced, it is desired to aim to minimize the impact on scheduler implementations.

·        Proposal 15: Latency requirement and scheduling flexibility should be considered when discussing any potential relaxed UE processing time for PDSCH processing and PUSCH preparation.

·        Proposal 16: Actual cost reduction from a UE perspective needs to be considered to investigate whether the gain from more relaxed UE processing time is justified.

·        Proposal 17: If Redcap UEs allow multiple antennas, data reception scheme with MIMO to achieve peak data rate should be considered as it would be more cost effective compared to that with 256QAM or carrier aggregation.

·        Proposal 18: When considering cost reduction by reducing the number of PDCCH blind decoding per slot and/or CCEs for channel estimation, the impacts on scheduling flexibility and blocking probability should also be considered.

Decision: The document is noted.

R1-2003966        Discussion on UE complexity reduction     CMCC

·        Proposal 1. The number of RX/TX antennas of reduced capability NR devices should take the complexity, device size and coverage performance into account.

·        Proposal 2. The UE Bandwidth reduction should take the coverage & capacity performance of control channel and the coexistence with eMBB/URLLC devices into account.

·        Proposal 3. When relaxed UE processing time is introduced, the default scheduling timing needs further examination.

·        Proposal 4. At most two capability sets are preferred for the UEs with reduced capability.

·        Proposal 5. At least 20MHz UE bandwidth is required for one set of UEs with reduced capability to achieve high peak data rate.

Decision: The document is noted.

R1-2004493        Considerations for Complexity Reduction of RedCap Devices           Qualcomm Incorporated

Proposal 1: For NR RedCap devices, study the reduction of max UE BW to optimize the tradeoff in cost saving, performance and standardization impact. When deployed in FR1, the RedCap UE needs to satisfy the following requirements:

·        support AL 16 for CORESET0

·        support 20 MHz as the mandatory and max BW for initial DL BWP

Proposal 2: For NR RedCap devices with reduced BW, study the peak data rate supported by single carrier, single layer and MCS range restriction. Specifically,

·        different MCS and BW can be allocated for DL and UL to adapt to asymmetric traffic patterns

·        in addition to supporting 20 MHz as the mandatory and max BW for initial DL BWP, smaller BW can be configured for the active DL/UL BWP of RedCap UE to support peak data rates in the range of 5~10 Mbps

·        256QAM modulation is not supported for RedCap UE

·        FFS whether or not to support 150 Mbps peak data rate on DL with active BWP wider than 20 MHz

·        FFS whether 64QAM needs to be supported on UL

Proposal 3: Study complexity reduction and coverage recovery techniques for NR RedCap devices, with 1 TX antenna and 1 RX antenna as the baseline.

Proposal 4: Study the relaxation of UE processing capabilities including reduced PDCCH monitoring, simplification of UE procedures for CSF, HD-FDD, HARQ, beam management and RLM/RRM measurements.

Proposal 5: Study the signalling support for HD-FDD UE and the co-existence of HD-FDD and FD-FDD devices on paired spectrum in FR1. Type-A HD-FDD mode of LTE and NR Rel-15 TDD slot format can be used as baseline for studying the HD-FDD design applicable to NR RedCap UE.

Proposal 6: Study gNB’s signalling support and UE’s indication mechanism for timeline relaxation of RedCap devices.

Proposal 7: Study new type of UE processing capabilities inherent to RedCap devices.

Proposal 8: Study the reduction of HARQ complexity for RedCap devices of IIoT.

Proposal 9: To save UE power and complexity in FR2, consider switching the UE to a narrow active BWP (NBWP) after initial cell search is complete, and study the impact of the narrower BWP on the overall system operation.

Proposal 10: To reduce UE complexity in FR2, study DL and UL beam management simplification techniques for RedCap.

Decision: The document is noted.

R1-2003281         Analysis of complexity reduction features for RedCap UEs      Futurewei

R1-2003301         Potential UE complexity reduction features  Huawei, HiSilicon

R1-2003307         Potential UE complexity reductiton features China Unicom

R1-2003344         Reduced Capability UE Complexity Reduction Features           Sierra Wireless, S.A.

R1-2003431         Capability and complexity reduction for Reduced Capability NR devices               vivo, Guangdong Genius

R1-2003644         Discussion on potential UE complexity reduction features        CATT

R1-2003687         On complexity reduction features for NR RedCap UEs             MediaTek Inc.

R1-2003770         On potential UE complexity reduction features           Intel Corporation

R1-2003801         Discussion on potential UE complexity reduction features        ZTE

R1-2003828         On UE complexity reduction features            Lenovo, Motorola Mobility

R1-2003910         UE complexity reduction  Samsung

R1-2003922         View on reduced capability NR devices        NEC

R1-2003934         UE complexity reduction features   Nokia, Nokia Shanghai Bell

R1-2003995         Discussion on potential UE complexity reduction features        Spreadtrum Communications

R1-2004021         Discussion on potential UE complexity reduction features        LG Electronics

R1-2004104         Discussion on UE complexity reduction        OPPO

R1-2004172         Potential UE complexity reduction features  TCL Communication Ltd.

R1-2004193         On potential UE complexity reduction features for NR devices Sony

R1-2004251         Standard Aspects of UE complexity Reduction Features           Apple

R1-2004270         On the effect of reducing the number of UE Rx antennas on DL capacity               Orange

R1-2004306         Discussion on potential UE complexity reduction features        Panasonic Corporation

R1-2004314         Complexity reduction features for reduced capability NR devices           InterDigital

R1-2004335         Discussion on Potential UE complexity reduction features       Sharp

R1-2004421         Potential UE complexity reduction features for RedCap            NTT DOCOMO, INC

R1-2004506         Initial discussion on the complexity reduction for reduced capability device               Xiaomi Technology

R1-2004536         Discussion on potential UE complexity reduction features        Asia Pacific Telecom co. Ltd

R1-2004557         UE Complexity Reduction for Reduced Capability NR Devices              Potevio

R1-2004595         On potential UE complexity reduction features           Convida Wireless

8.3.2        Reduced PDCCH monitoring

R1-2003911        Reduced PDCCH monitoring       Samsung

·        Proposal #1: Study reduced maximum numbers of PDCCH candidates per slot,  and  non-overlapping CCEs per slot, , with respect to reduced UE operating bandwidth.

·        Proposal #2: Study maximum number of monitored PDCCH candidates and non-overlapping CCEs in a span, where the  span gap X is more than a slot.

·        Proposal #3: Study dynamic adaptation on PDCCH monitoring with adaptive parameters including

o   CCE ALs to monitor

o   number of PDCCH candidates

o   span gap X

·        Proposal #4: Reuse reference configuration, traffic model, and power consumption model in TR 38.840 with necessary updates to address requirement of RedCap use cases.

·        Proposal #5: Support power model of PDCCH processing relaxation over X slots, such that P(X) = max (Pt/X, Ps), where Pt is power of PDCCH monitoring without relaxation, and Ps is power for micro sleep.

·        Proposal #6: Evaluate power saving gains and system overhead for PDCCH monitoring reduction mechanisms.

·        Observation #1: PDCCH resources in a CORESET are reduced compared to Rel-16 due to reduced UE operating BW.

Decision: The document is noted.

R1-2003935        Reduced PDCCH monitoring       Nokia, Nokia Shanghai Bell

·        Proposal 1: RAN1 to clarify working relationship with Release 17 UE Power Saving Enhancements working group.

·        Proposal 2: Agree the NR REDCAP UE capability set(s) for evaluation purpose.

o   2/3 sets of capabilities are envisaged depending on the peak data rate support, complexity and carrier support.

·        Proposal 3: Agree the NR REDCAP UE power consumption model for required scenarios.

o   Release 16 TR on UE Power Saving [4], can be used as a starting point and modified in accordance with the agreed UE capability set(s).

·        Proposal 4: Agree the link and system level assumptions, including the traffic models.

o   Traffic models should be aligned with the target use cases.

·        Proposal 5: This study should consider the comparison and impact of reduced REDCAP UE PDCCH and CCE limits, with several existing release 15 and 16 features that reduce PDCCH monitoring, including:

o   BWP switching

o   DRX

o   SPS

o   Grant Free Transmission

o   Power Saving DCI format 2-6

o   Cross-slot scheduling

o   UE power saving assistance information

Decision: The document is noted.

R1-2004252        PDCCH Monitoring for Reduced Capability Devices           Apple

·        Proposal 1:

o   The maximum number of PDCCH candidates and non-overlapped CCEs for USS should be relaxed for reduced capability devices.

o   The number of configurable aggregation levels for NR-lite devices can be further reduced compared to Rel-15 requirement.

·        Proposal 2: Study the feasibility to introduce a compact DCI format for reduced capability UEs to enhance the coverage.

·        Proposal 3: Reduced capability UE should be allowed to support cross-slot scheduling only i.e K0>0 to not only reduce power consumption but also UE complexity.

Decision: The document is noted.

R1-2003290         Reduced PDCCH monitoring for Redcap      Ericsson

R1-2003302         Power saving for reduced capability devices Huawei, HiSilicon

R1-2003432         Reduced PDCCH monitoring for Reduced Capability NR devices          vivo, Guangdong Genius

R1-2003546         Power savings for RedCap UEs       Futurewei

R1-2003645         Discussion on PDCCH monitoring reduction CATT

R1-2003688         Discussion on reduced PDCCH monitoring for NR RedCap UEs            MediaTek Inc.

R1-2003711         View on reduced PDCCH monitoring for NR devices NEC

R1-2003771         On PDCCH monitoring simplifications for RedCap NR Ues    Intel Corporation

R1-2003802         Considerations on reduced PDCCH monitoring          ZTE

R1-2003967         Discussion on PDCCH monitoring reduction for Reduced Capability NR Devices               CMCC

R1-2003996         Discussion on reduced PDCCH monitoring  Spreadtrum Communications

R1-2004022         Discussion on PDCCH monitoring for reduced capability NR devices   LG Electronics

R1-2004105         Discussion on reduced monitoring for PDCCH            OPPO

R1-2004173         Reduced PDCCH monitoring          TCL Communication Ltd.

R1-2004194         Battery lifetime enhancement for reduced capability NR devices through reduction of PDCCH monitoring           Sony

R1-2004302         Considerations on reducing PDCCH monitoring         Fujitsu

R1-2004315         Reduced PDCCH monitoring for reduced capability NR devices            InterDigital

R1-2004336         Reduced PDCCH monitoring for reduced capability UEs          Sharp

R1-2004373         PDCCH monitoring at reduced capability UEs            Motorola Mobility, Lenovo

R1-2004422         Reduced PDCCH monitoring for RedCap     NTT DOCOMO, INC

R1-2004494         Considerations for PDCCH Monitoring Reduction and Power Saving of RedCap Devices Qualcomm Incorporated

R1-2004514         Initial discussion on the reduced PDCCH monitoring for reduced capability devices               Xiaomi Technology

R1-2004541         Discussion on reducing PDCCH monitoring for RedCap UEs  PANASONIC

8.3.3        Functionality for coverage recovery

R1-2003303        Functionality for coverage recovery           Huawei, HiSilicon

·        Observation 1: For PDCCH, there is nearly 3dB performance loss if UE RX antennas are reduced from 4RX to 2RX.  Significant degradation of PDCCH performance can be expected if UE RX antennas are further reduced to 1RX.

·        Observation 2: For PDSCH, the total performance loss is about 5.5dB, if RX antennas are reduced from 4RX to 2RX and UE BW is reduced from 100MHz to 20MHz. Significant degradation of PDSCH performance can be expected if UE RX antennas are further reduced to 1RX.

·        Observation 3:  For PUCCH and PUSCH, there is no obvious performance gap between NR REDCAP UE and NR legacy UE.

·        Observation 4: There is no performance gap between NR REDCAP UE and NR legacy UE for common channels and signals (e.g. SSB).

·        Proposal 1: The number of UE RX antennas reducing to 2RX is with high priority.

·        Proposal 2: Some potential enhancements for PDCCH/PDSCH for NR REDCAP UEs should be considered.

Decision: The document is noted.

R1-2004317        Coverage enhancement for reduced capability NR devices  InterDigital

·        Proposal 1: Repetition is the baseline method for coverage recovery in reduced capability devices.

·        Proposal 2: The following methods should be considered for further study for coverage recovery in reduced capability devices:

o   Compact DCI

o   Low rate coding and lower order modulation

o   Improved channel estimation

Decision: The document is noted.

R1-2004423        Functionality for coverage recovery for RedCap    NTT DOCOMO, INC

·        Proposal 1: Performance evaluation on each physical channel is done in the following 3 steps:

o   Step 1: Coverage performance evaluation of NR Rel.15/16 UEs

§  Evaluation of NR Rel.15/16 UEs to obtain the reference/target performance for RedCap UEs

o   Step 2: Basic coverage performance evaluation of RedCap UEs

§  Evaluation of RedCap UEs to obtain the performance loss due to reduced complexity, e.g.,

·        Reduced number of UE RX/TX antennas

·        UE BW reduction

o   Step 3: Enhanced coverage performance evaluation of RedCap UEs, if needed

§  Evaluation of RedCap UEs with the potential functionalities to compensate the coverage reduction on a physical channel

·        Proposal 2: UMa, UMi, and indoor factory are assumed as the deployment scenarios of the performance evaluation for each use case.

Decision: The document is noted.

R1-2003282         Coverage recovery for RedCap       Futurewei

R1-2003291         Functionality for coverage recovery for Redcap          Ericsson

R1-2003433         Discussion on functionality for coverage recovery      vivo, Guangdong Genius

R1-2003558         Functionality for Coverage Recovery            Panasonic Corporation

R1-2003646         Coverage recovery for reduced capability NR devices CATT

R1-2003689         Discussion on coverage recovery for NR RedCap UEs              MediaTek Inc.

R1-2003772         On coverage recovery for RedCap NR UEs   Intel Corporation

R1-2003803         Discussion on functionality for coverage recovery      ZTE

R1-2003829         On coverage enhancement for RedCap          Lenovo, Motorola Mobility

R1-2003912         Coverage recovery for low capability device Samsung

R1-2003936         Functionality for coverage recovery Nokia, Nokia Shanghai Bell

R1-2003968         Consideration on coverage recovery for Reduced Capability NR Devices               CMCC

R1-2003998         Discussion on functionality for coverage recovery      Spreadtrum Communications

R1-2004023         Discussion on the coverage recovery of reduced capability NR devices LG Electronics

R1-2004106         Discussion on functionality for coverage recovery      OPPO

R1-2004195         Coverage recovery techniques for reduced capability NR devices           Sony

R1-2004253         Coverage recovery for reduced capability NR devices Apple

R1-2004337         Coverage recovery for reduced capability UEs            Sharp

R1-2004495         Considerations for Coverage Recovery of RedCap Devices      Qualcomm Incorporated

R1-2004532         Initial discussion on coverage recovery for reduced capability Xiaomi Technology

R1-2004596         On coverage recovery for reduced capability UEs       Convida Wireless

8.3.44        Other

R1-2003283         Framework for RedCap UEs            Futurewei

R1-2003292         Higher-layer aspects for Redcap     Ericsson

R1-2003434         RRM relaxation for Reduced Capability NR devices  vivo, Guangdong Genius

R1-2003647         Identification and access restriction for reduced capability NR devices  CATT

R1-2003804         Discussion on UE categories for reduced capability NR devices             ZTE

R1-2003913         Considerations on access barring and UE capability   Samsung

R1-2003969         Discussion on framework of Reduced Capability NR Devices  CMCC

R1-2003997         Consideration on power saving for reduced capability NR devices         Spreadtrum Communications

R1-2004024         Consideration on the framework to support reduced capability NR devices          LG Electronics

R1-2004107         Consideration on reduced UE capability       OPPO

R1-2004176         Discussion on RedCap      Sequans Communications

R1-2004318         Orthogonal ON/OFF keying for wake-up signal design             InterDigital

R1-2004374         Narrowband operation at reduced capability UEs        Motorola Mobility, Lenovo

R1-2004496         Considerations for Standardization Framework and Design Principles of RedCap Devices Qualcomm Incorporated

R1-2004535         On the framework and principles of Reduced Capability NR Devices    Xiaomi Technology

R1-2004612         Other aspects for reduced capability devices Huawei, HiSilicon

 RAN1#102-e

8.6       Study on Support of Reduced Capability NR Devices

Please refer to RP-201386 for detailed scope of the SI

R1-2005233        TR38.875 skeleton updates for Study on support of reduced capability NR devices  Ericsson

Decision: The clauses 4 & 5 in x5233 are endorsed by RAN1. The changes in other TR sections concern RAN2-led objectives, agreed in RAN2 (R2-2007366). Therefore R1-2005233 is endorsed as v0.0.2 as basis for further updates.

[102-e-Post-NR-RedCap-01] – Johan (Ericsson)/Hong (Apple)/Chao(Qualcomm)

Email discussion/approval

Phase 1 (9/10-9/29): template for evaluations, including:

·        cost reduction estimates

·        power saving estimates

·        Coverage recovery and capacity impact simulation results

Phase 2 (9/30-10/21)

·        Initial collection of the above evaluation results

8.6.1        Potential UE complexity reduction features

R1-2005234        Potential UE complexity reduction features for RedCap      Ericsson

·        Proposal 1: Capture in the recommendation and conclusion of the TR that in FR1, a RedCap UE is required to support at least 2 receiver branches in bands n7, n38, n41, n77, n78 and n79, and 1 receiver branch in all other bands.

·        Proposal 2: Capture in the recommendation and conclusion of the TR that in FR2, a RedCap UE is required to support at least support 2 receiver branches.

·        Proposal 3: Type B HD-FDD operation is not considered further during the study.

·        Proposal 4: Actual cost/complexity reduction from relaxing the UE processing time in terms of N1/N2 needs to be considered in connection with other UE complexity reduction features to investigate whether the gain from a more relaxed UE processing time is justified.

Decision: The document is noted.

R1-2006152        UE complexity reduction Samsung

·        Proposal 1: Take Table 1 as a starting point for complexity breakdown of reference UEs.

·        Proposal 2: Reduced number of UE Rx antennas to 1 Rx can be supported. Some techniques to recovery the coverage loss and improve the spectral efficiency can be considered. Early capability report in random access can be further studied.

·        Proposal 3: Bandwidth reduction to 20MHz for FR1 and to (FFS) 50 and/or 100MHz for FR 2 can be supported. Some specification changes at least including multiple initial BWPs, separated CORESET 0/Type 0 common search space, UE operating in a larger BW, CSI acquisition outside active BWP enhancement can be further studied. 

·        Proposal 4: HD-FDD can be considered for RedCap UE. Further study to identify whether any potential specification change is needed in RAN 1.

·        Proposal 5: Further study on necessary specification impact to support relaxed UE processing time.

·        Proposal 6: There is no need to support relaxed UE processing capability on top of antenna reduction and bandwidth reduction.

Decision: The document is noted. Further revised in R1-2007031.

R1-2006733        Discussion on potential UE complexity reduction features for RedCap               NTT DOCOMO, INC.

·        Proposal 1: Study the solution for SSB/CORESET0 with more than 50/100 MHz BW if 50/100 MHz maximum UE BW is assumed for FR2

·        Proposal 2: Study 1) larger than 20 MHz (e.g. 40 MHz) UE BW for initial access or 2) solution for the invalid RO issue with 8 FDMed ROs if maximum 20 MHz UE BW is assumed for FR1

Decision: The document is noted.

R1-2005269         Potential UE complexity reduction features  Huawei, HiSilicon

R1-2005277         Complexity reduction features for RedCap UEs          FUTUREWEI

R1-2005383         Discussion on complexity reduction for Reduced Capability NR devices               vivo, Guangdong Genius

R1-2005474         Potential UE complexity reduction features  ZTE

R1-2005525         UE complexity reduction features   Nokia, Nokia Shanghai Bell

R1-2005580         On potential complexity reduction techniques for NR devices  Sony

R1-2005637         On complexity reduction features for NR RedCap UEs             MediaTek Inc.

R1-2005714         Discussion on potential UE complexity reduction features        CATT

R1-2005770         Potential UE complexity reduction features  TCL Communication Ltd.

R1-2005830         On UE complexity reduction features for RedCap      Lenovo, Motorola Mobility

R1-2005880         On complexity reduction for RedCap UEs    Intel Corporation

R1-2005937         Reduced Capability UE Complexity Reduction Features           Sierra Wireless, S.A.

R1-2005959         Rel-16 UE power saving features for RedCap             NEC

R1-2005968         Discussion on the complexity reduction for reduced capability device   Beijing Xiaomi Software Tech

R1-2006036         Discussion on UE complexity reduction        OPPO

R1-2006196         Discussion on potential UE complexity reduction features        Panasonic Corporation

R1-2006217         Discussion on potential UE complexity reduction features        CMCC

R1-2006272         Discussion on potential UE complexity reduction features        Spreadtrum Communications

R1-2006306         Discussion on potential UE complexity reduction features        LG Electronics

R1-2006988         UE Complexity Reduction Features for RedCap         Apple    (Revision of R1-2006524)

R1-2006538         Complexity reduction features for reduced capability NR devices           InterDigital, Inc.

R1-2006542         On impacts of UE bandwidth reduction         Quectel

R1-2006576         Discussion on Potential UE complexity reduction features       Sharp

R1-2006644         Discussion on potential UE complexity reduction features        Asia Pacific Telecom co. Ltd

R1-2006682         Complexity reduction features for RedCap UE            Sequans Communications

R1-2006811         Complexity Reduction for RedCap Devices  Qualcomm Incorporated

[102-e-NR-RedCap-01] – Johan (Ericsson)

Email discussions/approval

·        By 8/20 – high priority

·        By 8/26 – medium

·        By 8/28 – last check

R1-2007090        FL summary #1 for Potential UE complexity reduction features for RedCap               Moderator (Ericsson)

Agreements:

·        For cost/complexity reduction analysis, the RF-to-baseband cost ratio for an FR1 UE is assumed to be 40:60.

·        For cost/complexity reduction analysis, the RF-to-baseband cost ratio for an FR2 UE is assumed to be approximately 50:50.

Conclusion:

·        The study of reduced number of UE (physical) antenna elements and panels in FR2 is not prioritized in the RedCap study item.

Agreements:

·        For RedCap UEs in FR1,

o   The baseline UE bandwidth capability is 20 MHz, which can be assumed during the initial access procedure.

o   Discuss further by email whether there is an issue or a necessity in achieving up to 150Mbps assuming a 20MHz and rank 1 transmission.

R1-2007177        FL summary #2 for Potential UE complexity reduction features for RedCap               Moderator (Ericsson)

Decision: As per email decision posted on August 23^rd,

Agreements:

·        For the purpose of evaluation, the UE processing time in terms of N1/N2 can be assumed to be doubled compared to those of capability #1, i.e.,

o   N1 = 16, 20, 34, and 40 symbols for 15, 30, 60, and 120 kHz SCS (assuming only front-loaded DMRS)

o   N2 = 20, 24, 46, and 72 symbols for 15, 30, 60, and 120 kHz SCS

Agreement:

·        Study of relaxed UE processing time related to CSI computation is not prioritized in the RedCap study item.

R1-2007269        FL summary #3 for Potential UE complexity reduction features for RedCap               Moderator (Ericsson)

From the GTW session on August 25^th,

Agreements:

·        For FR1 DL, study relaxation of maximum mandatory modulation to 64QAM instead of 256QAM.

·        For FR1 UL, study relaxation of maximum mandatory modulation to 16QAM instead of 64QAM.

·        For FR2 DL, study relaxation of maximum mandatory modulation to 16QAM instead of 64QAM.

·        For FR2 UL, study relaxation of maximum mandatory modulation to 16QAM instead of 64QAM.

·        Restriction to 1 or 2 MIMO layers in DL can be studied.

·        No TBS restriction is considered in this SI beyond the implicit TBS restrictions resulting from reduced UE bandwidth or reduced number of MIMO layers.

R1-2007302        FL summary #4 for Potential UE complexity reduction features for RedCap               Moderator (Ericsson)

Decision: As per email decision posted on August 26^th,

Agreements:

·        Assume the detailed cost breakdown for FR1 FDD/TDD and FR2 in the table below:

Agreements:

·        In potential cost evaluations for a UE, it is assumed that the multi-band support affects the RF cost but not the baseband cost significantly.

·        In the TR, at least include a qualitative statement; relevant numerical results can also be considered.

Decision: As per email decision posted on August 27^th, next agreement is confirmed (further to Sony's concern whether such UE feature will not affect the baseband cost significantly),

Agreements:

·        For the baseline UE bandwidth capability of RedCap UEs, the same maximum UE bandwidth in a band applies to both RF and baseband.

o   This maximum UE bandwidth applies to both data and control channels.

o   This maximum UE bandwidth is assumed for both DL and UL.

o   Complexity analyses with other mixes of bandwidths are not precluded.

Final summary in R1-2007331.

8.6.2        Reduced PDCCH monitoring

R1-2005881        On reduced PDCCH monitoring for RedCap UEs Intel Corporation

·        Proposal 1: RAN1 to further discuss appropriate scaling of the power consumption model for 3OS CORESET.

·        Proposal 2: Expand the power consumption model taking into account reduction in maximum number of non-overlapped CCEs.

·        Proposal 3: Target ~50% reduction on the maximum number of monitored PDCCH candidates.

o   FFS: Reduction in maximum number of non-overlapped CCEs per slot and per serving cell

·        Proposal 4: RAN1 to further study simplifications/reduction/constraints related to the following features:

o   Locations of PDCCH monitoring occasions in a slot.

o   Maximum number of CORESETs and SS sets in a BWP.

o   Maximum number of DCI format sizes compared to the “3+1” rule of Rel-15.

o   Overlapping monitoring occasions.

o   Maximum number of DL and UL scheduling DCI formats that a UE may be expected to store.

·        Proposal 5: RAN1 to further study approaches to help mitigate the adverse impact to system-level performance due to reduced PDCCH monitoring capabilities considering impact to scheduling flexibility and user blocking for PDCCH scheduling. At least the following should be considered:

o   Enabling configuration of DCI formats with compact size, smaller than formats 0_0/1_0 for a given DL/UL BWP.

o   Enabling scheduling of multiple PDSCHs/PUSCHs with different TBs using a single DCI format.

Decision: The document is noted.

R1-2006525        Reduced PDCCH Monitoring for RedCap Devices Apple

·        Proposal 1:

o   The maximum number of PDCCH candidates and non-overlapped CCEs for USS should be relaxed for RedCap devices.

o   The number of configurable aggregation levels for NR-lite devices can be further reduced compared to Rel-15 requirement.

·        Proposal 2: RedCap UE should be allowed to support cross-slot scheduling only i.e K0>0 to not only reduce power consumption but also UE complexity.

·        Proposal 3: Capture the power consumption evaluation results in Table 1 into RedCap TR.

Decision: The document is noted.

R1-2005235         Reduced PDCCH monitoring for RedCap     Ericsson

R1-2005270         Power saving for reduced capability devices Huawei, HiSilicon

R1-2005384         Reduced PDCCH monitoring for Reduced Capability NR devices          vivo, Guangdong Genius

R1-2005475         Consideration on reduced PDCCH monitoring            ZTE

R1-2005526         Reduced PDCCH monitoring          Nokia, Nokia Shanghai Bell

R1-2005591         Power savings for RedCap UEs       FUTUREWEI

R1-2005638         Discussion on reduced PDCCH monitoring for NR RedCap UEs            MediaTek Inc.

R1-2005715         Discussion on PDCCH monitoring reduction CATT

R1-2005771         Reduced PDCCH monitoring          TCL Communication Ltd.

R1-2005778         Reduced PDCCH monitoring for REDCAP NR devices            NEC

R1-2005779         Reduced PDCCH Monitoring for RedCap UEs           Fraunhofer HHI, Fraunhofer IIS

R1-2005933         PDCCH monitoring at reduced capability UE              Lenovo, Motorola Mobility

R1-2005969         Discussion on reduced PDCCH monitoring for reduced capability device               Beijing Xiaomi Software Tech

R1-2006037         Discussion on reduced monitoring for PDCCH            OPPO

R1-2006153         Reduced PDCCH monitoring          Samsung

R1-2006218         Discussion on reduced PDCCH monitoring  CMCC

R1-2006286         Discussion on reduced PDCCH monitoring  Spreadtrum Communications

R1-2006307         Discussion on PDCCH monitoring for reduced capability NR devices   LG Electronics

R1-2006539         Reduced PDCCH monitoring for reduced capability NR devices            InterDigital, Inc.

R1-2006683         Reduced PDCCH monitoring for RedCap UE              Sequans Communications

R1-2006734         Discussion on reduced PDCCH monitoring for RedCap            NTT DOCOMO, INC.

R1-2006812         PDCCH Monitoring Reduction and Power Saving for RedCap Devices Qualcomm Incorporated

R1-2006839         PDCCH Monitoring for Reduced Capability Devices GDCNI

R1-2006890         Discussion on PDCCH monitoring for RedCap UE     WILUS Inc.

R1-2006947         On power saving and battery lifetime enhancement for NR Redcap devices               Sony

[102-e-NR-RedCap-02] – Hong (Apple)

Email discussions/approval

·        By 8/20 – high priority

·        By 8/26 – medium

·        By 8/28 – last check

R1-2007030        Feature lead summary #1 on reduced PDCCH monitoring Moderator (Apple Inc.)

Agreements:

·        Use the VoIP traffic model from TR 38.840 as baseline. Other VoIP traffic models are not precluded and companies to report if other VoIP traffic models are assumed in evaluation.

Agreements:

·        For power saving evaluation of RedCap UEs:

o   Reuse the Instant message traffic model from TR 38.840 as baseline. Other Instant traffic models based on FTP model 3 are not precluded and companies to report the mean inter-arrival time and packet size if other instant traffic models are assumed in evaluation.

o   FFS: ‘heartbeat’ traffic model

R1-2007184        Feature lead summary #2 on reduced PDCCH monitoring Moderator (Apple Inc.)

R1-2007284        Feature lead summary #3 on reduced PDCCH monitoring Moderator (Apple Inc.)

From GTW session on August 25^th,

Agreements:

• The scaling factor ‘0.7’ is used for 2 Rx to 1Rx power scaling for power reduction related evaluation.
• For evaluation, the power scaling for PDCCH candidate reduction defined in TR 38.840 is reused for Redcap UEs.
• For power consumption evaluation, the DRX configurations of Instant message and VoIP in TR 38.840 are reused.
• Discussion on reduced maximum number of configurable CORESET technique for power saving is deprioritized in the Redcap power saving sub-agenda
• For power consumption evaluation, use FTP-3 model with 100 Bytes packet size and 60s mean inter-arrival time as baseline for ‘heartbeat’ traffic.
• For power consumption evaluation, reuse the following DRX configuration defined in TS 38.840 for ‘heartbeat’ traffic model:

o   C-DRX cycle 640 msec, inactivity timer {200, 80} msec

o   FR1 On duration: 10 msec

o   FR2 On duration: 5 msec

Agreements: For the PDCCH blocking rate evaluation, at least the following parameters are assumed as baseline:

R1-2007344        Feature lead summary #4 on reduced PDCCH monitoring Moderator (Apple Inc.)

From GTW session on August 28^th,

Agreements: For Redcap power consumption evaluation:

·        Note that 2RX is assumed

Working assumption:

Adopting the following rule for power determination

·        Rule 1: ‘Micro sleep’ power of 1 Rx is [0.8]x2 Rx ‘Micro sleep’ power

·        Rule 2: For both 1 Rx and 2 Rx configuration,

·        P(α) = max (Micro-sleep, α ∙ Pt + (1 – α) ∙ 0.7Pt))

·        Pt is the PDCCH-only power for same slot and cross-slot scheduling cases.

Conclusion: It is up to each company to report the power consumption modeling for 3-symbols CORESET configuration and reduced number of non-overlapped CCEs.  

Final summary in R1-2007426.

8.6.3        Coverage recovery and capacity impact

Including aspects related to evaluations of the impact to coverage, network capacity and spectral efficiency

R1-2005271        Functionality for coverage recovery           Huawei, HiSilicon

·        Proposal 1: PDCCH, PDSCH, PUCCH, PUSCH, msg3 can be considered for coverage evaluation in RedCap SI, any other channels is not needed.

·        Proposal 2: In urban scenario, in addition to TDD band, some FDD band should also be considered for coverage evaluation in RedCap SI.

·        Proposal 3: For the target data rate of PDSCH and PUSCH, in addition to the values discussed in R17 CE SI, the reference bitrate defined for RedCap use cases should also be considered for coverage evaluation in RedCap SI, such as 5Mbps for PDSCH, 2Mbps for PUSCH.

·        Proposal 4: Performance enhancements could be considered for NR RedCap UEs, such as BWP switching in a larger bandwidth, DMRS overhead reduction for stationary UEs and UEs with limited mobility, DCI size reduction for DL and SUL for UL.

Decision: The document is noted.

R1-2005639        Discussion on coverage recovery for NR RedCap UEs          MediaTek Inc.

·        Proposal 1: Coverage compensation mechanisms for NR UL channels are not considered in RedCap NR SI.

·        Proposal 2: Coverage compensation mechanisms for PDSCH are considered of low priority for RedCap NR SI.

·        Proposal 3: If NR coverage is impacted by PDCCH performance loss, techniques for improving the performance of NR PDCCH to compensate the coverage loss due to the reduction of #Rx antennas should be studied.

·        Proposal 4: UE-aware PDCCH repetition schemes are not considered for RedCap NR UEs.

·        Proposal 5: UE-transparent PDCCH repetitions can be considered for RedCap NR UEs.

·        Proposal 6: At initial cell search, a RedCap UE should be allowed to assume a shorter SSB period - 5ms or 10ms - than a normal NR UE currently does (20 ms).

Decision: The document is noted.

R1-2006813        Coverage Recovery for RedCap Devices   Qualcomm Incorporated

·        Proposal 1: For FR1, the coverage recovery for RedCap should target for 3-4 dB improvement in uplink, and 5-7 dB in downlink for two Rx antennas and 8-12 dB for single Rx antenna.

·        Proposal 2: For RedCap coverage evaluation, if the target data rate in the coverage enhancement SI is reused, it should be adjusted lower for the reduced maximum UE bandwidth. In addition, consider using additional target data rates for higher percentile users (e.g., median or cell center).

·        Proposal 3: If link budget is indeed needed, the link budget template in TR 36.824 with necessary revision for including reduced antenna efficiency can be considered

·        Proposal 4: Antenna array gain is included in LLS and the number of transmit and receive chain is equal to the number of TXRUs.

·        Proposal 5: RAN1 should study potential techniques for coverage recovery including time domain repetition, DMRS bundling, frequency hopping and TBS scaling.

·        Proposal 6: For FR2, study power and resource efficient solutions for coverage recovery in FR2, including:

·        Beam refinement

·        Hopping across a larger system frequency range

·        Enhanced L1/L2 inter-cell mobility (optimized to RedCap use cases)

·        Proposal 7: For FR2, study ways to reduce time blockage and/or resources by taking into consideration the larger latency requirements for some use cases.

·        Proposal 8: For FR2, study techniques to reduce the payload size for the L1 measurement report.

Decision: The document is noted. Further revised in R1-2007081.

R1-2005236         Coverage recovery and capacity impact for RedCap   Ericsson

R1-2005278         Coverage recovery for RedCap       FUTUREWEI

R1-2005385         Discussion on functionality for coverage recovery      vivo, Guangdong Genius, GDCNI

R1-2005476         Discussion on coverage recovery for RedCap UE       ZTE

R1-2005527         Functionality for coverage recovery Nokia, Nokia Shanghai Bell

R1-2005581         Coverage recovery and capacity impact of Redcap devices       Sony

R1-2005596         Coverage recovery and capacity impact        Panasonic Corporation

R1-2005716         Discussion on coverage recovery    CATT

R1-2005757         Discussion on coverage recovery and capacity impact NEC

R1-2005772         Coverage recovery and capacity impact        TCL Communication Ltd.

R1-2005831         On coverage recovery for RedCap  Lenovo, Motorola Mobility

R1-2005882         On coverage recovery for RedCap UEs         Intel Corporation

R1-2005970         Discussion on coverage recovery for reduced capability device Beijing Xiaomi Software Tech

R1-2006038         Discussion on functionality for coverage recovery      OPPO

R1-2006154         Coverage recovery for low capability device Samsung

R1-2006219         Discusison on coverage recovery for reduced capability NR devices      CMCC

R1-2006290         Discussion on  coverage recovery and capacity impact              Spreadtrum Communications

R1-2006308         Discussion on the coverage recovery of reduced capability NR devices LG Electronics

R1-2006363         Considerations for coverage recovery            ITL

R1-2006526         Functionality for Coverage Recovery for RedCap       Apple

R1-2006541         PDCCH coverage enhancement for reduced capability NR devices        InterDigital, Inc.

R1-2006577         Coverage recovery for reduced capability UEs            Sharp

R1-2006630         On coverage recovery for reduced capability UEs       Convida Wireless

R1-2006684         Coverage recovery for RedCap UE Sequans Communications

R1-2006735         Discussion on coverage recovery for RedCap              NTT DOCOMO, INC.

R1-2006891         Discussion on Coverage Recovery for RedCap UE     WILUS Inc.

[102-e-NR-RedCap-03] – Chao (Qualcomm)

Email discussions/approval

·        By 8/20 – high priority

·        By 8/26 – medium

·        By 8/28 – last check

R1-2007091        FL summary on coverage recovery and capacity impact for NR RedCap               Moderator (Qualcomm)

Agreements

For the channel(s) affected by complexity reduction, the following methodology can be used to determine the target performance for coverage recovery

·        Step 1: Obtain the link budget performance of the channel based on link budget evaluation

·        Step 2: Obtain the target performance requirement for RedCap UEs within a deployment scenario

o   FFS on the target performance requirement

·        Step 3: Find the coverage recovery value for the channel if the link budget performance is worse than the target performance requirement

Agreement:

·        Link budget evaluation for RedCap should include at least PDCCH/PDSCH and PUCCH/PUSCH

Agreements:

·        For initial access related channels, at least Msg2, Msg3, Msg4 and PDCCH scheduling Msg2/4 are included for link budget evaluation

o   Other initial access related channels are not precluded

Agreements:

·        The impact of small form factor is considered for all the uplink and downlink channels

o   A 3dB loss of antenna gain is included in link budget calculation for FR1

§  FFS on the application to both FDD and TDD bands or only FDD bands

R1-2007153        FL summary#2 on coverage recovery and capacity impact for NR RedCap               Moderator (Qualcomm)

From GTW on August 24^th,

Agreements: Down-selection on the following options for the target performance requirement for RedCap UEs in RAN1#103-e (aim for early in the e-meeting):

·        Option 1: The target performance requirement for each channel is identified by a target MCL or MIL or MPL within a reasonable deployment

·        Option 3: The target performance requirement for each channel is identified by the link budget of the bottleneck channel(s) for the reference NR UE within the same deployment scenario

·        Note: The “bottleneck channel(s)” are the physical channel(s) that have the lowest MCL or MIL or MPL

·        The details for the target performance requirement are FFS

Agreement: For RedCap UE, adopt the following target data rates for link budget evaluation for FR1 Rural.

·        1 Mbps on DL and 100kbps in UL

Agreement: For RedCap UE, down-selection on adopt the following target data rates for link budget evaluation for FR1 Urban.

·        2 Mbps on DL and 1Mbps in UL

Note: The 2Mbps target data rate in downlink is the scaled value of the 10Mbps in the CE SI by a factor of 0.2

Agreements: For RedCap UEs, the target data rates for link budget evaluation for FR2 are as follows:

·        25Mbps for BW 50MHz/100MHz on DL and 5Mbps in UL

o   Optionally, 12.5Mbps for BW 50MHz as the target data rate for DL, assuming the same DL PSD as that of BW 100MHz

o   Note: in case of 50MHz BW, the maximum supported DL data rate is half that of the 100MHz BW in DL

Agreements:

·        For link budget evaluation, the antenna gain loss due to the small form factor can be applied to all the FR1 bands

·        For RedCap coverage analysis, the agreements in the Rel-17 CE SI regarding link budget template and antenna array gain are reused.

o   Continue to discuss and decide the performance metric in RAN1-103 e-meeting

Agreements:

·        For RedCap coverage evaluation, the Rel-17 CE SI agreements on gNB antenna configuration, # gNB Tx/Rx chains, channel model and delay spread are reused with the following revision and/or addition

·        For RedCap coverage evaluation, adopt the following table for the reference NR UE.

·        For RedCap coverage evaluation, adopt the following table for the RedCap UE.

o   Other UE BWs are not precluded

Agreements:

·        For RedCap coverage evaluation, reuse the Rel-17 CE SI agreements on channel specific parameters with the following revision and/or addition

o   TBS/PRB/MCS of PDSCH (except for Msg2)/PUSCH for the RedCap UE are based on the agreed target data rates or message sizes and reported by companies

o   Adopt the following table for Msg2 evaluation

§  Note: the TBS scaling is not precluded in the table entry “PRBs/TBS/MCS”

Agreements:

·        For SLS based capacity evaluation, use the assumption in TR 38.802, Table A.2.1-1 as the baseline.

·        For calibration purposes, the following settings can be used:

Final summary in R1-2007312.

8.6.4        Framework and Principles for Reduced Capability

R1-2005528        Framework and Principles for Reduced Capability              Nokia, Nokia Shanghai Bell

·        Proposal 1: Spare Bits in the DCI used to schedule SIB1, are used to support REDCAP devices in determining:

o   If the cell is REDCAP capable

o   If REDCAP service is barred

·        Proposal 2: RAN1 and RAN2 determine if a separate SIB1 for REDCAP devices, R-SIB1, is specified.

·        Proposal 3: If a separate R-SIB1 is specified for REDCAP devices, spare bits in the DCI that are used to schedule SIB1, are used to support REDCAP devices in determining:

o   The scheduling of R-SIB1

Decision: The document is noted.

R1-2005237         Framework and principles for RedCap          Ericsson

R1-2005279         Framework for RedCap UEs            FUTUREWEI

R1-2005386         Framework and Principles for Reduced Capability     vivo, Guangdong Genius

R1-2005477         Views on Framework and Principles for Reduced Capability   ZTE

R1-2005640         On the framework for RedCap UEs MediaTek Inc.

R1-2005717         Framework and principles for reduced capability NR devices  CATT

R1-2005832         On Framework and Principles for RedCap    Lenovo, Motorola Mobility

R1-2005883         Introducing NR RedCap UEs: Overall framework      Intel Corporation

R1-2005971         Discussion on framework and principles for reduced capability device  Beijing Xiaomi Software Tech

R1-2006039         Consideration on reduced UE capability       OPPO

R1-2006155         Framework and Principles for Reduced Capability     Samsung

R1-2006220         Discussion on principles and framework of reduced capability NR         CMCC

R1-2006287         Discussion on Framework and Principles for Reduced Capability           Spreadtrum Communications

R1-2006309         Consideration on the framework to support reduced capability NR devices          LG Electronics

R1-2006388         Discussion on Framework and Principles for Reduced Capability           Panasonic

R1-2006406         Framework and principles for reduced capability devices         Huawei, HiSilicon

R1-2006686         Framework and principles for RedCap UE    Sequans Communications

R1-2006814         Standardization Framework and Design Principles for RedCap Devices Qualcomm Incorporated

[102-e-NR-RedCap-04] – Shinya (NTT DOCOMO)

Email discussions/approval by 8/26

R1-2007330        Summary on [102-e-NR-RedCap-04]         Moderator (NTT DOCOMO)

Agreement:

·        Studying how to constrain RedCap devices to be used only for the intended use cases is deprioritized in RAN1 

From 8/28 GTW

Agreement: Discussion on whether to study CA case is deprioritized for reduced capability UEs in Rel. 17 SI and it will not start until maximum UE channel bandwidth is clear.

8.6.55        Other

Including RAN2-led aspect on allowing devices with reduced capabilities to be explicitly identifiable to networks and network operators, and allow operators to restrict their access, if desired

R1-2006040        Other considerations for reduced UE capability     OPPO

·        Proposal 1: Two RedCap UEs types with different key requirements are defined for RedCap in Rel-17.

·        Proposal 2: Use case/device type orientated RedCap UEs features should be studied and defined.

Decision: The document is noted.

R1-2005238         Identification and access restriction for RedCap          Ericsson

R1-2005387         RRM relaxation for Reduced Capability NR devices  vivo, Guangdong Genius

R1-2005478         Discussion on access control for Reduced Capability NR devices           ZTE

R1-2005718         Identification and access restriction for reduced capability NR devices  CATT

R1-2005934         Aspects related to bandwidth reduction         Lenovo, Motorola Mobility

R1-2005960         CBW for RedCap NEC

R1-2005972         Discussion on the access control and configuration for reduced capability device               Beijing Xiaomi Software Tech

R1-2006156         Access barring and UE capability   Samsung

R1-2006270         Consideration on power saving for reduced capability NR devices         Spreadtrum Communications

R1-2006310         Support and control of initial cell access for reduced capability NR devices         LG Electronics

R1-2006411         Other aspects for reduced capability devices Huawei, HiSilicon

R1-2006687         Access restriction for reduced capability NR devices InterDigital, Inc.

[102-e-NR-RedCap-05] – Debdeep (Intel)

Email discussiona/approval by 8/26

R1-2007283        Summary on [102-e-NR-RedCap-05]         Moderator (Intel)

Decision: As per email decision posted on August 26^th,

Agreements:

·        Further study the options for identification of RedCap UEs, including at least the following indication methods:

o   Opt. 1: During Msg1 transmission, e.g., via separate initial UL BWP, separate PRACH resource, or PRACH preamble partitioning.

o   Opt. 2: During Msg3 transmission.

o   Opt. 3: Post Msg4 acknowledgment.

§  E.g., during Msg5 transmission or part of UE capability reporting.

o   Opt. 4: During MsgA transmission (subject to support of if 2-step RACH)

o   Other options are not precluded.

o   Note: This study intends to establish feasibility of, and pros and cons for the identified options from RAN1 perspective, without any intention of down-selection without guidance from RAN2.

Conclusion:

·        RAN1 to wait for further progress in RAN2 on the issues of temporary access barring and congestion control.

Conclusion:

·        RAN1 to defer to RAN2 for further progress on studies regarding RRM relaxations and E-DRx for RedCap UEs to facilitate reduced UE power consumption.

Conclude on the following proposed conclusion by 8/27

·        Potential studies on the need for supporting use of a DL BWP, that may be different from initial DL BWP defined by the SSB and CORESET 0, for SIB and/or other common control (RAR, paging) transmissions to RedCap UEs including those in Idle/Inactive modes, can be pursued in AI 8.6.1 as part of Reduced UE BW support

Decision: As per email decision posted on August 27^th, no formal conclusion – therefore no additional update.

 RAN1#103-e

8.6       Study on Support of Reduced Capability NR Devices

Please refer to RP-201677 for detailed scope of the SI

R1-2007482        FL summary on initial collection of RedCap evaluation results         Moderator (Ericsson, Apple, Qualcomm)

Decision: The document (outcomes from last meeting post-email discussion) is noted. The collection of evaluation results continues in email discussion [103-e-NR-RedCap-EvaluationResults]

R1-2009293        FL summary on RedCap evaluation results             Moderator (Ericsson, Apple, Qualcomm)

Decision: The document is noted and captures the RedCap study item evaluation results collected in the email discussion [103-e-NR-RedCap-EvaluationResults] for TR 38.875.

TR

R1-2007528        TR38.875 skeleton updates for Study on support of reduced capability NR devices  Rapporteur (Ericsson)

Decision: The draft TR update (v0.0.3) in x7528 is endorsed, except the update in Section 3.1.

[103-e-NR-RedCap-01] – Johan (Ericsson)

Email discussion for TR38.875 update

• 1^st check point: 10/29 (particularly related to any previous agreements)
• 2^nd check point: 11/12 further update based on the progress during this e-meeting.

Decision: As per email decision posted on Nov.2^nd, the following definition for RedCap UE is endorsed:

·        RedCap UE: For convenience only, a RedCap UE refers to a NR UE with reduced capabilities with details described herein.

R1-2009843        FL summary #1 for TR38.875 update for RedCap Moderator (Ericsson)

TR is endorsed as v0.0.3 in:

R1-2009490        TR38.875 v0.0.3 Study on support of reduced capability NR devices Rapporteur (Ericsson)

R1-2009844        FL summary #2 for TR38.875 update for RedCap Moderator (Ericsson)

R1-2009850        TR38.875 v0.1.0 Study on support of reduced capability NR devices Rapporteur (Ericsson)

Decision: As per email decision posted on Nov.20^th, TR v0.1.0 is endorsed as baseline for future updates – to be submitted for information to next plenary.

8.6.1        Potential UE complexity reduction features

R1-2008837         Potential UE complexity reduction features for RedCap            Ericsson (rev of R1-2007529)

R1-2007534         Complexity reduction features for RedCap UEs          FUTUREWEI

R1-2009318         Potential UE complexity reduction features  Huawei, HiSilicon             (rev of R1-2007596)

R1-2009212         Complexity reduction for Reduced Capability NR devices       vivo, Guangdong Genius   (rev of R1-2007668)

R1-2007715         Potential UE complexity reduction features  ZTE

R1-2007862         Discussion on UE complexity reduction features        CATT

R1-2007887         Potential UE complexity reduction features  TCL Communication Ltd.

R1-2009025         On potential UE complexity reduction features for RedCap      Intel Corporation (rev of R1-2007947)

R1-2008016         Discussion on  UE complexity reduction features       CMCC

R1-2008048         Discussion on potential UE complexity reduction features        LG Electronics

R1-2008068         UE complexity reduction features   Nokia, Nokia Shanghai Bell

R1-2008857         Discussion on the complexity reduction for reduced capability device   Xiaomi  (rev of R1-2008084)

R1-2008100         Discussion on potential UE complexity reduction features        Spreadtrum Communications

R1-2008114         Discussion on bandwidth related features for RedCap devices  NEC

R1-2008875         UE complexity reduction  Samsung              (rev of R1-2008170)

R1-2008260         Discussion on UE complexity reduction        OPPO

R1-2008294         UE complexity reduction features for RedCap             Lenovo, Motorola Mobility

R1-2008315         Reduced Capability UE Complexity Reduction Features           Sierra Wireless, S.A.

R1-2008366         On potential complexity reduction techniques for NR devices  Sony

R1-2008382         Discussion on potential UE complexity reduction features        Panasonic Corporation

R1-2008394         Discussion on Potential UE complexity reduction features       Sharp

R1-2008469         Potential UE complexity reduction features for RedCap            Apple

R1-2009543         On complexity reduction features for NR RedCap UEs             MediaTek Inc.     (rev of R1-2008510)

R1-2008551         Discussion on potential UE complexity reduction features for RedCap  NTT DOCOMO, INC.

R1-2008581         Discussion on potential UE complexity reduction features        ASUSTeK

R1-2008620         Complexity Reduction for RedCap Devices  Qualcomm Incorporated

R1-2008684         UE complexity reduction features for reduced capability NR devices     InterDigital, Inc.

R1-2008738         Complexity reduction features for RedCap UE            Sequans Communications

R1-2008869        FL summary #1 for Potential UE complexity reduction features for RedCap               Moderator (Ericsson)

Decision: Noted. From GTW on 10/26:

[103-e-NR-RedCap-02] – Johan (Ericsson)

Email discussion for potential UE complexity reduction features

• 1^st check point: 10/29
• 2^nd check point: 11/4
• 3^rd check point: 11/10
• Last check point 11/12, extended to 11/17

R1-2009391        FL summary #2 for Potential UE complexity reduction features for RedCap               Moderator (Ericsson)

R1-2009393        FL summary #3 for Potential UE complexity reduction features for RedCap               Moderator (Ericsson)

Agreements:

For evaluating complexity reduction, to come up with a set of combinations of techniques:

·        For each case (FR1 FDD, FR1 TDD, & FR2), target up to 6 to 8 combinations

o   Detailed combinations are FFS

Decision: As per email decision posted on Nov. 5^th,

Agreements:

·        Adopt the TP in R1-2009393 as baseline text for TR clause 7.2.1.

·        Adopt the TP in R1-2009393 for TR clause 7.3.1.

·        Adopt the TP in R1-2009393 as baseline text for TR clause 7.3.2.

o   Companies are invited to double-check their entries in the cost reduction spreadsheet with respect to the above comments (and to catch potential typos).

o   The table will be further updated with potential updated cost estimates.

·        Capture the recommendation that maximum bandwidth of an FR1 RedCap UE is 20 MHz during and after initial access.

o   FFS: Whether an FR1 RedCap UE can optionally support a maximum bandwidth larger than 20 MHz after initial access

·        Adopt the TP in R1-2009393 as baseline text for TR clause 7.4.1.

·        Adopt the updated TP in R1-2009393 as baseline text for TR clause 7.6.1

·        Adopt the updated TP in R1-2009393 as baseline text for TR clause 7.6.2.

·        Adopt the TP in R1-2009393 as baseline text for TR clause 7.7.2.

o   Companies are invited to double-check their entries in the cost reduction spreadsheet with respect to the above comments (and to catch potential typos).

o   The table will be further updated with potential updated cost estimates.

From GTW:

Working assumption:

·        Support that the maximum bandwidth of an FR2 RedCap UE is 100 MHz during initial access and 100MHz after initial access.

Agreements:

For TR section 7.2.2 (on reduced number of Rx antennas), the following combinations of complexity reduction techniques are evaluated.

• FR1 FDD: 1 layer, 1 Rx
• FR1 TDD: 1 layer, 1 Rx
• FR1 TDD: 2 layers, 2 Rx
• FR2: 1 layer, 1 Rx

Agreements: For FR1 FDD, the following combinations of complexity reduction techniques are evaluated:

• 1 layer, 1 Rx, 20 MHz
• 1 layer, 1 Rx, 20 MHz, HD-FDD type A
• 1 layer, 1 Rx, 20 MHz, relaxed modulations for DL & UL
• 1 layer, 1 Rx, 20 MHz, doubled processing time for N1 & N2 only
• 1 layer, 1 Rx, 20 MHz, relaxed modulations for DL & UL, doubled processing time for N1 & N2 only
• 1 layer, 1 Rx, 20 MHz, relaxed modulations for DL & UL, HD-FDD type A, doubled processing time for N1 & N2 only
• 2 layers, 2 Rx, 20 MHz, HD-FDD type A
• 2 layers, 2 Rx, 20 MHz, doubled processing time for N1 & N2 only

Agreements: For FR1 TDD, the following combinations of complexity reduction techniques are evaluated:

• 1 layer, 1 Rx, 20 MHz
• 1 layer, 1 Rx, 20 MHz, relaxed modulations for DL & UL
• 1 layer, 1 Rx, 20 MHz, doubled processing time for N1 & N2 only
• 1 layer, 1 Rx, 20 MHz, relaxed modulations for DL & UL, doubled processing time for N1 & N2 only
• 2 layers, 2 Rx, 20 MHz
• 2 layers, 2 Rx, 20 MHz, relaxed modulations for DL & UL
• 2 layers, 2 Rx, 20 MHz, doubled processing time for N1 & N2 only
• 2 layers, 2 Rx, 20 MHz, relaxed modulations for DL & UL, doubled processing time for N1 & N2 only

Agreements: For FR2, the following combinations of complexity reduction techniques are evaluated:

• 1 layer, 1 Rx, 100 MHz
• 1 layer, 1 Rx, 100 MHz, relaxed modulations DL & UL
• 1 layer, 1 Rx, 100 MHz, doubled processing time for N1 & N2 only
• 1 layer, 1 Rx, 100 MHz, relaxed modulations DL & UL, doubled processing time for N1 & N2 only
• 2 layers, 2 Rx, 100 MHz, relaxed modulations DL & UL
• 2 layers, 2 Rx, 100 MHz, doubled processing time for N1 & N2 only

·        2 layers, 2 Rx, 100 MHz, relaxed modulations DL & UL, doubled processing time for N1 & N2 only

R1-2009394        FL summary #4 for Potential UE complexity reduction features for RedCap               Moderator (Ericsson)

Decision: As per email decision posted on Nov. 9^th,

Agreement:

·        Adopt the updated TP in x9394 for TR clause 7.7.1

From GTW:

Agreement: For averaging of cost estimates, take the average of all values

R1-2009651        FL summary #5 for Potential UE complexity reduction features for RedCap               Moderator (Ericsson)

Decision: As per email decision posted on Nov. 11^th,

Agreements (see R1-2009651 for the TPs)

·        Adopt the updated TP above for TR clause 6.1.

·        Adopt the above description of the benefit of reduced number of UE Rx branches in terms of reducing the device size in FR1 as a baseline text for TR 38.875.

·        Adopt the above description of the benefit of reduced number of UE Rx branches in terms of reducing the device size in FR2 as a baseline text for TR 38.875.

·        Adopt the TP above as baseline text for TR clause 7.4.2.

·        Adopt the above description of the benefit of HD-FDD operation in terms of reducing the device size in FR1 FDD as a baseline text for TR 38.875.

·        Adopt the TP above as baseline text for TR clause 7.5.1.

·        Adopt the TP above as baseline text regarding relaxed CSI computation, either in TR clause 7.5.1 or in a TR (sub)clause on relaxed CSI computation.

·        Adopt the TP above as baseline text for TR clause 7.5.2.

·        Confirm the working assumption: Support that the maximum bandwidth of an FR2 RedCap UE is 100 MHz during initial access and 100MHz after initial access.

·        Adopt the TPs corresponding to Questions 7.2.3-2/3a/4a/5a/7a in R1-2009651

·        Adopt the TPs corresponding to Questions 7.3.3-2/3a/5a/7a in R1-2009651

·        Adopt the TPs corresponding to Questions 7.4.3-2a/3a/6/7a in R1-2009651

·        Adopt the TP corresponding to Question 7.5.3-3a in R1-2009651

·        Adopt the TPs corresponding to Questions 7.6.3-2/3a/4a/5a in R1-2009651

·        Adopt the TPs corresponding to Questions 7.7.3-2/4a/5/6a in R1-2009651

From GTW:

Agreements:

·        For FR1 FDD bands where a non-RedCap UE is required to be equipped with a minimum of 2 Rx branches,

·        The minimum number of Rx branches supported by specification for a RedCap UE is 1.

·        Specification also supports of 2 Rx branches for a RedCap UE.

Agreements:

·        For FR1 TDD bands where a non-RedCap UE is required to be equipped with a minimum of 4 Rx branches, the minimum number of Rx branches supported by specification for a RedCap UE is N. To be down-selected during the WI phase or at RAN plenary:

o   Alt 1: N=2

o   Alt 2: N=1, where N=2 is also supported

Agreements:

·        For FR1 FDD bands where a non-RedCap UE is required to be equipped with a minimum of 2 Rx branches,

o   For a RedCap UE with 1 Rx branch, the maximum number of DL MIMO layers is 1.

o   For a RedCap UE with 2 Rx branches, the maximum number of DL MIMO layers is M. Down-select between the following during the WI phase or at RAN plenary

§  Option 1: M=1, where M=2 is also supported

§  Option 2: M=2

Agreements:

·        For FR1 TDD bands where a non-RedCap UE is required to be equipped with a minimum of 4 Rx branches,

o   For a RedCap UE with 1 Rx branch (if supported), the maximum number of DL MIMO layers is 1.

o   For a RedCap UE with 2 Rx branches, the maximum number of DL MIMO layers is M. Down-select between the following options during the WI phase or at RAN plenary

§  Option 1: M=1, where M=2 is also supported

§  Option 2: M=2

Agreements:

• For FR2 bands where a non-RedCap UE is required to be equipped with a minimum of 2 Rx branches,
• For a RedCap UE with 1 Rx branch (if supported), the maximum number of DL MIMO layers is 1.
• For a RedCap UE with 2 Rx branches (if supported), the maximum number of DL MIMO layers is M. Down-select between the following options during the WI phase or at RAN plenary:
• Option 1: M=1, where M=2 is also supported
• Option 2: M=2

Agreements:

·        Recommend that HD-FDD type B is not supported for RedCap FR1 FDD UEs in Rel-17.

·        Decide at RAN plenary whether to have support FD-FDD or HD-FDD type A or both by specification for an FR1 FDD RedCap UE

Agreement:

·        Decide at RAN plenary whether to support relaxed UE processing time in terms of N1/N2 by specification for a RedCap UE.

Agreements:

·        Recommend that support of 256QAM in DL is optional (instead of mandatory) for a FR1 RedCap UE.

·        Recommend that relaxed maximum mandatory UL modulation (from 64QAM to 16QAM) is not supported by specification for an FR1 RedCap UE.

·        Recommend that relaxed maximum mandatory DL modulation (from 64QAM to 16QAM) is not supported by specification for an FR2 RedCap UE.

·        Recommend that relaxed maximum mandatory UL modulation (from 64QAM to 16QAM) is not supported by specification for an FR2 RedCap UE.

R1-2009652        FL summary #6 for Potential UE complexity reduction features for RedCap               Moderator (Ericsson)

Decision: As per email decision posted on Nov. 13^th,

Agreements:

·        For FR2 bands where a non-RedCap UE is required to be equipped with a minimum of 2 Rx branches,

o   The minimum number of Rx branches supported by specification for a RedCap UE is 1.

o   Specification also supports of 2 Rx branches for a RedCap UE.

·        Agree the following TPs in R1-2009652 as baseline for TR 38.875:

o   TP on introduction to UE complexity reduction features in Question 7.1-1

o   TP for TR clause 7.2.2 in Question 7.2.2-1d

o   TP on observations of the impact on coverage for UE with relaxed UE processing time in Question 7.5.3-2a

o   TP on observation of the coexistence impacts for UE with relaxed maximum number of MIMO layers in Question 7.6.4-2

o   TP on observation of specification impacts for UE with relaxed maximum number of MIMO layers in Question 7.6.5-2

o   TP on observations of the impact on network capacity and spectral efficiency for UE with relaxed maximum modulation orders in Question 7.7.3-3a

o   TP on observation of coexistence impacts for UE with relaxed maximum modulation orders in Question 7.7.4-2

o   TP on description of combinations of UE complexity reduction techniques in Question 7.8.1-1

o   TP for TR clause 7.8.2 in Proposal 7.8.2-1a

o   TP on performance impacts for combinations of UE complexity reduction techniques in Question 7.8.3-2

o   TP on coexistence impacts for combinations of UE complexity reduction techniques in Question 7.8.4-1

o   TP on specification impacts for combinations of UE complexity reduction techniques in Question 7.8.5-1

R1-2009795        FL summary #7 for Potential UE complexity reduction features for RedCap               Moderator (Ericsson)

Decision: As per email decision posted on Nov. 14^th,

Agreements:

·        Agree the following TPs in R1-2009795 as baseline for TR 38.875:

o   TP on observations of specification impacts of UE bandwidth reduction in Question 7.3.5-2a

o   TP on observations of the impact on latency and reliability for UE with relaxed UE processing time in Question 7.5.3-5b

o   TP on observations of specification impacts for UE with relaxed maximum modulation orders in Question 7.7.5-2a

o   TP on peak data rate impacts for combinations of UE complexity reduction techniques in Question 7.8.3-1a

R1-2009803        FL summary #8 for Potential UE complexity reduction features for RedCap               Moderator (Ericsson)

Decision: As per email decision posted on Nov. 18^th,

Agreements:

·        Adopt the TP in section 2 of R1-2009803 as baseline text for TR 38.875.

·        Adopt the TP in section 3 of R1-2009803 as baseline text for TR 38.875.

8.6.2        Reduced PDCCH monitoring

R1-2007530         Reduced PDCCH monitoring for RedCap     Ericsson

R1-2007535         Power savings for RedCap UEs       FUTUREWEI

R1-2007597         Power saving for reduced capability devices Huawei, HiSilicon

R1-2007625         Discussion on PDCCH monitoring reduction for RedCap UEs Panasonic

R1-2007669         Reduced PDCCH monitoring for Reduced Capability NR devices          vivo, Guangdong Genius

R1-2007716         Consideration on reduced PDCCH monitoring            ZTE

R1-2007863         Discussion on PDCCH monitoring reduction CATT

R1-2007888         Reduced PDCCH monitoring          TCL Communication Ltd.

R1-2007948         On reduced PDCCH monitoring for RedCap UEs       Intel Corporation

R1-2008017         Discussion on PDCCH monitoring reduction CMCC

R1-2008049         Discussion on PDCCH monitoring for reduced capability NR devices   LG Electronics

R1-2008069         Reduced PDCCH monitoring          Nokia, Nokia Shanghai Bell

R1-2008085         Discussion on reduced PDCCH monitoring for reduced capability device               Xiaomi

R1-2008105         Discussion on reduced PDCCH monitoring  Spreadtrum Communications

R1-2008115         Reduced PDCCH monitoring for REDCAP NR devices            NEC

R1-2008171         Reduced PDCCH monitoring          Samsung

R1-2008894         Solutions of reduced PDCCH monitoring     OPPO     (rev of R1-2008261)

R1-2008336         PDCCH monitoring at reduced capability UE              Lenovo, Motorola Mobility

R1-2008395         Reduced PDCCH Monitoring for RedCap Devices     Sharp

R1-2008470         Reduced PDCCH Monitoring for RedCap Devices     Apple

R1-2008511         Discussion on reduced PDCCH monitoring for NR RedCap UEs            MediaTek Inc.

R1-2008552         Discussion on reduced PDCCH monitoring for RedCap            NTT DOCOMO, INC.

R1-2008621         PDCCH Monitoring Reduction and Power Saving for RedCap Devices Qualcomm Incorporated

R1-2008685         Reduced PDCCH monitoring for reduced capability NR devices            InterDigital, Inc.

R1-2008712         Reduced PDCCH Monitoring for RedCap UEs           Fraunhofer HHI, Fraunhofer IIS

R1-2008727         Discussion on PDCCH monitoring for RedCap UE     WILUS Inc.

R1-2008739         Reduced PDCCH monitoring for RedCap UE              Sequans Communications

R1-2008471        Feature lead summary #1 on reduced PDCCH monitoring Moderator (Apple)

Decision: Noted. From GTW on 10/26:

[103-e-NR-RedCap-03] – Hong (Apple)

Email discussion for reduced PDCCH monitoring

• 1^st check point: 10/29
• 2^nd check point: 11/4
• 3^rd check point: 11/10
• Last check point 11/12, extended to 11/17

R1-2009370        Feature lead summary #2 on reduced PDCCH monitoring Moderator (Apple)

Agreements:

• To include description of the evaluated schemes #1/#2/#3 as in R1-2009370 to the TR
• Further discussion the detailed text proposal for these schemes
• Note: the description for scheme #1 is taken as a higher priority than #2/#3

Agreements:

·        Determine the Xx (smallest power saving gain)-Yy (largest power saving gain) value based on the smallest and largest values reported by each company at least considering:

o   Separate observations with corresponding Xx-Yy values are captured at least for cross-slot and same slot scheduling cases.

o   Separate observations for FR1 & FR2

o   Additonal cases for separate observations

·        Capture average/mean value of Xx-Yy excluding the smallest and the largest values among companies.

·        Explicitly mention the result/observations if it was provided by a few source companies e.g. 1 or 2 with special setup or assumptions.

·        Highlighting the gain is compared to the UE with configuring the maximum blind decoding for PDCCH monitoring defined in Rel-15/Rel-16

R1-2009411        Feature lead summary #3 on reduced PDCCH monitoring Moderator (Apple)

R1-2009493        Feature lead summary #4 on reduced PDCCH monitoring Moderator (Apple)

Agreements:

Incorporate the revised Table 2A/2B and Table 3A/3B in R1-2009493 into Redcap TR 38.875 as baseline. 

·        It is up to TR editor to use a separate excel sheet to include these Tables or directly capture these tables for inclusion in the TR.

·        The table will be further updated with potential updated power saving gain results.   

Agreements:

For FR1, capture the following observations in the TR (editorial modifications by TR editor can be made for inclusion in the TR)

·        11 sources ([vivo], [Ericsson], [Qualcomm], [CATT], [Spreadtrum], [OPPO], [Huawei, HiSilicon], [Apple], [Futurewei],[Intel], [ZTE]) reported the evaluation results of power saving gain for FR1 with same-slot scheduling for the 1 Rx antenna case.

The following is observed for 1 Rx antenna case:

o   For the instant message traffic model, with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50%, the power saving gains are in the range of approximately [0.7%~5.7%] and [1.3%~11.4%], respectively.  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50% are approximately 2.84% and 5.91%, respectively.

o   For the heartbeat traffic model with 200ms inactivity timer configuration, with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50%, the power saving gains are in the range of approximately [0.01%~3.40%] and [0.02%~6.80%], respectively. With excluding the smallest and the largest values among sources, the mean value of power saving gain by reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50% are approximately 1.59% and 3.33%, respectively.

o   For the heartbeat traffic model with 80ms inactivity timer configuration, with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50%, the power saving gains are in the range of approximately [0.01%~3.20%] and [0.02%~6.40%], respectively.  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50% are approximately 1.41% and 3.06%, respectively.

o   For the VoIP traffic model, with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50%, the power saving gains are in the range of approximately [0.90%~3.88%] and [1.82%~6.48%], respectively. With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50% are approximately 2.59% and 4.74%, respectively.

·        13 sources ([vivo], [Ericsson], [Qualcomm], [Nokia], [CATT], [Spreadtrum], [OPPO], [Huawei, HiSilicon], [Apple], [Futurewei], [Intel], [ZTE], [InterDigital]) reported the evaluation results of power saving gain for FR1 with same-slot scheduling for 2 Rx antennas cases.

The following is observed for 2 Rx antennas case:

o   For the instant message traffic model, with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50%, the power saving gains are in the range of approximately [0.64%~6.20%] and [1.55%~12.30%], respectively.  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50% are approximately 3.20% and 6.85%.

o   For the heartbeat traffic model with 200ms inactivity timer configuration, with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50%, the power saving gains are in the range of approximately [0.01%~4.10%] and [0.02%~8.20%], respectively.  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50% are approximately 1.65% and 3.92%, respectively.

o   For the heartbeat traffic model with 80ms inactivity timer configuration maximum PDCCH blind decoding (i.e. 36) by 25% and 50%, the power saving gains are in the range of approximately [0.01%~3.90%] and [0.02%~7.80%], respectively.  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50% are approximately 1.49% and 3.62%, respectively.

o   For the VoIP traffic model, with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50%, the power saving gains are in the range of approximately [??%-??%] and [??%~??%].  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50% are approximately 2.85% and 5.66%, respectively.

Agreements:

For FR1, capture the following observations in the TR (editorial modifications by TR editor can be made for inclusion in the TR)

·        8 sources ([vivo], [Ericsson], [Samsung], [Qualcomm], [OPPO], [Apple], [ZTE], [MediaTek]) reported the evaluation results of power saving gain for FR1 with cross-slot scheduling for the 1 Rx antenna and 2 Rx antennas cases.

The following is observed for 1 Rx antenna case:

o   For the instant message traffic model, with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50%, the power saving gains are in the range of approximately [0.66%~4.5%] and [0.81%~9%], respectively. With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50% are approximately 2.79% and 4.64%, respectively.

o   For the heartbeat traffic model with 200ms inactivity timer configuration, with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50%, the power saving gains are in the range of approximately [0.01%~2.7%] and [0.01%~5.5%], respectively  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing 36 PDCCH blind decoding by 25% and 50% are approximately 1.81% and 3.26%, respectively.

o   For the heartbeat traffic model with 80ms inactivity timer configuration, with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50%, the power saving gains are in the range of approximately [0.01%~2.6%] and [0.01%~5.1%], respectively.  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50% are approximately 1.8% and 3.35%, respectively.

o   For the VoIP traffic model, with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50%, the power saving gains are in the range of approximately [0.87%~4.5%] and [1.39%~7%], respectively.  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50% are approximately 2.29% and 3.20%, respectively.

The following is observed for 2 Rx antennas case:

o   For the instant message traffic model, with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50%, the power saving gains are in the range of approximately [0.77%~4.69%] and [1.44%~9.38%], respectively. With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50% are approximately 3.31% and 6.13%, respectively.

o   For the heartbeat traffic model with 200ms inactivity timer configuration, with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50%, the power saving gains are in the range of approximately [0.01%~2.9%] and [0.02%~5.7%], respectively  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50% are approximately 1.95% and 3.51%, respectively.

o   For the heartbeat traffic model with 80ms inactivity timer configuration, with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50%, the power saving gains are in the range of approximately [0.01%~2.5%] and [0.02%~4.94%], respectively.  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50% are approximately 1.69% and 3.21%, respectively.

o   For the VoIP traffic model, with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50%, the power saving gains are in the range of approximately [0.83%~3.5%] and [1.65%~6.07%], respectively.  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50% are approximately 2.28% and 4.45%, respectively.

·        In general, it is expected that the power saving gain by BD reduction for cross-slot scheduling is less than that of the same-slot scheduling.

·        In general, it is expected that the power saving gain by BD reduction for 1 Rx case is less than that of the 2 Rx case.

Agreements:

Incorporate the revised Table 4A/4B and Table 5A/5B in R1-2009493 into Redcap TR 38.875.

·        It is up to TR editor to use a separate excel sheet to include these Tables or directly capture these tables for inclusion in the TR.

·        The table will be further updated with potential updated power saving gain results.   

·        Note for Tables 4A & 5A, with the following update

·        1 packet requires 1 PDSCH for Heartbeat traffic model; 1 packet requires 24 16 PDSCHs for IM model, assuming cell center UE.

Agreements:

Fo FR2, capture the following observations in the TR (editorial modifications by TR editor can be made for inclusion in the TR)

·        6 sources ([Ericsson], [CATT], [Spreadtrum], [Futurewei], [Intel], [ZTE]) reported the evaluation results of power saving gain for FR2 with same-slot scheduling for the 1 Rx antenna and 2 Rx antennas cases.

The following is observed for 1 Rx antenna case:

o   For the instant message traffic model, with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50%, the power saving gains are in the range of approximately [1.94%~6.6%] and [3.59%~13.1%], respectively.  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50% are approximately 4.77% and 9.60%, respectively.

o   For the heartbeat traffic model with 200ms inactivity timer configuration, with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50%, the power saving gains are in the range of approximately [0.03%~4.30%] and [0.07%~8.60%], respectively. With excluding the smallest and the largest values among sources, the mean value of power saving gain by reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50% are approximately 2.14% and 4.41%, respectively.

o   For the heartbeat traffic model with 80ms inactivity timer configuration, with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50%, the power saving gains are in the range of approximately [0.03%~4%] and [0.06%~7.9%], respectively.  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50% are approximately 1.60% and 3.21%, respectively.

o   For the VoIP traffic model, with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50%, the power saving gains are in the range of approximately [2.52%~5%] and [4.66%~9.4%], respectively. With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50% are approximately 3.81% and 7.43%, respectively.

The following is observed for 2 Rx antennas case:

o   For the instant message traffic model, with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50%, the power saving gains are in the range of approximately [2.45%~6.8%] and [4.54%~13.6%], respectively.  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50% are approximately 4.94% and 9.87%, respectively.

o   For the heartbeat traffic model with 200ms inactivity timer configuration, with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50%, the power saving gains are in the range of approximately [0.04%~4.90%] and [0.10%~11.90%], respectively. With excluding the smallest and the largest values among sources, the mean value of power saving gain by reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50% are approximately 2.55% and 4.95%, respectively.

o   For the heartbeat traffic model with 80ms inactivity timer configuration, with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50%, the power saving gains are in the range of approximately [0.04%~4.6%] and [0.09%~9.2%], respectively.  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50% are approximately 2.38% and 4.64%, respectively.

o   For the VoIP traffic model, with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50%, the power saving gains are in the range of approximately [3.10%~5.5%] and [5.74%~10.5%], respectively. With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50% are approximately 4.27% and 8.27%, respectively.

Agreements:

For FR2, capture the following observations in the TR (editorial modifications by TR editor can be made for inclusion in the TR)

·        4 sources ([Ericsson], [Samsung], [ZTE], [MediaTek]) reported the evaluation results of power saving gain for FR2 with cross-slot scheduling for the 1 Rx antenna and 2 Rx antennas cases.

The following is observed for 1 Rx antenna case:

o   For the instant message traffic model, with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50%, the power saving gains are in the range of approximately [1.40%~6.30%] and [2.70%~12.7%], respectively.  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50% are approximately 3.64% and 7.04%, respectively.

o   For the heartbeat traffic model with 200ms inactivity timer configuration, with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50%, the power saving gains are in the range of approximately [0.02%~4.20%] and [0.04%~8.30%], respectively. With excluding the smallest and the largest values among sources, the mean value of power saving gain by reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50% are approximately 1.30% and 2.60%, respectively.

o   For the heartbeat traffic model with 80ms inactivity timer configuration, with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50%, the power saving gains are in the range of approximately [0.02%~3.9%] and [0.04%~7.6%], respectively.  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50% are approximately 1.24% and 2.48%, respectively.

o   For the VoIP traffic model, with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50%, the power saving gains are in the range of approximately [1.94%~6.5%] and [3.6%~13.1%], respectively. With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50% are approximately 3.27% and 6.33%, respectively.

The following is observed for 2 Rx antennas case:

o   For the instant message traffic model, with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50%, the power saving gains are in the range of approximately [1.89%~6.6%] and [3.50%~13.20%], respectively.  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50% are approximately 3.81% and 7.37%, respectively.

o   For the heartbeat traffic model with 200ms inactivity timer configuration, with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50%, the power saving gains are in the range of approximately [0.03%~4.90%] and [0.07%~9.60%], respectively. With excluding the smallest and the largest values among sources, the mean value of power saving gain by reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50% are approximately 1.56% and 3.13%, respectively.

o   For the heartbeat traffic model with 80ms inactivity timer configuration, with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50%, the power saving gains are in the range of approximately [0.03%~4.6%] and [0.06%~8.9%], respectively.  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50% are approximately 1.37% and 2.74%, respectively.

o   For the VoIP traffic model, with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50%, the power saving gains are in the range of approximately [1.97%~6.8%] and [3.95%~13.7%], respectively. With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 20) by 25% and 50% are approximately 3.38% and 6.52%, respectively.

·        In general, it is expected that the power saving gain by BD reduction for cross-slot scheduling is less than that of the same-slot scheduling.

·        In general, it is expected that the power saving gain by BD reduction for 1 Rx case is less than that of the 2 Rx case.

R1-2009571        Feature lead summary #5 on reduced PDCCH monitoring Moderator (Apple)

Agreements: Using both absolute increase and relative increase (as summarized in R1-2009571) to capture the observations for PDCCH blocking rate increase into TR 38.875.

Agreements: Separate the following observations to capture the PDCCH blocking rate increase into TR 38.875:

·        Separate observations for Aggregation Level (AL) distributions for AL [1,2,4,8,16] i.e. C1/C2/C3/Others.

·        Separate observations for number of simultaneously scheduled UEs X.

·        Separate observations for 25% and 50% reduction in BD limit.

·        FFS separate observations for baseline parameters and optional parameters, including comparison between baseline parameters and optional parameters.

R1-2009659        Feature lead summary #6 on reduced PDCCH monitoring Moderator (Apple)

Agreements:

·        For each of the simultaneously scheduled UE numbers denoting as ‘N’ (1<N<=10)

o   Step 1: Determine a single average/mean value Average_a_N(i) based on values reported by each company ‘i’ with existing Rel-15/16 schemes for DCI transmission

for company ‘j’. M represents the number of configurations that are simulated by company ‘j’ for ‘N’ simultaneously scheduled UEs in a slot.

o   Step 2: Determine a single average/mean value Average_a_N by averaging the values from different companies for a sperate observation, excluding the smallest and the largest values of Average_a(i)_N among companies if number of source companies > 3. 

where ‘K’ denotes the number of source companies that simulated a same observation configuration (e.g. ‘N=2’ in Table 10A) after excluding the smallest and largest value.

o   Step-3: Reuse the same approach to derive the Average_b_N for Case 2 and Case 3 with approximately 25% and 50% BD reduction. 

o   Step-4: Determine the absolute increase and relative increase as follows:

§  X_N% = [Average_b_N - Average_a_N].

§  Y_N% = [(Average_b_N - Average_a_N)/ Average_a_N ]

o   Step-5: Capture the following into TR for PDCCH blocking rate impact based on the template in Q 8.2.3.1-1

Agreements: Capturing the following formulation for PDCCH blocking rate impact observations decoding into TR 38.875 section 8.2.3.1.

-        The observation for PDCCH blocking rate impact is formulated using the vector format: <N, A%,  z1%, x1%,y1%,z2%,x2%,y2%>, which represents the following:

·        With N simultaneously scheduled UEs in a slot and z1% reduction in maximum PDCCH blind decoding, the PDCCH blocking rate is increased approximately x1% from A%, which corresponds to y1% increase relative to A%. With N simultaneously scheduled UEs in a slot and z2% reduction in maximum PDCCH blind decoding, the PDCCH blocking rate is increased approximately x2% from A%, which corresponds to y2% increase relative to A%.

Agreement: To include evaluation results for PDCCH AL distributions of AL configurations A1~A7 of Table 8 in R1-2009659 to the TR 38.875.

Agreement: To include evaluation results for number of PDCCH Candidates for AL [1,2,4,8,16] of Table 9 in R1-2009659 to the TR 38.875.

R1-2009720        Feature lead summary #7 on reduced PDCCH monitoring Moderator (Apple)

Agreements: Adopt the proposal 8.2.3.1 in R1-2009720 for TR 38.875 clause 8.2.3.1.  

• Note: the results for A2/A3 may not represent a typical case, e.g., because of the assumptions of unfavorable channel conditions.

Agreements: Capture the following note into TR 38.875 clause 8.2.3: 

Agreements: For FR1, capture the following updated observations in the TR (editorial modifications by TR editor can be made for inclusion in the TR) for same-slot scheduling with 2 Rx antennas:

·        §  For the VoIP traffic model, with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50%, the power saving gains are in the range of approximately [1.16%~4.60%] [??%-??%] and [2.32%~7.20%][??%~??%].  With excluding the smallest and the largest values among sources, the mean value of power saving gain with reducing maximum PDCCH blind decoding (i.e. 36) by 25% and 50% are approximately 2.85% and 5.66%, respectively.

R1-2009766        Feature lead summary #8 on reduced PDCCH monitoring Moderator (Apple)

Agreements:

Captured the following into TR 38.875 for section 8.2.4

Agreements:

Capture the following feature description for Scheme #3 in the TR:

Agreements:

Capture the following feature description for Scheme #1 in the TR:

Decision: As per email decision posted on Nov. 14^th,

Agreements: Capture the following feature description for Scheme #2 in the TR:

Agreements: Capturing the following into TR 38.875 for latency impact:

Decision: As per email decision posted on Nov. 18^th,

Agreements Capture the following into TR 38.875 for section 8.2.3 for scheduling flexibility impacts. 

Agreements Capture the following four paragraphs into TR 38.875 clause 12 for PDCCH monitoring:

Agreements Capturing the following into TR 38.875 for section 8.2.5

R1-2009783         Feature lead summary #9 on reduced PDCCH monitoring        Moderator (Apple)

R1-2009813         Feature lead summary #10 on reduced PDCCH monitoring      Moderator (Apple)

R1-2009839        Feature lead summary #11 on reduced PDCCH monitoring              Moderator (Apple)

Agreement: Adding the rows in proposal 8.2.2-1 for Table 2A,2B,2C and 2D with new notes in R1-2009839

Agreement: Update the agreement based on the new evaluation results for IM traffic model and Heartbeat traffic model in R1-2009839

8.6.3        Coverage recovery and capacity impact

Including aspects related to evaluations of the impact to coverage, network capacity and spectral efficiency

R1-2008865         Coverage recovery and capacity impact for RedCap   Ericsson (rev of R1-2007531)

R1-2007536         Coverage recovery for RedCap       FUTUREWEI

R1-2009782         Functionality for coverage recovery Huawei  (rev of R1-2008813, rev of R1-2007598)

R1-2009616         Discussion on coverage recovery, capacity and spectrum efficiency impact               vivo, Guangdong Genius   (rev of R1-2007670)

R1-2007717         Discussion on coverage recovery for RedCap UE       ZTE

R1-2007864         Coverage recovery for reduced capability NR devices CATT

R1-2007889         Coverage recovery and capacity impact        TCL Communication Ltd.

R1-2007949         On coverage recovery for RedCap UEs         Intel Corporation

R1-2009217         Coverage Recovery and Capacity Impact      Panasonic Corporation      (rev of R1-2007990)

R1-2008018         Discussion on coverage recovery for RedCap UEs      CMCC

R1-2008050         Discussion on the coverage recovery of reduced capability NR devices LG Electronics

R1-2008070         Functionality for coverage recovery Nokia, Nokia Shanghai Bell

R1-2008086         Discussion on coverage recovery for reduced capability device Xiaomi

R1-2008102         Discussion on coverage recovery and capacity impact Spreadtrum Communications

R1-2008172         Coverage recovery for low capability device Samsung

R1-2008262         Discussion on coverage recovery issues and evaluation             OPPO

R1-2009173         Coverage recovery for RedCap       Lenovo, Motorola Mobility             (rev of R1-2008295)

R1-2008367         Coverage recovery for Redcap devices          Sony

R1-2008396         Coverage recovery for reduced capability UEs            Sharp

R1-2008472         Functionality for Coverage Recovery for RedCap       Apple

R1-2008512         Discussion on coverage recovery for NR RedCap UEs              MediaTek Inc.

R1-2008518         On coverage recovery for reduced capability UEs       Convida Wireless

R1-2008553         Discussion on coverage recovery for RedCap              NTT DOCOMO, INC.

R1-2009310         Coverage Recovery for RedCap Devices       Qualcomm Incorporated   (rev of R1-2008622)

R1-2008686         Coverage recovery for reduced capability NR devices InterDigital, Inc.

R1-2008728         Discussion on Coverage Recovery for RedCap UE     WILUS Inc.

R1-2008740         Coverage recovery for RedCap UE Sequans Communications

R1-2008876         Considerations for coverage recovery            ITL

R1-2009311        FL summary #1 on coverage recovery and capacity impact for RedCap Ues               Moderator (Qualcomm)

Decision: Noted. From GTW on 10/26:

[103-e-NR-RedCap-04] – Chao (Qualcomm)

Email discussion for coverage recovery and capacity impact

• 1^st check point: 10/29
• 2^nd check point: 11/4
• 3^rd check point: 11/10
• Last check point 11/12, extended to 11/17

R1-2009365         FL summary #2 on coverage recovery and capacity impact for RedCap UEs               Moderator (Qualcomm)

R1-2009479        FL summary #3 on coverage recovery and capacity impact for RedCap UEs               Moderator (Qualcomm)

R1-2009580        FL summary #4 on coverage recovery and capacity impact for RedCap UEs               Moderator (Qualcomm)

Agreements:

·        If coverage recovery target performance requirement is based on Option 1

o   Maximum pathloss loss (MPL) is used as the coverage evaluation metric

·        If coverage recovery target performance requirement is based on Option 3

o   Maximum isotropic loss (MIL) is used as the coverage evaluation metric

Agreements:

·        For Option 3, down-selection on the following alternatives for coverage recovery

o   Alt 1: A single coverage recovery target based on the same bottleneck channel is used for initial access channels and non-initial access channels of RedCap UE

o   Alt 2: Identify 2 coverage recovery targets for the RedCap UE initial access channels and non-initial access channels, respectively:

§  The 1^st target is based on the bottleneck channel among the initial access channels of the reference NR UE

§  The 2^nd target is based on the bottleneck channel among all the channels of the reference NR UE

o   Note: The initial access channels include at least PBCH, PRACH, Msg2, Msg3, Msg4 and PDCCH CSS

Agreements:

·        Agree in principle using Option 3 for determining the coverage recovery target

o   Option 3: The coverage recovery target for each channel of RedCap UE corresponds to the link budget of the bottleneck channel(s) for the reference NR UE within the same deployment scenario

o   Note: The reference UE is a Rel-15/16 NR UE with mandatory features only

·        FFS For Option 3, companies report their individual observations of the amount of compensation for each channel by comparing the link budget with that of the bottleneck channel for the reference NR UE (i.e. the LB of the channel for RedCap UE – the LB of the bottleneck channel for the reference UE)

o   A representative value of the amount of compensation is derived by taking the mean value (in dB domain) from all the compensation values including both negative and non-negative values

§  Excluding the highest & the lowest values when the number of samples is more than 3

§  If the number of samples used to compute a representative value is less than 4 for each scenario, this representative value is not used for bottleneck identification

§  In this case, observations may still be drawn

o   The representative value of a channel is used for identifying whether the channel needs coverage recovery

§  Coverage recovery is not needed if the representative value of a channel is larger than or equal to zero

Agreements:

·        For Option 3, companies report their individual observations of the amount of coverage loss for each channel by comparing the link budget with that of the bottleneck channel for the reference NR UE (i.e. the LB of the channel for RedCap UE – the LB of the bottleneck channel for the reference UE)

o   A representative value of the amount of coverage loss is derived by taking the mean value (in dB domain) from all the compensation values including both negative and non-negative values

§  Excluding the highest & the lowest values when the number of samples is more than 3

§  If the number of samples used to compute a representative value is less than 4 for each scenario, this representative value is not used for bottleneck identification

§  In this case, observations may still be drawn

o   The representative value of a channel is used for identifying whether the channel needs coverage recovery

§  Coverage recovery is not needed if the representative value of a channel is larger than or equal to zero

§  The amount of coverage recovery to recommend will depend on further discussion of the techniques, scenarios, etc

Agreements:

Capture the following to the TR 38.875

·        Coverage recovery for Msg2 PDSCH was studied from several aspects, including TBS scaling [and Msg2 PDSCH repetition]

·        It is noted that TBS scaling is an existing technique mandatory for Rel-15 UE

·        Potential specification impacts of Msg2 PDSCH repetition (if supported) include

o   Msg2 PDSCH repetition configuration

o   Mechanism to differentiate enhanced UE and legacy UE, e.g., separate PRACH configurations (e.g, separate PRACH occasions or preambles)

Agreements:

Capture the following to the TR 38.875

·        Coverage recovery for Msg4 PDSCH was studied from several aspects, including scaling factor for TBS determination, PDSCH repetition and the use of the lower-MCS table.

·        Some techniques, such as scaling factor for TBS determination and PDSCH repetition have been studied also in the Rel-17 coverage enhancement SI

·        Potential specification impacts of using the lower-MCS table for Msg4 PDSCH include

o   Related signaling design

R1-2009660        FL summary #5 on coverage recovery and capacity impact for RedCap UEs               Moderator (Qualcomm)

Update on 11/11

Agreements:

·        Capture the link budget evaluation results (Urban 2.6 GHz) in Table 3.1-1 to Table 3.1-3 in R1-2009660 to the Appendix of TR 38.875

o   The tables will be further updated with potential updated evaluation results (to catch potential typos) and a clarification of assumption for Msg2 and PRACH.

o   MPL results to be included also. Up to editor to use the same or different tables

Agreements:

·        Adopted the updated TP in section 3.1 of R1-2009660 as baseline text for TR clause 9.1

o   Remove “and coverage recovery is needed” from the TP

Agreements:

·        Capture the link budget evaluation results (rural 0.7 GHz) in Table 3.2-1 to Table 3.2-3 in R1-2009660 to the Appendix of TR 38.875

o   The tables will be further updated with potential updated evaluation results (to catch potential typos) and a clarification of assumption for Msg2 and PRACH.

o   MPL results to be included also. Up to editor to use the same or different tables.

Agreements:

·        Adopted the updated TP in section 3.2 of R1-2009660 as baseline text for TR clause 9.1

o   Remove “and coverage recovery is needed” from the TP

Agreements:

·        Capture the link budget evaluation results (Urban 4 GHz) in Table 3.3-1 to Table 3.3-3 in R1-2009660 to the Appendix of TR 38.875

o   The tables will be further updated with potential updated evaluation results (to catch potential typos) and a clarification of assumption for Msg2, PRACH and DL PSD.

o   MPL results to be included also. Up to editor to use the same or different tables.

Agreements:

·        Adopted the updated TP in section 3.3 of R1-2009660 as baseline text for TR clause 9.1

o   Remove “and coverage recovery is needed” from the TP

o   Add the following sentence to the last paragraph of the TP

§  It should be noted that for DL PSD 24 dBm/MHz and 1 Rx RedCap UE case Msg2 results are based on no TBS scaling

Agreements:

For FR2 indoor scenario, the representative value is derived based on results for max TRP 12 dBm. The aggregated value for UL channels has then been obtained by considering

·        Results presented by companies assuming max TRP 12 dBm; and

·        Results presented by companies assuming max TRP 23 dBm, where corresponding MIL values have been reduced by 11 dB, and each company is counted only once (no double value is considered, if any).

Agreements:

·        Adopt the updated TP as baseline text for TR clause 10

------------------------------------------------------- Start Text ------------------------------------------------------

The SLS evaluations for the impacts of UE complexity reduction and antenna inefficiency to network capacity and spectrum efficiency are summarized in Table 4-1 to 4-25. Burst traffic model and optional full buffer traffic are considered.

The impact from potential coverage recovery techniques is reflected in some of the SLS results in the sense that we allow the PDSCH/PUSCH spectral efficiency to go lower due to, e.g. repetitions and/or HARQ transmissions (i.e. trading data rate for coverage).

For burst traffic evaluation, FTP model 3 is assumed for eMBB users. The assumption of traffic model for RedCap users varies across the sourcing companies. The instant message (IM) traffic model which in average generates an offered load of 400 kbps/s (0.1 MB payload every 2 s) is assumed for RedCap users by some sourcing companies. Compared to the assumed traffic model for the eMBB users which have an offered load of 20 Mbps (0.5 MB payload every 200 ms), the RedCap users will produce a very low data volume even with a 50-50 split of eMBB and RedCap users. The use of IM traffic for downlink capacity evaluation corresponds to video surveillance and industrial wireless sensor use cases for which traffic pattern is dominated by UL transmissions. In addition, the IM traffic may also be possible for some low data rate wearable use cases.

Some companies have considered to reuse the same FTP model 3 for RedCap users by assuming wearable use cases have DL heavy traffic and the traffic pattern is the same for RedCap users and eMBB users. It should be noted that among the companies assuming FTP3 traffic model for RedCap, there may be differences in the average traffic volume assumption. Such a difference may contribute to different conclusion.

For burst traffic evaluation with IM traffic model for RedCap users:

·        3 sources observed that the RedCap users have minor or no impact on spectral efficiency and capacity, and little impact to the performance of co-existing eMBB users in the system

·        It is further noted that the 1 Rx RedCap users do not make an appreciable change on the user throughput performance of the eMBB users compared to the 2 Rx RedCap users

For burst traffic evaluation with FTP model 3 for RedCap users:

·        One source with the respective simulation assumptions including the schedulable bandwidth reported the user throughput performance of the eMBB users is not degraded with the presence of the RedCap users in the system.

·        One source with the respective simulation assumptions including the schedulable bandwidth reported the impact on spectral efficiency will be substantial. It is further observed substantial cell spectral efficiency loss about 30% due to UE Rx antenna reduced from four to two and DL modulation order restriction from 256QAM to 64QAM in FR1 and about 50% spectral efficiency reduction due to UE Rx antenna reduced from four to one and DL modulation order restriction from 256QAM to 64QAM in FR1.

For optional full buffer traffic evaluation:

·        One source with the respective simulation assumptions including the schedulable bandwidth reported a minor degradation of the spectral efficiency for the eMBB users and the degree of spectral efficiency loss is irrespective of the number of Rx antennas for RedCap users.

·        One source with the respective simulation assumptions including the schedulable bandwidth reported the impact on spectral efficiency will be substantial. It is further observed substantial cell spectral efficiency loss about 54% due to UE Rx antenna reduced from four to two and DL modulation order restriction from 256QAM to 64QAM in FR1 and about 70% spectral efficiency reduction due to UE Rx antenna reduced from four to one and DL modulation order restriction from 256QAM to 64QAM in FR1.

------------------------------------------------------- End Text ------------------------------------------------------

Agreements:

Capture the following observations for FR1 coverage recovery to the TR 38.875

·        For FR1, under the consideration of potential reduced antenna efficiency due to device size limitations, the MIL(s) of PUSCH and/or Msg3 are worse than that of the bottleneck channel for the reference NR UE and coverage recovery is needed. The amount of coverage recovery is up to 3 dB. For other UL channels, coverage recovery may be not needed.

·        For FR1 including both FDD and TDD bands and RedCap UE with 2 Rx and reduced antenna efficiency, the MIL(s) of all the downlink channels are better than that of the bottleneck channel for the reference NR UE and coverage recovery is not needed.

·        For RedCap UE with 1 Rx and reduced antenna efficiency, dependent on frequency bands and the assumption of DL PSD, the need for coverage recovery can be different

o   For carrier frequency of 4 GHz with DL PSD 24 dBm/MHz, coverage recovery may be needed for the downlink channels of Msg2, Msg4 and PDCCH CSS. A small or moderate compensation can be considered:

§  [1 dB] for PDCCH CSS

§  [2-3 dB] for Msg4

§  [5-6 dB] for Msg2 without TBS scaling. It is noted that coverage loss for Msg2 can be compensated by using the existing TBS scaling technique.

o   For other carrier frequencies or DL PSD other than 24 dBm/MHz, coverage recovery is not needed for the downlink channels if the target for coverage recovery is based on the MIL of the bottleneck channel for the reference NR UE

o   It is noted that in the methodology for RedCap UE coverage recovery target determination, absolute ISD/MPL targets are not considered

o   The determination of which channels require coverage recovery and the amount of coverage recovery depend on the choice of the target for coverage recovery

Agreements:

Capture the following observations for FR2 coverage recovery to the TR 38.875

·        For FR2, there is no assumption of reduced antenna efficiency for RedCap UE and the MIL of the UL channels is the same as the reference NR UE and coverage recovery for UL channels is not needed.

·        [For RedCap UE with 100 MHz BW and 1Rx, although there is performance loss from reducing the number of Rx branches to 1, the MIL(s) of all the DL channels is better that that of the bottleneck channel for the reference NR UE and coverage recovery for DL channels is not needed. ]

·        For RedCap UE with 50MHz BW and 1Rx, coverage recovery may be needed for PDSCH when the same target data rate as the reference NR UE is assumed, and the amount of coverage recovery to be considered is approximately [2-3 dB]

o   The tradeoff between data rate and coverage can be considered and the amount of coverage recovery may depend on this choice.

·        The determination of which channels require coverage recovery and the amount of coverage recovery depend on the choice of the target for coverage recovery

o   E.g. coverage recovery may not be needed for FR2 indoor scenario when the target is based on an MPL value from a target ISD of 20m

o   E.g. a large amount of coverage recovery may be needed for the initial access channels if the target is to achieve the same coverage for the initial access channels between RedCap UE and the reference NR UE

Agreements:

Capture the following to the TR 38.875

·        Coverage recovery for broadcast PDCCH (PDCCH monitored in a Type0/0A/1/2/3-PDCCH CSS) was studied from several aspects, including PDCCH repetition, compact DCI, new AL [of 12, 24 or 32], PDCCH transmission via CORESET or search space bundling, PDCCH-less mechanism for SIB1 and/or SI message

·        If PDCCH repetition is supported, the potential specification impacts include

o   Repetition configuration (e.g. intra-slot or inter-slot)

o   DMRS design among PDCCH repetitions

o   Search space design for PDCCH repetition

·        If compact DCI is supported, the potential specification impacts include

o   DCI format with a small payload size

o   Reuse existing format by fixing some DCI bits

·        If new AL is supported, the potential specification impacts include

o   Mechanism for codeword generation and mapping to CCEs

o   CORESET duration extension

o   Related signaling design

·        If PDCCH transmission via CORESET bundling is supported, the potential specification impacts include

o   CORESET bundling configuration

o   DMRS design among CORESET bundling

·        If PDCCH-less is supported, the potential specification impacts include

o   Mechanism or resource allocation for indicating scheduling information for SIB1 and/or SI message in L1 signals(s)/channels(s) other than PDCCH

·        It is noted that some of the techniques may have compatibility issue if RedCap and normal UEs share the same initial DL BWP

Agreements:

Capture the following to the TR 38.875

·        Coverage recovery for PUSCH was studied from several aspects, including cross-slot or cross-repetition channel estimation, lower DM-RS density in time domain, enhancements on PUSCH repetition Type A and/or Type B, frequency hopping or BWP switching across a larger system bandwidth

·        Some techniques, such as cross-slot or cross-repetition channel estimation, lower DM-RS density in time domain, enhancements on PUSCH repetition Type A and/or Type B have been studied also in the Rel-17 coverage enhancement SI

·        Potential specification impacts of frequency hopping or BWP switching across a larger system bandwidth include:

o   Frequency domain hopping offsets/positions

o   Faster switching/RF retuning time.

§  Note this aspect requires RAN4 involvement, where the corresponding study in RAN4 is not performed yet.

o   Transmission/reception interruption during RF retuning time

Agreements:

Capture the following to the TR 38.875

·        Coverage recovery for Msg3 was studied including repetition for Msg3 PUSCH initial and/or retransmission

·        It is noted that enhancements on Msg3 PUSCH repetition have been studied also in the Rel-17 coverage enhancement SI

Agreements:

Capture the following to the TR 38.875

·        Coverage recovery for PDSCH was studied from several aspects, including the use of the lower-MCS table, larger aggregation factor for PDSCH reception, cross-slot or cross-repetition channel estimation, increasing the granularity of PRB bundling, frequency hopping or BWP switching across a larger system bandwidth.

·        Some techniques, such as the lower-MCS table and larger aggregation factor for PDSCH reception are existing techniques with optional UE capability signaling

·        If cross-slot or cross-repetition channel estimation for PDSCH is supported, potential specification impacts include:

o   Time-domain precoder cycling and DM-RS configuration

·        If hopping or BWP switching across a larger system bandwidth is supported, potential specification impacts include

o   PDSCH hopping configuration

o   Faster switching/RF retuning time

§  Note this aspect requires RAN4 involvement, where the corresponding study in RAN4 is not performed yet.

o   Transmission/reception interruption during RF retuning time

·        Potential specification impacts of increasing the granularity of PRB bundling include

o   Related signaling design

Agreements:

·        Capture the link budget evaluation results (indoor 28 GHz) in Table 3.4-1 to Table 3.4-3 in R1-2009660 to the Appendix of TR 38.875

o   The tables will be further updated with potential updated evaluation results (to catch potential typos) and a clarification of assumption for Msg2, PRACH and UE maximum Tx power.

o   MPL results to be included also. Up to editor to use the same or different tables

R1-2009721         FL summary #6 on coverage recovery and capacity impact for RedCap UEs               Moderator (Qualcomm)

R1-2009722        FL summary #7 on coverage recovery and capacity impact for RedCap UEs               Moderator (Qualcomm)

Agreements:

·        Capture the SLS evaluation results in Table 4-1 to Table 4-25 in R1-2009722 to TR 38.875

o   The tables will be further updated with potential updated evaluation results (to catch potential typos) and a clarification of evaluation assumption

Decision: As per email decision posted on Nov. 18^th,

Agreements:

·        Adopted the updated TP in section 3.4 of R1-2009722 as baseline text for TR clause 9.1

·        Adopt the following update to observations for FR2 indoor coverage recovery

Final summary in:

R1-2009796         FL summary #8 on coverage recovery and capacity impact for RedCap UEs               Moderator (Qualcomm)

R1-2009817        FL summary #9 (post e-meeting) on coverage recovery and capacity impact for RedCap UEs       Moderator (Qualcomm)

8.6.4        Framework and Principles for Reduced Capability

R1-2007532         Framework and principles for RedCap          Ericsson

R1-2007537         Framework for RedCap UEs            FUTUREWEI

R1-2007599         Framework and principles for reduced capability devices         Huawei, HiSilicon

R1-2007671         Framework and Principles for Reduced Capability     vivo, Guangdong Genius

R1-2007718         Views on Framework and Principles for Reduced Capability   ZTE

R1-2007865         Framework and principles for reduced capability NR devices  CATT

R1-2007950         Framework and principles for introduction of RedCap UEs      Intel Corporation

R1-2008019         Discussion on design principles and definition for RedCap device type CMCC

R1-2008051         Consideration on the framework to support reduced capability NR devices          LG Electronics

R1-2008071         Framework and Principles for Reduced Capability UE              Nokia, Nokia Shanghai Bell

R1-2008087         Framework and Principles for Reduced Capability     Xiaomi

R1-2008101         Discussion on Framework and Principles for Reduced Capability           Spreadtrum Communications

R1-2008173         Framework and Principles for Reduced Capability     Samsung

R1-2008263         Further considerations on reduced UE capability        OPPO

R1-2008290         Discussion on Framework and Principles for Reduced Capability           Panasonic

R1-2008296         Framework and Principles for RedCap          Lenovo, Motorola Mobility

R1-2008473         Framework and principles for RedCap          Apple

R1-2008513         On the framework for RedCap UEs MediaTek Inc.

R1-2008554         Discussion on framework and principles for RedCap  NTT DOCOMO, INC.

R1-2008623         Standardization Framework and Design Principles for RedCap Devices Qualcomm Incorporated

R1-2008687         Framework and Principles for Reduced Capability     InterDigital, Inc.

R1-2008741         Framework and principles for RedCap UE    Sequans Communications

R1-2008555        Summary on Framework and Principles for Reduced Capability     Moderator (NTT DOCOMO, INC.)

Decision: Noted. From GTW on 10/26:

[103-e-NR-RedCap-05] – Shinya (NTT DOCOMO)

Email discussion for framework and principles for RedCap

• 1^st check point: 10/29
• 2^nd check point: 11/5
• Last check point 11/12

R1-2009381        Summary#2 on Framework and Principles for Reduced Capability Moderator (NTT DOCOMO, INC.)

R1-2009534         Summary#3 on Framework and Principles for Reduced Capability         Moderator (NTT DOCOMO, INC.)

Decision: As per email decision posted on Oct. 30^th,

Conclusion:

·        Defer to RAN2 on the framework how to indicate the capabilities of RedCap UEin connected mode

o   Note: Possible early identification is used for UEs in idle mode and is discussed in AI8.6.5

o   Note: RAN1 continues the discussion on the exact composition of the set of L1 capabilities of the RedCap UE type

Conclusion:

·        Following coexistence issuesare not studied in Rel.17 RedCap SI 

o   Efficient Beam-based operation in FR2 

o   Efficient resource usage in FR2 

o   How to mitigate the PRACH collision in FR2 

Decision: As per email decision posted on Nov. 10^th,

Agreements:

·        At least for RedCap UE identification, explicit definition of RedCap UE type(s) is needed. Ppending conclusions on the reduced complexity features in AI8.6.1 and RedCap UE identification in AI8.6.5, the definition of the RedCap UE types can be based on one of:

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

o   FFS for other usages

From GTW session:

Agreements:

·        If early identification during initial access is supported, at least maximum supported UE BW during initial access is included in the set of L1 capabilities of the device type for RedCap early identification 

o   Note: 20 MHz for FR1 and 100 MHz for FR2

o   Identification of UEs optionally supporting bandwidths larger than 20 MHz in FR1 or larger than 100 MHz in FR2 after initial access, if supported, is not supported by early identification during initial access

o   FFS other L1 capabilities

o   Note: This does not preclude the case where the early indication only indicates whether it is a Redcap UE or which type of the Redcap UEs if multiple UE types are defined

Final summary in

R1-2009732        Summary#4 on Framework and Principles for Reduced Capability Moderator (NTT DOCOMO, INC.)

8.6.55        Other

Including RAN2-led aspect on allowing devices with reduced capabilities to be explicitly identifiable to networks and network operators, and allow operators to restrict their access, if desired

R1-2007533         UE identification and access restriction for RedCap   Ericsson

R1-2007538         Identification for RedCap UEs        FUTUREWEI

R1-2007672         RRM relaxation for Reduced Capability NR devices  vivo, Guangdong Genius

R1-2007719         Access control and identification for Reduced Capability NR devices    ZTE

R1-2008838         Identification and access restriction for reduced capability NR devices  CATT    (rev of R1-2007866)

R1-2007951         On identification of and access control for RedCap UEs           Intel Corporation

R1-2008020         Discussion on identification and access control for Reduced Capability NR devices               CMCC

R1-2008052         Other aspects for reduced capability NR devices         LG Electronics

R1-2008072         Initial access for RedCap UEs         Nokia, Nokia Shanghai Bell

R1-2008075         Procedure of identification for Reduced Capability NR devices              TCL Communication Ltd.

R1-2008088         Discussion on the access control and configuration for reduced capability device               Xiaomi

R1-2008106         Consideration on power saving for reduced capability NR devices         Spreadtrum Communications

R1-2008174         UE identification and access barring              Samsung

R1-2008264         Other considerations for reduced UE capability          OPPO

R1-2008291         On RedCap device identification     Panasonic

R1-2008329         Other aspects for reduced capability devices Huawei, HiSilicon

R1-2008337         Narrowband operation and identification of RedCap UE           Lenovo, Motorola Mobility

R1-2008397         Identification and access restriction for reduced capability UEs              Sharp

R1-2008556         Discussion on UE identification for RedCap NTT DOCOMO, INC.

R1-2008585         Discussion on identification of reduced capability UE ASUSTeK

R1-2008688         Device identification and access restriction for RedCap            InterDigital, Inc.

R1-2009317        Moderator summary on RedCap – Others Moderator (Intel)

Decision: Noted. From GTW on 10/26:

[103-e-NR-RedCap-06] – Debdeep (Intel)

Email discussion for 8.6.5

• 1^st check point: 10/29
• 2^nd check point: 11/5
• Last check point 11/12

R1-2009404        Moderator summary#2 on RedCap - Others           Moderator (Intel)

R1-2009608        Moderator summary#3 on RedCap - Others           Moderator (Intel)

R1-2009735        Moderator summary#4 on RedCap - Others           Moderator (Intel)

R1-2009771        Moderator summary#5 on RedCap - Others           Moderator (Intel)

Decision: As per email decision posted on Oct. 30^th,

·        For access control for RedCap UEs, detailed signaling options associated with system information are postponed to the WI phase. 

Decision: As per email decision posted on Nov. 5^th,

Agreements:

·        As a next step, for the study on the options for RedCap UE identification during RAN1 #103-e meeting, RAN1 to focus on establishing feasibility, necessity, and identifying pros and cons for the following schemes:

o   Opt. 1: During Msg1 transmission, e.g., via separate initial UL BWP, separate PRACH resource, or PRACH preamble partitioning.

o   Opt. 2: During Msg3 transmission.

o   Opt. 3: Post Msg4 acknowledgment.

§  E.g., during Msg5 transmission or part of UE capability reporting.

o   Opt. 4: During MsgA transmission.

Decision: As per email decision posted on Nov. 10^th,

Agreements:

• Considerations on Option 4 (during MsgA transmission) are deprioritized until further progress is made on Options 1 and 2 for 4-step RACH procedure.

From GTW:

Agreements:

·        Observation: Identification of RedCap UE type(s) during transmission of Msg1 could be feasible from the perspective of RAN1, at least for the following solutions:

o   Separation of PRACH resources (e.g., occasions and/or formats) or PRACH preambles between RedCap and non-RedCap UEs

o   Separation of initial UL BWP for RedCap and non-RedCap UEs

·        Note: The appropriateness of each solution, considering the number of UE type(s) to be indicated, etc. needs further considerations.

Agreements:

·        Observation: Identification of RedCap UE type(s) during transmission of Msg5 or as part of UE capability reporting are feasible options from the perspective of RAN1

Agreements:

·        Observation: If early identification of RedCap UE type(s) via Options 1, 2, or 4 are not supported, then RedCap UE type(s) need to be identified either during transmission of Msg5 or as part of UE capability reporting.

Agreements:

·        Observation: Early identification of RedCap UE type(s) during transmission of Msg1 may be necessary for:

o   coverage recovery (including link adaptation) for one or more of: Msg2 PDCCH/PDSCH, Msg3 PUSCH and PDCCH scheduling Msg3 reTx, Msg4 PDCCH/PDSCH or PUCCH in response to Msg4, Msg5 PUSCH and associated PDCCH, if it is determined that coverage recovery for RedCap UEs is necessary for one of more of these channels;

o   identifying UE minimum processing times capabilities for PDSCH processing and PUSCH preparation, if relaxations to UE min processing times are defined for N1 and N2;

o   identifying UE capability for UL modulation order for Msg3 and Msg5 scheduling, if relaxations to max UL modulation order (i.e., UL modulation order restricted to lower than 64QAM) are introduced;

o   identifying UE max bandwidth capability for Msg3 and Msg5 scheduling and PUCCH in response to Msg4.

·        Note: Exact necessity depends on outcome of studies on UE cost/complexity reduction in AI 8.6.1 and Coverage Recovery in AI 8.6.3, and the SI on Coverage Enhancements.  

Agreements:

·        Observation: The following pros and cons are identified for identification of RedCap UE type(s) during transmission of Msg1:

Agreements:

·        Observation: The following pros and cons are identified for identification of RedCap UE type(s) during transmission of Msg5 or in UE capability report:

Agreements:

·        Observation: Identification of RedCap UE type(s) during transmission of Msg3 may be feasible from the perspective of RAN1, at least for the following solutions:

o   Using the spare bit in existing Msg3 definition

o   Extending the Msg3 size to carry additional one or more bits, indicating RedCap UE type(s)

·        Note: The appropriateness and feasibility of each solution, considering the number of UE type(s) to be indicated, coverage performance for Msg3, etc. need further considerations from RAN2 and RAN1.

Agreements:

·        Observation: If early identification of RedCap UE type(s) via Option 1 is not supported, identification of RedCap UE type(s) during transmission of Msg3 may be necessary for coverage recovery (including link adaptation) for one or more of: Msg4 PDCCH/PDSCH, Msg5 PUSCH and associated PDCCH

·        Note: Exact necessity depends on outcome of studies on Coverage Recovery in AI 8.6.3

Agreements:

·        Observation: The following pros and cons are identified for identification of RedCap UE type(s) during transmission of Msg3:

Conclusion: The option of carrying RedCap UE type(s) identification as part of UCI multiplexed in Msg3 PUSCH is not considered during the Rel-17 RedCap SI.

Final summary in:

R1-2009780        Moderator summary#6 on RedCap - Others           Moderator (Intel)

 RAN1#104-e

8.6       Support of Reduced Capability NR Devices

Please refer to RP-202933 for detailed scope of the WI

R1-2100033         WI work plan for RedCap Rapporteur (Ericsson)

Summary of RAN1 agreements w.r.t RedCap in:

R1-2102220        RAN1 agreements for Rel-17 NR RedCap Rapporteur (Ericsson)

8.6.1        UE complexity reduction

Including reduced maximum UE bandwidth, reduced minimum number of Rx branches, maximum number of DL MIMO layers, relaxed maximum modulation order and duplex operation

R1-2100034        UE complexity reduction for RedCap        Ericsson

·        Proposal 1: For frequency-hopping Msg4 PUCCH or Msg3 PUSCH transmissions, support frequency retuning between the hops for the RedCap UE to ensure its PUCCH or PUSCH transmission is within its transmission bandwidth.

·        Proposal 2: Capture a reduction in number of supported DL MIMO layers in physical layer specifications as notes and/or conditions related to number of Rx branches.

·        Proposal 3: Existing DCI format can be used for RedCap UEs with 1 Rx branch supporting 1 DL MIMO layer and RedCap UEs with 2 Rx branches supporting 2 DL MIMO layers.

·        Proposal 4: Reuse existing MCS and CQI tables (i.e. Table 5.1.3.1-1, Table 5.1.3.1-3, Table 5.2.2.1-2 and Table 5.2.2.1-4 in TS 38.214 [8]) for RedCap UEs that do not support 256QAM in DL.

·        Proposal 5: Do not introduce new DCI formats for scheduling the PDSCH for RedCap UEs that do not support 256QAM in DL .

·        Proposal 6: Leave to RAN2 to discuss how to indicate UE’s maximum modulation order support.

·        Proposal 7: Strive to reuse the existing DL-to-UL and UL-to-DL switching time of a non-full-duplex UE for a HD-FDD Type-A UE. RAN4 confirmation on such feasibility is required.

·        Proposal 8: Reuse the existing UE behavior in handling DL/UL collision of the non-full-duplex UE as much as possible for the HD-FDD Type-A UE.

·        Proposal 9: In case of a collision between dynamically scheduled DL reception and UL configured grant occasion, discuss further whether the UE needs to prioritize dynamic scheduled DL reception.

Decision: The document is noted.

R1-2100230        Potential solutions for UE complexity reduction     Huawei, HiSilicon

·        Proposal 1: Study potential solutions for uplink channel transmission during initial access to resolve the issues caused by RedCap UE bandwidth reduction, including

o   PRACH/PUSCH for Msg.3/common PUCCH

·        Proposal 2: Consider to support configurability of using legacy SIB1 (possibly with RedCap specific IEs) or defining RedCap specific SIB1. FFS configuration separation for Paging or RAR specific to RedCap.

·        Proposal 3: Support that RedCap UEs can be configured on a BWP not containing any SSB.

·        Proposal 4: Both 1 Rx and 2 Rx branches are supported by specification for RedCap UEs in FR1 TDD bands where a non-RedCap UE is required to be equipped with a minimum of 4 Rx branches, and the supported number of Rx branches should be reported explicitly to the network.

·        Proposal 5: Consider to support PDCCH enhancements from the perspective of PDCCH capacity and efficiency improvement, e.g. a compact DCI or a group-wise DCI.

·        Proposal 6: For the NR RedCap UEs with HD-FDD capability, a guard period is created by not receiving the last part of DL symbol(s) immediately preceding UL symbol(s) from the same UE. The requirement of guard period can be determined in RAN4.

·        Proposal 7: The half-duplex capability should be reported explicitly to the network after initial access.

Decision: The document is noted.

R1-2101049        Discussion on UE complexity reduction     CMCC

·        Proposal 1: RedCap devices support a wider bandwidth up to 40MHz after initial access as an optional capability.

·        Proposal 2: BWP switching based on DCI, RRC and timer is supported.

·        Proposal 3: Early identification by Msg.1 can be used to solve coexistence issues if necessary.

·        Proposal 4: For FR1 TDD bands where a non-RedCap UE is required to be equipped with a minimum of 4 Rx branches, the minimum number of Rx branches supported by specification for a RedCap UE is 1. The specification also supports of 2 Rx branches for a RedCap UE.

·        Proposal 5: Default transmission direction or UL-DL configuration can be introduced for HD-FDD type A.

Decision: The document is noted.

R1-2101214        UE complexity reduction Samsung

·        Proposal 1: Further study on RedCap UE operating in a wider BWP, at least considering:

o   Define a retuning time for frequency hopping within a wider BWP

o   Resource allocation of PUSCH/PUSCH

o   Resource configuration for PDCCH and PUCCH

o   CSI report for a wider BWP bandwidth, including PDCCH based CSI report.

·        Proposal 2: Further study on supporting RedCap UE with UE-specific BWP no larger than its RF bandwith, at least considering:

o   Support SRS transmissions or CSI report for link adaptation outside active BWP. 

·        Proposal 3: LS RAN4 on the BWP switching time or RF retuning time assuming same subcarrier spacing.

·        Proposal 4: Consider to support SB CSI reporting for BWP size < 24 PRBs, at least for RedCap UEs:

o   Support a SB size for BWP size < 24 PRBs, where the SB size can be fixed or configured

o   When BWP size < 24 PRBs, the SB CSI reporting can be  restricted to rank 1 only and a small number of CSI-RS ports (e.g. 2 or 4)

·        Proposal 5: Separated configuration for initial access and paging can be supported.

·        Proposal 6: Further study on allowing the DL resource outside of COREST 0 for at least Type1-PDCCH CSS, Type 2-PDCCH CSS, and the scheduled PDSCH.

·        Proposal 7: Support multi-PDSCHs/PUSCHs scheduling for PDCCH overhead reduction and PDCCH blocking rate reduction.

·        Proposal 8: Send LS to RAN4 to ask whether “Transition time  and ” can be reused for a RedCap UE supporting HD-FDD type A.

·        Proposal 9: Apply TDD principles as much as possible in order to address collisions between DL and UL for a RedCap UE supporting HD-FDD type A.

Decision: The document is noted.

R1-2101390        On UE complexity reduction features for RedCap Apple

·        Proposal 1: Allowing Redcap devices to indicate support of wider bandwidth as part of UE capability signaling e.g., 40MHz to achieve higher data rate.

·        Proposal 2: For frequency band where legacy UE requires to support 4 Rx, the minimum number of Rx should be reduced to 1 for Redcap devices with additionally allowing to support 2 Rx as well.

·        Proposal 3: Type A HD-FDD operation is assumed for Redcap devices and FD-FDD mode can be reported as part of UE capability.

·        Proposal 4: For Type A HD-FDD operation, specifying the following priority order to handle the overlapping between DL reception and UL transmission: PUCCH or PUSCH or aperiodic SRS > PDCCH, P/SP-CSI-RS> P/SP-SRS

Decision: The document is noted.

R1-2101766        Complexity Reduction for RedCap Devices             Qualcomm Incorporated (rev of R1-2101471)

·        Proposal 1: Support early indication of RedCap by configuring dedicated PRACH resources for RedCap UE, wherein the PRACH can be used for msg1 transmission of 4-step RACH, or msgA preamble transmission of 2-step RACH.

·        Proposal 2: If the initial DL/UL BWP of non-RedCap UE is wider than that of RedCap UE, the initial BWP configuration  for RedCap UE can be indicated in SI, or by rules specified in NR R17 standards.

·        Proposal 3: NR RedCap UE and non-RedCap UE should share the same SSB/CORESET0/SIB1, to reduce the signaling overhead of broadcast signals/channels.

·        Proposal 4: Other SIBs of RedCap UE can either be scheduled by SIB1, or be transmitted on-demand within the initial DL BWP of RedCap UE. The dedicated PRACH resources configured for RedCap UE can be used to request the on-demand transmission of SI dedicated to RedCap UE.

·        Proposal 5:  In FR1, SUL is not supported by NR RedCap UE. Coverage recovery on NUL can re-use at least the solutions provided by R17 CE WI.

·        Proposal 6: For use cases requiring high peak rates up to 150 Mbps, up to 40 MHz UE BW can be supported by 1RX UE after initial access.

·        Proposal 7: Support 1 RX as the minimum number of RX branches for R17 RedCap devices in FR1. 2 RX branches are also supported as an optional UE feature for R17 RedCap devices.

·        Proposal 8: For Type-A HD-FDD, a guard period is needed by RedCap UE when it switches from DL to UL. The guard period can be accommodated by an OFDM symbol with SCS 15/30/60 kHz.

o   FFS guard period configuration when UE switches from UL to DL.

·        Proposal 9: When a RedCap UE is operating in Type-A HD-FDD mode, it can be configured with semi-static slot formats. If the RedCap UE is not configured with semi-static slot formats, it will follow the dynamic grant transmitted on the DL carrier.

·        Proposal 10: For FR2, to save UE power and complexity, consider switching the UE to a narrow active BWP (NBWP) after initial access is complete. The switching may be network initiated/controlled, implicit, or UE initiated/requested

·        Proposal 11: For FR2, consider ways to reduce the impact of the narrower BWP on the system operation by:

o   Utilizing BWP hopping to reduce the NB interference effects

§  Includes methods to reduce the BWP switching gap effects

o   Hopping across larger BW (e.g., across CCs) to achieve frequency diversity gains

o   Defining a leaner system and reusing resources between eMBB and RedCap

Decision: The document is noted.

R1-2101619        Discussion on UE complexity reduction for RedCap             NTT DOCOMO, INC.

·        Proposal 1: Support initial UL BWP for RedCap UEs to include the RO corresponding to the best SSB.

·        Proposal 2: Support compact DCI with potential further DCI size reduction for RedCap UEs.

·        Proposal 3: For frequency bands where a legacy NR UE (other than 2-Rx vehicular UE) is required to be equipped with a minimum of 4 Rx antenna ports, support one of 2 Rx antenna ports or 1 Rx antenna port without 3dB antenna efficiency loss for RedCap UEs, to be confirmed in RAN#91e.

·        Proposal 4: Support UL-to-DL switching time in HD-FDD operation for RedCap UEs, considering the transition time specified in Table 4.3.2-3 in TS 38.211 as baseline.

·        Proposal 5: Support DL-UL collision handling in HD-FDD operation for RedCap UEs, considering the DL-UL collision handling specified in Clause 11.1 in TS 38.213 as baseline.

Decision: The document is noted.

R1-2100046         Complexity reduction features for RedCap UEs          FUTUREWEI

R1-2101777         Discussion on UE complexity reduction        OPPO     (rev of R1-2100165)

R1-2100389         Discussion on UE complexity reduction features        CATT

R1-2100449         Discussion on UE Complexity reduction       vivo, Guangdong Genius

R1-2100499         UE complexity reduction  Nokia, Nokia Shanghai Bell

R1-2100564         UE complexity reduction for Reduced Capability NR devices  ZTE

R1-2100579         On complexity reduction features for NR RedCap UEs             MediaTek Inc.