, defined as
the SNR variation w.r.t. baseline under the requirement BLER=10-1.Please refer to RP-221858 for detailed scope of the WI on further NR coverage enhancements.
R1-2210782 Session notes for 9.14 (Further NR coverage enhancements) Ad-Hoc Chair (CMCC) (rev of R1-2210696)
R1-2208783 Work plan for Rel-18 WI on Further NR coverage enhancements China Telecom
R1-2208488 Discussion on PRACH coverage enhancements ZTE
Number of PRACH repetitions
· Proposal 1: One or more new configured SSB-RSRP thresholds can be introduced for different PRACH coverage levels, i.e., different number of PRACH repetitions.
· Proposal 2: The number of PRACH repetitions with 2, 4 and 8 is proposed for multiple PRACH transmissions.
Same beam or different beams
· Proposal 3: Multiple PRACH transmissions with same beam on the ROs associated with the same SSB should be supported for PRACH coverage enhancement.
· Proposal 4: Multiple PRACH transmissions with different beams on the ROs associated with the same SSB should be considered for PRACH coverage enhancement.
Resource for multiple PRACH transmissions
· Proposal 5: For preamble index in multiple PRACH transmissions bundle, keep the same preamble index or randomize the preamble index in group based on predefined rule.
· Proposal 6: Separated preamble index for multiple PRACH transmissions is needed to differentiate between the multiple PRACH transmissions and single PRACH transmission, or to identify the number of multiple PRACH transmissions, if legacy ROs are shared by multiple PRACH transmissions.
· Proposal 7: Separate ROs by shared legacy PRACH configuration with or without additional new parameters should be considered for the multiple PRACH transmissions.
· Proposal 8: Completely separating PRACH configuration for multiple PRACH transmissions from legacy PRACH configuration is not preferred.
· Proposal 9: Approach of multiple PRACH transmissions in the frequency domain is not recommended.
· Proposal 10: Multiple PRACH transmissions using multiple panels could be investigated.
RAR enhancements
· Proposal 11: RAR window starts after the last PRACH repetitions should be applied if single RAR is adopted for multiple PRACH transmissions.
· Proposal 12: Multiple RAR windows for multiple PRACH transmissions can be considered if gNB cannot have the knowledge about whether or not the UE is under multiple PRACH transmissions.
RA-RNTI
· Proposal 13: Single RA-RNTI is calculated based on RO for the last or first PRACH repetition.
· Proposal 14: UE should assume that multiple RA-RNTIs are calculated based on multiple ROs for the PRACH repetitions if RA-RNTI calculation is not based on a predefined single RO.
Others
· Proposal 15: Power ramping is applied in case of multiple PRACH transmissions with the same beam. The power should remain unchanged in case of multiple PRACH transmissions with different beams.
· Proposal 16: Multiple PRACH transmissions can be enabled during the PRACH re-attempts in case of transmitting power or number of PRACH retransmissions reaching a threshold.
· Proposal 17: If multiple PRACH transmissions is used in the initial access, the retransmission should use multiple PRACH transmissions too.
· Proposal 18: The coupling between PRACH repetitions, msg3 repetitions, and PUCCH repetitions for HARQ-ACK of Msg4 should be investigated.
· Proposal 19: The CFRA based multiple PRACH transmissions should be investigated.
· Proposal 20: Study potential coverage enhancements for PRACH in FWA scenario to address the demands from practical network deployment.
Decision: The document is noted.
R1-2208411 Discussion on PRACH coverage enhancements Huawei, HiSilicon
R1-2208575 Discussion on PRACH coverage enhancements Spreadtrum Communications
R1-2208671 Discussions on PRACH coverage enhancements vivo
R1-2208784 Discussion on PRACH coverage enhancement China Telecom
R1-2208846 PRACH coverage enhancements OPPO
R1-2208963 PRACH coverage enhancements CATT
R1-2209001 PRACH coverage enhancements TCL Communication Ltd.
R1-2209025 Discussion on PRACH Coverage Enhancement Fujitsu
R1-2209078 Discussions on PRACH coverage enhancement Intel Corporation
R1-2209116 PRACH Coverage Enhancement using Multi PRACH Transmissions Sony
R1-2209130 Discussion on PRACH coverage enhancements Panasonic
R1-2209159 Discussion on PRACH coverage enhancement NEC
R1-2209223 PRACH coverage enhancements Lenovo
R1-2209249 Discussion on solutions for NR PRACH coverage enhancement Mavenir
R1-2209272 Discussion on PRACH coverage enhancements xiaomi
R1-2209363 Discussion on PRACH coverage enhancements CMCC
R1-2209412 PRACH coverage enhancements ETRI
R1-2209415 Discussion on triggering multiple PRACH transmissions FGI
R1-2209521 Enhancements for PRACH coverage MediaTek Inc.
R1-2209608 Discussion on PRACH coverage enhancement Apple
R1-2209661 Discussion on PRACH repetition InterDigital, Inc.
R1-2209672 Discussion on PRACH coverage enhancement Ericsson
R1-2209759 PRACH coverage enhancements Samsung
R1-2209788 Views on multiple PRACH transmission for coverage enhancement Sharp
R1-2209803 Discussion on PRACH repeated transmission for NR coverage enhancement LG Electronics
R1-2209925 Discussion on PRACH coverage enhancements NTT DOCOMO, INC.
R1-2210013 PRACH Coverage Enhancements Qualcomm Incorporated
R1-2210165 PRACH coverage enhancements Nokia, Nokia Shanghai Bell
[110bis-e-R18-Coverage-01] – Nanxi (China Telecom)
Email discussion on PRACH coverage enhancement by October 19
- Check points: October 14, October 19
R1-2210318 FL Summary#1 of PRACH coverage enhancements Moderator (China Telecom)
Presented in Oct 13th GTW session
R1-2210553 FL Summary#2 of PRACH coverage enhancements Moderator (China Telecom)
R1-2210554 FL Summary#3 of PRACH coverage enhancements Moderator (China Telecom)
From Oct 18th GTW session
Agreement
For multiple PRACH transmissions with same beam, at least support to use same PRACH preamble during the multiple PRACH transmissions in one RACH attempt.
· FFS: whether different preambles can be utilized in different PRACH transmissions during the multiple PRACH transmissions in one RACH attempt.
Agreement
For multiple PRACH transmissions with same beam, at least ROs located at different time instances can be utilized for the transmissions.
· FFS: whether/how the starting RB of ROs can be different at different time instances for multiple PRACH transmissions.
· FFS: whether/how multiple PRACH transmissions located in the same time instance, e.g., for UEs with multiple Tx chains.
Agreement
For multiple PRACH transmissions with same beam, for RAR monitoring, consider the following options.
· Option 1: One RAR window per each PRACH transmission, the RAR window follows the legacy design.
o FFS: RA-RNTI.
· Option 2: Only one RAR window for all of the multiple PRACH transmissions.
o FFS: the start position of the RAR window.
o FFS: RA-RNTI.
Final summary in R1-2210660.
R1-2210014 Power-domain enhancements Qualcomm Incorporated
On enhancements to reduce MPR/PAPR
· Proposal 1: For power-domain enhancements targeting MPR/PAPR optimization focus on the following class of waveforms:
o DFT-S-OFDM
o QPSK modulation
o Inner and outer RB allocations
o Small RB allocation (1-16 RBs)
· Proposal 2: Study non-transparent techniques that allow a 0-dB MPR waveform to be transmitted at a transmit power exceeding the maximum power associated with the UE power class.
· Proposal 3: Study sideband tone reservation as a non-transparent waveform shaping technique to transmit DFT-S-OFM waveforms at a higher transmit power.
o Sideband tone reservation is given in units of RBs
· Proposal 4: For evaluating the benefits of tone reservation, use legacy R17 PUSCH waveforms as a baseline, with the excess bandwidth included in the total allocated bandwidth.
· Proposal 5: Study FDSS with bandwidth expansion as a non-transparent waveform shaping technique to transmit DFT-S-OFM waveforms at a higher transmit power.
o Excess bandwidth is given in units of RBs
o DMRS and data symbols undergo spectrum shaping
· Proposal 6: For FDSS with bandwidth expansion, link-level performance evaluations are required to assess the overall coverage gains. In particular, evaluate the impact of (a) the amount power spent in the excess bandwidth region and (b) gNB receiver handling of the excess bandwidth when receiving the PUSCH transmission for further processing.
· Proposal 7: For FDSS with bandwidth expansion, evaluate the impact of gNB not knowing the pulse shaping filter used by the UE (but aware of bandwidth expansion).
On enhancements to realize high power uplink transmissions in CA and DC
· Proposal 8: To facilitate higher power transmission in CA and DC scenarios, introduce signalling mechanisms between UE and gNB focused on
o increasing awareness of power or energy budget available at the UE for each carrier/band,
o aiding the selection of the best band combination for UL CA, and
o aiding scheduling policy when UE is configured with multiple bands in UL CA, for e.g., selecting preferred carrier for servicing uplink, or adaptive load sharing across carriers.
· Proposal 9: Introduce signaling to allow UE to report aspects related to power management and RF exposure.
· Proposal 10: Enhance the current power headroom reporting framework to allow a user to also report P-MPR (via MPE field) for FR1 carriers.
· Proposal 11: Enhance the current power headroom reporting framework to allow a user to report power headroom for a carrier that is configured for downlink but not for uplink (i.e., no active uplink BWP).
· Proposal 12: Introduce MAC-CE signaling to allow UE to report energy headroom for each of the bands in a CA/DC configuration given to the UE.
o FFS: signaling details, including, periodicity, reporting triggers, relation to PHR, how to handle multiple bands, reference power, etc.
Decision: The document is noted.
R1-2208412 Discussion on coverage enhancement in power domain Huawei, HiSilicon
R1-2208489 Discussion on power domain enhancements ZTE
R1-2208576 Discussion on power domain enhancements Spreadtrum Communications
R1-2208672 Discussions on power domain enhancements vivo
R1-2208847 The study of power domain enhancements OPPO
R1-2208964 Discussion on power domain enhancements CATT
R1-2209026 Discussion on power domain enhancements for CA/DC Fujitsu
R1-2209079 Discussions on power domain enhancement Intel Corporation
R1-2209224 Power domain enhancements Lenovo
R1-2209364 Discussion on power domain enhancements CMCC
R1-2209522 Discussion on power-domain enhancements MediaTek Inc.
R1-2209609 Discussion on power domain coverage enhancement Apple
R1-2209662 Uplink power enhancements InterDigital, Inc.
R1-2209673 Power Domain Enhancement Evaluation Methodology and Schemes Ericsson
R1-2209760 Power domain enhancements Samsung
R1-2209789 Power domain enhancements for Rel-18 CovEnh Sharp
R1-2209926 Discussion on power domain enhancements NTT DOCOMO, INC.
R1-2210166 RAN1 impacts for power domain enhancements Nokia, Nokia Shanghai Bell
[110bis-e-R18-Coverage-02] – Marco (Nokia)
Email discussion on power domain enhancements by October 19
- Check points: October 14, October 19
R1-2210322 FL summary of power domain enhancements (AI 9.14.2) Moderator (Nokia/Nokia Shanghai Bell)
R1-2210323 FL summary #2 of power domain enhancements (AI 9.14.2) Moderator (Nokia/Nokia Shanghai Bell)
From Oct 13th GTW session
Agreement
The following work split principles will be adopted in RAN1 for power domain enhancement throughout Rel-18 from RAN1 perspective and send LS to RAN4 in this meeting:
· RAN1 performs link level simulations of candidate solutions for power domain enhancements to study at least the SNR variation, PAPR/CM, and EVM, brought by each solution.
o Transparent MPR/PAR reduction solutions can be considered as a benchmark for studying the performance of non-transparent solutions.
· RAN1 is not expected to perform RF simulations of candidate solutions for power domain enhancements
o Results of RF simulations can be included in RAN1 contributions
· RAN1 will assess RAN1 specification impact of candidate MPR/PAR reduction solutions
o A list of candidate solutions, including necessary parameters, from RAN1 perspective should be ready before the end of RAN1 #111, and should be included in an LS to RAN4.
· RAN1 understands that RAN4 is responsible for selecting the Rel-18 MPR/PAR reduction solution, if any.
R1-2210324 FL summary #3 of power domain enhancements (AI 9.14.2) Moderator (Nokia/Nokia Shanghai Bell)
Decision: As per email decision posted on Oct 18th,
R1-2210563 [Draft] LS on work split principles adopted in RAN1 for power domain enhancements Moderator (Nokia)
Decision: The draft LS R1-2210563 is endorsed in principle with modifying (‘RAN2’ should be ‘RAN4’ in “ACTION: RAN1 respectfully requests RAN2 to take the above into account in their future work.”). Final LS is approved in R1-2210674.
Conclusion
Sub-PRB transmission is de-prioritized for the study of MPR/PAR reduction solutions in Rel-18.
Agreement
The following spectrum extension options for frequency domain spectrum shaping with spectrum extension (FDSS-SE), are considered for studying MPR/PAR reduction enhancements in Rel-18:
· Option 1: Symmetric extension
· Option 2: Cyclic extension
· Option 3: Cyclic shift plus symmetric extension.
Agreement
The following design aspects of tone reservation (TR), are considered for studying MPR/PAR reduction enhancements in Rel-18:
· Sideband tone reservation size is expressed in integer units of RBs.
· FFS:
o Sideband tone reservation size
o Sideband tone reservation size determination
o Whether PRTs are added only to data or also DMRS symbols
R1-2210325 FL summary #4 of power domain enhancements (AI 9.14.2) Moderator (Nokia/Nokia Shanghai Bell)
From Oct 18th GTW session
Agreement
For enhancements to realize increasing UE power high limit for CA and DC, RAN1 can study based on RAN4’s input
· Whether RAN1 enhancements to information exchange between UE and gNB are needed to improve scheduling and network performance when using higher power CA/DC.
o FFS how to realize such information exchange, e.g., signalling enhancement, and what is the spec impact.
Decision: As per email decision posted on Oct 19th,
R1-2210673 [Draft] LS on enhancements to realize increasing UE power high limit for CA and DC Moderator (Nokia)
Decision: The draft LS R1-2210673 is endorsed in principle. Final LS is approved in R1-2210739.
Agreement
DFT-s-OFDM is the target waveform for the study and, if applicable, the design of MPR/PAR reduction solutions in Rel-18.
Note: No doubt from RAN1 about the offline consensus “Results concerning the application of solutions for DFT-s-OFDM to CP-OFDM can be presented by companies in their contributions”.
Agreement
For power-domain enhancements targeting MPR/PAR reduction, study the following configurations for DFT-S-OFDM:
· At least pi/2-BPSK and QPSK modulation are considered
o FFS: other modulations, e.g., 16-QAM
· Any number of RB can be considered
· The starting RB of the allocation can be any RB in the BWP
o FFS:
§ Whether restrictions on the number of allocated RB or on the starting RB of the allocation are considered.
Agreement
At least the following candidate solutions for MPR/PAR reduction will be studied in RAN1.
• Frequency domain spectrum shaping w/ spectrum extension
• Frequency domain spectrum shaping w/o spectrum extension
• Tone reservation (which can only be w/ spectrum extension)
Decision: As per email decision posted on Oct 20th,
Agreement
The following design aspects of frequency domain spectrum shaping with spectrum extension (FDSS-SE), are considered for studying MPR/PAR reduction enhancements in Rel-18:
• Spectrum extension size is expressed in integer units of RBs.
• Both DMRS and data symbols undergo spectrum shaping
• FFS:
o Which extensions factor(s) to consider, where extension factor (α) is given by spectrum extension size / Total allocation size.
o Impact of shaping filter on FDSS-SE performance
o How to extend DMRS sequence to spectrum extensions, based on either the existing ZC-sequence DMRS or low-PAPR DMRS for PUSCH (FG 16-6c)
o How extension size is determined
Agreement
For link-level performance evaluation:
All considered solutions should be configured to operate with same amount of time-frequency resource and a same spectral efficiency, that is:
Note: it is understood that minor TBS variations across different waveform configurations can occur and are acceptable.
Agreement
For link-level performance evaluation, the performance of the considered MPR/PAR reduction solutions
is studied using at least the metrics included in the work split principles for
power domain enhancement agreed by RAN1 for Rel-18, for instance, but no
limited to, , defined as
the SNR variation w.r.t. baseline under the requirement BLER=10-1.
• FFS whether further definition or refinement of the metrics is needed
Note: metrics other than the ones included in the work split principles for power domain enhancement agreed by RAN1 for Rel-18 can be reported by companies.
Agreement
For link-level performance evaluation, companies are encouraged to report configuration details of the following aspects, when applicable:
• Shaping filter used for evaluating frequency domain spectrum shaping w/ and w/o spectrum extension (both the filter used at the transmitter and at the receiver should be reported, if the two filters are assumed to be mismatched).
• PRT generation algorithm used for evaluation tone reservation w/ spectrum extension.
• Design details and configuration of any transparent scheme used as benchmark
Agreement
For link-level performance evaluation of MPR/PAR reduction solutions involving the use of Tx filter, companies are encouraged to assume a Tx filter which fulfils a set of spectrum flatness requirements, e.g., existing RAN4 spectrum flatness requirements
For link-level performance evaluation of MPR/PAR reduction solutions involving the use of spectrum extensions or sideband, companies are encouraged to report whether/how the extended portion of the spectrum is handled by the receiver in the simulations.
R1-2210326 Final FL summary of power domain enhancements (AI 9.14.2) Moderator (Nokia/Nokia Shanghai Bell)
R1-2210167 Dynamic switching between DFT-s-OFDM and CP-OFDM Nokia, Nokia Shanghai Bell
o RB regions and associated MPR (i.e., DFT-s-OFDM is used when the PUSCH is scheduled in the outer/edge regions and CP-OFDM is used when the PUSCH is scheduled in the inner RB region),
o PHR limitation (i.e., DFT-s-OFDM is used when the latest PHR is sufficiently small, otherwise CP-OFDM),
o Total allocated RBs (i.e., DFT-s-OFDM is used when the total number of allocated RBs is sufficiently small, otherwise CP-OFDM).
· Proposal 8. RAN1 to study enhancements for power headroom reporting for assisting gNB on selecting a suitable waveform.
Decision: The document is noted.
R1-2208413 Discussion on dynamic waveform switching for coverage enhancement Huawei, HiSilicon
R1-2208490 Discussion on dynamic waveform switching ZTE
R1-2208577 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Spreadtrum Communications
R1-2208673 Discussions on dynamic switching between DFT-S-OFDM and CP-OFDM vivo
R1-2208785 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM China Telecom
R1-2208848 Supporting of dynamic switching between DFT-S-OFDM and CP-OFDM OPPO
R1-2208965 Dynamic switching between DFT-S-OFDM and CP-OFDM CATT
R1-2209080 Dynamic switching between DFT-S-OFDM and CP-OFDM waveform Intel Corporation
R1-2209117 Considerations on dynamic waveform switching for NR UL Sony
R1-2209160 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NEC
R1-2209162 Discussion on dynamic waveform switching Panasonic
R1-2209205 Dynamic switching between DFT-S-OFDM and CP-OFDM InterDigital, Inc.
R1-2209225 Discussion on dynamic switching between DFT-s-OFDM and CP-OFDM Lenovo
R1-2209248 Discussion on solutions for NR dynamic switching between DFT-S-OFDM and CP-OFDM Mavenir
R1-2209273 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM xiaomi
R1-2209365 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM CMCC
R1-2209413 Dynamic switching between DFT-S-OFDM and CP-OFDM ETRI
R1-2209433 Discussion on Dynamic switching between DFT-s-OFDM and CP-OFDM Fujitsu Limited
R1-2209523 Discussion on dynamic switching between waveforms MediaTek Inc.
R1-2209610 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Apple
R1-2209674 Discussion on Dynamic UL Waveform Switching Ericsson
R1-2209761 Dynamic switching between DFT-S-OFDM and CP-OFDM Samsung
R1-2209790 Dynamic switching between DFT-S-OFDM and CP-OFDM for Rel-18 CovEnh Sharp
R1-2209804 Discussion on dynamic waveform switching for NR coverage enhancement LG Electronics
R1-2209927 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NTT DOCOMO, INC.
R1-2210015 Dynamic switching between DFT-S-OFDM and CP-OFDM Qualcomm Incorporated
R1-2210115 Discussion on Dynamic switching between DFT-S-OFDM and CP-OFDM CEWiT
[110bis-e-R18-Coverage-03] – Paul (InterDigital)
Email discussion on dynamic switching between DFT-S-OFDM and CP-OFDM by October 19
- Check points: October 14, October 19
R1-2210431 Summary #1 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
R1-2210432 Summary #2 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
Presented in Oct 13th GTW session
Decision: As per email decision posted on Oct 16th,
Agreement
Dynamic waveform switching enhancement in R18 is only applicable to PUSCH channel.
R1-2210433 Summary #3 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From Oct 17th GTW session
Working Assumption
Support at least one of the following options for the dynamic waveform indication in R18:
· Alt 1: Indication from an UL scheduling DCI
o Alt 1-A: New field in scheduling DCI
o Alt 1-B: Reuse existing field in scheduling DCI
§ Alt 1-B-1: Explicit indication by repurposing field, e.g.
· Add one column to TDRA table
· Add one column to MCS table(s)
· Other solutions not precluded
§ Alt 1-B-2: Implicit determination from condition(s) on scheduling information, e.g.
· RA type, MSB of RA
· Number of RBs (below threshold or multiple of 2,3,5)
· Location of RB allocation within carrier and the associated MPR
· MCS below threshold
· Number of PUSCH repetitions (or whether PUSCH repetition is used) and/or TBoMS
· Number of DMRS CDM group(s) without data
· Precoding information and number of layers
· SRI
· Condition over multiple types of scheduling information
· Other types of scheduling information not precluded
o Indicated waveform applies at least to the scheduled PUSCH transmission
§ FFS: Whether it also applies to subsequent transmissions, and of which type
o FFS: DCI formats can contain the indication
o FFS: Indication applies only if condition(s) are satisfied (e.g. PDCCH occasion, /RNTI, /Search space of the scheduling DCI, latest PHR reported by the UE, etc.)
· Alt 2: Indication from a non-UL scheduling DCI
o FFS: DCI formats that can provide the indication (e.g. Downlink DCI, UE-group common DCI)
o FFS: Types of subsequent transmissions to which indication is applicable
From Oct 18th GTW session
Agreement
To study and if necessary, specify, enhancements to assist the scheduler in determining waveform switching, such as:
· Reporting power headroom related information
· Other solutions are not precluded
Decision: As per email decision posted on Oct 21st,
Agreement
Dynamic waveform switching enhancement in R18 is applicable to 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.
Final summary in R1-2210749.
Please refer to RP-221858 for detailed scope of the WI on further NR coverage enhancements.
R1-2212851 Session notes for 9.14 (Further NR coverage enhancements) Ad-Hoc Chair (CMCC)
Endorsed and contents incorporated below.
[111-R18-CovEnh] – Nanxi (China Telecom)
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-2210879 Discussion on PRACH coverage enhancements Huawei, HiSilicon
R1-2211033 Discussions on issues of PRACH coverage enhancements vivo
R1-2211047 Discussion on PRACH coverage enhancements ZTE
R1-2211087 Discussion on PRACH coverage enhancements Fujitsu
R1-2211185 PRACH coverage enhancements CATT
R1-2211254 Discussion on PRACH coverage enhancements Spreadtrum Communications
R1-2211350 Discussion on PRACH coverage enhancements xiaomi
R1-2211423 Discussions on PRACH coverage enhancement Intel Corporation
R1-2211474 PRACH coverage enhancements OPPO
R1-2211537 Discussion on PRACH coverage enhancement China Telecom
R1-2211541 PRACH coverage enhancements TCL Communication Ltd.
R1-2211568 PRACH coverage enhancements ETRI
R1-2211573 PRACH coverage enhancements Lenovo
R1-2211592 Discussion on PRACH coverage enhancements Panasonic
R1-2211595 PRACH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2211630 PRACH Coverage Enhancement using Multi PRACH Transmissions Sony
R1-2211705 Discussion on PRACH coverage enhancements CMCC
R1-2211711 Discussion on PRACH coverage enhancements InterDigital, Inc.
R1-2211837 Discussion on PRACH coverage enhancement Apple
R1-2211881 Discussion on PRACH Resource for multiple PRACH transmissions FGI
R1-2212562 Discussion on PRACH coverage enhancement Ericsson (rev of R1-2211895)
R1-2211931 Discussion on PRACH repeated transmission for NR coverage enhancement LG Electronics
R1-2212009 Discussion on PRACH coverage enhancements NTT DOCOMO, INC.
R1-2212073 PRACH coverage enhancements Samsung
R1-2212145 PRACH Coverage Enhancements Qualcomm Incorporated
R1-2212181 Views on multiple PRACH transmission for coverage enhancement Sharp
R1-2212255 Discussion on PRACH coverage enhancements MediaTek Inc.
R1-2212273 Discussion on issues of PRACH coverage enhancement Mavenir
R1-2212360 Discussion on PRACH coverage enhancement NEC
R1-2212566 FL Summary#1 on PRACH coverage enhancements Moderator (China Telecom)
From Nov 14th session
Agreement
For multiple PRACH transmissions with same Tx beam, support to differentiate at least between multiple PRACH transmissions and single PRACH transmissions.
Agreement
For multiple PRACH transmissions with same Tx beam, to differentiate the multiple PRACH transmissions with single PRACH transmission, consider one or multiple of the following options.
· Option 1: Multiple PRACH are transmitted with separate preamble on shared ROs.
· Option 2: Multiple PRACH are transmitted on separate ROs.
· Option 3: Partial of multiple PRACHs are transmitted with separate preamble on shared ROs, while the other multiple PRACHs are transmitted on separate ROs.
· Other options are not precluded.
· Note: Shared or separate RO/preamble means that the RO/preamble is shared or separated with single PRACH transmission.
Agreement
Study at least the following case for multiple PRACH transmissions with different Tx beams.
· UE uses different TX beams to transmit the multiple PRACH over ROs associated with the same SSB/CSI-RS
· FFS: UE uses different TX beams to transmit the multiple PRACH over ROs associated with different SSBs /CSI-RSs, where the different SSBs/CSI-RSs are not associated with the same RO.
· Note: not related to decision on CFRA
Note: UE uses different TX beams to transmit the multiple PRACH over ROs associated with different SSBs/CSI-RSs, where the different SSBs/CSI-RSs are associated with the same RO is not considered.
Working Assumption
Simulation results for multiple PRACH transmissions with different beam(s) and same beam(s) (baseline) to be discussed in the next meeting.
· Simulation assumptions in TR 38.830 are used as the starting point for the simulation.
o Focus on FR2.
§ UE antenna configuration 2-2-2(baseline), 1-4-1(optional)
o Performance metric: 0.1% false alarm, 1% miss-detection
o Companies report the number of beams, the beam widths, beam correspondence assumption, and the boresights.
· Channel model for link-level simulation: CDL-A defined in table 7.7.1-1 in TR 38.901.
· Both that UE fulfills beamCorrespondence requirements Without UL-BeamSweeping and UE fulfils beamCorrespondence requirements With UL-BeamSweeping can be considered in the simulation are used as starting point for simulation.
R1-2212567 FL Summary#2 on PRACH coverage enhancements Moderator (China Telecom)
From Nov 17th session
Agreement
For multiple PRACH transmissions with same Tx beam, down-select one option from the following options.
Agreement
Final summary in R1-2212568.
R1-2210880 Discussion on coverage enhancement in power domain Huawei, HiSilicon
R1-2211034 Discussions on issues of power domain enhancements vivo
R1-2211048 Discussion on power domain enhancements ZTE
R1-2211088 Discussion on Power domain enhancements for CA/DC Fujitsu
R1-2211186 Discussion on enhancements to reduce MPR/PAR CATT
R1-2211255 Discussion on power domain enhancements Spreadtrum Communications
R1-2211351 Discussion on power domain enhancements xiaomi
R1-2211424 Discussions on power domain enhancement Intel Corporation
R1-2211475 The study of power domain enhancements OPPO
R1-2211574 Power domain enhancements Lenovo
R1-2211593 Discussion on power domain enhancements Panasonic
R1-2211596 RAN1 impacts for power domain enhancements Nokia, Nokia Shanghai Bell
R1-2211706 Discussion on power domain enhancements CMCC
R1-2211712 Discussion on power domain enhancements InterDigital, Inc.
R1-2211838 Discussion on power domain coverage enhancement Apple
R1-2211896 Power Domain Enhancement Evaluation Methodology and Schemes Ericsson
R1-2212010 Discussion on power domain enhancements NTT DOCOMO, INC.
R1-2212074 Power domain enhancements Samsung
R1-2212146 Power-domain enhancements Qualcomm Incorporated
R1-2212182 Power domain enhancements for Rel-18 CovEnh Sharp
R1-2212256 Discussion on power domain enhancements MediaTek Inc.
R1-2212282 DMRS design for power domain enhancements Indian Institute of Tech (H)
R1-2212573 FL summary of power domain enhancements (AI 9.14.2) Moderator (Nokia)
R1-2212574 FL summary #2 of power domain enhancements (AI 9.14.2) Moderator (Nokia)
From Nov 15th session
Agreement
Agreement
For RAN1 link-level performance
evaluation of MPR/PAR reduction solutions involving the use of Tx spectrum shaping filter, companies are encouraged to use at least the
following spectrum shaping filter configuration for calibration purpose:
There is no restriction to use
other spectrum shaping filter coefficients in simulations, e.g., [1 0.28].
Note: the above does not have spec impact.
Agreement
The following non-transparent solutions for MPR/PAR reduction are currently under discussion in RAN1.
In addition, transparent schemes, for instance but not limited to frequency domain spectrum shaping w/o spectrum extension or schemes based on clipping and filtering, are also being evaluated to serve as a benchmark to assess the benefits of non-transparent solutions. Companies are allowed to use any transparent transmission scheme of their choice.
Agreement
At least the symmetric spectrum extension option for frequency domain spectrum shaping with spectrum extension (FDSS-SE), are considered for studying MPR/PAR reduction enhancements in Rel-18.
Conclusion
It is RAN1 understanding that:
· Performance comparison based on net gain results combining transmitter and receiver performance is performed by RAN4.
· No final decision would be taken by RAN1 on which MPR/PAR reduction solution, will be specified in Rel-18, if any, since this is RAN4’s responsibility.
o It does not preclude RAN1 specification impact
Agreement
For the study of the PAPR/CM of DMRS when considering tone reservation as candidate enhancement for MPR/PAR reduction in Rel-18, RAN1 to consider at least the case that PRTs are added to the DMRS symbols (in the sideband). The case of PRTs not added to DMRS symbols can be used as a benchmark.
Agreement
The LS out RAN1 aims at drafting before the end of RAN1 #111 should include at least the following three parts:
1. List of candidate non-transparent and an initial list of transparent (if any) schemes considered for study by RAN1
2. Schemes-specific parameterization used by RAN1 for evaluation, e.g., spectrum extension factor and cyclic shift (if applicable), sideband size, filter assumptions (if any), channel model and so on.
3. Further parameterizations used in RAN1 evaluations, e.g., carrier frequency, channel model and so on.
R1-2212575 FL summary #3 of power domain enhancements (AI 9.14.2) Moderator (Nokia)
From Nov 17th session
Agreement
The following baseline parameterization is used for link-level performance evaluation of MPR-PAR reduction solutions in RAN1 for Rel-18.
|
Channel |
PUSCH, 14 symbols |
|
Carrier frequency and scenario |
4GHz (Urban), 28GHz (Urban) 700MHz (Rural), |
|
Channel BW |
100MHz for Urban 20MHz for Rural, |
|
SCS |
30 kHz (4GHz), 120 kHz (28GHz) 15 kHz (700 MHz), |
|
Channel model |
TDL-C 300ns for FR1 Urban (4GHz), TDL-A 30ns for FR2 Urban (28GHz), TDL-D 30ns for Rural |
|
UE speed |
3km/h |
|
Waveform |
According to agreements |
|
Modulation |
According to agreements |
|
Number of Tx antennas |
1, Optional: 2 |
|
Number of Rx antennas |
4 for FR1 Urban, 2 for FR2, 2 or 4 for FR1 Rural, |
|
Number of DMRS symbols |
2 |
|
Number of PUSCH data symbols |
12 |
|
HARQ configuration |
No retransmissions |
|
Frequency hopping |
Disabled |
|
Number of PRBs |
Reported by companies |
|
MCS |
Chosen as a function of the number of PRBs to guarantee same spectral efficiency between MPR/PAR reduction solutions and baseline/benchmarks as per agreements |
|
Extension factor [FDSS-SE] / sideband size [TR] (α) |
[1/8, 1/4, 3/8] is encouraged. |
|
BLER |
10% |
For any parameter that is not listed in the table, companies are encouraged to consider corresponding value from TR 38.830 (or TR 38.868, if the parameter is absent in TR 38.830) and report the parameter with the results.
Notes:
· Other configurations and scenarios can be studied, and corresponding results can be reported.
· RAN1 to inform RAN4 about the content of the table.
· This table can be updated in future meetings, especially if alignment with assumptions and parameterization in RAN4 is needed
Agreement
Study the PAPR/CM[/OBO] of DMRS with FDSS-SE, e.g., the following solutions:
· Option 1 - Based on low PAPR Type 1 DMRS sequence:
o 1-a: A DMRS sequence is generated considering the number of PRBs in the inband + extension. The sequence length depends on the number of PRBs in the inband + extension.
o 1-b A DMRS sequence is generated considering the number of PRBs in the inband (no extension). The sequence length depends on the number of PRBs in the inband. The sequence is then cyclically extended to span the PRBs in the extension.
o 1-c A DMRS sequence is generated considering the number of PRBs in the inband (no extension). The sequence length depends on the number of PRBs in the inband. DMRS extension is applied similar to data to span the PRBs in the extension.
· Option 2 - Based on low PAPR type 2 DMRS sequence
o Variances like those of Option 1 can be referred
· Option 3 – For in-band DMRS lengths 6/12/18/24 symbols, DMRS sequence is obtained by DFT transformation of low PAPR sequence type 1. Then the sequence is extended to span the PRBs in the extension in the same way as data extension.
Note: Other solutions can be studied. Comparison with the three solutions above is encouraged. Sequence with different density between in-band and extension can be studied.
R1-2212576 FL summary #4 of power domain enhancements (AI 9.14.2) Moderator (Nokia)
From Nov 18th session
Working Assumption
· The following set of configurations is for companies’ consideration for the calibration of the link performance of MPR/PAR reduction techniques.
|
|
No spectrum extension |
With spectrum extension |
|||||
|
TBS value |
Tput estimation for DDDSU @4GHz |
#PRBs |
MCS |
#PRBs before extension |
#PRBs after extension |
MCS |
Spectrum extension factor |
|
2408 |
963.2 kbps |
16 |
7 |
14 |
16 |
8 |
1/8 |
|
5376 |
~2.15 Mbps |
32 |
8 |
28 |
32 |
9 |
1/8 |
|
272 |
108.8 kbps |
8 |
0 |
6 |
8 |
1 |
¼ |
|
1032 |
412.8 kbps |
8 |
6 |
6 |
8 |
8 |
¼ |
|
2152 |
~0.9 Mbps |
40 |
2 |
30 |
40 |
3 |
¼ |
|
4992 |
~2.0 Mbps |
40 |
6 |
30 |
40 |
8 |
¼ |
|
552 |
220.8 kbps |
16 |
0 |
10 |
16 |
2 |
3/8 |
|
1736 |
694.6 kbps |
32 |
2 |
20 |
32 |
4 |
3/8 |
|
[432 |
172.8 kbps |
8 |
2 |
6 |
8 |
3 |
¼] |
|
[808 |
323.2 kbps |
24 |
0 |
18 |
24 |
1 |
¼] |
· The values above serve as a common basis, but any other configuration and result reported by companies will be considered for any input related to LLS that RAN1 may provide to RAN4.
· Results of the simulations of MPR/PAR reduction solutions which companies may report in contributions to RAN1 #112 should be reported using the template in R1-2212918.
· Note: At least 10% BLER SNR is reported
R1-2212916 [Draft] LS to RAN4 for further information on RAN1 assumptions for LLS performance evaluation of MPR/PAR reduction solutions Moderator (Nokia)
Decision: The draft LS in R1-2212916 is endorsed in principle. Final LS is approved in R1-2212917.
Final FL summary in R1-2212577.
R1-2212918 Template for reporting results of LLS performance evaluations of MPR/PAR reduction solutions Moderator (Nokia)
R1-2210881 Discussion on dynamic waveform switching for coverage enhancement Huawei, HiSilicon
R1-2211035 Discussions on issues of dynamic waveform switching vivo
R1-2211049 Discussion on dynamic waveform switching ZTE
R1-2211089 Discussion on Dynamic switching between DFT-s-OFDM and CP-OFDM Fujitsu
R1-2211134 Discussion on dynamic waveform switching Panasonic
R1-2211187 Dynamic switching between DFT-S-OFDM and CP-OFDM CATT
R1-2211256 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Spreadtrum Communications
R1-2211324 Dynamic switching between DFT-S-OFDM and CP-OFDM InterDigital, Inc.
R1-2211352 Discussion on dynamic switching between DFT-s-OFDM and CP-OFDM xiaomi
R1-2211390 Dynamic switching between DFT-S-OFDM and CP-OFDM waveform Intel Corporation
R1-2211476 Considerations on dynamic switching between DFT-S-OFDM and CP-OFDM OPPO
R1-2211538 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM China Telecom
R1-2211569 Dynamic switching between DFT-S-OFDM and CP-OFDM ETRI
R1-2211575 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Lenovo
R1-2211597 Dynamic switching between DFT-s-OFDM and CP-OFDM Nokia, Nokia Shanghai Bell
R1-2211631 Further considerations on dynamic waveform switching for NR UL Sony
R1-2211707 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM CMCC
R1-2211839 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Apple
R1-2211879 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM FGI
R1-2211897 Discussion on Dynamic UL Waveform Switching Ericsson
R1-2211932 Discussion on dynamic waveform switching for NR coverage enhancement LG Electronics
R1-2212011 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NTT DOCOMO, INC.
R1-2212075 Dynamic switching between DFT-S-OFDM and CP-OFDM Samsung
R1-2212147 Dynamic switching between DFT-S-OFDM and CP-OFDM Qualcomm Incorporated
R1-2212183 Dynamic switching between DFT-S-OFDM and CP-OFDM for Rel-18 CovEnh Sharp
R1-2212257 Dynamic switching between waveforms MediaTek Inc.
R1-2212272 Discussion on Dynamic switching mechanism of CP-OFDM and DFT-S-OFDM Mavenir
R1-2212361 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NEC
R1-2212431 Discussion on Dynamic switching between DFT-S-OFDM and CP-OFDM CEWiT
R1-2212445 Summary #1 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
R1-2212446 Summary #2 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
R1-2212445 Summary #1 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From Nov 15th session
Working Assumption
Support at least one of the following options for the dynamic waveform indication in R18:
· Alt 1: Indication from an UL scheduling DCI
o Alt 1-A: New field in scheduling DCI
o Alt 1-B: Reuse existing field in scheduling DCI
§ Alt 1-B-1: Explicit indication by repurposing field, e.g.
· Add one column to TDRA table
· Add one column to MCS table(s)
· Other solutions not precluded
§ Alt 1-B-2: Implicit determination from condition(s) on scheduling information, e.g.
· RA type, MSB of RA
· Number of RBs (below threshold or multiple of 2,3,5)
· Location of RB allocation within carrier and the associated MPR
· MCS below threshold
· Number of PUSCH repetitions (or whether PUSCH repetition is used) and/or TBoMS
· Number of DMRS CDM group(s) without data
· Precoding information and number of layers
· SRI
· Condition over multiple types of scheduling information
· Other types of scheduling information not precluded
o Indicated waveform applies at least to the scheduled PUSCH transmission
o FFS: Whether it also applies to subsequent transmissions, and of which type
o FFS: DCI formats can contain the indication
o FFS: Indication applies only if condition(s) are satisfied (e.g. PDCCH occasion, /RNTI, /Search space of the scheduling DCI, latest PHR reported by the UE, etc.)
· Alt 2: Indication from a non-UL scheduling DCI
o FFS: DCI formats that can provide the indication (e.g. Downlink DCI, UE-group common DCI)
o FFS: Types of subsequent transmissions to which indication is applicable
Agreement
For DCI based solution,
· For supported dynamically scheduled PUSCH, support dynamic waveform switching indication from UL scheduling DCI
o Note: “Supported dynamically scheduled PUSCH” is to be confirmed in further discussion
o Note: It does not imply that the waveform switching indication applies to other transmission or not
Note: the working assumption made in RAN1#110b-e for “Support at least one of the following options for the dynamic waveform indication in R18” does not need to be confirmed
R1-2212446 Summary #2 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From Nov 17th session
Working Assumption
Support new 1-bit field for dynamic waveform indication from UL scheduling DCI
· Note: no change of the current size alignment procedure between UL DCI and DL DCI
Agreement
Study the necessity of the following potential enhancements to assist the scheduler in determining waveform switching:
· Reporting power headroom related information based on PCMAX,f,c applicable to a target waveform
o Target waveform can be same or different from waveform of an actual PUSCH transmission
o FFS target RB allocation and/or target modulation order can be same or different from respective properties of an actual PUSCH transmission
o FFS determination of target waveform, target RB allocation, target modulation order
o FFS details, e.g. report PCMAX,f,c or Type 1 power headroom for a waveform, or difference thereof between waveforms
· PHR triggering enhancements, e.g.
o Network-triggered PHR
o PH becomes lower (higher) than a threshold
o PHR triggered by waveform switching
· Reporting of recommended waveform or request to switch waveform
· Other solutions not precluded
Final summary in R1-2212983.
Please refer to RP-221858 for detailed scope of the WI on further NR coverage enhancements.
R1-2302069 Session notes for 9.14 (Further NR coverage enhancements) Ad-Hoc Chair (CMCC)
[112-R18-CovEnh] – Nanxi (China Telecom)
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-2300089 Discussion on PRACH coverage enhancements Huawei, HiSilicon
R1-2300244 Discussion on PRACH coverage enhancements Spreadtrum Communications
R1-2300276 PRACH coverage enhancements OPPO
R1-2300344 Discussion on PRACH coverage enhancements ZTE
R1-2300479 Discussions on PRACH coverage enhancements vivo
R1-2300495 Discussion on Resource Allocation for Multiple PRACH Transmission FGI
R1-2301770 Discussion on PRACH coverage enhancements xiaomi (rev of R1-2300561)
R1-2300667 PRACH coverage enhancements CATT
R1-2300728 Discussion on PRACH coverage enhancement China Telecom
R1-2300758 Discussion on PRACH coverage enhancements Fujitsu
R1-2300796 Discussion on PRACH coverage enhancements Panasonic
R1-2300828 Discussion on PRACH coverage enhancement NEC
R1-2300838 PRACH coverage enhancements TCL Communication Ltd.
R1-2300860 PRACH coverage enhancements Lenovo
R1-2300894 PRACH Coverage Enhancement using Multi PRACH Transmissions Sony
R1-2300904 Discussion on PRACH coverage enhancement Mavenir
R1-2300972 Discussions on PRACH coverage enhancement Intel Corporation
R1-2301027 Discussion on PRACH coverage enhancements CMCC
R1-2301053 PRACH coverage enhancements ETRI
R1-2301074 Discussion on PRACH repeated transmission for NR coverage enhancement LG Electronics
R1-2301171 Discussion on PRACH coverage enhancements InterDigital Communications
R1-2301185 Discussion on PRACH coverage enhancement Ericsson
R1-2301292 PRACH coverage enhancements Samsung
R1-2301374 Discussion on PRACH coverage enhancement Apple
R1-2301441 PRACH Coverage Enhancements Qualcomm Incorporated
R1-2301519 Discussion on PRACH coverage enhancements NTT DOCOMO, INC.
R1-2301550 Views on multiple PRACH transmission for coverage enhancement Sharp
R1-2301777 On PRACH coverage enhancements MediaTek Inc. (rev of R1-2301603)
R1-2301654 PRACH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2301848 FL Summary#1 on PRACH coverage enhancements Moderator (China Telecom)
From Monday session
Agreement
For multiple PRACH transmissions with same Tx beam, gNB can configure one or multiple values for the number of multiple PRACH transmissions.
Working Assumption
For multiple PRACH transmissions with same Tx beam, to differentiate the multiple PRACH transmissions with single PRACH transmission, at least support that multiple PRACH are transmitted on separate ROs.
Working Assumption
For multiple PRACH transmissions with same Tx beam, to differentiate the multiple PRACH transmissions with single PRACH transmission, support that multiple PRACH are transmitted with separate preamble on shared ROs.
R1-2301849 FL Summary#2 on PRACH coverage enhancements Moderator (China Telecom)
From Wednesday session
Conclusion
For multiple PRACH transmissions within one RACH attempt, they are only transmitted over ROs associated with the same SSB/CSI-RS.
Note: This applies for multiple PRACH transmissions with same Tx beam, and also applies for multiple PRACH transmissions with different Tx beam (if supported).
Agreement
For multiple PRACH transmissions with same Tx beam in one RACH attempt, transmission power ramping is not applied within one RACH attempt.
Agreement
For multiple PRACH transmissions with same Tx beam, only one RAR window is supported for RAR monitoring for one RACH attempt.
· FFS: the start position of the RAR window.
· FFS: RA-RNTI.
Agreement
For multiple PRACH transmissions with same Tx beam, "RO group" is assumed for multiple PRACH transmissions with separate preamble on shared ROs and/or multiple PRACH transmissions on separate ROs, and one RO group consists of valid RO(s) for a specific number of multiple PRACH transmissions.
· Note 1: All ROs in one RO group is associated with the same SSB(s).
· Note 2: Shared or separate RO/preamble means that the RO/preamble is shared or separated with single PRACH transmission.
· Note 3: whether/how to define “RO group” in specification will be discussed separately
· Note 4: Valid RO(s) refers to what is defined in existing specification
· FFS: whether and how to address collision between valid ROs for multiple PRACH transmissions and other existing ROs for legacy single PRACH transmission or other features, e.g., 2-step RACH.
· FFS: the time span of RO group.
· FFS: whether and how ROs can be shared between different RO groups for different number of multiple PRACH transmissions.
· FFS: other details
R1-2301850 FL Summary#3 on PRACH coverage enhancements Moderator (China Telecom)
From Thursday session
Agreement
Support {2, 4, 8} for the number of multiple PRACH transmissions with same Tx beams.
Note: It is summarized by FL that for the same number of PRACH transmissions per source,
· 1 source [Ericsson] shows that: Multiple PRACH transmitted by beam sweeping, where a UE has no prior knowledge of channel and sweeps Tx beams across 360 degrees horizontally and 180 degrees vertically, outperforms multiple PRACH transmissions with the same Tx wide beam (omni direction) by at least 1 dB, provided gNB configures only one SSB and receives PRACH with a wide beam.
· 3 sources [ZTE, Nokia, vivo] show that: A gain from about 1~3 dB of beam sweeping is observed if a UE is able to direct at least one of its Tx beams in the right direction or to narrow down the azimuth and/or zenith range of 360 degrees and/or 180 degrees for beam sweeping compared with multiple PRACH transmissions with the same Tx wide beam.
· 1 source [Huawei] shows that: compared to the same wide beam for multiple PRACH transmission, if different Tx beams are finer beams, then 3.9~5 dB gains are observed assuming that only one PRACH occasion with the best detected SINR is selected at the gNB reception, where the beam gain of fine beam is 4 times that of wide beam.
· 1 source [vivo] shows that: The performance of PRACH repetition with beam sweeping among beams far apart is 3 dB worse than PRACH repetition with single best beam
· 1 source [vivo] shows that: The performance of PRACH repetition with beam sweeping among beams in the directions close to the best Tx beam is 1dB worse than PRACH repetition with single best beam.
· 1 source [vivo] shows that: PRACH repetition via random beam directions performs 1 dB worse than PRACH repetition with omni beam.
R1-2300090 Discussion on coverage enhancement in power domain Huawei, HiSilicon
R1-2300245 Discussion on power domain enhancements Spreadtrum Communications
R1-2300277 The study of power domain enhancements OPPO
R1-2300345 Discussion on power domain enhancements ZTE
R1-2300480 Discussions on power domain enhancements vivo
R1-2300562 Discussion on power domain enhancements xiaomi
R1-2300668 Discussion on MPR/PAR reduction enhancements CATT
R1-2300729 Discussion on power domain enhancements China Telecom
R1-2300759 Discussion on Power domain enhancements Fujitsu
R1-2300797 Discussion on power domain enhancements Panasonic
R1-2300861 Power domain enhancements Lenovo
R1-2300895 Considerations on tone reservation for PAPR reduction Sony
R1-2300973 Discussions on power domain enhancement Intel Corporation
R1-2301028 Discussion on power domain enhancements CMCC
R1-2301172 Discussion on power domain enhancements InterDigital Communications
R1-2301186 Power Domain Enhancement Schemes and Performance Ericsson
R1-2301293 Power domain enhancements Samsung
R1-2301375 Discussion on power domain coverage enhancement Apple
R1-2301442 Power-domain enhancements Qualcomm Incorporated
R1-2301520 Discussion on power domain enhancements NTT DOCOMO, INC.
R1-2301778 Views on power domain enhancements MediaTek Inc. (rev of R1-2301604)
R1-2301995 DMRS design for power domain enhancements Indian Institute of Tech (H) (rev of R1-2301635)
R1-2301655 RAN1 impacts for power domain enhancements Nokia, Nokia Shanghai Bell
R1-2301869 FL summary of power domain enhancements (AI 9.14.2) Moderator(Nokia)
R1-2301870 FL summary #2 of power domain enhancements (AI 9.14.2) Moderator (Nokia)
R1-2301871 FL summary #3 of power domain enhancements (AI 9.14.2) Moderator (Nokia)
From Wednesday session
Agreement
Further discussions in RAN1 concerning means to facilitate higher power transmissions in CA and DC, if applicable, can target increasing gNB awareness of UE’s Tx power, e.g., PHR reporting enhancement such as current power class, power class change, or application of P-MPR by UE (subject to RAN4’s input).
o FFS: details.
Agreement
If FDSS-SE is supported in Rel-18, RAN1 to further study the following approaches for DMRS, when the DMRS sequence length before extension of the sequence, if any, is larger than or equal to 30:
· Approach A – the DMRS sequence is extended: A DMRS sequence is generated considering the number of PRBs in the inband (no extension). The sequence length depends on the number of PRBs in the inband. Two sequence types can be considered:
FFS: how the sequence is extended.
Note:
if low PAPR type 2 is used then both the number of PRBs in the inband
and the number of PRBs in the inband+extension must be valid DFT sizes as per
NR specification
Performance metrics considered for the study are PAPR, CM[, and OBO] for DMRS and 10% BLER SNR for data (to measure channel estimation accuracy).
Agreement
If FDSS-SE is supported in Rel-18, and RB allocations resulting in DMRS sequence length smaller than 30 before extension of the sequence, if any, are supported, RAN1 to study at least the following approaches:
FFS: how the sequence is extended.
Note:
if low PAPR type 2 is used then both the number of PRBs in the inband
and the number of PRBs in the inband+extension must be valid DFT sizes as per
NR specification
Note: Other sequences are not precluded for Approach A and Approach B.
Performance metrics considered for the study are PAPR, CM [, and OBO] for DMRS and 10% BLER SNR for data (to measure channel estimation accuracy).
Agreement
Include in the LS to RAN4 for reporting LLS results
Note: The excel file is used to collect the results.
R1-2301872 FL summary #4 of power domain enhancements (AI 9.14.2) Moderator (Nokia)
From Thursday session
Working Assumption
· The following set of configurations is for companies’ consideration for the comparsion of the performance of DMRS with FDSS-SE.
|
No spectrum extension |
With spectrum extension |
||||
|
#PRBs |
MCS |
#PRBs before extension |
#PRBs after extension |
MCS |
Spectrum extension factor |
|
8 |
0 [only QPSK] |
6 |
8 |
1 [only QPSK] |
¼ |
|
8 |
6 |
6 |
8 |
8 |
¼ |
|
40 |
2 |
30 |
40 |
3 |
¼ |
|
40 |
6 |
30 |
40 |
8 |
¼ |
|
|
|
|
|
|
|
|
[6 |
3 |
4 |
6 |
5 |
1/3] |
|
[36 |
7 |
32 |
36 |
8 |
1/9] |
· FR1 4GHz Urban scenario is prioritized.
· The following filters are for companies’ consideration for the calibration of the performance of DMRS with FDSS-SE
o 3-tap (0.28 1 0.28)
o [Truncated RRC (0.5, 0.1667) or 2-tap (1 0.28)]
· Note1: Considered metrics are PAPR/CM, 10% BLER SNR of data for the considered DMRS configuration (for measuring impact of channel estimation accuracy)[, and OBO]
· Note2: companies are encouraged to consider a receiver which at least makes use of the extension for the decoding (e.g., MRC)
· Note3: The values above serve as a common basis, but any other configuration can be studied by companies.
R1-2302080 [Draft] LS to RAN4 for results of the LLS performance evaluation of MPR/PAR reduction solutions Moderator (Nokia)
Decision: The Draft LS R1-2302080 is endorsed in principle. Final LS is approved in R1-2302081.
Final summary in R1-2301873.
R1-2300091 Discussion on dynamic waveform switching for coverage enhancement Huawei, HiSilicon
R1-2300246 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Spreadtrum Communications
R1-2300278 Considerations on dynamic switching between DFT-S-OFDM and CP-OFDM OPPO
R1-2300346 Discussion on dynamic waveform switching ZTE
R1-2300481 Discussions on dynamic waveform switching vivo
R1-2300563 Discussion on dynamic switching between DFT-s-OFDM and CP-OFDM xiaomi
R1-2300669 Dynamic switching between DFT-S-OFDM and CP-OFDM CATT
R1-2300730 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM China Telecom
R1-2300829 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NEC
R1-2300856 Dynamic switching between DFT-S-OFDM and CP-OFDM InterDigital, Inc.
R1-2300862 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Lenovo
R1-2300864 Discussion on dynamic waveform switching Panasonic
R1-2300896 Further considerations on dynamic waveform switching for the UE UL Sony
R1-2300903 Discussion on solutions for NR dynamic switching between DFT-S-OFDM and CP-OFDM Mavenir
R1-2300974 Dynamic switching between DFT-S-OFDM and CP-OFDM waveform Intel Corporation
R1-2301029 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM CMCC
R1-2301054 Dynamic switching between DFT-S-OFDM and CP-OFDM ETRI
R1-2301075 Discussion on dynamic waveform switching for NR coverage enhancement LG Electronics
R1-2301086 Discussion on dynamic waveform switching DENSO CORPORATION
R1-2301187 Discussion on Dynamic UL Waveform Switching Ericsson
R1-2301294 Dynamic switching between DFT-S-OFDM and CP-OFDM Samsung
R1-2301312 Discussion of dynamic switching between DFT-S-OFDM and CP-OFDM Transsion Holdings
R1-2301376 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Apple
R1-2301443 Dynamic switching between DFT-S-OFDM and CP-OFDM Qualcomm Incorporated
R1-2301521 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NTT DOCOMO, INC.
R1-2301540 Summary #1 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
R1-2301541 Summary #2 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
R1-2301551 Dynamic switching between DFT-S-OFDM and CP-OFDM for Rel-18 CovEnh Sharp
R1-2301779 Dynamic switching between waveforms MediaTek Inc. (rev of R1-2301605)
R1-2301656 Dynamic switching between DFT-s-OFDM and CP-OFDM Nokia, Nokia Shanghai Bell
R1-2301540 Summary #1 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
R1-2301541 Summary #2 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From Wednesday session
Agreement
For single TB scheduled by single DCI, support new 1-bit field for dynamic waveform indication from UL scheduling DCI.
Note: no change of the current size alignment procedure between UL DCI and DL DCI.
R1-2302124 Summary #3 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From Thursday session
Conclusion
There is no consensus to support “Dynamic waveform switching to PUSCH transmissions with a Type 2 configured grant” in R18.
Agreement
Dynamic waveform switching in R18 is not applicable to PUSCH transmissions with a Type 1 configured grant.
Conclusion
The dynamic waveform indication in a DCI containing a dynamic uplink grant applies only to PUSCH transmission(s) corresponding to the dynamic uplink grant.
Final summary in R1-2302222.
Please refer to RP-221858 for detailed scope of the WI on further NR coverage enhancements.
R1-2304174 Session notes for 9.12 (Further NR coverage enhancements) Ad-Hoc Chair (CMCC)
R1-2302350 Discussion on PRACH coverage enhancements Huawei, HiSilicon
R1-2302509 Discussions on remaining issues of PRACH coverage enhancements vivo
R1-2302573 PRACH coverage enhancements OPPO
R1-2302623 Discussion on PRACH coverage enhancements Spreadtrum Communications
R1-2302690 PRACH coverage enhancements CATT
R1-2302759 Discussion on PRACH coverage enhancements ZTE
R1-2302818 Discussions on PRACH coverage enhancement Intel Corporation
R1-2302835 PRACH coverage enhancements TCL Communication Ltd.
R1-2302863 PRACH Coverage Enhancement using Multiple PRACH Transmissions Sony
R1-2302880 PRACH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2302885 Discussion on PRACH coverage enhancements Panasonic
R1-2302915 Discussion on PRACH coverage enhancements Fujitsu
R1-2302970 Discussion on PRACH coverage enhancements xiaomi
R1-2303034 Discussion on PRACH coverage enhancement China Telecom
R1-2303086 Discussion on solutions for NR PRACH coverage enhancement Mavenir
R1-2303090 PRACH coverage enhancements Lenovo
R1-2303153 PRACH coverage enhancements Samsung
R1-2303206 PRACH coverage enhancements ETRI
R1-2303209 Discussion on PRACH coverage enhancements Quectel
R1-2303256 Discussion on PRACH coverage enhancements CMCC
R1-2303353 On PRACH coverage enhancements MediaTek Inc.
R1-2303411 Discussion on CFRA for Multiple PRACH Transmission FGI
R1-2303453 Discussion on PRACH coverage enhancements InterDigital, Inc.
R1-2303508 Discussion on PRACH coverage enhancement Apple
R1-2303615 PRACH Coverage Enhancements Qualcomm Incorporated
R1-2303640 Views on multiple PRACH transmission for coverage enhancement Sharp
R1-2303661 Discussion on PRACH coverage enhancement Ericsson
R1-2303681 Discussion on PRACH coverage enhancement NEC
R1-2303731 Discussion on PRACH coverage enhancements NTT DOCOMO, INC.
R1-2303750 Discussion on PRACH repeated transmission for NR coverage enhancement LG Electronics
[112bis-e-R18-Coverage-01] – Nanxi (China Telecom)
Email discussion on PRACH coverage enhancement by April 26th
- Check points: April 21, April 26
R1-2303959 FL Summary#1 on PRACH coverage enhancements Moderator (China Telecom)
From April 17th GTW session
Agreement
Confirm the following working assumptions.
|
Working Assumption For multiple PRACH transmissions with same Tx beam, to differentiate the multiple PRACH transmissions with single PRACH transmission, at least support that multiple PRACH are transmitted on separate ROs. · Note: Separate RO means that the RO is separated with single PRACH transmission. · FFS: whether Rel-17 framework of feature combination (FeatureCombination-r17) and additional RACH configuration (AdditionalRACH-Config-r17) can be reused for Rel-18 multiple PRACH transmissions to realize the corresponding PRACH resource partitioning.
Working Assumption For multiple PRACH transmissions with same Tx beam, to differentiate the multiple PRACH transmissions with single PRACH transmission, support that multiple PRACH are transmitted with separate preamble on shared ROs. · Note: Shared or separate RO/preamble means that the RO/preamble is shared or separated with single PRACH transmission. · FFS: whether Rel-17 framework of feature combination (FeatureCombination-r17) and additional RACH configuration (AdditionalRACH-Config-r17) can be reused for Rel-18 multiple PRACH transmissions to realize the corresponding PRACH resource partitioning. |
R1-2303960 FL Summary#2 on PRACH coverage enhancements Moderator (China Telecom)
From April 19th GTW session
Agreement
Send LS to inform RAN2 about the 2 confirmed Working Assumptions, and details on how to realize PRACH resource partitioning is up to RAN2.
Conclusion
There is no consensus to support multiple PRACH transmissions within one RACH attempt located at same time instance in Rel-18.
Note: multiple PRACH transmissions within one RACH attempt located at same time instance includes multiple PRACH transmissions in FDMed ROs located at the same time instance and multiple PRACH transmissions with different preambles in the same RO.
R1-2303961 FL Summary#3 on PRACH coverage enhancements Moderator (China Telecom)
From April 21st GTW session
Conclusion
There is no consensus to support utilizing different preambles during the multiple PRACH transmissions with the same Tx beam in one attempt.
Agreement
· Multiple PRACH transmissions within one RACH attempt are only performed within one RO group.
o The number of valid ROs in the RO group is equal to one of the configured number(s) of multiple PRACH transmissions.
§ Note1: If only one value is configured for multiple PRACH transmissions, then the number of valid ROs in the RO group is equal to this value.
§ Note2: If multiple values are configured for multiple PRACH transmissions, for each value, the number of valid ROs in the RO group is equal to the corresponding number of multiple PRACH transmissions.
§ Note 3: Valid RO(s) refers to what is defined in existing specification.
R1-2304070 [Draft] LS on PRACH coverage enhancement China Telecom
Decision: [Draft] LS R1-2304070 is endorsed in principle by appending RAN1 agreement “Agreement
Send LS to inform RAN2 about the 2 confirmed Working Assumptions, and details on how to realize PRACH resource partitioning is up to RAN2”, as well as fixing the formulation of the LS.
Agreement
Final LS R1-2304141 is approved.
R1-2303962 FL Summary#4 on PRACH coverage enhancements Moderator (China Telecom)
From April 25th GTW session
Agreement
The starting point of RAR window is after the last symbol of the last valid RO in the RO group corresponding to the multiple PRACH transmissions.
Note: Valid RO(s) refers to what is defined in existing specification, i.e., Section 8.1 in TS 38.213.
Note: The last valid RO is irrespective of whether the PRACH transmission on the last valid RO in the RO group is dropped or not.
R1-2304234 Final summary on PRACH coverage enhancements Moderator (China Telecom)
R1-2302351 Discussion on coverage enhancement in power domain Huawei, HiSilicon
R1-2302510 Discussions on remaining issues of power domain enhancements vivo
R1-2302574 The study of power domain enhancements OPPO
R1-2302624 Discussion on power domain enhancements Spreadtrum Communications
R1-2302691 Discussion on MPR/PAR reduction enhancements CATT
R1-2302760 Discussion on power domain enhancements ZTE
R1-2302787 Discussions on power domain enhancement Intel Corporation
R1-2302864 Considerations on tone reservation for PAPR reduction Sony
R1-2302881 RAN1 impacts for power domain enhancements Nokia, Nokia Shanghai Bell
R1-2302886 Discussion on power domain enhancements Panasonic
R1-2302916 Discussion on Power domain enhancements Fujitsu
R1-2302971 Discussion on power domain enhancements Xiaomi
R1-2303035 Discussion on power domain enhancements China Telecom
R1-2303091 Power domain enhancements Lenovo
R1-2303154 Power domain enhancements Samsung
R1-2303257 Discussion on power domain enhancements CMCC
R1-2303354 Views on power domain enhancements MediaTek Inc.
R1-2303454 Discussion on power domain enhancements InterDigital, Inc.
R1-2303509 Discussion on power domain coverage enhancement Apple
R1-2303616 Power-domain enhancements Qualcomm Incorporated
R1-2303658 Discussion on power domain enhancements Google Inc.
R1-2303662 Power Domain Enhancement Schemes and Performance Ericsson
R1-2303732 Discussion on power domain enhancements NTT DOCOMO, INC.
R1-2303751 Discussion on Power Domain Enhancements LG Electronics
R1-2303767 Power domain enhancements for Rel-18 CovEnh Sharp
R1-2303777 DMRS design for power domain enhancements Indian Institute of Tech (H)
[112bis-e-R18-Coverage-02] – Marco (Nokia)
Email discussion on power domain enhancements by April 26th
- Check points: April 21, April 26
R1-2303921 FL summary of power domain enhancements (AI 9.12.2) Moderator (Nokia)
Presented in April 17th GTW session
R1-2303922 FL summary #2 of power domain enhancements (AI 9.12.2) Moderator (Nokia)
Presented in April 19th GTW session
R1-2303923 FL summary #3 of power domain enhancements (AI 9.12.2) Moderator (Nokia)
From April 21st GTW session
Agreement
· If FDSS-SE is supported in Rel-18, DMRS are mapped on PRBs of both inband and extension and gNB can assume that they are filtered using the same Tx shaping filter as data.
· FFS: whether and which optimizations to Rel-15 and/or Rel-16 DMRS, including sequence extension and/or mapping, to be used with FDSS-SE, are needed.
· Note: whether this will have RAN1 specification impact (if any) is a separate discussion and subject to RAN4’s conclusion to support FDSS-SE as one MPR/PAR reduction solution for Rel-18 (if any).
R1-2303924 FL summary #4 of power domain enhancements (AI 9.12.2) Moderator (Nokia)
From April 25th GTW session
Observation
RAN1 discussed advantages and disadvantages of solutions included in R1-2302270 (R4-2303701) on enhancements to realize increasing UE power high limit for CA and DC. Pros and cons of the inclusion in the PHR report of at least one of the following quantities have been analyzed for different reporting mechanisms, triggers, and reporting periodicities:
· ∆PPowerClass
· Power class
· P-MPR
· Start and length of evaluation period for power class fallback
· Estimated duration of power class fallback
· Estimated duration over which UE can sustain Pcmax before additional P-MPR is required
· Sustainable duty cycle to prevent a fallback
· Energy/power availability
Note: Discussion is still ongoing, and its full current content can be found in Section 2.1.2 of R1-2303924.
R1-2303925 Final FL summary of power domain enhancements (AI 9.12.2) Moderator (Nokia)
R1-2302352 Discussion on dynamic waveform switching for coverage enhancement Huawei, HiSilicon
R1-2302511 Discussions on remaining issues of dynamic waveform switching vivo
R1-2302575 Considerations on dynamic switching between DFT-S-OFDM and CP-OFDM OPPO
R1-2302625 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Spreadtrum Communications
R1-2302692 Dynamic switching between DFT-S-OFDM and CP-OFDM CATT
R1-2302761 Discussion on dynamic waveform switching ZTE
R1-2302788 Dynamic switching between DFT-S-OFDM and CP-OFDM waveform Intel Corporation
R1-2302865 Considerations on dynamic waveform switching for various PUSCH types Sony
R1-2302882 Dynamic switching between DFT-s-OFDM and CP-OFDM Nokia, Nokia Shanghai Bell
R1-2302972 Discussion on dynamic switching between DFT-s-OFDM and CP-OFDM Xiaomi
R1-2303018 Dynamic switching between DFT-S-OFDM and CP-OFDM InterDigital, Inc.
R1-2303036 Discussion on dynamic waveform switching between DFT-s-OFDM and CP-OFDM China Telecom
R1-2303039 Discussion on dynamic waveform switching Panasonic
R1-2303085 Discussion on solutions for NR dynamic switching between DFT-S-OFDM and CP-OFDM Mavenir
R1-2303092 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Lenovo
R1-2303155 Dynamic switching between DFT-S-OFDM and CP-OFDM Samsung
R1-2303207 Dynamic switching between DFT-S-OFDM and CP-OFDM ETRI
R1-2303258 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM CMCC
R1-2303355 Dynamic switching between waveforms MediaTek Inc.
R1-2303382 Discussion of dynamic switching between DFT-S-OFDM and CP-OFDM Transsion Holdings
R1-2303510 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Apple
R1-2303617 Dynamic switching between DFT-S-OFDM and CP-OFDM Qualcomm Incorporated
R1-2303641 Dynamic switching between DFT-S-OFDM and CP-OFDM for Rel-18 CovEnh Sharp
R1-2303644 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Google Inc.
R1-2303663 Discussion on Dynamic UL Waveform Switching Ericsson
R1-2303682 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NEC
R1-2303733 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NTT DOCOMO, INC.
R1-2303752 Discussion on dynamic waveform switching for NR coverage enhancement LG Electronics
[112bis-e-R18-Coverage-03] – Paul (InterDigital)
Email discussion on dynamic switching between DFT-S-OFDM and CP-OFDM by April 26
- Check points: April 21, April 26
R1-2303788 Summary #1 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From April 17th GTW session
Agreement
For DCI format 0_1/0_2 containing dynamic waveform indication, bit width of each field is set to the maximum between the bit width of the field if transform precoding is disabled and the bit width of the field if transform precoding is enabled, if different.
· If, for the waveform indicated in the DCI, the bit width N of a field would be smaller than the bit width of the field set as per the above, UE decodes the field using N least significant bits. If N=0, the UE ignores the field for the indicated waveform.
R1-2303789 Summary #2 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From April 19th GTW session
Agreement
For potential enhancements to assist the scheduler in determining waveform switching, RAN1 to select 1 from the following options:
Conclusion
For PUSCH transmission scheduled by C-RNTI with DCI format 0_0, UE considers transform precoding enabled or disabled according to msg3-transformPrecoder as in legacy.
R1-2303790 Summary #3 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From April 21st GTW session
Agreement
Dynamic waveform switching is configured separately for each BWP, within PUSCH-Config.
Agreement
For UE configured with multi-PUSCH scheduling in time domain in a carrier (i.e. pusch-TimeDomainAllocationListForMultiPUSCH), DCI format 0_1 supports 1-bit field for dynamic waveform switching indication.
· When configured, 1-bit field indicates waveform for all scheduled PUSCH transmissions.
Agreement
For PUSCH scheduled by DCI format 0_1/0_2 with dynamic waveform switching indication field configured, and useInterlacePUCCH-PUSCH is not configured, downselect between following options:
· Option 1 (configuration restriction with error case handling):
o UE does not expect resourceAllocation set to resourceAllocationType0.
o If DFT-S-OFDM is indicated and resourceAllocation set to dynamicSwitch, UE does not expect MSB of FDRA field set to 0.
· Option 2 (UE only uses resourceAllocation if CP-OFDM is indicated):
o If DFT-S-OFDM is indicated, UE applies type 1 resource allocation.
o If CP-OFDM is indicated, UE applies resource allocation according to resourceAllocation IE.
o Size of FDRA field is aligned between size for type 1 resource allocation and size according to resourceAllocation IE.
Agreement
For PUSCH scheduled by DCI format 0_1/0_2 with dynamic waveform switching indication field configured, downselect between following options:
· Option 1 (configuration restriction with error case handling):
o UE does not expect dmrs-Type to be set to type2.
· Option 2 (UE only uses dmrs-Type if CP-OFDM is indicated):
o If DFT-S-OFDM is indicated, UE applies DMRS type 1.
o If CP-OFDM is indicated, UE applies DMRS type according to dmrs-Type.
Agreement
For configuration of 1-bit dynamic waveform switching indication in DCI format 0_1/0_2 per a carrier, downselect between following options:
· Option 1: Separate configuration of presence of dynamic waveform switching field for DCI format 0_1 and DCI format 0_2.
· Option 2: Common configuration of presence of dynamic waveform switching field for DCI format 0_1 and DCI format 0_2.
Final summary in R1-2304222.