Please refer to RP-193240 for detailed scope of the SI
R1-2003833 Draft skeleton of TR 38.830 Study on NR coverage enhancements China Telecom
Decision: The draft skeleton is endorsed with the updated that 5.1/5.2/5.3 are put in brackets (assuming the section numbering is updated) – Revised version is endorsed as v0.0.1 in R1-2004753 as basis for future work.
R1-2003832 Work plan for Study on NR coverage enhancements China Telecom
R1-2004155 Overview of coverage enhancement: scenarios, channels, services and potential solutions Huawei, HiSilicon
R1-2004631 General Considerations for the Coverage Enhancement Study Ericsson
For the scenarios and services as identified in the SID based on link-level simulation
R1-2003648 Discussion on the methodology for coverage enhancement CATT
R1-2003919 Assumptions for NR coverage evaluation vivo
R1-2004027 Discussion on evaluation for coverage enhancement LG Electronics
R1-2004377 Considerations for Coverage Enhancement Indian Institute of Tech (H)
R1-2004632 Evaluation Methodology for Coverage Enhancements Ericsson
[101-e-NR-Cov-Enh] – Jianchi (CT)
Continue offline discussion (focusing on FR1 + FR2) till 6/1
R1-2005004 [101-e-NR-Cov-Enh] Email discussion on evaluation methodology and simulation assumptions for NR coverage enhancements Moderator (China Telecom)
Decision: As per decision from GTW on June 4th,
Agreements:
· Adopt the following target data rates for eMBB performance evaluation for FR1.
o Urban scenario: DL 10Mbps, UL 1Mbps
o Rural scenario: DL 1Mbps, UL 100kbps
o
Rural with long distance
scenario: DL 1Mbps, UL 100kbps, [30kbps] (optional)
Agreements:
· For VoIP performance evaluation based on link-level simulation for FR1.
o A packet size of [320] bits with 20ms data arriving interval is adopted.
o
FFSTBD: TBS for SIP invite
message. Payload of 1500 bytes can be a starting point.
Agreements:
· The basic evaluation methodology is based on link-level simulation for FR1.
o Step 1: Obtain the required SINR for the physical channels under target scenarios and service/reliability requirements.
o Step 2: Obtain the baseline performance based on required SINR and link budget template.
o Note: asepcts related to identifying target performance and coverage bottlenecks based on target performance metric is to be handled separately
·
FFS: The evaluation methodology based on system-level simulation is
optional for FR1.
o Note: The simulation assumptions for SLS are up to companies’ reports.
Agreements:
· For link level simulation, adopt the following table for PUSCH and PUCCH for FR1.
|
Parameters |
Values |
|
Scenario and frequency |
Urban: 4GHz (TDD), 2.6GHz (TDD) Rural: 4GHz (TDD), 2.6GHz (TDD), 2GHz (FDD), 700MHz (FDD) Rural with long distance: 700MHz (FDD), 4GHz (TDD) |
|
Frame structure for TDD |
DDDSU (S: 10D:2G:2U) only for 4GHz DDDSUDDSUU (S: 10D:2G:2U) only for 4GHz DDDDDDDSUU (S: 6D:4G:4U) only for 2.6GHz Other frame structures can be reported by companies. |
|
Pathloss model (select from LoS or NLoS) |
Urban: NLoS Rural: NLoS and LoS |
|
BWP |
100MHz for 4GHz and 2.6GHz. 20MHz for 2GHz (FDD 20MHz (optional for 10MHz) for 700MHz. (FDD) |
|
SCS |
30kHz for TDD, 15kHz for FDD. |
|
Channel model for link-level simulation |
TDL-C for NLOS, TDL-D for LOS. [CDL] |
|
UE velocity |
Urban: 3km/h for indoor Rural: 3km/h for indoor, 120km/h (optional 30km/h) for outdoor |
|
Frequency hopping |
w/ or w/o w/
frequency hopping for PUCCH |
R1-2005005 Unified link budget template for Rel-17 NR coverage enhancements Moderator (China Telecom)
Decision: As per email decision posted on June 6th,
Agreement:
· Down selection on the following options for the link budget template for FR1 in next meeting.
o Option 1: Adopt single link budget template based on IMT-2020 self-evaluation with necessary revisions, including adding/removing/revising some parameters.
§ FFS: The template provided by FL in Tdoc R1-2005005.
o Option 2: Adopt both templates, i.e. link budget template in IMT-2020 self-evaluation and link budget template in TR 36.824.
o Option 3: Adopt single link budget template in TR 36.824 with necessary revisions, including adding/revising some parameters.
Agreement:
· Down selection on the following options for antenna array gain for LLS based methodology for FR1 in next meeting.
o Option 1: Antenna array gain is included in the link budget template.
§ FFS: array gain = 10 * 1og10 (number of antenna elements/number of TxRUs)
§ FFS: For TDL channel model
§ FFS: Values reflective of realistic implementation and network operation.
o Option 2: Antenna array gain is included in LLS.
§ FFS: For CDL channel model
Agreement:
· For link level simulation, adopt the following table for PDSCH for FR1.
|
Parameters |
Values |
|
Waveform |
CP-OFDM |
|
PRBs/MCS/TBS |
Reported by companies. |
|
PDSCH duration |
12 OS |
|
Other parameters |
FFS |
Agreement:
· For link level simulation, adopt following TBS for Msg3 for FR1
o 56 bits
Agreement:
· For link level simulation, the packet size of VoIP for FR2 is the same as FR1.
Agreement:
· For link level simulation, TBS of Msg3 for FR2 is the same as FR1.
Agreement:
· The evaluation methodology for FR2 is the same as FR1.
Agreement:
· The link budget template for FR2 is the same as FR1.
Agreements:
· For link level simulation, adopt the following table for PUSCH and PDSCH for FR2.
|
Parameters |
Values |
|
Scenario and frequency |
28GHz |
|
Frame structure for TDD |
DDDSU (S: 10D:2G:2U) DDSU (S: 11D:3G:0U) Other frame structures can be reported by companies. |
|
Subcarrier Space |
120kHz |
|
UE velocity |
Indoor scenario:3km/h Urban scenario: 3km/h for indoor, 30km/h for outdoor. Suburban scenario: 3km/h for indoor, 30km/h, (optional: 120km/h) for outdoor. |
|
Occupied channel bandwidth for |
100MHz, [400MHz] |
|
Frequency hopping for PUSCH |
w/ or w/o frequency hopping |
Update on 6/7, post e-Meeting additional email approval
[101-e-Post-NR-Cov-Enh] – Jianchi (CT)
Email discussion/approval focusing on remaining evaluation assumptions till 6/17
R1-2004716 Baseline coverage performance for FR1 Huawei, HiSilicon (rev of R1-2003298)
· Proposal 1: Reuse the evaluation methodology of link budget in IMT-2020 self-evaluation for Rel-17 NR coverage enhancement at FR1.
· Proposal 2: Adopt the revised values in Table 3 to the link budget template for the baseline link budget evaluation of Rel-17 coverage enhancement.
· Proposal 3: PUSCH should be prioritized for coverage enhancement.
· Proposal 4: Other channels including msg3, PDCCH and PDSCH cannot achieve coverage requirements under rural with long distance scenarios with ISD=12km, where coverage enhancement can be considered.
Decision: The document is noted.
R1-2003464 Requirements for Voice coverage enhancements with FR1 SoftBank Corp.
· NR coverage enhancement SI should strive for better NR voice coverage than that of UMTS
· In this study, MCL of 147 dB should be adopted as a target value for NR voice coverage enhancement with FR1
· At least low-band re-farming spectrum (e.g. 700, 800, 900 MHz and 1.7, 2GHz with FDD) should be used for the evaluations.
· For FDD re-farming spectrum, additional gain by advanced MIMO shouldn’t be expected in this study, i.e.
o 2 (passive antenna) at gNB
o 2 at UE
· 13.2kbps voice bitrate should be assumed in this study
· L1 channels & signals used for 4-step RACH should be evaluated
o Msg.1 (PRACH preamble)
o Msg.2 (PDCCH)
o Msg.3 (Msg.3 PUSCH)
o Msg.4(PDCCH/PDSCH for contention resolution and PUCCH for HARQ-ACK)
· PUSCH should be evaluated
o Adopt target PUSCH throughput of 24kbps to convey UL SIP message
o RAN1 to contrinue discussion on the adjustment of this value
· DL/UL voice packet with 13.2kbps should be evaluated in this study
Decision: The document is noted.
R1-2003834 Evaluation methodology and preliminary baseline performance for NR coverage enhancements China Telecom
· Proposal 1: Capture the evaluation methodology in Section 2 into TR 38.830.
· Proposal 2: Capture the simulation assumptions for the required SNR calculation in Table 3.1 and Table 3.2 into TR 38.830.
· Proposal 3: Capture the link budget template for coverage enhancement in Table 3.3 into TR 38.830.
· Proposal 4: Capture the formulas for the target performance calculation in Table 3.4 into TR 38.830.
· Proposal 5: The coverage performance of PUSCH for urban eMBB should be enhanced.
· Proposal 6: The coverage performance of PUSCH for rural eMBB should be enhanced.
· Proposal 7: The coverage performance of PUSCH for rural VoIP should be enhanced.
· Proposal 8: The coverage performance of PUCCH should be enhanced.
Decision: The document is noted.
R1-2004352 Simulation Parameters and Initial Results for FR1 Ericsson
· Consider two configurations as shown in Table 1,
o for low band a 2x10MHz FDD with 15kHz subcarrier spacing at 700 MHz with 2T/2R at base station and 1T/2R at terminal
o for mid band a 1x100MHz 3DL1UL TDD with 30kHz subcarrier spacing at 4GHz using up to 32T/32R at base station and 1T/4R at terminal
· For the baseline link level simulations, consider 2T for downlink 1T for uplink, whereas 2R and 4R are relevant for both uplink and downlink at 700MHz and 4GHz respectively, see also Table 2.
· For the link level simulations, initially consider TDL-A with medium spatiws1al correlation, RMS delay spread 100ns. Later consider also 30ns delay spread and for the 700MHz case and 300ns for the 4GHz targeting rural macro and urban micro deployments (where a majority of users are indoors). Initially consider terminal speed of 3km/h and later consider also other higher speeds like 30km/h and 120km/h. This summarized in Table 3.
· For the coverage analysis for low band, consider, the channels and assumptions in Table 4.
· For the coverage analysis for mid band, consider, the channels and assumptions in Table 5.
· Focus coverage enhancements efforts on uplink data and uplink control.
Decision: The document is noted. Further revised in R1-2004937.
R1-2004497 Baseline FR1 coverage performance Qualcomm Incorporated
On baseline coverage evaluation assumption and performance target
· Proposal 1: Use Table 1 to Table 7 as link-level simulation assumption for baseline FR1 coverage evaluation.
· Proposal 2: Reuse MCL template (Table 5-1) in TR 36.824 for MCL analysis.
· Proposal 3: The MCL target could be based on the control channel coverage.
On eMBB traffic:
· Proposal 4: Consider enhancement to PUCCH performance to reduce the uplink-downlink control channel coverage imbalance in rural scenarios. Also consider enhancements to PUSCH performance to ensure minimum service requirements.
· Proposal 5: Consider enhancements aimed at improving the coverage of PUSCH, PUCCH, and downlink broadcast channels in urban environments.
On voice traffic:
· Proposal 6: Consider enhancements to PUCCH and PUSCH to improve coverage performance for VoNR services.
Decision: The document is noted.
R1-2003338 Discussion on baseline coverage performance for FR1 ZTE
R1-2003342 NR Coverage requirements and simulation assumption for FR1 Sierra Wireless, S.A.
R1-2003435 Evaluation on NR coverage performance for FR1 vivo
R1-2003649 Discussion on the baseline performance and simulation assumptions of coverage enhancement for FR1 CATT
R1-2003683 Discussion on scenarios for FR1 baseline performance evaluation MediaTek Inc.
R1-2003773 Discussion on baseline coverage performance for FR1 Intel Corporation
R1-2003778 Downlink coverage in FR1 Charter Communications, Inc
R1-2003816 Discussion on evaluation methodologies for baseline coverage performance analysis Panasonic Corporation
R1-2003821 Baseline evaluation for NR UL coverage enhancement Lenovo, Motorola Mobility
R1-2003914 Scenarios and simulation assumptions for coverage enhancement in FR1 Samsung
R1-2003940 Simulation Assumptions and Baseline Coverage for FR1 Nomor Research GmbH, Facebook
R1-2003970 Discussion on coverage enhancements in FR1 CMCC
R1-2004108 NR coverage performance for FR1 OPPO
R1-2004178 Baseline coverage evaluation of UL and DL channels – FR1 Nokia, Nokia Shanghai Bell
R1-2004196 On NR coverage analysis in FR1 Sony
R1-2004249 On baseline coverage performance for FR1 Apple
R1-2004304 Simulation assumptions and throughput performance for UL in FR1 InterDigital, Inc.
R1-2004700 Preliminary evaluation for FR1 Urban scenario Sharp (rev of R1-2004338)
R1-2004424 Baseline coverage performance for FR1 NTT DOCOMO, INC
R1-2004540 Baseline coverage performance for FR1 xiaomi
R1-2003436 Evaluation on NR coverage performance for FR2 vivo
· Proposal 1: The coverage evaluation methodology based on link budget calculation and link level simulation in ITU self-evaluation can be considered as baseline in NR coverage enhancement SI, and for other device types, e.g. Redcap UEs.
· Proposal 2: the target ISD for outdoor to indoor pathloss model in urban scenario should be further discussed.
· Proposal 3 : All downlink channels need to be enhanced in the following scenarios
o Urban O-to-I
· Proposal 4: All uplink channels need to be enhanced in the following scenarios
o Urban O-to-O and Urban O-to-I
Decision: The document is noted. Further revised in R1-2004758.
R1-2003971 Discussion on coverage enhancements in FR2 CMCC
· Proposal 1: The line of sight scenario in outdoor and indoor scenarios could be the first priority.
· Proposal 2: The target ISD of FR2 is 300m for urban scenario, and the target data rate in SID is taken as the starting point, i.e., 25 Mbps in downlink and 5Mbps in uplink.
· Proposal 3: Adopt the parameters and values in table 1 for link budget evaluation for PDSCH and PUSCH.
· Proposal 4: Consider the general methodology below for the study to identify the limited channels and the enhancements needed.
o STEP 1: determine the target cell edge data rate and target coverage distance
o STEP 2: carry out link budget calculations to derive baseline performance
o STEP 3: determine the limited channels and performance gap for the targeted performances
· Proposal 5: More discussions are needed for determining the enhancement target for bottleneck channel in FR2. Two options could be considered.
o Option 1: enhance the bottleneck channel to reach the target ISD, e.g., 300m ISD.
o Option 2: enhance the bottleneck channel to achieve the same coverage performance of the worst channel among other channels.
· Proposal 6: The coverage enhancement of PUSCH should be considered in the study. The enhancement target is 7.5 dB.
Decision: The document is noted.
R1-2004179 Baseline coverage evaluation of UL and DL channels – FR2 Nokia, Nokia Shanghai Bell
Decision: The document is noted.
R1-2004425 Baseline coverage performance for FR2 NTT DOCOMO, INC
· Proposal 1: Maximum coupling loss (MCL) methodology is used for the study of NR coverage enhancement. The proposed MCL calculation template is given in table 1.
· Proposal 2: General parameters listed in table 2 should be defined for MCL evaluation. Our proposed values are also listed in the table.
· Proposal 3: Channel-specific parameters listed in table 3 should be defined for MCL evaluation. Our proposed values are also listed in the table. Parameters with TBI (to be indicated) are not defined, so that each company has to indicate its values when presenting the results.
Decision: The document is noted.
R1-2003299 Baseline coverage performance for FR2 Huawei, HiSilicon
R1-2003339 Discussion on baseline coverage performance for FR2 ZTE
R1-2003650 Discussion on the baseline performance and simulation assumptions of coverage enhancement for FR2 CATT
R1-2003774 Discussion on baseline coverage performance for FR2 Intel Corporation
R1-2003779 Downlink coverage in FR2 Charter Communications, Inc
R1-2003915 Scenarios and simulation assumptions for coverage enhancement in FR2 Samsung
R1-2004197 Considerations on Simulation Assumptions for Coverage Enhancements for FR2 Sony
R1-2004305 Simulation assumptions for UL in FR2 InterDigital, Inc.
R1-2004353 Simulation Parameters and Initial Results for FR2 Ericsson
R1-2004498 Baseline FR2 coverage performance Qualcomm Incorporated
Note: a placeholder, no treatment during the e-Meeting
R1-2003300 Potential solutions for coverage enhancement Huawei, HiSilicon
R1-2003340 Discussion on potential techniques for coverage enhancements ZTE
R1-2003343 Potential techniques for NR coverage enhancements Sierra Wireless, S.A.
R1-2003437 Discussion on potential techniques for coverage enhancements vivo
R1-2003651 Discussion on the method for coverage enhancement CATT
R1-2003775 Discussion on potential techniques for NR coverage enhancement Intel Corporation
R1-2003817 Discussion on potential techniques for coverage enhancements Panasonic Corporation
R1-2003835 Potential solutions for PUSCH coverage enhancements China Telecom
R1-2003916 Considerations on potential techniques for coverage enhancement Samsung
R1-2003938 Potential Solutions on Coverage Enhancement for FR1 Nomor Research GmbH, Facebook
R1-2004028 Discussion on potential techniques for coverage enhancement LG Electronics
R1-2004109 The potential solutions to enhance NR coverage OPPO
R1-2004180 Discussion on possible approaches and solutions for NR coverage enhancement Nokia, Nokia Shanghai Bell
R1-2004198 Techniques for NR coverage enhancement Sony
R1-2004250 On potential techniques for coverage enhancement Apple
R1-2004273 Potential techniques for coverage enhancements InterDigital, Inc.
R1-2004354 Potential Areas for Coverage Enhancement Ericsson
R1-2004426 Potential techniques for coverage enhancements NTT DOCOMO, INC
R1-2004499 Potential techniques for coverage enhancement Qualcomm Incorporated
R1-2003341 Discussion on evaluation methodology for NR coverage ZTE
R1-2003438 Discussion on coverage evaluation assumptions and performance for RedCap UE vivo
R1-2003652 Preliminary simulation results for different channels CATT
R1-2003776 Discussion on simulation assumption for NR coverage enhancement Intel Corporation
R1-2003917 Preliminary results for VoIP service in TDD Samsung
R1-2004181 Evaluation assumptions for NR coverage enhancement evaluation Nokia, Nokia Shanghai Bell
R1-2004355 Coverage Enhancements: Four BS Antennas at Low Band Ericsson
R1-2004610 System-level simulation assumptions and evaluation metrics for coverage enhancement Huawei, HiSilicon
Please refer to RP-200861for detailed scope of the SI
R1-2005729 Updated work plan for Study on NR coverage enhancements China Telecom
R1-2005730 TR 38.830 v0.0.2 Study on NR coverage enhancements China Telecom
Decision: The updated TR is endorsed.
[102-e-Post-NR-CovEnh-01] – Yosuke (Softbank)/Marco (Nokia)
Email discussion/approval from 9/7 – 9/17 of remaining simulation assumptions, including
[102-e-Post-NR-CovEnh-02] – Yosuke (Softbank)/Marco (Nokia)/Jianchi (CT)/Yi (Qualcomm)/Xianghui(ZTE)
Email discussion/approval of link budget template, initial collection of simulation results for baseline and enhancements
· Phase 1 (9/10 to 9/29): link budget template
· Phase 2 (9/30 to 10/14): initial collection of simulation results for baseline
· Phase 3: (10/12 to 10/21): initial collection of simulation results for enhancements
R1-2006242 Discussion on simulation assumptions for VoIP InterDigital, Inc.
R1-2005297 Baseline coverage evaluation of UL and DL channels – FR1 Nokia, Nokia Shanghai Bell
· Proposal 1. The qam64-LowSE MCS index table (table 3) shall be considered for the study of NR coverage enhancement.
· Proposal 2. The maximum coverage of PUSCH shall be evaluated for the combination of number of allocated PRBs and MCS index which yields the largest MCL value.
· Proposal 3. Antenna array gain values reflective of realistic implementation and network operation should be used, whenever possible.
· Proposal 4. For antenna array gain for LLS based methodology for FR1, Option 1 should be preferred and hybrid simulation approach to model antenna array gain could be considered. Alternatively, practically relevant correction factors should be used to modify the theoretical array gain calculations.
· Proposal 5. Frame structure in TDD deployments has a significant impact on MCL and coverage of both downlink and uplink channels. The existence of this degree of freedom for the scheduler in practical deployments shall not be ignored when assessing the merit of possible PUSCH enhancements in the context of the SI.
Decision: The document is noted.
R1-2005256 Evaluation on the baseline performance for FR1 Huawei, HiSilicon
R1-2005393 Evaluation on NR coverage performance for FR1 vivo
R1-2005425 Discussion on baseline coverage performance for FR1 ZTE
R1-2005644 Discussion on scenarios for FR1 baseline performance evaluation MediaTek Inc.
R1-2007010 Baseline coverage performance for FR1 CATT (Revision of R1-2005722)
R1-2005731 Baseline performance for NR coverage enhancements for FR1 China Telecom
R1-2005887 Discussion on baseline coverage performance for FR1 Intel Corporation
R1-2005939 FR1 PUSCH Coverage Performance Sierra Wireless, S.A.
R1-2006045 Evaluation on NR coverage performance for FR1 OPPO
R1-2006160 Baseline coverage performance using LLS for FR1 Samsung
R1-2006224 Discussion on the baseline performance in FR1 CMCC
R1-2006243 FR1 baseline coverage performance using LLS InterDigital, Inc.
R1-2006990 Baseline coverage performance analysis in FR1 Panasonic Corporation (Revision of R1-2006346)
R1-2006455 Baseline coverage performance for uplink Indian Institute of Tech (H)
R1-2006530 Evaluation on FR1 coverage performance Apple
R1-2006534 Baseline coverage performance for FR1 Xiaomi Technology
R1-2006578 Evaluation results of coverage for FR1 Urban scenario Sharp
R1-2007048 Link and System Evaluation of Coverage for FR1 Ericsson (rev of R1-2006611)
R1-2006645 Views on target performance metric and values for FR1 coverage enhancements SoftBank Corp.
R1-2007106 Baseline coverage performance for FR1 Charter Communications (rev of R1-2006652)
R1-2006739 Baseline coverage performance for FR1 NTT DOCOMO, INC.
R1-2006818 Baseline FR1 coverage performance Qualcomm Incorporated
[102-e-NR-CovEnh-01] Email discussiona/approval – Yosuke (Softbank)
· By 8/20 – high priority
· By 8/26 – medium
· By 8/28 – last check
R1-2007449 [102-e-NR-CovEnh-01] Summary on A.I. 8.8.1.1 baseline coverage performance using LLS for FR1 Moderator (SoftBank)
Agreements:
· TDL models are used to generate results in the link budget templates for FR1
o This does not preclude companies from performing the link-level simulations using CDL
Agreements (for both FR1 & FR2):
· For the definition of antenna array gain, adopt option 1, i.e. Antenna array gain is included in the link budget template, where there are four antenna gain components
o Note: the four components are illustrated below – the figure is for illustration purpose only
o FFS which component(s) are NOT part of the definition of antenna array gain
Agreements:
· For TDL Option 1
o Definition of MCL
§ Total transmit power - Receiver sensitivity + gNB antenna gain (component 2)
o Definition of MIL
§ Total transmit power - Receiver sensitivity + gNB antenna gain (component 2 + 3 + 4) + UE antenna gain
o Definition of MPL
§ Further discussion offline the definition using below as a starting point:
· Total transmit power - Receiver sensitivity + gNB antenna array gain (component 2+3+4 for TDL option 1) + UE antenna gain - (8) Cable, connector, combiner, body losses (Tx side) - (20) Receiver implementation margin + (21a/b) H-ARQ gain - (25a/b) Shadow fading margin + (26) BS selection/macro-diversity gain - (27) Penetration margin + (28) Other gains – (12) Cable, connector, combiner, body losses (Rx side)
o Note: whether/how to use the above definitions is to be discussed
From GTW session on August 24th,
Agreements:
· Adopt single link budget template for both FR1 and FR2 based on IMT-2020 self-evaluation with rows for MIL, MCL, MPL, and necessary revisions, including adding/removing/revising/simplifying some parameters
o [For LLS based methodology, ]coverage bottleneck(s) identification is performed using at least [MCL and] MIL.
o [MCL values can also be considered to compare channels with similar antenna (and antenna array) gain]
Agreements:
· MPL can be used as supplemental information for coverage bottleneck(s) identification
o The results based on MPL are to be captured in TR
§ Note: this is used to show the achievable ISD.
o The definition of MPL shall be determined in RAN1
o RAN1 will not further discuss on specific values for the parameters related to MPL
§ IMT-2020 values are as a starting point, but:
· companies may use other values, and
· for the parameters that companies think IMT-2020 self-evaluation does not clearly define the values for some scenarios, it is up to companies to report
Agreements:
· RAN1 strives for satisfying appropriate targets identified by companies particularly operators
o The targets may be in the form of one or more of the following:
§ Scenario dependent targets, e.g., ISD/MPL
§ Service dependent targets, e.g., [MCL=147] dB for VoIP;
§ Relative difference between channels, e.g, MIL(/[MCL])
o Further values and details of such targets will be clarified at RAN1#103-e
o Note: there is no intention in RAN1 to update the study item objectives due to the identified targets.
Agreements:
· Adopt single link budget template for both FR1 and FR2 based on IMT-2020 self-evaluation with rows for MIL, MCL, MPL, and necessary revisions, including adding/removing/revising/simplifying some parameters
o For LLS based methodology, coverage bottleneck(s) identification is performed using at least MIL or MCL (assuming the set of simulation assumptions)
§ Even when SLS is used to obtain some components of MIL or MCL, it is categorized as LLS based methodology.
§ MCL values can also be used to identify the coverage bottleneck(s) when applicable
· “applicable” above means the following situation:
o [comparing channels with similar antenna (and antenna array) gain, and/or
o the simulation results with MIL from companies are diverse, and the comparison with MIL is not easy]
Decision: As per email decision posted on August 27th,
Agreements:
· for SIP invite message
o Payload of 1500 bytes can be a starting point.
o The assumptions (TB size, time period etc.) are reported by companies.
o Contributions R1-2003464 and R1-2005259 are taken into account for the evaluation.
§ In addition, 1 second time period can also be considered.
Agreement:
· For PDSCH, other parameters are reported by companies.
Agreements:
· Confirm the working assumption on DMRS configuration for PUSCH:
o For 3km/h: Type I, 1 or 2 DMRS symbol, no multiplexing with data.
· The number of DMRS symbols is reported by companies
Agreements:
· Update the description on Repetitions for PUSCH as follows:
o For VoIP, w/ type A repetition. (optional for type B repetition) the actual number of repetitions is reported by companies.
Agreements:
· Update the row for BLER for PUCCH as follows:
o
FFS: BLER for CSI (10% or 1%, (optional for 10%) )
Agreements:
|
Number of TxRUs for BS |
gNB modelling in LLS for TDL: ·
·
Optional · Companies can report if and how correlation is modelled |
Agreements:
· Remove the whole bullets about gNB architectures to study for CDL and gNB modelling in LLS for CDL
· Note: if CDL is used for link level simulation for a certain purpose, the assumption for the number of TxRUs for BS is reported by companies, which implies that the assumption will be captured in the TR.
Agreements:
· The same PDSCH duration as PDSCH is used for Msg.4 PDSCH (i.e. remove the square bracket)
o Note: this does not preclude Msg4 with retransmission as a baseline.
Agreements:
· Update the BLER for PDCCH as follows:
|
BLER for PDCCH |
1% BLER
|
Agreements:
· The agreement at RAN1#101-e remains: the simulation assumptions for SLS are up to companies’ reports
· The target performance of SLS based methodology, it is recommended to refer the agreements for LLS based methodology as much as possible.
· Note: these proposals are not necessary to be captured in the chairman’s note.
From GTW session on August 28th,
Agreements:
Update the agreements as follows:
· For VoIP performance evaluation based on link-level simulation for FR1
o
A packet size of [320bits] with
20ms data arriving interval is adopted, which component
is as follows:
|
|
Size (bits) |
|
Payload |
256 |
|
CRC |
16 (TBS size lower than 3824 bits) |
|
MAC |
16 (with 12 bits SN size) |
|
RLC |
8 (with 6 bits SN size) |
|
PDCP |
16 |
|
RTP/UDP/IP |
24 (w RoHC) |
·
The
following packet component for AMR-WB 12.65 (kbit/s) is optionally adopted.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
·
[A
packet size of 160 bits with 20ms data arriving interval is optionally adopted for
rural scenario with long distance]
· If applicable, companies report TB size assumed in evaluation
Agreement:
· For the evaluation, it is assumed that Msg. 4 PDSCH payload size is 1040 bits.
Agreements:
· For receiver interference density
o Up to each company to report for all scenarios as baseline
§ E.g. obtained by SLS, the ones for ITU self-evaluation, etc.
Agreements:
Further clarify the agreement on antenna gain and antenna gain components including antenna gain correction factors as follows:
· For both TDL option 1 (table A below) and TDL option 2 & CDL (table B below)
o The gain of antenna gain component 1 is included in LLS results
o The gain of antenna gain component 2 is included in link budget template
§ The gain is expressed by 10 * log 10( N/k ) - D1
§ For TDL option 2 & CDL, the gain is 0 dB
o The gain of antenna gain component 3 is included in link budget template
o The gain of antenna gain component 4 is included in link budget template
§ The gain of antenna gain components 3 and 4 is expressed by Antenna Element Gain + 10 * log 10( M/N ) -D2
§ For Tx, One row is used represent the gain of antenna gain component 3 + 4, i.e. row No. (4)
§ For Rx, One row is used represent the gain of antenna gain component 3 + 4, i.e. row No. (11)
§ Note: more appropriate name or explanation will be added to row No.(4) and (11). Details can be discussed when the link budget template is updated.
Agreements:
· Define PSD for DL Tx power, which is depend on deployment scenario
o For 4GHz frequency,
§ For rural with long distance scenario, PSD is 24 and 33 dBm/MHz
§ For rural scenario, PSD is 24 and 33 dBm/MHz
§ For urban scenario, PSD is 24 and 33 dBm/MHz
o For 2.6 GHz frequency,
§ For rural with long distance scenario, PSD is 33 dBm/MHz
§ For rural scenario, PSD is 33 dBm/MHz
§ For urban scenario, PSD is 33 dBm/MHz
o For 700MHz, 2GHz frequency
§ For rural with long distance scenario, PSD is 36 dBm/MHz
§ For rural scenario, PSD is 36 dBm/MHz
§ For urban scenario, PSD is 36 dBm/MHz
· Modify the description of row(s) of link budget template:
o Keep the meaning of Total transmit power (row (3) ) and adding a new row (3 bis):
§ (3bis) means the transmit power for occupied channel bandwidth for control channel (17a) or data channel (17b)
· Companies are requested to set appropriate values for parameters, which is used to determine total transmit power ( row (3) and/or (3bis) ), to satisfy the PSD value above
· Note: RAN1 will further check the consistency of the definition of row(s) in link budget table when the IMT-2020 based link budget tale is updated
Agreements:
For FR1 and FR2:
Agreements:
Definition of MPL for TDL option 1
Decision: As per email decision posted on August 28th,
Agreements:
· As for the agreement on antenna gain and antenna gain components including antenna gain correction factors, Table A and Table B are defined as below
Table A. antenna gain components for TDL option 1
Table B. antenna gain components for TDL option 2 and CDL
Agreement:
· Latency requirements assumed in VoIP evaluation for TDD and FDD are reported by companies.
R1-2006612 Link and System Evaluation of Coverage for FR2 Ericsson
Proposals:
· As a starting point, neglect any constraints imposed by certain beamforming implementation such as the possibility to simultaneous receive or transmit with maximum gain in more than one direction.
· Neglect PTRS overhead and compensation algorithms.
· Focus coverage enhancements efforts on uplink and downlink data.
Decision: The document is noted. Further revised in R1-2007049.
R1-2005257 Evaluation on the baseline performance for FR2 Huawei, HiSilicon
R1-2005298 Baseline coverage evaluation of UL and DL channels – FR2 Nokia, Nokia Shanghai Bell
R1-2005394 Evaluation on NR coverage performance for FR2 vivo
R1-2005426 Discussion on baseline coverage performance for FR2 ZTE
R1-2005723 Baseline coverage performance for FR2 CATT
R1-2005888 Discussion on baseline coverage performance for FR2 Intel Corporation
R1-2006046 Evaluation on NR coverage performance for FR2 OPPO
R1-2006161 Baseline coverage performance using LLS for FR2 Samsung
R1-2006225 Discussion on the baseline performance in FR2 CMCC
R1-2006244 FR2 baseline coverage performance using LLS InterDigital, Inc.
R1-2006740 Baseline coverage performance for FR2 NTT DOCOMO, INC.
R1-2006819 Baseline FR2 coverage performance Qualcomm Incorporated
[102-e-NR-CovEnh-02] Email discussiona/approval – Marco (Nokia)
· By 8/20 – high priority
· By 8/26 – medium
· By 8/28 – last check
R1-2007414 FL Summary of Baseline Coverage Evaluation of DL and UL for FR2 Moderator (Nokia)
Decision: As per email decision posted on August 26th,
Agreements:
R1-2005258 Discussion on the potential coverage enhancement solutions for PUSCH Huawei, HiSilicon
· Proposal 1: Joint channel estimation across consecutive PUSCH transmissions should be studied.
· Proposal 2: Mechanism to reduce resource waste in HARQ (re)transmissions should be studied, such as PUSCH (re)transmissions with finer granularities and shared DMRS among multiple PUSCH retransmissions to reduce DMRS overhead.
· Proposal 3: Study FDD higher power UE for PUSCH coverage enhancement
Decision: The document is noted.
R1-2005732 Potential solutions for PUSCH coverage enhancements China Telecom
· Proposal 1: Increasing the number of repetition for PUSCH or spreading the repetitions of transmission within the delay budget can be considered to enhance the coverage performance of voice service.
· Proposal 2: PUSCH repetition should be considered for Msg3.
· Proposal 3: The repetition mechanism for PUSCH should be enhanced to overcome the cancellation of the repetition due to DL/UL collision for TDD.
· Proposal 4: Early termination of PUSCH repetition can be considered.
· Proposal 5: For frequency hopping, more frequency offsets can be configured by higher layer.
· Proposal 6: For intra-slot frequency hopping and inter-slot frequency hopping, more frequency positions can be considered for the actual PUSCH transmission.
· Proposal 7: Inter-bundle frequency hopping can be considered for PUSCH coverage enhancements.
· Proposal 8: Sub-PRB transmission can be considered for PUSCH coverage enhancements.
· Proposal 9: DM-RS enhancement can be considered for PUSCH coverage enhancements.
· Proposal 10: Packet aggregation can be considered for PUSCH coverage enhancements.
Decision: The document is noted.
R1-2006977 Potential coverage enhancement techniques for PUSCH Qualcomm Incorporated (Revision of R1-2006820)
· Proposal 1: Techniques for UE transmit waveform design that allow further reduction in the MPR values for DFT-S-OFDM and CP-OFDM waveforms should be studied for coverage enhancement. In particular, consider tone reservation principle for DFT-s-OFDM and CP-OFDM waveforms to further reduce PAPR.
· Proposal 2: Consider DMRS bundling technique for coverage enhancement in NR Rel-17.
· Proposal 3: Consider adaptive DMRS configuration for PUSCH to improve both coverage and link efficiency and introduce signaling mechanisms for dynamic DMRS configuration change.
· Proposal 4: Additional RS should be studied for improving channel estimation to extend PUSCH coverage.
· Proposal 5: Consider TBS scaling and optimization across multiple slots for PUSCH coverage enhancement for eMBB and VoNR.
· Proposal 6: Consider Msg3 PUSCH repetition as an enhancement technique to extend coverage of Msg3 in Rel-17.
Decision: The document is noted.
R1-2005299 Discussion on potential approaches and solutions for NR PUSCH coverage enhancement Nokia, Nokia Shanghai Bell
R1-2005395 Discussion on Solutions for PUSCH coverage enhancement vivo
R1-2005427 Discussion on potential techniques for PUSCH coverage enhancements ZTE
R1-2005584 On PUSCH coverage enhancement techniques Sony
R1-2005724 Discussion on potential techniques for PUSCH coverage enhancement CATT
R1-2005758 Discussion on PUSCH coverage enhancement NEC
R1-2005889 Discussion on potential techniques for PUSCH coverage enhancement Intel Corporation
R1-2005938 Potential techniques for PUSCH coverage enhancements Sierra Wireless, S.A.
R1-2006047 Consideration on PUSCH coverage enhancement OPPO
R1-2006162 PUSCH coverage enhancement Samsung
R1-2006226 Discussion on the PUSCH coverage enhancement CMCC
R1-2006245 PUSCH coverage enhancement InterDigital, Inc.
R1-2006253 Potential solutions for PUSCH coverage enhancement Spreadtrum Communications
R1-2006348 Discussion on PUSCH coverage enhancements Panasonic Corporation
R1-2006456 PUSCH coverage enhancements Indian Institute of Tech (H)
R1-2006531 On potential techniques for PUSCH coverage enhancement Apple
R1-2006579 PUSCH coverage enhancement Sharp
R1-2006613 PUSCH coverage enhancement Ericsson
R1-2006741 Potential techniques for PUSCH coverage enhancements NTT DOCOMO, INC.
R1-2006877 Discussion on potential techniques for coverage enhancement LG Electronics
R1-2006892 Discussion on potential techniques for PUSCH coverage enhancement WILUS Inc.
[102-e-NR-CovEnh-03] Email discussiona/approval – Jianchi (CT)
· By 8/20 – high priority
· By 8/26 – medium
· By 8/28 – last check
R1-2007404 [102-e-NR-CovEnh-03] Email discussion/approval on PUSCH coverage enhancement Moderator (China Telecom)
Decision: As per email decision posted on August 21st,
Agreements:
6.1 PUSCH coverage enhancements
6.1.1 Time-domain based solutions
6.1.2 Frequency-domain based solutions
6.1.3 DM-RS enhancements
6.1.4 Power-domain based solutions
6.1.5 Spatial-domain based solutions
6.1.6 Others
From GTW session on August 25th,
Agreements:
· Prioritize the study on the performance and specification impacts on time domain based solutions for PUSCH enhancements, including
o
Increase the number of repetitions
for PUSCH repetition type A
§ PUSCH repetition with non-consecutive slots/on the basis of available slots for TDD
§ Note: whether increasing the number of PUSCH repetition for FDD depends on the outcome of AI 8.8.1.1.
o Enhancement on PUSCH repetition Type B
§ E.g., actual repetition across the slot boundary, or the length of actual repetition larger than 14 symbols, etc.
o TB processing at least over multi-slot PUSCH
§ e.g., single TB, sized for a single slot, but transmitted in parts over multiple slots; or single TB, sized for multiple slots, transmitted over multiple slots, and in conjunction with repetition, etc.
· FFS
o OCC spreading based repetition
o Symbol-level repetition
o TB interleaving
o RV repetition
o Early termination of PUSCH repetitions
Agreements:
· Following solutions are not considered for PUSCH enhancements in this study item in RAN1:
o Enhancements to improve spherical coverage / beam correspondence
o Reflective arrays
o Polarization aspects of the UL and/or DL reference signals
Agreements:
· Prioritize the study on the performance and specification impacts on DM-RS enhancements for PUSCH, including
o Cross-slot channel estimation
o With a lower priority compared with cross-slot channel estimation (i.e., companies are encouraged to study it)
§ Lower density
· E.g., DM-RS sharing among multiple PUSCH transmissions or lower DMRS density in the frequency domain.
§ Higher density
· E.g., in time or frequency domain, e.g., 1-comb pattern
§ Adaptive configuration
§ DM-RS balancing among frequency hops
Agreements:
· Multiple layer PUSCH transmission with DFT-S-OFDM for PUSCH enhancements can be studied with low priority.
· Study open-loop/closed loop Tx diversity for PUSCH enhancements with low priority.
From GTW session on August 28th,
Agreements:
· Study the performance and specification impacts on frequency domain based solutions for PUSCH, including
o Inter-slot frequency hopping
§ with more frequency offsets
§ with more frequency hopping positions.
o Inter-slot frequency hopping with inter-slot bundling to enable cross-slot channel estimation
o Enhancements on frequency hopping for PUSCH repetition type B
§ Note that the above inter-slot frequency hopping enhancement can apply for PUSCH repetition type B
o [Sub-PRB transmission for VoIP]
§ FFS: details, e.g., number of tones, multi-slot aggregation
· FFS
o Intra-slot frequency hopping
§ with more frequency offsets
§ with more frequency hopping positions.
[Note: Appropriate simulation assumptions are expected.]
Agreements:
· Study following power domain based solution for PUSCH enhancements
o Waveform design to optimize MPR/A-MPR
o [FDD high power UE]
o Power boosting for pi/2 BPSK
Note: if a LS to RAN4 (for the last two bullets) is deemed necessary, target sending the LS in the 1st week of RAN1#103-e.
R1-2005759 Discussion on PUCCH coverage enhancement NEC
· Proposal 1: If PUSCH cross channel estimation is adopted for coverage enhancement, PUCCH cross channel estimation should also be supported for PUCCH repetition case.
· Proposal 2: If PUSCH enhanced frequency hopping is adopted for coverage enhancement, PUCCH enhanced frequency hopping should also be supported.
· Proposal 3: Sequence based transmission (PUCCH format 0 like) could be studied to enhance PUCCH format 1 for UCI up to 2 bits.
· Proposal 4: Sequence based transmission could be studied to enhance PUCCH transmission for UCI larger than 2 bits and up to X bits.
Decision: The document is noted.
R1-2006227 Discussion on the PUCCH coverage enhancement CMCC
· Proposal 1: Short sequence combination based PUCCH format can be considered for more than 2 bits UCI to improve PUCCH performance.
Decision: The document is noted.
R1-2006742 Potential techniques for PUCCH coverage enhancements NTT DOCOMO, INC.
· Proposal 1: Extension of PUCCH repetition to support non-consecutive slots can be one of the potential techniques for PUCCH coverage enhancement.
· Proposal 2: Improvement of PUCCH format 0 should be considered for FR2 VoIP, and repetition for format 0 can be one of the potential techniques.
Decision: The document is noted.
R1-2005273 Discussion on the potential coverage enhancement solutions for PUCCH Huawei, HiSilicon
R1-2005300 Discussion on potential approaches and solutions for NR PUCCH coverage enhancement Nokia, Nokia Shanghai Bell
R1-2005396 Discussion on Solutions for PUCCH coverage enhancement vivo
R1-2005428 Discussion on potential techniques for PUCCH coverage enhancements ZTE
R1-2005585 On PUCCH coverage enhancement techniques Sony
R1-2005725 Discussion on potential techniques for PUCCH coverage enhancement CATT
R1-2007175 Discussion on potential techniques for PUCCH coverage enhancement Intel Corporation (rev of R1-2005890)
R1-2006048 Consideration on PUCCH coverage enhancement OPPO
R1-2006163 PUCCH coverage enhancement Samsung
R1-2006246 PUCCH coverage enhancement InterDigital, Inc.
R1-2006349 Discussion on PUCCH coverage enhancements Panasonic Corporation
R1-2006457 PUCCH coverage enhancements Indian Institute of Tech (H)
R1-2006580 PUCCH coverage enhancement Sharp
R1-2006614 PUCCH coverage enhancement Ericsson
R1-2006821 Potential coverage enhancement techniques for PUCCH Qualcomm Incorporated
R1-2006880 Limitations of NR short block-length codes for PUCCH coverage enhancement EURECOM
R1-2006893 Discussion on potential techniques for PUCCH coverage enhancement WILUS Inc.
[102-e-NR-CovEnh-04] Email discussiona/approval – Yi (Qualcomm)
· By 8/20 – high priority
· By 8/26 – medium
· By 8/28 – last check
R1-2007473 FL summary of PUCCH coverage enhancement Moderator (Qualcomm)
From GTW session on August 25th,
Contingent on all of the outcome of sub-agenda 8.8.1 regarding PUCCH enhancements, prioritize the study of the following schemes for PUCCH coverage enhancement,
Note 1: other schemes are not excluded.
Note 2: the study on DMRS bundling for PUCCH repetition can be a joint study with DMRS bundling for PUSCH repetition studied under 8.8.2.1.
Note 3: Companies are invited to report details of the receivers used in the evaluation. Advanced receiver can be included (not mandatory) in performance evaluations. Performance and receiver complexity are discussed respect to a baseline Rel-15/16 PUCCH scheme.
Note 4: proposed PUCCH repetitions scheme shall account for the resources used by PUSCH to meet the throughput target and should be compared against Rel-15/16 PUCCH repetition framework.
[Note 5: enhancement on one or more PUCCH formats/UCI types may or may not be needed, depends on the outcome of sub-agenda 8.8.1]
Agreements:
Deprioritize the study of the following schemes for PUCCH coverage enhancement
· UE Antenna configuration enhancement for FR2
· Relay (including sidelink relay)
· Reflective arrays
From GTW session on August 28th,
Agreements:
Contingent on all of the outcome of sub-agenda 8.8.1 regarding PUCCH enhancements, the following schemes for PUCCH coverage enhancement can be further studied
· Sequence based PF 0/1 with Pi/2 BPSK
· Pre-DFT data-RS multiplexing for PF2 with Pi/2 BPSK
· UCI size reduction
· Freq hopping enhancement for PUCCH
· Short/mini-slot PUCCH repetition
· Power control enhancement for PUCCH (including power boost for pi/2 BPSK)
· Increase maximum # allowed repetitions for PUCCH
· PUCCH Transmit diversity scheme
· Symbol-level repetition for long PUCCH
· Split UCI payload on short and long PUCCH on adjacent S and U slots
· Potential higher DMRS density for PUCCH with repetitions
Conclusion:
For the performance evaluation of PUCCH coverage enhancement schemes under 8.8.2.2, use PUCCH simulation assumptions agreed under 8.4.1 in RAN1#101e as a baseline. Companies are encouraged to report additional simulation parameters/assumptions particular to their proposed schemes together with the simulations results in RAN1 #103e.
R1-2005429 Discussion on potential techniques for channels other than PUSCH and PUCCH ZTE
· Proposal 1: Study compact fallback DCI for broadcast PDCCH coverage enhancement.
· Proposal 2: PDCCH repetition can be considered for PDCCH coverage enhancement.
· Proposal 3: PDCCH-less for broadcast messages can be considered for NR coverage enhancement.
· Proposal 4: Increasing SSB number can be considered for NR coverage enhancement.
· Proposal 5: Multiple Msg.1 transmissions before the end of a monitored Msg.2 reception window can be considered.
· Proposal 6: Beam refinement based on CSI-RS measurement during RACH procedure can be considered.
· Proposal 7: MSG3 PUSCH repetition can be considered for coverage enhancement.
Decision: The document is noted.
R1-2005274 Discussion on the potential coverage enhancement solutions for other channels Huawei, HiSilicon
R1-2005301 Discussion on potential approaches and solutions for NR coverage enhancement: other channels than PUSCH and PUCCH Nokia, Nokia Shanghai Bell
R1-2005397 Discussion on coverage enhancement for channels other than PUCCH and PUSCH vivo
R1-2005586 Coverage enhancement for channels other than PUSCH and PUCCH Sony
R1-2005726 Disucssion on coverage enhancement for channels other than PUSCH and PUCCH CATT
R1-2005891 Discussion on NR coverage enhancement for other physical channels Intel Corporation
R1-2006049 Enhancement on NR channels for coverage OPPO
R1-2006164 Coverage enhancement for channels other than PUSCH and PUCCH Samsung
R1-2006292 Coverage enhancement for initial access InterDigital, Inc.
R1-2006532 On potential techniques for PDCCH and PDSCH coverage enhancement Apple
R1-2006615 Coverage enhancement for channels other than PUSCH and PUCCH Ericsson
R1-2006743 Potential techniques for coverage enhancement for channels other than PUSCH and PUCCH NTT DOCOMO, INC.
R1-2006822 Potential coverage enhancement techniques for other channels Qualcomm Incorporated
[102-e-NR-CovEnh-05] Email discussiona/approval – Xianghui (ZTE)
· By 8/20 – high priority
· By 8/26 – medium
· By 8/28 – last check
R1-2007392 Feature lead summary on coverage enhancement for channels other than PUSCH and PUCCH Moderator (ZTE)
Decision: As per email decision posted on August 23rd,
Agreements:
Agreement:
Agreement:
If PRACH enhancement is needed, study it in NR coverage enhancement SI, e.g. multiple PRACH transmissions.
Agreement:
Study whether/how to enable potential techniques for early CSI and/or beam refinement for physical channels during initial/random access procedure.
Agreements:
Agreement:
Further discuss the evaluation of PDSCH and discuss whether/how to enhance PDSCH in NR coverage enhancement SI.
From GTW session on August 26th,
Agreement:
Enhancement to PUSCH scheduled by RAR UL grant will not consider the optimization specific for CFRA case in NR coverage SI.
From GTW session on August 28th,
Agreements:
· Capture the following structure in TR 38.830.
o 6.3 Coverage enhancements for channels other than PUSCH and PUCCH
o 6.3.1 Enhancements for Msg3 PUSCH
o
6.3.2 Others
· Note: The above structure can be further updated by adding more sections under section 6.3 for other enhancements if justified.
R1-2005259 Discussions on simulation assumptions for VoIP Huawei, HiSilicon
R1-2005303 Evaluation assumptions for NR coverage enhancement evaluation Nokia, Nokia Shanghai Bell
R1-2005398 Considerations on Evaluation Assumptions for Coverage Enhancements vivo
R1-2005430 Discussion on evaluation methodology for NR coverage ZTE
R1-2005727 Discussion on the methodology for baseline coverage performance using LLS CATT
R1-2005733 Remaining issues on evaluation methodology for NR coverage enhancements China Telecom
R1-2005892 Discussion on simulation assumptions for NR coverage enhancement Intel Corporation
R1-2006050 Functionality of Coverage Enhancement and other SI/WI OPPO
R1-2006293 Reducing PDCCH load of coverage-limited UEs InterDigital, Inc.
R1-2006616 Evaluation methodology for coverage enhancements Ericsson
R1-2006823 Other coverage enhancement aspects Qualcomm Incorporated
Please refer to RP-200861for detailed scope of the SI
R1-2007992 TR 38.830 v0.0.3 Study on NR coverage enhancements China Telecom
[103-e-NR-CovEnh-01] – Jianchi (China Telecom)
Email discussion for TR38.830 update
R1-2009852 [103-e-NR-CovEnh-01] Summary of email discussion on TR38.830 update Moderator (China Telecom)
Decision: Further to GTW on Oct.29th, as per email decision posted on Oct.30th,
Next update to capture all agreements from RAN1#103-e till 11/12; further extended to 11/19
Decision: As per email decision posted on Nov.20th,
R1-2007484 [102-e-Post-NR-CovEnh-02] Summary on email discussion/approval of initial collection of simulation results for baseline Moderator (SoftBank, Nokia)
Decision: The document (outcomes from last meeting post-email discussion) is noted.
R1-2007483 [102-e-Post-NR-CovEnh-02] Phase 3: initial collection of simulation results for enhancements Moderator (China Telecom)
R1-2009808 [103-e-NR-CovEnh-EvaluationResults]: Summary of simulation results for baseline Moderator (SoftBank, Nokia)
Decision: The document is noted as summary of email discussion on the collection of simulation results for baseline only.
R1-2009568 Evaluation on the baseline performance for FR1 Huawei, HiSilicon (rev of R1-2007581)
R1-2007678 Evaluation on NR coverage performance for FR1 vivo
R1-2007741 Discussion on baseline coverage performance for FR1 ZTE
R1-2007872 Baseline coverage performance for FR1 CATT
R1-2007904 Baseline coverage performance for uplink in FR1 Indian Institute of Tech (H)
R1-2007931 FR1 PUSCH Baseline Coverage Performance Sierra Wireless, S.A.
R1-2007952 On baseline coverage performance for FR1 Intel Corporation
R1-2007993 Updated baseline performance for NR coverage enhancements for FR1 China Telecom
R1-2008024 Discussion on the baseline performance in FR1 CMCC
R1-2008089 Baseline coverage performance for FR1 Xiaomi
R1-2008179 Baseline coverage performance using LLS for FR1 Samsung
R1-2008269 Evaluation on NR coverage performance for FR1 OPPO
R1-2009727 Link and System Evaluation of Coverage for FR1 Ericsson (rev of R1-2008343)
R1-2009582 Baseline coverage performance analysis in FR1 Panasonic Corporation (rev of R1-2008377)
R1-2008380 Target value for FR1 voice coverage enhancements SoftBank Corp.
R1-2009617 Link budget analysis for FR1 Sharp (rev of R1-2008398)
R1-2008478 Evaluation on FR1 coverage performance Apple
R1-2009169 FR1 baseline coverage performance using LLS InterDigital, Inc. (rev of R1-2008481)
R1-2008515 Discussion on scenarios for FR1 baseline performance evaluation MediaTek Inc.
R1-2008557 Baseline coverage performance for FR1 NTT DOCOMO, INC.
R1-2009316 Baseline FR1 coverage performance Qualcomm Incorporated (rev of R1-2008624)
R1-2008701 Baseline coverage evaluation of UL and DL channels – FR1 Nokia, Nokia Shanghai Bell
R1-2009341 Summary #1 on A.I. 8.8.1.1 baseline coverage performance using LLS for FR1 Moderator (SoftBank)
Decision: Noted. From GTW on 10/26:
[103-e-NR-CovEnh-02] – Yosuke (Softbank)
Email discussion for FR1 coverage performance
Decision: From GTW on 10/29:
Agreements:
R1-2009809 Summary of [103-e-NR-CovEnh-02] A.I. 8.8.1.1 baseline coverage performance using LLS for FR1 Source: Moderator (SoftBank)
Agreements:
· Rephrase the following terminologies, which is used in e.g. link budget template:
o “PDCCH of Msg.2” refers to as “broadcast PDCCH (PDCCH of Msg.2)”
o “PDCCH” refers to as “unicast PDCCH”
Agreements:
· Representative values are computed for the following channels or signals for FR1, and they are used to draw observation and to identify bottlenecks (if any) if the number of samples for each scenario is more than Y (Y=3)
o PUSCH for eMBB (FDD, & TDD with DDDSU and DDDSUDDSUU for 4GHz, DDDDDDDSUU for 2.6GHz)
o PUSCH for VoIP (FDD, & TDD with DDDSU and DDDSUDDSUU for 4GHz, DDDDDDDSUU for 2.6GHz)
o PUCCH Format 1 with 2bits
o PUCCH Format 3 with 11bits
o PUCCH Format 3 with 22bits
o SSB
o PRACH format 0
o PRACH format B4
o Broadcast PDCCH (PDCCH of Msg.2)
o PDSCH for Msg.2
o PUSCH of Msg.3
o PDSCH of Msg.4
o Unicast PDCCH
o PDSCH for eMBB (FDD, & TDD with DDDSU and DDDSUDDSUU for 4GHz, DDDDDDDSUU for 2.6GHz)
o PUCCH with HARQ-ACK for Msg.4
Agreements:
· The following scenarios are used for drawing observations and bottleneck identification for FR1
o 1st priority
§ Urban 4GHz TDD
§ Urban 2.6GHz TDD
§ Rural 4GHz TDD NLOS O2I
§ Rural 700MHz FDD NLOS O2I
§ Rural 2GHz FDD NLOS O2I
§ Rural 2.6GHz TDD NLOS O2I
o 2nd priority
§ Rural 700MHz with long distance FDD LOS O2O
§ Rural 4GHz with long distance TDD LOS O2O
o Note: the difference between 1st priority and 2nd priority is as follows
§ RAN1 discussion will focus on 1st priority scenarios for drawing observation and bottleneck identification, while less time will be spent on 2nd priority scenarios
§ If RAN1 cannot reach consensus on 2nd priority scenarios, the scenario(s) will still be captured in the Appendix of the TR for completeness, but no observation/conclusion will be made for them.
Agreements
· No categorization by other simulation parameters (such as UE speed, antenna gain correction factors) will be introduced for FR1 for deriving representative values
o The amount of available results for DL channels in FR1 4GHz scenario should be considered as given by the total number of available results for both 33 dBm/MHz and 24 dBm/MHz, given that they can be derived one from the other by simple subtraction, and where each company is counted only once.
o In order to address the misalignment issue of the companies’ evaluation results due to no categorization and/or different simulation assumptions,
§ Number of samples and standard deviation is shown together with a representative value, and
§ A description on the potential fluctuation due to no categorization and/or different simulation assumptions can be added in the observation
· The evaluation results, which are used for neither representative value derivation nor coverage bottleneck identification due to the lack of number of samples etc., can be used to make additional observations to be captured in the TR.
o This discussion will be held in RAN1#103-e on a low priority basis.
Agreements:
· For, Scenario dependent targets, e.g., ISD/MPL
o The following formula is used to convert an ISD value to a target MPL value (to add the reference when capturing into TR):
§ For urban scenarios,
§ For rural scenarios,
§ For rural with long distance scenarios (working assumption)
Agreements:
· All the parameters/values/configurations related to FR1 modelling for which an agreement has not been reached among companies prior to RAN1 #103-e, will be henceforth treated according to the “reported by companies” principle. RAN1 will not spend further time during RAN1 #103-e on the resolution of these issues.
Agreements:
· For Scenario dependent targets, e.g., ISD/MPL
o For each scenario, multiple target ISD values can be used to draw observations, and a single target ISD value can be used to identify bottlenecks (if applicable)
o Target ISD values for each scenario are as follows:
§ Urban 4GHz TDD –400, 500m for observation and 400m for bottleneck identification
§ Urban 2.6GHz TDD –400, 500m for observation and 400m for bottleneck identification
§ Rural 4GHz TDD NLOS O2I – 1732 and 3000 m for observation and 1732m with 33dBm/MHz BS transmit power for bottleneck identification
§ Rural 2.6 GHz TDD NLOS O2I – 1732m for observation and bottleneck identification
§ Rural 2 GHz FDD NLOS O2I – 1732m for observation and bottleneck identification
§ Rural 700MHz FDD NLOS O2I –3000m, 4000m for observation and 4000m for bottleneck identification
Agreements:
· For Service dependent targets for VoIP
o MCL of 139.2dB is used for Rural 700MHz scenario for drawing observation and can be used to identify bottlenecks (if applicable)
§ Captured the following table, which shows how the target value (i.e. 139.2dB) is derived, in Annex of the TR.
|
Transmitter |
|
|
(2a) Number of transmit chains modelled in LLS |
1 |
|
(3) Total transmit
power (dBm) |
23 |
|
(3a) System bandwidth for downlink, or occupied bandwidth for uplink (Hz) |
3840000 |
|
(3b) Power Spectrum
Density = (3) - 10 log( (3a) / 1000000 ) (dBm/MHz) |
17.16 |
|
(3c) bandwidth used
for the evaluated channel (Hz) |
3840000 |
|
(3bis) Total transmit power for occupied bandwidth = (3b) + 10 log ( (3c) / 1000000 ) (dBm) |
23.00 |
|
(5) total antenna gain
at antenna gain component 2 of transmitter = (5a) - (5b) (dB) |
0 |
|
(5a) antenna gain at
antenna gain component 2 of transmitter = 10 log( (2)/(2a)) (dB) |
0 |
|
(5b) antena gain
correction factor at antenna gain component 2 of transmitter (dB) |
0 |
|
Receiver |
|
|
(10a) Number of
[receive TxRUs] |
2 |
|
(10b) Number of receive chains modelled in LLS |
2 |
|
(11bis) total antenna
gain at antenna gain component 2 of receiver = (11bis-a) - (11bis-b) (dB) |
0 |
|
(11bis-a) antenna gain
at antenna gain component 2 of receiver = 10 log( (10a)/(10b)) (dB) |
0 |
|
(11bis-b) antena gain
correction factor at antenna gain component 2 of receiver (dB) |
0 |
|
(13) Receiver noise figure (dB) |
5 |
|
(14) Thermal noise density (dBm/Hz) |
-174 |
|
(15) Receiver interference density (dBm/Hz) |
-165.7 |
|
(16) Total noise plus interference density = 10 log (10^(( (13) + (14))/10) + 10^((15)/10)) (dBm/Hz) |
-164.0 |
|
(18) Effective noise power = (16) + 10 log((3c)) (dBm) |
-98.2 |
|
(19) Required SNR (dB) |
5 |
|
(20) Receiver implementation margin (dB) |
2 |
|
(21) H-ARQ gain (dB)
or Process gain for UMTS |
25 |
|
(22) Receiver sensitivity = (18) + (19) + (20) – (21) (dBm) |
-116.2 |
|
(22bis) MCL = (3bis) - (22) + (5) + (11bis) (dB) |
139.2 |
o The following channels/signals are used:
§ PUSCH for VoIP
§ PUCCH format 1
§ PUCCH format 3 with 11bits
§ SSB
§ PRACH format 0
§ PDCCH of Msg.2
§ PDSCH for Msg.2
§ PUSCH of Msg.3
§ PDSCH of Msg.4
§ PDCCH
Agreements:
· Capture the following table (working assumption) showing the result of bottleneck identification by using absolute metrics
Agreements:
· For FR1, the potential bottleneck channels identified by absolute metrics can be further filtered by using relative difference between channels in MIL
o FFS details, including the possibility of applying the relative difference for a limited set of scenario(s)
Agreement:
· For Rural with long distance 4GHz TDD LOS O2O scenario, 12km is applied for observation and bottleneck identification
Agreements:
· The following channels are identified as the potential bottleneck channels derived from the absolute metrics (i.e. service dependent metric and scenario dependent metrics) and the relative metric (i.e. relative difference between channels)
o 1st priority
§ PUSCH for eMBB (for FDD and TDD with DDDSU, DDDSUDDSUU and DDDDDDDSUU)
§ PUSCH for VoIP (for FDD and TDD with DDDSU, DDDSUDDSUU)
o 2nd priority
§ PRACH format B4
§ PUSCH of Msg.3
§ PUCCH format 1
§ PUCCH format 3 with 11bit
§ PUCCH format 3 with 22bit
§ Broadcast PDCCH
Agreements:
· Confirm the Working Assumption on the pathloss formula for rural with long distance scenarios.
· TR editor will take care of the detailed description regarding which model in the reference document is used for these formulae.
Agreements:
· For Relative difference between channels
o MIL is used to derive relative differential values.
o Relative difference between channels is used to draw observation for the 1st and 2nd priority scenarios, and can be used to identify bottlenecks (if applicable)
o For each channel, relative differential value is defined by the following formula for FR1
§ (MIL of the channel) – (MIL of the worst channel among the channels that have more than 3 samples)
Agreements:
· Capture the following tables in Annex of the TR
o Note: Even when the channel has less than 4 samples, it can be included in the table.
o Note: The excelsheet for these tables is:
o Urban 4GHz scenario
§ For BS with 33dBm/Hz Tx power
§ For BS with 24dBm/Hz Tx power
o Urban 2.6GHz scenario
o Rural 4GHz TDD NLOS O2I scenario
§ For BS with 33dBm/Hz Tx power
§ For BS with 24dBm/Hz Tx power
o Rural 2.6GHz TDD NLOS O2I scenario
o Rural 2GHz Rural 2GHz FDD NLOS O2I scenario
o Rural 700MHz FDD NLOS O2I scenario
o Rural 4GHz with long distance TDD NLOS O2O scenario
Agreements:
· Capture the following observation for Urban 4GHz TDD scenario in the TR
o PUSCH for eMBB with frame structure DDDSU is the worst channel in terms of MIL, and can be the coverage bottleneck for the given scenario.
§
If
only one channel can be enhanced for frame structure DDDSU, coverage
enhancement of 10.26 dB can be achieved at maximum.
o In order to achieve 400m ISD, the following channel(s) needs to be enhanced:
§
PUSCH for eMBB with frame
structure DDDSU: 8.12 dB
§
PUSCH for eMBB with frame
structure DDDSUDDSUU: 7.09 dB
§
If low transmit
power BS (i.e 24dBm/MHz) is assumed,
·
Broadcast PDCCH
(PDCCH of Msg.2): 2.17dB
o In order to achieve 500m ISD, the following channel(s) needs to be enhanced:
§
PUSCH for eMBB with frame
structure DDDSU: 11.91 dB
§
PUSCH for eMBB with frame
structure DDDSUDDSUU: 10.88 dB
§
PUSCH for VoIP with frame
structure DDDSU: 0.03 dB
· However as shown by standard deviation in the table, this additional gain may be achieved by the existing technologies or parameter optimization, which means that new a functionality in Rel-17 is not always required.
§
PUSCH for VoIP with frame
structure DDDSUDDSUU: 0.86 dB
· However as shown by standard deviation in the table, this additional gain may be achieved by the existing technologies or parameter optimization, which means that a new functionality in Rel-17 is not always required.
§
PUCCH format 3 with 22 bit
payload: 2.62 dB
§
PRACH
Format B4: 0.48dB
· However as shown by standard deviation in the table, this additional gain may be achieved by the existing technologies or parameter optimization, which means that a new functionality in Rel-17 is not always required.
§
PUSCH of Msg.3: 1.11 dB
o If low transmit power BS (i.e 24dBm/MHz) is assumed, the following DL channel(s) needs to be enhanced, additionally.
§ For 400m ISD
· Broadcast PDCCH (PDCCH of Msg.2)
§ For 500m ISD
·
SSB: 2.85dB
·
Broadcast PDCCH (PDCCH of
Msg.2): 5.95dB
·
PDSCH for eMBB with
frame structure DDDSUDDSUU: 1.09 dB
o However as shown by standard deviation in the table, this additional gain may be achieved by the existing technologies or parameter optimization, which means that a new functionality in Rel-17 is not always required.
Note a typo to be handled in the TR: For the observation of Urban 4GHz TDD scenario with 500m ISD, it is clarified that PUSCH of Msg.3 does not need to be enhanced.
Agreements:
· Capture the following observation for Urban 2.6GHz TDD scenario in the TR
o PUSCH for eMBB with frame structure DDDDDDDSUU is the worst channel in terms of MIL, and can be the coverage bottleneck for the given scenario.
§
If
only one channel can be enhanced, coverage enhancement of 10.00 dB can be
achieved at maximum.
o In order to achieve 400m ISD, the following channel(s) needs to be enhanced:
§
PUSCH for eMBB with frame
structure DDDDDDDSUU: 5.13 dB
o In order to achieve 500m ISD, the following channel(s) needs to be enhanced:
§
PUSCH for eMBB with frame
structure DDDDDDDSUU: 8.92 dB
Agreements:
· Capture the following observation for Rural 4GHz TDD NLOS O2I scenario in the TR
o PUSCH for eMBB with frame structure DDDSU is the worst channel in terms of MIL, and can be the coverage bottleneck for the given scenario.
§
If
only one channel can be enhanced for frame structure DDDSU, coverage
enhancement of 4.23 dB can be achieved at maximum.
o In order to achieve 1732m ISD, the following channel(s) needs to be enhanced for BS with 33dBm/MHz transmit power:
§
PUSCH for eMBB with frame
structure DDDSU: 7.05 dB
§
PUSCH for eMBB with frame
structure DDDSUDDSUU: 5.39 dB
§
PUSCH for VoIP with frame
structure DDDSU: 1.89 dB
§
PUSCH for VoIP with frame
structure DDDSUDDSUU: 1.80 dB
§
PUCCH Format 1:
1.23 dB
§
PUCCH Format 3 with 11bit
payload: 2.53 dB
§
PUCCH Format 3 with 22bit
payload: 5.49 dB
§
PRACH Format 0: 2.24 dB
· However, due to the lack of the number of samples, the statistical correctness of this estimation has not been pursued in this study item.
§
PRACH Format B4: 5.72 dB
§
Broadcast PDCCH(PDCCH of
Msg.2) : 1.11 dB
· However, due to the lack of the number of samples, the statistical correctness of this estimation has not been pursued in this study item.
§
PUSCH of Msg.3: 1.90 dB
§
PUCCH w/ HARQ-ACK for Msg.4:
1.47 dB
· However, due to the lack of the number of samples, the statistical correctness of this estimation has not been pursued in this study item.
o Achievement of 3000m ISD is not easy because it requires enhancements for all the channels
§
Especially, PUSCH for eMBB
with frame structure DDDSU requires huge amount of enhancements of 16.27 dB
Agreements:
· Capture the following observation for Rural 2.6GHz TDD NLOS O2I scenario
o PUSCH for eMBB with frame structure DDDDDDDSUU is the worst channel in terms of MIL, and can be the coverage bottleneck for the given scenario.
§
If
only one channel can be enhanced, coverage enhancement of 5.44 dB can be
achieved at maximum.
o In order to achieve 1732m ISD, the following channel(s) needs to be enhanced:
§
PUSCH for eMBB with frame
structure DDDDDDDSUU: 3.86 dB
§
PUCCH format 3 with 11bit
payload: 0.50 dB
·
However
as shown by standard deviation in the table, this additional gain may be
achieved by the existing technologies or parameter optimization, which means
that a new functionality in Rel-17 is not always required.
§
PUCCH format 3 with 22bit
payload: 1.60 dB
· However, due to the lack of the number of samples, the statistical correctness of this estimation has not been pursued in this study item.
Agreements:
· Capture the following observation for Rural 2GHz FDD NLOS O2I scenario
o PRACH format B4 is the worst channel in terms of MIL, and can be the coverage bottleneck for the given scenario.
§ Since the number of samples to derive the representative value is 4, further analysis is advisable for more accurate MIL estimation on this channel as necessity. It has not been pursued in this study item.
§
If
only one channel can be enhanced, coverage enhancement of 2.85 dB can be
achieved at maximum.
o In order to achieve 1732m ISD, the following channel(s) needs to be enhanced:
§
PUSCH with SIP invite:
2.09dB
· However, due to the lack of the number of samples, the statistical correctness of this estimation has not been pursued in this study item.
§
PRACH format B4: 3.10dB
Agreements:
· Capture the following observation for Rural 700MHz FDD NLOS O2I scenario
o For the service based requirement for VoIP that is defined by 139.2dB MCL, the following channels can be bottlenecks for the given scenario.
§
PUSCH for VoIP: 5.01 dB
§
PUSCH with SIP invite:
4.20 dB
· However, due to the lack of the number of samples, the statistical correctness of this estimation has not been pursued in this study item.
§
PUSCH for CSI with 11bit
payload: 1.45 dB
· However, due to the lack of the number of samples, the statistical correctness of this estimation has not been pursued in this study item.
§
PUSCH for CSI with 22bit
payload: 2.95 dB
· However, due to the lack of the number of samples, the statistical correctness of this estimation has not been pursued in this study item.
§
PUCCH Format 1: 1.68
dB
§
PUCCH Format 3 with 11bit
payload: 3.35 dB
§
PRACH Format B4: 6.51 dB
· However, due to the lack of the number of samples, the statistical correctness of this estimation has not been pursued in this study item.
§
PUSCH of Msg.3 4.49
dB
o PUCCH format 3 with 22 bit payload is the worst channel in terms of MIL, and can be the coverage bottleneck for the given scenario.
§ As the table of representative values (in annex) shows, the gap between the worst and the 2nd worst channel (PUSCH for eMBB) is relatively small, i.e. in the range of standard deviation. Thus more analysis is necessary for the accurate bottleneck channel identification. However, it has not been pursued in this study item.
§
If
only one channel can be enhanced, coverage enhancement of 0.22 dB can be
achieved at maximum.
o In order to achieve 3000m ISD, the following channel(s) needs to be enhanced:
§
PUCCH Format 3 with 22 bit
payload: 2.28dB
§
PRACH format B4: 4.48dB
· However, due to the lack of the number of samples, the statistical correctness of this estimation has not been pursued in this study item.
§
PUCCH w/ HARQ-ACK for Msg.4:
4.43dB
· However, due to the lack of the number of samples, the statistical correctness of this estimation has not been pursued in this study item.
o In order to achieve 4000m ISD, the following channel(s) needs to be enhanced:
§
PUSCH for eMBB: 3.05 dB
§
PUSCH for VoIP: 1.22 dB
§
PUCCH Format 1: 1.01 dB
§
PUCCH Format 3 with 11bit
payload: 2.58 dB
§
PUCCH Format 3 with 22bit
payload: 7.11 dB
§
PRACH Format B4: 9.31 dB
· However, due to the lack of the number of samples, the statistical correctness of this estimation has not been pursued in this study item.
§
PUSCH of Msg.3: 0.60 dB
· However as shown by standard deviation in the table, this additional gain may be achieved by the existing technologies or parameter optimization, which means that a new functionality in Rel-17 is not always required.
§
PUCCH w/ HARQ-ACK for Msg.4:
9.26 dB
· However, due to the lack of the number of samples, the statistical correctness of this estimation has not been pursued in this study item.
Agreements:
· Capture the following observation for Rural 4GHz with long distance TDD LOS O2O scenario in the TR
o PUSCH for eMBB with frame structure DDDSU is the worst channel in terms of MIL. However, due to the lack of the number of samples for each channel, the statistical analysis by relative difference between channels could not be performed.
o In order to achieve 12km ISD, at least the following channel(s) needs to be enhanced:
§
PUSCH for eMBB with frame
structure DDDSU: 3.15 dB
§
PUSCH for eMBB with frame
structure DDDSUDDSUU: 2.42 dB
§ This does not mean that other channels do not require any enhancements. RAN1 did not perform any analysis for this point because of the lack of the number of samples for each channel for this scenario.
Agreements:
· Capture the following observation in the TR
o One source (ZTE, R1-2007741) evaluated the target performance, i.e. the 5th percentile geometry SINR value, based on system-level simulation. Compared to the baseline performance, i.e., required SNR based on link level simulation, the following is observed for FR1.
§
In Urban 4 GHz O2I scenario with ISD 500m, PUSCH eMBB, PUSCH VoIP, Msg3, PRACH
B4, PUCCH Format
1 with 2
bits, PUCCH Format
3 with 11
bits, and PUCCH Format 3 with 22 bits, requires coverage compensation, and the compensation gap is
14.65 dB, 3.86 dB, 2.1 dB, 5.2 dB, 4.26 dB, 4.29 dB and 4.64 dB respectively.
§
In Rural 4 GHz O2I scenario with ISD 1732m, PUSCH eMBB, Msg3, PRACH B4, PUCCH Format 1 with 2 bits, PUCCH Format 3 with 11 bits, and PUCCH Format 3 with 22 bits, requires coverage compensation, and the compensation gap is
5.89 dB, 3.08 dB, 4.14 dB, 4.19 dB, 4.31 dB and 4.56 dB respectively.
§
In Rural 2.6 GHz O2I scenario with ISD 1732m, PUSCH eMBB, Msg3, PRACH B4,
PUCCH Format 1
with 2
bits, PUCCH Format
3 with 11
bits and PUCCH Format 3 with 22 bits, requires coverage compensation, and the compensation gap is
5.11 dB, 3.35 dB, 4.11 dB, 4.3 dB, 4.28 dB and 4.56 dB respectively.
§ In Rural 700MHz O2O scenario with ISD 1732m, no channel requires coverage compensation.
§ In Rural with long distance 700MHz O2O scenario with ISD 12km, no channel requires coverage compensation.
Agreements:
· Regarding the working assumption on the result of bottleneck identification by using absolute metrics, the working assumption is confirmed by applying the following table.
R1-2007582 Evaluation on the baseline performance for FR2 Huawei, HiSilicon
R1-2007679 Evaluation on NR coverage performance for FR2 vivo
R1-2007742 Discussion on baseline coverage performance for FR2 ZTE
R1-2007873 Baseline coverage performance for FR2 CATT
R1-2007953 On baseline coverage performance for FR2 Intel Corporation
R1-2008025 Discussion on the baseline performance in FR2 CMCC
R1-2008090 Evaluation on NR coverage performance for FR2 Xiaomi
R1-2008180 Baseline coverage performance using LLS for FR2 Samsung
R1-2008270 Evaluation on NR coverage performance for FR2 OPPO
R1-2008344 Link and System Evaluation of Coverage for FR2 Ericsson LM
R1-2009170 FR2 baseline coverage performance using LLS InterDigital, Inc. (rev of R1-2008482)
R1-2008558 Baseline coverage performance for FR2 NTT DOCOMO, INC.
R1-2008625 Baseline FR2 coverage performance Qualcomm Incorporated
R1-2008702 Baseline coverage evaluation of UL and DL channels – FR2 Nokia, Nokia Shanghai Bell
R1-2009342 Summary of A.I. 8.8.1.2 - Baseline coverage performance using LLS for FR2 Moderator (Nokia)
Decision: Noted. From GTW on 10/26:
[103-e-NR-CovEnh-03] – Marco (Nokia)
Email discussion for FR2 coverage performance
Decision: From GTW on 10/29:
Conclusion:
Agreements:
The amount of available results for UL channels in FR2 should be considered as given by the total number of available results for both 23 dBm and 12 dBm, given that they can be derived one from the other by simple subtraction, and where each company is counted only once.
Agreements:
· For FR2, representative values are computed according to agreements made for FR1 related on representative value calculation method;
· For FR2, classification of scenarios/channels/frame structures into 1st priority and 2nd priority as follows:
o 1st priority has enough available results, i.e., larger than 2;
o 2nd priority has less than 3 available results.
· No categorization by other simulation parameters (such as UE speed, antenna array gain correction factors, UE Tx power) will be introduced for FR2.
· At least for FR2
o RAN1 discussion will focus on 1st priority scenarios/channels/frame structures for drawing observations and bottleneck identification.
o RAN1 discussion will focus on 2nd priority scenarios/channels/frame structures on a low priority basis, i.e., after discussion on 1st priority scenarios/channels/frame structures.
o If results presented for 2nd priority scenarios/channels/frame structures are used by RAN1 for neither representative value derivation nor coverage bottleneck identification, they
§ will still be captured in the Appendix of the TR for completeness;
§ can be used to make additional observations to be captured in the TR.
§ cannot be used to draw conclusions to be captured in the TR.
R1-2009797 Summary on AI 8.8.1.2 baseline coverage performance using LLS for FR2 Nokia, Nokia Shanghai Bell
Agreements:
If absolute ISD/MPL targets are agreed to be used for coverage bottleneck identification then the following targets are considered for FR2:
· Dense Urban: ISD = 200m; MPL = [123.1] dB;
· Indoor: ISD = [20]m; MPL = [94.03] dB
FFS: If MIL targets are also considered for control and data channels.
Agreements:
Scenarios, with corresponding frame structures, are classified as follows:
· 1st priority
o Urban 28 GHz O2I, DDDSU
o Urban 28 GHz, O2O DDDSU
o Urban 28 GHz, O2I, DDSU [Only PUSCH VoIP, PUSCH and PDSCH]
o Indoor 28 GHz, DDDSU
· 2nd priority
o Indoor 28 GHz, DDSU
o Urban 28 GHz, O2I, DDSU [only PDSCH of msg2]
o Urban 28 GHz, O2O DDSU
o Suburban 28 GHz, O2I DDDSU
o Suburban 28 GHz, O2O DDSU
Channels are classified as follows:
· 1st priority
o PUSCH for eMBB (12 dBm and 23 dBm) [DDDSU and DDSU]
o PUSCH for VoIP (12 dBm and 23 dBm) [DDDSU and DDSU (Only for Urban)]
o PUCCH Format 1 with 2bits (12 dBm and 23 dBm) [DDDSU]
o PUCCH Format 3 with 11bits (12 dBm and 23 dBm) [DDDSU]
o PUCCH Format 3 with 22bits (12 dBm and 23 dBm) [DDDSU]
o SSB [DDDSU]
o PRACH format B4 (12 dBm and 23 dBm) [DDDSU]
o PDCCH for Msg.2 [DDDSU]
o PUSCH for Msg.3 (12 dBm and 23 dBm) [DDDSU]
o PDSCH for Msg.4 [DDDSU]
o PDCCH [DDDSU]
o PDSCH for eMBB [DDDSU and DDSU (Only for Urban)]
· 2nd priority
o PUSCH for CSI with 11 bits (12 dBm and 23 dBm)
o PUSCH for CSI with 22 bits (12 dBm and 23 dBm)
o PUCCH with 3-HARQ-ACK bits + SR (12 dBm and 23 dBm)
o PUCCH with HARQ-ACK for Msg.4 (12 dBm and 23 dBm)
o PRACH format C2 (12 dBm and 23 dBm)
o PDSCH of Msg.2
o PUCCH Format 0 (12 dBm and 23 dBm)
o PUCCH Format 2 (12 dBm and 23 dBm)
Agreements:
If absolute ISD/MPL targets are agreed to be used for coverage bottleneck identification then the following targets are considered for FR2:
· Dense Urban: ISD = 200m; MPL = 123.1 dB;
· Indoor: ISD = 20m; MPL = 94.03 dB;
Where MPL values are calculated from ISD targets using the following equations (add reference when capturing into the TR)
FFS d3D with respect to ISD
FFS: If absolute MIL targets are also considered for coverage bottleneck identification including possible different targets for data and control channels.
Decision: As per email decision posted on Nov.11th,
Agreement:
For target MPL calculation associated to
agreed ISD targets, 
is equal to the target range calculated by ISD/
.
Agreement:
PUSCH for SIP invite is added to the list of 2nd priority channels for FR2.
Agreements:
Performance targets for FR2 are calculated, for all scenarios, as follows:
· [Absolute] ISD targets are used to find corresponding absolute target MPL values;
· [Relative] Relative differential MIL value of a target channel is calculated considering PUCCH F1 as reference channel, as follows:
o (MIL of the target channel) – (MIL of PUCCH F1)
Coverage bottleneck identification for FR2 is performed using at least absolute MPL and relative differential MIL targets, as follows:
· Absolute MPL targets are used to filter the channels/signals, i.e., the candidate bottleneck channels.
· Filtered channels/signals whose relative differential MIL value is negative are considered as a potential coverage bottleneck.
The necessary link budget increase for each bottleneck channel/signal, expressed in the form of MPL increase (in dB), that enhancements for that channel/signal that is to be targeted, are obtained by changing the sign of the relative differential MIL value of the channel/signal.
Other options to draw additional observations from collected results are not precluded.
Agreements:
· The following channels are identified as the potential bottleneck channels for 28 GHz scenario
o PUSCH eMBB (DDDSU and DDSU)
o PUSCH VoIP (DDDSU and DDSU)
o PUCCH F3 11bits
o PUCCH F3 22bits
o PRACH B4
o PUSCH of Msg3
o
PUCCH
F1
· No evident coverage bottleneck is identified for Indoor scenario for FR2
Agreements:
· PRACH B4 is reference to assess how many additional dBs over the baseline PRACH enhancements may target.
· PUCCH F3 with either 11 bits or 22 bits or both is reference to assess how many additional dBs over the baseline PUCCH F3 enhancements may target
Agreement:
· For FR2, coverage bottleneck identification and discussion on enhancements will not include aspects related to the deprioritized Suburban scenario.
R1-2009719 [103-e-NR-CovEnh-EvaluationResults]: Summary of simulation results for enhancements Moderator (China Telecom)
Decision: The document is noted as summary of email discussion on the collection of simulation results for enhancements.
R1-2007905 PUSCH coverage enhancements Indian Institute of Tech (H)
· Study enhanced TBS calculations to increase the MCL for Rel-17 by supporting transmissions over multiple UL slots.
· Make pi/2 BPSK power boosting a function of the UL duty cycle.
· Send LS to RAN4 to study the feasibility of power boosting for pi/2 BPSK modulation beyond 26 dBm as a function of the UL duty cycle.
Decision: The document is noted.
R1-2007583 Potential solutions for PUSCH coverage enhancement Huawei, HiSilicon
R1-2007640 PUSCH coverage enhancement Beijing Xiaomi Mobile Software
R1-2007680 Discussion on Solutions for PUSCH coverage enhancement vivo
R1-2007743 Discussion on potential techniques for PUSCH coverage enhancements ZTE
R1-2007874 Discussion on potential techniques for PUSCH coverage enhancement CATT
R1-2007930 Potential techniques for NR coverage enhancements Sierra Wireless, S.A.
R1-2007954 On potential techniques for PUSCH coverage enhancement Intel Corporation
R1-2007989 PUSCH coverage enhancement ETRI
R1-2008874 Discussion on PUSCH coverage enhancements China Telecom (rev of R1-2007994)
R1-2008026 Discussion on the PUSCH coverage enhancement CMCC
R1-2008078 Discussion on PUSCH coverage enhancement NEC
R1-2008092 Potential solutions for PUSCH coverage enhancement Spreadtrum Communications
R1-2009647 PUSCH coverage enhancement Samsung (rev of R1-2008895, rev of R1-2008181)
R1-2008271 Consideration on PUSCH coverage enhancement OPPO
R1-2008370 On PUSCH coverage enhancement techniques Sony
R1-2008378 Discussion on PUSCH coverage enhancements Panasonic Corporation
R1-2008399 PUSCH coverage enhancement Sharp
R1-2008403 Discussions on PUSCH coverage enhancement LG Electronics
R1-2008419 PUSCH coverage enhancement Ericsson
R1-2008479 On potential techniques for PUSCH coverage enhancement Apple
R1-2009583 PUSCH coverage enhancements InterDigital, Inc. (rev of R1-2009168, rev of R1-2008483)
R1-2008559 Potential techniques for PUSCH coverage enhancements NTT DOCOMO, INC.
R1-2009729 Potential coverage enhancement techniques for PUSCH Qualcomm Incorporated (rev of R1-2008626)
R1-2008700 On the use of Tx diversity in DFT-s-OFDM for PUSCH coverage enhancement NICT
R1-2009792 Discussion on approaches and solutions for NR PUSCH coverage enhancement Nokia, Nokia Shanghai Bell (rev of R1-2008703)
R1-2008729 Discussion on potential techniques for PUSCH coverage enhancement WILUS Inc.
R1-2008743 On transmit diversity techniques for PUSCH coverage enhancement Mitsubishi Electric RCE
R1-2009320 FL summary of PUSCH coverage enhancements Moderator (China Telecom)
Decision: Noted. From GTW on 10/26:
[103-e-NR-CovEnh-04] – Jianchi (China Telecom)
Email discussion for PUSCH coverage enhancement
Decision: From GTW on 10/29:
Agreements:
For the agreement made in RAN1 #102-e:
|
Agreements: • Study following power domain based solution for PUSCH enhancements ‐ Waveform design to optimize MPR/A-MPR ‐ [FDD high power UE] ‐ Power boosting for pi/2 BPSK Note: if a LS to RAN4 (for the last two bullets) is deemed necessary, target sending the LS in the 1st week of RAN1#103-e. |
RAN1 targets to make a decision whether to further study on power boosting for pi/2 BPSK during this e-meeting.
Agreements: Capture the followings into the TR
Agreements: Capture the followings into the TR
Agreements: Capture the followings into the TR
Agreements: Capture the followings into the TR
R1-2009814 [103-e-NR-CovEnh-04] Summary of email discussion on PUSCH coverage enhancements Moderator (China Telecom)
Agreements: Capture the followings into the TR
· Enhancements on PUSCH repetition type A were studied from several aspects, including increasing the maximum number of repetitions, the number of repetitions counted on the basis of available UL slots and flexible symbol resource allocation in different slots.
· Potential specification impacts of enhancements on increasing the maximum number of repetitions include:
o TDRA (Time-Domain Resource Allocation).
· Potential specification impacts of enhancements on the number of repetitions counted on the basis of available UL slots include:
o TDRA (Time-Domain Resource Allocation).
o Mechanism to determine transmission occasion of actual repetition.
o
Mechanism to determine
whether flexible special slot can be determined as an available UL slot.
· Potential specification impacts of enhancements on flexible symbol resource allocation in different slots include:
o TDRA (Time-Domain Resource Allocation).
o Mechanism to determine UL symbols for each slot.
Agreements: Capture the followings into the TR
· TB processing over multi-slot PUSCH was studied from several aspects, including TBS determined based on single slot and transmitted in parts over multiple slots, TBS determined based on multiple slots and transmitted over multiple slots.
· Potential specification impacts of TB processing over multi-slot PUSCH include:
o TDRA (Time-Domain Resource Allocation), TBS determination, RV determination.
o Note that power consistency, phase continuity and enhancements for DM-RS configurations may or may not be required depending on factors such as cross-slot channel estimation, etc.
Agreements: Capture the followings into the TR
· Joint channel estimation or DM-RS bundling with/without optimization of DMRS location/granularity was studied from several aspects, including cross-slot channel estimation over consecutive slots, cross-slot channel estimation over non-consecutive slots, cross-repetition channel estimation within one slot, and inter-slot frequency hopping with inter-slot bundling to enable cross-slot channel estimation.
· Potential specification impacts of joint channel estimation or DM-RS bundling include:
o Power consistency and phase continuity, DM-RS placement in special slot and DM-RS configuration.
o Time domain hopping interval for inter-slot frequency hopping with inter-slot bundling
Agreements: Capture the followings into the TR
· Power boosting for pi/2 BPSK was studied, including beyond 26 dBm as a function of the UL duty cycle.
· Potential specification impacts include
o UE behavior for power boosting based on the UL time domain resource allocation, explicit or implicit signaling, RF requirement.
Agreements: Capture the followings into the TR
· SIP signal compression was studied for enhancement large payload PUSCH including SigComp used for application information compression and the compression efficiency.
· Potential specification impacts include
o Using compression algorithm to compress the large SIP signaling message in higher layer.
Agreements: Capture the followings into the TR
· Dynamic PUSCH waveform adaptation was studied. Potential specification impacts include:
o Related signaling design.
Agreements: Capture the followings into the TR
· Enhancements on PUSCH repetition type B were studied from several aspects, including actual PUSCH transmission across the slot boundary/invalid symbols, the length of actual repetition larger than 14 symbols, and RV enhancement.
· Potential specification impacts of enhancements on PUSCH repetition type B include:
o TBS determination, DM-RS pattern, TDRA (Time-Domain Resource Allocation), RV determination,
o Note that power consistency and phase continuity may or may not be required depending on factors such as cross-slot channel estimation, etc.
Agreements:
· Sub-PRB transmission for VoIP was studied from several aspects, including number of tones, sub-PRB transmission with single slot and sub-PRB transmission with multi-slot aggregation.
· Potential specification impacts of sub-PRB transmission with single slot include:
o Frequency domain resource allocation, TBS determination, DM-RS pattern, hopping pattern within/between the PRBs, PUSCH signal generation for DFT-s-OFDM waveform, RF requirement.
· Potential specification impacts of sub-PRB transmission with multi-slot aggregation include:
o Frequency domain resource allocation, time domain resource allocation, TBS determination, DM-RS pattern, RV determination, hopping pattern within/between the PRBs, PUSCH signal generation for DFT-s-OFDM waveform, RF requirement.
Agreements: Capture the followings into the TR
· Enhancements on intra-slot frequency hopping were studied from several aspects, including:
o More frequency offsets, e.g. 4 for BWP less than 50 PRBs, 8 for BWP greater than 50 PRBs.
o More frequency hopping positions, e.g. 3.
o More time-domain hop positions within a slot, e.g. 3.
o DM-RS sharing among multiple PUSCH transmissions with the same frequency position between two consecutive slots [add a reference to the section of DM-RS enhancements when capturing in the TR].
· Potential specification impacts of enhancements on intra-slot frequency hopping include:
o Frequency domain hopping offsets, DM-RS pattern, TBS determination.
o Power consistency and phase continuity for DM-RS sharing among multiple PUSCH transmissions
Agreements: Capture the followings into the TR
· UE transmit waveform design to reduce MPR was studied from several aspects, including tone reservation, FDSS (Frequency Domain Spectral Shaping) without spectral extension for pi/2 BPSK, and FDSS with and without spectral extension for QPSK.
· Potential specification impacts include
o Related signalling, design for spectral extension, RF requirements.
Note: For tone reservation, a fraction of tones allocated to a UE are reserved for the UE to shape its waveform; no data is transmitted on these tones.
Agreements: Capture the followings into the TR
· Spatial domain based solutions were studies from several aspects, including multiple layer PUSCH transmission with DFT-S-OFDM and Open-loop Tx diversity.
· Potential specification impacts include
· Mechanism to indicate the support of multiple layer PUSCH transmission with DFT-S-OFDM and to determine the precoder, e.g. reuse a subset of the R15 codebooks.
· Signalling related to support of Tx diversity for PUSCH with DFT-s-OFDM, and different PUSCH spatial filter parameters and different antenna ports for different PUSCH transmissions
Agreements:
Capture the following observation into the TR.
Observations:
· Fifteen sources ([China Telecom, R1-2008874], [ZTE, R1-2007743], [Intel, R1-2007954], [Qualcomm, R1-2008626], [Sharp, R1-2008399], [Panasonic, R1-2008378], [DOCOMO, R1-2008559], [Samsung, R1-2009647], [CMCC, R1-2008026], [vivo, R1-2007680], [Ericsson, R1-2008419], [Nokia, R1-2008703], [Apple, R1-2008479], [InterDigital, R1-2009168], [Huawei, R1-2007583]) evaluate the performance of joint channel estimation.
o Eleven sources ([China Telecom, R1-2008874], [ZTE, R1-2007743], [Qualcomm, R1-2008626], [Sharp, R1-2008399], [Panasonic, R1-2008378], [CMCC, R1-2008026], [vivo, R1-2007680], [Ericsson, R1-2008419], [Nokia, R1-2008703], [Apple, R1-2008479], [Huawei, R1-2007583]) show 0.2~2.1 dB SNR gain for joint channel estimation over multiple slots for eMBB at 10% iBLER depending on the number of slots for FR1, compared to Rel-16 PUSCH transmission without joint channel estimation.
o One source ([Intel, R1-2007954]) shows 2 dB SNR gain for joint channel estimation over multiple non-consecutive slots with inter-slot frequency hopping for eMBB at 10% iBLER, compared to Rel-16 inter-slot frequency hopping without joint channel estimation.
o Three sources ([Samsung, R1-2009647], [NTT DOCOMO, R1-2008559]) show 0.9~1.3 dB SNR gain for joint channel estimation over multiple slots for VoIP at 2% rBLER depending on the number of slots for FR1, compared to Rel-16 PUSCH transmission without joint channel estimation.
o One source ([InterDigital, R1-2009168]) shows 0.3 dB SNR gain for joint channel estimation over multiple slots with DMRS in a special slot for VoIP at 2% rBLER, compared to Rel-16 PUSCH transmission without joint channel estimation.
o One source shows ([Samsung, R1-2009647]) 0.85~1.1 dB SNR gain for joint channel estimation over multiple slots for VoIP at 2% rBLER depending on the number of slots for FR2, compared to Rel-16 PUSCH transmission without joint channel estimation.
o One source ([vivo, R1-2007680]) shows 0.8 dB SNR gain for joint channel estimation over multiple repetition within a slot, compared to Rel-16 PUSCH transmission without joint channel estimation.
o Two sources ([CMCC, R1-2008026], [vivo, R1-2007680]) show 1.0~1.22 dB required SNR gain for lower DM-RS density in time domain with joint channel estimation and using multi-slot PUSCH with 4 symbols in the special slot over multiple slots for eMBB at 10% iBLER for FR1, compared to Rel-16 DM-RS density without joint channel estimation.
o One source ([vivo, R1-2007680]) shows 1.0 dB required SNR gain for lower DM-RS density in time domain with joint channel estimation over multiple repetition within a slot for eMBB at 10% iBLER for FR1, compared to Rel-16 PUSCH transmission without joint channel estimation.
· Five sources ([China Telecom, R1-2008874], [ZTE, R1-2007743], [Intel, R1-2007954], [Samsung, R1-2009647], [Ericsson, R1-2008419]) evaluate the performance of inter-slot frequency hopping with inter-slot bundling and joint channel estimation.
o Two sources ([China Telecom, R1-2008874], [Samsung, R1-2009647]) show 0.5~2.5 dB SNR gain for inter-slot frequency hopping with inter-slot bundling for VoIP at 2% rBLER depending on bundle size, DM-RS configurations for FR1, compared to Rel-16 inter-slot frequency hopping.
o One source ([Samsung, R1-2009647]) shows 1.0~1.55 dB SNR gain for inter-slot frequency hopping with inter-slot bundling for VoIP at 2% rBLER depending on bundle size, DM-RS configurations for FR2, compared to Rel-16 inter-slot frequency hopping.
o Three sources ([ZTE, R1-2007743], [Intel, R1-2007954], [Ericsson, R1-2008419]) show 0.5~3 dB SNR gain for inter-slot frequency hopping with inter-slot bundling for eMBB at 10% iBLER depending on bundle size for FR1, compared to Rel-16 inter-slot frequency hopping.
o One source ([Intel, R1-2007954]) shows 1 dB SNR gain for inter-slot frequency hopping with inter-slot bundling and joint channel estimation over multiple slot for eMBB at 10% iBLER for FR1, compared to Rel-16 inter-slot frequency hopping with joint channel estimation over multiple non-consecutive slots.
Agreements:
Capture the following observation into the TR.
Observations:
· Two sources ([ZTE, R1-2007743], [Intel, R1-2007954]) evaluate the performance of lower DM-RS density.
o One source ([ZTE, R1-2007743]) shows around 1.0 dB SNR gain for lower DM-RS density in frequency domain for eMBB at 10% iBLER for FR1, compared to Rel-16 DM-RS density. The results is based on the assumption with only 1 RX antenna, single front-loaded DMRS symbol and without frequency hopping.
o One source ([Intel, R1-2007954]) shows around 0.2 dB SNR loss for lower DM-RS density in time domain for eMBB at 10% iBLER for FR1, compared to Rel-16 DM-RS density.
Agreements:
Capture the following observation into the TR.
Observations:
· Three sources ([China Telecom, R1-2008874], [Intel, R1-2007954], [DOCOMO, R1-2008559]) evaluate the performance of higher DM-RS density.
o One source ([China Telecom, R1-2008874]) shows 0.5~1.5 dB SNR gain for 1-comb DM-RS for eMBB at 10% iBLER for FR1, compared to Rel-16 DM-RS density without power boosting.
o One source ([DOCOMO, R1-2008559]) shows around 1.0 dB SNR gain for additional DM-RS symbol position for VoIP at 2% rBLER for FR1, compared to Rel-16 DM-RS density with only single DMRS symbol.
o One source ([Intel, R1-2007954]) shows around 0.05 dB SNR loss for higher DM-RS density in time domain for eMBB 10% iBLER for FR1, compared to Rel-16 DM-RS density.
Agreements:
Capture the following observation into the TR.
Observations:
· One source ([Qualcomm, R1-2008626]) evaluates the performance of adaptive DM-RS configuration and shows 1.7 dB SNR gain for eMBB at 10% iBLER for FR1, compared to Rel-16 semi-static DM-RS configuration. For low SNR such as -10 to -12 dB, it shows that adaptive DM-RS configuration can bring 10-100% increase in throughput compared to an ill-suited DMRS configuration depending on factors such as UE speed, DMRS bundling, and PUSCH repetition.
· One source ([China Telecom, R1-2008874]) evaluates the performance of enhanced intra-slot frequency hopping with more frequency offsets/ more frequency hopping positions and shows around 1.8 dB SNR gain for VoIP at 2% rBLER and 0.4 dB SNR gain for eMBB at 2% rBLER for FR1, compared to Rel-16 intra-slot frequency hopping.
· One source (IITH, R1-2007905)) evaluates the performance of power boosting for pi/2 BPSK and shows around 3 dB gain for UL duty cycle less than 50% and around 6 dB gain for UL duty cycle less than 25%.
· One source ([Qualcomm, R1-2008626]) evaluates the performance of dynamic switching between DFT-S-OFDM and CP-OFDM and shows 2~3 dB gain, compared to semi-static switching between DFT-S-OFDM and CP-OFDM when using QPSK modulation.
· One source ([Qualcomm, R1-2008626]) evaluates the performance of UE transmit waveform design to reduce MPR and shows 1 ~1.5 dB gain, compared to Rel-16 DFT-S-OFDM and CP-OFDM.
· One source ([Panasonic, R1-2008378]) evaluates the performance of symbol level repetition and shows around 0.4 dB SNR gain for UE speed 3km/h and around 0.3dB SNR loss for UE speed 120km/h, respectively, for eMBB at 10% iBLER for FR1, compared to Rel-16 PUSCH repetition type A.
· One source ([Mitsubishi, R1-2008743]) evaluates the performance of Alamouti-based transmit diversity and shows 2-2.7dB SNR gain for FR1, and 2-3dB SNR gain with QPSK and up to 8.5dB SNR gain with 16QAM for FR2.
· One source ([Ericsson, R1-2008419]) evaluates the performance of multiple layer PUSCH transmission with DFT-S-OFDM and shows around 3 dB cubic metric gain, compared to multiple layer PUSCH transmission with CP-OFDM.
Agreements: Capture the following observation into the TR.
Observations:
· Five sources ([China Telecom, R1-2008874], [ZTE, R1-2007743], [vivo, R1-2007680], [InterDigital, R1-2009168], [Samsung, R1-2009647]) evaluate the performance of enhancements on PUSCH repetition type B.
o Three sources ([China Telecom, R1-2008874], [InterDigital, R1-2009168], [Samsung, R1-2009647]) show 0.2~2.0 dB SNR gain when the actual PUSCH transmission can cross the slot boundary, cross-slot channel estimation is used, and the length of actual repetition can be larger than 14 symbols for VoIP at 2% rBLER for FR1 TDD, compared to Rel-16 PUSCH repetition type B without joint channel estimation. HARQ is not used.
o One source ([ZTE, R1-2007743]) show 0.8 dB required SNR gain when the actual PUSCH transmission can across the slot boundary or the length of actual repetition can be larger than 14 symbols and cross-slot channel estimation is used for VoIP at 2% rBLER for FR1 TDD, compared to Rel-16 PUSCH repetition type B without joint channel estimation. HARQ is not used. Same TB size is used for both baseline and enhancement.
o One source ([Samsung, R1-2009647]) shows around 1.4 dB SNR gain when the actual PUSCH transmission can cross the slot boundary, cross-slot channel estimation is used, and the length of actual repetition can be larger than 14 symbols for VoIP at 2% rBLER for FR2 TDD, compared to Rel-16 PUSCH repetition type B without joint channel estimation.
o
One source ([InterDigital, R1-2009168]) shows 0.33~1.3 dB SNR gain when the actual
PUSCH transmission can cross the slot boundary, cross-slot channel estimation
is used, and the length of actual repetition can be larger than 14 symbols for eMBB at 10% iBLER for FR1 TDD, compared to Rel-16 PUSCH
repetition type B with 14-symbol actual repetition without
joint channel estimation. HARQ is not used.
o
One source ([InterDigital, R1-2009168]) shows the number of RBs can be reduced from 38 to 33, when the actual PUSCH transmission can cross the slot boundary, cross-slot
channel estimation is used, and the length of actual repetition can be larger
than 14 symbols for VoIP at 2% rBLER for FR1 TDD,
compared to Rel-16 PUSCH repetition type B with
14-symbol actual repetition without joint channel estimation.
HARQ is not used.
o
One source ([InterDigital, R1-2009168]) shows the number of RBs can be reduced from 30 to 26, when the actual PUSCH transmission can cross the slot boundary, cross-slot
channel estimation is used, and the length of actual repetition can be larger
than 14 symbols for eMBB at 10% iBLER for FR2 TDD,
compared to Rel-16 PUSCH repetition type B with
14-symbol actual repetition without joint channel estimation.
HARQ is not used.
o One source ([vivo, R1-2007680]) shows around 2.0 dB SNR gain for RV enhancement for eMBB at 10% iBLER for FR 1 TDD, compared to Rel-16 PUSCH repetition type B without joint channel estimation.
Agreements: Capture the following observation into the TR.
Observations:
· Six sources ([ZTE, R1-2007743], [Intel, R1-2007954], [Qualcomm, R1-2009729], [vivo, R1-2007680], [Ericsson, R1-2008419], [Huawei, R1-2007583]) evaluate the performance of inter-slot frequency hopping with more frequency offsets/ more frequency hopping positions.
o Five sources ([ZTE, R1-2007743], [Intel, R1-2007954], [vivo, R1-2007680], [Ericsson, R1-2008419], [Huawei,
R1-2007583]) show 0.3~1.7 dB SNR gain for inter-slot
frequency hopping with more frequency offsets/ more frequency hopping positions
for eMBB at 10% iBLER for FR1, compared to Rel-16 inter frequency hopping. Cross-slot channel estimation is not used, 2 RX is
assumed for gains higher than 0.3dB, [300ns] is assumed for gains
higher than 0.3dB.
o One source ([Qualcomm, R1-2009729]) shows no gain for inter-slot frequency hopping with more frequency offsets/ more frequency hopping positions for eMBB at 10% iBLER for FR1, compared to Rel-16 inter frequency hopping.
o One source ([Ericsson, R1-2008419]) shows no gain for inter-slot frequency hopping with more frequency offsets/ more frequency hopping positions and joint channel estimation over multiple slots is implemented for eMBB at 10% iBLER for FR1, compared to Rel-16 inter frequency hopping with joint channel estimation over multiple slots.
Agreements: Capture the following observation into the TR.
· Enhancements on PUSCH repetition type A is beneficial for PUSCH coverage enhancements for TDD. It is recommended to support enhancements on PUSCH repetition type A in Rel-17, including the following two options (potential down-selection during the WI phase):
o Option 1: Increasing the maximum number of repetitions, e.g., up to 32.
o Option 2: The number of repetitions counted on the basis of available UL slots.
Agreements: Capture the following observation into the TR.
TB processing over multi-slot PUSCH is beneficial for PUSCH coverage enhancements. It is recommended to support TB processing over multi-slot PUSCH in Rel-17, including:
· TBS determined based on multiple slots and transmitted over multiple integer slots.
Agreements: Capture the following observation into the TR.
Joint channel estimation is beneficial for PUSCH coverage enhancements. It is recommended to support Joint channel estimation or DM-RS bundling for PUSCH in Rel-17, including:
· Joint channel estimation over consecutive PUSCH transmissions
· Inter-slot frequency hopping with inter-slot bundling
Agreements: Capture the following observation into the TR.
Observations:
· Seven sources ([China Telecom, R1-2008874], [IITH, R1-2007905, [Intel, R1-2007954, [Qualcomm, R1-2008626], [InterDigital, R1-2009168], [Nokia, ?], [Sierra Wireless, R1-2007930]) evaluate the performance of TB processing over multi-slot PUSCH.
o
Two sources (China Telecom,
R1-2008874], [Qualcomm, R1-2008626]) show
0.6~2 dB SNR gain when TBS determined based on multiple slots and
transmitted over multiple slots for VoIP at 2% rBLER for FR1 and cross-slot channel estimation is used,
compared to TB is determined based on single slot with repetition in Rel-16 without cross-slot channel estimation. HARQ is not
used. [If HARQ is enabled, legacy transmissions incur
increased frequency domain resource use and a fair comparison cannot be made.]
Different redundancy version {0, 2, 3, 1} is
used for repetitions in [China Telecom, R1-2008874]. The same
redundancy version is used for repetitions in [Qualcomm, R1-2008626]. Gains due to reduction in upper-layer (MAC/RLC/PDCP) headers is
not reflected in [Qualcomm, R1-2008626].
o
Two sources ([China
Telecom, R1-2008874], [Qualcomm, R1-2008626]) show
1.0~2.7 dB SNR gain when TBS determined based on multiple slots and transmitted
over multiple slots for eMBB at 10% iBLER for FR1
and cross-slot channel estimation is used, compared to TB is
determined based on single slot with repetition in Rel-16 without cross-slot channel estimation. HARQ is
not used. [If HARQ is enabled, legacy transmissions
incur increased frequency domain resource use and a fair comparison cannot be
made.] Different redundancy version {0, 2, 3, 1}
is used for repetitions in [China Telecom, R1-2008874]. The same
redundancy version is used for repetitions in [Qualcomm, R1-2008626]. Gains due to reduction in upper-layer (MAC/RLC/PDCP) headers is
not reflected in [Qualcomm, R1-2008626].
o
Two One sources ([IITH, R1-2007905], [Nokia, ?]) shows
0.8~1.0 dB SNR gain when TBS determined
based on multiple slots and transmitted over multiple slots for eMBB at 10%
iBLER for FR1 and cross-slot channel estimation is
used, compared to TB is determined based on single slot with
repetition in Rel-16 without cross-slot channel
estimation. HARQ is not used. The same redundancy version is used
for repetitions.
o
Two One sources ([IITH, R1-2007905], [Nokia, ?]) show 0.8~1.0 dB SNR gain when TBS determined based on
multiple slots and transmitted over multiple slots for eMBB at 10% iBLER for
FR1 and cross-slot channel estimation is used, compared to TB is determined
based on single slot with repetition in Rel-16 without cross-slot channel
estimation. HARQ is not used. The same redundancy version is used for
repetitions.
o One source ([InterDigital, R1-2009168]) shows 0.4 and 2.0 dB SNR gain and with different number of aggregated slots and modulation schemes when TBS determined based on multiple slots and transmitted over multiple slots for VoIP at 2% rBLER for FR1 FDD and cross-slot channel estimation is used, compared to TB is determined based on single slot without repetition in Rel-16. HARQ is not used. Up to 10dB power boosting gain can be obtained depending on different number of aggregated slots when TBS determined based on multiple slots and transmitted over multiple slots for FR1 FDD VoIP.
o One source ([InterDigital, R1-2009168]) shows 0~1.75 dB SNR gain when TBS determined based on multiple slots and transmitted over multiple slots for eMBB at 10% iBLER for FR1 and cross-slot channel estimation is used, compared to TB is determined based on single slot without repetition in Rel-16. HARQ is not used. Up to 6.98 dB power boosting gain can be obtained depending on the number of aggregated slots when TBS determined based on multiple slots and transmitted over multiple slots for FR1 eMBB.
o
One source ([Intel, R1-2007954]) shows 0.2 dB SNR gain and 6.2 dB link budget gain when TBS
determined based on multiple slots and transmitted over multiple slots for VoIP
at 2% rBLER for FR1 TDD and cross-slot channel
estimation is used, compared to TB is determined based on single
slot without repetition in Rel-16. HARQ is not used.
o
One source ([Sierra
Wireless, R1-2007930]) shows 2 (w/ frequency hopping) and 2.5 dB (w/o frequency hopping)
SNR gain for when
codewords TBS determined
based on multiple slots and transmitted over multiple slots with gaps for eMBB
at 10% iBLER for FR1 and cross-slot channel
estimation is used, compared to Rel-16 where multiple TBs with repeats are scheduled over
contiguous slots without cross-slot channel
estimation. HARQ is not used. Perfect
channel estimation is assumed.
Agreements: Capture the following observation into the TR.
Observations:
· Four sources ([China Telecom, R1-2008874], [Samsung, R1-2009647], [vivo, R1-2007680], [Sierra Wireless, R1-2007930]) evaluate the performance of sub-PRB transmission with multi-slot aggregation.
o
One source ([China Telecom,
R1-2008874]) shows around 0.8 dB link budget gain for sub-PRB transmission
with multi-slot aggregation (6 tones) for VoIP at 2% rBLER for FR1 when cross-slot channel estimation is used,
compared to Rel-16 PRB-based transmission with repetition without cross-slot channel estimation. HARQ is not
used. Different redundancy version {0, 2, 3, 1} is used
for Rel-16 PRB-based transmission with repetition.
o One source ([Samsung, R1-2009647]) shows around 5.6 dB link budget gain for sub-PRB transmission with multi-slot aggregation (6 tones) for VoIP at 2% rBLER for FR1, compared to Rel-16 PRB-based transmission with 4 PRBs without repetition. HARQ is not used.
o One source ([Samsung, R1-2009647]) shows around 1.6 and 8.5 dB link budget gain for sub-PRB transmission with multi-slot aggregation (6 tones) for eMBB at 10% iBELR for FR1, respectively, depending on the number of aggregation slots, compared to Rel-16 PRB-based transmission with 1 PRB and 4 PRBs, respectively without repetition. HARQ is not used.
o
One source ([Sierra
Wireless, R1-2007930]) evaluatesd
the performance of sub-PRB transmission with 2 tones which to
reduce MPR and showsed 5 7 dB PAPR
reduction. This PAPR reduction allows for MPR
relaxation for VoIP use case at 2% rBLER
for FR1, compared to Rel-16 PRB-based transmission with CP-OFDM DFT-s-OFDM.
o One source ([vivo, R1-2007680]) shows no gain for sub-PRB transmission with multi-slot aggregation (6 tones) for VoIP at 2% rBLER for FR1, compared to Rel-16 PRB-based transmission with repetition. HARQ is not used.
Agreements:
Observations:
· Seven sources ([China Telecom, R1-2008874], [ZTE, R1-2007743], [Intel, R1-2007954], [DOCOMO, R1-2008557], [Sierra Wireless, R1-2007930], [Apple, R1-2008479], [Huawei, R1-2007583]) evaluate the performance of enhancements on PUSCH repetition type A.
o One source ([China Telecom, R1-2008874]) shows 3.2 dB (O2I) and 4 dB (O2O) SNR gain when the actual number of repetition is increased from 3 to 8 (counted on the basis of available UL slots) for VoIP at 2% rBLER for FR1 TDD, compared to Rel-16 PUSCH repetition type A with 8 nominal repetitions. HARQ is not used.
o One source ([ZTE, R1-2007743]) shows 1.0~1.5 dB SNR gain for PUSCH transmission with 4 repetitions and maximum 1 re-transmissions (maximum 8 actual transmissions in total, redundancy version {0, 2, 3, 1}) for VoIP at 2% rBLER for FR1 TDD 4GHz with ‘DDDSUDDSUU’ configured by 16 repetitions, compared to PUSCH transmission with 2 repetitions and maximum 3 re-transmissions (maximum 8 actual transmissions in total, redundancy version {0, 2}).
o One source ([DOCOMO, R1-2008557]) shows 6.8 dB SNR gain, when the actual number of repetition is increased for VoIP at 2% rBLER for FR1 TDD, compared to Rel-16 PUSCH repetition type A. HARQ is not used.
o
One source ([DOCOMO,
R1-2008557]) shows 6.4 dB SNR gain, when the actual number of repetition is
increased for eMBB 1Mbps at 10% iBLER for FR1
TDD, compared to Rel-16 PUSCH repetition type A. HARQ is not used.
o One source ([Intel, R1-2007954]) shows 2.0 dB SNR gain, when the actual number
of repetition is doubled for eMBB with the TBS
fixed
at of 136 bits at 10%
iBLER for FR1 FDD, compared to Rel-16 PUSCH repetition type A with 8
repetitions. HARQ is not used. Note: the observed gain was for data rates less
than the required 100kbps for the eMBB use case.
o
One source ([Apple, R1-2008479]) shows 2.2
dB SNR gain when the maximum number of
repetitions is increased to 16 for eMBB at 10% iBLER
for FR1 FDD, compared to Rel-16 PUSCH repetition type A with 8 repetitions.
HARQ is not used.
o
One source ([Apple, R1-2008479]) shows 0.8 dB SNR gain with the
repetition and the frequency hopping is enabled for
eMBB at 10% iBLER for FR1 FDD. The TBS is
changed to keep the target data rate 100kpbs for with or without repetition. It also shows 2.2dB SNR gain when the maximum
number of repetitions is increased to 16 for eMBB with TBS 120bits at 10% iBLER
for FR1 FDD, compared to Rel-16 PUSCH repetition type A with 8 repetitions.
HARQ is not used.
o One source ([Huawei, R1-2007583]) shows about 2.0 dB SNR gain when the actual number of repetition is doubled, e.g. from 2 to 4, from 4 to 8, for eMBB at 10% iBLER for FR1 TDD. HARQ is not used. Note: the observed gain was for different data rates where the data rate was sometimes less than the required 100kbps for the eMBB use case.
o One source ([Huawei, R1-2007583]) shows about 8.1dB SNR gain for PUSCH transmission with 3 retransmissions combined with 4 actual repetitions for VoIP at 2% rBLER for FR1 TDD, compared to PUSCH transmission with no repetition and no retransmission.
o
One source ([Sierra Wireless, R1-2007930]) shows when the TBS is adjusted to maintain
the target data rate of 100kbps, +0.4, +0.2, -1.6
dB SNR gain loss was
observed when the maximum number of repetitions was increased to 4, 8,
16 respectively for eMBB at 10% iBLER for FR1
FDD using Rel-16 PUSCH repetition type A.
Conclusion:
RAN plenary to decide whether to support power boosting for pi/2 BPSK for PUSCH for PC2 UEs.
Proposal:
Support sub-PRB transmission with multi-slot aggregation for PUSCH targeting VoIP services in Rel-17.
· Supported by: China Telecom, Sony, LG Electronics, NTT DOCOMO, Sierra Wireless, Samsung, Qualcomm, IITH, IITM, CEWIT, Reliance Jio, Tejas Networks, Nokia, Nokia Shanghai Bell
· Not supported by: Ericsson, vivo
R1-2009747 Potential solutions for PUCCH coverage enhancement Huawei, HiSilicon (rev of R1-2007584)
R1-2009648 Discussion on Solutions for PUCCH coverage enhancement vivo (rev of R1-2008942, rev of R1-2007681)
R1-2009696 Discussion on potential techniques for PUCCH coverage enhancements ZTE (rev of R1-2007744)
R1-2007875 Discussion on potential techniques for PUCCH coverage enhancement CATT
R1-2009602 On potential techniques for PUCCH coverage enhancement Intel Corporation (rev of R1-2007955)
R1-2007995 Discussion on PUCCH coverage enhancements China Telecom
R1-2008027 Discussion on PUCCH coverage enhancement CMCC
R1-2008079 Discussion on PUCCH coverage enhancement NEC
R1-2008182 PUCCH coverage enhancement Samsung
R1-2008272 PUCCH coverage enhancement schemes OPPO
R1-2008379 Discussion on PUCCH coverage enhancements Panasonic Corporation
R1-2008400 PUCCH coverage enhancement Sharp
R1-2008404 Discussions on PUCCH coverage enhancement LG Electronics
R1-2009737 PUCCH DTX detection performance Ericsson (rev of R1-2008420)
R1-2008484 PUCCH coverage enhancements InterDigital, Inc.
R1-2008560 Potential techniques for PUCCH coverage enhancements NTT DOCOMO, INC.
R1-2009802 Potential coverage enhancement techniques for PUCCH Qualcomm Incorporated (rev of R1-2009711, rev of R1-2009552, rev of R1-2009360, rev of R1-2009315, rev of R1-2008627)
R1-2008704 Discussion on approaches and solutions for NR PUCCH coverage enhancement Nokia, Nokia Shanghai Bell
R1-2008730 Discussion on potential techniques for PUCCH coverage enhancement WILUS Inc.
R1-2008756 PUCCH coverage enhancements Indian Institute of Tech (H)
R1-2009451 Low-PAPR Sequence-Based Approaches for PUCCH Coverage Enhancement EURECOM (rev of R1-2008938, rev of R1-2008759)
R1-2009321 FL summary of PUCCH coverage enhancement Moderator (Qualcomm)
Decision: Noted. From GTW on 10/26:
[103-e-NR-CovEnh-05] – Yi (Qualcomm)
Email discussion for PUCCH coverage enhancement
Agreements:
(Working assumption): For coverage enhancement study for PUCCH with >2 bits UCI, in addition to the 1% BLER performance metric agreed in RAN1 101e, the following performance metric can be considered:
· For UCI with HARQ-ACK payload (with or without CSI/SR payload), the performance metric for HARQ-ACK is 1% DTX to ACK error rate, 1% ACK miss detection (including ACK to NACK and ACK to DTX) error rate, and 0.1% NACK to ACK error rate.
o The payload size is 3 and 11 bits for HARQ-ACK. Other payload sizes can be evaluated and if so, reported by each individual company
· For UCI with HARQ-ACK and CSI/SR payload, the performance metric for CSI/SR is 1% false alarm rate, 1% BLER [or 10% BLER], 5% undetectable error rate for <=11 bits, and 2% undetectable error rate for >11 bits
o The payload size is 11 bits or 22 bits, where 4 and 8 bits for HARQ-ACK, respectively. Other payload sizes can be evaluated and if so, reported by each individual company
Note 1: In addition to the results already submitted to RAN1 103e which does not consider DTX detection, for any PUCCH coverage enhancement scheme especially the four prioritized schemes, companies are encouraged to submit more simulation results by 11/10/2020 with DTX detection, considering the above performance metric. Both results with and without DTX detection will be captured in the TR.
Note 2: false alarm rate is the probability that DTX is detected as a correct payload.
Note 3: undetectable error rate = # instances that a UCI payload is declared as correct when the UCI payload is in error / Total # instances that UCI payloads are in error, where a UCI payload is declared as correct if it passes the error detection check (with details up to each company, and to be reported)
Decision: As per email decision posted on 11/11:
Agreements:
For DMRS-less PUCCH, capture the following in the TR
Potential Spec impact:
·
A new
PUCCH format would need needs to be specified, including the power
control of the new PUCCH format. The new PUCCH format is would be an
addition to existing PUCCH formats.
· Two approaches to generate sequence for DMRS-less PUCCH (i.e., reuse Rel-15/16 CGS/ZC/Gold/m-sequence or design new sequences) were studied. The potential spec impacts include:
o If reusing Rel-15/16 CGS/ZC/Gold/m-sequence of the same length being supported by the current Rel-15/16 specification, no new sequences need to be specified.
o If new sequences (including new sequence type or same type as in Rel-15/16 but with different length) or sequences based on modification of NR Rel-15/16 UCI encoding scheme are adopted, the new sequences or the modification of NR Rel-15/16 UCI encoding scheme need to be specified.
· UCI to sequence mapping and sequence to RE mapping need to be specified
· [UCI info bits size (X) needs to be specified]
· [New RAN4 MPR requirement needs to be defined, if new sequences other than Rel-15/16 CGS/ZC/Gold/m-sequences are adopted]
·
[CSI
and HARQ-ACK UCI multiplexing for this new PUCCH format need to be
specified]
Agreements:
For PUSCH repetition type-B like PUCCH repetition, capture the following in the TR
Impact to receiver:
· gNB needs to process more than one PUCCH repetitions in a slot
· gNB needs to combine multiple repetitions with different code rates/time length
Agreements:
For dynamic PUCCH repetition factor indication, capture the following in the TR
Potential Spec impact:
· a new PUCCH repetition signalling mechanism needs to be specified
Impact to receiver: None
Impact to UE implementation:
· Need implement transmissions of the PUCCH repetitions based on the dynamic indicator
[Impact to system]
· [FFS the impact to system]
Agreements:
For DMRS bundling cross PUCCH repetitions, capture the following in the TR
Potential Spec impact:
· Restrictions to guarantee phase coherency cross repetitions need to be specified
· UE behaviour needs to be defined if the phase coherency of PUCCH repetition is impacted by other procedures
· DMRS bundling with inter-slot frequency hopping pattern enhancement need to be specified, if the frequency hopping enhancement is agreed.
Agreements:
For DMRS bundling cross PUCCH or PUSCH repetitions, send an LS to RAN4 to ask the following
· Under what conditions UE can keep phase continuity cross PUCCH or PUSCH repetitions
o Whether back-to-back PUCCH or PUSCH repetitions is one of the conditions required to keep phase continuity cross the repetitions
· Power control tolerance level cross PUCCH or PUSCH repetitions
Agreements: For DMRS-less PUCCH, capture Table 1, Table 2, and Table 3 in the TR.
Table 1: Performance (SNR) gain observed for DMRS-less PUCCH over Rel-15/16 baseline
|
Simulated scenario |
Performance metric |
Observed SNR gains |
Source |
|
Scenario 1: 2 bits UCI Baseline: PF1 Enhancement: DMRS-less PUCCH |
1% FA, 1% ACK miss detection, 0.1% NACK->ACK error |
3dB |
QC |
|
3dB |
OPPO |
||
|
3~4dB |
Huawei |
||
|
Scenario 2: 3/4/6 bits UCI Baseline: PF3 Enhancement: DMRS-less PUCCH
Note: Intel simulated 3-7 bits UCI |
1% BLER |
3dB |
QC |
|
3dB |
Sharp |
||
|
1.5 ~ 2.1dB |
Eurecom |
||
|
1% FA, 1% BLER |
0dB |
Intel |
|
|
0.3~0.5dB |
VIVO |
||
|
1% FA, 1% ACK miss detection, and 0.1% NACK to ACK |
1~2dB |
VIVO |
|
|
2.8dB |
QC |
||
|
0dB |
Ericsson |
||
|
Scenario 3: 11 bits UCI Baseline: PF3 Enhancement: DMRS-less PUCCH
Note: Intel simulated 8-11 bits UCI |
1% BLER |
3~4dB |
QC |
|
3~4dB |
HW |
||
|
2~3dB |
ZTE |
||
|
1.5~2.1dB |
Eurecom |
||
|
0 ~ 0.2dB |
Ericsson |
||
|
1 ~ 2.7dB |
CMCC |
||
|
1% FA, 1% BLER |
0.3dB |
Intel |
|
|
2.1dB |
QC |
||
|
1% FA, 1% ACK miss detection, and 0.1% NACK to ACK error |
4dB |
VIVO |
|
|
3.8dB |
ZTE |
||
|
4dB |
QC |
||
|
0dB |
Ericsson |
||
|
1% FA, 1% BLER, and 5% undetectable error rate |
4dB |
QC |
|
|
Scenario 3: 22/24 bits UCI Baseline: PF3 Enhancement: DMRS-less PUCCH |
1% BLER |
-2dB |
Eurecom |
|
1dB |
QC |
Table 2: Performance (PAPR/CM) gain observed for DMRS-less PUCCH over Rel-15/16 baseline
|
Modulation order |
Observed PAPR/CM gain |
Source |
|
QPSK |
3.5dB PARR gain 1dB CM gain |
QC |
|
6.3dB PAPR gain |
Eurecom |
|
|
4.5dB PAPR gain |
Huawei |
|
|
Pi/2 BPSK |
0.5dB PAPR gain 0.6dB CM gain |
QC |
|
4.8 dB PAPR gain |
Eurecom |
Table 3: Key simulation assumptions for DMRS-less PUCCH study over Rel-15/16 baseline
|
Company |
Key simulation assumptions |
|
ZTE |
Receiver for Rel-15/16 PUCCH: ML coherent receiver Receiver for sequence based PUCCH: ML noncoherent sequence detector |
|
Intel |
Receiver for Rel-15/16 PUCCH: ML coherent receiver (MMSE channel estimator and equalizer) and non-coherent receiver Receiver for sequence based PUCCH: ML noncoherent sequence detector/correlator |
|
Qualcomm |
Receiver for Rel-15/16 PUCCH: ML coherent receiver Receiver for sequence based PUCCH: ML noncoherent receiver (correlator with 2D-FFT or fast Hadamard transform) |
|
Sharp |
Receiver for Rel-15/16 PUCCH: MMSE channel estimation (with genie Doppler and delay spread) + ML coherent detection Receiver for sequence based PUCCH: ML noncoherent sequence detector/correlator |
|
CMCC |
Receiver for Rel-15/16 PUCCH: ML coherent receiver Receiver for sequence based PUCCH: ML noncoherent sequence detector/correlator |
|
vivo |
Receiver for Rel-15/16 PUCCH: ML coherent receiver Receiver for sequence based PUCCH: ML noncoherent sequence detector/correlator Ideal noise power estimation is used for both receiver for both legacy PUCCH and new sequence based PUCCH, and the noise power is used only in DTX detection. |
|
Ericsson |
Receiver for Rel-15/16 PUCCH: conventional and ML noncoherent receiver Receiver for sequence based PUCCH: ML noncoherent receiver |
|
EURECOM |
Receiver for Rel-15/16 PUCCH: advanced receivers for <=11 bits(non-coherent ML), conventional receiver for 22 bits (LS channel estimation + MMSE/MRC) Receiver for sequence based PUCCH: ML noncoherent sequence detector/correlator for 4/11 bit case; non-coherent LLR unit adapted to 3GPP polar code for 22-bit case. Also simulated low-complexity receiver for 11-bit UCI case. |
|
Huawei, HiSi |
Receiver for Rel-15/16 PUCCH: 2D-Wiener filter based channel estimation + MMSE equalization Receiver for sequence based PUCCH: CHIRRUP algorithm based sequence detection |
|
OPPO |
Receiver for Rel-15/16 PUCCH: LMMSE-IRC receiver. Receiver for sequence based PUCCH: ML correlation. |
Agreements: For DMRS-less PUCCH, capture the following in the TR
· Receiver needs to implement a non-coherent sequence detector/correlator for reception of the new PUCCH format.
· [For reception of the new PUCCH format, channel and noise covariance matrix estimation is not required. ]
· Computation efficient implementations of the receiver for the new PUCCH format have been studied. Their complexity can be lower or higher than the decoder for existing NR PUCCH coherent receiver depending on the adopted sequence, on the UCI payload size and on the implementation of the considered coherent receiver.
· [Receiver that uses PUCCH DM-RS for channel parameters estimation, channel tracking, and/or interference estimation must instead use other signals.]
Agreements: For DMRS-less PUCCH, capture the following in the TR
· Receiver implementation for the new PUCCH format is an extension of the PUCCH format 0 receiver with similarity that both are noncoherent sequence detectors, while the new receiver needs to perform correlation over a larger sequence pool. The size of the sequence pool over which the receiver for the new PUCCH format needs to perform correlation increases exponentially with the number of UCI bits.
Agreements: For DMRS-less PUCCH, capture the following in the TR
· UE needs to implement a UCI to sequence mapping and sequence to RE mapping for the new PUCCH format
· Four potential approaches to implement the sequences for DMRS-less PUCCH were studied.
o Approach 1: Reuse Rel-15/16 CGS/ZC/Gold/m-sequences generation with the same sequence length being supported in Rel-15/16
o Approach 2: Reuse Rel-15/16 CGS/ZC/Gold/m-sequences generation with a different sequence length being supported in Rel-15/16
o Approach 3: Modification of NR Rel-15/16 UCI encoding scheme to generate the sequences
o Approach 4: implement a new sequence generation which is not covered by above, if the new sequence is adopted in spec.
Agreements: For PUSCH repetition type-B like PUCCH repetition, capture the following in the TR
Restriction of the scheme:
· Only applicable to UCI <=11 bits
Agreements: For PUSCH repetition type-B like PUCCH repetition, captured Table 4 in the TR.
Table 4: Performance gain observed for PUSCH repetition Type-B like PUCCH repetition
|
Company |
Observed performance gain |
Key simulation assumptions |
|
VIVO |
0.5dB (w/o DMRS bundling) 1~1.5dB (w DMRS bundling)
Note: the 1~1.5 gain observed is a combination of DMRS bundling gain and type-B PUSCH repetition. |
11 bits UCI, w/ DTX detection, 1% BLER Receiver for Rel-15/16 PUCCH: coherent detection, DTX is performed based on union of DMRS and UCI symbols.
Receiver for PUCCH enhancement scheme: with and without joint channel estimation for the consecutive PUCCH repetitions, in addition to receiver for Rel-15 and Rel-16 UEs. Note: Ideal noise power estimation is used for above receivers, and the noise power is used only in DTX detection. |
Agreements: For PUSCH repetition type-B like PUCCH repetition, capture the following in the TR
Potential Spec impact:
· Nominal repetition, actual repetition, segmentation for type B PUCCH repetition, and flexible time domain resource allocation in each slot need to be specified
· Procedure to handle postpone/cancel PUCCH repetitions (including interaction with dynamic SFI) needs to be specified
· [Upper bound on UCI info bits size needs to be specified]
· [PUSCH type B repetition specification can be leveraged]
·
[Procedure
to transmit actual repetition in DFT-S-OFDM waveform with 1/2/3 OFDM symbols
needs to be specified, if 1/2/3 OFDM symbol actual type B PUCCH repetition is
supported]
o
[Potentially
new DMRS patterns need to be specified]
· The issue of whether supporting type B PUCCH repetitions with different PUCCH formats was studied and three options were identified to resolve this issue:
o Option 1: Restrict type B PUSCCH repetition applicable to actual repetitions with the same PUCCH format.
o Option 2: Allow type B PUCCH repetition with different PUCCH formats. The procedure to handle format switch between repetitions needs to be specified.
o Option 3: Introduce and specify PUCCH format 3/4 of length 1/2/3 OFDM symbols to support type B PUCCH repetition.
·
[Procedure
and RAN4 requirements to handle different PUCCH formats (with potential
switching between different waveforms of OFDM and DFT-S-OFDM) cross actual
repetitions needs to be specified, if option 2 is adopted]
· Power control for actual repetitions needs to be specified
·
[CSI
and HARQ-ACK multiplexing with type B PUCCH repetition need to be specified]
Agreements: For dynamic PUCCH repetition factor indication, capture Table 5 in the TR.
Table 5: Performance gain observed for Dynamic PUCCH repetition factor indication
|
Company |
Observed performance gain |
Key simulation assumptions |
|
Ericsson |
5 dB (with repetition factor 8) |
11 bits CSI, w/o DTX detection, 10% BLER Receiver for Rel-15/16 PUCCH: conventional DMRS based receiver Receiver for PUCCH enhancement scheme: conventional DMRS based receiver (without cross slot channel estimation). |
|
ZTE |
Reducing the number of PUCCH repetitions for more than 70% cases. |
11 bits UCI, w/o DTX detection, 1% BLER |
Agreements: For DMRS bundling cross PUCCH repetitions, capture the following in the TR
Restriction of the scheme:
· Phase coherency cross PUCCH repetitions is required
· The same frequency resource allocation cross PUCCH repetitions is required
· The same power cross PUCCH repetitions is required
Agreements: For DMRS bundling cross PUCCH repetitions, capture Table 6 in the TR
Table 6: Performance gain observed for DMRS bundling cross PUCCH repetitions over Rel-15/16 baseline
|
Company |
Observed performance gain |
Key simulation assumptions |
|
ZTE |
1 dB |
22 bits UCI, w/o DTX detection, 1% BLER, 4 PUCCH repetitions Receiver for Rel-15/16 PUCCH: ML coherent receiver, w/o cross-slot channel estimation Receiver for PUCCH enhancement scheme: ML coherent receiver, w/ cross-slot channel estimation |
|
Intel |
~1.2 dB |
22 bits UCI, w/o DTX detection, 1% BLER, 8 PUCCH repetitions Receiver for Rel-15/16 PUCCH: coherent receiver, w/o cross-slot channel estimation Receiver for PUCCH enhancement scheme: coherent receiver, w/ cross-slot channel estimation |
|
VIVO |
0.85 ~ 1.3 dB |
11 bits UCI, w/ DTX detection, 1% BLER, 2 PUCCH repetitions Receiver for Rel-15/16 PUCCH: Coherent detection, DTX is performed based on union of DMRS and UCI symbols. Channel estimation is performed individually for each repetition. Receiver for PUCCH enhancement scheme: Joint channel estimation is used for PUCCH repetitions in consecutive slots, in addition to receiver for Rel-15 and Rel-16 UEs. Note: Ideal noise power estimation is used for both receivers, and the noise power is used only in DTX detection. |
Agreements: For DMRS bundling cross PUCCH repetitions, capture the following in the TR
· New channel estimator needs to be implemented at receiver to process DMRS across multiple repetitions
· Same phase and transmission power need to be maintained at UE cross PUCCH repetitions
· [Maintaining phase coherence across slots requires UE to alter how slot boundaries events (such as timing or power adjustments) are handled]
R1-2009784 LS on PUCCH and PUSCH repetition RAN1, Qualcomm
Decision: As per email decision posted on Nov.16th, the latest draft LS is endorsed. Final LS is approved in R1-2009784.
Agreements:
· For DMRS-less PUCCH, update the Table 1, Table 2, Table 3 as the following and capture them in the TR.
Table 1: Performance (SNR) gain observed for DMRS-less PUCCH
|
Simulated scenario |
Performance metric |
Observed SNR gains |
Source |
|
Scenario 1: 2 bits UCI Baseline: PF1 Enhancement: DMRS-less PUCCH |
1% FA, 1% ACK miss detection, 0.1% NACK->ACK error |
3dB |
QC |
|
3dB |
OPPO |
||
|
3~4dB |
Huawei |
||
|
Scenario 2: 3/4/6 bits UCI Baseline: PF3 Enhancement: DMRS-less PUCCH
Note: Intel/Ericsson simulated 3-7 bits UCI |
1% BLER |
3dB |
QC |
|
3dB |
Sharp |
||
|
1.5 ~ 2.1dB |
Eurecom |
||
|
0 ~ 0.2dB |
Ericsson |
||
|
1% FA, 1% BLER |
0dB |
Intel |
|
|
0.3~0.5dB |
VIVO |
||
|
1% FA, 1% ACK miss detection, and 0.1% NACK to ACK |
1~2dB |
VIVO |
|
|
2.8dB |
QC |
||
|
0dB |
Ericsson |
||
|
Scenario 3: 11 bits UCI Baseline: PF3 Enhancement: DMRS-less PUCCH
Note: Intel/Ericsson simulated 8-11 bits UCI |
1% BLER |
3~4dB |
QC |
|
3~4dB |
HW |
||
|
2~3dB |
ZTE |
||
|
1.5~2.1dB |
Eurecom |
||
|
0 ~ 0.2dB |
Ericsson |
||
|
1 ~ 2.7dB |
CMCC |
||
|
1% FA, 1% BLER |
0.3dB |
Intel |
|
|
2.1dB |
QC |
||
|
1% FA, 1% ACK miss detection, and 0.1% NACK to ACK error |
4dB |
VIVO |
|
|
3.8dB |
ZTE |
||
|
4dB |
QC |
||
|
4.1dB |
HW |
||
|
0dB |
Ericsson |
||
|
1% FA, 1% BLER, and 5% undetectable error rate |
4dB |
QC |
|
|
3dB |
HW |
||
|
Scenario 3: 22/24 bits UCI Baseline: PF3 Enhancement: DMRS-less PUCCH |
1% BLER |
-2dB |
Eurecom |
|
1dB |
QC |
Table 2: Performance (PAPR/CM) gain observed for DMRS-less PUCCH over Rel-15/16 baseline
|
Modulation order |
Observed PAPR/CM gain |
Source |
|
QPSK |
3.5dB PARR gain 1dB CM gain |
QC |
|
6.3dB PAPR gain |
Eurecom |
|
|
4.5dB PAPR gain 1.7dB CM gain |
Huawei |
|
|
Pi/2 BPSK |
0.5dB PAPR gain 0.6dB CM gain |
QC |
|
4.8 dB PAPR gain |
Eurecom |
|
|
2.4dB PAPR gain |
Huawei |
Table 3: Key simulation assumptions for DMRS-less PUCCH study
|
Company |
Key simulation assumptions |
|
ZTE |
Receiver for Rel-15/16 PUCCH: ML coherent receiver Receiver for sequence based PUCCH: ML noncoherent sequence detector |
|
Intel |
Receiver for Rel-15/16 PUCCH: ML coherent receiver (MMSE channel estimator and equalizer) and non-coherent receiver Receiver for sequence based PUCCH: ML noncoherent sequence detector/correlator |
|
Qualcomm |
Receiver for Rel-15/16 PUCCH: ML coherent receiver Receiver for sequence based PUCCH: ML noncoherent receiver (correlator with 2D-FFT or fast Hadamard transform) |
|
Sharp |
Receiver for Rel-15/16 PUCCH: MMSE channel estimation (with genie Doppler and delay spread) + ML coherent detection Receiver for sequence based PUCCH: ML noncoherent sequence detector/correlator |
|
CMCC |
Receiver for Rel-15/16 PUCCH: ML coherent receiver Receiver for sequence based PUCCH: ML noncoherent sequence detector/correlator |
|
vivo |
Receiver for Rel-15/16 PUCCH: ML coherent receiver Receiver for sequence based PUCCH: ML noncoherent sequence detector/correlator Ideal noise power estimation is used for both receiver for both legacy PUCCH and new sequence based PUCCH, and the noise power is used only in DTX detection. |
|
Ericsson |
Receiver for Rel-15/16 PUCCH: conventional and ML noncoherent receiver Receiver for sequence based PUCCH: ML noncoherent receiver |
|
EURECOM |
Receiver for Rel-15/16 PUCCH: advanced receivers for <=11 bits(non-coherent ML), conventional receiver for 22 bits (LS channel esimtation + MMSE/MRC) Receiver for sequence based PUCCH: ML noncoherent sequence detector/correlator for 4/11 bit case; non-coherent LLR unit adapted to 3GPP polar code for 22-bit case. Also simulated low-complexity receiver for 11-bit UCI case. |
|
Huawei, HiSi |
Receiver 1 (higher complexity) for Rel-15/16 PUCCH: ML non-coherent receiver Receiver 2 (lower complexity) for Rel-15/16 PUCCH: 2D-Wiener filter based channel estimation + MMSE equalization+ ML coherent detection Receiver 1 (higher complexity) for sequence based PUCCH: ML non-coherent receiver Receiver 2 (lower complexity) for sequence based PUCCH: Rx signal combination +CHIRRUP algorithm based sequence detection |
|
OPPO |
Receiver for Rel-15/16 PUCCH: LMMSE-IRC receiver. Receiver for sequence based PUCCH: ML correlation. |
Agreements:
· For DMRS-less PUCCH, update the Table 1, Table 2, Table 3 as the following and capture them in the TR.
Table 1: Performance (SNR) gain observed for DMRS-less PUCCH over Rel-15/16 baseline
|
Simulated scenario |
Performance metric |
Observed SNR gains |
Source |
|
Scenario 1: 2 bits UCI Baseline: PF1 Enhancement: DMRS-less PUCCH |
1% FA, 1% ACK miss detection, 0.1% NACK->ACK error |
3dB |
Source 3 [QC] (receiver assumption 1) |
|
3dB |
Source 10 [OPPO] |
||
|
3~4dB |
Source 9 [HW] (receiver assumption A) |
||
|
Scenario 2: 3/4/6 bits UCI Baseline: PF3 Enhancement: DMRS-less PUCCH
Note: Intel/Ericsson simulated 3-7 bits UCI |
1% BLER |
3dB |
Source 3 [QC] (receiver assumption 2) |
|
3dB |
Source 4 [Sharp] |
||
|
1.5 ~ 2.1dB |
Source 8 [Eurecom] |
||
|
0 ~ 0.2dB |
Source 7 [Ericsson] |
||
|
1% FA, 1% BLER |
0dB |
Source 2 [Intel] |
|
|
0.3~0.5dB |
Source 6 [vivo] |
||
|
1% FA, 1% ACK miss detection, and 0.1% NACK to ACK |
1~2dB |
Source 6 [vivo] |
|
|
2.8dB |
Source 3 [QC] (receiver assumption 2) |
||
|
1dB |
Source 3 [QC] (receiver assumption 1) |
||
|
0dB |
Source 7 [Ericsson] |
||
|
Scenario 3: 11 bits UCI Baseline: PF3 Enhancement: DMRS-less PUCCH
Note: Intel/Erisson simulated 8-11 bits UCI |
1% BLER |
3~4dB |
Source 3 [QC] (receiver assumption 2) |
|
0.8~1.5dB |
Source 3 [QC] (receiver assumption 1) |
||
|
3dB |
Source 9 [HW] (receiver assumption B) |
||
|
2.4dB |
Source 9 [HW] (receiver assumption A) |
||
|
2~3dB |
Source 1 [ZTE] |
||
|
1.5~2.1dB |
Source 8 [Eurecom] |
||
|
0 ~ 0.2dB |
Source 7 [Ericsson] |
||
|
1 ~ 2.7dB |
Source 5 [CMCC] |
||
|
1% FA, 1% BLER |
0.3dB |
Source 2 [Intel] |
|
|
2.1dB |
Source 3 [QC] (receiver assumption 2) |
||
|
1% FA, 1% ACK miss detection, and 0.1% NACK to ACK error |
4dB |
Source 6 [vivo] |
|
|
3.8dB |
Source 1 [ZTE] |
||
|
4dB |
Source 3 [QC] (receiver assumption 2) |
||
|
0.9~4.8dB |
Source 3 [QC] (receiver assumption 1) |
||
|
4.1dB |
Source 9 [HW] (receiver assumption B) |
||
|
2.8dB |
Source 9 [HW] (receiver assumption A) |
||
|
0dB |
Source 7 [Ericsson] |
||
|
1% FA, 1% BLER, and 5% undetectable error rate |
4dB |
Source 3 [QC] (receiver assumption 2) |
|
|
1.5~2.8dB |
Source 3 [QC] (receiver assumption 1) |
||
|
3dB |
Source 9 [HW] (receiver assumption B) |
||
|
2dB |
Source 9 [HW] (receiver assumption A) |
||
|
0dB |
Source 7 [Ericsson] |
||
|
Scenario 3: 22/24 bits UCI Baseline: PF3 Enhancement: DMRS-less PUCCH |
1% BLER |
-2dB |
Source 8 [Eurecom] |
|
1dB |
Source 3 [QC] (receiver assumption 2) |
Table 2: Performance (PAPR/CM) gain observed for DMRS-less PUCCH over Rel-15/16 baseline
|
Modulation order |
Observed PAPR/CM gain |
Source |
|
QPSK |
3.5dB PARR gain 1dB CM gain |
Source 3 [QC] |
|
6.3dB PAPR gain |
Source 8 [Eurecom] |
|
|
4.5dB PAPR gain 1.7dB CM gain |
Source 9 [HW] |
|
|
Pi/2 BPSK |
0.5dB PAPR gain 0.6dB CM gain |
Source 3 [QC] |
|
4.8 dB PAPR gain |
Source 8 [Eurecom] |
|
|
2.4dB PAPR gain |
Source 9 [HW] |
Table 3: Key simulation assumptions for DMRS-less PUCCH study
|
Company |
Key simulation assumptions |
|
Source 1 [ZTE] |
Channel model of TDL-C 300 ns, UE speed of 3km/h Receiver for Rel-15/16 PUCCH: ML coherent receiver Receiver for sequence based PUCCH: ML noncoherent sequence detector |
|
Source 2 [Intel] |
Channel model of TDL-C 300 ns, UE speed of 3km/h Receiver for Rel-15/16 PUCCH: ML coherent receiver (MMSE channel estimator and equalizer) and non-coherent receiver Receiver for sequence based PUCCH: ML noncoherent sequence detector/correlator |
|
Source 3 [QC] |
Channel model of TDL-C and TDL-A with up to 800 ns channel delay spread (including effects of timing error), up to 1111 Hz doppler (including effect of frequency error)
Receiver assumption 1: · Receiver for Rel-15/16 PUCCH: noncoherent ML detection performed on union of PUCCH DMRS and UCI symbols. Error detection based on noncoherent duo metric. · Receiver for sequence based PUCCH: ML noncoherent receiver (correlator with 2D-FFT or fast Hadamard transform) Receiver assumption 2: · Receiver for Rel-15/16 PUCCH: ML coherent receiver · Receiver for sequence based PUCCH: ML noncoherent receiver (correlator with 2D-FFT or fast Hadamard transform) |
|
Source 4 [Sharp] |
Receiver for Rel-15/16 PUCCH: MMSE channel estimation (with genie Doppler and delay spread) + ML coherent detection Receiver for sequence based PUCCH: ML noncoherent sequence detector/correlator |
|
Source 5 [CMCC] |
Channel model of TDL-C 300 ns Receiver for Rel-15/16 PUCCH: ML coherent receiver Receiver for sequence based PUCCH: ML noncoherent sequence detector/correlator |
|
Source 6 [vivo] |
Channel model of TDL-C 100 ns, UE speed of 3km/h Receiver for Rel-15/16 PUCCH: ML coherent receiver Receiver for sequence based PUCCH: ML noncoherent sequence detector/correlator Ideal noise power estimation is used for both receiver for both legacy PUCCH and new sequence based PUCCH, and the noise power is used only in DTX detection. |
|
Source 7 [Ericsson] |
Channel model of TDL-C 300 ns, UE speed of 3km/h Receiver for Rel-15/16 PUCCH: conventional and ML noncoherent receiver Receiver for sequence based PUCCH: ML noncoherent receiver |
|
Source 8 [Eurecom] |
Receiver for Rel-15/16 PUCCH: advanced receivers for <=11 bits(non-coherent ML), conventional receiver for 22 bits (LS channel esimtation + MMSE/MRC) Receiver for sequence based PUCCH: ML noncoherent sequence detector/correlator for 4/11 bit case; non-coherent LLR unit adapted to 3GPP polar code for 22-bit case. Also simulated low-complexity receiver for 11-bit UCI case. |
|
Source 9 [HW] |
Channel model of TDL-C 300 ns, UE speed of 3km/h or 120km/h Receiver assumption A: · Receiver (higher complexity) for Rel-15/16 PUCCH: ML non-coherent receiver · Receiver (higher complexity) for sequence based PUCCH: ML non-coherent receiver Receiver assumption B: · Receiver (lower complexity) for Rel-15/16 PUCCH: 2D-Wiener filter based channel estimation + MMSE equalization+ ML coherent detection · Receiver (lower complexity) for sequence based PUCCH: Rx signal combination +CHIRRUP algorithm based sequence detection |
|
Source 10 [OPPO] |
Channel model of TDL-C 300 ns, UE speed of 3km/h Receiver for Rel-15/16 PUCCH: LMMSE-IRC receiver. Receiver for sequence based PUCCH: ML correlation. |
Agreement:
For long PUCCH format, the number of UCI bits that the DMRS-less PUCCH support is up to 11 bits.
Agreement:
RAN1 has not concluded on which of 2 or 3 bits is the minimum number of UCI bits that DMRS-less PUCCH can support.
Agreements:
For DMRS-less PUCCH, update the following agreements and capture them in the TR
Potential Spec impact:
· A new PUCCH format would need to be specified, including the power control of the new PUCCH format. The new PUCCH format would be an addition to existing PUCCH formats.
· Two approaches to generate sequence for DMRS-less PUCCH (i.e., reuse Rel-15/16 CGS/ZC/Gold/m-sequence or design new sequences) were studied. The potential spec impacts include:
o If reusing Rel-15/16 CGS/ZC/Gold/m-sequence of the same length being supported by the current Rel-15/16 specification, no new sequences need to be specified.
o If new sequences (including new sequence type or same type as in Rel-15/16 but with different length) or sequences based on modification of NR Rel-15/16 UCI encoding scheme are adopted, the new sequences or the modification of NR Rel-15/16 UCI encoding scheme need to be specified.
· UCI to sequence mapping and sequence to RE mapping need to be specified
·
[UCI
info bits size (X) needs to be specified]
·
[New RAN4 MPR requirement may needs to be defined, if new sequences other than
Rel-15/16 CGS/ZC/Gold/m-sequences are adopted]
·
[UCI multiplexing for this new PUCCH format need to be specified]
Agreements:
For DMRS-less PUCCH, capture the following in the TR
· In the non-coherent sequence detector at receiver, changes to existing implementation for DTX detection, including noise and interference power estimation, may be necessary if the existing implementation relies on the presence of DMRS.
Agreements:
For DMRS-less PUCCH, update the following agreements and capture them in the TR
· Receiver needs to implement a non-coherent sequence detector/correlator for reception of the new PUCCH format.
·
[For reception of the new PUCCH format, channel and noise covariance
matrix estimation using DMRS is not required].
· Computation efficient implementations of the receiver for the new PUCCH format have been studied. Their complexity can be lower or higher than the decoder for existing NR PUCCH coherent receiver depending on the adopted sequence, on the UCI payload size and on the implementation of the considered coherent receiver.
·
[Receiver
that uses PUCCH DM-RS for channel parameters estimation, channel tracking,
and/or interference estimation must instead use other signals.]
· gNB receivers may use PUCCH DM-RS for channel parameter estimation, channel tracking, and/or interference estimation. Absence of DMRS in the new PUCCH format requires such gNB receivers to rely on other reference signals or pursue data-aided estimation and tracking
Agreements:
For DMRS bundling cross PUCCH repetitions, capture the following in the TR
Impact to system
· gNB needs to maintain phase coherence across slots. gNB cannot switch beamformers or make any RF adjustments across multiple slots.
· UE needs to maintain phase coherence across multiple slots. UE-side adjustments for timing and frequency will have to be postponed to a later slot. UE may not have the best timing and frequency settings for multiple uplink slots.
Final summary in:
R1-2009405 FL summary#2 of PUCCH coverage enhancement Moderator (Qualcomm)
R1-2007585 Discussion on the potential coverage enhancement solutions for other channels Huawei, HiSilicon
R1-2007682 Discussion on coverage enhancement for channels other than PUCCH and PUSCH vivo
R1-2007745 Discussion on potential techniques for channels other than PUSCH and PUCCH ZTE
R1-2007876 Discussion on coverage enhancement for channels other than PUSCH and PUCCH CATT
R1-2007906 Coverage enhancement for Msg3 Indian Institute of Tech (H)
R1-2007956 On coverage enhancement for channels other than PUSCH and PUCCH Intel Corporation
R1-2007996 Discussion on Msg3 PUSCH enhancements China Telecom
R1-2008028 Discussion on coverage enhancement for channels other than PUSCH and PUCCH CMCC
R1-2008080 Discussion on Msg3 coverage enhancement NEC
R1-2008183 Coverage enhancement for channels other than PUSCH and PUCCH Samsung
R1-2008273 Coverage enhancement on NR channels other than PUSCH and PUCCH OPPO
R1-2008310 Coverage Enhancements for initial access AT&T
R1-2008372 Coverage enhancement for initial access Sony
R1-2008401 Coverage enhancement for channels other than PUCCH/PUSCH Sharp
R1-2008405 Discussions on coverage enhancement for channels other than PUSCH and PUCCH LG Electronics
R1-2008421 Coverage enhancement for channels other than PUSCH and PUCCH Ericsson
R1-2008480 Discussion on Msg3 coverage enhancement Apple
R1-2008485 Coverage enhancements for initial access InterDigital, Inc.
R1-2008561 Potential techniques for coverage enhancement for channels other than PUSCH and PUCCH NTT DOCOMO, INC.
R1-2009309 Potential coverage enhancement techniques for other channels Qualcomm Incorporated (rev of R1-2008628)
R1-2009793 Discussion on approaches and solutions for NR coverage enhancement: other channels than PUSCH and PUCCH Nokia, Nokia Shanghai Bell (rev of R1-2008705)
R1-2008716 Potential techniques for Msg3 PUSCH coverage enhancement Potevio
R1-2008731 Discussion on potential techniques for coverage enhancement for channels other than PUSCH and PUCCH WILUS Inc.
R1-2009322 Feature lead summary on coverage enhancement for channels other than PUSCH and PUCCH Moderator (ZTE)
Decision: Noted. From GTW on 10/26:
[103-e-NR-CovEnh-06] – Xianghui (ZTE)
Email discussion for coverage enhancement for channels other PUSCH and PUCCH
Decision: As per email decision posted on Nov.2nd,
Agreement: Capture the followings into the TR.
PUCCH repetition carrying HARQ-ACK for Msg4 was studied. Potential specification impacts include related signaling design, differentiation between enhanced UE and legacy UE.
Agreement: Capture the followings into the TR
Beam reporting during initial/random access procedure was studied from several aspects, including the best SSB, alternative SSB beam and early CSI report in Msg3 PUSCH. Potential specification impacts include signaling design in Msg3 PUSCH, CSI-RS resources configured during initial access, beam indication for the following steps for RACH procedure.
Decision: As per email decision posted on Nov.5th,
Agreements: Capture the followings into the TR
· PRACH enhancements were studied from several aspects, including multiple PRACH transmissions with the same beam, multiple PRACH transmissions with different beams, and PRACH enhancements with finer beam.
· Potential specification impacts of multiple PRACH transmissions include:
o For multiple PRACH transmissions with the same transmission beam and multiple PRACH transmissions with different transmission beams,
§ mechanism on triggering/initiating multiple PRACH transmissions,
§ determination of number of transmissions and transmission pattern,
§ differentiation between enhanced UE and legacy UE and
§ possible collision handling between PRACH transmission with and without multiple PRACH transmissions.
o Only for multiple PRACH transmissions with different transmission beams,
§ transmission beam to be used for each initial transmission and
§ beam determination for the following steps in RACH procedure.
o Potential specification impacts of PRACH enhancements with finer beam include finer beam for PRACH based on CSI-RS resources configured during initial access.
Agreement: Capture the followings into the TR
Broadcast PDCCH repetition was studied. Potential specification impacts include PDCCH repetition configuration.
Agreements: Capture the followings into the TR
· Msg4 PDSCH enhancements were studied from several aspects, including introducing early CSI on Msg3 PUSCH for early link adaptation , scaling factor for TBS determination and PDSCH repetition.
· Potential specification impacts of early CSI on Msg3 PUSCH for early link adaptation include:
o CSI-RS resources configured during initial access.
· Potential specification impacts of scaling factor for TBS determination include:
o TBS determination.
· Potential specification impacts of PDSCH repetition include:
o PDSCH repetition configuration, DMRS design among PDSCH repetitions.
Agreements: Capture the followings into the TR
Enhancements on Msg3 PUSCH repetition were studied from several aspects, including the indication of the number of repetitions for Msg3 initial transmission and re-transmission, the repetition type, the feasibility and applicability of enhancements studied for PUSCH in RRC_CONNECTED state for Msg3 PUSCH initial and re-transmission, inter-slot frequency hopping and differentiation between enhanced UE and legacy UE.
· Potential specification impacts of indication of the number of repetitions for Msg3 initial transmission include:
o Explicit indication mechanism, e.g., indicated by RAR UL grant, DCI format 1_0 with CRC scrambled by RA-RNTI or SIB1.
o Implicit indication mechanism, e.g., determined by PRACH configuration or information carried by RAR.
· Potential specification impacts of indication of the number of repetitions for Msg3 re-transmission include:
o Explicit indication mechanism, e.g., indicated by DCI format 0_0 with CRC scrambled by TC-RNTI.
o Implicit indication mechanism, e.g., determined by Msg3 initial transmission.
· Potential specification impacts of the repetition type include:
o Introducing PUSCH repetition Type A.
· Potential specification impacts of the feasibility and applicability of enhancements studied for PUSCH in RRC_CONNECTED state for Msg3 PUSCH initial and re-transmission include:
o The potential specification impacts for the solutions studied in Section 6.1.
· Potential specification impacts of inter-slot frequency hopping include:
o Inter-slot frequency hopping configuration and frequency hopping pattern.
· Potential specification impacts of differentiation between enhanced UE and legacy UE include:
o Mechanism to differentiate enhanced UE and legacy UE, e.g., separate PRACH configurations (e.g, separate PRACH occasions or preambles) and separate Msg3 configurations (e.g., separate DMRS ports).
Agreements: Capture the followings into the TR
Power domain-based solutions were studied for Msg3 PUSCH, including pi/2 BPSK waveform using DFT-s-OFDM and power control enhancements.
· Potential specification impacts of pi/2 BPSK waveform using DFT-s-OFDM include defining the usage of pi/2 BPSK modulation for Msg3 and either explicit or implicit power boosting based on the Msg3 time domain resource allocation.
· Potential specification impacts of power control enhancements include configuration of multiple sets of power control parameters.
Decision: As per email decision posted on Nov.11th,
Agreement: Capture the followings into the TR
CSI repetition on PUSCH was studied. Potential specification impacts include mechanism to determine A-CSI repetitions on PUSCH, e.g. A-CSI request and/or repetition factor in UL DCI, one A-CSI in each PUSCH repetition, and PUSCH repetition type A.
Agreement: Capture the followings into the TR
Spatial domain based solutions were studied from several aspects for Msg3 PUSCH, including spatial filter setting between PRACH transmission and corresponding Msg3 PUSCH transmission and open-loop transmission diversity.
· Potential specification impacts of spatial filter setting between PRACH transmission and corresponding Msg3 PUSCH transmission include specifying the same spatial filter between PRACH transmission and corresponding Msg3 PUSCH transmission, mechanism to differentiate enhanced UE and legacy UE.
· Potential specification impacts of open-loop transmission diversity include, mechanism to indicate support of transmission diversity for Msg3 PUSCH with DFT-s-OFDM, mechanism to differentiate enhanced UE and legacy UE, mechanism to determine the precoder cycling pattern during random access procedure, e.g. on different Msg3 PUSCH repetitions.
Agreement: Capture the followings into the TR
Compact DCI and PDCCH-less for broadcast PDCCH were studied for broadcast PDCCH.
· Potential specification impacts of compact DCI include mechanism for DCI bit field design for fallback DCI.
· Potential specification impacts of PDCCH-less include the mechanism to indicate the scheduling information for broadcast PDSCH carrying SIB messages.
Agreements: Capture the following observations into the TR
Observation 1:
Nine sources ([ZTE], [Intel], [NTT DOCOMO], [CMCC], [vivo], [Ericsson], [Nokia/NSB], [Huawei, HiSilicon], [Apple]) evaluated the performance of enhancements on Msg3 repetition.
· Eight sources show about 2 dB gain when the number of repetitions is doubled in FR1.
· One source shows 4.27 dB gain when the number of repetitions is increased to 8 in FR2.
· One source shows 1.1~1.75 dB gain when performing cross-slot channel estimation among 2 repetitions.
· One source shows 0.5~1.07 dB gain when performing cross-slot channel estimation among 4 repetitions.
· One source shows 3.8 dB gain with 2 repetitions and inter-slot hopping comparing with no repetition and no intra-slot hopping.
· One source shows 3.2 dB gain with 2 repetitions and inter-slot hopping comparing with no repetition and intra-slot hopping.
Observation 2:
One source ([IITH, IITM, CEWIT, Reliance Jio, Tejas Networks]) evaluated the performance of power boosting using pi/2 BPSK waveform for Msg3 and shows 3 dB gain for UL duty cycle lower than 50% and 6 dB gain for UL duty cycle lower than 25%.
Observation 3:
Three sources ([ZTE],[NTT DOCOMO], [Qualcomm]) evaluated the performance of enhancements on PDCCH repetition.
· Two sources show 2 dB gain and one source shows 2.8~3.1 dB gain when the number of repetitions is increased to 2.
· One source shows 4~5.8 dB gain and one source shows 4 dB gain when the number of repetitions is increased to 4.
· One source shows about 3dB and 6dB gain if DMRS bundling is considered for 2 and 4 repetitions respectively.
Observation 4:
One source [[NTT DOCOMO]] evaluated the performance of compact DCI and shows 1.5 dB gain if the number of DCI payload size is reduced from 40 bits to 20 bits.
Observation 5:
One source ([ZTE]) evaluated the performance of increasing the number of SSBs and shows 1.84 dB gain when the number of SSBs is increased from 4 to 8 at 700MHz in rural scenario.
Observation 6:
Two sources ([ZTE], [Nokia/NSB]) evaluated the performance of PRACH enhancements.
· One source ([ZTE]) shows 3.7 dB and 5.2 dB gain when performing 2 and 4 PRACH transmissions with the same transmission beam respectively at 4 GHz in urban scenario.
· One source ([ZTE]) shows 1.7 dB and 3.7 dB gain when performing 2 and 4 PRACH transmissions with the same transmission beam respectively at 28 GHz in urban scenario.
· One source ([Nokia/NSB])) shows 2 dB gain when performing 2 PRACH transmissions with different transmission beams at 2 GHz in rural scenario.
· One source ([Nokia/NSB]) shows 2 dB and 4.7 dB gain when performing 2 and 4 PRACH transmissions with different transmission beams respectively at 28 GHz in urban scenario.
Observation 7:
· One source ([ZTE]) evaluated the performance of PUCCH repetition with HARQ-ACK for Msg4 and shows 3 dB and 6 dB gain when the number repetitions is increased to 2 and 4 respectively at 2 GHz in rural scenario.
Observation 8:
· One source ([Ericsson]) evaluated the performance of A-CSI repetition on PUSCH and shows 4 dB gain for 8 repetitions with 11 bits CSI at 10% BLER target at 4GHz.
Agreement: Capture the followings into the TR
UE awareness of paired orthogonally polarized SSBs has been studied. Potential specification impacts of dual polarized SSBs with the same spatial filter setting include mechanisms to ensure UE awareness of polarization properties of SSBs, e.g., communication of paired SSB indices associated with the same spatial filtering and different polarizations, to the UE.
Agreements: Capture the followings into the TR
A-CSI on PUCCH to allow A-CSI repetition was studied. Potential specification impacts include
· mechanism to determine the repetition of A-CSI PUCCH, e.g. CSI request and/or repetition factor in the downlink DCI, configuration of repetition levels per PUCCH resource, and related timeline,
· mechanism for the PUCCH resource determination, e.g. based on existing PUCCH resource configuration framework in DL DCI (i.e., DCI format 1_0, 1_1, 1_2), existing PUCCH formats that can carry CSI.
· RS resource for CSI measurement (e.g. aperiodic CSI-RS, DMRS)
Decision: As per email decision posted on Nov.11th,
Proposal: To include the following recommendations in the TR:
· For coverage enhancements for channels other than PUSCH and PUCCH, it is recommended to support Msg3 PUSCH repetition in Rel-17.
· Supported by: SoftBank, vivo, ZTE, CATT, Intel, China Telecom, CMCC, NEC, Samsung, OPPO, Sharp, LG Electronics, Ericsson, Apple, InterDigital, NTT DOCOMO, Qualcomm, Nokia/Nokia Shanghai Bell, Potevio, WILUS
· Not supported by: Huawei/HiSilicon
Proposal: To include the following recommendations in the TR:
· For coverage enhancements for channels other than PUSCH and PUCCH, it is recommended to support the following in Rel-17:
o Enhancements on short PRACH format for FR2, including multiple PRACH transmissions with the same beam and multiple PRACH transmissions with different beams.
· Supported by: ZTE, Intel, Samsung, OPPO, Sony, InterDigital, Qualcomm, Nokia, Potevio, Sharp
· Not supported by: Ericsson, vivo, Huawei/HiSilicon
Final summary in:
R1-2009805 Feature lead summary#2 on coverage enhancement for channels other than PUSCH and PUCCH Moderator (ZTE)
R1-2007683 Considerations on Parameters for Coverage Evaluation vivo
R1-2007746 Discussion on target performance for NR coverage enhancements ZTE
R1-2007877 Discussion on remaining issues for coverage enhancement CATT
R1-2007957 On simulation assumptions for NR coverage enhancement Intel Corporation
R1-2008274 Functionality of Coverage Enhancement and other WI OPPO
R1-2008422 Coverage Parameter Sensitivity and Network Enhancement Ericsson
R1-2008487 Discussion on simulation assumptions for VoIP InterDigital, Inc.
R1-2008629 Other coverage enhancement aspects Qualcomm Incorporated
R1-2008706 Evaluation assumptions for NR coverage enhancement evaluation Nokia, Nokia Shanghai Bell
Please refer to RP-202928 for detailed scope of the WI
R1-2100914 Work plan for Rel-17 WI on NR coverage enhancements China Telecom
R1-2101625 PUSCH enhancements for coverage enhancements NTT DOCOMO, INC.
Withdrawn
R1-2100915 Enhancements on PUSCH repetition type A China Telecom
· Proposal 1: In Rel-17, both of the maximum number of repetitions configured by pusch-AggregationFactor and dynamically indicated by numberOfRepetitions-r17 can be increased to 32.
· Proposal 2: Network can configure different modes to differentiate whether the number of repetitions for PUSCH repetition type A is counted on the basis of contiguous slots or the number of repetitions counted on the basis of available UL slots by RRC.
· Proposal 3: The number of repetitions for PUSCH repetition type A is counted on the basis of semi-statically configured available UL slots.
· Proposal 4: For the number of repetitions for PUSCH repetition type A counted on the basis of available UL slots, the same symbol allocation is applied across the K available UL slots except for the special slots. For the special slots, the available UL symbols can be used for PUSCH transmission.
Decision: The document is noted.
R1-2100095 Discussion on enhanced PUSCH repetition type A ZTE
R1-2100172 Enhancements on PUSCH repetition type A OPPO
R1-2100196 Coverage enhancements for PUSCH repetition typeA Huawei, HiSilicon
R1-2100397 Discussion on enhancements on PUSCH repetition type A CATT
R1-2100457 Discussion on enhancement for PUSCH repetition type A vivo
R1-2100665 Enhancements on PUSCH repetition type A Intel Corporation
R1-2100712 Discussions on PUSCH repetition type A enhancements LG Electronics
R1-2100731 PUSCH repetition for coverage enhancements InterDigital, Inc.
R1-2100942 Discussion on enhancements on PUSCH repetition type A NEC
R1-2101001 Enhancements on PUSCH repetition type A Lenovo, Motorola Mobility
R1-2101017 Discussion on enhancements on PUSCH repetition Type A Panasonic Corporation
R1-2101055 Discussion on enhancements on PUSCH repetition type A CMCC
R1-2101656 Enhancements on PUSCH repetiton type A Xiaomi (rev of R1-2101127)
R1-2101221 Enhancements on PUSCH repetition type A Samsung
R1-2101327 Design Considerations for Enhancements on PUSCH repetition Sierra Wireless, S.A.
R1-2101395 Discussion on PUSCH repetition type A enhancement Apple
R1-2101407 PUSCH Repetitions for Coverage Enhancement Indian Institute of Tech (H)
R1-2101477 Enhancements on PUSCH repetition type A Qualcomm Incorporated
R1-2101520 PUSCH Repetition Type A Enhancement Ericsson
R1-2101545 Enhancements on PUSCH repetition type A Sharp
R1-2101641 Enhancements on PUSCH repetition type A NTT DOCOMO, INC.
R1-2101679 Discussion on enhancements on PUSCH repetition type A WILUS Inc.
R1-2101710 Enhancements on PUSCH repetition type A Nokia, Nokia Shanghai Bell
[104-e-NR-CovEnh-01] – Toshi (Sharp)
Email discussion on enhancements on PUSCH repetition type A
- 1st check point: Jan 28
- 2nd check point: Feb 2
- 3rd check point: Feb 4
R1-2102113 FL Summary on Enhancements on PUSCH repetition type A Moderator (Sharp)
Agreements:
Select one of the following alternatives, considering the aspect whether or not the determination of all the available slots should be done prior to the first actual transmission of the repetitions (other alternatives are not precluded)
· Alt1: Whether or not a slot is determined as available for UL transmissions depends on RRC configurations (at least tdd_ul_dl configuration, FFS: other RRC configurations) and does not depend on dynamic signaling (at least SFI, FFS: other dynamic signaling e.g. CI, PUSCH priority for URLLC).
· Alt2: Whether or not a slot is determined as available for UL transmissions depends on RRC configurations (at least tdd_ul_dl configuration, FFS: other RRC configurations) and also depends on dynamic signaling (at least SFI, FFS: other dynamic signaling e.g. CI, PUSCH priority for URLLC).
Agreement:
The maximum number of repetitions for DG-PUSCH is also applicable to CG-PUSCH.
Agreements:
For defining available slots: a slot is determined as unavailable if at least one of the symbols indicated by TDRA for a PUSCH in the slot overlaps with the symbol not intended for UL transmissions
· FFS details
Agreements:
Rel-17 PUSCH repetition Type A supports the increase of maximum number of repetitions with repetition factors configured in a TDRA list with a row index indicated either by the configured grant configuration or by TDRA field in a DCI.
· FFS: increasing the maximum number of repetitions with repetition factor configured in PUSCH-Config and/or ConfiguredGrantConfig.
Conclusion:
Discuss further to select one of the following alternatives:
· Alt-a: The determination of all the available slots has to be done prior to the first actual transmission of the repetitions.
· Alt-b: The determination of all the available slots does not have to be done prior to the first actual transmission of the repetitions. The timeline requirement is per repetition basis.
R1-2101018 Discussion on TB processing over multi-slot PUSCH Panasonic Corporation
· Proposal 1: The multiple slots for TBS determination are not required to be the same value as multiple slots for PUSCH transmissions.
· Proposal 2: For the time-domain resource, following options should be considered.
o Option 1: Time-domain resource more than 14 OFDM symbols
o Option 2: Multi-SLIV based
· Proposal 3: For the TBS determination for TB processing over multi-slot PUSCH, there could be the following steps:
o TBS is determined based on the number of REs over multiple slots.
§ UE first determines the number of REs within a PRB over multiple slots for TB processing,
§ Then, UE determines the TBS based on the equation in the current specification in TS38.214.
· Proposal 4: To specify how to handle the interactions of TB processing over multi-slot PUSCH with DL / UL direction and cancellation.
Decision: The document is noted.
R1-2100096 Discussion on TB processing over multi-slot PUSCH ZTE
R1-2100173 Supporting TB over multi-slot PUSCH OPPO
R1-2100232 Discussion on TB processing over multi-slot PUSCH Huawei, HiSilicon
R1-2100398 Discussion on TB processing over multi-slot PUSCH CATT
R1-2100458 Discussion on PUSCH TB processing over multiple slots vivo
R1-2100666 Discussion on TB processing over multi-slot PUSCH Intel Corporation
R1-2100713 Discussions on TB processing over multi-slot PUSCH LG Electronics
R1-2100732 TB processing over multi-slot PUSCH InterDigital, Inc.
R1-2100743 Views on TB processing over multi-slot PUSCH Fujitsu
R1-2100916 Discussion on TB processing over multi-slot PUSCH China Telecom
R1-2100943 Discussion on TB processing over multi-slot PUSCH NEC
R1-2101002 Enhancements for TB processing over multi-slot PUSCH Lenovo, Motorola Mobility
R1-2101056 Discussion on TB processing over multi-slot PUSCH CMCC
R1-2101128 Joint channel estimation for PUSCH Xiaomi
R1-2101222 TB processing over multi-slot PUSCH Samsung
R1-2101328 Design Considerations for TB processing over multi-slot PUSCH Sierra Wireless, S.A.
R1-2101396 Discussion on TB processing over multi-slot PUSCH Apple
R1-2101406 On TB processing over multiple slots for PUSCH Indian Institute of Tech (H)
R1-2101478 TB processing over multi-slot PUSCH Qualcomm Incorporated
R1-2101521 TB Processing over Multi-Slot PUSCH Ericsson
R1-2101546 TB processing over multi-slot PUSCH Sharp
R1-2101642 TB processing over multi-slot PUSCH NTT DOCOMO, INC.
R1-2101646 Discussion on TB processing over multi-slot PUSCH MediaTek Inc.
R1-2101680 Discussion on TB processing over multi-slot PUSCH WILUS Inc.
R1-2101711 Transport block processing for PUSCH coverage enhancements Nokia, Nokia Shanghai Bell
[104-e-NR-CovEnh-02] – Marco (Nokia)
Email discussion on TB processing over multi-slot PUSCH
- 1st check point: Jan 28
- 2nd check point: Feb 2
- 3rd check point: Feb 4
R1-2102241 FL summary of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia)
Decision: As per email posted on Feb 2nd,
· Consider one or two of the following options as starting points to design time domain resource determination of TBoMS
o PUSCH repetition type A like TDRA, i.e., the number of allocated symbols is the same in each slot.
o PUSCH repetition type B like TDRA, i.e., the number of allocated symbols in each slot can be different
Agreement:
· The same number of PRBs per symbol is allocated across slots for TBoMS transmission.
From GTW sessions:
Agreements:
· Consecutive physical slots for UL transmission can be used for TBoMS for unpaired spectrum
o To resolve in RAN1#104b-e whether to support non-consecutive physical slots for UL transmission for TBoMS for unpaired spectrum
· Consecutive physical slots for UL transmission can be used for TBoMS for paired spectrum and the SUL band
o FFS if non-consecutive physical slots for UL transmission are also supported for paired spectrum and the SUL band
Agreements:
For TBoMS, the maximum supported TBS should not exceed legacy maximum supported TBS in Rel-15/16, for the same number of layers.
· FFS: Details and further constraints on the applicability of TBoMS.
Decision: As per email posted on Feb 5th,
Agreements:
One or two of the following approaches will be considered as a starting point to decide how NInfo for TBoMS is calculated (aiming for down selection in RAN1 #104-bis-e):
· Approach 1: Based on all REs determined across the symbols or slots (FFS whether symbols or slots are used) over which the TBoMS transmission is allocated
· Approach 2: Based on the number of REs determined in the first L symbols over which the TBoMS transmission is allocated, scaled by K≥1.
o FFS: the definition of K
Note: L is the number of symbols determined using the SLIV of PUSCH indicated via TDRA
FFS: impacts and further details if repetitions of TBoMS is supported.
FFS: whether the symbols over which the TBoMS transmission is allocated are the same or can be different from the symbols over which the TBoMS transmission is performed, and details on how to handle such scenarios.
Agreements:
One or two of the following options will be considered (aiming for down-selection in RAN1#104b-e) to calculate NohPRB for TBoMS:
· Option 1: NohPRB is assumed to be the same for all the slots over which the TBoMS transmission is allocated and can be configured by xOverhead as in Rel-15/16.
· Option 2: NohPRB is calculated depending on both xOverhead and the number of symbols or slots (FFS whether symbol or slot are used) over which the TBoMS transmission is allocated.
o FFS: if either the number of symbols or the number of slots is used.
o FFS: if xOverhead is separately configured from the one in Rel-15/16.
FFS: impacts and further details if repetitions of TBoMS is supported.
FFS: whether the symbols allocated over which the TBoMS transmission is allocated are the same or can be different from the symbols over which the TBoMS transmission is performed.
R1-2101522 Joint Channel Estimation for PUSCH Ericsson
Proposals:
· Further study the benefit of gNB estimated inter-slot relative phase correction for PUSCH, addressing how frequency selective such phase corrections would need to be for UEs and/or conditions that do not sufficiently support maintaining inter-slot relative phase.
· Consider operation with and without frequency hopping or multiantenna transmission such as UL MIMO or transparent transmit diversity.
· Identify which mechanisms should be specified and which can be gNB implementation to support phase coherence across slots with multiple repetitions.
Decision: The document is noted.
R1-2100097 Discussion on joint channel estimation for PUSCH ZTE
R1-2101778 Joint channel estimation for PUSCH OPPO (rev of R1-2100174)
R1-2100233 Discussion on Joint channel estimation for PUSCH Huawei, HiSilicon
R1-2100399 Discussion on joint channel estimation for PUSCH CATT
R1-2100459 Discussion on Joint channel estimation for PUSCH vivo
R1-2100558 Potential techniques for PUSCH coverage enhancement Potevio Company Limited
R1-2100667 Discussion on joint channel estimation for PUSCH Intel Corporation
R1-2100714 Discussions on joint channel estimation for PUSCH LG Electronics
R1-2100733 Discussions on joint channel estimation for PUSCH InterDigital, Inc.
R1-2100797 Considerations on joint channel estimation over multi-PUSCH Spreadtrum Communications
R1-2100917 Discussion on joint channel estimation for PUSCH China Telecom
R1-2101003 Enhancements for DM-RS bundling for multiple PUSCH Lenovo, Motorola Mobility
R1-2101020 Discussion on joint channel estimation for PUSCH Panasonic Corporation
R1-2101057 Discussion on joint channel estimation for PUSCH CMCC
R1-2101223 Joint channel estimation for PUSCH Samsung
R1-2101329 Design Considerations for Joint channel estimation for PUSCH Sierra Wireless, S.A.
R1-2101397 Discussion on joint channel estimation for PUSCH Apple
R1-2101479 Joint channel estimation for PUSCH Qualcomm Incorporated
R1-2101547 Joint channel estimation for PUSCH Sharp
R1-2101643 Joint channel estimation for PUSCH NTT DOCOMO, INC.
R1-2101681 Discussion on joint channel estimation for PUSCH WILUS Inc.
R1-2101712 Joint channel estimation for PUSCH coverage enhancements Nokia, Nokia Shanghai Bell
[104-e-NR-CovEnh-03] – Jianchi (China Telecom)
Email discussion on joint channel estimation for PUSCH
- 1st check point: Jan 28
- 2nd check point: Feb 2
- 3rd check point: Feb 4
R1-2102161 [104-e-NR-CovEnh-03] Summary of email discussion on joint channel estimation for PUSCH Moderator (China Telecom)
Agreements:
· Following potential use cases are considered for joint channel estimation for PUSCH:
o Use case 1: back-to-back PUSCH transmissions within one slot.
o Use case 2: non-back-to-back PUSCH transmissions within one slot.
o Use case 3: back-to-back PUSCH transmissions across consecutive slots.
o Use case 4: non-back-to-back PUSCH transmissions across consecutive slots.
o Use case 5: PUSCH transmissions across non-consecutive slots.
Note: RAN1 assumes “back-to-back PUSCH transmission” has zero gap in-between adjacent PUSCH transmissions.
Agreements:
· For back-to-back PUSCH transmissions across consecutive slots, support necessary design aspects (under the condition of power consistency and phase continuity) to enable joint channel estimation at least for the following case:
o Over back-to-back PUSCH transmissions (of the same TB) for repetition type A scheduled by dynamic grant or configured grant
o FFS details (including possible other cases)
Agreements:
· For joint channel estimation, a time domain window is introduced to facilitate further discussion, during which UE is expected to maintain power consistency and phase continuity among PUSCH transmissions subject to power consistency and phase continuity requirements.
o FFS: whether the window should be specified
o FFS: the length of the time domain window is defined by a set of repetitions/slots/symbols
o FFS: single or multiple time domain windows
o FFS: relation with UE capability
o FFS: the time domain window may or may not be configured
o FFS: whether the term "time domain window" is used in the specification or replaced by other technical terms
o FFS: Whether the window is determined by the power consistency and phase continuity requirements and/or by other factors is to be decided.
Agreements:
· Companies are encouraged to study optimization of DMRS granularity in time domain with joint channel estimation, including:
o Use cases
o Simulations results
o Enhanced schemes, e.g.,
§ Different DMRS density for different PUSCH transmissions
§ No DMRS for some PUSCH transmissions
o If applicable, impact of dynamic changes, e.g., cancellation of a repetition and companies report the evaluation method.
· Companies are encouraged to study optimization of DMRS location in time domain with joint channel estimation, including:
o Use cases
o Simulations results
o Enhanced schemes, e.g.,
§ DMRS equally spaced among PUSCH transmissions
§ DMRS located in special slots
§ Orphan symbol used for DMRS
o If applicable, impact of dynamic changes, e.g., cancellation of a repetition and companies report the evaluation method.
· Note: the simulation assumptions for DM-RS in TR 38.830 are used as baseline for performance evaluation on optimization of DMRS location/granularity in time domain.
o Take into account impairments such as frequency offset, and report corresponding parametrization together with the results. Further discuss impairment details.
Working assumption:
· For back-to-back PUSCH transmissions across consecutive slots, support necessary design aspects (under the condition of power consistency and phase continuity) to enable joint channel estimation for the following case:
o Over back-to-back PUSCH transmissions for one TB processed over multiple slots
§ It’s subject to UE capability
Decision: As per email posted on Feb 5th,
Agreements:
Including dynamic PUCCH repetition factor indication and DMRS bundling across PUCCH repetitions
R1-2100460 Discussion on PUCCH enhancements vivo
· Proposal 1: The PUCCH repetition can be configured on PUCCH resource instead of PUCCH format, and the explicit indication of PUCCH repetition can be realized by indication of PUCCH resource with different repetition number through PRI.
· Proposal 2: UE can report capability on whether UE can ensure phase continuity for UL transmission across multiple occasions, and how long UE can maintain the phase continuity.
· Proposal 3: PUCCH repetitions with DMRS bundling may be interrupted by other transmissions/procedures, and whether and how to ensure phase continuity in these cases should be further studied. The interruptions can be caused in the following cases
o PUCCH transmissions is cancelled by SFI, CI or higher priority transmissions,
o UL transmission in another serving cell, when intra band CA is configured.
· Proposal 4: DMRS bundling size can be determined implicitly, and frame structure should be considered for DMRS bundling size determination in TDD spectrum.
· Proposal 5: Inter-slot frequency hopping with DMRS bundling can be considered for PUCCH repetition.
· Proposal 6: Frequency hopping granularity for PUCCH repetition can be the same as DMRS bundling size, which can also be determined implicitly taking the frame structure into consideration.
Decision: The document is noted.
R1-2101224 PUCCH enhancements Samsung
· Proposal 1: Support dynamic adjustments for a number of repetitions for a PUCCH transmission. Consider adjustments based on Rel-15 power adjustments according to UCI payload and number of symbols per slot and/or based on explicit/implicit indication by a DCI format.
· Proposal 2: Support configuration of different sets of numbers of repetitions to reduce the number of DCI bits needed to indicate the number of repetitions.
· Proposal 3: Support configuration of different sets of numbers of repetitions associated with different coverage levels, or different maximum UCI payload sizes or different maximum numbers of symbols per repetition.
· Proposal 4: The maximum number of repetitions for transmission of PUCCH repetition is 32.
Decision: The document is noted.
R1-2100098 Discussion on coverage enhancements for PUCCH ZTE
R1-2100175 PUCCH enhancements for coverage OPPO
R1-2100198 PUCCH coverage enhancement Huawei, HiSilicon
R1-2100400 Discussion on PUCCH enhancements CATT
R1-2100668 Discussion on PUCCH enhancements Intel Corporation
R1-2100715 Discussions on coverage enhancement for PUCCH LG Electronics
R1-2100747 Discussions on PUCCH enhancements InterDigital, Inc.
R1-2100798 Considerations on PUCCH coverage enhancement Spreadtrum Communications
R1-2100918 Discussion on PUCCH enhancements China Telecom
R1-2101021 Discussion on PUCCH enhancement for NR coverage enhancement Panasonic Corporation
R1-2101058 Discussion on PUCCH enhancements CMCC
R1-2101081 PUCCH enhancements ETRI
R1-2101129 PUCCH enhancement Xiaomi
R1-2101398 PUCCH coverage enhancement Apple
R1-2101480 PUCCH coverage enhancements Qualcomm Incorporated
R1-2101523 PUCCH Dynamic Repetition and DMRS Bundling Ericsson
R1-2101548 Dynamic PUCCH repetition factor indication Sharp
R1-2101576 Enhancements for PUCCH repetition Lenovo, Motorola Mobility
R1-2101626 PUCCH enhancements for coverage enhancements NTT DOCOMO, INC.
R1-2101682 Discussion on PUCCH enhancements for coverage enhancement WILUS Inc.
R1-2101713 PUCCH coverage enhancements Nokia, Nokia Shanghai Bell
[104-e-NR-CovEnh-04] – Yi (Qualcomm)
Email discussion on PUCCH enhancements
- 1st check point: Jan 28
- 2nd check point: Feb 2
- 3rd check point: Feb 4
R1-2101813 FL summary of PUCCH coverage enhancement Moderator (Qualcomm)
From GTW sessions:
Agreements: Down select from the following two options to support dynamic PUCCH repetition factor indication.
· Option 1 (without DCI enhancement): Enhance RRC signaling to allow configuration of PUCCH repetition factor per PUCCH resource. PUCCH repetition factor is implicitly indicated by DCI.
o FFS details, e.g., via reusing the “PUCCH resource indicator” field (without increase # bits of it), starting CCE index (when applicable) of DCI, by PDCCH aggregation level, etc.
o FFS: RRC signaling enhancement details
· Option 2 (with DCI enhancement): PUCCH repetition factor is explicitly indicated by DCI
o e.g., introduce a new field or increase the number of bits of an existing field (e.g., PRI) in DCI for PUCCH repetition factor indication
o FFS whether there is a need for RRC update
Agreements: Subject to the prerequisite of DMRS bundling for PUCCH repetitions, enhance inter-slot frequency hopping pattern for PUCCH repetitions with DMRS bundling.
· FFS: details in inter-slot frequency hopping pattern enhancement, e.g., additional frequency hopping patterns than Rel-16.
· Strive for common design for PUSCH/PUCCH with DMRS bundling as much as possible
Decision: As per email posted on Jan 31st,
Agreements:
Subject to the prerequisites of DMRS bundling for PUCCH repetitions, support enabling PUCCH repetitions with DMRS bundling via RRC configuration.
· FFS: whether additional dynamic signaling is needed to enable/disable PUCCH repetitions with DMRS bundling
From GTW sessions:
Conclusion: In Rel-17, deprioritize the study of DMRS pattern/location/granularity optimization for PUCCH coverage enhancement in AI 8.8.2. This conclusion could be revisited after the progress on the study of DMRS pattern/location/granularity optimization for PUSCH coverage enhancement in AI 8.8.1.3.
Conclusion: For the study of enhancing inter-slot frequency hopping pattern for PUCCH repetitions with DMRS bundling, at least the following aspects can be considered:
· Performance tradeoff between maximizing # consecutive UL slots in one frequency hop (to achieve more DMRS bundling gain) and maximizing # hops (to achieve more diversity gain)
o Note: the maximum # frequency hopping positions
is still 2 as in Rel-15/16., which is signaled by startingPRB and secondHopPRB
· Interaction between hopping boundary determination and TDD configuration
Conclusion: For the simulations to study the enhancement of inter-slot frequency hopping pattern for PUCCH repetitions with DMRS bundling, simulation assumptions in 38.830 are reused as a starting point.
Note: Additional simulation scenarios/assumptions are not precluded.
R1-2100099 Discussion on support of Type A PUSCH repetitions for Msg3 ZTE
· Proposal 1: Support to use MAC RAR or fallbackRAR for repetition indication for Msg3 initial transmission.
· Proposal 2: Support to use DCI format 0_0 with CRC scrambled by TC-RNTI for repetition indication for Msg3 re-transmission.
· Proposal 3: Support inter-slot frequency hopping for Msg3 repetition.
o FFS the relate signaling and hopping pattern by taking cross-slot channel estimation into account.
· Proposal 4: For RV determination for Msg3 repetition,
o FFS whether to use a fixed or dynamically indicated RV pattern for Msg3 initial transmission.
o The RV for each repetition of Msg3 re-transmission is based on RV cycling pattern {0, 2, 3, 1} with the RV index for the first repetition indicated by DCI format 0_0 scrambled by TC-RNTI.
· Proposal 5: The enhancements on PUSCH repetition type A specified for regular PUSCH are supported for Msg3 repetition.
· Proposal 6: Do not consider TB processing over multi-slot PUSCH for Msg3 repetition.
· Proposal 7: Support joint channel estimation for Msg3 repetition.
o Inter-slot frequency hopping with inter-slot bundling to enable joint channel estimation is supported.
· Proposal 8: Support to use separate PRACH transmission (e.g., via separate initial UL BWP, separate PRACH resource, or PRACH preamble) for differentiation between legacy UEs and Rel-17 CE UEs supporting Msg3 enhancements.
· Proposal 9: No differentiation between Rel-17 CE UEs and Redcap UEs before Msg3 transmission can be considered.
Decision: The document is noted.
R1-2100176 Type A PUSCH repetitions for Msg3 coverage OPPO
R1-2100197 Msg3 repetition for coverage enhancement Huawei, HiSilicon
R1-2100401 Discussion on Type A PUSCH repetitions for Msg3 CATT
R1-2100461 Discussion on Type A PUSCH repetitions for Msg3 vivo
R1-2100490 Target of PUSCH Msg.3 coverage enhancements SoftBank Corp.
R1-2100669 On Msg3 PUSCH repetition Intel Corporation
R1-2100716 Discussion on coverage enhancement for Msg3 PUSCH LG Electronics
R1-2100748 Type A PUSCH repetitions for Msg3 InterDigital, Inc.
R1-2100919 Discussion on type A PUSCH repetitions for Msg3 China Telecom
R1-2100944 Discussion on PUSCH repetitions for Msg3 NEC
R1-2101022 Discussion on Type A PUSCH repetitions for Msg.3 Panasonic Corporation
R1-2101059 Discussion on type A PUSCH repetitions for Msg3 CMCC
R1-2101082 PUSCH coverage enhancement ETRI
R1-2101130 Type A PUSCH repetitions for Msg3 Xiaomi
R1-2101225 Type A PUSCH repetitions for Msg3 Samsung
R1-2101399 Discussion on msg3 PUSCH repetition Apple
R1-2101481 Type A PUSCH repetition for Msg3 Qualcomm Incorporated
R1-2101524 Type A PUSCH Repetition for Msg3 Ericsson
R1-2101549 Type A PUSCH repetitions for Msg3 Sharp
R1-2101627 Type A PUSCH repetitions for Msg3 for coverage enhancements NTT DOCOMO, INC.
R1-2101683 Discussion on Type A PUSCH repetitions for Msg3 WILUS Inc.
R1-2101714 Approaches and solutions for Type A PUSCH repetitions for Msg3 Nokia, Nokia Shanghai Bell
[104-e-NR-CovEnh-05] – Xianghui (ZTE)
Email discussion on type A PUSCH repetitions for Msg 3
- 1st check point: Jan 28
- 2nd check point: Feb 2
- 3rd check point: Feb 4
R1-2102226 Feature lead summary on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
Decision: As per email posted on Jan 31st,
Agreements:
· For indication of the number of repetitions for Msg3 initial transmission, down-select one option from the options below.
o Option1: UL grant scheduling Msg3.
§ FFS details.
§ FFS fallbackRAR UL grant.
§ Note: Optimization specific for fallbackRAR UL grant in 2-step RACH is not considered in Rel-17 CovEnh WI, if supported.
o Option2: DCI format 1_0 with CRC scrambled by RA-RNTI
§ FFS details.
o Option3: SIB1 only
· Any modifications of RAR UL grant or DCI format 1_0 with CRC scrambled by RA-RNTI for indicating Msg3 repetitions shall not impact the legacy UE interpretation of the RAR or DCI format 1_0 with CRC scrambled by RA-RNTI respectively
Agreements:
· For indication of the number of repetitions for Msg3 re-transmission, down-select one option from the options below.
o Option1: DCI format 0_0 with CRC scrambled by TC-RNTI.
§ FFS details.
§ Any modifications of DCI format 0_0 with CRC scrambled by TC-RNTI for indicating Msg3 repetitions shall not impact the legacy UE interpretation of the DCI format 0_0 with CRC scrambled by TC-RNTI.
o Option2: Can be determined based on the repetition number for Msg3 initial transmission
Agreements:
Support inter-slot frequency hopping for repetition of Msg3 initial and re-transmission.
· FFS details, e.g., signaling etc.
Agreements:
For Msg3 PUSCH repetition, the following options are considered, aiming for down-selection in RAN1#104b-e:
· Option 1-1: For gNB scheduled Msg3 PUSCH repetition without UE request,
o A UE indicates to support of Msg3 PUSCH repetition via separate PRACH occasion or separate PRACH preamble in case of shared PRACH occasions.
o For a UE supporting Msg3 PUSCH repetition, gNB decides whether to schedule Msg3 PUSCH repetition or not. If scheduled, gNB decides the number of repetitions.
o FFS details if any.
· Option 1-2: For gNB scheduled Msg3 PUSCH repetition without UE request,
o gNB decides whether to schedule Msg3 PUSCH repetition or not. If scheduled, gNB decides the number of repetitions.
§ For UE does not support Msg3 PUSCH repetition, UE transmits Msg3 PUSCH without repetition
§ For UE does support Msg3 PUSCH repetition, UE transmits Msg3 PUSCH with repetition as indicated by gNB and UE uses, e.g., separate DMRS configuration or UCI multiplexing with Msg3 PUSCH (or other ways)
· Note: e.g., this can be for differentiation between UEs not supporting Msg3 PUSCH repetition and Rel-17 CE UEs supporting Msg3 PUSCH repetition or between RACH procedure with Msg3 PUSCH repetition and Msg3 PUSCH without repetition, etc.
o gNB blindly decodes Msg3 PUSCH with two different assumptions, w/ and w/o repetition.
o FFS details if any.
· Option 2-1: For UE triggered Msg3 PUSCH repetition with gNB indicating the number of repetitions,
o A UE can trigger RACH procedure with Msg3 PUSCH repetition via separate PRACH occasion or separate PRACH preamble in case of shared PRACH occasions.
§ Whether a UE would trigger is based on some conditions, e.g., measured SS-RSRP threshold, which may or may not have spec impact.
o If Msg3 PUSCH repetition is triggered by UE, gNB decides the number of repetitions for Msg3 PUSCH 3 (re)-transmission.
o FFS details if any.
· Option 2-2: For UE triggered Msg3 PUSCH repetition with gNB indicating the number of repetitions,
o gNB decides whether to schedule Msg3 PUSCH repetition or not. If scheduled, gNB decides the number of repetitions.
o If Msg3 PUSCH repetition is scheduled, UE transmits Msg3 PUSCH with or without repetition. If UE transmits Msg3 PUSCH repetition, the number of repetition follows the indication of gNB and UE uses e.g., separate DMRS configuration or UCI multiplexing with Msg3 PUSCH (or other ways)
§ Whether a UE would trigger is based on some conditions, e.g., measured SS-RSRP threshold, which may or may not have spec impact.
o FFS details if any.
· Other options are not precluded.
R1-2100100 Discussion on PUSCH and Msg3 enhancements for Redcap UEs ZTE
R1-2100177 Other considerations for coverage enhancement OPPO
R1-2100402 Views on reusing PUSCH enhancements for Msg3 CATT
R1-2100462 Enhanced Contention resolution mechanism for CBRA procedure with MSG3 PUSCH repetition vivo
R1-2100749 Discussion on the number of HARQ processes for VoIP InterDigital, Inc.
R1-2100868 Association of dual polarized SSBs Sony
R1-2101226 Discussion on PRACH enhancements for msg3 improvement Samsung
R1-2101253 Views on handling potential overlaps with other WIs Huawei, HiSilicon
R1-2101525 Other Coverage Enhancements for PUSCH Ericsson
R1-2101715 On the scope of RAN1 LS on phase and power requirements for joint channel estimation/DM-RS bundling of PUSCH and PUCCH Nokia, Nokia Shanghai Bell
Please refer to RP-210855 for detailed scope of the WI
//From AI5
[104b-e-NR-R17-CovEnh-LS-01] - Yi (Qualcomm)
R1-2102298 Reply LS on PUCCH and PUSCH repetition RAN4, Qualcomm
Reply LS to R1-2102298 for email discussion/approval till 4/16
R1-2104119 Reply LS on PUCCH and PUSCH repetition RAN1, Qualcomm
Decision: As per email decision posted on April 20th, the LS is approved.
Void (not be handled during this e-meeting). No contributions please.
The following is withdrawn.
R1-2103459 Design considerations for PUSCH repetition Type A Enhancements Sierra Wireless, S.A.
R1-2102314 Discussion on TB processing over multi-slot PUSCH Huawei, HiSilicon
R1-2102408 Issues for TB over multi-slot PUSCH OPPO
R1-2102498 Discussion on TB processing over multi-slot PUSCH ZTE
R1-2102535 Discussion on PUSCH TB processing over multiple slots vivo
R1-2102644 Discussion on TB processing over multi-slot PUSCH CATT
R1-2102691 Discussion on TB processing over multi-slot PUSCH MediaTek Inc.
R1-2102718 Views on TB processing over multi-slot PUSCH Fujitsu
R1-2102861 Discussion on TB processing over multi-slot PUSCH China Telecom
R1-2102894 Discussion on TB processing over multi-slot PUSCH CMCC
R1-2102913 On TB processing over multiple slots for PUSCH Indian Institute of Tech (H)
R1-2102993 TB processing over multi-slot PUSCH Xiaomi
R1-2103008 TB processing over multi-slot PUSCH InterDigital, Inc.
R1-2103043 Discussion on TB processing over multi-slot PUSCH Intel Corporation
R1-2103117 Discussion on TB processing over multi-slot PUSCH Apple
R1-2103179 TB processing over multi-slot PUSCH Qualcomm Incorporated
R1-2103208 Discussion on TB processing over multi-slot PUSCH Panasonic Corporation
R1-2103252 TB processing over multi-slot PUSCH Samsung
R1-2103381 Transport block processing for PUSCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2103445 TB Processing over Multi-Slot PUSCH Ericsson
R1-2103461 Design Considerations for TB Processing over Multi-Slot PUSCH Sierra Wireless, S.A.
R1-2103480 TB processing over multi-slot PUSCH Sharp
R1-2103514 Discussion on TB processing over multi-slot PUSCH NEC
R1-2103588 TB processing over multi-slot PUSCH NTT DOCOMO, INC.
R1-2103616 Enhancements for TB processing over multi-slot PUSCH Lenovo, Motorola Mobility
R1-2103625 Discussions on TB processing over multi-slot PUSCH LG Electronics
R1-2103700 Discussion on TB processing over multi-slot PUSCH WILUS Inc.
[104b-e-NR-R17-CovEnh-01] – Marco (Nokia)
Email discussion on TB processing over multi-slot PUSCH
- 1st check point: 4/15
- 2nd check point: 4/19
- 3rd check point: 4/20
R1-2103876 FL summary of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia)
Decision: As per email decision posted on April 16th,
Non-consecutive physical slots for UL transmission can be used to transmit TBoMS at least for unpaired spectrum.
From GTW session.
Working Assumption
The concept of transmission occasion for TBoMS (TOT) is utilized for the purpose of discussion, where a TOT is constituted of time domain resources which may or may not span multiple slots
· FFS: details, whether multiple slots which constitute a TOT are consecutive or non-consecutive physical slots for UL transmissions
· FFS: other details.
· FFS: whether such concept will be specified or not.
Agreements:
For the definition of a single TBoMS, down select among the following options:
· Option 1: Only one TOT is determined for a TBoMS. The TB is transmitted on the TOT using a single RV.
o FFS: whether and how the single RV is rate matched across the TOT, e.g., continuous rate-matching across the TOT, rate matched for each slot and so on.
· Option 2: Only one TOT is determined for a TBoMS. The TB is transmitted on the TOT using different RVs.
o FFS: how RV index is refreshed within the TOT, e.g. after each slot boundary, at every jump between two non-contiguous resources, if any, and so on.
· Option 3: Multiple TOTs are determined for a TBoMS. The TB is transmitted on the multiple TOTs using a single RV.
o FFS: how the single RV is rate matched across single or multiple TOTs, e.g., rate matched for each TOT, rate matched for all the TOTs, rate matched for each slot and so on.
· Option 4: Multiple TOTs are determined for a TBoMS. The TB is transmitted on the multiple TOTs using different RVs.
o FFS: whether and how RV index is refreshed within one TOT, e.g. after each slot boundary, at every jump between two non-contiguous resources, if any, and so on.
· FFS: the exact TBS determination procedure.
· FFS: whether a single TBoMS can be repeated or not.
· FFS: other implications, e.g., power control, collision handling and so on.
Final summary in R1-2104102
R1-2102313 Discussion on Joint channel estimation for PUSCH Huawei, HiSilicon
R1-2102409 Consideration on Joint channel estimation for PUSCH OPPO
R1-2102465 Consideration on joint channel estimation over multi-PUSCH Spreadtrum Communications
R1-2102499 Discussion on joint channel estimation for PUSCH ZTE
R1-2102536 Discussion on Joint channel estimation for PUSCH vivo
R1-2102645 Discussion on joint channel estimation for PUSCH CATT
R1-2102692 Discussion on joint channel estimation for PUSCH MediaTek Inc.
R1-2102862 Discussion on joint channel estimation for PUSCH China Telecom
R1-2102895 Discussion on joint channel estimation for PUSCH CMCC
R1-2102994 Joint channel estimation for PUSCH Xiaomi
R1-2103009 Discussions on joint channel estimation for PUSCH InterDigital, Inc.
R1-2103044 Discussion on joint channel estimation for PUSCH Intel Corporation
R1-2103118 Discussion on joint channel estimation for PUSCH Apple
R1-2103180 Joint channel estimation for PUSCH Qualcomm Incorporated
R1-2103253 Joint channel estimation for PUSCH Samsung
R1-2103312 UE configuration for enhanced JCE in TDD Sony
R1-2103382 Joint channel estimation for PUSCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2103446 Joint Channel Estimation for PUSCH Ericsson
R1-2103458 Discussion on joint channel estimation for PUSCH Panasonic Corporation
R1-2103460 Design Considerations for Joint channel estimation for PUSCH Sierra Wireless, S.A.
R1-2103481 Joint channel estimation for multi-slot PUSCH Sharp
R1-2103589 Joint channel estimation for PUSCH NTT DOCOMO, INC.
R1-2103617 Enhancements for joint channel estimation for multiple PUSCH Lenovo, Motorola Mobility
R1-2103626 Discussions on joint channel estimation for PUSCH LG Electronics
R1-2103701 Discussion on joint channel estimation for PUSCH WILUS Inc.
R1-2103808 FL Summary of joint channel estimation for PUSCH Moderator (China Telecom)
[104b-e-NR-R17-CovEnh-02] – Jianchi (China Telecom)
Email discussion on joint channel estimation for PUSCH
- 1st check point: 4/15
- 2nd check point: 4/19
- 3rd check point: 4/20
R1-2104006 [104b-e-NR-R17-CovEnh-02] Summary of email discussion on joint channel estimation for PUSCH Moderator (China Telecom)
Agreements:
· For joint channel estimation, specify a time domain window during which a UE is expected to maintain power consistency and phase continuity among PUSCH transmissions subject to power consistency and phase continuity requirements.
o FFS how the time domain window is determined (e.g., via explicit configuration and/or implicitly derived) and whether or not to have the possibility of enabling/disabling the time domain window
o FFS the units the time domain windown (e.g. repetitions, slots, and/or symbols)
§ FFS : association between the potential use case(s) and units of the time window
o FFS: single or multiple time domain windows
o FFS: relation with UE capability
o FFS: whether the term "time domain window" is used in the specification or replaced by other technical terms
o FFS whether or not to further consider impacting of timing advance
Decision: As per email decision posted on April 16th,
Agreement:
· A new DMRS pattern equally spaced among PUSCH transmissions is not considered for joint channel estimation in Rel-17.
Agreements:
Conclusion:
Agreements:
· For the time domain window for joint channel estimation, down select on the following two options:
o Option 1: The unit of the time domain window is defined separately for the following PUSCH transmissions:
§ PUSCH repetition type A
§ PUSCH repetition type B, if agreed
§ TBoMS, if agreed
§ Different TB, if agreed
o Option 2: The unit of the time domain window is the same for the following PUSCH transmission:
§ PUSCH repetition type A
§ PUSCH repetition type B, if agreed
§ TBoMS, if agreed
§ Different TB, if agreed
Agreement:
· For back-to-back PUSCH transmissions across consecutive slots, support necessary design aspects (under the condition of power consistency and phase continuity) to enable joint channel estimation for the following cases:
o Over back-to-back PUSCH transmissions (of the same TB) for repetition type B scheduled by dynamic grant or configured grant, if it reuses only those joint channel estimation specification enhancements defined to support repetition Type A.
§ FFS: additional specification enhancements on top of that defined to support repetition Type A
§ Only for single layer transmissions
§ Subject to UE capability
o FFS: Over back-to-back PUSCH transmissions with different TBs
Including dynamic PUCCH repetition factor indication, and DMRS bundling across PUCCH repetitions (When applicable, based on similar mechanism(s) for enabling joint channel estimation for PUSCH)
Void (not be handled during this e-meeting). No contributions please.
R1-2102315 Discussion on Msg3 repetition for coverage enhancement Huawei, HiSilicon
R1-2102410 Type A PUSCH repetitions for Msg3 coverage OPPO
R1-2102466 Discussion on type A PUSCH repetitions for Msg3 Spreadtrum Communications
R1-2102500 Discussion on support of Type A PUSCH repetitions for Msg3 ZTE
R1-2102537 Discussion on Type A PUSCH repetitions for Msg3 vivo
R1-2102646 Discussion on Type A PUSCH repetitions for Msg3 CATT
R1-2102863 Discussion on type A PUSCH repetitions for Msg3 China Telecom
R1-2103772 Discussion on type A PUSCH repetitions for Msg3 CMCC (rev of R1-2102896)
R1-2102995 Type A PUSCH repetition for Msg3 Xiaomi
R1-2103010 Type A PUSCH repetitions for Msg3 InterDigital, Inc.
R1-2103045 On Msg3 PUSCH repetition Intel Corporation
R1-2103119 Discussion on Msg3 Coverage Enhancement Apple
R1-2103181 Type A PUSCH repetition for Msg3 Qualcomm Incorporated
R1-2103209 Discussion on Type A PUSCH repetitions for Msg.3 Panasonic Corporation
R1-2103254 Type A PUSCH repetitions for Msg3 Samsung
R1-2103329 Type A PUSCH repetitions for Msg3 ETRI
R1-2103383 Approaches and solutions for Type A PUSCH repetitions for Msg3 Nokia, Nokia Shanghai Bell
R1-2103447 Type A PUSCH Repetition for Msg3 Ericsson
R1-2103482 Type A repetition for msg3 PUSCH Sharp
R1-2103515 Discussion on PUSCH repetitions for Msg3 NEC
R1-2103590 Type A PUSCH repetitions for Msg3 NTT DOCOMO, INC.
R1-2103618 Type A PUSCH repetition for Msg3 Lenovo, Motorola Mobility
R1-2103627 Discussion on coverage enhancement for Msg3 PUSCH LG Electronics
R1-2103702 Discussion on Type A PUSCH repetitions for Msg3 WILUS Inc.
[104b-e-NR-R17-CovEnh-03] – Xianghui (ZTE)
Email discussion on type A PUSCH repetitions for Msg 3
- 1st check point: 4/15
- 2nd check point: 4/19
- 3rd check point: 4/20
R1-2103829 Feature lead summary #1 on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
Agreement:
For Msg3 PUSCH repetition, support the following modified Option 2-1.
·
Option 2-1: For UE requested triggered Msg3
PUSCH repetition with gNB indicating the number of repetitions,
o A UE can request trigger RACH
procedure with Msg3 PUSCH
repetition via separate PRACH resources (FFS details, e.g.,
separate PRACH occasion or separate PRACH preamble in case of shared PRACH
occasions after SSB association, etc.).
§ Whether a UE would request trigger
is based on some conditions, e.g., measured
SS-RSRP threshold, which may or may not have spec impact.
o If Msg3 PUSCH repetition is requested triggered by UE,
gNB decides whether to schedule Msg3 PUSCH
repetition or not. If scheduled, gNB decides
the number of repetitions for Msg3 PUSCH 3 (re)-transmission.
o FFS the UE capability of supporting Msg3 PUSCH repetition can be reported after initial access procedure as usual
o FFS details if any.
Decision: As per email decision posted on April 16th,
Agreements: For the determination of RV for Msg3 PUSCH repetition,
Agreements: For indication of the number of repetitions for Msg3 initial transmission, Option 1 (i.e., using UL grant scheduling Msg3) is adopted.
Agreements: For indication of the number of repetitions for Msg3 re-transmission, Option 1 (i.e., using DCI format 0_0 with CRC scrambled by TC-RNTI) is adopted.
Working assumption:
The number of repetitions is counted on the basis of available slots for Type A PUSCH repetitions for Msg3.
· FFS: the determination of available slots.
Final summary in R1-2104101.
Void (not be handled during this e-meeting). No contributions please.
Please refer to RP-210855 for detailed scope of the WI
R1-2104240 Discussion on coverage enhancements for PUSCH repetition type A Huawei, HiSilicon
R1-2104291 Discussion on enhancements on PUSCH repetition Type A for low latency requirement NICT, TOYOTA MOTOR CORPORATION
R1-2104330 Discussion on enhanced PUSCH repetition type A ZTE
R1-2104376 Discussion on enhancement for PUSCH repetition type A vivo
R1-2104537 Discussion on enhancements on PUSCH repetition type A CATT
R1-2104625 Discussion on enhancements on PUSCH repetition type A CMCC
R1-2104685 Enhancements on PUSCH Repetition Type A Qualcomm Incorporated
R1-2104792 Enhancements on PUSCH repetition type A OPPO
R1-2104846 Enhancements on PUSCH repetition type A China Telecom
R1-2104859 Type-A PUSCH repetition for coverage enhancement InterDigital, Inc.
R1-2104919 Enhancements on PUSCH repetition type A Intel Corporation
R1-2105119 Discussion on PUSCH repetition type A enhancement Apple
R1-2105146 Discussion on enhancements on PUSCH repetition Type A Panasonic Corporation
R1-2105255 Discussion on PUSCH repetition type A NEC
R1-2105325 Enhancements on PUSCH repetition type A Samsung
R1-2105488 Discussions on PUSCH repetition type A enhancements LG Electronics
R1-2105511 Design considerations for PUSCH repetition Type A Enhancements Sierra Wireless, S.A.
R1-2105575 Enhancements on PUSCH repetition type A Xiaomi
R1-2105640 Enhancements on PUSCH repetition type A Sharp
R1-2105652 PUSCH Repetition Type A Enhancement Ericsson
R1-2105711 Enhancement on PUSCH repetition type A NTT DOCOMO, INC.
R1-2105773 Enhancements on PUSCH repetition type A Lenovo, Motorola Mobility
R1-2105877 Discussion on enhancements on PUSCH repetition type A WILUS Inc.
R1-2105901 Enhancements on PUSCH repetition type A Nokia, Nokia Shanghai Bell
[105-e-NR-R17-CovEnh-01] – Toshi (Sharp)
Email discussion regarding enhancements for PUSCH repetition type A
R1-2105992 FL Summary on Enhancements on PUSCH repetition type A Moderator (Sharp)
Decision: As per email decision posted on May 22nd,
Agreement:
· RV cycling is based on available slot for the Type A PUSCH repetition enhancement with repetitions counted based on available slot in Rel-17
R1-2106155 FL Summary#2 on Enhancements on PUSCH repetition type A Moderator (Sharp)
From GTW session:
Agreement:
· Down-selection in RAN1#106-e:
o Alt 1: The maximum number of repetitions supported by Rel-17 PUSCH repetition Type A is 32, irrespective of counting method,
o Alt 2: The maximum number of repetitions supported by Rel-17 PUSCH repetition Type A is: 32 for the counting based on physical slots; and 16 (i.e. no change from Rel-16) for the counting based on available slots.
Conclusion:
· The following agreement in RAN1#104-e is applied to all slots including special slots.
|
Agreements: For defining available slots: a slot is determined as unavailable if at least one of the symbols indicated by TDRA for a PUSCH in the slot overlaps with the symbol not intended for UL transmissions. · FFS details |
R1-2106199 FL Summary#3 on Enhancements on PUSCH repetition type A Moderator (Sharp)
From GTW session:
Agreement:
· In addition to {1, 2, 3, 4, 7, 8, 12, 16} and {32}, the following additional value set for repetition factor is supported in Rel-17.
o {20, 24, 28}
Agreement:
· Each available slot identified by the UE is considered as a transmission occasion for PUSCH repetition.
o RV is cycled across transmission occasions, irrespective of whether PUSCH transmission in the transmission occasion is further omitted or not.
Agreement:
· If PUSCH symbol in a slot overlaps with flexible symbol(s) with SSB transmission, the slot is determined as not available during the counting of repetitions. As there is no PUSCH in the slot, no PUSCH omission applies to the slot.
Agreement:
Select one from the following (further refinement of the alternatives can be further discussed), for the procedure of Rel-17 PUSCH repetition Type A (other alternatives are not precluded)
· Alt 1-B consisting of two steps
o Step 1: Determine available slots for K repetitions based on RRC configuration(s) in addition to TDRA in the DCI scheduling the PUSCH, CG configuration or activation DCI
o Step 2: The UE determines whether to drop a PUSCH repetition or not according to Rel-15/16 PUSCH dropping rules, but the PUSCH repetition is still counted in the K repetitions.
· Alt 1-B’ consisting of two steps
o Step 1: Determine K repetitions based on available slots, where the available slot is the UL slot and flexible slot indicated by tdd-UL-DL-ConfigurationCommon, or tdd-UL-DL-ConfigurationDedicated.
o Step 2: The UE determines whether to drop a PUSCH repetition or not according to Rel-15/16 PUSCH dropping rules, but the PUSCH repetition is still counted in the K repetitions.
o FFS: handling of dynamic signalling (e.g. UL CI, DCI for high priority channel), e.g., UE without CI capability
· Alt 2-A consisting of a single step
o Step 1: Determine available slots for K repetitions based on RRC configuration(s) and dynamic signalling (e.g. SFI, UL CI, DCI for high priority channel) in addition to TDRA in the DCI scheduling the PUSCH, CG configuration or activation DCI
· Alt 2-B consisting of two steps
o Step 1: Determine available slots for K repetitions based on RRC configuration(s) and dynamic SFI in addition to TDRA in the DCI scheduling the PUSCH, CG configuration or activation DCI
§ FFS timeline for the dynamic signalling
o Step 2: The UE determines whether to drop a PUSCH repetition or not according to Rel-15/16 PUSCH dropping rules, but the PUSCH repetition is still counted in the K repetitions.
Final summary in:
R1-2106279 FL Summary#4 on Enhancements on PUSCH repetition type A Moderator (Sharp)
R1-2104242 Discussion on TB processing over multi-slot PUSCH Huawei, HiSilicon
R1-2104297 On TB processing over multiple slots for PUSCH Indian Institute of Tech (H)
R1-2104331 Discussion on TB processing over multi-slot PUSCH ZTE
R1-2104377 Discussion on PUSCH TB processing over multiple slots vivo
R1-2104436 Discussion on TB processing over multi-slot PUSCH Spreadtrum Communications
R1-2104538 Discussion on TB processing over multi-slot PUSCH CATT
R1-2104626 Discussion on TB processing over multi-slot PUSCH CMCC
R1-2104686 TB processing over multi-slot PUSCH Qualcomm Incorporated
R1-2104793 Issues for TB over multi-slot PUSCH OPPO
R1-2104847 Discussion on TB processing over multi-slot PUSCH China Telecom
R1-2104860 TB processing over multiple slots InterDigital, Inc.
R1-2104920 Discussion on TB processing over multi-slot PUSCH Intel Corporation
R1-2105064 Views on TB processing over multi-slot PUSCH Fujitsu
R1-2105120 Discussion on TB processing over multi-slot PUSCH Apple
R1-2105147 Discussion on TB processing over multi-slot PUSCH Panasonic Corporation
R1-2105256 Discussion on TB processing over multi-slot PUSCH NEC
R1-2105326 TB processing over multi-slot PUSCH Samsung
R1-2105968 Discussion on TB processing over multi-slot PUSCH MediaTek Inc. (rev of R1-2105384)
R1-2105489 Discussions on TB processing over multi-slot PUSCH LG Electronics
R1-2105510 Design Considerations for TB processing over multi-slot PUSCH Sierra Wireless, S.A.
R1-2105576 Discussion on TB processing over multi-slot PUSCH Xiaomi
R1-2105641 TB processing over multi-slot PUSCH Sharp
R1-2105653 TB Processing over Multi-Slot PUSCH Ericsson
R1-2105712 TB processing over multi-slot PUSCH NTT DOCOMO, INC.
R1-2105774 Enhancements for TB processing over multi-slot PUSCH Lenovo, Motorola Mobility
R1-2105878 Discussion on TB processing over multi-slot PUSCH WILUS Inc.
R1-2105902 Transport block processing for PUSCH coverage enhancements Nokia, Nokia Shanghai Bell
[105-e-NR-R17-CovEnh-02] – Marco (Nokia)
Email discussion regarding TB processing over multi-slot PUSCH
R1-2105996 FL summary of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia)
From GTW session:
Working assumption: à Agreement:
For TBS determination of TBoMS:
· NohPRB is configured by xOverhead and represents the overhead per slot.
· NohPRB is assumed to be the same for all the slots over which the TBoMS transmission is allocated.
Note: xOverhead configuration is as per Rel-15/16.
Agreement:
The following 2 options for time domain resource determination for TBoMS are considered for down-selection during RAN1#105-e:
R1-2106250 FL summary#2 of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia)
From GTW session:
Working assumption
A transmission occasion for TBoMS (TOT) is constituted of at least one slot or multiple consecutive physical slots for UL transmission
· FFS: whether the concept of TOT will be used for designing aspects related to signal generation, e.g., rate-matching, power control, etc.
· FFS: whether such concept will be specified or not.
Agreement:
o Option 3, if a design based on single RV is adopted.
o Option 4, if a design based on different RVs is adopted.
Agreement:
Time domain resource determination for TBoMS can be performed only via PUSCH repetition Type A like TDRA.
Working assumption
Allocating resources for TBoMS in the special slot in TDD is possible according to the agreed time domain resource determination for TBoMS.
Agreement:
The following three options for rate-matching for TBoMS are considered for down-selection during RAN1 #106-e, where only one option will be selected:
· Option a: Rate-matching is performed per slot;
· Option b: Rate matching is performed continuously across all the allocated slot(s) per TOT;
· Option c: Rate matching is performed continuously across all the allocated slots/TOTs for TBoMS
Note: “rate-matching is performed per X” means that the time unit for the bit selection and bit interleaving is X.
Note2: the above 3 options imply that the UL resource in the time unit may or may not be consecutive (depending on the given option)
Agreement:
Number of slots allocated for TBoMS is determined by using a row index of a TDRA list, configured via RRC.
Agreement:
The following approach is used to calculate NInfo for TBoMS:
· Approach 2: Based on the number of REs determined in the first L symbols over which the TBoMS transmission is allocated, scaled by K≥1.
o FFS: the definition of K.
L is the number of symbols determined using the SLIV of PUSCH indicated via TDRA
FFS: impacts and further details if repetitions of TBoMS is supported.
FFS: whether the symbols over which the TBoMS transmission is allocated are the same or can be different from the symbols over which the TBoMS transmission is performed, and details on how to handle such scenarios.
Final summary in:
R1-2106251 Final FL summary of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia)
R1-2104241 Discussion on joint channel estimation for PUSCH Huawei, HiSilicon
R1-2104332 Discussion on joint channel estimation for PUSCH ZTE
R1-2104378 Discussion on Joint channel estimation for PUSCH vivo
R1-2104437 Discussion on joint channel estimation for PUSCH Spreadtrum Communications
R1-2104539 Discussion on joint channel estimation for PUSCH CATT
R1-2104627 Discussion on joint channel estimation for PUSCH CMCC
R1-2104687 Joint channel estimation for PUSCH Qualcomm Incorporated
R1-2104794 Consideration on Joint channel estimation for PUSCH OPPO
R1-2104848 Discussion on joint channel estimation for PUSCH China Telecom
R1-2104861 Joint channel estimation for PUSCH InterDigital, Inc.
R1-2104882 Discussion on joint channel estimation for PUSCH TCL Communication Ltd.
R1-2104921 Discussion on joint channel estimation for PUSCH Intel Corporation
R1-2105121 Discussion on joint channel estimation for PUSCH Apple
R1-2105176 Joint channel estimation for PUSCH Sony
R1-2105327 Joint channel estimation for PUSCH Samsung
R1-2105394 Discussion on joint channel estimation for PUSCH MediaTek Inc.
R1-2105397 Discussion on joint channel estimation for PUSCH Panasonic Corporation
R1-2105490 Discussions on joint channel estimation for PUSCH LG Electronics
R1-2105509 Design Considerations for Joint channel estimation for PUSCH Sierra Wireless, S.A.
R1-2105577 Joint channel estimation for PUSCH Xiaomi
R1-2105642 Joint channel estimation for multi-slot PUSCH Sharp
R1-2105654 Joint Channel Estimation for PUSCH Ericsson
R1-2105713 Joint channel estimation for PUSCH NTT DOCOMO, INC.
R1-2105775 Enhancements for joint channel estimation for multiple PUSCH Lenovo, Motorola Mobility
R1-2105879 Discussion on joint channel estimation for PUSCH WILUS Inc.
R1-2105903 Joint channel estimation for PUSCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2105979 FL Summary of joint channel estimation for PUSCH Moderator (China Telecom)
//Handled under NWM – See RAN1-105-e-NWM-NR-R17-CovEnh-03 as the document name
[105-e-NR-R17-CovEnh-03] – Jianchi (China Telecom)
Email discussion regarding joint channel estimation for PUSCH
R1-2106152 [105-e-NR-R17-CovEnh-03] Summary of email discussion on joint channel estimation for PUSCH Moderator (China Telecom)
Agreement:
· Joint channel estimation over non-back-to-back PUSCH transmissions within one slot is not supported.
Agreement:
· Definition of the maximum duration: a maximum time duration during which UE is able to maintain power consistency and phase continuity subject to power consistency and phase continuity requirements.
Agreement: Send LS to RAN4 asking the following questions
· For joint channel estimation, is there a maximum duration during which UE is able to maintain power consistency and phase continuity under certain tolerance level? If any, how long is it?
o What factors determine the maximum duration?
o Whether the maximum duration should be the same for different cases for both PUSCH and PUCCH?
o Whether the maximum duration is dependent on the modulation order of transmission, e.g., QPSK, 16QAM, 64QAM?
o Whether the maximum duration is dependent on UL waveform (DFT-s-OFDM vs. OFDM)?
o Whether the maximum duration is band specific?
o Besides the factors listed above, whether or not the maximum duration is further dependent on UE capabilities (e.g., multiple possible values for a given set of factor(s)), and if so, whether the UE should report such a duration
R1-2106212 LS on joint channel estimation for PUSCH and PUCCH RAN1, China Telecom
Decision: As per email decision posted on May 26th, the LS is approved.
Agreement:
· Optimization of DMRS granularity in time domain for PUSCH is not considered for joint channel estimation in Rel-17.
Agreement:
· For back-to-back PUSCH transmissions within one slot, support necessary design aspects (under the condition of power consistency and phase continuity) to enable joint channel estimation for the following cases:
o Over back-to-back PUSCH transmissions (of the same TB) for repetition type B scheduled by dynamic grant or configured grant, if it reuses only those joint channel estimation specification enhancements defined to support repetition Type A with consecutive slots
§ FFS: additional specification enhancements on top of that defined to support repetition Type A
§ Only for single layer transmissions
§ Subject to UE capability
· Joint channel estimation over back-to-back PUSCH transmissions with different TBs within one slot is not supported.
Working assumption:
· For non-back-to-back PUSCH transmissions (at least for the case of the same TB) across consecutive slots, support necessary design aspects (under the condition of power consistency and phase continuity) to enable joint channel estimation for the following cases:
o Over non-back-to-back PUSCH transmissions (of the same TB) for repetition type A scheduled by dynamic grant or configured grant.
o Over non-back-to-back PUSCH transmissions (of the same TB) for repetition type B scheduled by dynamic grant or configured grant, if it reuses only those joint channel estimation specification enhancements defined to support repetition Type A.
§ FFS: additional specification enhancements on top of that defined to support repetition Type A
§ Only for single layer transmissions
§ Subject to UE capability
o FFS: Over non-back-to-back PUSCH transmissions with different TBs
o FFS: Over non-back-to-back PUSCH transmissions for TBoMS
o For the non-back-to-back PUSCH transmissions, it is defined as at least when there is no UL transmission between the two successive PUSCH transmissions
o Subject to UE capability with details FFS (e.g., separate vs. joint capability for type A & type B, w.r.t. OFF power requirements, etc.)
· FFS: Joint channel estimation over non-back-to-back PUSCH transmissions with other uplink transmissions between the two successive PUSCH transmissions across consecutive slot.
Agreement:
· Joint channel estimation for PUSCH transmissions is enabled or disabled via RRC configuration for a UE
o FFS: whether additional dynamic signalling is needed to enable/disable joint channel estimation for PUSCH transmissions
o Note: the enabling of such a feature is subject to certain prerequisites
o FFS RRC parameter details (including explicit vs. implicit configuration)
· FFS For joint channel estimation for PUSCH, the time domain window is not explicitly enabled or disabled separately from joint channel estimation.
Note: Enabling/disabling of joint channel estimation for PUSCH transmissions means enabling/disabling of DMRS bundling for PUSCH transmissions under the condition of power consistency and phase continuity.
Agreement:
For joint channel estimation for PUSCH repetition type A of PUSCH repetitons of the same TB, down select one of the following alternatives for the time domain window.
· Alt 1: All the repetitions are covered by one single time domain window
o The start of the window is the first PUSCH transmission
o FFS: how to handle non-consecutive physical slots for UL transmission, e.g., due to DL/UL configuration for unpaired spectrum
o FFS: frequency hopping and precoder cycling
· Alt 2: All the repetitions are covered by one or multiple time domain windows
o For the start of each window,
§ The start of the first window is the first PUSCH transmission.
§ FFS: how to determine the start of other windows, e.g., whether multiple windows are consecutive or non-consecutive, whether the start of the window depends on DL/UL configuration for unpaired spectrum
o For the length of each window,
§ FFS Each window consists of at least two adjacent physical slots for UL transmission.
§ The length of each window is no longer than the maximum duration.
§ FFS: how to determine the length of each window
§ FFS: whether the length of each window depends on DL/UL configuration for unpaired spectrum
o FFS: how to handle non-consecutive physical slots for UL transmission, e.g., due to DL/UL configuration for unpaired spectrum.
o FFS: frequency hopping and precoder cycling
· Other alternatives are not precluded.
Final summary in R1-2106152.
Including dynamic PUCCH repetition factor indication, and DMRS bundling across PUCCH repetitions (When applicable, based on similar mechanism(s) for enabling joint channel estimation for PUSCH)
R1-2104243 Discussion on PUCCH coverage enhancement Huawei, HiSilicon
R1-2104333 Discussion on coverage enhancements for PUCCH ZTE
R1-2104379 Discussion on PUCCH enhancements vivo
R1-2104438 Discussion on PUCCH enhancements Spreadtrum Communications
R1-2104540 Discussion on PUCCH enhancement CATT
R1-2104628 Discussion on PUCCH enhancements CMCC
R1-2104688 PUCCH enhancements Qualcomm Incorporated
R1-2104795 PUCCH enhancements for coverage OPPO
R1-2104849 Discussion on PUCCH enhancements China Telecom
R1-2104862 Discussions on PUCCH enhancements InterDigital, Inc.
R1-2104922 Discussion on PUCCH enhancements Intel Corporation
R1-2105122 PUCCH coverage enhancement Apple
R1-2105149 Discussion on PUCCH enhancement for NR coverage enhancement Panasonic Corporation
R1-2105224 PUCCH enhancements ETRI
R1-2105257 Discussion on PUCCH enhancements NEC
R1-2105328 PUCCH enhancements Samsung
R1-2105491 Discussions on coverage enhancement for PUCCH LG Electronics
R1-2105578 PUCCH coverage enhancement Xiaomi
R1-2105643 PUCCH coverage enhancement Sharp
R1-2105655 PUCCH Dynamic Repetition and DMRS Bundling Ericsson
R1-2105714 PUCCH enhancements NTT DOCOMO, INC.
R1-2105776 Enhancements for PUCCH repetition Lenovo, Motorola Mobility
R1-2105904 PUCCH coverage enhancements Nokia, Nokia Shanghai Bell
[105-e-NR-R17-CovEnh-04] – Yi (Qualcomm)
Email discussion regarding PUCCH enhancements
R1-2106014 FL summary of PUCCH coverage enhancement Moderator (Qualcomm)
From GTW session:
Agreement:
For DMRS bundling for PUCCH repetitions, specify a time domain window during which a UE is expected to maintain power consistency and phase continuity among PUCCH repetitions subject to power consistency and phase continuity requirements.
· Strive for common design of the time domain window for PUSCH/PUCCH with DMRS bundling as much as possible.
R1-2106154 FL summary#2 of PUCCH coverage enhancement Moderator (Qualcomm)
From GTW session:
Working assumption: In Rel-17, for a PUCCH with associated scheduling DCI, support the following for dynamic PUCCH repetition factor indication.
· Enhance RRC signalling to allow configuration of PUCCH repetition factor per PUCCH resource. Reuse Rel-16 PUCCH resource indication mechanism based on “PUCCH resource indicator” (PRI) field and starting CCE index (when applicable based on Rel-16 spec) of DCI to indicate a PUCCH resource and its associated repetition factor.
o FFS: RRC signalling enhancement details
Conclusion:
For PUCCH repetitions, the following use cases are deprioritized in RAN1 work on PUCCH DMRS bundling
· Use case 1: back-to-back PUCCH repetitions within one slot.
· Use case 2: non-back-to-back PUCCH repetitions within one slot.
o Use case 2a: no uplink transmission in the middle of two PUCCH repetitions
o Use case 2b: other uplink transmissions in the middle of two PUCCH repetitions
R1-2104244 Msg3 repetition for coverage enhancement Huawei, HiSilicon
R1-2104334 Discussion on support of Type A PUSCH repetitions for Msg3 ZTE
R1-2104380 Discussion on Type A PUSCH repetitions for Msg3 vivo
R1-2104439 Discussion on type A PUSCH repetitions for Msg3 Spreadtrum Communications
R1-2104541 Discussion on Type A PUSCH repetitions for Msg3 CATT
R1-2104629 Discussion on type A PUSCH repetitions for Msg3 CMCC
R1-2104689 Type A PUSCH repetition for Msg3 Qualcomm Incorporated
R1-2104796 Type A PUSCH repetitions for Msg3 coverage OPPO
R1-2104850 Discussion on type A PUSCH repetitions for Msg3 China Telecom
R1-2104863 Type A PUSCH repetitions for Msg3 InterDigital, Inc.
R1-2104923 On Msg3 PUSCH repetition Intel Corporation
R1-2105123 Discussion on Msg3 Coverage Enhancement Apple
R1-2105150 Discussion on Type A PUSCH repetitions for Msg.3 Panasonic Corporation
R1-2105225 Type A PUSCH repetitions for Msg3 ETRI
R1-2105329 Type A PUSCH repetitions for Msg3 Samsung
R1-2105492 Discussion on coverage enhancement for Msg3 PUSCH LG Electronics
R1-2105579 Discussion on Type A PUSCH repetition for Msg3 Xiaomi
R1-2105644 Type A repetition for msg3 PUSCH Sharp
R1-2105656 Type A PUSCH Repetition for Msg3 Ericsson
R1-2105715 Type A PUSCH repetitions for Msg3 NTT DOCOMO, INC.
R1-2105777 Type A PUSCH repetitions for Msg3 Lenovo, Motorola Mobility
R1-2105880 Discussion on Type A PUSCH repetitions for Msg3 WILUS Inc.
R1-2105905 Approaches and solutions for Type A PUSCH repetitions for Msg3 Nokia, Nokia Shanghai Bell
[105-e-NR-R17-CovEnh-05] – Xianghui (ZTE)
Email discussion regarding Type A PUSCH repetitions for Msg 3
R1-2106007 Feature lead summary#1 on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
Decision: As per email decision posted on May 22nd,
Agreement:
A UE requests Msg3 PUSCH repetition at least when the RSRP of the downlink pathloss reference is lower than an RSRP threshold.
· FFS the determination of the RSRP threshold.
Agreement:
For repetition indication of Msg3 re-transmission, select one options from the following two options.
· Option 1: Use the same mechanism as supported for Msg3 initial transmission.
· Option2: Use HARQ process number bit field in DCI format 0_0 with CRC scrambled by TC-RNTI.
Agreement:
· Available slot for Msg3 PUSCH repetition does not depend on dynamic SFI in DCI format 2-0.
Agreement:
· Available slot for Msg3 PUSCH repetition does not depend on UL CI.
Agreement:
Use a fixed RV sequence [0 2 3 1] for repetition of Msg3 initial and re-transmission.
· The RV cycling for Msg3 initial transmission follows the rule specified in the first row in Table 6.1.2.1-2 in TS38.214.
· The RV cycling for Msg3 re-transmission follows the rules specified in Table 6.1.2.1-2 in TS38.214.
· FFS: The RV cycling for Msg3 is based on transmission occasions on available slot.
R1-2106008 Feature lead summary#2 on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
Agreement:
· For requesting Msg3 PUSCH repetition, support the following:
o Use separate preamble with shared RO configured by the same PRACH configuration index with legacy UEs.
§ FFS whether to introduce a PRACH mask to indicate a sub-set of ROs associated with a same SSB index within an SSB-RO mapping cycle for requesting Msg3 repetition for a UE.
§ FFS definition of shared RO (e.g., whether the shared RO can be an RO with preamble(s) for 4-step RACH only or with preambles for both 4-step RACH and 2-step RACH).
o FFS whether or not to additionally support one (& only one) more option:
§ E.g., option 2: Use separate RO configured by a separate PRACH configuration index from legacy UEs
§ E.g., Option 3: Use separate RO, which include
· the separate RO configured by a separate RACH configuration index from legacy UE, and
· the remaining RO (if any) configured, by the same PRACH configuration index with legacy UEs, that cannot be used by legacy rules for PRACH transmission.
Agreement:
· Available slots for Msg3 PUSCH repetition do not depend on tdd-UL-DL-ConfigurationDedicated.
Agreement:
· Available slot for Msg3 PUSCH repetition depends on TDD-UL-DL-Configcommon.
o A slot is determined as available for Msg3 repetition only if the consecutive symbols allocated for Msg3 repetition in the slot are all available symbols.
§ UL symbols indicated by TDD-UL-DL-Configcommon are determined as available for Msg3 repetition.
§ FFS whether and how to use flexible symbols indicated by TDD-UL-DL-Configcommon.
Working assumption:
· The total size of RAR UL grant does not change.
· Position of all fields in the bit sequence of the RAR UL grant does not change, regardless of whether they are repurposed or not.
· FFS details, e.g., TDRA table selection, or whether/how to indicate which interpretation UE should use for the repurposed information field (legacy vs repurposed interpretation) etc.
Conclusion:
Final summary in:
R1-2106247 Final feature lead summary on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
R1-2104335 Performance impacts of residual frequency error for joint channel estimation of PUSCH and PUCCH transmissions ZTE
R1-2104381 Enhanced Contention resolution mechanism for CBRA procedure with MSG3 PUSCH repetition vivo
R1-2104542 Views on reusing PUSCH enhancements for Msg3 CATT
R1-2104797 Other considerations for coverage enhancement OPPO
R1-2104864 Deterministic PUSCH repetition for coverage enhancements InterDigital, Inc.
R1-2105330 Discussion on PRACH enhancements for msg3 beam improvement Samsung
R1-2105523 Other issues for coverage enhancement Huawei, HiSilicon
R1-2105657 Other Coverage Enhancements for PUSCH Ericsson
R1-2105906 Implications of DMRS bundling for PUSCH and PUCCH Nokia, Nokia Shanghai Bell
Please refer to RP-211566 for detailed scope of the WI
R1-2108608 Session notes for 8.8 (NR coverage enhancement) Ad-hoc Chair (CMCC)
//From AI5
//Handled under NWM – See RAN1-106-e-NWM-NR-R17-CovEnh-LS-01 as the document name
[106-e-NR-R17-CovEnh-LS-01] – Yi (Qualcomm)
Email discussion/approval for the reply LS to R1-2106423 by August 20th.
As per email decision posted on Aug 21st, the following is endorsed:
-------------------------------------------------------------------------------------------------------------------------------------------------------------
1. Overall Description:
In LS R1-2106423 (R4-2107880), RAN1 received the following question from RAN4.
RAN4 also asks RAN1 to provide more information on the scenario when “downlink reception” from UE point of view includes downlink symbols without actual DL transmission from gNB to UE and UE is not assumed to do DL monitoring?
RAN1 has discussed the issues raised in this question and would like to provide the following answers to RAN4.
In RAN1 understanding, regarding to the “downlink reception”, there are actually three scenarios:
For scenario 1, one example is that PDSCH is actually transmitted on DL symbols. For scenario 2, one example is that a PDCCH monitoring occasion is configured, but gNB does not send PDCCH actually on the PDCCH monitoring occasion. For scenario 3, one example is that some symbols are indicated (e.g., by tdd-UL-DL-ConfigurationCommon) as DL symbols, but neither PDCCH monitoring occasion is configured nor PDSCH is transmitted on those DL symbols.
RAN1 understand that, the “downlink reception” in RAN4 reply LS R4-2103393 covers scenario 1 and scenario 2 already. The question “whether ‘downlink reception’ include downlink symbols without actual DL transmission from gNB to UE and without DL monitoring” that RAN1 asking to RAN4 in R1-2104119 simply means the following
·
In additional to scenario 1 and 2,
does the “downlink reception” in RAN4 reply LS R4-2103393 (“No downlink
reception in-between the PUSCH or PUCCH repetition in the same band for TDD
case”) further include scenario 3? the above scenario 2, or
scenario 3, or both scenario 2 and 3?
[Besides
the above, RAN1 also like to clarify that any DL measurement that a UE needs to
perform is also included in “downlink reception” under scenario 1.]
2. Actions:
RAN1 respectfully asks RAN4 to take the above information into account in their work on NR coverage enhancement.
RAN1 respectfully asks RAN4 to provide answers to the following question.
·
Question 1: In additional to
scenario 1 and 2, does the “downlink reception” in RAN4 reply LS R4-2103393
(“No downlink reception in-between the PUSCH or PUCCH repetition in the same
band for TDD case”) further include scenario 3? the above
scenario 2, or scenario 3, or both scenario 2 and 3?
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Final LS is approved in
R1-2108458 Reply LS on PUCCH and PUSCH repetition RAN1, Qualcomm
R1-2106495 Discussion on coverage enhancements for PUSCH repetition type A Huawei, HiSilicon
R1-2106611 Discussion on enhancement for PUSCH repetition type A vivo
R1-2106655 Enhancements on PUSCH repetition type A Nokia, Nokia Shanghai Bell
R1-2106739 Discussion on enhanced PUSCH repetition type A ZTE
R1-2106902 Enhancements on PUSCH repetition type A Samsung
R1-2106988 Discussion on enhancements on PUSCH repetition type A CATT
R1-2107116 Discussion on enhancements on PUSCH repetition Type A Panasonic Corporation
R1-2107121 Discussion on enhancements on PUSCH repetition type A Rakuten Mobile, Inc
R1-2107123 Enhancements on PUSCH repetition type A China Telecom
R1-2107140 Discussion on PUSCH repetition type A NEC
R1-2107190 Enhancements on PUSCH repetition type A Lenovo, Motorola Mobility
R1-2107256 Enhancements on PUSCH repetition type A OPPO
R1-2107359 Enhancements on PUSCH Repetition Type A Qualcomm Incorporated
R1-2107417 Discussion on enhancements on PUSCH repetition type A CMCC
R1-2107548 Discussions on PUSCH repetition type A enhancements LG Electronics
R1-2107559 PUSCH Repetition Type A Enhancement Ericsson
R1-2107602 Enhancements on PUSCH repetition type A Intel Corporation
R1-2107634 Design considerations for PUSCH repetition Type A Enhancements Sierra Wireless, S.A.
R1-2107650 Type-A PUSCH repetition for coverage enhancement InterDigital, Inc.
R1-2107753 Discussion on PUSCH repetition type A enhancement Apple
R1-2107799 Enhancements on PUSCH repetition type A Sharp
R1-2107872 Enhancements on PUSCH repetition type A NTT DOCOMO, INC.
R1-2107935 Enhancements on PUSCH repetition type A Xiaomi
R1-2108157 Discussion on enhancements on PUSCH repetition type A WILUS Inc.
[106-e-NR-R17-CovEnh-01] – Toshi (Sharp)
Email discussion regarding enhancements for PUSCH repetition type A
R1-2108286 FL Summary #1 on Enhancements on PUSCH repetition type A Moderator (Sharp)
Agreement:
· For Rel-17 PUSCH repetition Type A without joint channel estimation, no new inter-slot frequency hopping mechanism is introduced.
R1-2108287 FL Summary #2 on Enhancements on PUSCH repetition type A Moderator (Sharp)
R1-2108462 FL Summary #3 on Enhancements on PUSCH repetition type A Moderator (Sharp)
Agreement:
Take Option 1-B as an agreement for the procedure of Rel-17 PUSCH repetitions counted on the basis of available slots.
· Alt 1-B consisting of two steps
o Step 1: Determine available slots for K repetitions based on RRC configuration(s) in addition to TDRA in the DCI scheduling the PUSCH, CG configuration or activation DCI
o Step 2: The UE determines whether to drop a PUSCH repetition or not according to Rel-15/16 PUSCH dropping rules, but the PUSCH repetition is still counted in the K repetitions.
· FFS: Rel-17 PUSCH dropping rules are also applied if introduced in other WI(s)
Agreement
For PUSCH repetition Type A for Rel-17 CG-PUSCH, semi-static flexible symbol is considered as available.
Agreement
For PUSCH repetition Type A for Rel-17 DG-PUSCH, semi-static flexible symbol is considered as available.
Note: The applicability for Msg 3 is to be discussed in 8.8.3
R1-2108463 FL Summary #4 on Enhancements on PUSCH repetition type A Moderator (Sharp)
R1-2108616 FL Summary #5 on Enhancements on PUSCH repetition type A Moderator (Sharp)
Agreement
· DCI format 0_1 and DCI format 0_2 support Rel-17 PUSCH repetition Type A with the increased maximum repetition numbers configured in TDRA lists.
Agreement
Working Assumption
The maximum number of repetitions accounted for available slots supported by Rel-17 PUSCH repetition Type A is 32
Final summary in R1-2108650.
R1-2106496 Discussion on TB processing over multi-slot PUSCH Huawei, HiSilicon
R1-2106612 Discussion on PUSCH TB processing over multiple slots vivo
R1-2106656 Transport block processing for PUSCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2106740 Discussion on TB processing over multi-slot PUSCH ZTE
R1-2106903 TB processing over multi-slot PUSCH Samsung
R1-2106989 Discussion on TB processing over multi-slot PUSCH CATT
R1-2107035 Views on TB processing over multi-slot PUSCH Fujitsu
R1-2107117 Discussion on TB processing over multi-slot PUSCH Panasonic Corporation
R1-2107124 Discussion on TB processing over multi-slot PUSCH China Telecom
R1-2107141 Discussion on TB processing over multi-slot PUSCH NEC
R1-2107191 Enhancements for TB processing over multi-slot PUSCH Lenovo, Motorola Mobility
R1-2107198 Discussion on TBoMS TCL Communication Ltd.
R1-2107257 Issues for TB over multi-slot PUSCH OPPO
R1-2107360 TB processing over multi-slot PUSCH Qualcomm Incorporated
R1-2107418 Discussion on TB processing over multi-slot PUSCH CMCC
R1-2107523 Discussion on TB processing over multi-slot PUSCH MediaTek Inc.
R1-2107549 Discussions on TB processing over multi-slot PUSCH LG Electronics
R1-2107560 TB Processing over Multi-Slot PUSCH Ericsson
R1-2107603 Discussion on TB processing over multi-slot PUSCH Intel Corporation
R1-2107635 Design Considerations for TB Processing over Multi-Slot PUSCH Sierra Wireless, S.A.
R1-2107651 TB processing over multiple slots InterDigital, Inc.
R1-2107754 Discussion on TB processing over multi-slot PUSCH Apple
R1-2107800 Transport block processing over multi-slot PUSCH Sharp
R1-2107873 TB processing over multi-slot PUSCH NTT DOCOMO, INC.
R1-2107936 Discussion on TB processing over multi-slot PUSCH Xiaomi
R1-2108158 Discussion on TB processing over multi-slot PUSCH WILUS Inc.
[106-e-NR-R17-CovEnh-02] – Marco (Nokia)
Email discussion regarding TB processing over multi-slot PUSCH
R1-2108253 FL summary of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia/Nokia Shanghai Bell)
From GTW session:
Agreement
The number of slots allocated for TBoMS is counted based on the available slots for UL transmission.
· The determination of available slots for PUSCH repetition type A, as defined in AI 8.8.1.1, is reused.
· Note: Available slots for FDD or SUL could be revisited according to discussion in AI 8.8.1.1
Agreement
Allocating resources for TBoMS in the special slot in TDD is possible according to the agreed time domain resource determination for TBoMS.
· No further optimization to allocate resources for TBoMS in the special slot is supported.
R1-2108544 FL summary #2 of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia)
Agreement
TBoMS is supported for both configured grant and dynamic grant.
Working Assumption
Single TBoMS structure of Option 3 is selected
· Option 3: Multiple TOTs are determined for a TBoMS. The TB is transmitted on the multiple TOTs using a single RV.
o FFS: how the single RV is rate matched across single or multiple TOTs, e.g., rate matched for each TOT, rate matched for all the TOTs, rate matched for each slot and so on.
Agreement
To
calculate 
for TBS determination, at least
the scaling factor value 
=N is supported, where N is the
number of allocated slots for a single TBoMS.
· FFS: whether further values 1<K<N are supported.
·
FFS: details related to the indication of .
· Note: No supporting the case K=1 for a single TBoMS.
Agreement
Repetitions of a single TBoMS are supported, where:
·
The number of configured repetitions
is denoted by M, i.e., the total number of allocated slots for TBoMS repetition
is M*N.
o Note: M*N is no more than the max number of repetitions agreed for repetition Type A enhancement in agenda 8.8.1.1
· Available slot determination is according to existing agreements.
· The number and location of allocated symbols within an allocated slot for TBoMS transmission are the same among all repeated single TBoMS.
· FFS other aspects of TBoMS repetitions, e.g.:
o Details of time domain resource indication.
o Supported values for the number of TBoMS repetitions.
o How to indicate the number of TBoMS repetitions.
o Interactions with frequency hopping and precoder cycling across the M groups of N allocated slots for each single TBoMS repetition.
o Whether RV indices should be cycled across the M groups of N allocated slots for each single TBoMS repetition.
o Details of TBoMS retransmissions.
o Potential MAC layer impact, but should be decided by RAN2
Note: No additional dropping rule optimization will be introduced other than dropping rules for single TBoMS transmission.
Conclusion
Bit interleaving performed per ToT is precluded, and ToT will not be used in further discussion.
Agreement
The UE determines whether or not to drop a slot determined as available for TBoMS transmission according to Rel-15/16 PUSCH dropping rules, where the dropped slot is still counted in the N allocated slots for the single TBoMS transmission.
FFS: Rel-17 PUSCH dropping rules are also applied if introduced in other WI(s)
Conclusion
The N allocated slots for the single TBoMS are defined as the number of slots after available slot determination for a single TBoMS transmission, before dropping rules are applied.
Note: the number of final transmitted slots for the single TBoMS may be lower than N, depending on dropping rules for TBoMS transmission.
R1-2108545 Final FL summary of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia)
R1-2106497 Discussion on joint channel estimation for PUSCH Huawei, HiSilicon
R1-2106613 Discussion on joint channel estimation for PUSCH vivo
R1-2106657 Joint channel estimation for PUSCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2106711 Discussion on joint channel estimation for PUSCH Spreadtrum Communications
R1-2106741 Discussion on joint channel estimation for PUSCH ZTE
R1-2106817 On joint channel estimation for PUSCH Sony
R1-2106904 Joint channel estimation for PUSCH Samsung
R1-2106990 Discussion on joint channel estimation for PUSCH CATT
R1-2107125 Discussion on joint channel estimation for PUSCH China Telecom
R1-2107192 Enhancements for joint channel estimation for multiple PUSCH Lenovo, Motorola Mobility
R1-2107199 Discussion on Joint channel estimation for PUSCH TCL Communication Ltd.
R1-2107258 Consideration on Joint channel estimation for PUSCH OPPO
R1-2107361 Joint channel estimation for PUSCH Qualcomm Incorporated
R1-2107419 Discussion on joint channel estimation for PUSCH CMCC
R1-2107524 Discussion on Joint channel estimation over multi-slot PUSCH MediaTek Inc.
R1-2107550 Discussions on joint channel estimation for PUSCH LG Electronics
R1-2107561 Joint Channel Estimation for PUSCH Ericsson
R1-2107604 Discussion on joint channel estimation for PUSCH Intel Corporation
R1-2107633 Design Considerations for Joint channel estimation for PUSCH Sierra Wireless, S.A.
R1-2107652 Joint channel estimation for PUSCH InterDigital, Inc.
R1-2107755 Discussion on joint channel estimation for PUSCH Apple
R1-2107801 Joint channel estimation for multiple PUSCH transmission Sharp
R1-2107832 Discussion on joint channel estimation for PUSCH Panasonic Corporation
R1-2107874 Joint channel estimation for PUSCH NTT DOCOMO, INC.
R1-2107937 Discussion on joint channel estimation for PUSCH Xiaomi
R1-2108159 Discussion on joint channel estimation for PUSCH WILUS Inc.
[106-e-NR-R17-CovEnh-03] – Jianchi (China Telecom)
Email discussion regarding joint channel estimation for PUSCH
R1-2108221 FL Summary of joint channel estimation for PUSCH Moderator (China Telecom)
R1-2108371 FL Summary#2 of joint channel estimation for PUSCH Moderator (China Telecom)
From GTW session:
Confirm the following working assumption
· For non-back-to-back PUSCH transmissions (at least for the case of the same TB) across consecutive slots, support necessary design aspects (under the condition of power consistency and phase continuity) to enable joint channel estimation for the following cases:
o Over non-back-to-back PUSCH transmissions (of the same TB) for repetition type A scheduled by dynamic grant or configured grant.
o Over non-back-to-back PUSCH transmissions (of the same TB) for repetition type B scheduled by dynamic grant or configured grant, if it reuses only those joint channel estimation specification enhancements defined to support repetition Type A.
§ FFS: additional specification enhancements on top of that defined to support repetition Type A
§ Only for single layer transmissions
§ Subject to UE capability
o FFS: Over non-back-to-back PUSCH transmissions with different TBs
o FFS: Over non-back-to-back PUSCH transmissions for TBoMS
o For the non-back-to-back PUSCH transmissions, it is defined as at least when there is no UL transmission between the two successive PUSCH transmissions
o Subject to UE capability with details FFS (e.g., separate vs. joint capability for type A & type B, w.r.t. OFF power requirements, etc.)
· FFS: Joint channel estimation over non-back-to-back PUSCH transmissions with other uplink transmissions between the two successive PUSCH transmissions across consecutive slot.
Conclusion
Optimization of DMRS location in time domain for PUSCH is not considered for joint channel estimation in Rel-17.
Agreement
· Joint channel estimation for PUSCH transmissions and the time domain window are jointly enabled or disabled via RRC configuration for a UE.
o Note: Enabling/disabling of joint channel estimation for PUSCH transmissions means enabling/disabling of DMRS bundling for PUSCH transmissions under the condition of power consistency and phase continuity.
Agreement
Make down-selection between the following two alternatives:
· Alt 1: UE is not expected to receive TPC commands during the current time domain window.
· Alt 2: UE receives and accumulates TPC commands without taking effect during the current time domain window.
R1-2108416 FL Summary#3 of joint channel estimation for PUSCH Moderator (China Telecom)
R1-2108503 FL Summary#4 of joint channel estimation for PUSCH Moderator (China Telecom)
R1-2108504 FL Summary#5 of joint channel estimation for PUSCH Moderator (China Telecom)
Agreement
· UE should not perform TA adjustment during the time domain window.
o FFS: UE does not expect to receive TA command to indicate TA adjustment during the TDW.
o FFS: UE ignores any TA command which indicates TA adjustment during the TDW.
o FFS: UE performs TA adjustment after the TDW if it receives any TA command indicating TA adjustment during the TDW.
Decision: As per email decision posted on Sep 1st,
Working assumption:
For joint channel estimation for PUSCH repetition type A of PUSCH repetitions of the same TB, all the repetitions are covered by one or multiple consecutive/non-consecutive configured TDWs.
· Each configured TDW consists of one or multiple consecutive physical slots.
·
The window length L of
the configured TDW(s) can be explicitly configured with a single value and L is
no longer than the maximum duration.
o
FFS: The maximum value of L is the
duration of all repetitions
o
FFS: Solutions to error propagation issue if
for L is longer
than the maximum duration is to be discussed further.
o FFS: The window length L is configured per UL BWP
· The start of the first configured TDW is the first PUSCH transmission
o FFS: The first available slot/symbol, or the first physical slot/symbol for the first PUSCH transmission.
· The start of other configured TDWs can be implicitly determined prior to first repetition.
o FFS: The configured TDWs are consecutive for paired spectrum/SUL band
o FFS: The start of the configured TDWs for unpaired spectrum is implicitly determined based on semi-static DL/UL configuration.
· The end of the last configured TDW is the end of the last PUSCH transmission.
o FFS: The end of the configured TDW is the last available slot/symbol, or the last physical slot/symbol for the last PUSCH transmission.
· Within one configured TDW, one or multiple actual TDWs can be implicitly determined:
o The start of the first actual TDW is the first PUSCH transmission within the configured TDW.
§ The first available slot/symbol, or the first physical slot/symbol for the first PUSCH transmission.
o After one actual TDW starts, UE is expected to maintain the power consistency and phase continuity until one of the following conditions is met, then the actual TDW is ended.
§ The actual TDW reaches the end of the last PUSCH transmission within the configured TDW.
· FFS: The end of the actual TDW is the last available slot/symbol, or the last physical slot/symbol for the last PUSCH transmission.
§ An event occurs that violates power consistency and phase continuity
· FFS: The events may include e.g., a DL slot based on DL/UL configuration for unpaired spectrum, the actual TDW reaches the maximum duration, DL reception/monitoring occasion for unpaired spectrum, high priority transmission, frequency hopping, precoder cycling.
· FFS: The end of the actual TDW is the last available slot/symbol of the PUSCH transmission right before an event such that the power consistency and phase continuity are violated.
o If the power consistency and phase continuity are violated due to an event, whether a new actual TDW is created is subject to UE capability of supporting restarting DMRS bundling.
§ If UE is capable of restarting DM-RS bundling, one new actual TDW is created after the event,
· FFS: The start of the new actual TDW is the first available slot/symbol for PUSCH transmission after the event.
§ If UE is not capable of restarting DM-RS bundling, no new actual TDW is created until the end of the configured TDW.
§ FFS: UE capability of restarting DMRS bundling is applied only to dynamic event or not
Note 1: A ‘configured TDW’ refers to a time domain window whose length can be configured to ‘L’ and whose start and end is determined as described above.
Note 2: An ‘actual TDW’ refers to a time domain window during whose entire duration the DM-RS bundling is actually applied. An ‘actual TDW’ duration is always less than or equal to the ‘configure TDW’ duration.
Note 3: Whether the terms ‘configured TDW’ and ‘actual TDW’ are revised to other terms and if such terminology is used in specifications is to be further discussed.
Final summary in R1-2108644 [106-e-NR-R17-CovEnh-03] Summary of email discussion on joint channel estimation for PUSCH Moderator (China Telecom)
Including dynamic PUCCH repetition factor indication, and DMRS bundling across PUCCH repetitions (When applicable, based on similar mechanism(s) for enabling joint channel estimation for PUSCH)
R1-2106498 Discussion on PUCCH coverage enhancement Huawei, HiSilicon
R1-2106614 Discussion on PUCCH enhancements vivo
R1-2106658 PUCCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2106712 Discussion on PUCCH enhancements Spreadtrum Communications
R1-2106742 Discussion on coverage enhancements for PUCCH ZTE
R1-2106905 PUCCH enhancements Samsung
R1-2106991 Discussion on PUCCH enhancement CATT
R1-2107118 Discussion on PUCCH enhancement for NR coverage enhancement Panasonic Corporation
R1-2107126 Discussion on PUCCH enhancements China Telecom
R1-2107142 Discussion on PUCCH enhancements NEC
R1-2107193 Enhancements for PUCCH repetition Lenovo, Motorola Mobility
R1-2107259 PUCCH enhancements for coverage OPPO
R1-2107362 PUCCH enhancements Qualcomm Incorporated
R1-2107420 Discussion on PUCCH enhancements CMCC
R1-2107477 PUCCH enhancements ETRI
R1-2107551 Discussions on coverage enhancement for PUCCH LG Electronics
R1-2107562 PUCCH Dynamic Repetition and DMRS Bundling Ericsson
R1-2107605 Discussion on PUCCH enhancements Intel Corporation
R1-2107653 Discussions on PUCCH enhancements InterDigital, Inc.
R1-2107756 PUCCH coverage enhancement Apple
R1-2107802 PUCCH coverage enhancement Sharp
R1-2107875 PUCCH enhancements NTT DOCOMO, INC.
R1-2107938 Discussion on PUCCH enhancements Xiaomi
[106-e-NR-R17-CovEnh-04] Email discussion regarding PUCCH enhancements – Yi (Qualcomm)
R1-2108315 FL summary of PUCCH coverage enhancement Moderator (Qualcomm)
R1-2108347 FL summary#2 of PUCCH coverage enhancement Moderator (Qualcomm)
From GTW session:
Confirm the following working assumption
In Rel-17, for a PUCCH with associated scheduling DCI, support the following for dynamic PUCCH repetition factor indication.
· Enhance RRC signaling to allow configuration of PUCCH repetition factor per PUCCH resource. Reuse Rel-16 PUCCH resource indication mechanism based on “PUCCH resource indicator” (PRI) field and starting CCE index (when applicable based on Rel-16 spec) of DCI to indicate a PUCCH resource and its associated repetition factor.
o FFS: RRC signaling enhancement details
R1-2108482 FL summary#3 of PUCCH coverage enhancement Moderator (Qualcomm)
R1-2108619 FL summary#4 of PUCCH coverage enhancement Moderator (Qualcomm)
From GTW session:
Agreement
· For a PUCCH resource, if both a new repetition parameter corresponding to Rel-17 dynamic PUCCH repetition factor indication and the Rel-15/16 nrofSlots are configured, the new repetition parameter overrides nrofSlots.
Agreement
· In Rel-17, reuse the Rel-16 PUCCH repetition factors 2, 4, 8.
· Do not support PUCCH repetition factor larger than 8 In Rel-17.
Agreement
· For DMRS bundling for PUCCH repetitions, RAN1 at least prioritize use cases 3 and 4a in R1-2104119.
Agreement
Dynamic PUCCH repetition factor indication for SR or P/SP-CSI on PUCCH is not supported in Rel-17.
R1-2106499 Discussion on Msg3 repetition for coverage enhancement Huawei, HiSilicon
R1-2106615 Discussion on Type A PUSCH repetitions for Msg3 vivo
R1-2106659 Approaches and solutions for Type A PUSCH repetitions for Msg3 Nokia, Nokia Shanghai Bell
R1-2106713 Discussion on type A PUSCH repetitions for Msg3 Spreadtrum Communications
R1-2106743 Discussion on support of Type A PUSCH repetitions for Msg3 ZTE
R1-2106906 Type A PUSCH repetitions for Msg3 Samsung
R1-2106992 Discussion on Type A PUSCH repetitions for Msg3 CATT
R1-2107119 Discussion on Type A PUSCH repetitions for Msg.3 Panasonic Corporation
R1-2107127 Discussion on type A PUSCH repetitions for Msg3 China Telecom
R1-2107260 Type A PUSCH repetitions for Msg3 coverage OPPO
R1-2107363 Type A PUSCH repetition for Msg3 Qualcomm Incorporated
R1-2107421 Discussion on type A PUSCH repetitions for Msg3 CMCC
R1-2107478 Type A PUSCH repetitions for Msg3 ETRI
R1-2107552 Discussion on coverage enhancement for Msg3 PUSCH LG Electronics
R1-2107563 Type A PUSCH Repetition for Msg3 Ericsson
R1-2107606 On Msg3 PUSCH repetition Intel Corporation
R1-2107654 Type A PUSCH repetitions for Msg3 InterDigital, Inc.
R1-2107757 Discussion on Msg3 Coverage Enhancement Apple
R1-2107803 Type A PUSCH repetition for msg3 Sharp
R1-2107876 Type A PUSCH repetitions for Msg3 NTT DOCOMO, INC.
R1-2107939 Discussion on Type A PUSCH repetition for Msg3 Xiaomi
R1-2108160 Discussion on Type A PUSCH repetitions for Msg3 WILUS Inc.
[106-e-NR-R17-CovEnh-05] – Xianghui (ZTE)
Email discussion regarding Type A PUSCH repetitions for Msg 3
R1-2108258 Feature lead summary #1 on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
From GTW session:
Agreement
Do NOT support fallback RAR UL grant in 2-step RACH for indicating Msg3 repetition.
Agreement
The separate preambles for requesting Msg3 repetition could be configured only in an RO configured with 4-step RACH preambles not for requesting Msg3 repetition.
Working Assumption
Down-select only one from the following methods for indication of the number of repetition of Msg3 initial transmission.
· Alt 1: If TDRA information field is chosen, introducing a new configurable TDRA table including the repetition factors.
o The new TDRA table is configured by SIB1, with selecting one of the two options below.
§ Option 1: The new TDRA table includes separate new indication for K2, mapping type, SLIV and repetition factor.
§ Option 2: The new TDRA table includes legacy indication for K2, mapping type and SLIV from legacy TDRA table, and new indication for repetition factor.
o If a new TDRA table is not configured, the legacy default TDRA table is used, and repetition factor K=1 is applied.
§
K=1.
· Alt 2: If MCS information field is chosen, repurpose the MCS information field as follows.
o X MSB bits of the MCS information field are used for repetition indication.
§ FFS the value of X.
§ FFS whether the X bits are directly used for indicating the repetition factor (i.e., the decimal value of X is equal to the repetition factor) or used for selecting one repetition factor from a predefined/SIB1 configured set.
· Alt 3: If TPC information field is chosen, repurpose the TPC information field by selecting one of the two options below.
o Option 1: X LSB bits of the TPC information field are used for repetition indication.
§ FFS the value of X.
§ FFS whether the X bits are directly used for indicating the repetition factor (i.e., the decimal value of X is equal to the repetition factor) or used for selecting one repetition factor from a predefined/SIB1 configured set.
o Option 2: A predefined TPC command table with including repetition factor K is introduced.
§ FFS details.
R1-2108259 Feature lead summary #2 on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
R1-2108584 Feature lead summary #3 on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
Agreement
Down-select one of the two options on how a UE should interpret the selected information field for indication of the number of repetitions.
· Option 1:
o When a UE requests Msg3 repetition, the new TDRA table or repurposed information field is applied. gNB schedules Msg3 with or without repetition for the UE requesting Msg3 repetition.
§ Repetition factor K=1 is included in the TDRA table or one entry/codepoint of the repurposed information field.
o When the UE doesn’t request Msg3 repetition (including legacy UE), the legacy TDRA table or legacy information field is applied. gNB schedules Msg3 without repetition for the UE not requesting Msg3 repetition.
· Option 2:
o When a UE requests Msg3 repetition, gNB schedules Msg3 with or without repetition by respectively using the new TDRA table or legacy TDRA table; or gNB schedules Msg3 with or without repetition by respectively using repurposed information field or legacy interpretation of information field. Whether the UE should apply the new or the legacy TDRA table, or apply repurposed or legacy interpretation of the information field, is indicated by gNB.
§ FFS details, e.g. implicit or explicit indication or predefined.
§ Repetition factor K=1 is NOT included in the TDRA table or one entry/codepoint of the repurposed information field.
o When the UE doesn't request Msg3 repetition (including legacy UE), gNB schedules Msg3 without repetition. The UE applies the legacy TDRA table, or the legacy interpretation of the information field.
Agreement
· Support at least repetition factor K = {2, 4} for Msg3 PUSCH repetition.
o FFS whether to support other values, e.g., 8.
· Note: K=1 is supported and how to support K=1 is FFS.
Agreement
· The available slot of Msg3 PUSCH repetition is only determined by the tdd-UL-DL-ConfigurationCommon and ssb-PositionsInBurst, no other additional Rel-16 signals/signalings will be considered.
o If a symbol for Msg3 repetition in a slot overlaps with SSB transmission [FFS:N Gap symbols after SSB], the slot is determined as not available during the counting of repetitions. As there is no Msg3 repetition in the slot, no Msg3 repetition omission applies to the slot.
Agreement
Do not support TBoMS for Msg3 in Rel-17 coverage enhancement WI.
Final summary in R1-2108585 Feature lead summary #4 on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
R1-2106616 Enhanced contention resolution mechanism for CBRA procedure with MSG3 PUSCH repetition vivo
R1-2106660 Discussion on the scope of DMRS bundling for PUSCH Nokia, Nokia Shanghai Bell
R1-2106744 Performance impacts of residual frequency error for joint channel estimation of PUSCH and PUCCH transmissions ZTE
R1-2106993 Views on reusing PUSCH enhancements for Msg3 CATT
R1-2107564 Other Coverage Enhancements for PUSCH Ericsson
R1-2107655 Deterministic PUSCH repetition for coverage enhancement InterDigital, Inc.
R1-2107679 On futher potential coverage enhancements Huawei, HiSilicon
R1-2107940 Other considerations for coverage enhancement xiaomi
Please refer to RP-211566 for detailed scope of the WI.
Please also refer to section 5 of RP-212555 for additional guidance for this e-meeting.
Incoming LS(s) related to this work/study item under agenda item 5: R1-2108703, R1-2108712.
R1-2110617 Session notes for 8.8 (NR coverage enhancement) Ad-hoc Chair (CMCC)
[106bis-e-R17-RRC-CovEnh] – Jianchi (China Telecom)
Email discussion on Rel-17 RRC parameters for Coverage Enhancement
- 1st check point: October 14
- Final check point: October 19
R1-2110567 [106bis-e-R17-RRC-CovEnh] Email discussion on Rel-17 RRC parameters for Coverage Enhancement Moderator (China Telecom, Sharp, Nokia, Qualcomm, ZTE)
Document is noted. For consolidation under 8 in [106bis-e-R17-RRC].
RRC parameters of AI 8.8.1.1
For the editors: The structure used for supporting the increased maximum number of repetitions for PUSCH repetition A is endorsed in principle to clarify its usage. Please consider them in the specification draft.
· To support the increased maximum number of repetitions for PUSCH repetition A, reuse PUSCH-TimeDomainResourceAllocation-r16 structure with adding numberOfRepetitions-r17 to PUSCH-Allocation-r16.
Agreement
A single RRC parameter AvailableSlotCounting that applies to both DG-PUSCH and CG-PUSCH is introduced.
Agreement
Two enhancements are configured separately (simultaneous configurations allowed).
· If the new Rel-17 RRC parameter “AvailableSlotCounting” set to “enabled” is configured, numberofrepetitions-r17 may or may not be configured and the counting based on available slots is used.
· Otherwise, numberofrepetitions-r17 may or may not be configured and the counting based on physical slots is used.
RRC parameters of AI 8.8.1.2
Observation
· The parameter numberOfSlotsTBoMS-r17 is UE-specific.
For the editors: The description about the parameter ‘numberOfSlotsTBoMS-r17’ is endorsed in principle to clarify its usage. Please consider them in the specification draft.
The parameter numberOfSlotsTBoMS-r17 could be described as follows.
|
numberOfSlotsTBoMS-r17 Number of slots allocated for TB processing over multi-slot PUSCH for DCI format 0_1/0_2 (see TS 38.214 [X], clause XX) |
For the editors: Below table is endorsed in principle. Please consider them during drafting the specification.
|
Sub-feature group |
Parameter name in the spec |
New or existing? |
Description |
Value range |
Per (UE, cell, TRP, …) |
UE-specific or Cell-specific |
Specification |
Comment |
|
|
NR_cov_enh-Core |
TB processing over multi-slot PUSCH |
numberOfSlotsTBoMS-r17 |
new |
Number of slots allocated for TB processing over multi-slot PUSCH for DCI format 0_1/0_2 (see TS 38.214 [X], clause XX) |
[1], 2,4,8 |
Per UE, Parent IE: PUSCH-TimeDomainResourceAllocationList |
UE-specific |
38.331 |
Agreement The number N of allocated slots for TBoMS is indicated via a new column added to the TDRA table configured via PUSCH-TimeDomainAllocationList. The existing column for configuring the number of repetitions in the TDRA for Rel-17 PUSCH repetition Type A, i.e., numberOfRepetitions, is used for indicating the number of repetitions M of a single TBoMS, when TBoMS transmission is enabled. FFS: supported values of N and M. FFS: how to enable the TBoMS transmission FFS: details of retransmission of TBoMS
Agreement At least the following values are supported in Rel-17 for the number N of allocated slots for the single TBoMS: FFS: whether N=1 is also supported depends on how TBoMS transmission feature is enabled (or disabled) FFS: other values, if any. FFS: further constraints on N*M |
|
WI code |
Sub-feature group |
Parameter name in the spec |
New or existing? |
Description |
Value range |
Per (UE, cell, TRP, …) |
UE-specific or Cell-specific |
Specification |
Comment |
|
NR_cov_enh-Core |
TB processing over multi-slot PUSCH |
numberOfRepetitions |
Existing |
Number of repetitions of a single TB over multi-slot PUSCH (see TS 38.214 [X], clause XX) |
1,2,3,4,7,8, 12, 16 |
Per UE, Parent IE: PUSCH-TimeDomainResourceAllocationList |
UE-specific |
38.331 |
Agreement The number N of allocated slots for TBoMS is indicated via a new column added to the TDRA table configured via PUSCH-TimeDomainAllocationList. The existing column for configuring the number of repetitions in the TDRA for Rel-17 PUSCH repetition Type A, i.e., numberOfRepetitions, is used for indicating the number of repetitions M of a single TBoMS, when TBoMS transmission is enabled. FFS: supported values of N and M. FFS: how to enable the TBoMS transmission FFS: details of retransmission of TBoMS
Agreement The following values are supported in Rel-17 for the number M of repetitions of the single TBoMS: FFS: further constraints on N*M, e.g., N*M is a valid value according to agreements in AI 8.8.1.1 |
RRC parameters of AI 8.8.1.3
Agreement
· Introduce two RRC parameters to indicate enabling of DM-RS bundling and the window length of the configured TDW respectively.
Agreement
· Introduce a new RRC parameter for when UE restarts a PUSCH bundling window
RRC parameters of AI 8.8.2
Agreement
For dynamic PUCCH repetition factor indication, the parent IE for RRC parameter ‘PUCCH-nrofSlots-r17’ is “PUCCH-Resource”.
RRC parameters of AI 8.8.3
|
WI code |
Sub-feature group |
Parameter name in the spec |
New or existing? |
Description |
Value range |
Per (UE, cell, TRP, …) |
UE-specific or Cell-specific |
Specification |
Comment |
|
NR_cov_enh-Core |
Type A PUSCH repetitions for Msg3 |
numberOfMsg3Repetitions |
new |
The number of repetitions for Msg3 PUSCH repetition, including Msg3 initial transmission and Msg3 re-transmission. |
FFS |
FFS |
Cell-specific |
38.331 |
Working Assumption Down-select only one from the following methods for indication of the number of repetitions of Msg3 initial transmission. · Alt 1: If TDRA information field is chosen, Option 2 is supported. o The candidate values for repetition factor could be chosen from {[1], 2, 3, 4, 7, 8, [12], [16]} · Alt 2: If MCS information field is chosen, repurpose the MCS information field as follows. o 2 MSB bits of the MCS information field are used for selecting one repetition factor from a SIB1 configured set with 4 candidate values. § The set of candidate values for repetition factor could be chosen from {[1], 2, 3, 4, 7, 8, [12], [16]} Note: Whether ‘1’ is included depends on the outcome of interpretation of the selected information field. |
|
NR_cov_enh-Core |
Type A PUSCH repetitions for Msg3 |
Msg3Repetitions-CB-PreamblesPerSSB-PerSharedRO |
new |
The number of preambles per SSB for request of Msg3 repetition with shared RO |
INTEGER (1..60) |
RACH-ConfigCommon |
Cell-specific |
38.331 |
Agreement Include the following into the reply LS to R1-2108712(R2-2109195). RAN1 thinks at least the number of preambles per SSB per RO for request of Msg3 repetition is needed. It’s up to RAN2 whether to indicate the start of preamble index for request of Msg3 repetition with shared RO. |
[106bis-e-NR-R17-CovEnh-06] – Yi (Qualcomm)
Discuss incoming LS for a possible reply LS by October 18
R1-2108703 Reply LS on PUCCH and PUSCH transmissions RAN4, Qualcomm
R1-2110699 FL summary of discussion on incoming LS R1-2108703 on PUCCH and PUSCH repetitions Moderator (Qualcomm)
R1-2110642 Reply LS on PUCCH and PUSCH repetition RAN1, Qualcomm
Decision: As per email decision posted on Oct 21st, the LS is approved.
R1-2110688 RAN1 agreements for Rel-17 NR coverage enhancements WI rapporteur (China Telecom)
R1-2108738 Discussion on coverage enhancements for PUSCH repetition type A Huawei, HiSilicon
R1-2108845 Discussion on enhanced PUSCH repetition type A ZTE
R1-2108919 Discussion on enhancements for PUSCH repetition Type A Spreadtrum Communications
R1-2108989 Discussion on enhancement for PUSCH repetition type A vivo
R1-2109088 Enhancements on PUSCH repetition type A OPPO
R1-2109240 Discussion on enhancements on PUSCH repetition type A CATT
R1-2109247 Remaining issues on PUSCH repetition type A enhancements China Telecom
R1-2109295 Discussion on enhancements on PUSCH repetition type A CMCC
R1-2109424 Enhancements on PUSCH repetition type A Xiaomi
R1-2109452 Discussion on enhancements on PUSCH repetition type A Rakuten Mobile, Inc
R1-2109455 Discussion on enhancements on PUSCH repetition Type A Panasonic Corporation
R1-2109504 Enhancements on PUSCH repetition type A Samsung
R1-2109624 Enhancements on PUSCH repetition type A Intel Corporation
R1-2109692 Enhancements on PUSCH repetition type A NTT DOCOMO, INC.
R1-2109886 Enhancements on PUSCH repetition type A Nokia, Nokia Shanghai Bell
R1-2109990 Design considerations for PUSCH repetition Type A Enhancements Sierra Wireless. S.A.
R1-2110000 Enhancements on PUSCH repetition type A Sharp
R1-2110046 Discussion on PUSCH repetition type A enhancement Apple
R1-2110096 Discussions on PUSCH repetition type A enhancements LG Electronics
R1-2110122 PUSCH Repetition Type A Enhancement Ericsson
R1-2110152 Type-A PUSCH repetition for coverage enhancement InterDigital, Inc.
R1-2110201 Enhancements on PUSCH Repetition Type A Qualcomm Incorporated
R1-2110237 Enhancements on PUSCH repetition type A Lenovo, Motorola Mobility
R1-2110327 Discussion on enhancements on PUSCH repetition type A WILUS Inc.
[106bis-e-NR-R17-CovEnh-01] – Toshi (Sharp)
Email discussion regarding enhancements for PUSCH repetition type A
- 1st check point: October 14
- Final check point: October 19
R1-2110448 FL Summary #1 on Enhancements on PUSCH repetition type A Moderator (Sharp)
From Oct 12th GTW session
Agreement
Following working assumption is confirmed
The maximum number of repetitions accounted for available slots supported by Rel-17 PUSCH repetition Type A is 32.
Agreement (from RAN1#106-e meeting)
Take Option 1-B as an agreement for the procedure of Rel-17 PUSCH repetitions counted on the basis of available slots.
· Alt 1-B consisting of two steps
o Step 1: Determine available slots for K repetitions based on RRC configuration(s) in addition to TDRA in the DCI scheduling the PUSCH, CG configuration or activation DCI
o Step 2: The UE determines whether to drop a PUSCH repetition or not according to Rel-15/16 PUSCH dropping rules, but the PUSCH repetition is still counted in the K repetitions.
· FFS: Rel-17 PUSCH dropping rules are also applied if introduced in other WI(s)
Agreement
For CG-PUSCH repetition Type A with the counting based on available slots, the R16 existing restrictions as defined in Clause 6.1.2.3.1 of TS38.214 at least on the initial transmission of a transport block are applied, assuming the K repetitions of R17 determined based the rule of counting available slots.
R1-2110449 FL Summary #2 on Enhancements on PUSCH repetition type A Moderator (Sharp)
From Oct 14th GTW session
Conclusion:
For CG-PUSCH repetitions counted on the basis of available slots, all the K transmission occasions including the 1st transmission occasion are determined on the basis of available slots.
Observation
· Whether or not the counting based on available slots is applicable only to unpaired spectrum is not discussed under AI 8.8.1.1 in RAN1#106bis-e. Discussions on how HD-FDD RedCap UEs support the available slot counting may take place in AI 8.8.1.1 in RAN1#107-e, depending on the progress of RedCap WI discussions.
R1-2110450 FL Summary #3 on Enhancements on PUSCH repetition type A Moderator (Sharp)
Decision: As per email decision posted on Oct 19th,
Agreement
· For the K repetitions of DG-PUSCH, Step 1 of the previously agreed two-step procedure (i.e., Alt 1-B) determines the K earliest available slots no earlier than the slot which is determined by the slot offset K2.
o No RAN1 spec impact is expected in terms of the relation with the slot which is determined by the slot offset K2.
o Note: The available slot determination is to be specified.
· For the K repetitions of CG-PUSCH, Step 1 of the previously agreed two-step procedure (i.e., Alt 1-B) determines the K earliest available slots no earlier than the first slot which is determined by at least ConfiguredGrantConfig.
o No RAN1 spec impact is expected in terms of the relation with the first slot which is determined by at least ConfiguredGrantConfig.
o Note: The available slot determination is to be specified.
Agreement
· Only tdd-UL-DL-ConfigurationCommon, tdd-UL-DL-ConfigurationDedicated and ssb-PositionsInBurst are considered for the determination of available slots.
o Any other RRC configuration is not considered for the determination of available slots.
Agreement
· The existing restriction “The UE is not expected to be configured with the time duration for the transmission of K repetitions larger than the time duration derived by the periodicity P” applies to both the counting based on physical slots and the counting based on available slots.
· The above “the time duration for the transmission of K repetitions” means the time duration between the start of the 1st slot of the K repetitions and the end of the last slot of the K repetitions for any instance of a CG period.
Final summary in R1-2110596.
R1-2108739 Discussion on TB processing over multi-slot PUSCH Huawei, HiSilicon
R1-2108846 Discussion on TB processing over multi-slot PUSCH ZTE
R1-2108920 Discussion on TB processing over multi-slot PUSCH Spreadtrum Communications
R1-2108990 Discussion on PUSCH TB processing over multiple slots vivo
R1-2109035 Views on TB processing over multi-slot PUSCH Fujitsu
R1-2109089 Further considerations for TB over multi-slot PUSCH OPPO
R1-2109133 Discussion on TB processing over multi-slot PUSCH NEC
R1-2109141 On TB processing over multiple slots for PUSCH Indian Institute of Tech (H)
R1-2109241 Discussion on TB processing over multi-slot PUSCH CATT
R1-2109248 Remaining issues on TB processing over multi-slot PUSCH China Telecom
R1-2109296 Discussion on TB processing over multi-slot PUSCH CMCC
R1-2109329 Discussion on TBoMS PUSCH TCL Communication Ltd.
R1-2109425 Discussion on TB processing over multi-slot PUSCH Xiaomi
R1-2109456 Discussion on TB processing over multi-slot PUSCH Panasonic Corporation
R1-2109505 TB processing over multi-slot PUSCH Samsung
R1-2109571 Discussion on TB processing over multi-slot MediaTek Inc.
R1-2109625 Discussion on TB processing over multi-slot PUSCH Intel Corporation
R1-2109693 TB processing over multi-slot PUSCH NTT DOCOMO, INC.
R1-2109887 Transport block processing for PUSCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2110001 Transport block processing over multi-slot PUSCH Sharp
R1-2110047 Discussion on TB processing over multi-slot PUSCH Apple
R1-2110097 Discussions on TB processing over multi-slot PUSCH LG Electronics
R1-2110123 TB Processing over Multi-Slot PUSCH Ericsson
R1-2110153 TB processing over multiple slots InterDigital, Inc.
R1-2110202 TB processing over multi-slot PUSCH Qualcomm Incorporated
R1-2110238 Enhancements for TB processing over multi-slot PUSCH Lenovo, Motorola Mobility
R1-2110328 Discussion on TB processing over multi-slot PUSCH WILUS Inc.
[106bis-e-NR-R17-CovEnh-02] – Marco (Nokia)
Email discussion regarding TB processing over multi-slot PUSCH
- 1st check point: October 14
- Final check point: October 19
R1-2110428 FL summary of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia/Nokia Shanghai Bell)
From Oct 12th GTW session
Agreement
· For transmission power determination of TBoMS transmission in Rel-17, RAN1 to down-select one of the following two options:
o Option 1: The transmission power determination of TBoMS should be based on all the REs allocated in one available slot for the TBoMS transmission, excluding the overhead of reference signals
o Option 2: The transmission power determination of TBoMS should be based on all the REs allocated in the N available slots for the TBoMS transmission, excluding the overhead of reference signals.
· FFS: details on BPRE
Agreement
The number of MIMO layers (rank) for TBoMS transmission in Rel-17 is limited to 1.
Decision: As per email decision posted on Oct 14th,
Agreement
For a single TBoMS transmission and TBoMS repetitions in Rel-17, at least the legacy Rel-15/16 inter-slot frequency hopping framework used in PUSCH repetition Type A is supported.
· FFS: other frequency hopping schemes.
R1-2110528 FL summary #2 of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia, Nokia Shanghai Bell)
Decision: As per email decision posted on Oct 17th,
Agreement
·
The number N of
allocated slots for TBoMS is indicated via a new column added to the TDRA table
configured via PUSCH-TimeDomainAllocationList. The existing column for
configuring the number of repetitions in the TDRA for Rel-17 PUSCH repetition
Type A, i.e., numberOfRepetitions, is used for indicating the
number of repetitions M of a single TBoMS, when TBoMS
transmission is enabled.
· FFS: supported values of N and M.
· FFS: how to enable the TBoMS transmission
· FFS: details of retransmission of TBoMS
Agreement
For the repetition of a single TBoMS transmission, redundancy versions (RVs) are cycled across the TBoMS repetitions. The legacy Rel-15/16 RV sequences and RV index indication are reused.
Conclusion
Values 1<K<N for the scaling factor to calculate N_info for TBS determination for TBoMS transmission in Rel-17 are not supported.
Decision: As per email decision posted on Oct 19th,
Agreement
At least the following values are supported in Rel-17 for the number N of allocated slots for the single TBoMS:
·
FFS: whether N=1 is also supported depends on how TBoMS transmission feature is enabled (or disabled)
FFS: other values, if any.
FFS: further constraints on N*M
Agreement
The following values are supported in Rel-17 for the number M of repetitions of the single TBoMS:
·
FFS: further constraints on N*M, e.g., N*M is a valid value according to agreements in AI 8.8.1.1
Agreement
BPRE
for TBOMS is calculated as 
where N is
the number of slots allocated for a single TBOMS and 
is
the number of allocated REs in one allocated slot of a single TBOMS.
Note: How this equation or its equivalent is captured in the specification is left to the editor
Agreement
For a single TBoMS transmission and TBoMS repetitions in Rel-17, the legacy Rel-15/16 intra-slot frequency hopping framework used in PUSCH repetition Type A is supported.
· FFS: other frequency hopping schemes.
R1-2110529 FL summary #3 of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia/Nokia Shanghai Bell)
Working Assumption
For TBoMS in Rel-17, the following is supported:
· Bit interleaving is performed per slot.
o The index of the starting coded bit for each transmitted slot is predetermined prior to the start of the TBoMS transmission.
· Transmission is limited to one CB only.
· FFS: whether UCI multiplexing bits or cancellation/dropping of coded bits, if any, have to be known prior to the determination of the index of the starting coded bit for each transmitted slot or not
· FFS: Performance with UCI multiplexing on single and multiple slots of a single TBoMS
Note: How UCI multiplexing and cancellation/dropping of coded bits influence the sequence of coded bits transmitted in each slot of a single TBOMS is to be further discussed. Some knowledge on UCI to be multiplexed or cancellation/dropping of coded bits in each slot of a single TBOMS may be known prior to the start of a single TBOMS transmission. How this is to be handled is to be discussed further.
Agreement
For the bit selection for each transmitted slot for TBoMS, one of the following is to be down selected in RAN1 #107-e for determining the index of the starting coded bit in the circular buffer:
· Option B: the index of the starting coded bit in the circular buffer is the index continuous from the position of the last bit selected in the previous allocated slot.
· Option C: the index of the starting coded bit in the circular buffer is the index continuous from the position of the last bit selected in the previous allocated slot, regardless of whether UCI multiplexing occurred in the previous allocated slot or not.
FFS: whether the index of the starting coded bit for each transmitted slot is expressed as a multiple integer of the lifting size Zc
Note: Dropping/cancellation rules are not considered for the starting bit position determination in both Option B and Option C.
Agreement
For TBoMS transmission in Rel-17:
· TBoMS feature is enabled (or disabled) by configuring (or not) the number of allocated slots for a single TBoMS (N) in a row of the TDRA table.
o TBoMS transmission is enabled when N>1, where N is the number of allocated slots for a single TBoMS.
o Single-slot PUSCH transmission is enabled when N=1.
o Supported combinations of N and M that can be configured in the TDRA table, these combinations are constrained by retransmission are to be further discussed
Final summary in R1-2110530.
R1-2108740 Discussion on joint channel estimation for PUSCH Huawei, HiSilicon
R1-2108847 Discussion on joint channel estimation for PUSCH ZTE
R1-2108921 Discussion on joint channel estimation for PUSCH Spreadtrum Communications
R1-2108991 Discussion on joint channel estimation for PUSCH vivo
R1-2109090 Consideration on Joint channel estimation for PUSCH OPPO
R1-2109242 Discussion on joint channel estimation for PUSCH CATT
R1-2109249 Remaining issues on joint channel estimation for PUSCH China Telecom
R1-2109297 Discussion on joint channel estimation for PUSCH CMCC
R1-2109330 Discussion on joint channel estimation for PUSCH TCL Communication Ltd.
R1-2109426 Discussion on joint channel estimation for PUSCH Xiaomi
R1-2109459 Discussion on joint channel estimation for PUSCH Panasonic Corporation
R1-2109506 Joint channel estimation for PUSCH Samsung
R1-2109572 Discussion on Joint channel estimation over multi-slot MediaTek Inc.
R1-2109626 Discussion on joint channel estimation for PUSCH Intel Corporation
R1-2109694 Joint channel estimation for PUSCH NTT DOCOMO, INC.
R1-2109799 Views on Joint Channel Estimation for PUSCH Sony
R1-2109888 Joint channel estimation for PUSCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2109991 Design Considerations for Joint channel estimation for PUSCH Sierra Wireless. S.A.
R1-2110002 Joint channel estimation for multiple PUSCH transmission Sharp
R1-2110048 Discussion on joint channel estimation for PUSCH Apple
R1-2110098 Discussions on joint channel estimation for PUSCH LG Electronics
R1-2110124 Joint Channel Estimation for PUSCH Ericsson
R1-2110154 Joint channel estimation for PUSCH InterDigital, Inc.
R1-2110203 Joint channel estimation for PUSCH Qualcomm Incorporated
R1-2110239 Enhancements for joint channel estimation for multiple PUSCH Lenovo, Motorola Mobility
R1-2110329 Discussion on joint channel estimation for PUSCH WILUS Inc.
[106bis-e-NR-R17-CovEnh-03] Email discussion regarding joint channel estimation for PUSCH – Jianchi (China Telecom)
- 1st check point: October 14
- Final check point: October 19
R1-2109250 FL Summary of joint channel estimation for PUSCH Moderator (China Telecom)
From Oct 12th GTW session
Revise the working assumption
· For back-to-back PUSCH transmissions across consecutive slots, support necessary design aspects (under the condition of power consistency and phase continuity) to enable joint channel estimation for the following case:
o Over back-to-back PUSCH transmissions for one TB processed over multiple slots
§ It’s subject to UE capability
to Working assumption:
· For back-to-back PUSCH transmissions across consecutive slots, support necessary design aspects (under the condition of power consistency and phase continuity) to enable joint channel estimation for the following case:
o Over back-to-back PUSCH transmissions for one TB processed over multiple slots
§ It’s subject to UE capability
§ If it reuses only those joint channel estimation specification enhancements defined to support repetition Type A.
R1-2110502 FL Summary#2 of joint channel estimation for PUSCH Moderator (China Telecom)
From Oct 14th GTW session
Agreement
It is agreed that
· For PUSCH repetition type A counting based on physical slots
o The start of the first configured TDW is the first physical slot for the first PUSCH transmission.
o The end of the last configured TDW is the last physical slot for the last PUSCH transmission.
· For PUSCH repetition type A counting based on available slots
o The start of the first configured TDW is the first available slot for the first PUSCH transmission.
o The end of the last configured TDW is the last available slot for the last PUSCH transmission.
o Note: The determination of available slots for PUSCH repetition Type A is defined in AI 8.8.1.1.
R1-2110503 FL Summary#3 of joint channel estimation for PUSCH Moderator (China Telecom)
From Oct 15th GTW session
Conclusion
· Joint channel estimation over PUSCH transmissions across non-consecutive slots is not supported in Rel-17.
Agreement
Down-select one of the following options in
this next meeting:
· Option 1:
o The maximum value of window length L of the configured TDW should not exceed the maximum duration, which is reported as UE capability as the duration where UE is able to maintain power consistency and phase continuity subject to power consistency and phase continuity requirements.
· Option 1’:
o The maximum value of window length L of the configured TDW should not exceed the maximum duration, which is reported as UE capability as the duration where UE is able to maintain power consistency and phase continuity subject to power consistency and phase continuity requirements.
§
If L is not
configured, the configured TDW length is equal to all repetitions
§ If L is not configured, default behavior should be defined, e.g., the configured TDW length is equal to all repetitions
· Option 3’:
o Whether the window length L of the configured TDW can be longer than maximum duration is subject to UE capability.
§ If UE is capable of L being longer than maximum duration,
· The maximum value of the window length L of the configured TDW is the duration of all repetitions.
· FFS: whether L cannot be other values other than the duration of all repetitions, if it is longer than the maximum duration.
§ If L is longer than the maximum duration, UE does not expect dynamic events.
· FFS: details of dynamic events
Agreement
· For DG-PUSCH, Type1 CG-PUSCH and Type2 CG-PUSCH, the window length L of the configured TDW is at least configured by RRC.
· FFS: For DG-PUSCH and Type2 CG-PUSCH, whether the window length L of the configured TDW can be indicated by DCI or indicated by TDRA table with one additional entry.
Agreement
· The window length L of the RRC configured TDW is configured separately for PUSCH and PUCCH.
o For PUSCH, L is configured per BWP.
FFS whether the window length L can be configured with each row in the TDRA table
Agreement
· For PUSCH repetition type A counting based on physical slots
o The configured TDWs are consecutive, where the start of other configured TDWs is the first physical slot right after the last physical slot of a previous configured TDW.
· For PUSCH repetition type A counting based on available slots
o
The configured TDWs are
determined based on available slots, where start of a configured TDWs is the next first
available slot after the conclusion last
available slot of a previous configured TDW.
o Note: The determination of available slots for PUSCH repetition Type A is defined in AI 8.8.1.1.
R1-2110568 FL Summary#4 of joint channel estimation for PUSCH Moderator (China Telecom)
From Oct 19th GTW session
Working Assumption
Support Actual TDW Option 2b’:
·
The
start of the first actual TDW is the first available symbol (at least determined by TDRA table) in available slot for the first PUSCH transmission in an available slot
within the configured TDW.
· The end of the actual TDW is
o the last available symbol (at least determined by TDRA table) in available slot for the last PUSCH transmission in an available slot
within the configured TDW if the actual TDW reaches the end of the last PUSCH
transmission within the configured TDW.
o the last available symbol (at least determined by TDRA table) in available slot of the PUSCH transmission right before the event if an
event occurs that violates power consistency and phase continuity, and the
PUSCH transmission is in an available slot.
o For UE capable of restarting DM-RS bundling, the
start of the new actual TDW is the first available symbol (at least determined by TDRA table) in available slot for PUSCH transmission after the event violates power
consistency and phase continuity, and the PUSCH transmission is in an available
slot.
Decision: As per email decision posted on Oct 21st,
Agreement
For back-to-back PUSCH transmissions across consecutive slots, support necessary design aspects (under the condition of power consistency and phase continuity) to enable joint channel estimation for the following case:
· Over back-to-back PUSCH transmissions for one TB processed over multiple slots
o It’s subject to UE capability
o if it reuses only those joint channel estimation specification enhancements defined to support repetition Type A
Note: No need to confirm the following
Working assumption:
For back-to-back PUSCH transmissions across consecutive slots, support necessary design aspects (under the condition of power consistency and phase continuity) to enable joint channel estimation for the following case:
· Over back-to-back PUSCH transmissions for one TB processed over multiple slots
o It’s subject to UE capability
Agreement
For non-back-to-back PUSCH transmissions across consecutive slots (no uplink transmission in the middle of two PUSCH transmissions), support necessary design aspects (under the condition of power consistency and phase continuity) to enable joint channel estimation for the following case:
· Over non-back-to-back PUSCH transmissions for one TB processed over multiple slots
o It’s subject to UE capability
o if it reuses only those joint channel estimation specification enhancements defined to support repetition Type A
Agreement
Down-select one of the following options:
· Option 1: If DM-RS bundling is supported, UE is mandatory to support restarting DM-RS bundling due to semi-static events. UE capability of restarting DMRS bundling is applied only to dynamic events.
· Option 2: UE capability of restarting DMRS bundling is applied to both semi-static events and dynamic events.
Agreement
Support at least the following events that violate power consistency and phase continuity.
· Dropping/cancellation based on Rel-15/16 collision rules.
· FFS: Rel-17 collision rules.
· DL slot or DL reception/monitoring based on semi-static DL/UL configuration for unpaired spectrum.
· FFS: Other UL transmission in between PUSCH/PUCCH transmissions.
· Gap between two PUSCH/PUCCH transmissions exceeds 13 symbols.
· FFS: Transmission parameters need to be changed due to network-indicated operations, including: Tx power, UL beam/TPMI, and RB allocation.
· FFS: TPC command.
· FFS: TA adjustment.
· FFS: The actual TDW reaches the maximum duration.
· FFS: Frequency hopping.
· FFS: Precoder cycling.
· FFS: other events.
· FFS: whether events are semi-static events or dynamic events.
· FFS: the time duration of an event.
Final summary in R1-2110569.
Including dynamic PUCCH repetition factor indication, and DMRS bundling across PUCCH repetitions (When applicable, based on similar mechanism(s) for enabling joint channel estimation for PUSCH).
R1-2108741 Discussion on PUCCH coverage enhancement Huawei, HiSilicon
R1-2108848 Discussion on coverage enhancements for PUCCH ZTE
R1-2108922 Discussion on PUCCH enhancements Spreadtrum Communications
R1-2108992 Discussion on PUCCH enhancements vivo
R1-2109091 PUCCH enhancements for coverage OPPO
R1-2109243 Discussion on PUCCH enhancement CATT
R1-2109251 Remaining issues on PUCCH enhancements China Telecom
R1-2109298 Discussion on PUCCH enhancements CMCC
R1-2109427 Discussion on PUCCH enhancements Xiaomi
R1-2109457 Discussion on PUCCH enhancement for NR coverage enhancement Panasonic Corporation
R1-2109507 PUCCH enhancements Samsung
R1-2109627 Discussion on PUCCH enhancements Intel Corporation
R1-2109695 PUCCH enhancements for coverage enhancement NTT DOCOMO, INC.
R1-2109814 PUCCH enhancements ETRI
R1-2109889 PUCCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2110003 PUCCH coverage enhancement Sharp
R1-2110049 PUCCH coverage enhancement Apple
R1-2110099 Discussions on coverage enhancement for PUCCH LG Electronics
R1-2110125 PUCCH Dynamic Repetition and DMRS Bundling Ericsson
R1-2110155 Discussions on PUCCH enhancements InterDigital, Inc.
R1-2110204 PUCCH enhancements Qualcomm Incorporated
R1-2110240 Enhancements for PUCCH repetition Lenovo, Motorola Mobility
[106bis-e-NR-R17-CovEnh-04] – Yi (Qualcomm)
Email discussion regarding PUCCH enhancements
- 1st check point: October 14
- Final check point: October 19
R1-2110441 FL summary#1 of PUCCH coverage enhancement Moderator (Qualcomm)
R1-2110513 FL summary#2 of PUCCH coverage enhancement Moderator (Qualcomm)
From Oct 14th GTW session
Agreement
Dynamic signaling to enable/disable DMRS bundling for PUCCH or PUSCH repetitions is not supported in Rel-17.
Agreement:
For the interaction between inter-slot frequency hopping and DMRS bundling for PUCCH/PUSCH repetitions, a UE performs the “hopping intervals determination”, “configured TDW determination”, and “actual TDW determination” in a sequential ordering. One option of the following options is to be selected.
· Option 1: “hopping intervals determination” -> “configured TDW determination” -> “actual TDW determination”
· Option 2: “configured TDW determination” -> “hopping intervals determination” -> “actual TDW determination”
· Option 4: “configured TDW determination” -> “actual TDW determination” and “hopping intervals determination”
Note: option 1 and 2 assume a hopping interval can be different than an actual TDW. Option 4 assumes a hopping interval is the same as an actual TDW.
Agreement
Support dynamic PUCCH repetition factor indication for all PUCCH formats including format 0, 1, 2, 3, 4 with a unified mechanism as agreed in RAN1#106e under agenda 8.8.2.
Note: it does not impact the discussion of slot level or sub-slot level repetition
Final summary in R1-2110590.
R1-2108742 Discussion on Msg3 repetition for coverage enhancement Huawei, HiSilicon
R1-2108849 Discussion on support of Type A PUSCH repetitions for Msg3 ZTE
R1-2108923 Discussion on Type A PUSCH repetitions for Msg3 Spreadtrum Communications
R1-2108993 Discussion on Type A PUSCH repetitions for Msg3 vivo
R1-2109092 Type A PUSCH repetitions for Msg3 coverage OPPO
R1-2109134 Discussion on PUSCH repetition for Msg3 NEC
R1-2109244 Discussion on Type A PUSCH repetitions for Msg3 CATT
R1-2109252 Remaining issues on type A PUSCH repetitions for Msg3 China Telecom
R1-2109299 Discussion on type A PUSCH repetitions for Msg3 CMCC
R1-2109428 Discussion on Type A PUSCH repetition for Msg3 Xiaomi
R1-2109458 Discussion on Type A PUSCH repetitions for Msg.3 Panasonic Corporation
R1-2109508 Type A PUSCH repetitions for Msg3 Samsung
R1-2109628 On Msg3 PUSCH repetition Intel Corporation
R1-2109696 Type A PUSCH repetitions for Msg3 NTT DOCOMO, INC.
R1-2109815 Type A PUSCH repetitions for Msg3 ETRI
R1-2109890 Approaches and solutions for Type A PUSCH repetitions for Msg3 Nokia, Nokia Shanghai Bell
R1-2110004 Type-A PUSCH repetition for msg3 Sharp
R1-2110050 Discussion on Msg3 Coverage Enhancement Apple
R1-2110100 Discussion on coverage enhancement for Msg3 PUSCH LG Electronics
R1-2110126 Type A PUSCH Repetition for Msg3 Ericsson
R1-2110205 Type A PUSCH repetition for Msg3 Qualcomm Incorporated
R1-2110236 Type A PUSCH repetitions for Msg3 InterDigital, Inc.
R1-2110330 Discussion on Type A PUSCH repetitions for Msg3 WILUS Inc.
[106bis-e-NR-R17-CovEnh-05] – Xianghui (ZTE)
Email discussion regarding Type A PUSCH repetitions for Msg 3
- 1st check point: October 14
- Final check point: October 19
R1-2110417 Feature lead summary #1 on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
From Oct 14th GTW session
Working Assumption
Down-select only one from the following methods for indication of the number of repetitions of Msg3 initial transmission.
· Alt 1: If TDRA information field is chosen, Option 2 is supported.
o The candidate values for repetition factor could be chosen from {[1], 2, 3, 4, 7, 8, [12], [16]}
· Alt 2: If MCS information field is chosen, repurpose the MCS information field as follows.
o 2 MSB bits of the MCS information field are used for selecting one repetition factor from a SIB1 configured set with 4 candidate values.
§ The set of candidate values for repetition factor could be chosen from {[1], 2, 3, 4, 7, 8, [12], [16]}
Note: Whether ‘1’ is included depends on the outcome of interpretation of the selected information field.
Agreement
Include the following into the reply LS to R1-2108712(R2-2109195).
RAN1
thinks at least the number of preambles per SSB per RO for request of Msg3
repetition, i.e., CB-PreamblesPerSSB,
is needed. It’s up to RAN2 whether to indicate the start of preamble index for
request of Msg3 repetition with shared RO.
Agreement
Include the following into the reply LS to R1-2108712(R2-2109195).
From RAN1 perspective, there is no need to separately configure the following legacy RACH parameters configured in RACH-ConfigCommon for requesting Msg3 PUSCH repetition with shared RO on a given UL carrier.
· prach-ConfigurationIndex
· msg1-FDM
· msg1-FrequencyStart
· zeroCorrelationZoneConfig
· totalNumberOfRA-Preambles
· ssb-perRACH-OccasionAndCB-PreamblesPerSSB
· FFS: rsrp-ThresholdSSB
· rsrp-ThresholdSSB-SUL
· prach-RootSequenceIndex
· msg1-SubcarrierSpacing
· restrictedSetConfig
· msg3-transformPrecoder
Conclusion
There is no consensus to additionally support intra-slot frequency hopping for Msg3 PUSCH with repetition in Rel-17.
Note: intra-slot FH is supported when a UE is scheduled Msg3 PUSCH without repetition.
R1-2110418 Feature lead summary #2 on support of Type A PUSCH repetitions for Msg4 Moderator (ZTE)
Decision: As per email decision posted on Oct 20th,
Agreement
Include the following into the reply LS to R1-2108712(R2-2109195)
· From RAN1 perspective, it can be beneficial to separately configure rsrp-ThresholdSSB for requesting Msg3 PUSCH repetition with shared RO on a given UL carrier.
Agreement
If UE is indicated with Msg3 PUSCH with repetition, the frequency hopping flag information field in UL RAR grant or DCI format 0_0 with CRC scrambled by TC-RNTI is reused to enable/disable inter-slot frequency hopping.
Agreement
The Rel-15/16 Msg3 PUSCH collision handling rules are reused for transmission of Msg3 PUSCH repetition in an available slot.
· FFS whether collision with downlink symbols indicated by tdd-UL-DL-ConfigurationDedicated is an exceptional case, i.e., Msg3 PUSCH repetition cannot be cancelled by downlink symbols indicated by tdd-UL-DL-ConfigurationDedicated in Rel-17.
· FFS: Rel-17 Msg3 PUSCH collision rules are also applied if introduced in other WI(s)
Final summary in R1-2110419.
[106bis-e-NR-R17-CovEnh-07] – Xianghui (ZTE)
Discuss incoming LS for a possible reply LS by October 18
R1-2108712 LS on Msg3 repetition in coverage enhancement RAN2, ZTE
R1-2110589 Summary of discussion on reply LS for Msg3 repetition in coverage enhancement Moderator (ZTE)
R1-2110585 Reply LS on Msg3 repetition in coverage enhancement RAN1, ZTE
Decision: As per email decision posted on Oct 21st, the LS is approved.
R1-2108850 Performance impacts of residual frequency error for joint channel estimation of PUSCH and PUCCH transmissions ZTE
R1-2108994 Enhanced contention resolution mechanism for CBRA procedure with MSG3 PUSCH repetition vivo
R1-2109245 Views on reusing PUSCH enhancements for Msg3 CATT
R1-2109429 Other considerations for coverage enhancement Xiaomi
R1-2109509 Considerations on Rel-17 RRC parameters for Coverage Enhancement Samsung
R1-2109746 On further potential coverage enhancements Huawei, HiSilicon
R1-2109891 On the support of DMRS bundling for the scenario of other UL transmission in-between PUSCH/PUCCH repetitions Nokia, Nokia Shanghai Bell
R1-2110127 Frequency Hopping for TBoMS Ericsson
Please refer to RP-211566 for detailed scope of the WI.
Please also refer to section 5 of RP-212555 for additional guidance for this e-meeting.
R1-2112795 Session notes for 8.8 (NR coverage enhancement) Ad-hoc Chair (CMCC)
Rel-17 CRs related to cov_enh
R1-2112433 Introduction of coverage enhancements Ericsson
Decision: Draft CR to 38.211 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
R1-2112440 Introduction of coverage enhancements in NR Samsung
Decision: Draft CR to 38.213 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
R1-2112470 Introduction of Coverage Enhancements Huawei
Decision: Draft CR to 38.212 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
R1-2112480 Introduction of NR coverage enhancements Nokia
Decision: Draft CR to 38.214 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
[107-e-R17-RRC-CovEnh] – Jianchi (China Telecom)
Email discussion on Rel-17 RRC parameters for Coverage Enhancement
- Email discussion to start on November 15
R1-2112827 [107-e-R17-RRC-CovEnh] Summary of email discussion on Rel-17 RRC parameters for Coverage Enhancement Moderator (China Telecom, Sharp, Nokia, Qualcomm, ZTE)
Document is noted. For consolidation under 8 in [107-e-R17-RRC].
R1-2112899 RAN1 agreements for Rel-17 NR coverage enhancements WI rapporteur (China Telecom)
R1-2111648 Discussion on priorities for remaining issues for coverage enhancements vivo
R1-2110789 Discussion on coverage enhancements for PUSCH repetition type A Huawei, HiSilicon
R1-2110863 Enhancements on PUSCH repetition type A Nokia, Nokia Shanghai Bell
R1-2110918 Discussion on enhanced PUSCH repetition type A ZTE
R1-2111027 Remaining issues on enhancement for PUSCH repetition type A vivo
R1-2111106 Discussion on enhancements for PUSCH repetition Type A Spreadtrum Communications
R1-2111203 Discussion on PUSCH repetition type A enhancements TCL Communication Ltd.
R1-2111271 Discussion on enhancements on PUSCH repetition type A CATT
R1-2111328 Enhancements on PUSCH repetition type A OPPO
R1-2111426 Remaining issues on PUSCH repetition type A enhancements China Telecom
R1-2111437 Discussion on enhancements on PUSCH repetition Type A Panasonic Corporation
R1-2111507 Enhancements on PUSCH repetition type A Intel Corporation
R1-2111584 Enhancements on PUSCH repetition type A Xiaomi
R1-2111590 Discussion on enhancements on PUSCH repetition type A Rakuten Mobile, Inc
R1-2111620 Discussion on enhancements on PUSCH repetition type A CMCC
R1-2111751 Enhancements on PUSCH repetition type A Samsung
R1-2111792 Type-A PUSCH repetition for coverage enhancement InterDigital, Inc.
R1-2111842 Design considerations for PUSCH repetition Type A Enhancements Sierra Wireless. S.A.
R1-2111887 Discussion on PUSCH repetition type A enhancement Apple
R1-2111948 Enhancements on PUSCH repetition type A Lenovo, Motorola Mobility
R1-2112019 Enhancements on PUSCH repetition type A Sharp
R1-2112035 Remaining Issues for PUSCH Repetition Type A Enhancement Ericsson
R1-2112119 Enhancements on PUSCH repetition type A NTT DOCOMO, INC.
R1-2112230 Enhancements on PUSCH Repetition Type A Qualcomm Incorporated
[107-e-NR-R17-CovEnh-01] – Toshi (Sharp)
Email discussion regarding enhancements for PUSCH repetition type A
- 1st check point: November 15
- Final check point: November 19
R1-2112519 FL Summary #1 on Enhancements on PUSCH repetition type A Moderator (Sharp)
R1-2112520 FL Summary #2 on Enhancements on PUSCH repetition type A Moderator (Sharp)
From Nov 15th GTW session
Agreement
· The counting based on available slots is applicable to unpaired spectrum, paired spectrum and SUL
o For paired spectrum and SUL except HD-FDD, all slots are considered as available slots in the first step of determining the available slots.
Agreement
· For HD-FDD RedCap Ues supporting the counting based on available slots.
o For CG-PUSCH, ssb-PositionsInBurst is used in the first step of determining of available slots.
§ A slot is not counted in the number of available slots if at least one of the symbols indicated by the indexed row of the used resource allocation table in the slot overlaps with a symbol of an SS/PBCH block with index provided by ssb-PositionInBurst.
o FFS: For DG-PUSCH
o Note: Neither tdd-UL-DL-ConfigurationCommon nor tdd-UL-DL-ConfigurationDedicated is configured for FDD.
From Nov 17th GTW session
Agreement
· Rel-17 does not support numberOfRepetitions-r17 for DG-PUSCH scheduled by DCI format 0_0 and for Type 2 CG-PUSCH activated by DCI format 0_0.
· repK-r17 supporting up-to-32 repetitions is introduced and is applicable to Type 1 CG-PUSCH and Type 2 CG-PUSCH (irrespective of the activating DCI format).
o Note: No RAN1 spec impact is expected.
o The possible values of repK-r17 includes 16 and 32. FFS: other values.
· numberOfRepetitions-r17 is not applicable to Type 1 CG-PUSCH repetition type A.
Agreement
· All the following combinations support the counting based on available slots.
o DG-PUSCH with Rel-15 repetition factor
o Type-1 CG-PUSCH with Rel-15 repetition factor
o Type-2 CG-PUSCH with Rel-15 repetition factor
o DG-PUSCH with Rel-16 repetition factor
o Type-2 CG-PUSCH with Rel-16 repetition factor
o DG-PUSCH with Rel-17 repetition factor
o Type-1 CG-PUSCH with Rel-17 repetition factor, if supported in Issue#1-1
o Type-2 CG-PUSCH with Rel-17 repetition factor
Conclusion
Rel-17 PUSCH repetition Type A with K>1 does not support PUSCH transmission without UL-SCH.
Decision: As per email decision posted on Nov 19th,
Agreement
· For repK-r17,
o The value range of repK-17 is {1, 2, 4, 8, 12, 16, 24, 32}.
o repK-r17 is included in ConfiguredGrantConfig.
o When repK-r17 is provided, the legacy repK is not provided.
Agreement
· For HD-FDD RedCap Ues supporting the counting based on available slots.
· For DG-PUSCH, ssb-PositionsInBurst is used in the first step of determining of available slots.
o A slot is not counted in the number of available slots if at least one of the symbols indicated by the indexed row of the used resource allocation table in the slot overlaps with a symbol of an SS/PBCH block with index provided by ssb-PositionInBurst.
· Note: Neither tdd-UL-DL-ConfigurationCommon nor tdd-UL-DL-ConfigurationDedicated is configured for FDD.
Final summary in
R1-2112521 FL Summary #3 on Enhancements on PUSCH repetition type A Moderator (Sharp)
R1-2110790 Discussion on TB processing over multi-slot PUSCH Huawei, HiSilicon
R1-2110864 Transport block processing for PUSCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2110919 Discussion on TB processing over multi-slot PUSCH ZTE
R1-2111028 Remaining issues on PUSCH TB processing over multiple slots vivo
R1-2111107 Discussion on TB processing over multi-slot PUSCH Spreadtrum Communications
R1-2111149 Views on TB processing over multi-slot PUSCH Fujitsu
R1-2111204 Discussion on TB processing over multi-slot PUSCH TCL Communication Ltd.
R1-2111272 Discussion on TB processing over multi-slot PUSCH CATT
R1-2111329 Further considerations for TB over multi-slot PUSCH OPPO
R1-2111427 Remaining issues on TB processing over multi-slot PUSCH China Telecom
R1-2111438 Discussion on TB processing over multi-slot PUSCH Panasonic Corporation
R1-2111508 Discussion on TB processing over multi-slot PUSCH Intel Corporation
R1-2111585 Discussion on TB processing over multi-slot PUSCH Xiaomi
R1-2111621 Discussion on TB processing over multi-slot PUSCH CMCC
R1-2111693 Discussion on TB processing over multi-slot PUSCH NEC
R1-2111752 TB processing over multi-slot PUSCH Samsung
R1-2111793 TB processing over multiple slots InterDigital, Inc.
R1-2111888 Discussion on TB processing over multi-slot PUSCH Apple
R1-2111949 Enhancements for TB processing over multi-slot PUSCH Lenovo, Motorola Mobility
R1-2111979 Discussions on TB processing over multi-slot PUSCH LG Electronics
R1-2112020 Transport block processing over multi-slot PUSCH Sharp
R1-2112611 Remaining Issues for TB Processing over Multi-Slot PUSCH Ericsson (rev of R1-2112036)
R1-2112120 TB processing over multi-slot PUSCH NTT DOCOMO, INC.
R1-2112231 TB processing over multi-slot PUSCH Qualcomm Incorporated
R1-2112316 Discussion on TB processing over multi-slot MediaTek Inc.
R1-2112390 Discussion on TB processing over multi-slot PUSCH WILUS Inc.
[107-e-NR-R17-CovEnh-02] – Marco (Nokia)
Email discussion regarding TB processing over multi-slot PUSCH
- 1st check point: November 15
- Final check point: November 19
R1-2112462 FL summary of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia/Nokia Shanghai Bell)
From Nov 11th GTW session
Agreement
A single RV is used to transmit a single TBoMS.
· Note: It is common assumption for option B and option C for “Starting bit in each slot for the single TBoMS”
· Note: below working assumption does not need confirm.
Working Assumption
Single TBoMS structure of Option 3 is selected
· Option 3: Multiple TOTs are determined for a TBoMS. The TB is transmitted on the multiple TOTs using a single RV.
FFS: how the single RV is rate matched across single or multiple TOTs, e.g., rate matched for each TOT, rate matched for all the TOTs, rate matched for each slot and so on.
Agreement
The following working assumption is confirmed.
For TBoMS in Rel-17, the following is supported:
· Bit interleaving is performed per slot.
o The index of the starting coded bit for each transmitted slot is predetermined prior to the start of the TBoMS transmission.
· Transmission is limited to one CB only.
· FFS: whether UCI multiplexing bits or cancellation/dropping of coded bits, if any, have to be known prior to the determination of the index of the starting coded bit for each transmitted slot or not
· FFS: Performance with UCI multiplexing on single and multiple slots of a single TBoMS
Note: How UCI multiplexing and cancellation/dropping of coded bits influence the sequence of coded bits transmitted in each slot of a single TBOMS is to be further discussed. Some knowledge on UCI to be multiplexed or cancellation/dropping of coded bits in each slot of a single TBOMS may be known prior to the start of a single TBOMS transmission. How this is to be handled is to be discussed further.
From Nov 15th GTW session
Conclusion
There is no consensus in RAN1 to introduce any restriction on the combinations of N and M that can be configured in the TDRA table, other than the already agreed N*M <= 32 restriction.
Agreement
· For TBoMS, UCI is multiplexed on the individual overlapping slot for UL transmission in one carrier
· FFS: timeline requirements
· FFS: details on the calculation of the number of coded modulation symbols per layer for UCI multiplexing on a single TBoMS.
· Note: no new UCI multiplexing mechanism other than existing puncturing or rate-matching is introduced for TBoMS in Rel-17.
R1-2112686 FL summary #2 of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia/Nokia Shanghai Bell)
R1-2112687 FL summary #3 of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia/Nokia Shanghai Bell)
Decision: As per email decision posted on Nov 19th,
Agreement
For TBoMS repetitions, if the parameter numberOfRepetitions is not configured in the TDRA table, then the number of repetitions M of a single TBoMS is equal to 1.
Agreement
For a configured grant type 2, if M=1, or if M>1 and the configured grant is configured with startingFromRV0 set to 'off', the initial transmission of the transport block may only start at the first slot of the N*M slots determined as available for PUSCH transmission of TBoMS. Otherwise, the initial transmission of the transport block may start at
· The first slot of the N*M slots determined as available for PUSCH transmission of TBoMS if the configured RV sequence is {0,2,3,1},
· The first slot of any of the M groups of N slots determined as available for PUSCH transmission of TBoMS associated with RV=0, if the configured RV sequence is {0,3,0,3} or {0,0,0,0}.
Note: It is up to Editor to decide how to capture these rules.
Decision: As per email decision posted on Nov 20th,
Agreement
For
UCI multiplexing on an available slot for TBoMS, the following are supported in
Rel-17 for calculating 
, 
, 
, and 
:
·
is the number of symbols in an available slot for TBoMS in which
UCI is multiplexed.
·
The CB size is scaled by 
, where N is the number of slots allocated for TBoMS, i.e., 
becomes 
.
Note: It is up to the Editor to decide how to capture the scaling in the specification.
Agreement
The UE does not expect NW to indicate a TBoMS configuration which results in a TBS which exceeds the maximum TBS for single CB transmission.
Agreement
For the retransmission of a single TBoMS with or without repetition in Rel-17:
· The gNB schedules only complete retransmissions of TBs.
· How the retransmission of the entire TB is done is up to gNB, e.g., could be single slot PUSCH retransmission or TBoMS retransmission, etc.
Note: this has no specification impact.
Final summary in R1-2112688.
R1-2110791 Discussion on joint channel estimation for PUSCH Huawei, HiSilicon
R1-2110865 Joint channel estimation for PUSCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2110920 Discussion on joint channel estimation for PUSCH ZTE
R1-2111029 Remaining issues on joint channel estimation for PUSCH vivo
R1-2111108 Discussion on joint channel estimation for PUSCH Spreadtrum Communications
R1-2111205 Discussion on joint channel estimation for PUSCH TCL Communication Ltd.
R1-2111273 Discussion on joint channel estimation for PUSCH CATT
R1-2111330 Consideration on Joint channel estimation for PUSCH OPPO
R1-2111425 Discussion on joint channel estimation for PUSCH Panasonic Corporation
R1-2111428 Remaining issues on joint channel estimation for PUSCH China Telecom
R1-2111509 Discussion on joint channel estimation for PUSCH Intel Corporation
R1-2111586 Discussion on joint channel estimation for PUSCH Xiaomi
R1-2111622 Discussion on joint channel estimation for PUSCH CMCC
R1-2111681 On events for Joint Channel Estimation for PUSCH Sony
R1-2111753 Joint channel estimation for PUSCH Samsung
R1-2111794 Joint channel estimation for PUSCH InterDigital, Inc.
R1-2111841 Design Considerations for Joint channel estimation for PUSCH Sierra Wireless. S.A.
R1-2111889 Discussion on joint channel estimation for PUSCH Apple
R1-2111950 Enhancements for joint channel estimation for multiple PUSCH Lenovo, Motorola Mobility
R1-2111980 Discussions on joint channel estimation for PUSCH LG Electronics
R1-2112021 Joint channel estimation for multiple PUSCH transmission Sharp
R1-2112037 Remaining Issues for Joint Channel Estimation for PUSCH Ericsson
R1-2112121 Joint channel estimation for PUSCH NTT DOCOMO, INC.
R1-2112232 Joint channel estimation for PUSCH Qualcomm Incorporated
R1-2112317 Discussion on Joint channel estimation over multi-slot MediaTek Inc.
R1-2112391 Discussion on joint channel estimation for PUSCH WILUS Inc.
[107-e-NR-R17-CovEnh-03] – Jianchi (China Telecom)
Email discussion regarding joint channel estimation for PUSCH
- 1st check point: November 15
- Final check point: November 19
R1-2111429 FL Summary of joint channel estimation for PUSCH Moderator (China Telecom)
From Nov 11th GTW session
Agreement
Support Option 1’-a
Option 1’-a:
· If L is configured, the maximum value of window length L of the configured TDW should not exceed the maximum duration, which is reported as UE capability as the duration where UE is able to maintain power consistency and phase continuity subject to power consistency and phase continuity requirements.
· If L is not configured, the default value of L = min (maximum duration, duration of all PUSCH repetitions)
Decision: As per email decision posted on Nov 17th,
Agreement
· For non-back-to-back PUSCH/PUCCH transmissions across consecutive slots, the other uplink transmission in the middle of two PUSCH/PUCCH transmissions constitutes an event that violates power consistency and phase continuity.
Conclusion
Dynamic indication of the window length L of the configured TDW by DCI or indicated by TDRA table with one additional entry is not supported.
Agreement
The following working assumption is confirmed:
·
The start of the first actual TDW is the
first available symbol (at least determined by TDRA table) in available slot for the first PUSCH transmission
in an available slot within the configured TDW.
· The end of the actual TDW is
o
the last available
symbol (at least determined by TDRA table) in available slot for the last PUSCH transmission
in an available slot within the configured TDW if the actual TDW reaches the
end of the last PUSCH transmission within the configured TDW.
o
the last available
symbol (at least determined by TDRA table) in available slot of the PUSCH transmission right
before the event if an event occurs that violates power consistency and phase
continuity, and the PUSCH transmission is in an available slot.
·
For UE capable of restarting DM-RS bundling,
the start of the new actual TDW is the first available
symbol (at least determined by TDRA table) in available slot for PUSCH transmission after the
event violates power consistency and phase continuity, and the PUSCH
transmission is in an available slot.
R1-2112561 FL Summary#2 of joint channel estimation for PUSCH Moderator (China Telecom)
R1-2112562 FL Summary#3 of joint channel estimation for PUSCH Moderator (China Telecom)
From Nov 17th GTW session
Agreement
· The action of gNB indicated TA commands constitutes an event that violates power consistency and phase continuity.
Agreement
· If DM-RS bundling is supported, UE is mandatory to support restarting DM-RS bundling due to semi-static events. UE capability of restarting DMRS bundling is applied only to dynamic events.
o An event is regarded as a dynamic event if it is triggered by a DCI or MAC-CE, otherwise it is regarded as a semi-static event.
o Note: At least frequency hopping event is considered as semi-static event.
Working assumption:
The action of group common TPC commands with format 2_2 does not constitute an event that violates power consistency and phase continuity.
· If UE is configured to accumulate TPC commands,
o If UE receives TPC commands that would take into effect during a configured TDW, UE accumulates TPC commands without taking effect during the current configured TDW. TPC commands take effect after the current configured TDW.
· If UE is not configured to accumulate TPC commands
o the last TPC command that would take effect within a configured TDW supersedes all previous TPC commands that take effect within that configured TDW and only the last TPC command is applied by the UE after the current configured TDW.
§ FFS: no more than 1 TPC command is expected to take effect during a configured TDW.
R1-2112563 FL Summary#4 of joint channel estimation for PUSCH Moderator (China Telecom)
From Nov 19th GTW session
Agreement
· UE should not perform UE autonomous TA adjustment during the actual time domain window.
Agreement
· The candidate values of the window length L of the configured TDW can be any integer value that is larger than 1 and no larger than the maximum duration.
Agreement
The following agreement is clarified as follows.
· For PUSCH repetition type A counting based on available slots,
o “The configured TDWs are determined based on available slots” in the agreement means “The start of the configured TDWs is determined based on available slots”
Agreement(RAN1#106b-e)
· For PUSCH repetition type A counting based on physical slots
o The configured TDWs are consecutive, where the start of other configured TDWs is the first physical slot right after the last physical slot of a previous configured TDW
· For PUSCH repetition type A counting based on available slots
o The configured TDWs are determined based on available slots, where start of a configured TDWs is the first available slot after the last available slot of a previous configured TDW.
Note: The determination of available slots for PUSCH repetition Type A is defined in AI 8.8.1.1.
Agreement
· The TDW determination procedure agreed for PUSCH repetition type A is reused, when applicable, for PUSCH repetition type B and TBoMS with or without repetition.
· No additional specification enhancements for PUSCH repetition type B and TBoMS.
Agreement
The following working assumption is confirmed
For joint channel estimation for PUSCH repetition type A of PUSCH repetitions of the same TB, all the repetitions are covered by one or multiple consecutive/non-consecutive configured TDWs.
Note 1: A ‘configured TDW’ refers to a time domain window whose length can be configured to ‘L’ and whose start and end is determined as described above.
Note 2: An ‘actual TDW’ refers to a time domain window during whose entire duration the DM-RS bundling is actually applied. An ‘actual TDW’ duration is always less than or equal to the ‘configure TDW’ duration.
Note 3: Whether the terms ‘configured TDW’ and ‘actual TDW’ are revised to other terms and if such terminology is used in specifications is to be further discussed.
Decision: As per email decision posted on Nov 20th,
Agreement
· If DMRS bundling and UL beam switching for multi-TRP operation are configured simultaneously, UL beam switching for multi-TRP operation constitutes an event that violates power consistency and phase continuity.
o FFS: UL beam switching for multi-TRP operation is regarded as a semi-static event.
Final summary in R1-2112828.
Including dynamic PUCCH repetition factor indication, and DMRS bundling across PUCCH repetitions (When applicable, based on similar mechanism(s) for enabling joint channel estimation for PUSCH).
R1-2110792 Discussion on PUCCH coverage enhancement Huawei, HiSilicon
R1-2110866 PUCCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2110921 Discussion on coverage enhancements for PUCCH ZTE
R1-2111030 Remaining issues on PUCCH enhancements vivo
R1-2111109 Discussion on PUCCH enhancements Spreadtrum Communications
R1-2111274 Discussion on PUCCH enhancement CATT
R1-2111331 PUCCH enhancements for coverage OPPO
R1-2111430 Remaining issues on PUCCH enhancements China Telecom
R1-2111439 Discussion on PUCCH enhancement for NR coverage enhancement Panasonic Corporation
R1-2111510 Discussion on PUCCH enhancements Intel Corporation
R1-2111587 Discussion on PUCCH enhancements Xiaomi
R1-2111623 Discussion on PUCCH enhancements CMCC
R1-2111694 Discussion on dynamic PUCCH repetition factor NEC
R1-2111754 PUCCH enhancements Samsung
R1-2111795 Discussions on PUCCH enhancements InterDigital, Inc.
R1-2111890 PUCCH coverage enhancement Apple
R1-2111951 Enhancements for PUCCH repetition Lenovo, Motorola Mobility
R1-2111981 Discussions on coverage enhancement for PUCCH LG Electronics
R1-2111993 PUCCH enhancements ETRI
R1-2112022 PUCCH coverage enhancement Sharp
R1-2112038 Remaining Issues for PUCCH Dynamic Repetition and DMRS Bundling Ericsson
R1-2112122 PUCCH enhancements for coverage enhancement NTT DOCOMO, INC.
R1-2112233 PUCCH enhancements Qualcomm Incorporated
R1-2112392 Discussion on PUCCH enhancements for coverage enhancement WILUS Inc.
[107-e-NR-R17-CovEnh-04] – Yi (Qualcomm)
Email discussion regarding PUCCH enhancements
- 1st check point: November 15
- Final check point: November 19
R1-2112582 FL summary #1 of PUCCH coverage enhancement Moderator (Qualcomm)
R1-2112622 FL summary #2 of PUCCH coverage enhancement Moderator (Qualcomm)
From Nov 15th GTW session
Agreement
For a PUCCH resource to transmit a PUCCH without an associated scheduling DCI (e.g. P/SP-CSI or SR), if the PUCCH resource is configured with RRC parameter “nrofSlots-r17”, “nrofSlots-r17” is ignored and the RRC parameter “nrofSlots” is used for determining the repetition factor of the specific PUCCH resource.
Agreement
The following use case 5 of PUCCH DMRS bundling is not supported in Rel-17
· Use case 5: PUCCH repetitions across non-consecutive slots.
o Use case 5a: no uplink transmission in the middle of two PUCCH repetitions
o Use case 5b: other uplink transmissions in the middle of two PUCCH repetitions
Agreement
For PUCCH DMRS bundling, when appliable, reuse the procedure developed for PUSCH DMRS bundling to determine configured TDW(s) and actual TDW(s).
· FFS: events for PUCCH actual TDW(s)
Agreement
For the interaction between inter-slot frequency hopping and DMRS bundling for PUCCH/PUSCH repetitions, a UE perform the “hopping intervals determination”, “configured TDW determination”, and “actual TDW determination” in a sequential ordering. One option of the following options is to be selected.
· Option 1: “hopping intervals determination” à “configured TDW determination” à “actual TDW determination”
o FFS: DMRS bundling should be restarted in case of frequency hopping event
o FFS: whether same or separate RRC configuration(s) for hopping interval and configured TDW.
· Option 2: “configured TDW determination” à “hopping intervals determination” à “actual TDW determination”
R1-2112700 FL summary #3 of PUCCH coverage enhancement Moderator (Qualcomm)
From Nov 17th GTW session
Possible Agreement
For the interaction between inter-slot frequency hopping and DMRS bundling for PUCCH/PUSCH repetitions, a UE performs the “hopping intervals determination”, “configured TDW determination”, and “actual TDW determination” in a sequential ordering, based on the following option 1.
· Option 1: “hopping intervals determination” -> “configured TDW determination” -> “actual TDW determination”
o DMRS bundling shall be restarted at the beginning of each frequency hop
o DMRS bunding is per actual TDW
§ FFS: determination of actual TDWs, if a frequency
hop contains multiple actual TDWs.
o Frequency hopping pattern is determined by physical slot indices only.
o Support separate RRC configuration(s) for hopping interval and configured TDW.
§ if hopping pattern is not configured, the default hopping pattern is the same as the configured TDW
· FFS: if both hopping pattern and TDW are not configured
§ Note: hopping pattern is determined by the configuration of hopping pattern if hopping pattern is configured
§ [Note: Both same and different configuration(s) for hopping interval and configured TDW are allowed by specification. It is up to NW to configure same or different configuration(s).]
From Nov 19th GTW session
Agreement
For the interaction between inter-slot frequency hopping and DMRS bundling for PUCCH/PUSCH repetitions, a UE performs the “hopping intervals determination”, “configured TDW determination”, and “actual TDW determination” in a sequential ordering, based on the following option 1.
· Option 1: “hopping intervals determination” à “configured TDW determination” à “actual TDW determination”
o DMRS bundling shall be restarted at the beginning of each frequency hop
o DMRS bunding is per actual TDW
o FFS: Frequency hopping pattern is determined by physical slot indices.
§ FFS: different FH pattern determination for PUCCH and PUSCH
§ FFS: details of FH pattern design
o Support separate RRC configuration(s) for hopping interval and configured TDW length.
§ if hopping interval is not configured, the default hopping interval is the same as the configured TDW length
· FFS: if both hopping interval and TDW length are not configured
§ Note: hopping interval is only determined by the configuration of hopping interval if hopping interval is configured
Final summary in
R1-2112708 FL summary #4 of PUCCH coverage enhancement Moderator (Qualcomm)
R1-2112543 Discussion on Msg3 repetition for coverage enhancement Huawei, HiSilicon (rev of R1-2110793)
R1-2110867 Approaches and solutions for Type A PUSCH repetitions for Msg3 Nokia, Nokia Shanghai Bell
R1-2110922 Discussion on support of Type A PUSCH repetitions for Msg3 ZTE
R1-2111031 Remaining issues on Type A PUSCH repetitions for Msg3 vivo
R1-2111110 Discussion on Type A PUSCH repetitions for Msg3 Spreadtrum Communications
R1-2111275 Discussion on Type A PUSCH repetitions for Msg3 CATT
R1-2111332 Type A PUSCH repetitions for Msg3 coverage OPPO
R1-2111431 Remaining issues on type A PUSCH repetitions for Msg3 China Telecom
R1-2111440 Discussion on Type A PUSCH repetitions for Msg.3 Panasonic Corporation
R1-2111511 On Msg3 PUSCH repetition Intel Corporation
R1-2111588 Discussion on Type A PUSCH repetition for Msg3 Xiaomi
R1-2111624 Discussion on type A PUSCH repetitions for Msg3 CMCC
R1-2111755 Type A PUSCH repetitions for Msg3 Samsung
R1-2111796 Type A PUSCH repetitions for Msg3 InterDigital, Inc.
R1-2111891 Discussion on Msg3 Coverage Enhancement Apple
R1-2111982 Discussion on coverage enhancement for Msg3 PUSCH LG Electronics
R1-2111994 Type A PUSCH repetitions for Msg3 ETRI
R1-2112023 Type A PUSCH repetitions for Msg3 Sharp
R1-2112039 Remaining Issues for Type A PUSCH Repetition for Msg3 Ericsson
R1-2112123 Type A PUSCH repetitions for Msg3 NTT DOCOMO, INC.
R1-2112234 Type A PUSCH repetition for Msg3 Qualcomm Incorporated
R1-2112393 Discussion on Type A PUSCH repetitions for Msg3 WILUS Inc.
[107-e-NR-R17-CovEnh-05] – Xianghui (ZTE)
Email discussion regarding Type A PUSCH repetitions for Msg 3
- 1st check point: November 15
- Final check point: November 19
R1-2112556 Feature lead summary #1 on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
From Nov 15th GTW session
Possible Agreement
· For indication of the number of repetitions of Msg3 initial transmission, Alt 1 (i.e., using TDRA information field) is adopted.
Support：12 companies
Possible Agreement 2
· For indication of the number of repetitions of Msg3 initial transmission, Alt 2 (i.e., using MCS information field) is adopted.
Support: 10 companies
Decision: As per email decision posted on Nov 16th,
Agreement
Flexible symbol indicated by tdd-UL-DL-ConfigurationCommon and not overlapped with SSB symbols indicated by ssb-PositionsInBurst can be regarded as available symbols for Msg3 PUSCH repetition.
· Note: whether and how to introduce other potential mechanisms to use the flexible symbols are separately discussed.
· Note: The Rel-15/16 rules are reused for collision handling between Msg3 PUSCH transmission and a CORESET for Type0-PDCCH CSS set indicated to a UE by pdcch-ConfigSIB1 in MIB in a set of flexible symbols indicated by tdd-UL-DL-ConfigurationCommon.
Conclusion
There is no consensus to additionally introduce explicit indication to indicate whether or not flexible slots/symbols configured via TDD-UL-DL-Configcommon are available for Msg3 repetition.
Agreement
RV cycling for Msg3 PUSCH repetition is based on transmission occasions on available slots.
Agreement
For inter-slot FH for Msg3 PUSCH repetition, adopt the following legacy rules.
· The Rel-16 RB offset determination mechanism defined in Table 8.3-1 of TS 38.213 for intra-slot FH for Msg3 PUSCH is reused.
· The Rel-16 additional DMRS configuration defined in Clause 6.2.2 of TS 38.214 for Msg3 PUSCH in case intra-slot FH is disabled is reused.
· The Rel-16 inter-slot FH pattern defined in Clause 6.3.1 of TS 38.214 for PUSCH repetition type A is reused.
R1-2112557 Feature lead summary #2 on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
R1-2112558 Feature lead summary #3 on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
From Nov 19th GTW session
Agreement
· For indication of the number of repetitions of Msg3 initial transmission, Alt 2 (i.e., using MCS information field) is adopted.
o Four candidate MCS indexes can be configured by SIB1 for Msg3 initial transmission. MCS 0~3 are applied if the configuration is absent.
o If the four candidate repetition factors are not configured, the default values are {1, 2, 3, 4}.
Agreement
For repetition indication for Msg3 re-transmission, Option 1 (i.e., use the same mechanism as supported for Msg3 initial transmission) is adopted.
FFS: [8] MCS index to be used for Msg3 re-transmission
Decision: As per email decision posted on Nov 20th,
Agreement
Reuse legacy collision handling rule between Msg3 PUSCH transmission and downlink symbols indicated by tdd-UL-DL-ConfigurationDedicated.
· Note: there is no specification impact.
Working assumption
Support repetition for a PUSCH scheduled by RAR UL grant, including both Msg3 PUSCH and CFRA PUSCH.
· Use the same mechanism of Msg3 PUSCH repetition, when applicable, for CFRA PUSCH with repetitions.
o No separate CFRA preamble/RO for repetition of CFRA PUSCH is introduced.
o No additional optimization specific for CFRA PUSCH is considered for CFRA PUSCH with repetition.
· No additional RAN1 specification impact
Note: UE reports Msg3 repetition capability after initial access.
Note: The working assumption can be confirmed only if no additional RAN1 specification impact nor optimization specific for CFRA PUSCH.
Final summary in R1-2112836.
R1-2110868 Discussion on the dependency of RRC parameters for counting on available slots and TBoMS Nokia, Nokia Shanghai Bell
R1-2110923 Discussion on RRC parameters for coverage enhancement ZTE
R1-2111032 Enhanced contention resolution mechanism for CBRA procedure with MSG3 PUSCH repetition vivo
R1-2111589 Other considerations for coverage enhancement xiaomi
R1-2112040 Frequency Hopping for TBoMS Ericsson
R1-2112401 On futher potential coverage enhancements Huawei, HiSilicon
Please refer to RP-211566 for detailed scope of the WI. Please also refer to slide 5 of R1-2200001 for additional guidance for this e-meeting.
R1-2200794 Session notes for 8.8 (NR coverage enhancement) Ad-hoc Chair (CMCC)
[107bis-e-R17-RRC-CovEnh] – Jianchi (China Telecom)
Email discussion on Rel-17 RRC parameters for Coverage Enhancement
- Email discussion to start on January 20 and end by January 25
The thread [107bis-e-R17-RRC-CovEnh] was not kicked off, since the moderator (CMCC) agreed that each Feature Lead took care of the RRC parameters of their respective sub-agenda. Agreements on the corresponding RRC parameters are included below.
R1-2200051 Discussion on coverage enhancements for PUSCH repetition type A Huawei, HiSilicon
R1-2200086 Remaining issues on enhancement for PUSCH repetition type A vivo
R1-2200111 Discussion on remaining issues for enhanced PUSCH repetition type A ZTE
R1-2200160 Enhancements on PUSCH repetition type A Nokia, Nokia Shanghai Bell
R1-2200205 Enhancements on PUSCH repetition type A Samsung
R1-2200301 Enhancements on PUSCH Repetition Type A Qualcomm Incorporated
R1-2200334 Enhancements on PUSCH repetition type A OPPO
R1-2200379 Remaining details of enhancements on PUSCH repetition type A Intel Corporation
R1-2200420 Discussion on PUSCH repetition type A enhancement Apple
R1-2200500 Enhancements on PUSCH repetition type A Sharp
R1-2200518 Type-A PUSCH repetition for coverage enhancement InterDigital, Inc.
R1-2200588 Remaining issues on PUSCH repetition type A enhancement CMCC
R1-2200655 Remaining Issues for PUSCH Repetition Type A Enhancement Ericsson
[107bis-e-R17-CovEnh-01] – Toshi (Sharp)
Email discussion regarding enhancements for PUSCH repetition type A
- 1st check point: January 20
- Final check point: January 25
R1-2200685 FL Summary #1 on Enhancements on PUSCH repetition type A Moderator (Sharp)
From Jan 18th GTW session
Conclusion
No consensus to introduce pusch-AggregationFactor-r17.
R1-2200686 FL Summary #2 on Enhancements on PUSCH repetition type A Moderator (Sharp)
From Jan 20th GTW session
Agreement
· Remove the notes from “Per (UE, cell, TRP, …)” and “Comment” columns of the existing AvailableSlotCounting in the consolidated RRC parameter list.
· If separate FGs are defined for DG-PUSCH and CG-PUSCH, add another AvailableSlotCounting to the consolidated RRC parameter list, with the following contents.
|
WI code |
Sub-feature group |
RAN1 specification |
Section |
RAN2 Parant IE |
RAN2 ASN.1 name |
Parameter name in the spec |
New or existing? |
Parameter name in the text |
Description |
Value range |
Default value aspect |
Per (UE, cell, TRP, …) |
UE-specific or Cell-specific |
Specification |
Comment |
|
NR_cov_enh-Core |
Enhancement on PUSCH repetition Type A |
|
|
|
|
AvailableSlotCounting |
new |
|
Enabling PUSCH repetitions counted on the basis of available slots |
ENUMERATED {enabled, disable } |
|
in
ConfiguredGrantConf |
UE-specific |
38.331 |
Agreement: |
Conclusion
The cancellation of LP PUSCH (introduced in Rel-17 eIIoT/URLLC WI) is applied in Step 2 of the previously agreed 2-step procedure of Rel-17 PUSCH repetitions counted on the basis of available slots (i.e., Option 1-B).
· No specification impact is expected.
R1-2200687 FL Summary #3 on Enhancements on PUSCH repetition type A Moderator (Sharp)
From Jan 24th GTW session
Conclusion
· The CovEnh discussion on the available slot counting for inter-cell mTRPs is deferred until further progress on the collision handling between UL channels/signals and multiple SSBs for inter-cell mTRPs is made in feMIMO session.
Final summary in R1-2200789.
R1-2200052 Discussion on TB processing over multi-slot PUSCH Huawei, HiSilicon
R1-2200087 Remaining issues on PUSCH TB processing over multiple slots vivo
R1-2200112 Discussion on remaining issues for TB processing over multi-slot PUSCH ZTE
R1-2200152 Remaining issues on TB processing over multi-slot PUSCH CATT
R1-2200161 Transport block processing for PUSCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2200206 TB processing over multi-slot PUSCH Samsung
R1-2200237 TB processing over multi-slot PUSCH NTT DOCOMO, INC.
R1-2200302 TB processing over multi-slot PUSCH Qualcomm Incorporated
R1-2200321 Discussion on TB processing over multi-slot PUSCH Panasonic Corporation
R1-2200335 Further considerations for TB over multi-slot PUSCH OPPO
R1-2200380 Remaining details on TB processing over multi-slot PUSCH Intel Corporation
R1-2200421 Discussion on TB processing over multi-slot PUSCH Apple
R1-2200466 Discussion on TB processing over multi-slot PUSCH xiaomi
R1-2200501 TB processing over multi-slot PUSCH Sharp
R1-2200509 Discussion on remaining issue of TBoMS NEC
R1-2200519 TB processing over multiple slots InterDigital, Inc.
R1-2200589 Remaining issues on TB processing over multi-slot PUSCH CMCC
R1-2200604 Discussion on TBoMS PUSCH TCL Communication Ltd.
R1-2200656 Remaining Issues for TB Processing over Multi-Slot PUSCH Ericsson
[107bis-e-R17-CovEnh-02] – Marco (Nokia)
Email discussion regarding TB processing over multi-slot PUSCH
- 1st check point: January 20
- Final check point: January 25
R1-2200680 FL summary of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia)
From Jan 18th GTW session
Conclusion
There is no consensus in RAN1 on
whether the index of the starting coded bit in the circular buffer should be
expressed as function of the lifting size 
.
Agreement
The Rel-16 per-slot transmission occasion definition is re-used for transmission power determination for TBoMS.
R1-2200750 FL summary #2 of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia/Nokia Shanghai Bell)
Decision: As per email decision posted on Jan 23rd,
Conclusion
· Configuration and/or indication of priority of TBoMS transmission is up to gNB.
· No new TBoMS-specific collision handling and dropping rules are introduced.
Agreement
The following text proposal for TS 38.213, Clause 9.2.6, is adopted.
|
9.2.6 PUCCH repetition procedure <omitted text> If a UE would transmit a PUCCH over a first number <omitted text> |
Conclusion
Existing rules can be reused for UCI multiplexing on PUSCH in case of TBoMS and UL CA scenario.
Agreement
A UE that supports TBoMS supports all values of N defined for TBoMS, and a UE that supports TBoMS repetition supports all values of M defined for TBoMS repetition.
Agreement
The use of TBoMS for HD-FDD UE with counting on available slot is supported.
Note: Existing mechanism as in AI8.8.1.1 should be applied for this case
Decision: As per email decision posted on Jan 24th,
Agreement
· For CG-PUSCH transmissions of TBoMS, the UE is not expected to be configured with the time duration for the N*M transmissions larger than the time duration derived by the periodicity P.
Final summary in
R1-2200752 Final FL summary of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia/Nokia Shanghai Bell)
R1-2200053 Discussion on joint channel estimation for PUSCH Huawei, HiSilicon
R1-2200088 Remaining issues on joint channel estimation for PUSCH vivo
R1-2200113 Discussion on remaining issues for joint channel estimation for PUSCH ZTE
R1-2200162 Joint channel estimation for PUSCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2200207 Joint channel estimation for PUSCH Samsung
R1-2200238 Joint channel estimation for PUSCH NTT DOCOMO, INC.
R1-2200268 Discussion on joint channel estimation for PUSCH Panasonic Corporation
R1-2200279 Discussion on joint channel estimation for PUSCH Spreadtrum Communications
R1-2200303 Joint channel estimation for PUSCH Qualcomm Incorporated
R1-2200336 Consideration on Joint channel estimation for PUSCH OPPO
R1-2200381 Remaining details on joint channel estimation for PUSCH Intel Corporation
R1-2200422 Discussion on joint channel estimation for PUSCH Apple
R1-2200467 Discussion on joint channel estimation for PUSCH xiaomi
R1-2200486 Remaining issues on joint channel estimation China Telecom
R1-2200499 Joint channel estimation for PUSCH Sharp
R1-2200520 Discussions on joint channel estimation InterDigital, Inc.
R1-2200553 Discussion on Joint channel estimation over multi-slot MediaTek Inc.
R1-2200590 Remaining issues on joint channel estimation for PUSCH CMCC
R1-2200613 Discussions on joint channel estimation for PUSCH LG Electronics
R1-2200657 Remaining Issues for Joint Channel Estimation for PUSCH Ericsson
[107bis-e-R17-CovEnh-03] – Jianchi (China Telecom)
Email discussion regarding joint channel estimation for PUSCH
- 1st check point: January 20
- Final check point: January 25
R1-2200487 FL Summary of joint channel estimation for PUSCH Moderator (China Telecom)
From Jan 18th GTW session
Proposal:
· No redefinition of transmission occasion for PUSCH/PUCCH in Rel-17.
R1-2200735 FL Summary#2 of joint channel estimation for PUSCH Moderator (China Telecom)
From Jan 20th GTW session
Conclusion
· It is not expected to redefine transmission occasion for PUSCH/PUCCH for DMRS bundling in Rel-17.
Agreement
· The value range of PUSCH-TimeDomainWindowLength is INTEGER (2..[32]).
· The value range of PUCCH-TimeDomainWindowLength is INTEGER (2..[8]).
o Note: the value shall not exceed the maximum duration.
Decision: As per email decision posted on Jan 21st,
Agreement
· Adopt the following TP to TS 38.214
|
6.1.7 UE procedure for determining time domain windows for bundling DM-RS < unchanged text omitted> - For PUCCH transmissions of PUCCH repetition, a dropping or cancellation of a PUCCH transmission according to clause 9, clause 9.2.6 and clause 11.1 of [6, TS 38.213]. < unchanged text omitted> |
Agreement
Send an LS to RAN4 asking the following question
· For extended CP, is 11-symbol the maximum length for the non-zero un-scheduled gap in-between the PUSCH transmission or PUCCH repetition, when UE is required to maintain power consistency and phase continuity?
R1-2200773 LS on DMRS bundling for PUSCH and PUCCH RAN1, China Telecom
Decision: As per email decision posted on Jan 23rd, the LS to RAN4 is approved.
R1-2200736 FL Summary#3 of joint channel estimation for PUSCH Moderator (China Telecom)
Decision: As per email decision posted on Jan 25th,
Agreement
· If DMRS bundling and UL beam switching for multi-TRP operation are configured simultaneously, UL beam switching for multi-TRP operation is regarded as a semi-static event.
Agreement
Update the description of the RRC parameters PUSCH-Window-Restart and PUCCH-Window-Restart as follows.
· UE bundles PUSCH DM-RS remaining in a nominal time domain window after event(s) triggered by DCI or MAC-CE that violate power consistency and phase continuity requirements
· UE bundles PUCCH DM-RS remaining in a nominal time domain window after event(s) triggered by DCI or MAC-CE that violate power consistency and phase continuity requirements
Note: Events which are triggered by DCI or MAC CE, but regarded as semi-static events, e.g. frequency hopping, UL beam switching for multi-TRP operation, or other if defined, are excluded.
Final summary in R1-2200790.
Including dynamic PUCCH repetition factor indication, and DMRS bundling across PUCCH repetitions (When applicable, based on similar mechanism(s) for enabling joint channel estimation for PUSCH).
R1-2200054 Discussion on PUCCH coverage enhancement Huawei, HiSilicon
R1-2200089 Remaining issues on PUCCH enhancements vivo
R1-2200114 Discussion on remaining issues for coverage enhancements for PUCCH ZTE
R1-2200153 Remaining issues on PUCCH enhancements CATT
R1-2200163 PUCCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2200208 PUCCH enhancements Samsung
R1-2200239 PUCCH enhancements for coverage enhancement NTT DOCOMO, INC.
R1-2200280 Discussion on PUCCH enhancements Spreadtrum Communications
R1-2200304 PUCCH enhancements Qualcomm Incorporated
R1-2200322 Discussion on the interaction between inter-slot frequency hopping and DMRS bundling Panasonic Corporation
R1-2200337 PUCCH enhancements for coverage OPPO
R1-2200382 Remaining details on PUCCH enhancements Intel Corporation
R1-2200423 Further discussion on PUCCH coverage enhancement Apple
R1-2200468 Discussion on PUCCH enhancements xiaomi
R1-2200488 Remaining issues on inter-slot frequency hopping with inter-slot bundling for PUCCH and PUSCH China Telecom
R1-2200502 PUCCH coverage enhancement Sharp
R1-2200521 Discussions on PUCCH enhancements InterDigital, Inc.
R1-2200591 Remaining issues on PUCCH enhancements CMCC
R1-2200614 Discussions on coverage enhancement for PUCCH LG Electronics
R1-2200636 Remaining issues on PUCCH enhancements for coverage enhancement WILUS Inc.
R1-2200658 Remaining Issues for PUCCH Dynamic Repetition and DMRS Bundling Ericsson
[107bis-e-R17-CovEnh-04] – Yi (Qualcomm)
Email discussion regarding PUCCH enhancements
- 1st check point: January 20
- Final check point: January 25
R1-2200708 FL summary #1 of PUCCH coverage enhancement Moderator (Qualcomm)
From Jan 18th GTW session
Agreement
In column J of RRC parameter “PUCCH-nrofSlots-r17”, add a note as the following:
· Note: a PUCCH resource not configured with PUCCH-nrofSlots-r17 can attain the value of 1 according to when the Rel-15/16 parameter nrofSlots is not configured.
R1-2200754 FL summary #2 of PUCCH coverage enhancement Moderator (Qualcomm)
From Jan 20th GTW session
Agreement
For PUCCH repetitions and PUSCH repetitions with DMRS bundling, introduce the following two RRC parameters for frequency hopping interval configuration.
· PUCCH-Frequencyhopping-Interval
· PUSCH-Frequencyhopping-Interval
Note: finalize the details (such as value range, parent IE, etc…) of these two RRC parameters in RAN1 107#bis-e.
Agreement
PUCCH repetitions with different sets of power control parameters in multi-TRP operation should be regarded as a [semi-static] event that causes power consistency and phase continuity not to be maintained across PUCCH repetitions.
R1-2200774 FL summary #3 of PUCCH coverage enhancement Moderator (Qualcomm)
From Jan 24th GTW session
Agreement
· The RRC parameter “PUCCH-DMRS-Bundling” is per UL BWP, and the RRC parameter “PUCCH-TimeDomainWindowLength” is per UL BWP.
o PUCCH DMRS bundling is not supported for PUCCH format 0/2.
Decision: As per email decision posted on Jan 26th,
Agreement
Adopt the following table for the RRC parameters PUCCH-nrofSlots-r17, PUCCH-DMRS-Bundling, PUCCH-TimeDomainWindowLength, PUCCH-Window-Restart, PUCCH-Frequencyhopping-Interval, and PUSCH-Frequencyhopping-Interval.
|
WI code |
Sub-feature group |
Parameter name in the spec |
New or existing? |
Description |
Value range |
Default value aspect |
Per (UE, cell, TRP, …) |
UE-specific or Cell-specific |
|
NR_cov_enh-Core |
PUCCH enhancements |
PUCCH-nrofSlots-r17 |
new |
A new repetition parameter corresponding to Rel-17 dynamic PUCCH repetition factor indication. The new repetition parameter is configured per PUCCH resource and should be in PUCCH-Resource. Note: a PUCCH resource not configured with PUCCH-nrofSlots-r17 can attain the value of 1 according to when the Rel-15/16 parameter nrofSlots is not configured. |
ENUMERATED {2, 4, 8} |
|
In PUCCH-resource |
UE-specific |
|
NR_cov_enh-Core |
DM-RS bundling for PUCCH |
PUCCH-DMRS-Bundling |
new |
Enabling/disabling of DM-RS bundling and time domain window for PUCCH repetitions. |
ENUMERATED {enabled, disable } |
|
in PUCCH-Config Note: The RRC parameter “PUCCH-DMRS-Bundling” is per UL BWP. PUCCH DMRS Bundling is not supported for PUCCH format 0/2 |
UE-specific |
|
NR_cov_enh-Core |
DM-RS bundling for PUCCH |
PUCCH-TimeDomainWindowLength |
new |
Length of a |
INTEGER (2..[8]) Note: the value shall not exceed the maximum duration |
|
in PUCCH-Config Note: The RRC parameter “PUCCH-TimeDomainWindowLength” is per UL BWP. PUCCH DMRS Bundling is not supported for PUCCH format 0/2 |
UE-specific |
|
NR_cov_enh-Core |
DM-RS bundling for PUCCH |
PUCCH-Window-Restart |
new |
UE bundles PUCCH DM-RS remaining
in a nominal time domain window after Note: Events, which are triggered by DCI or MAC CE, but regarded as semi-static events, e.g. frequency hopping, UL beam switching for multi-TRP operation, or other if defined, are excluded. |
ENUMERATED {enabled, disable } |
|
in PUCCH-Config |
UE-specific |
|
NR_cov_enh-Core |
DM-RS bundling for PUCCH |
PUCCH-Frequencyhopping-Interval |
New |
Number of consecutive slots for UE to perform Rel-17 inter-slot frequency hopping with inter-slot bundling for PUCCH Note: When DMRS bundling for PUCCH is enabled by PUCCH-DMRS-Bundling, PUCCH frequency hopping interval is only determined by the configuration of PUCCH hopping interval if PUCCH hopping interval is configured.
|
FFS |
PUCCH-TimeDomainWindowLength |
in PUCCH-Config |
UE-specific |
|
NR_cov_enh-Core |
DM-RS bundling for PUSCH |
PUSCH-Frequencyhopping-Interval |
New |
Number of consecutive slots for UE to perform Rel-17 inter-slot frequency hopping with inter-slot bundling for PUSCH. Note 1: This RRC parameter is shared for both DG-PUSCH and CG-PUSCH Note 2: When DMRS bundling for PUSCH is enabled by PUSCH-DMRS-Bundling, PUSCH frequency hopping interval is only determined by the configuration of PUSCH hopping interval if PUSCH hopping interval is configured.
|
FFS |
PUSCH-TimeDomainWindowLength |
in PUSCH-Config |
UE-specific |
Agreement
The same mechanism supporting inter-slot frequency hopping with inter-slot bundling for DMRS bundling for type-A PUSCH repetitions is reused for TBoMS with/without repetitions.
· No optimization of FH mechanism specific to TBoMS with repetitions
Final summary in R1-2200806.
R1-2200055 Discussion on Msg3 repetition for coverage enhancement Huawei, HiSilicon
R1-2200090 Remaining issues on Type A PUSCH repetitions for Msg3 vivo
R1-2200115 Discussion on remaining issues for Type A PUSCH repetitions for Msg3 ZTE
R1-2200154 Remaining issues on Type A PUSCH repetitions for Msg3 CATT
R1-2200164 Approaches and solutions for Type A PUSCH repetitions for Msg3 Nokia, Nokia Shanghai Bell
R1-2200209 Type A PUSCH repetitions for Msg3 Samsung
R1-2200240 Type A PUSCH repetitions for Msg3 NTT DOCOMO, INC.
R1-2200305 Type A PUSCH repetition for Msg3 Qualcomm Incorporated
R1-2200323 Discussion on Type A PUSCH repetitions for Msg.3 Panasonic Corporation
R1-2200338 Type A PUSCH repetitions for Msg3 coverage OPPO
R1-2200383 Remaining details on Msg3 PUSCH repetition Intel Corporation
R1-2200424 On remaining issues for Msg3 Coverage Enhancement Apple
R1-2200469 Discussion on Type A PUSCH repetition for Msg3 xiaomi
R1-2200489 Remaining issues on type A PUSCH repetitions for Msg3 China Telecom
R1-2200503 Type A PUSCH repetitions for Msg3 Sharp
R1-2200522 Type A PUSCH repetitions for Msg3 InterDigital, Inc.
R1-2200592 Remaining issues on type A PUSCH repetitions for Msg3 CMCC
R1-2200615 Discussion on coverage enhancement for Msg3 PUSCH LG Electronics
R1-2200637 Remaining issues on Type A PUSCH repetitions for Msg3 WILUS Inc.
R1-2200659 Remaining Issues for Type A PUSCH Repetition for Msg3 Ericsson
[107bis-e-R17-CovEnh-05] – Xianghui (ZTE)
Email discussion regarding Type A PUSCH repetitions for Msg 3
- 1st check point: January 20
- Final check point: January 25
R1-2200712 Feature lead summary #1 on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
From Jan 18th GTW session
Proposal for Issue#1:
The 3 LSB bits of MCS information field in DCI format 0_0 with CRC scrambled by the TC-RNTI is used to indicate one value from 8 candidate MCS indexes for Msg3 retransmission.
· Option 1-A: The 8 candidate MCS indexes are MCS 0~7.
o Support/Can live with: Nokia/NSB, Sharp, Panasonic, Qualcomm, Apple, WILUS, China Telecom, NTT DOCOMO, CMCC, Spreadtrum, ZTE, Huawei/HiSilicon, LG Electronics
· [Option 1-B: The 8 candidate MCS indexes can be configured by SIB1, MCS 0~7 are applied if the configuration is absent. The first 4 indexes of the 8 candidate MCS indexes are used for initial PUSCH transmission scheduled by RAR UL grant.]
o Support/Can live with: Samsung, Intel, OPPO, LG Electronics, Ericsson, CATT, CMCC, Nokia/NSB, ZTE
Agreement
Regarding how a UE should interpret MCS information field for indication of the number of repetitions for the case of CBRA, Option 1 is supported.
· When a UE requests Msg3 repetition, the repurposed MCS information field is applied. gNB schedules Msg3 with or without repetition for the UE requesting Msg3 repetition.
o Repetition factor K=1 is included in the four candidate repetition factors used for repetition indication.
· When the UE doesn’t request Msg3 repetition (including legacy UE), the legacy MCS information field is applied. gNB schedules Msg3 without repetition for the UE not requesting Msg3 repetition.
R1-2200713 Feature lead summary #2 on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
From Jan 20th GTW session
Agreement
The 3 LSB bits of MCS information field in DCI format 0_0 with CRC scrambled by the TC-RNTI is used to indicate one value from 8 candidate MCS indexes for Msg3 retransmission.
· The 8 candidate MCS indexes can be configured by SIB1, MCS 0~7 are applied if the configuration is absent. The first 4 indexes of the 8 candidate MCS indexes are used for initial PUSCH transmission scheduled by RAR UL grant.
Decision: As per email decision posted on Jan 21st,
Agreement
For the number of repetitions configured by numberOfMsg3Repetitions, support {1, 2, 3, 4, 7, 8, 12, 16}.
Conclusion
For Rel-17 CE WI, Issue (4~7) in Section 2.6 of R1-2200712 will not be discussed in RAN1 in future meetings, and issue (1~3) in Section 2.6 of R1-2200712 can only be discussed in RAN1 if requested by other WGs.
Decision: As per email decision posted on Jan 23rd,
Agreement
All slots are considered as available slots for Msg3 repetition for both FD-FDD UEs and HD-FDD RedCap UEs.
R1-2200714 Feature lead summary #3 on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
From Jan 24th GTW session
Agreement
Introduce the following the RRC parameter for indication of the number of repetitions for PUSCH repetition scheduled by RAR UL grant and DCI format 0_0 with CRC scrambled by TC-RNTI.
|
WI code |
Sub-feature group |
Parameter name in the spec |
New or existing? |
Description |
Value range |
Default value aspect |
Per (UE, cell, TRP, …) |
UE-specific or Cell-specific |
Specification |
Comment |
|
NR_cov_enh-Core |
Type A PUSCH repetitions for Msg3 |
numberOfMsg3Repetitions |
new |
The number of repetitions for PUSCH transmission scheduled by RAR UL grant and DCI format 0_0 with CRC scrambled by TC-RNTI |
SEQUENCE (SIZE (4)) OF INTEGER (1,2, 3, 4, 7, 8, 12, 16) |
{1, 2, 3, 4} |
RACH-ConfigCommon |
Cell-specific |
38.331 |
Working Assumption Down-select only one from the following methods for indication of the number of repetitions of Msg3 initial transmission. · Alt 1: If TDRA information field is chosen, Option 2 is supported. o The candidate values for repetition factor could be chosen from {[1], 2, 3, 4, 7, 8, [12], [16]} · Alt 2: If MCS information field is chosen, repurpose the MCS information field as follows. o 2 MSB bits of the MCS information field are used for selecting one repetition factor from a SIB1 configured set with 4 candidate values. § The set of candidate values for repetition factor could be chosen from {[1], 2, 3, 4, 7, 8, [12], [16]} Note: Whether ‘1’ is included depends on the outcome of interpretation of the selected information field.
Agreements l For indication of the number of repetitions of Msg3 initial transmission, Alt 2 (i.e., using MCS information field) is adopted. n Four candidate MCS indexes can be configured by SIB1 for Msg3 initial transmission. MCS 0~3 are applied if the configuration is absent. If the four candidate repetition factors are not configured, the default values are {1, 2, 3, 4}.
Agreement For repetition indication for Msg3 re-transmission, Option 1 (i.e., use the same mechanism as supported for Msg3 initial transmission) is adopted. FFS: [8] MCS index to be used for Msg3 re-transmission
Working assumption : support repetition for a PUSCH scheduled by RAR UL grant, including both Msg3 PUSCH and CFRA PUSCH. n Use the same mechanism of Msg3 PUSCH repetition, when applicable, for CFRA PUSCH with repetitions. u No separate CFRA preamble/RO for repetition of CFRA PUSCH is introduced. u No additional optimization specific for CFRA PUSCH is considered for CFRA PUSCH with repetition. n No additional RAN1 specification impact Note: UE reports Msg3 repetition capability after initial access. Note: The working assumption can be confirmed only if no additional RAN1 specification impact nor optimization specific for CFRA PUSCH.
Agreement Regarding how a UE should interpret MCS information field for indication of the number of repetitions for the case of CBRA, Option 1 is supported. l When a UE requests Msg3 repetition, the repurposed MCS information field is applied. gNB schedules Msg3 with or without repetition for the UE requesting Msg3 repetition. n Repetition factor K=1 is included in the four candidate repetition factors used for repetition indication. When the UE doesn’t request Msg3 repetition (including legacy UE), the legacy MCS information field is applied. gNB schedules Msg3 without repetition for the UE not requesting Msg3 repetition.
Agreement For the number of repetitions configured by numberOfMsg3Repetitions, support {1, 2, 3, 4, 7, 8, 12, 16}. |
Agreement
Introduce the following the RRC parameter for indication of the MCS index for PUSCH repetition scheduled by RAR UL grant and DCI format 0_0 with CRC scrambled by TC-RNTI.
|
WI code |
Sub-feature group |
Parameter name in the spec |
New or existing? |
Description |
Value range |
Default value aspect |
Per (UE, cell, TRP, …) |
UE-specific or Cell-specific |
Specification |
Comment |
|
NR_cov_enh-Core |
Type A PUSCH repetitions for Msg3 |
mcs-Msg3Repetition |
new |
Configure eight candidate MCS indexes for PUSCH transmission scheduled by RAR UL grant and DCI format 0_0 with CRC scrambled by TC-RNTI. Only the first 4 configured or default MCS indexes are used for PUSCH transmission scheduled by RAR UL grant.
|
SEQUENCE (SIZE (8)) OF INTEGER (0..31)
|
{0, 1, 2, 3, 4, 5, 6, 7} |
RACH-ConfigCommon |
Cell-specific |
38.331 |
Agreements l For indication of the number of repetitions of Msg3 initial transmission, Alt 2 (i.e., using MCS information field) is adopted. n Four candidate MCS indexes can be configured by SIB1 for Msg3 initial transmission. MCS 0~3 are applied if the configuration is absent. If the four candidate repetition factors are not configured, the default values are {1, 2, 3, 4}.
Agreement For repetition indication for Msg3 re-transmission, Option 1 (i.e., use the same mechanism as supported for Msg3 initial transmission) is adopted. FFS: [8] MCS index to be used for Msg3 re-transmission
Working assumption : support repetition for a PUSCH scheduled by RAR UL grant, including both Msg3 PUSCH and CFRA PUSCH. n Use the same mechanism of Msg3 PUSCH repetition, when applicable, for CFRA PUSCH with repetitions. u No separate CFRA preamble/RO for repetition of CFRA PUSCH is introduced. u No additional optimization specific for CFRA PUSCH is considered for CFRA PUSCH with repetition. n No additional RAN1 specification impact Note: UE reports Msg3 repetition capability after initial access. Note: The working assumption can be confirmed only if no additional RAN1 specification impact nor optimization specific for CFRA PUSCH.
Agreement The 3 LSB bits of MCS information field in DCI format 0_0 with CRC scrambled by the TC-RNTI is used to indicate one value from 8 candidate MCS indexes for Msg3 retransmission. The 8 candidate MCS indexes can be configured by SIB1, MCS 0~7 are applied if the configuration is absent. The first 4 indexes of the 8 candidate MCS indexes are used for initial PUSCH transmission scheduled by RAR UL grant. |
Conclusion
· Same Tx beam is applied for all repetitions of Msg3 initial transmission scheduled by a RAR UL grant.
o It is up to UE implementation how the Tx beam forms.
· Same Tx beam is applied for all repetitions of Msg3 re-transmission scheduled by a DCI scrambled with TC-RNTI.
o It is up to UE implementation how the Tx beam forms.
Decision: As per email decision posted on Jan 26th,
Agreement
· Adopt the text proposal for Clause 7.3.1.1.1 in TS 38.212 h00 as in the Appendix section of R1-2200802.
Agreement
· Adopt the text proposal for Clause 6.1.4.1 in TS 38.214 h00 as in the Appendix section of R1-2200802.
Agreement
· Adopt the text proposal for Clause 8.3 in TS38.213 h00 as in the Appendix section of R1-2200802.
Final summary in
R1-2200802 Feature lead summary #4 on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
R1-2200116 Discussion on RRC parameters for coverage enhancement ZTE
R1-2200165 Performance of Type A PUSCH repetitions for Msg3 for different MCS index configurations Nokia, Nokia Shanghai Bell
R1-2200470 Other considerations for coverage enhancement xiaomi
R1-2200563 Remaining issues on RRC parameters for NR coverage enhancement vivo
R1-2200653 Other considerations for coverage enhancement Huawei, HiSilicon
R1-2200660 Frequency Hopping for TBoMS Ericsson
Please refer to RP-211566 for detailed scope of the WI.
Please also refer to section 5 of RP-212555 for additional guidance for this e-meeting.
R1-2202788 Session notes for 8.8 (NR coverage enhancement) Ad-hoc Chair (CMCC)
[108-e-R17-RRC-CovEnh] – Jianchi (China Telecom)
Email discussion on Rel-17 RRC parameters for Coverage Enhancement
- 1st check point for first LS in [108-e-R17-RRC]: February 24
- Final check point for second LS in [108-e-R17-RRC] if necessary: March 3
The thread [108-e-R17-RRC-CovEnh] was not kicked off, since the moderator (China Telecom) agreed that each Feature Lead take care of the RRC parameters of their respective sub-agenda. Agreements on the corresponding RRC parameters are included below.
[108-e-R17-CovEnh-06] – Jianchi (China Telecom)
Email discussion for incoming LS on Stage 2 description for Coverage Enhancements
R1-2200879 LS on Stage 2 description for Coverage Enhancements RAN2, China Telecom
R1-2202868 [108-e-R17-CovEnh-06] Summary of email discussion for incoming LS on Stage 2 description for Coverage Enhancements Moderator (China Telecom)
R1-2202867 Reply LS on Stage 2 description for Coverage Enhancements RAN1, China Telecom
Decision: As per email decision posted on Mar 2nd, the reply LS to RAN2 LS (R2-2201784) is approved.
R1-2200966 Discussion on coverage enhancements for PUSCH repetition type A Huawei, HiSilicon
R1-2201012 Enhancements on PUSCH repetition type A Nokia, Nokia Shanghai Bell
R1-2201104 Remaining issues on enhancement for PUSCH repetition type A vivo
R1-2201164 Discussion on remaining issues for enhanced PUSCH repetition type A ZTE
R1-2201283 Enhancements on PUSCH repetition type A OPPO
R1-2201373 Remaining issues on enhancements on PUSCH repetition type A CATT
R1-2201380 Discussion on enhancements on PUSCH repetition Type A Panasonic Corporation
R1-2201442 Remaining issues on PUSCH repetition type A enhancements China Telecom
R1-2201487 Remaining issues on enhancements on PUSCH repetition type A NTT DOCOMO, INC.
R1-2201554 Discussion on enhancements for PUSCH repetition Type A Spreadtrum Communications
R1-2201657 Type-A PUSCH repetition for coverage enhancement InterDigital, Inc.
R1-2201708 Remaining details of enhancements on PUSCH repetition type A Intel Corporation
R1-2201780 Remaining issues on PUSCH repetition type A enhancement Apple
R1-2201868 Remaining issues on PUSCH repetition type A enhancement CMCC
R1-2201961 Remaining Issues for PUSCH Repetition Type A Enhancement Ericsson
R1-2202026 Enhancements on PUSCH repetition type A Samsung
R1-2202151 Enhancements on PUSCH Repetition Type A Qualcomm Incorporated
R1-2202196 Enhancements on PUSCH repetition type A Sharp
R1-2202239 Discussion on PUSCH repetition type A enhancement TCL Communication Ltd.
R1-2202299 Discussions on PUSCH repetition type A enhancements LG Electronics
R1-2202486 Remaining issues on enhancements for PUSCH repetition Type A WILUS Inc.
[108-e-R17-CovEnh-01] – Toshi (Sharp)
Email discussion regarding enhancements for PUSCH repetition type A
- 1st check point: February 25
- Final check point: March 3
R1-2202566 FL Summary #1 on Enhancements on PUSCH repetition type A Moderator (Sharp)
R1-2202567 FL Summary #2 on Enhancements on PUSCH repetition type A Moderator (Sharp)
Decision: As per email decision posted on Feb 24th,
Agreement
· Text proposal TP#B to TS38.214 clause 6.1.2.1 and clause 6.1.2.3.1, as in section 2.2.2 of R1-2202567 (1st round summary (Issue#2-2)) is endorsed
R1-2202568 FL Summary #3 on Enhancements on PUSCH repetition type A Moderator (Sharp)
Decision: As per email decision posted on Mar 3rd,
Agreement
· For DG-PUSCH repetition Type A scheduled by DCI format 0_1 or 0_2, the legacy counting method applies when K=1, regardless of whether AvailableSlotCounting is enabled or not
o Note: The legacy assumption on the K2 offset is applied, i.e., no RAN1 spec impact on the K2 offset is expected.
· For CG-PUSCH repetition Type A, the legacy counting method applies when K=1, regardless of whether AvailableSlotCounting is enabled or not.
o Note: No RAN1 spec impact is expected.
o Note: No additional restriction on CG periodicity configurations, compared to Rel-16, is considered for CG-PUSCH with K=1.
· For CG-PUSCH repetition Type A, when AvailableSlotCounting is enabled, and for K>1, a UE assumes that the slot (i.e., the first configured slot in a CG period) determined in 38.321 Section 5.8.2 can be the slot which is not counted in K available slots.
o Note: No RAN1 spec impact is expected.
Final summary in R1-2202569.
R1-2200967 Discussion on TB processing over multi-slot PUSCH Huawei, HiSilicon
R1-2201013 Transport block processing for PUSCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2201105 Remaining issues on PUSCH TB processing over multiple slots vivo
R1-2201165 Discussion on remaining issues for TB processing over multi-slot PUSCH ZTE
R1-2201284 Further considerations for TB over multi-slot PUSCH OPPO
R1-2201374 Remaining issues on TB processing over multi-slot PUSCH CATT
R1-2201381 Discussion on TB processing over multi-slot PUSCH Panasonic Corporation
R1-2201488 Remaining issues on TB processing over multi-slot PUSCH NTT DOCOMO, INC.
R1-2201658 TB processing over multiple slots InterDigital, Inc.
R1-2201709 Remaining details on TB processing over multi-slot PUSCH Intel Corporation
R1-2201781 Remaining issues on TB processing over multi-slot PUSCH Apple
R1-2201869 Remaining issues on TB processing over multi-slot PUSCH CMCC
R1-2201905 Discussion on remaining issue of TBoMS NEC
R1-2201925 Remaining issues on TB processing over multi-slot PUSCH Xiaomi
R1-2201962 Remaining Issues for TB Processing over Multi-Slot PUSCH Ericsson
R1-2202027 TB processing over multi-slot PUSCH Samsung
R1-2202152 TB processing over multi-slot PUSCH Qualcomm Incorporated
R1-2202197 TB processing over multi-slot PUSCH Sharp
R1-2202240 Discussion on TBoMS PUSCH TCL Communication Ltd.
R1-2202300 Discussions on TB processing over multi-slot PUSCH LG Electronics
R1-2202487 Remaining issues for TB processing over multi-slot PUSCH WILUS Inc.
[108-e-R17-CovEnh-02] – Marco (Nokia)
Email discussion regarding TB processing over multi-slot PUSCH
- 1st check point: February 25
- Final check point: March 3
R1-2202527 FL summary of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia)
From Feb 22nd GTW session
Agreement
For the bit selection of TBoMS:
· G in Clause 5.4.2.1 [and/or Clause 6.2.6] of TS 38.212 is defined for TBoMS as the total number of coded bits available for transmission of the transport block in a slot.
· Note: no intention to change the legacy behavior
For determining the index of the starting coded bit in the circular buffer for the n-th slot of a single TBoMS, RAN1 to down-select one of the following two options during RAN1 #108-e.
|
Option 1 The index of the starting coded bit in the circular
buffer for the Where: ·
·
·
·
·
Note: this equation describes the logic of the bit-selection for TBoMS; decision on where and how to capture this in TS 38.212 is up to the Editor. |
|
Option 2 Adopt the following TP for TS 38.212 5.4.2.1 Bit selection <Unchanged parts omitted> Denote
by |
R1-2202638 FL summary #2 of TB processing over multi-slot PUSCH (AI 8.8.1.2) Moderator (Nokia)
From Feb 24th GTW session
Agreement
The
index of the starting coded bit in the circular buffer for the 
-th slot of a single
TBoMS, i.e., 
, is calculated as
Where:
· k0 is given by Table 5.4.2.1-2.
·
is the number of slots allocated for TBoMS
·
is the length of circular buffer
·
is the total number of coded bits available for transmission of the
TB in a slot allocated for TBoMS, assuming no UCI multiplexing
·
is the number of filler bits that would be skipped in the bit
selection step, assuming no UCI multiplexing, in the 
-th slot allocated for TBoMS, if any.
Note: this equation describes the logic of the determining the starting coded bit in bit selection for TBoMS slot; decision on where and how to capture this or wording that is equivalent in TS 38.212 is up to the editor.
From Feb 28th GTW session
Conclusion
There is no consensus in RAN1 to support TBoMS for CG-Type 1.
Conclusion
The decision on whether to modify the definition of G in Clause 6.2.6 of TS 38.212 such that this parameter is described as the total number of coded bits available for transmission of the transport block in a slot is left to the Editor’s discretion.
Final summary in R1-2202640.
R1-2200968 Discussion on joint channel estimation for PUSCH Huawei, HiSilicon
R1-2201014 Joint channel estimation for PUSCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2201106 Remaining issues on joint channel estimation for PUSCH vivo
R1-2201166 Discussion on remaining issues for joint channel estimation for PUSCH ZTE
R1-2201285 Consideration on Joint channel estimation for PUSCH OPPO
R1-2201375 Remaining issues on joint channel estimation for PUSCH CATT
R1-2201434 Discussion on joint channel estimation for PUSCH Panasonic Corporation
R1-2201443 Remaining issues on joint channel estimation China Telecom
R1-2201489 Remaining issues on joint channel estimation for PUSCH NTT DOCOMO, INC.
R1-2201555 Discussion on joint channel estimation for PUSCH Spreadtrum Communications
R1-2201659 Discussion on joint channel estimation InterDigital, Inc.
R1-2201710 Remaining details on joint channel estimation for PUSCH Intel Corporation
R1-2201782 Remaining issues on cross-slot channel estimation for PUSCH Apple
R1-2201870 Remaining issues on joint channel estimation for PUSCH CMCC
R1-2201912 Remaining issues on joint channel estimation for PUSCH Xiaomi
R1-2201963 Remaining Issues for Joint Channel Estimation for PUSCH Ericsson
R1-2202028 Joint channel estimation for PUSCH Samsung
R1-2202085 Discussion on Joint channel estimation over multi-slot MediaTek Inc.
R1-2202153 Joint channel estimation for PUSCH Qualcomm Incorporated
R1-2202198 Joint channel estimation for PUSCH Sharp
R1-2202237 Discussion on joint channel estimation for PUSCH TCL Communication Ltd.
R1-2202301 Discussions on joint channel estimation for PUSCH LG Electronics
R1-2201444 FL Summary of joint channel estimation for PUSCH Moderator (China Telecom)
[108-e-R17-CovEnh-03] – Jianchi (China Telecom)
Email discussion regarding joint channel estimation for PUSCH
- 1st check point: February 25
- Final check point: March 3
R1-2202617 FL Summary#3 of joint channel estimation for PUSCH Moderator (China Telecom)
Decision: As per email decision posted on Feb 25th,
Agreement
· For HD-FDD RedCap UEs configured with DMRS bundling, an event is constituted for a case where a dropping or cancellation of a PUSCH transmission according dropping rules in [17.2, TS 38.213].
Decision: As per email decision posted on Mar 1st,
Agreement
· For HD-FDD RedCap UEs configured with DMRS bundling, an event is constituted for a case where the gap between two consecutive PUSCH transmissions overlaps with any symbol of downlink reception or downlink monitoring even if neither of the repetitions overlaps with it.
Decision: As per email decision posted on Mar 3rd,
Conclusion
PUSCH repetitions with different sets of power control parameters in multi-TRP operation is regarded as a semi-static event.
Note: No additional specification impact is expected
Agreement
· Gap between two PUSCH/PUCCH transmissions exceeds 11 symbols for extended CP is regarded as an event.
R1-2202869 FL Summary#4 of joint channel estimation for PUSCH Moderator (China Telecom)
From Mar 3rd GTW session
Agreement
· The value range of PUSCH-TimeDomainWindowLength is INTEGER (2 .. 32).
· The value range of PUCCH-TimeDomainWindowLength is INTEGER (2 .. 8).
· Note: the value shall not exceed the maximum duration.
R1-2202815 Reply LS on Maximum duration for DMRS bundling RAN4, Qualcomm Incorporated
RAN4 reply's considered and taken into account in the above last 2 agreements.
Final summary in R1-2202870.
Including dynamic PUCCH repetition factor indication, and DMRS bundling across PUCCH repetitions (When applicable, based on similar mechanism(s) for enabling joint channel estimation for PUSCH).
R1-2200969 Discussion on PUCCH coverage enhancement Huawei, HiSilicon
R1-2201015 PUCCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2201107 Remaining issues on PUCCH enhancements vivo
R1-2201167 Discussion on remaining issues for coverage enhancements for PUCCH ZTE
R1-2201286 PUCCH enhancements for coverage OPPO
R1-2201376 Remaining issues on PUCCH enhancement CATT
R1-2201382 Discussion on the interaction between inter-slot frequency hopping and DMRS bundling Panasonic Corporation
R1-2201445 Remaining issues on inter-slot frequency hopping with inter-slot bundling China Telecom
R1-2201490 Remaining issues on PUCCH enhancement NTT DOCOMO, INC.
R1-2201556 Discussion on PUCCH enhancements Spreadtrum Communications
R1-2201660 Discussion on PUCCH enhancements InterDigital, Inc.
R1-2201711 Remaining details on PUCCH enhancements Intel Corporation
R1-2201783 Remaining issues on PUCCH coverage enhancement Apple
R1-2201871 Remaining issues on PUCCH enhancements CMCC
R1-2201913 Remaining issues on PUCCH enhancements Xiaomi
R1-2201964 Remaining Issues for PUCCH Dynamic Repetition and DMRS Bundling Ericsson
R1-2202029 PUCCH enhancements Samsung
R1-2202154 PUCCH enhancements Qualcomm Incorporated
R1-2202199 PUCCH coverage enhancement Sharp
R1-2202238 Discussion on PUCCH enhancements TCL Communication Ltd.
R1-2202302 Discussions on coverage enhancement for PUCCH LG Electronics
R1-2202488 Remaining issues on PUCCH enhancements for coverage enhancement WILUS Inc.
[108-e-R17-CovEnh-04] – Yi (Qualcomm)
Email discussion regarding PUCCH enhancements
- 1st check point: February 25
- Final check point: March 3
R1-2202555 FL summary #1 of PUCCH coverage enhancement Moderator (Qualcomm)
R1-2202676 FL summary #2 of PUCCH coverage enhancement Moderator (Qualcomm)
From Feb 24th GTW session
Agreement
Inter-slot frequency hopping pattern for PUSCH repetitions with DMRS bundling is determined based on physical slot index.
Agreement
Inter-slot frequency hopping pattern for PUCCH repetitions with DMRS bundling is determined based on down-selection (in RAN1#108e) option 2
· Option 2: relative slot index – option A
Note: Option A/B for relative slot index are defined as the following
· Option A: frequency hopping pattern is determined based on relative slot index. Relative slot 0 is the slot where PUCCH/PUSCH repetition starts. Each of the subsequent slots are counted and relative slot index increase by one regardless the slot is used to transmit PUCCH/PUSCH or not.
· Option B: frequency hopping pattern is determined based on relative slot index. Relative slot 0 is the slot where PUCCH/PUSCH repetition starts. One of the subsequent slots are counted and the slot index increase by one only if the slot is used to transmit PUCCH/PUSCH.
Decision: As per email decision posted on Feb 27th,
Conclusion
For frequency hopping for PUCCH/PUSCH repetitions with DMRS bundling, in Rel-17, there is no consensus to increase the number of frequency offset over what are supported in Rel-15/16.
Agreement (Excerpted from RAN1#107bis-e)
PUCCH repetitions with different sets of power control parameters in multi-TRP operation should be regarded as a [semi-static] event that causes power consistency and phase continuity not to be maintained across PUCCH repetitions.
Agreement
Update the above agreement made in RAN1 107bis-e as below
PUCCH repetitions with different sets of power control parameters
in multi-TRP operation should be regarded as a [semi-static] event that
causes power consistency and phase continuity not to be maintained across PUCCH
repetitions.
R1-2202753 FL summary #3 of PUCCH coverage enhancement Moderator (Qualcomm)
From Feb 28th GTW session
Agreement
· Values for PUSCH-Frequencyhopping-Interval are “{2, 4, 5, 6, 8, 10, 12, 14, 16, 20}”
Note: For unpaired spectrum, UE is not expected to be configured the value of 6, 8, 12, 14, 16
Agreement
·
Values for
PUCCH-Frequencyhopping-Interval are “{2, 4, 5, [8],10}”
Agreement
When both inter-slot frequency hopping and DMRS bundling are enabled for PUCCH/PUSCH repetitions, UE is expected to be configured with at least one of frequency hopping interval and TDW length.
Note: Conclusion is to added to RRC parameter agreement and sent to RAN2 in LS.
R1-2200970 Discussion on Msg3 repetition for coverage enhancement Huawei, HiSilicon
R1-2201016 Approaches and solutions for Type A PUSCH repetitions for Msg3 Nokia, Nokia Shanghai Bell
R1-2201108 Remaining issues on Type A PUSCH repetitions for Msg3 vivo
R1-2201168 Discussion on remaining issues for Type A PUSCH repetitions for Msg3 ZTE
R1-2201287 Type A PUSCH repetitions for Msg3 coverage OPPO
R1-2201377 Remaining issues on Type A PUSCH repetitions for Msg3 CATT
R1-2201446 Remaining issues on type A PUSCH repetitions for Msg3 China Telecom
R1-2201491 Remaining issues on type A PUSCH repetitions for Msg3 NTT DOCOMO, INC.
R1-2201661 Type A PUSCH repetitions for Msg3 InterDigital, Inc.
R1-2201712 Remaining details on Msg3 PUSCH repetition Intel Corporation
R1-2201872 Remaining issues on type A PUSCH repetitions for Msg3 CMCC
R1-2201926 Remaining issues on Type A PUSCH repetition for Msg3 Xiaomi
R1-2201965 Remaining Issues for Type A PUSCH Repetition for Msg3 Ericsson
R1-2202030 Type A PUSCH repetitions for Msg3 Samsung
R1-2202200 Type A PUSCH repetitions for Msg3 Sharp
R1-2202303 Discussion on coverage enhancement for Msg3 PUSCH LG Electronics
[108-e-R17-CovEnh-05] – Xianghui (ZTE)
Email discussion regarding Type A PUSCH repetitions for Msg 3
1st check point: February 25
Final check point: March 3
R1-2202592 Feature lead summary #1 on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
Decision: As per email decision posted on Feb 24th,
Agreement (Excerpted from RAN1#107bis-e)
Regarding how a UE should interpret MCS information field for indication of the number of repetitions for the case of CBRA, Option 1 is supported.
· When a UE requests Msg3 repetition, the repurposed MCS information field is applied. gNB schedules Msg3 with or without repetition for the UE requesting Msg3 repetition.
o Repetition factor K=1 is included in the four candidate repetition factors used for repetition indication.
· When the UE doesn’t request Msg3 repetition (including legacy UE), the legacy MCS information field is applied. gNB schedules Msg3 without repetition for the UE not requesting Msg3 repetition.
Agreement
The above agreement from RAN1#107bis-e is updated as follows.
|
Regarding how a UE should interpret MCS information field for indication of the number of repetitions for the case of CBRA, Option 1 is supported. Ÿ When a UE requests Msg3 repetition, the repurposed MCS information field is applied. gNB schedules Msg3 with or without repetition for the UE requesting Msg3 repetition. Ÿ Whether Rrepetition factor K=1 is included in the four candidate repetition factors used for repetition indication is up to gNB configuration. Ÿ When the UE doesn’t request Msg3 repetition (including legacy UE), the legacy MCS information field is applied. gNB schedules Msg3 without repetition for the UE not requesting Msg3 repetition. |
Agreement
The Rel-17 collision rules among SSB and Msg3 PUSCH transmission for HD-FDD UEs, which is subject to the discussion on collision handling for Msg3 transmission in AI 8.6.1.2, can be reused for Msg3 PUSCH repetition for HD-FDD UEs.
Agreement
RAN1 confirms to support separate RO for requesting of Msg3 PUSCH repetition in a BWP configured with ROs not for requesting of Msg3 PUSCH repetition.
· Note: It expects RAN2 will continue the work on RACH partitioning based on separate RO for Rel-17 CE, and no further action in RAN1 on this aspect is pursued unless triggered by RAN2.
R1-2202593 Feature lead summary #2 on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
Decision: As per email decision posted on Mar 3rd,
R1-2200885 LS on UL BWP with PRACH resources only for RACH with Msg3 repetition RAN2, Qualcomm
R1-2202828 [Draft] Reply LS on UL BWP with PRACH resources only for RACH with Msg3 repetition Moderator (ZTE)
The draft LS is endorsed in principle. Final reply LS to RAN2 LS (R2-2201982) is approved in R1-2202829.
Agreement
The following TP for Clause 6.1.2.1 of TS 38.214 h00 is endorsed.
|
6.1.2.1 Resource allocation in time domain <Unchanged parts are omitted> For PUSCH repetition Type A, when transmitting PUSCH scheduled by DCI format 0_1 or 0_2 in PDCCH with CRC scrambled with C-RNTI, MCS-C-RNTI, or CS-RNTI with NDI=1, the number of repetitions K is determined as - if numberOfRepetitions is present in the resource allocation table, the number of repetitions K is equal to numberOfRepetitions; - elseif the UE is configured with pusch-AggregationFactor, the number of repetitions K is equal to pusch-AggregationFactor; - otherwise K=1. - the number of slots used for TBS determination N is equal to 1. For PUSCH repetition type A, when transmitting PUSCH scheduled by RAR UL grant, the 2 MSBs of the MCS information field of the RAR UL grant provide a codepoint to determine the number of repetitions K according to Table 6.1.2.1-1A, based on whether or not the higher layer parameter numberOfMsg3Repetitions is configured. The number of slots used for TBS determination N is equal to 1. For PUSCH repetition type A, when transmitting PUSCH scheduled by DCI format 0_0 with CRC scrambled by TC-RNTI, the 2 MSBs of the MCS information field of the DCI format 0_0 with CRC scrambled by TC-RNTI provide a codepoint to determine the number of repetitions K according to Table 6.1.2.1-1A, based on whether or not the higher layer parameter numberOfMsg3Repetitions is configured. The number of slots used for TBS determination N is equal to 1. <Unchanged parts are omitted> |
Final summary in R1-2202594.
R1-2201169 Discussion on RRC parameters for coverage enhancement ZTE
R1-2201966 Frequency Hopping for TBoMS Ericsson
R1-2202448 On futher potential coverage enhancements Huawei, HiSilicon
R1-2205566 Session notes for 8.8 (NR coverage enhancement) Ad-hoc Chair (CMCC)
R1-2203651 Summary of preparation phase for Rel-17 NR coverage enhancements Moderator (China Telecom)
Including enhancements on PUSCH repetition type A, TB processing over multi-slot PUSCH, and Type A PUSCH repetitions for Msg3.
R1-2203095 Discussion on PUSCH enhancements Huawei, HiSilicon
R1-2203191 Discussion on remaining issues for PUSCH enhancements ZTE
R1-2203439 Remaining issues on PUSCH enhancements in Rel-17 CATT
R1-2203521 Remaining issues on PUSCH enhancements vivo
R1-2203610 Remaining issues on PUSCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2203791 Maintenance on PUSCH enhancements xiaomi
R1-2203837 Remaining issues on TB processing over multi-slot PUSCH Langbo
R1-2203869 PUSCH enhancements Samsung
R1-2203994 Enhancements on PUSCH repetition type A OPPO
R1-2204089 Remaining issues on PUSCH enhancements InterDigital, Inc.
R1-2204212 Remaining issues on PUSCH repetition type A enhancement Apple
R1-2204278 Discussion on the remaining issues of CE PUSCH enhancement CMCC
R1-2204349 Remaining issues on PUSCH enhancements for coverage enhancement NTT DOCOMO, INC.
R1-2204527 Remaining details on PUSCH enhancements LG Electronics
R1-2204548 Remaining issues on enhancements for PUSCH repetition Type A WILUS Inc.
R1-2204657 Discussion on remaining issues on PUSCH repetition Type A enhancements Panasonic
R1-2204664 PUSCH enhancements for Rel-17 CovEnh Sharp
R1-2204726 Discussion on PUSCH enhancements MediaTek Inc.
R1-2204775 Remaining issues on PUSCH enhancements Intel Corporation
R1-2204871 Maintenance for PUSCH Repetition and TBoMS Ericsson
R1-2204990 PUSCH Enhancements Qualcomm Incorporated
[109-e-R17_CovEnh-01] – Toshi (Sharp)
Email discussion under 8.8.1 for maintenance on PUSCH enhancement, for proposals in the FL summary of the preparation phase discussion, including
Enhancements on PUSCH repetition type A: Issue#1, Issue#2, Issue#3 and Issue#5
- Discussion and decision by May 18
R1-2205421 Summary on [109-e-R17_CovEnh-01] for maintenance on PUSCH enhancement (Enhancements on PUSCH repetition type A) Moderator (Sharp)
Decision: As per email decision posted on May 12th,
Conclusion
At least for Rel-17, it is RAN1’s common understanding that:
· For PUSCH scheduled (with or without repetitions) by RAR UL grant or by DCI format 0_0 with CRC scrambled by TC-RNTI, the UE is not required to read frequencyHopping in pusch-Config for the determination of frequency hopping type or for the determination of whether the frequency hopping is applied for the PUSCH and is required to read the frequency hopping flag information field of the RAR UL grant or the DCI format 0_0 with CRC scrambled by TC-RNTI for the determination of whether the frequency hopping is applied for the PUSCH or not.
· For a PUSCH scheduled by a DCI format 0_0 with CRC scrambled by C-RNTI, MCS-C-RNTI or CS-RNTI, the frequency hopping field in the DCI format 0_0 is not expected to be set to 1 if frequencyHopping in PUSCH-Config is not provided or set to interSlot.
o Note: This follows the conclusion for R1-2003594 in RAN1#101-e
· For Type 2 CG PUSCH activated by DCI format 0_0 with CRC scrambled by CS-RNTI, the frequency hopping field in the DCI format 0_0 is not expected to be set to if frequencyHopping in configuredGrantConfig is not provided or set to interSlot.
o Note: This follows the conclusion for R1-2003594 in RAN1#101-e
Decision: As per email decision posted on May 18th,
Agreement
· Adopt the following TP to the 1st sentence of Clause 6.3.1 in TS38.214.
============================= start of TP==========================================
<omitted text>
6.3.1 Frequency hopping for PUSCH repetition Type A and for TB processing over multiple slots
For PUSCH repetition Type A other than the
PUSCH scheduled by RAR UL grant
or fallbackRAR UL grant or by DCI
format 0_1 or 0_2 0_0 with CRC scrambled by
TC-RNTI and for TB processing over multiple
slots (as determined according to procedures defined in Clause 6.1.2.1 for
scheduled PUSCH, or Clause 6.1.2.3 for
configured PUSCH), a UE is configured for frequency hopping by the higher layer
parameter frequencyHoppingDCI-0-2 in pusch-Config for
PUSCH transmission scheduled by DCI format 0_2, and by frequencyHopping provided
in pusch-Config for PUSCH transmission scheduled by a DCI
format other than 0_2, and by frequencyHopping provided
in configuredGrantConfig for configured PUSCH
<omitted text>
============================== end of TP==========================================
Conclusion
There is no consensus to introduce the solutions intended for mitigation of DL throughput degradation due to Rel-17 CovEnh features.
[109-e-R17_CovEnh-02] – Quang (Nokia)
Email discussion under 8.8.1 for maintenance on PUSCH enhancement, for proposals in the FL summary of the preparation phase discussion, including
TB processing over multi-slot PUSCH：Issue#1, Issue#5, and Issue#7
- Discussion and decision by May 18
R1-2205366 FL summary #2 of TB processing over multi-slot PUSCH Moderator (Nokia/Nokia Shanghai Bell)
Decision: As per email decision posted on May 13th,
Agreement
· Adopt the text proposal of FL’s proposal 1 in R1-2205366 for TS 38.214, Clause 6.1.2.1 (changes are highlighted in red)
Agreement
· Adopt the text proposal of FL’s proposal 2 in R1-2205366 for TS 38.214, Clause 6.1.2.3.3 (changes are highlighted in red)
Agreement (modified as below on May 20th)
· SP/A-CSI multiplexing on a slot of TBoMS with UL-SCH is supported.
o FFS: which slot of the single TBoMS (and which repetition, in case of TBoMS repetition) is selected for SP/A-CSI multiplexing.
· SP/A-CSI multiplexing on TBoMS without UL-SCH is not supported.
R1-2205417 FL summary #3 of TB processing over multi-slot PUSCH Moderator (Nokia/Nokia Shanghai Bell)
Decision: As per email decision posted on May 20th,
Agreement
Note: To editors, above agreement on SP/A-CSI multiplexing on a slot of TBoMS with UL-SCH is modified as follows.
·
SP/A-CSI multiplexing on a slot of TBoMS with
UL-SCH is supported.
o FFS: which slot of the single TBoMS (and which
repetition, in case of TBoMS repetition) is selected for SP/A-CSI
multiplexing.
· SP/A-CSI multiplexing on TBoMS without UL-SCH is not supported.
R1-2205367 Final FL summary of TB processing over multi-slot PUSCH Moderator (Nokia/Nokia Shanghai Bell)
R1-2203096 Discussion on joint channel estimation for PUSCH and PUCCH Huawei, HiSilicon
R1-2203192 Discussion on remaining issues for joint channel estimation ZTE
R1-2203309 Discussion on joint channel estimation for PUSCH&PUCCH Spreadtrum Communications
R1-2203402 Discussion on joint channel estimation for PUSCH and PUCCH Panasonic
R1-2203440 Remaining issues on joint channel estimation in Rel-17 CATT
R1-2203522 Remaining issues on joint channel estimation vivo
R1-2203611 Remaining issues on joint channel estimation for PUSCH and PUCCH Nokia, Nokia Shanghai Bell
R1-2203652 Remaining issues on joint channel estimation for PUSCH and PUCCH China Telecom
R1-2203870 Joint channel estimation for PUSCH and PUCCH Samsung
R1-2204090 Joint channel estimation for PUSCH and PUCCH InterDigital, Inc.
R1-2204213 Remaining issues on cross-slot channel estimation for PUSCH Apple
R1-2204279 Discussion on the remaining issues of joint channel estimation for PUSCH and PUCCH CMCC
R1-2204350 Remaining issues on joint channel estimation for PUSCH and PUCCH for coverage enhancement NTT DOCOMO, INC.
R1-2204513 Joint channel estimation for PUSCH and PUCCH Sharp
R1-2204549 Remaining issues on Joint channel estimation for PUCCH and PUSCH WILUS Inc.
R1-2204776 Remaining issues on joint channel estimation for PUSCH and PUCCH Intel Corporation
R1-2204872 Maintenance of Joint Channel Estimation for PUSCH and PUCCH Ericsson
R1-2204991 Joint channel estimation for PUSCH and PUCCH Qualcomm Incorporated
[109-e-R17_CovEnh-03] – Yi (Qualcomm)
Email discussion under 8.8.2 for maintenance on PUCCH enhancements for proposals in the FL summary of the preparation phase discussion, including Issue#1, Issue#2, Issue#3 and Issue# 5
- Discussion and decision by May 20
R1-2205185 FL summary #1 of maintenance on PUCCH enhancements Moderator (Qualcomm)
Decision: As per email decision posted on May 20th,
Conclusion
RAN1 concludes the following.
· The dynamic PUCCH repetition factor indication mechanism of NR R17 is not applicable to HARQ-ACK for the first SPS PDSCH associated with the activation DCI
· The dynamic PUCCH repetition factor indication mechanism of NR R17 is applicable to HARQ-ACK corresponding to the SPS release DCI
Note: no specification impact with the above conclusions.
R1-2205626 Agreed TP for maintenance on joint channel estimation for PUSCH and PUCCH Moderator (Qualcomm)
Agreement
· Adopt the TP of Further update FL proposal 2 in R1-2205626 for Subclause 6.3.1 in TS 38.214.
Final summary in R1-2205441.
[109-e-R17_CovEnh-04] – Jianchi (China Telcom)
Email discussion under 8.8.2 for maintenance on Joint channel estimation for PUSCH and PUCCH for proposals in the FL summary of the preparation phase discussion, including Issue#1, Issue#2, Issue#3 and Issue 8(Issue 8-1 and Issue 8-2)
- Discussion and decision by May 20
R1-2205351 FL Summary of joint channel estimation for PUSCH and PUCCH Moderator (China Telecom)
From May 16th GTW session
Conclusion
· No consensus on confirming the following working assumption in R17.
Working assumption:
· The action of group common TPC commands with format 2_2 does not constitute an event that violates power consistency and phase continuity.
o If UE is configured to accumulate TPC commands,
§ If UE receives TPC commands that would take into effect during a configured TDW, UE accumulates TPC commands without taking effect during the current configured TDW. TPC commands take effect after the current configured TDW.
o If UE is not configured to accumulate TPC commands
§ the last TPC command that would take effect within a configured TDW supersedes all previous TPC commands that take effect within that configured TDW and only the last TPC command is applied by the UE after the current configured TDW.
· FFS: no more than 1 TPC command is expected to take effect during a configured TDW.
R1-2205444 FL Summary#2 of joint channel estimation for PUSCH and PUCCH Moderator (China Telecom)
Decision: As per email decision posted on May 17th,
Agreement
· Adopt the TP of proposal 4 in R1-2205444 to Section 6.1.7 of TS 38.214.
Final summary in R1-2205483.
R1-2203193 Discussion on remaining issues for coverage enhancements for PUCCH ZTE
R1-2203612 Draft LS on description of RRC parameters for nominal time domain window length for PUSCH and PUCCH DMRS bundling Nokia, Nokia Shanghai Bell
R1-2203792 Other considerations for TB processing over multi-slot PUSCH xiaomi
R1-2205121 Rel-17 Multi-Slot Frequency Hopping and Further Enhancements Ericsson (rev of R1-2204873)
R1-2204902 Further consideration on PUSCH coverage enhancment Huawei, HiSilicon
R1-2204957 Remaining issues for PUCCH coverage enhancements InterDigital, Inc.
R1-2208139 Session notes for 8.8 (NR coverage enhancement) Ad-hoc Chair (CMCC)
[110-R17-CovEnh] Email to be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc – Jianchi (China Telcom)
R1-2205777 Discussion on frequency hopping pattern enhancements for joint channel estimation for PUSCH Huawei, HiSilicon
R1-2205780 Correction on frequency hopping pattern enhancements for joint channel estimation for PUSCH Huawei, HiSilicon
R1-2205806 Correction on determining time domain window for bundling DMRS Huawei, HiSilicon
R1-2205953 Correction on available slot counting for inter-cell multi-TRPs ZTE
R1-2205954 Discussion on UE behavior of restarting DMRS bundling ZTE
R1-2205955 Correction on UE behavior of restarting DMRS bundling ZTE
R1-2206301 Enhancements on PUSCH repetition type A OPPO
R1-2206302 Draft CR for PUSCH repetition type A OPPO
R1-2206370 Correction on inter-slot frequency hopping with inter-slot bundling CATT
R1-2206553 Discussion on PUSCH repetition type A with available slots counting for inter-cell multi-TRPs Intel Corporation
R1-2206554 Correction on PUSCH repetition type A with available slots counting for inter-cell multi-TRPs Intel Corporation
R1-2206557 Discussion on action of TPC command and restarting DMRS bundling Intel Corporation
R1-2206558 Correction on action of TPC command for DMRS bundling Intel Corporation
R1-2206559 Discussion on enhanced inter-slot frequency hopping for PUSCH repetitions Intel Corporation
R1-2206560 Correction on enhanced inter-slot frequency hopping for PUSCH repetitions Intel Corporation
R1-2206619 Maintenance on NR coverage enhancement Xiaomi
R1-2206683 Remaining issues on Rel-17 NR coverage enhancements China Telecom
R1-2206684 Correction on inter-slot frequency hopping for DMRS bundling China Telecom
R1-2206758 Available slot determination for inter-cell mTRP vivo
R1-2206759 Frequency hop determination for PUSCH with DMRS bundling vivo
R1-2206760 UE behavior of restarting DMRS bundling vivo
R1-2206799 PUSCH enhancements Samsung
R1-2206800 Draft CR on available slot counting for inter-cell multi-TRPs Samsung
R1-2206801 Joint channel estimation for PUSCH and PUCCH Samsung
R1-2206802 Draft CR on transmit power for DMRS bundling Samsung
R1-2206852 Draft CR for NR coverage enhancement about UE behavior for DMRS bundling MediaTek Beijing Inc.
R1-2206862 Discussion on joint channel estimation for PUSCH and PUCCH Panasonic
R1-2206889 Maintenance on NR coverage enhancement CMCC
R1-2206943 Discussion on inter-slot frequency hopping for DMRS bundling for PUSCH transmissions ZTE
R1-2206944 Correction on inter-slot frequency hopping for DMRS bundling for PUSCH transmissions ZTE
R1-2207099 Remaining issues on enhancements for PUSCH repetition type A Nokia, Nokia Shanghai Bell
R1-2207100 Change request on out of order PUSCH scheduling in case of counting on available slots Nokia, Nokia Shanghai Bell
R1-2207101 Change request on available slots counting in inter-cell multi-TRPs Nokia, Nokia Shanghai Bell
R1-2207102 Remaining issues on joint channel estimation for PUSCH and PUCCH Nokia, Nokia Shanghai Bell
R1-2207103 Change request on UE behavior for power control adjustment state for PUCCH in the case of DMRS bundling Nokia, Nokia Shanghai Bell
R1-2207104 Change request on UE behavior for power control adjustment state for PUSCH in the case of DMRS bundling Nokia, Nokia Shanghai Bell
R1-2207105 Change request on removal of square brackets for starting RB determination for inter-slot frequency hopping when DMRS bundling is enabled Nokia, Nokia Shanghai Bell
R1-2207106 Change request on SRS resource sets mapping for supporting PUSCH repetition type A with joint channel estimation Nokia, Nokia Shanghai Bell
R1-2207107 Change request on spatial settings or power control parameters sets mapping for supporting PUCCH repetition with joint channel estimation Nokia, Nokia Shanghai Bell
R1-2207108 Remaining issues on transport block processing for PUSCH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2207155 Discussion on available slot counting for inter-cell mTRP InterDigital, Inc.
R1-2207156 Available slot counting for inter-cell mTRP InterDigital, Inc.
R1-2207158 Correction for Available Slot Determination for Inter-Cell Multi-TRP Operation Ericsson
R1-2207159 Correction for Power Control with DMRS Bundling Ericsson
R1-2207161 Correction on Frequency Hopping Offset and Interval Determination for DMRS Bundling Ericsson
R1-2207201 Discussion on remaining issues on NR coverage enhancement Qualcomm Incorporated
R1-2207202 Correction on Inter-slot Frequency Hopping for PUSCH with DMRS Bundling Qualcomm Incorporated
R1-2207277 Available slot counting for Inter-cell multi-TRPs in Rel-17 CovEnh Sharp
R1-2207278 Corrections on use of SSBs for inter-cell multiple TRPs for the available slot determination Sharp
R1-2207385 Discussion on remaining issues for NR coverage enhancement NTT DOCOMO, INC.
R1-2207448 Maintenance for coverage enhancement in terms of joint channel estimation for PUSCH Sharp
R1-2207449 Inter-slot frequency hopping with DMRS bundling for PUSCH Sharp
R1-2207586 Discussion on Available Slot Determination for Inter-Cell Multi-TRP Ericsson
R1-2207587 Discussion on Power Control with DMRS Bundling Ericsson
R1-2207588 Discussion on DMRS Bundling Restart Ericsson
R1-2207597 Remaining issues on enhancements for PUSCH repetition Type A WILUS Inc.
R1-2207889 [Draft] CR for coverage enhancements in NR ETRI
R1-2205776 Discussion on A-CSI multiplexing on TBoMS PUSCH Huawei, HiSilicon
R1-2205779 Correction on A-CSI multiplexing on TBoMS PUSCH Huawei, HiSilicon
R1-2205976 Clarification of A-CSI multiplexing on TBoMS Spreadtrum Communications
R1-2206555 Correction on TBoMS for HD-FDD RedCap UEs Intel Corporation
R1-2206556 Correction on A-CSI reports on TBoMS Intel Corporation
R1-2206757 A-CSI multiplexing on TBoMS vivo
R1-2206945 Discussion on A-CSI for TBoMS ZTE
R1-2207109 Change request on A-CSI multiplexing on TBoMS Nokia, Nokia Shanghai Bell
R1-2207160 Correction for A-CSI Multiplexing on TBoMS Ericsson
R1-2207203 Correction on A-CSI multiplexing with TBOMS Qualcomm Incorporated
R1-2207589 Discussion on A-CSI Multiplexing on TBoMS Ericsson
R1-2207755 Summary of preparation phase for Rel-17 NR coverage enhancements – Remaining issues for TBoMS Moderator (Nokia)
R1-2207756 Summary of remaining issues for TBoMS for Rel-17 NR coverage enhancements Moderator (Nokia)
R1-2207918 Change request on A-CSI multiplexing on TBoMS Nokia (Moderator), Intel, vivo
Agreement
· The draft CR to 38.214 in R1-2207918 is endorsed.
Final CR (Rel-17, 38.214, NR_cov_enh-Core, CR#0344, Cat F) is agreed in:
R1-2208313 Change request on A-CSI multiplexing on TBoMS Moderator (Nokia), Intel, vivo
R1-2207886 FL summary #1 of maintenance on PUCCH enhancements Moderator (Qualcomm)
R1-2208111 FL summary #2 of maintenance on PUCCH enhancements Moderator (Qualcomm)
Agreement
· Adopt the offline consensus in Section 5.2 RRC parameter alignment in R1-2208111 to clause 9.2.6 in TS 38.213 V17.2.0.
o For editors: The TP is to be included in alignment CR for TS 38.213.
R1-2206755 Corrections of Msg3 repetition vivo
R1-2206756 Corrections of Msg3 repetition vivo
R1-2207142 Correction on available slot counting for a PUSCH scheduled by RAR UL grant or by DCI format with CRC scrambled by TC-RNTI for HD-FDD RedCap UE Sharp
R1-2207485 Draft 38.213 CR on Msg3 repetition ZTE
R1-2207486 Draft 38.214 CR on Msg3 repetition ZTE
R1-2207845 Feature lead summary #1 on support of Type A PUSCH repetitions for Msg3 Moderator (ZTE)
Agreement
· The draft 38.213 CR on Msg3 repetition in R1-2207845 is endorsed in principle.
o For editors: This draft CR is to be included in alignment CR for TS 38.213.
Agreement
· The draft 38.214 CR on Msg3 repetition in R1-2207845 is endorsed in principle.
o For editors: This draft CR is to be included in alignment CR for TS 38.214.
Conclusion
For the available slot counting with inter-cell mTRPs, both the SSB by ssb-PositionsInBurst in SystemInformationBlockType1 or by ssb-PositionsInBurst in ServingCellConfigCommon and all the configured SSBs by ssb-PositionsInBurst in SSB-MTCAdditionalPCI are used for the available slot determination.
· Note: No RAN1 specification impact.
Conclusion
Reply to RAN4, including below:
“RAN1 spec requires power consistency and phase continuity to be maintained during an actual TDW, as defined in Clause 6.1.7 in 38.214. RAN1 has not taken into account any power change due to P-MPR for satisfying the regulatory requirements. It is up to RAN4 to define any needed requirements for power consistency and phase continuity while also taking P-MPR into account.”
From AI 5
R1-2205715 Reply LS to RAN1/RAN2 on DMRS bundling RAN4, MediaTek
R1-2207917 Moderator summary on RAN4 LS Reply about DMRS bundling for R17 NR Coverage Enhancement Moderator (MediaTek Inc.)
R1-2208211 Draft Reply LS to RAN4 on DMRS bundling MediaTek
Decision: The draft LS is endorsed. Final version is approved in R1-2208212.
R1-2207765 FL summary of discussion on joint channel estimation for Rel-17 NR coverage enhancements Moderator (China Telecom)
R1-2207885 FL summary #1 for Rel-17 CovEnh maintenance: Enhancements on PUSCH repetition type A Moderator (Sharp)
R1-2208188 FL summary #2 for Rel-17 CovEnh maintenance: Enhancements on PUSCH repetition type A Moderator (Sharp)
R1-2210684 Session notes for 8.8 (NR coverage enhancement) Ad-hoc Chair (CMCC)
[110bis-e-R17-CovEnh-01] – Jianchi (China Telecom)
Email discussion to determine maintenance issues to be handled in RAN1#110bis-e by October 12
- Additional email discussions will be set up once the maintenance issues for RAN1#110bis-e are determined
R1-2210332 [110bis-e-R17-CovEnh-01] Summary of email discussion to determine maintenance issues Moderator (China Telecom)
Decision: Maintenance issues on Rel-17 NR coverage enhancements identified for joint channel estimation for email discussion are:
· Issue#2: UE behavior of restarting DMRS bundling
· Issue#5: Correction on events for determining TDW
R1-2208608 UE behavior of restarting DMRS bundling vivo
R1-2208766 Maintenance on Rel-17 NR coverage enhancements China Telecom
R1-2208840 Discussion on remaining issue of coverage enhancement OPPO
R1-2208841 Draft CR for coverage enhancement OPPO
R1-2208942 Correction on MCS determination of RAR grant CATT
R1-2208943 Discussion on UE behavior of restarting DMRS bundling CATT
R1-2209035 Discussion on remaining issues for DMRS bundling Intel Corporation
R1-2209132 Discussion on joint channel estimation for PUSCH and PUCCH Panasonic
R1-2209226 Remaining issues on joint channel estimation for Rel-17 NR coverage enhancements Lenovo
R1-2209227 Remaining issues on PUSCH repetition type A enhancement Lenovo
R1-2209308 Maintenance on NR coverage enhancement CMCC
R1-2209468 Correction on cancellation of PUSCH repetitions and TBoMS ZTE
R1-2209532 Discussion on RAN4 Reply LS for DMRS bundling MediaTek Inc.
R1-2209561 Discussion on RAN4 LS on DMRS bundling Apple
R1-2209669 Discussion on DMRS Bundling Restart Ericsson
R1-2209707 Maintenance on NR coverage enhancement Samsung
R1-2209872 Discussion on remaining issues for NR coverage enhancement NTT DOCOMO, INC.
R1-2209948 Discussion on remaining issues in NR Coverage Enhancement Qualcomm Incorporated
R1-2210160 Remaining issues on enhancements for PUSCH repetition type A Nokia, Nokia Shanghai Bell
R1-2210161 Change request on out of order PUSCH scheduling in case of counting on available slots Nokia, Nokia Shanghai Bell
R1-2210162 Remaining issues on joint channel estimation for PUSCH and PUCCH Nokia, Nokia Shanghai Bell
R1-2210163 Change request on SRS resource sets mapping for supporting PUSCH repetition type A with joint channel estimation Nokia, Nokia Shanghai Bell
R1-2210164 Change request on spatial settings or power control parameters sets mapping for supporting PUCCH repetition with joint channel estimation Nokia, Nokia Shanghai Bell
R1-2210181 Discussion on Power Control with DMRS Bundling Ericsson
R1-2210182 Correction for Power Control with DMRS Bundling Ericsson
R1-2210214 Correction on events for determining time domain window for bundling DM-RS Huawei, HiSilicon
R1-2210420 FL summary of discussion on joint channel estimation for Rel-17 NR coverage enhancements Moderator (China Telecom)
From Oct 12th GTW session, no consensus on issue#2 and issue#5.
/To be handled using NWM – please use 110bis-e-NWM-R17-CovEnh-02 as the document name
[110bis-e-R17-CovEnh-02] – Tao (MediaTek)
Email discussion on incoming RAN4 LS in R1-2205715 (from RAN1#110) by October 14
R1-2210426 Moderator’s summary #1 for discussions on RAN4 reply LS about DMRS bundling Moderator (MediaTek Inc.)
R1-2210456 Moderator’s summary #2 for discussions on RAN4 reply LS about DMRS bundling Moderator (MediaTek Inc.)
Conclusion
|
For CA/DC/SUL cases listed in RAN4 LS as extracted below: - DL CA with “additional” UL carrier configured with SRS only (i.e. no PUCCH/PUSCH configured) - FR1 inter-band UL CA with DMRS bundling - SUL with DMRS bundling DMRS bundling can be applied with the following conditions additional to the ones listed in RAN4 LS: - Concurrent transmissions scheduled/configured over multiple carriers are not expected by UE - Only configuration of a single TAG - Only applicable for the back-to-back case (i.e., zero gap between two transmissions within an actual TDW) - Only one band can be configured with DMRS bundling at a time Ask RAN4 to take into account the conditions listed in RAN4 LS and the additional conditions above in RAN4 spec. Note 1: Under the above conditions, phase continuity and power consistency within any actual TDW on one carrier is not impacted by operations on a different carrier. Note 2: Under the above conditions, the events defined in section 6.1.7 of TS38.214 for the carrier with DMRS bundling are not triggered by any transmission within any actual TDW on the other carrier. Note 3: If the modulation scheme higher than QPSK is scheduled for transmission on any carrier configured with DMRS bundling, DMRS bundling is not applicable according to UE feature 30-4 (i.e., the error case and up to UE implementation) Note: No RAN1 specification impact |
R1-2210544 [Draft] Reply LS to RAN4 for further information on DMRS bundling MediaTek Inc.
Decision: As per email decision posted on Oct 19th, the draft LS is endorsed in principle. Final LS is approved in R1-2210545.
R1-2212838 Session notes for 8.8 (NR coverage enhancement) Ad-hoc Chair (CMCC)
Endorsed and contents incorporated below.
[111-R17-CovEnh] – Jianchi (China Telcom)
To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2210975 Correction of RV of CG PUSCH repetitions vivo
R1-2212766 FL summary of remaining issues for TB processing over multi-slot PUSCH Moderator (Nokia)
Agreement
· Adopt the following corrections to Section 6.1.2.3.1 and Section 6.1.2.3.2 of TS 38.214.
|
The procedures described in this clause apply to PUSCH transmissions of PUSCH repetition Type A with a Type 1 or Type 2 configured grant. The higher layer parameter repK-RV defines the redundancy version pattern to be applied to the repetitions. If cg-RetransmissionTimer is provided, the redundancy version for uplink transmission with a configured grant is determined by the UE. If the parameter repK-RV is not provided in the configuredGrantConfig and cg-RetransmissionTimer is not provided, the redundancy version for uplink transmissions with a configured grant shall be set to 0. If the parameter repK-RV is provided in the configuredGrantConfig and cg-RetransmissionTimer is not provided, for the nth transmission occasion among K repetitions, n=1, 2, …, K, it is associated with (mod(((n-mod(n, N))/N)-1,4)+1)th value in the configured RV sequence, where N=1. If a configured grant configuration is configured with startingFromRV0 set to 'off', the initial transmission of a transport block may only start at the first transmission occasion of the K repetitions. Otherwise, the initial transmission of a transport block may start at - the first transmission occasion of the K repetitions if the configured RV sequence is {0,2,3,1}, - any of the transmission occasions of the K repetitions that are associated with RV=0 if the configured RV sequence is {0,3,0,3}, - any of the transmission occasions of the K repetitions if the configured RV sequence is {0,0,0,0}, except the last transmission occasion when K≥8. The procedures described in this Clause apply to PUSCH transmissions of PUSCH repetition type B with a Type 1 or Type 2 configured grant. For PUSCH transmissions with a Type 1 or Type 2 configured grant, the nominal repetitions and the actual repetitions are determined according to the procedures for PUSCH repetition Type B defined in Clause 6.1.2.1. The higher layer configured parameters repK-RV defines the redundancy version pattern to be applied to the repetitions. If the parameter repK-RV is not provided in the configuredGrantConfig, the redundancy version for each actual repetition with a configured grant shall be set to 0. Otherwise, for the nth transmission occasion among all the actual repetitions (including the actual repetitions that are omitted) of the K nominal repetitions, it is associated with (mod(((n-mod(n, N))/N)-1,4)+1)th value in the configured RV sequence, where N = 1. If a configured grant configuration is configured with startingFromRV0 set to 'off', the initial transmission of a transport block may only start at the first transmission occasion of the actual repetitions. Otherwise, the initial transmission of a transport block may start at - the first transmission occasion of the actual repetitions if the configured RV sequence is {0,2,3,1}, - any of the transmission occasions of the actual repetitions that are associated with RV=0 if the configured RV sequence is {0,3,0,3}, - any of the transmission occasions of the actual repetitions if the configured RV sequence is {0,0,0,0}, except the actual repetitions within the last nominal repetition when K≥8. <unchanged text omitted > |
R1-2212856 Correction of RV of CG PUSCH repetitions Moderator (Nokia), vivo
Decision: The draft CR is endorsed in principle. Final CR (TS 38.214, Rel-17, CR#0378, Cat F) is agreed in R1-2212857.
R1-2211469 Draft CR for restarting DMRS bundling OPPO
R1-2211637 Correction on restarting of DMRS bundling ZTE
R1-2211638 Correction on the gap between two consecutive UL transmissions for DMRS bundling ZTE
R1-2211639 Discussion on DMRS bundling during DAPS handover ZTE
R1-2211640 Draft CR on DMRS bundling during DAPS handover ZTE
R1-2211959 Discussion on remaining issues for NR coverage enhancement NTT DOCOMO, INC.
R1-2212176 Corrections on DMRS bundling for PUCCH transmission for reduced capability HD-UE Sharp
R1-2212177 Corrections on determination N·K for DMRS bundling of CS-PUSCH Sharp
R1-2212413 Discussion on Power Control with DMRS Bundling Ericsson
R1-2212414 Correction for Power Control with DMRS Bundling Ericsson
R1-2212461 Correction on determining additional DM-RS for Msg3 with frequency hopping enabled/disabled Huawei, HiSilicon
R1-2212584 FL summary of discussion on joint channel estimation for Rel-17 NR coverage enhancements Moderator (China Telecom)
Agreement
· Adopt the following TP to clause 6.17, TS 38.214.
|
6.1.7 UE procedure for determining time domain windows for bundling DM-RS <Unchanged parts are omitted> The UE shall maintain power consistency and phase continuity within an actual TDW, across PUSCH transmissions of PUSCH repetition Type A scheduled by DCI format 0_1 or 0_2, or PUSCH repetition Type A with a configured grant, or PUSCH repetition type B or TB processing over multiple slots, or across PUCCH transmissions of PUCCH repetition, in case the actual TDW is created in response to frequency hopping, or in response to the use of a different SRS resource set association for the two PUSCH transmissions of PUSCH repetition type A, or PUSCH repetition type B, or in response to the use of different spatial relations or different power control parameters for the two PUCCH transmissions of PUCCH repetition, or in response to any event not triggered by DCI or MAC-CE. The UE maintains power consistency and phase continuity within an actual TDW, across PUSCH transmissions of PUSCH repetition Type A scheduled by DCI format 0_1 or 0_2, or PUSCH repetition Type A with a configured grant, or PUSCH repetition type B or TB processing over multiple slots, or across PUCCH transmissions of PUCCH repetition, in case the actual TDW is created in response to an event triggered by DCI other than frequency hopping or the use of a different SRS resource set association for the two PUSCH transmissions of PUSCH repetition type A, or PUSCH repetition type B, or the use of different spatial relations or different power control parameters for the two PUCCH transmissions of PUCCH repetition, or in response to an event triggered by MAC-CE, subject to UE capability. <Unchanged parts are omitted> |
R1-2212874 Correction on events for restarting of DMRS bundling Moderator (China Telecom), ZTE
Decision: The draft CR is endorsed in principle. Final CR (TS 38.214, Rel-17, CR#0386, Cat F) is agreed in R1-2212959.
Agreement
· Adopt the following TP to clause 6.1.7, TS 38.214.
|
6.1.7 UE procedure for determining time domain windows for bundling DM-RS <Unchanged text is omitted> - For reduced capability half-duplex UEs, - a
dropping or cancellation of a PUSCH or PUCCH
transmission according to clause 17.2 of [6, TS 38.213] - an overlapping of the gap between two consecutive PUSCH or two consecutive PUCCH transmissions and any symbol of downlink reception or downlink monitoring <Unchanged text is omitted> |
R1-2212875 Correction on DMRS bundling for reduced capability HD-UE Moderator (China Telecom), Sharp
Decision: The draft CR is endorsed in principle. Final CR (TS 38.214, Rel-17, CR#0387, Cat F) is agreed in R1-2212960.
Agreement
· Adopt the following TP to clause 6.1.7, TS 38.214.
|
6.1.7 UE procedure for determining time domain windows for bundling DM-RS For PUSCH transmissions of PUSCH repetition Type A scheduled by DCI format 0_1 or 0_2, PUSCH repetition Type A with a configured grant, PUSCH repetition Type B and TB processing over multiple slots, when PUSCH-DMRS-Bundling is enabled, and for PUCCH transmissions of PUCCH repetition, when PUCCH-DMRS-Bundling is enabled, the UE determines one or multiple nominal TDWs, as follows: - For PUSCH transmissions of repetition Type A, PUSCH repetition Type B and TB processing over multiple slots, the duration of each nominal TDW except the last nominal TDW, in number of consecutive slots, is: - Given by PUSCH-TimeDomainWindowLength, if configured. - Computed
as min ([maxDMRS-BundlingDuration], M), if PUSCH-TimeDomainWindowLength is
not configured, where [maxDMRS-BundlingDuration] is maximum duration for a
nominal TDW subject to UE capability [13, TS 38.306], M is the time duration
in consecutive slots of - For PUSCH transmissions of PUSCH repetition Type A, N=1 and K is the number of repetitions, as defined in Clause 6.1.2.1 or in Clause 6.1.2.3. - For PUSCH transmissions of PUSCH repetition Type B, N=1 and K is the number of nominal repetitions, as defined in Clause 6.1.2.1 or in Clause 6.1.2.3. - For PUSCH transmissions of TB processing over multiple slots, N is the number of slots used for TBS determination and K is the number of repetitions of the number of slots N used for TBS determination, as defined in Clause 6.1.2.1 or in Clause 6.1.2.3. <Unchanged text is omitted> |
R1-2212876 Correction on determination N·K for DMRS bundling of CG-PUSCH Moderator (China Telecom), Sharp
Decision: The draft CR is endorsed in principle. Final CR (TS 38.214, Rel-17, CR#0388, Cat F) is agreed in R1-2212961.
R1-2302058 Session notes for 8.8 (NR coverage enhancement) Ad-hoc Chair (CMCC)
[112-R17-CovEnh] – Jianchi (China Telcom)
To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2300715 Draft Correction on RRC parameters for DMRS bundling China Telecom
R1-2301472 Discussion on remaining issues for NR coverage enhancement NTT DOCOMO, INC.
R1-2301473 Draft CR on unified TCI state with DMRS bundling NTT DOCOMO, INC.
R1-2301740 Correction for window restart with DMRS bundling Ericsson
R1-2301942 FL summary of discussion on joint channel estimation for Rel-17 NR coverage enhancements Moderator (China Telecom)
From Wednesday session
Agreement
· Adopt the following TP to TS 38.214 for alignment CR.
|
6.1.7 UE procedure for determining time domain windows for bundling DM-RS < Unchanged parts are omitted > - Computed
as min (maxDurationDMRS-Bundling < Unchanged parts are omitted > - Computed
as min (maxDurationDMRS-Bundling < Unchanged parts are omitted > For PUSCH transmissions of a PUSCH repetition Type A scheduled by DCI format 0_1 or 0_2, PUSCH repetition Type A with a configured grant, PUSCH repetition Type B and TB processing over multiple slots, a nominal TDW consists of one or multiple actual TDWs. The UE determines the actual TDWs as follows: - The start of the first actual TDW is the first symbol of the first PUSCH transmission in a slot for PUSCH transmission of PUSCH repetition type A scheduled by DCI format 0_1 or 0_2, or PUSCH repetition Type A with a configured grant, or PUSCH repetition type B or TB processing over multiple slots within the nominal TDW. - The end of an actual TDW is - The last symbol of the last PUSCH transmission in a slot for PUSCH transmission of PUSCH repetition type A scheduled by DCI format 0_1 or 0_2, or PUSCH repetition Type A with a configured grant, or PUSCH repetition type B or TB processing over multiple slots within the nominal TDW, if the actual TDW reaches the end of the last PUSCH transmission within the nominal TDW. - The
last symbol of a PUSCH transmission before the event, if an event occurs
which causes power consistency and phase continuity not to be maintained
across PUSCH transmissions of PUSCH repetition type A scheduled by DCI format
0_1 or 0_2, or PUSCH repetition Type A with a configured grant, or PUSCH
repetition type B or TB processing over multiple slots within the nominal
TDW, and the PUSCH transmission is in a slot for PUSCH transmission of PUSCH
repetition type A scheduled by DCI format 0_1 or 0_2, or PUSCH repetition
Type A - When pusch-WindowRestart For PUCCH transmissions of PUCCH repetition, a nominal TDW consists of one or multiple actual TDWs. The UE determines the actual TDWs as follows: - The start of the
first actual TDW is the first symbol of the first PUCCH transmission in a
slot determined for PUCCH - The end of an actual TDW is - The last symbol of the last PUCCH transmission in a slot determined for transmission of the PUCCH within the nominal TDW, if the actual TDW reaches the end of the last PUCCH transmission within the nominal TDW. - The last symbol of a PUCCH transmission before the event, if an event occurs which causes power consistency and phase continuity not be maintained across PUCCH transmissions of PUCCH repetition within the nominal TDW, and the PUCCH transmission is in a slot determined for transmission of the PUCCH. - When pucch-WindowRestart < Unchanged parts are omitted > |
From Thursday session
Agreement
· Adopt the following TP to Section 6.1.7, TS 38.214 for alignment CR.
|
6.1.7 UE procedure for determining time domain windows for bundling DM-RS < Unchanged parts are omitted > The UE shall maintain power consistency and phase continuity within an actual TDW, across PUSCH transmissions of PUSCH repetition Type A scheduled by DCI format 0_1 or 0_2, or PUSCH repetition Type A with a configured grant, or PUSCH repetition type B or TB processing over multiple slots, or across PUCCH transmissions of PUCCH repetition, in case the actual TDW is created in response to frequency hopping, or in response to the use of a different SRS resource set association for the two PUSCH transmissions of PUSCH repetition type A, or PUSCH repetition type B, or in response to the use of different spatial relations or different power control parameters for the two PUCCH transmissions of PUCCH repetition, or in response to any event not triggered by DCI or MAC-CE. The UE maintains power consistency and phase continuity within an actual TDW, across PUSCH transmissions of PUSCH repetition Type A scheduled by DCI format 0_1 or 0_2, or PUSCH repetition Type A with a configured grant, or PUSCH repetition type B or TB processing over multiple slots, or across PUCCH transmissions of PUCCH repetition, in case the actual TDW is created in response to an event triggered by DCI other than frequency hopping or the use of a different SRS resource set association for the two PUSCH transmissions of PUSCH repetition type A, or PUSCH repetition type B, or the use of different spatial relations or different power control parameters for the two PUCCH transmissions of PUCCH repetition, or in response to an event triggered by MAC-CE, subject to UE capability of dmrs-BundlingRestart [13, TS 38.306] and when pusch-WindowRestart or pucch-WindowRestart is enabled. < Unchanged parts are omitted > |
