Please refer to RP-193259 for detailed scope of the SI
R1-2005094 Session notes for 8.1 (Study on supporting NR from 52.6 GHz to 71 GHz) Ad-Hoc Chair (Ericsson)
Notes incorporated below.
R1-2004703 Summary of discussions on supporting NR from 52.6 GHz to 71 GHz Moderator (Intel Corporation)
R1-2004751 Skeleton TR 38.808-001: Study on supporting NR from 52.6 GHz to 71 GHz Intel Corporation
Further to initial conference call:
[101-e-NR-52_71_GHz] – Daewon (Intel)
Email discussion/approval on NR from 52.6 GHz to 71 GHz prioritizing evaluation assumptions until 6/4
R1-2004754 Summary of email discussions for [101-e-NR-52_71_GHz] Moderator (Intel Corporation)
R1-2005003 Summary#2 of email discussions for [101-e-NR-52_71_GHz] Moderator (Intel Corporation)
Update on 6/7: post e-meeting additional email discussion/approval
[101-e-Post-NR-52_71_GHz] – Daewon (Intel)
Email discussion/approval prioritizing remaining evaluation assumptions till 6/17
R1-2003293 Link level evaluation methodology and considerations for PHY design in 52.6-71 GHz using NR waveform Huawei, HiSilicon
· Proposal 1: if link-level evaluations are needed for the study of SCS for NR-U-60, the evaluation parameters in Appendix A are taken as starting point for discussion on evaluation assumptions.
· Proposal 2: for the selection of SCS for above 52.6 GHz for licensed operation, while striving for a similar design for licensed and unlicensed operation, the following criteria should be considered if SCSs larger than 120 kHz are proposed:
o Impact of coverage (physical channel transmission duration, CP length)
o Impact on BLER (robustness to phase noise)
o Impact on UE processing timelines
o Impact on PDCCH monitoring capability
· Proposal 3: For initial access procedure above 52.6GHz, legacy SCS configurations for FR2 can be reused. Whether new SCSs are needed should be further studied.
· Proposal 4: NR-U-60 could consider numerology to support larger single carrier bandwidth for operation with unlicensed band compared with those in NR FR2.
· Proposal 5: Changes for operation in unlicensed band depend on the channel access mechanisms, i.e. whether LBT is necessary.
· Proposal 6: According to the requirements of unlicensed band regulations, the following changes on the physical layer signals and channels should be further studied:
o Candidate SSB positions and RMSI CORESET/PDSCH multiplexing
o New ZC lengths and RO/PO multiplexing in 2 step RACH
o PRB based interlace resource mapping for PUSCH/PUCCH/SRS
Decision: The document is noted.
R1-2003811 Required changes to NR using existing DL/UL NR waveform Nokia, Nokia Shanghai Bell
Proposal 1: Extend the numerology scaling framework defined in NR Rel-15 to higher numerologies with an appropriate range of integer values for μ.
Proposal 2: Maintain the maximum number of RBs supported by NR specification also for NR scenario above 52.6 GHz, and support new numerologies (in red) in Table 1 for data and control channels.
Proposal 3: Support operation with CBW=2.16 GHz
Proposal 4: Support both channel bonding and CA between 2.16 GHz channels
Proposal 5: Support at least 960 kHz and 1920 kHz SCS (3840 kHz SCS is FFS).
Proposal 6: Consider n x 400 MHz, n=[1, 2, 3] as supported channel BW options for operation within a 2.16 GHz channel
· Support for BW <400 MHz is FFS
· Support also CA within 2.16 GHz channels.
Proposal 7: Consider sub-channelization for 2.16 GHz channels to enable narrowband operation.
Proposal 8: Study the need for ECP length at least for the highest SCSs
Proposal 9: Study the impacts of beam switching gap on NR physical layer design extended to higher SCSs
Proposal 10: Support at least 960kHz and 1920kHz SCS for OFDM to enable use of high-order modulations with current PTRS designs.
Proposal 11: Consider block-PTRS for OFDM.
Proposal 12: Support also SCS of 120kHz for OFDM for better system coverage compared to higher SCS
Proposal 13: Consider supporting 960kHz SCS for SC-FDMA to robustly enable all MCSs.
Proposal 14: Consider defining new PTRS configurations for SC-FDMA.
Proposal 15: Support also current numerologies for SC-FDMA including 120kHz SCS.
Proposal 16: Consider supporting rank-2 SU-MIMO for DFT-s-OFDM.
Proposal 17: Regarding SSB numerologies: 1) Support existing SSB numerologies and 2) study further need for new numerologies for SSB and Type0-PDCCH design.
Proposal 18: Consider coverage enhancements for channels and signals with higher SCS.
Proposal 19: Consider increase of the minimum scheduling/ PDCCH monitoring unit to avoid excessive increase in PDCCH monitoring rate
· Study different options to increase the scheduling/monitoring unit length.
Proposal 20: Determine BD/CCE limits based on nominal scheduling/monitoring unit such as slot of e.g. 120kHz (defined in R15)/240kHz (FFS).
Proposal 21: Consider support for contiguous multi-PRB allocation for PUCCH format 0 and format 1 or use of PUCCH format 2 and format 3 for SR and before dedicated PUCCH configuration.
Decision: The document is noted.
R1-2004247 On Required changes to NR using existing DL/UL NR Waveform Apple
Observation 1: NR above 52.6 GHz should support larger bandwidths and SCSs, a careful selection of the CP lengths, a modification of the PTRS signal design, and enhanced beam management procedures.
Observation 2: SCS value no larger than 960 kHz should be considered for NR > 52.6 GHz.
Observation 3: A maximum SCS of 480 kHz has been used for multiple elements of the Rel-15/Rel-16 specification. The use of SCS > 480 kHz should be justified to reduce the specification impact.
Observation 4: There is a need for carrier aggregation to achieve the high bandwidth allocations in the unlicensed band between 52.6GHz and 71 GHz.
Proposal 1: Select the maximum BW numerology based on ratios similar to or less than the values selected in Rel-15/Rel16.
Observation 5: The total PN increases when compared to below 52.6 GHz operation.
Observation 6: The bandwidth and the SCS should not be selected independently.
Proposal 2: To counter the increase in PN, NR should consider increasing the data transmission SCS for operation between 52.6 GHz and 71 GHz to at or above 480 kHz.
Proposal 3: RAN1 to study the need to update Rel-15 PTRS for both OFDM and DFT-S-OFDM to account increased CPE/ICI at higher frequencies.
Observation 7: As the SCS increases, there is a trade-off between the CP required for the delay spread after beamforming (reducing the cyclic prefix and increasing the irreducible noise floor), the phase noise (reducing the PN inter-carrier interference) and the bandwidth of operation.
Proposal 4: RAN1 to study the performance based on selecting 120 kHz, 240 kHz and 480 kHz as SCS candidates for NR operation between 52.6 GHz and 71 GHz. RAN1 to study performance and specification impact of selecting 960 kHz as an SCS candidate.
Proposal 5: Down-select SCS based on the phase noise reduction requirements of transmission at < 71 GHz, the bandwidth requirements and the cyclic prefix required to mitigate the effect of the beam formed delay spread.
Decision: The document is noted.
R1-2004500 NR using existing DL-UL NR waveform to support operation between 52p6 GHz and 71 GHz Qualcomm Incorporated
Observation 1: For low MCSs (e.g., MCS 7) with QPSK modulation, no or little performance degradation is observed for SCSs 60kHz and 120kHz in the high frequency regime, even if PTRS-based phase noise correction is not applied.
Observation 2: For mid-range MCSs with 16QAM modulation, SCS 120kHz sustains the performance while SCS 60kHz starts showing an error floor.
Observation 3: SCS 60kHz in the high frequency regime suffers from severe performance degradation at very high MCSs (e.g., MCS 28), even with PTRS-based phase noise correction.
Observation 4: SCS 120kHz in the high frequency regime starts showing an error floor at very high MCSs (e.g., MCS 28), even with PTRS-based phase noise correction. However, the error floor is sustained below 1%.
Observation 5: SCS 960kHz in the high frequency regime retain high performance throughout all MCSs, if the PTRS-based phase noise correction is used.
Observation 6: SCS 960kHz with NCP (73ns) shows reasonable performance to the channel delay spread up to 200ns.
Proposal 1: For physical control, data, and random access channels and for SSB in the high frequency regime from 52.6GHz to 71GHz, SCSs of 120kHz and 960kHz should be considered.
Proposal 2: Existing FR2 phase noise models, possibly with some modifications, are reused for the study on the high frequency regime. RAN1 may send a LS to RAN4 asking for further confirmation.
Proposal 3: If needed, the impact of power amplifier nonlinearity may also be investigated during the study on the high frequency regime.
Proposal 4: When a new numerology (e.g., 960kHz) is introduced for the high frequency regime, the impact of the extremely short slot duration to the existing physical signals and channels should be investigated.
Decision: The document is noted.
R1-2003286 Channelization in unlicensed spectrum above 52.6GHz and below 71GHz Futurewei
R1-2003304 Discussion on potential physical layer impacts for NR beyond 52.6 GHz Lenovo, Motorola Mobility
R1-2003424 Discussion on requried changes to NR using existing DL/UL NR waveform vivo
R1-2003461 Discussion on the required changes to NR for above 52.6GHz ZTE, Sanechips
R1-2003636 System Analysis and evaluation methodology of NR opration up to 71 GHz CATT
R1-2003679 On Required changes to NR using existing DL/UL NR waveform for supporting NR from 52.6GHz to 71 GHz MediaTek Inc.
R1-2003764 Discussion on Required Changes to NR in 52.6 – 71 GHz Intel Corporation
R1-2003777 Waveform Enhancements for 60GHz operation Charter Communications, Inc
R1-2003849 On NR operations in 52.6 to 71 GHz Ericsson
R1-2003903 Design aspects for extending NR to up to 71 GHz Samsung
R1-2003945 Discussions on Changes to NR Using Existing DL/UL NR Waveform Quectel
R1-2003961 Discussion on required changes to NR for above 52.6GHz CMCC
R1-2004004 Discussion on required changes to NR using existing NR waveform Spreadtrum Communications
R1-2004038 Consideration on required physical layer changes to support NR above 52.6 GHz LG Electronics
R1-2004096 Discussion on the waveform for DL/UL at above 52.6 GHz OPPO
R1-2004188 Considerations on bandwidth and subcarrier spacing for above 52.6 GHz Sony
R1-2004299 Consideration on supporting above 52.6GHz in NR InterDigital, Inc.
R1-2004301 Consideration on required changes to NR using existing NR waveform Fujitsu
R1-2004312 Study on the required changes to NR using existing DL/UL NR waveform NEC
R1-2004333 Initial views of required changes of NR DL/UL waveform Sharp
R1-2004340 Discussion on required changes to NR using existing DL/UL waveform ITRI
R1-2004417 Evaluation Methodology and Required Changes on NR on 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2004519 Discussions on required changes on supporting NR from 52.6GHz to 71 GHz CAICT
R1-2004593 On NR operation between 52.6 GHz and 71 GHz Convida Wireless
R1-2003425 Discussion on channel access mechanism vivo
Observation 1: Interference is observed and degrades UE performance for DL-only and UL-only traffic in two operators’ scenario.
Observation 2: No-LBT scheme works for single operator and some cases of two operators’ scenario with beam operation on 60 GHz.
Observation 3: The cell edge UEs observe strong interference and degrade the UPT, especially when traffic load increases.
Proposal 1: Adopt the indoor scenario system level evaluation assumptions for above 52.6 GHz as in Table 1.
Proposal 2: Adopt the outdoor scenario system level evaluation assumptions for above 52.6 GHz as in Table 2.
Proposal 3: Directional LBT should be studied in 60 GHz band.
Proposal 4: The receiver assisted channel access scheme can be considered in 60 GHz band and how to implement this handshaking mechanism in NR systems should be studied.
Decision: The document is noted.
R1-2003765 Channel Access Procedure for NR in 52.6 - 71 GHz Intel Corporation
Observation 1: CEPT ECC has recently opened the band 66-71 GHz band for unlicensed used. Furthermore, it relaxed the maximum mean EIRP to 23 dBm/MHz for the European/CEPT areas.
Observation 2: RAN1 should account for the OCB requirements mandated in the ITU Region 1 by ETSI EN 302 567 when a system operates in band 56 GHz to 71 GHz.
Observation 3: RAN1 should assume mandatory LBT procedure when operating in Region 1 in band 56 GHz to 71 GHz.
Observation 4: ETSI EN 302 567 CCA rules are aligned with IEEE 802.11ad channel access operations, especially with regards to channel access random backoff time unit, aSlotTime equal to 5 μs, and minimum channel IDLE period for channel access, PIFS time equal to 8 μs.
Observation 5: ETSI EN 302 567 CCA level is 1 dB looser (i.e. -47 dBm) than what IEEE 802.11ad specification requires for energy detection (i.e. -48 dBm). However, ETSI EN 302 567 rules contain CCA detection threshold relaxation as a function of intended transmit power reduction from 40 dBm, whereas IEEE 802.11ad specification does not have such mechanism.
Observation 6: While the unlicensed design of NR above 52.6 GHz should be always complaint with the worldwide regulatory restrictions, these could be met only when mandated.
Proposal 1: The LBT procedure detailed in the ETSI EN 302 567 should be used as a baseline to develop the channel access procedure for at least when the system operates in the ITU Region 1 within band 56 GHz to 71 GHz.
Decision: The document is noted.
R1-2003850 Channel Access Mechanism Ericsson
Observation 1: New harmonized standards are being developed in ETSI BRAN for unlicensed spectrum access in the 57-71 GHz band following the updated frequency band and regulatory parameters decision by CEPT ECC.
Observation 2: To ensure a technically neutral and fair spectrum sharing mechanism among different access technologies, it is beneficial that 3GPP companies actively participate in the ETSI harmonized standard development for unlicensed spectrum in the 57-71 GHz band.
Observation 3: FCC does not enforce spectrum access and mitigation requirements for 57-71 GHz frequency band.
Observation 4: For the frequency range of 57-71 GHz, LBT is mandatory ONLY in the current ETSI BRAN harmonised standard ETSI EN 302 567 to facilitate spectrum sharing on the unlicensed c1 band (57-66 GHz).
Observation 5: In the initial draft of the ETSI EN 303 722 Harmonized Standard for c2 and c3 bands, ATPC is proposed as the medium access mechanism. LBT is not indicated in the draft.
Observation 6: ECC Report 288 concludes that in the 57-66 GHz band, system performance is reduced when LBT enabled, even with proper ED setting.
Observation 7: The effectiveness of LBT as medium access mechanism for co-existence in unlicensed spectrum in 60 GHz band is questionable.
Observation 8: There are many technical issues with directional LBT, while the benefit from directional LBT is not clear.
Proposal 1: Rel-17 should consider supporting two medium access mechanism modes for the 60GHz spectrum, one requiring LBT and one without LBT.
Decision: The document is noted.
R1-2003287 Considerations on channel access in the unlicensed spectrum above 52.6GHz and below 71GHz Futurewei
R1-2003294 Channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
R1-2003305 Discussion on channel access for NR beyond 52.6 GHz Lenovo, Motorola Mobility
R1-2003462 Discussion on the channel access mechanism for above 52.6GHz ZTE, Sanechips
R1-2003637 Channel Access Mechanism in support CATT
R1-2003680 On channel access mechanism from 52.6GHz to 71GHz MediaTek Inc.
R1-2003780 Channel access mechanisms for 60 GHz NR-U Charter Communications, Inc
R1-2003812 NR coexistence mechanisms for 60 GHz unlicensed band Nokia, Nokia Shanghai Bell
R1-2003904 Channel access mechanism for 60 GHz unlicensed spectrum Samsung
R1-2003921 Discussion on channel access mechanism for supporting NR from 52.6GHz to 71 GHz Beijing Xiaomi Mobile Software
R1-2003962 Discussion on channel access for above 52.6GHz CMCC
R1-2004005 Discussion on channel access mechanism for above 52.6GHz Spreadtrum Communications
R1-2004039 Considerations on channel access mechanism to support NR above 52.6 GHz LG Electronics
R1-2004097 Discussion on channel access mechanism for above 52.6GHz OPPO
R1-2004174 Channel access mechanism TCL Communication Ltd.
R1-2004189 Channel access mechanism for 60 GHz unlicensed spectrum Sony
R1-2004248 On Unlicensed Channel Access Mechanisms for > 52.6GHz Apple
R1-2004288 Channel access mechanisms for NR from 52.6-71GHz AT&T
R1-2004300 On Channel Access Mechanisms InterDigital, Inc.
R1-2004303 Discussions on channel access mechanism for NR from 52.6GHz to 71 GHz Quectel
R1-2004313 Study on the channel access mechanism NEC
R1-2004334 Channel access mechanism Sharp
R1-2004341 Discussion on channel access mechanism ITRI
R1-2004418 Channel Access Mechanism for NR in 60 GHz unlicensed spectrum NTT DOCOMO, INC.
R1-2004489 Channel access mechanism for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2004520 Discussions on channel access mechanism on supporting NR from 52.6GHz to 71 GHz CAICT
R1-2004558 Discussion on channel access for unlicensed spectrum from 52.6GHz to 71 GHz Potevio
R1-2004594 Considerations on channel access mechanism for NR supporting from 52.6 to 71 GHz Convida Wireless
R1-2003426 Evaluation on different numerologies for NR using existing DL/UL NR waveform vivo
R1-2003463 Discussion on the evaluation assumptions for above 52.6GHz ZTE, Sanechips
R1-2003766 Considerations on performance evaluation for NR in 52.6-71GHz Intel Corporation
R1-2003813 Performance of existing DL NR waveform beyond 52.6 GHz Nokia, Nokia Shanghai Bell
R1-2003851 Enhanced phase noise modeling Ericsson
R1-2003905 Evaluaton assumptions for SLS and LLS Samsung
R1-2004040 Consideration on multi-carrier operation for NR above 52.6 GHz LG Electronics
R1-2004098 Discussion on deployment scenarios for carrier frequency above 52.6GHz OPPO
R1-2004419 Potential Enhancements for NR on 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2004606 System level evaluation methodology and results for 60 GHz unlicensed operation Huawei, HiSilicon
Please refer to RP-200902 for detailed scope of the SI
R1-2007384 Session notes for 8.2 (Study on supporting NR from 52.6 GHz to 71 GHz) Ad-Hoc Chair (Ericsson)
R1-2005865 Draft TR 38.808 v001: Study on supporting NR from 52.6 GHz to 71 GHz Intel Corporation
R1-2007340 Draft TR 38.808 v002: Study on supporting NR from 52.6 GHz to 71 GHz Intel Corporation
Note: TR updates incorporate agreements made from this meeting on evaluations, aiming for review and potential endorsement in the beginning of the next meeting.
R1-2005239 Discussion on potential physical layer impacts for NR beyond 52.6 GHz Lenovo, Motorola Mobility
· Proposal 1: For supporting NR beyond 52.6 GHz with existing waveforms in Rel. 17, higher subcarrier spacing (numerologies) than 120 kHz should be adopted only if there is a significant performance gain in terms of phase noise reduction in comparison to existing subcarrier spacing (numerologies).
· Proposal 2: For supporting NR beyond 52.6 GHz with existing waveforms in Rel. 17, if higher subcarrier spacings (numerologies) are adopted, the existing limitation of maximum FFT size 4096 should still be followed.
· Proposal 3: For supporting NR operation between 52.6GHz and 71GHz in Rel. 17, at least higher subcarrier spacing values of 240kHz and 480kHz should be supported with normal cyclic prefix.
· Proposal 4: For supporting single carrier bandwidth of ~2GHz for NR operation between 52.6GHz and 71GHz in Rel. 17, subcarrier spacing of 960kHz with normal cyclic prefix can be supported and higher subcarrier spacing value should not be further considered in NR Rel. 17.
· Proposal 5: For supporting NR operation between 52.6GHz and 71GHz in Rel. 17, no PT-RS configuration should also be supported, depending up on the MCS range, if higher subcarrier spacing values are agreed to be supported.
· Proposal 6: For supporting NR beyond 52.6 GHz with existing waveforms in Rel. 17, if higher subcarrier spacings (numerologies) are adopted, new DM-RS configurations should be studied.
· Proposal 7: For supporting NR beyond 52.6 GHz with existing waveforms in Rel. 17, if higher subcarrier spacings (numerologies) are adopted, then potential enhancements should be considered on how to efficiently utilize UE’s limited processing capability to reduce latency and efficiently handle processing/preparation of CSI reports associated with multiple numerologies parallelly.
· Proposal 8: For supporting NR beyond 52.6 GHz with existing waveforms in Rel. 17, if higher subcarrier spacings (numerologies) are adopted, then enhancements to current PDCCH design including the possibility:
o To introduce new DCI formats should be considered for reduced PDCCH monitoring and efficient scheduling for both UL and DL
o To limit the monitoring to specific DCI formats
· Proposal 9: For supporting NR beyond 52.6 GHz in unlicensed band in Rel. 17, study the enhancement of PRB/sub-PRB interlacing designs for NR with higher SCS, if agreed to be supported.
Decision: The document is noted.
R1-2005371 Discussion on requried changes to NR using existing DL/UL NR waveform vivo
· Proposal 1: For BWP numerology, (960K, NCP) is preferred for scenarios targeting high peak data rate and (120K, NCP) is preferred with no spec impact for scenarios targeting large coverage.
· Proposal 2: SSB numerology would better to be determined after BWP numerology is selected and supported (SSB, corset 0) numerology pairs need to be determined as well by considering koffset indication and SSB-Coreset 0 multiplexing pattern.
· Proposal 3: Format 0-3 with special SCS is not supported and candidate PRACH numerologies for format A, B and C would better to be the same as candidate BWP numerologies.
· Proposal 4: Perform modeling of I/Q imbalance in link level evaluation with reasonable sideband suppression value, and study potential enhancement if problem is identified.
· Proposal 5: Perform PAPR evaluation for different channels/signals, and study potential PAPR reduction technique if problem is identified.
· Proposal 6: The following aspects should be studied for SSB design:
o Frequency domain offset estimation;
o Amount of buffering SSB samples;
o Beam switching for contiguous candidate SSBs.
· Proposal 7: Both coverage and capacity should be studied for PRACH design with new defined numerology.
· Proposal 8: Coverage enhancement mechanism should be studied for PDCCH design especially for high SCS.
· Proposal 9: DM-RS/PT-RS enhancement should be studied to solve the problem brought by RF impairment such as phase noise, I-Q imbalance and PA non-linear work range.
· Proposal 10: Timeline definition, basic time unit and super long CP per half frame should be discussed for new defined numerology such as (960K, NCP).
Decision: The document is noted.
R1-2006986 Discussion on Required Changes to NR in 52.6 – 71 GHz Intel Corporation (Rev. of R1-2005866)
· Proposal 1
o Follow NR principle to determine frame structure for carrier frequency between 52.6GHz and 71GHz.
o RAN1 consults RAN4 regarding support of channel bandwidths for carrier frequencies between 52.6GHz and 71GHz sufficiently larger than currently supported in NR Rel-15 for FR2.
· Proposal 2: RAN1 to send the LS to RAN4 on updating the MIMO TAE minimum requirements.
· Proposal 3: Consider to support larger SCS than currently defined in NR Rel-15 for FR2, i.e., 480 kHz and 960 kHz for NR operating in 52.6 – 71GHz.
· Proposal 4: Extended CP may not be needed for NR in 52.6–71GHz if MIMO TAE requirement less than 65ns is defined.
· Proposal 5: When a large subcarrier spacing is defined, SSB pattern and multiplexing of SSB and CORESET0/RMSI need to be updated to accommodate beam switching time.
· Proposal 6: When a large subcarrier spacing is defined, PRACH configuration related aspects need to be investigated.
· Proposal 7: When a large subcarrier spacing is defined, processing time related aspects, including PDSCH/PUSCH processing time, CSI computation time, etc., need to be investigated.
· Proposal 8: When a large subcarrier spacing is defined, maximum number of BDs/CCEs for PDCCH monitoring needs to be investigated.
· Proposal 9: When a large subcarrier spacing is defined, multi-TTI based scheduling can be considered to relax scheduler implementation and higher layer processing burden.
Decision: The document is noted.
R1-2005920 On NR operations in 52.6 to 71 GHz Ericsson
· Proposal 1: Consider channel bandwidths up to 1.6 GHz for NR operation in 52.6 to 71 GHz.
· Proposal 2: Consider sub-carrier spacings up to 480 kHz for NR operation in 52.6 to 71 GHz.
· Proposal 3: Extended CP need not be considered for NR operation in 52.6 to 71 GHz.
· Proposal 16: For 60GHz operation, reduce the FDRA fields size by supporting larger RBG sizes.
Decision: The document is noted. Further revised with new simulation results in R1-2007046.
R1-2006725 Evaluation Methodology and Required Changes on NR from 52.6 to 71 GHz NTT DOCOMO, INC.
· Proposal 1: For numerology, at least one higher SCS than 120 kHz should be introduced for 52.6 – 71 GHz NR.
o The number of SCSs to be newly supported for 52.6 – 71 GHz should be minimized
o For 960 kHz SCS if supported for 52.6 – 71 GHz, extended CP should be considered
· Proposal 2: For bandwidth, at least wider maximum channel bandwidth than 400 MHz should be defined for 52.6- 71 GHz.
o 2 GHz or slightly smaller but sufficiently wide bandwidth such as 1 GHz should be considered.
§ FFT size should remain the same or smaller than 4k
o Wider minimum channel bandwidth for 52.6 – 71 GHz than 50 MHz should be considered.
· Proposal 3: Whether to introduce gap symbol(s) for beam switching time should be discussed not only for SSB but also for any signal/channels with beam switching in case that higher SCS such as 960 kHz is supported.
· Proposal 4: For PRACH sequence, short PRACH sequence supported in Rel-15 NR should be a baseline.
· Proposal 5: How to allocate resource for RS (e.g. DMRS, PTRS) in frequency domain needs to be considered for higher SCS if introduced
o DMRS density in frequency domain may not be sufficient
o DMRS ports multiplexing may not work well
· Proposal 6: How to allocate resource for data in frequency domain needs to be considered especially for higher SCS if introduced.
o PDSCH/PUSCH allocated on more than 14 symbols would be beneficial.
o In unlicensed band, interlaced PUCCH/PUSCH would be necessary.
· Proposal 7: BFR procedure enhancement needs to be considered with at least following points
o
The number of candidate beams included in set
o The minimum time gap to apply new beam configuration after receiving BFR response from gNB
o Simultaneous update of beam configuration for multiple SCells
o Monitoring aperiodic transmissions for beam failure detection
· Proposal 8: For higher SCS, the appropriate configuration of k0, k1, k2 need to be discussed to meet UE minimum processing timeline.
o If the current candidate values don’t meet UE processing limitation, extending, limiting or shifting the range of k0, k1, k2 may be necessary.
Decision: The document is noted.
R1-2005241 PHY design in 52.6-71 GHz using NR waveform Huawei, HiSilicon
R1-2005280 Considerations on phase noise for numerology selection FUTUREWEI
R1-2005543 Consideration on required changes to NR using existing NR waveform Fujitsu
R1-2005567 Considerations on bandwidth and subcarrier spacing for above 52.6 GHz Sony
R1-2005607 Discussion on the required changes to NR for above 52.6GHz ZTE, Sanechips
R1-2006989 On required changes to NR using existing DL/UL NR waveform for operation in 60GHz band MediaTek Inc. (Revision of R1-2005643)
R1-2005699 System Analysis of NR opration in 52.6 to 71 GHz CATT
R1-2005734 Physical layer design for NR 52.6-71GHz Beijing Xiaomi Software Tech
R1-2005764 Study on the required changes to NR using existing DL/UL NR waveform NEC
R1-2005766 Required changes to NR using existing DL/UL NR waveform TCL Communication Ltd.
R1-2005787 On phase noise compensation for NR from 52.6GHz to 71GHz Mitsubishi Electric RCE
R1-2006026 discusson on DL/UL NR waveform for 52.6GHz to 71GHz OPPO
R1-2006136 Design aspects for extending NR to up to 71 GHz Samsung
R1-2006237 Required changes to NR using existing DL/UL NR waveform in 52.6GHz ~ 71GHz CMCC
R1-2006274 Discussion on required changes to NR using existing NR waveform Spreadtrum Communications
R1-2006304 Consideration on required physical layer changes to support NR above 52.6 GHz LG Electronics
R1-2006452 Consideration on supporting above 52.6GHz in NR InterDigital, Inc.
R1-2006512 On Required changes to NR above 52.6 GHz using the existing DL/UL NR Waveform Apple
R1-2006628 On NR operation between 52.6 GHz and 71 GHz Convida Wireless
R1-2006649 60 GHz DL and UL waveform evaluations Charter Communications
R1-2006797 NR using existing DL-UL NR waveform to support operation between 52p6 GHz and 71 GHz Qualcomm Incorporated
R1-2006853 Discussions on required changes on supporting NR from 52.6GHz to 71 GHz CAICT
R1-2006885 Discussion on physical layer aspects for NR beyond 52.6GHz WILUS Inc.
R1-2006907 Required changes to NR using existing DL/UL NR waveform Nokia, Nokia Shanghai Bell
R1-2006982 Issue Summary for physical layer changes for supporting NR from 52.6 GHz to 71 GHz Moderator (Intel Corporation)
[102-e-NR-52-71-Waveform-Changes] – Daewon (Intel)
Email discussion/approval on required changes to NR using existing DL/UL NR waveform until 8/21; address any remaining aspects by 8/27
R1-2007038 Discussion summary of [102-e-NR-52-71-Waveform-Changes] Moderator (Intel Corporation)
R1-2007109 Discussion summary#2 of [102-e-NR-52-71-Waveform-Changes] Moderator (Intel Corporation)
R1-2007246 Discussion summary#3 of [102-e-NR-52-71-Waveform-Changes] Moderator (Intel Corporation)
R1-2007289 Discussion summary#4 of [102-e-NR-52-71-Waveform-Changes] Moderator (Intel Corporation)
R1-2007364 Discussion summary #5 of [102-e-NR-52-71-Waveform-Changes] Moderator (Intel Corporation)
R1-2007397 Discussion summary #6 of [102-e-NR-52-71-Waveform-Changes] Moderator (Intel Corporation)
For NR system operating in 52.6 GHz to 71 GHz,
· NR should be designed with maximum FFT size of 4096 and maximum of 275RBs per carrier;
· Candidate supported maximum carrier bandwidth(s) for a cell is between 400 MHz and 2160 MHz;
· If subcarrier spacing 240 kHz or below are supported, NR in 52.6 to 71 GHz is expected to use normal CP length only (does not have any implications on whether ECP is supported for the higher subcarrier spacings, if supported).
Conclusion:
RAN1 continues study and specification effort for both licensed and unlicensed operation for supporting NR from 52.6 GHz to 71 GHz SI.
· RAN1 strives for maximum commonality for the system design for licensed and unlicensed operation for NR from 52.6GHz to 71GHz, and for maximum re-use of the existing NR design
Agreement:
· Instruct rapporteur to create dedicated (sub-)section for set of identified issues for physical layer NR design.
· Endorse following text proposal as introduction to the (sub-)sections for discussing identified issues for physical layer.
o For supporting NR operation in both licensed and unlicensed band in the frequency range from 52.6 GHz to 71 GHz, FR2 numerologies and additional numerologies beyond that supported currently in NR are studied. Existing framework for numerology scaling is considered i.e. 2μ ×15 subcarrier spacing to select the candidates. For SSB transmissions, it is investigated whether or not µ>4 (larger than 240 kHz) is needed and corresponding impacts, if any, on the aspects including at least SSB pattern, multiplexing of other signal/channels, and transmission window, if supported. For data and control channel transmissions, it is investigated if µ>3 (larger than 120 kHz) is needed and corresponding impacts, if any, on aspects including at least processing timelines, PDCCH monitoring capability (BD/CCE), scheduling enhancements, beam-management, and reference signal design. For investigating the need for higher numerologies, some of the key aspects that are studied are the impact due to phase noise, delay spread, TAE, analog beam switching delay, and impact to coverage, spectral efficiency and peak data rates, and relative delay in intra-cell/inter-cell multi-TRP operations.
Agreement:
· Study whether or not different SSB patterns should be supported for licensed and unlicensed bands.
· For each licensed and unlicensed band, if issues are identified for reuse of existing SSB, consider at least the following aspects for SSB
o Beam switching gap between SSB(s) and between SSB and other signal(s)/channel(s)
o SSB pattern in time domain
o Whether or not it is needed to define a transmission window (such as DRS window), and if needed, number of SSB transmission opportunities within a transmission window
· For each licensed and unlicensed band, if issues are identified for reuse of all or some of the existing SSB and CORESET#0 multiplexing pattern, consider at least the following aspects for SSB, CORESET#0, and other signal/channel design
o Supported multiplexing pattern type(s) (Pattern 1, 2, and/or 3) for SSB and CORESET#0 multiplexing.
o Multiplexing of other signal/channels (e.g. RMSI, paging, CSI-RS) with SSB
o Configuration of Type0-PDCCH search space set
Agreement:
RAN1 at least considers the following aspects for determination of supported SSB subcarrier spacing
· Detection performance of SSB (including PSS, SSS, PBCH DMRS, and PBCH) and SSB coverage requirement
· Impact on initial cell search complexity due to frequency errors (e.g. carrier frequency offset, Doppler shift, etc)
· Timing detection accuracy and its relation to uplink transmission accuracy
· Signaling design for supporting different subcarrier spacing for SSB and CORESET#0 (if supported)
· Multi-TRP delay considerations
· Consideration of SSB-based RRM/RLM and beam management if the SSB SCS is significantly different from that of the active BWP (e.g., switching gap, scheduling constraint, etc.)
Agreement:
Consider the at least following aspects for PRACH design of NR operating in 52.6 GHz to 71 GHz
· PRACH coverage requirements
· applicable PRACH Sequence length(s) and subcarrier spacing(s) for PRACH, including any impact on PRACH coverage and capacity from the applicable sequence length(s).
· RACH RO configurations with new SCS (if new SCS is supported)
· LBT gap between RACH occasions (RO)
Agreement:
Consider at least the following aspects of PT-RS design for a given SCS
· Phase noise compensation performance of existing PT-RS design
· Study of need of any modification/changes to existing PT-RS design
o Potential modification to the PT-RS pattern or configuration to aid performance improvement for CP-OFDM and DFT-s-OFDM waveforms (if needed)
o Potential methods to aid ICI compensation at the receiver (if needed)
Agreement:
Consider at least the following aspects of DM-RS design for a given SCS
· Channel estimation performance of existing DM-RS design with existing and new SCSs (if any)
· Study whether there is a need of any modification/changes to existing DM-RS design
o Potential modification or introduction of new DM-RS pattern, configuration or indication to aid performance improvement for CP-OFDM and DFT-S OFDM waveforms (if needed)
Agreement:
Consider at least the following aspects of processing timelines for new SCS (if agreed) that are not currently supported,
· appropriate configuration(s) of k0, k1, k2,
· PDSCH processing time (N1),
· PUSCH preparation time (N2),
· HARQ-ACK multiplexing timeline (N3)
· CSI processing time, Z1, Z2, and Z3, and CSI processing units
· Any potential enhancements to CPU occupation calculation
· Related UE capability(ies) for processing timelines
· minimum guard period between two SRS resources of an SRS resource set for antenna switching
Agreement:
Consider at least the following aspects of PDCCH monitoring for a given SCS
· For new SCS, if agreed, that are not supported in Rel-15/16 NR,
o investigate on the maximum number of BDs/CCEs for PDCCH monitoring per time unit
§ e.g. slot as Rel-15, or new scheduling/monitoring unit
o any potential limitation to PDCCH monitoring configurations (e.g. search spaces, DCI formats, overbooking/dropping, etc) to help with UE processing, if needed
§ e.g. increased minimum PDCCH monitoring unit
o potential enhancements for CORESET, if needed
o related UE capability(ies) for PDCCH processing
Agreement:
Consider at least the following aspects of scheduling for BWP with a given SCS
· Study of frequency domain scheduling enhancements/optimization for PDSCH/PUSCH, if needed
o e.g. potential impact to UL scheduling if frequency domain resource allocation with different granularity than FR1/2 (e.g. sub-PRB, or more than one PRB) is supported
· Study of time domain scheduling enhancements for PDSCH/PUSCH, if needed
o e.g. increasing the minimum time-domain scheduling unit to be larger than one symbol, supporting multi-PDSCH scheduled by one DCI, supporting one TB mapped to multiple slots (i.e., TTI bundling)
· Study potential enhancements or alternatives to the scheduling request mechanism to reduce scheduling latency due to beam sweeping, if needed
Agreement:
Consider at least the following aspects for uplink transmission
· Study of potential enhancements for PUSCH/PUCCH/PRACH transmissions to achieve higher transmit power (when transmit power spectral density limits apply), if needed
· Study whether uplink interlace needs to be supported for unlicensed operation in 60 GHz band.
o If supported, study uplink PRB and/or sub-PRB based interlace design for PUCCH, PUSCH, and/or SRS.
Agreement:
· Study single carrier and multi carrier operations for achieving wide bandwidth utilization, while at least considering aspects such as control signaling overhead, transceiver complexity, spectral efficiency, etc.
Agreement:
Consider at least the following aspects in system operations with beams
· Study of BFR mechanism enhancements, if supported
o e.g., the use of aperiodic CSI-RS for BFR, increased number of RSs for monitoring/candidates and efficient utilization of the increased number of RSs, enhanced reliability to cope with narrower beamwidth
· Study of UE capabilities on beam switch timing in beam management procedure
· Study of enhancements for beam management and corresponding RS(s) in DL and UL are needed further considering at least the following aspects, if supported:
o beam switching time, beam alignment delay (including initial access), LBT failure, and potential coverage loss (if large SCS is supported)
· Study of beam switching gap handling for signals/channels (e.g. CSI-RS, PDSCH, SRS, PUSCH) for higher subcarriers spacing, if supported
Agreement:
R1-2005242 Channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
· Proposal 1：For operation in the 60 GHz band, Omni-directional LBT, directional LBT and No LBT should be considered for different scenarios.
· Proposal 2：For operation in the 60 GHz band, NR-U should consider to reuse the channel access mechanisms for 5/6GHz and modify the channel access parameters in accordance with the ETSI BRAN Harmonized Standard if LBT is supported.
· Proposal 3：The procedures specified for CWS adjustment and multi-channel access in Rel-16 NR-U should be considered for operation in the 60 GHz band with necessary modifications if LBT is supported.
· Proposal 4：NR-U should support receiver-assisted LBT with directional LBT in 60GHz unlicensed band.
Decision: The document is noted.
R1-2005608 Discussion on the channel access mechanism for above 52.6GHz ZTE, Sanechips
· Proposal 1: The following regulation rules for above 52.6 GHz, including channel access, OCB, COT, EIRP and PSD should be supported and enhanced to achieve good spectrum sharing with other systems.
· Proposal 2: Release 17 NR-U should consider supporting different channel access modes for above 52.6 GHz, e.g., directional LBT and No LBT.
· Proposal 3: For multiple transmission(s) with different beams case, channel condition difference for different beams should be considered when designing the channel access schemes for COT sharing in NR unlicensed spectrum.
Decision: The document is noted.
R1-2006798 Channel access mechanism for NR in 52.6 to 71GHz band Qualcomm Incorporated
· Proposal 1: Conditions for deployment modes where No-LBT or No Sensing is viable could be based on EIRP/transmit power, duty cycle of channel occupancy and spatial characteristics of transmission, or a combination thereof.
· Proposal 2: Explore long-term sensing-based deployment modes further to allow a reuse friendly approach while still resolving catastrophic beam collisions. Provision for channel measurement gaps and/or long-term sensing gaps to facilitate the same.
· Proposal 3: LBT or Short-Term Sensing: Identify conditions for deployment modes where short term medium sensing before a transmission needs to be considered for every transmission.
· Proposal 4: Contention Exempt Transmissions: Investigate and identify conditions where some transmissions can be permitted in a contention exempt manner, i.e. a sensing medium is not a requirement before transmission, even within deployment modes which require some form of sensing.
· Proposal 5: Consider the use of antenna gain of sensing beam and transmission beam to determine the suitability of using a given sensing beam in conjunction with another transmission beam.
· Proposal 6: Study and design channel access procedures and sensing guidelines that consider the prevalence of Tx Sensing-Rx mismatch.
Decision: The document is noted.
R1-2006908 NR coexistence mechanisms for 60 GHz unlicensed band Nokia, Nokia Shanghai Bell
· Proposal 1: NR coexistence mechanism shall be decided based on on achievable performance/fairness trade-off and on the impact on the implementation and complexity.
· Proposal 2: Various deployment scenarions relevant for 60 GHz band usage should be considered when NR coexistence mechanism is decided.
· Proposal 3: LBT should not always be mandated.
· Proposal 4: Study DFS and ATPC as candidate coexistence mechanisms in addition to LBT e.g. for relaying or IAB backhaul deployments.
· Proposal 5: Introduce multiple coexistence modes, e.g., with and without LBT.
· Proposal 6: Study the use of the coexistence mode without LBT e.g. in scenarios where:
o UE transmissions are limited to gNB initiated shared COTs, allowing for UE implementation without LBT
o a cell is sufficiently spatially isolated, or
o gNB and/or UE transmissions are sufficiently directional
· Proposal 7: Channelization based on 2.16 GHz is assumed as a starting point in the coexistence mechanisms studies.
· Proposal 8: Transmissions with a (channel) bandwidth smaller than 2.16 GHz, such as 400 MHz, are also considered in the coexistence mechanisms studies.
· Proposal 9: LBT described in EN 302 567 draft V2.1.20 is used as baseline for LBT procedure design for 60 GHz unlicensed band.
· Proposal 10: Beamforming for gNB’s LBT is left for implementation as much as possible.
· Proposal 11: Study the need for LBT ensuring fairness between cells with different bandwidths while maintaining efficient spatial reuse between cells of same bandwidth.
Decision: The document is noted.
R1-2005240 Discussion on channel access for NR beyond 52.6 GHz Lenovo, Motorola Mobility
R1-2005282 Considerations on directional LBT and spatial reuse FUTUREWEI
R1-2005372 Discussion on channel access mechanism vivo
R1-2005568 Channel access mechanism for 60 GHz unlicensed spectrum Sony
R1-2005700 Channel Access Mechanism in support of NR operation in 52.6 to 71 GHz CATT
R1-2005735 Channel access mechanism for NR on 52.6-71 GHz Beijing Xiaomi Software Tech
R1-2005765 Study on the channel access mechanism NEC
R1-2005767 Channel access mechanism TCL Communication Ltd.
R1-2005867 Channel Access Procedure for NR in 52.6 - 71 GHz Intel Corporation
R1-2005921 Channel Access Mechanism Ericsson
R1-2005950 Channel access mechanisms for NR from 52.6-71GHz AT&T
R1-2006027 discussion on channel access mechanism OPPO
R1-2006137 Channel access mechanism for 60 GHz unlicensed spectrum Samsung
R1-2006275 Discussion on channel access mechanism for above 52.6GHz Spreadtrum Communications
R1-2006305 Considerations on channel access mechanism to support NR above 52.6 GHz LG Electronics
R1-2006453 On Channel access mechanisms InterDigital, Inc.
R1-2006513 On Channel Access Mechanisms for Unlicensed Access above 52.6 GHz Apple
R1-2006571 Channel access mechanism Sharp
R1-2006629 On Channel Access for NR Supporting From 52.6 GHz to 71 GHz Convida Wireless
R1-2006650 Channel access considerations for the indoor scenario Charter Communications
R1-2006655 Discussion on channel access mechanism ITRI
R1-2006726 Channel Access Mechanism for NR in 60 GHz unlicensed spectrum NTT DOCOMO, INC.
R1-2006854 Discussions on channel access mechanism on supporting NR from 52.6GHz to 71 GHz CAICT
R1-2006871 Discussion on channel access mechanism for NR from 52.6GHz to 71 GHz Potevio
R1-2006994 FL summary for channel access mechanism for 52.6GHz to 71GHz Moderator (Qualcomm)
[102-e-NR-52-71-Channel-Access] – Jing (Qualcomm)
Email discussion/approval on channel access mechanism until 8/20; address any remaining aspects by 8/25
R1-2007094 Email discussion summary on channel access of 52.6-71GHz band Moderator (Qualcomm)
R1-2007193 Email discussion summary on channel access of 52.6-71GHz band Moderator (Qualcomm)
The OCB requirement of draft version v2.1.20 of EN 302 567 implies that
· Device supports one or multiple declared nominal channel bandwidths.
· For each declared nominal channel bandwidth, RAN1 design should support at least one physical layer signal/channel transmission that occupies at least 70% of the nominal channel bandwidth.
· FFS: Mapping of nominal channel bandwidth to bandwidth definitions in NR.
Conclusion:
The RAN1 understanding of the CCA check procedure in draft v2.1.20 of EN 302 567 is as follows:
· When performing CCA before initiating transmission, during count down, when an observation slot fails ED, the counter freezes, and will continue count down 8us after the interference is detected to be gone
Agreement:
· For gNB/UE to initiate a channel occupancy, both channel access with LBT mechanism(s) and a channel access mechanism without LBT are supported
· FFS: LBT mechanisms such as Omni-directional LBT, directional LBT and receiver assisted LBT type of schemes when channel access with LBT is used.
· FFS: If operation restrictions for channel access without LBT are needed, e.g. compliance with regulations, and/or in presence of ATPC, DFS, long term sensing, or other interference mitigation mechanisms
· FFS: The mechanism and condition(s) to switch between channel access with LBT and channel access without LBT (if local regulation allows)
Agreement:
Use the LBT procedures in draft v2.1.20 of EN 302 567 as the baseline system evaluation with LBT
· Enhancements to ED threshold, contention window sizes etc. can be considered as part of the evaluations.
R1-2005373 Evaluation on different numerologies for NR using existing DL/UL NR waveform vivo
R1-2005609 Preliminary simulation results for above 52.6GHz ZTE, Sanechips
R1-2005868 Considerations on performance evaluation for NR in 52.6-71GHz Intel Corporation
R1-2005922 On phase noise compensation for OFDM Ericsson
R1-2006028 discussion on other aspects OPPO
R1-2006138 Remaining details on evaluation assumptions Samsung
R1-2006454 Evaluation results for above 52.6GHz in NR InterDigital, Inc.
R1-2006727 Potential Enhancements for NR on 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2006909 Simulation Results for NR from 52.6 GHz to 71 GHz Nokia, Nokia Shanghai Bell
R1-2006928 Link level and System level evaluation for NR system operating in 52.6GHz to 71GHz Huawei, HiSilicon
R1-2007009 Summary of evaluation related issues on supporting NR from 52.6 GHz to 71 GHz Moderator (vivo)
[102-e-NR-52-71-Evaluations] – Huaming (Vivo)
Email discussion/approval on link and system level evaluation assumptions, scenarios and results until 8/20; address any remaining aspects by 8/26
R1-2007078 Discussion summary of [102-e-NR-52-71-Evaluations] Moderator (vivo)
R1-2007126 Discussion summary#2 of [102-e-NR-52-71-Evaluations] Moderator (vivo)
Agreement:
Keep modification CDL-B/D model in Table 2 as optional and add 20 ns DS to the baseline TDL-A channel model in addition to 5 ns and 10 ns.
· FFS in this meeting whether to add 40 ns DS to the baseline TDL-A channel model
Agreement:
Agreement:
Agreement:
Indoor scenario area reduction for indoor-A and indoor-C in Table 5 is not discussed further
Agreement:
Agreement:
For SLS performance evaluations purpose, -71 dBm + 10 log10 (BW/2GHz) is the baseline RSRP threshold for cell selection (UE with RSRP below this threshold are not considered in simulation and not counted toward UE distribution count) in the Cell selection criteria field of Table 6.
Agreement:
Agreement:
8 Mbytes is an optional FTP traffic model packet size for SLS.
Agreement:
Companies are encouraged to submit RSRP distribution (e.g. serving BS to UE links, BS-to-BS links, UE-to-UE links) for the evaluated scenario in SLS.
Agreement:
Add (Mg,Ng,M,N,P) = (1,1,8,16,2) per pol with (0.5 dv, 0.5 dH) as an optional antenna setting for gNB for indoor environment.
Conclusion:
Contributions based on optional model/scenario/parameter are not precluded from being considered for discussion and decisions on design to support NR from 52.6 GHz to 71 GHz.
Agreement:
· Proposal #9a in Section 4 of R1-2007126 is agreed.
Agreement:
· Proposal #10 in Section 4 of R1-2007126 is agreed.
Agreement:
Agreement:
For SLS evaluation purpose, the following is assumed as the channel model for UE-to-UE links.
· InH open office: InH – office channel model with LOS probability for indoor - mixed office from TR38.901
Agreement:
For SLS evaluation purpose, the following is assumed as the channel model for gNB-to-UE and gNB-gNB links.
· InH open office: InH – office channel model with LOS probability for indoor - open office from TR38.901
o Indoor – mixed office from TR38.901 can be optionally used for the LOS probability
Agreement:
For SLS evaluation purpose, the following is assumed as an optional model for UE-to-UE links in Dense Urban scenario.
· UMi street canyon channel & PL model from TR38.901
Working assumption:
For SLS evaluation purpose, for the D2D channel model for UE-to-UE links in Dense Urban scenario, the outdoor to outdoor model should be used.
· Companies should report how they scaled the model to 60 GHz.
R1-2007292 Discussion summary#3 of [102-e-NR-52-71-Evaluations] Moderator (vivo)
R1-2007342 Discussion summary#4 of [102-e-NR-52-71-Evaluations] Moderator (vivo)
Please refer to RP-201838 for detailed scope of the SI
R1-2009833 Session notes for 8.2 (Study on supporting NR from 52.6 GHz to 71 GHz) Ad-Hoc Chair (Ericsson)
R1-2007958 Draft TR 38.808 v002: Study on supporting NR from 52.6 GHz to 71 GHz Intel Corporation
Agreement:
R1-2007958 is endorsed with the “smallest of Z_min” modifed to “smallest value of Z_max” and setting Z_min equal to 0 in Section A.3. Modifications to fix errors will be made as part of upcoming updates.
R1-2009713 TR 38.808 v010: Study on supporting NR from 52.6 GHz to 71 GHz Intel Corporation
Decision: As per email decision posted on Nov.18th, TR 38.808 v010 capturing all RAN1 parts of the TR is endorsed. An updated version should follow to capture a couple of RAN4 endorsed TPs (R4-2016927, R4-2016995).
R1-2009849 TR 38.808 v020: Study on supporting NR from 52.6 GHz to 71 GHz Intel Corporation
Decision: As per email decision posted on Nov.20th, TR 38.808 v020 is endorsed.
R1-2007549 "Further discussion on B52 numerology" FUTUREWEI
R1-2007558 Discussion on physical layer impacts for NR beyond 52.6 GHz Lenovo, Motorola Mobility
R1-2007604 PHY design in 52.6-71 GHz using NR waveform Huawei, HiSilicon
R1-2007642 Physical layer design for NR 52.6-71GHz Beijing Xiaomi Software Tech
R1-2007652 Discussion on requried changes to NR using existing DL/UL NR waveform vivo
R1-2007785 Consideration on required changes to NR using existing NR waveform Fujitsu
R1-2007790 Consideration on supporting above 52.6GHz in NR InterDigital, Inc.
R1-2007847 System Analysis of NR opration in 52.6 to 71 GHz CATT
R1-2007883 Required changes to NR using existing DL/UL NR waveform TCL Communication Ltd.
R1-2007926 Required changes to NR using existing DL/UL NR waveform Nokia, Nokia Shanghai Bell
R1-2007929 On phase noise compensation for NR from 52.6GHz to 71GHz Mitsubishi Electric RCE
R1-2009379 Discussion on Required Changes to NR in 52.6 – 71 GHz Intel Corporation (rev of R1-2008805, rev of R1-2007941)
R1-2007965 On the required changes to NR for above 52.6GHz ZTE, Sanechips
R1-2007982 On NR operations in 52.6 to 71 GHz Ericsson
R1-2009653 Consideration on required physical layer changes to support NR above 52.6 GHz LG Electronics (rev of R1-2008045)
R1-2008076 Discussion on required changes to NR using existing DL/UL NR waveform in 52.6GHz ~ 71GHz CMCC
R1-2008082 Study on the numerology to support 52.6 GHz to 71GHz NEC
R1-2008872 Design aspects for extending NR to up to 71 GHz Samsung (rev of R1-2008156)
R1-2008250 Discusson on required changes to NR using DL/UL NR waveform OPPO
R1-2008353 Considerations on required changes to NR from 52.6 GHz to 71 GHz Sony
R1-2008457 A Discussion on Physical Layer Design for NR above 52.6GHz Apple
R1-2008493 Discussions on required changes on supporting NR from 52.6GHz to 71 GHz CAICT
R1-2008501 On required changes to NR using existing DL/UL NR waveform for operation in 60GHz band MediaTek Inc.
R1-2008516 On NR operation between 52.6 GHz and 71 GHz Convida Wireless
R1-2009062 Evaluation Methodology and Required Changes on NR from 52.6 to 71 GHz NTT DOCOMO, INC. (rev of R1-2008547)
R1-2008615 NR using existing DL-UL NR waveform to support operation between 52p6 GHz and 71 GHz Qualcomm Incorporated
R1-2008726 Discussion on physical layer aspects for NR beyond 52.6GHz WILUS Inc.
R1-2008769 Waveform considerations for NR above 52.6 GHz Charter Communications
R1-2009313 Issue Summary for physical layer changes for supporting NR from 52.6 GHz to 71 GHz Moderator (Intel Corporation)
[103-e-NR-52-71-Waveform-Changes] – Daewon (Intel)
Email discussion/approval on required changes to NR using existing DL/UL NR waveform and any TR updates until 11/2; address any remaining aspects by 11/10
Additional checkpoints where agreements can be declared: 11/5 and 11/12 (11/12 for approval of final TR)
R1-2009352 [103-e-NR-52-71-Waveform-Changes] Discussions Summary #1 Moderator (Intel Corporation)
R1-2009403 [103-e-NR-52-71-Waveform-Changes] Discussions Summary #1 Moderator (Intel Corporation)
Decisions: From GTW sessions,
Agreement:
· Numerologies below 120 kHz or above 960 kHz are not supported for any signal or channel.
Agreement:
For operation in 52-71 GHz:
R1-2009540 [103-e-NR-52-71-Waveform-Changes] Discussions Summary #2 Moderator (Intel Corporation)
R1-2009667 [103-e-NR-52-71-Waveform-Changes] Discussions Summary #3 Moderator (Intel Corporation)
R1-2009688 [103-e-NR-52-71-Waveform-Changes] Discussions Summary #4 Moderator (Intel Corporation)
Decisions: From GTW sessions,
Agreement:
Capture the following observations in the TR. Editorial modifications and changes to references can be made when capturing the observations in the TR.
· It was observed that amount of specification effort increases with the number of new numerologies enabled and supported for 52.6 GHz to 71 GHz frequency.
· In order to minimize specification effort while maximizing supported use cases and deployment scenarios applicable for 52.6 GHz to 71 GHz frequency, It is recommended to support 120 kHz subcarrier spacing with normal CP length, and at least one more subcarrier spacing. It is recommended to consider supporting at most up to three subcarrier spacings, including 120 kHz subcarrier spacing. Applicability of the supported subcarrier spacing to particular signals and channels should be further discussed in the corresponding WI phase.
· It is recommended that numerologies 240 kHz, 480 kHz, and 960 kHz are considered as candidates for additional numerologies in addition to 120 kHz, and numerologies outside this range are not supported for any signals or channels.
· In order to bound implementation complexity, it is recommended to limit the maximum FFT size required to operate system in 52.6 GHz to 71 GHz frequency to 4096 and to limit the maximum of RBs per carrier to 275 RBs.
· Selection of the additional subcarrier spacing (on top of 120 kHz) should consider versatility of being able to support various applications and deployment scenarios with all the subcarrier spacings that would be supported by specification, accounting for what is already supported in Rel-15 and Rel-16 specifications.
· Some companies have noted that ability for a deployed system to operate with a single numerology for all channels and signals is beneficial, and some companies have further noted benefit remains even if SSB numerology is different. Some companies have noted mixed numerology operation is functional and is supported in Rel-15 and Rel-16 specifications (e.g. 240 kHz SSB subcarrier spacing with 120 kHz subcarrier spacing for PDCCH/PDSCH/PUSCH/PUCCH/PRACH in an initial BWP and activation of a dedicated BWP with SCS different than the initial BWP) and consideration of single numerology operation is not needed.
Agreement:
Capture the following observations in the TR. Editorial modifications and changes to references can be made when capturing the observations in the TR.
Overall implementation complexity for supporting a specific subcarrier spacing may need to consider the following, but not limited to:
· processing complexity for equalization including inter-carrier interference mitigation (if required to support higher modulation orders) and compensation, andFFT complexity per unit time for a given bandwidth,
· complexity associated with supporting multiple component carriers to reach a specific throughput
· complexity associated with supporting given reduced (in abosolute time) requirements on UE processing times (e.g. N1, N2, N3, Z1, Z2, Z3, etc) and UE PDCCH processing budget as a function of subcarrier spacing, if scheduling and monitoring unit is maintained to be one slot.
· supported features indicated by UE capability signaling or implemented by the gNB
· complexity associated with supporting required timing error tolerance which may need to considerinitial timing error, timing advance setting, TA granularity, MIMO TAE (TAE value will be defined by RAN4), multi-TRP timing alignment as a function of SCS, whether mixture or a single subcarrier spacing for signals is configured, and deployment scenarios.
· complexity associated with supporting higher sampling rates and with channel bandwidth larger than 2 GHz
Agreement:
· It is observed that for a single carrier with the same number of transmitted symbols, in general, smaller subcarrier spacing may potentially provide larger coverage due to use of smaller bandwidth and gears towards (but not limited to) coverage driven scenarios.
· It is observed that for a single carrier, in general, larger subcarrier spacing may potentially provide higher peak data rates due to use of larger bandwidth and gears towards (but not limited to) peak data-rate driven scenarios.
R1-2009717 [103-e-NR-52-71-Waveform-Changes] Discussions Summary #5 Moderator (Intel Corporation)
Decisions: From GTW sessions,
Agreement:
Capture the following observations in the TR. Editorial modifications and changes to references can be made when capturing the observations in the TR.
· Some companies noted that standardization effort to support 240 kHz, 480 kHz, and 960 kHz numerologies are comparable. Some companies noted that standardization effort for 240 kHz numerology could be relatively smaller compared to 480 kHz or 960 kHz numerologies.
· The following, which is not an exhaustive list, are some potential physical layer impact that are common to all numerologies:
o supporting unlicensed operation
o if mixed numerology is supported, supporting mixed numerology operation.
o SSB and CORESET#0 offsets needed for supported channelization
· The following, which is not an exhaustive list, are some potential physical layer impact areas for each numerology:
o 120 kHz:
§ Potential consideration of PTRS enhancement for CP-OFDM and DFT-s-OFDM, if needed
o 240 kHz:
§ Potential consideration of PTRS enhancement for CP-OFDM and DFT-s-OFDM, if needed
§ If common SSB/CORESET0 numerology (240/240) is supported, SSB patterns, and CORESET#0 configuration
§ RO configuration
§ Timelines for scheduling, processing and HARQ
§ Potential enhancement to DM-RS, if needed
§ PDCCH monitoring
o 480 kHz:
§ If 480 kHz SSB is supported, SSB patterns, and CORESET#0 configuration
§ Timelines for scheduling, processing and HARQ
§ RO configuration
§ Potential enhancement to DM-RS, if needed
§ PDCCH monitoring
§ Potential consideration of PTRS enhancement for CP-OFDM and DFT-s-OFDM, if neeeded
o 960 kHz:
§ Potential consideration of ECP, if needed, depending on deployment scenarios
§ If 960 kHz SSB is supported, SSB patterns, and CORESET#0 configuration
§ Timelines for scheduling, processing and HARQ
§ RO configuration
§ Potential enhancement to DM-RS, if needed
§ PDCCH monitoring
§ Potential updates to smallest time unit, Tc, used in specifications depending on supported maximum carrier BW
Agreement:
Capture the following observations in the TR. Editorial modifications and changes to references can be made when capturing the observations in the TR.
Observations on the delay spread distribution:
· One source (R1-2007654, vivo) observed that for the delay spread distributions for the typical indoor scenarios evaluated, the delay spread of almost 80% of the users are less than 30 nsec.
· One source (R1-2007982, Ericsson) observed that Factory Scenario A (InF-DH) results in post-beamforming delay spreads that are a significant fraction of the CP duration for 960 kHz SCS.
· One source (R1-2007943, Intel) observed that 85% of the UE experience r.m.s delay spread small than CP length of 1.92 MHz subcarrier spacing (i.e. 36.6ns) in indoor, outdoor, and factory scenarios.
· One source (R1-2008615, Qualcomm) observed that for small range indoor hotspot deployment, the channel delay spread is not an issue with normal CP. For outdoor scenarios with larger ISD and at moderate to high SNR (this may be produced by higher EIRP or smaller BW), normal CP demonstrates SINR degradation compared to extended CP. However, for such large coverage, high EIRP, and small BW use cases, we can choose to use a small SCS, e.g., 120kHz, with NCP.
· One source (R1-2007790, Interdigital) observed that while each scenario experiences different amounts of r.m.s. delay spread, regardless of scenarios, most of UEs experience smaller r.m.s. delay spreads than normal CP of 960 kHz.
· One source (R1-2009062, Docomo) observed that the mean r.m.s. delay spread of 60 GHz system in Outdoor-B scenario is about 23 nsec and the 95%-tile delay spread value is about 80 nsec. More than half of UE experiences channels with delay larger than 20 ns, which should be referred to in the link performance evaluation with large delay configurations.
Agreement:
Capture the following observations in the TR (Editorial modifications and changes to references can be made when capturing the observations in the TR):
· Some companies have noted support of channelization that are aligned with IEEE 802.11ad and 802.11ay channelization is beneficial for coexistence. While some companies have noted alignment of channelization for coexistence is not necessary. Alignment of channelization between a NR channel and IEEE 802.11ad and 802.11ay channel in this context refers to a NR channel that is contained within one of the channels defined for IEEE 802.11ad and 802.11ay and NR channel bandwidth does not cross over channel boundaries of IEEE 802.11ad and 802.11ay.
· One company has evaluated misaligned NR wideband channels with 1.6 GHz and 2 GHz without LBT and have not identified coexistence issues between NR and NR.
· Some companies proposed that 2 GHz channel bandwidth should be supported andhave the raster points for 2 GHz channel bandwidth to be aligned with IEEE 802.11ad and 802.11ay channelization.
· Some companies proposed that 1.6 GHz should be the maximum channel bandwidth and channels do not necessarily need to be aligned with IEEE 802.11ad and 802.11ay channelizations.
· Some companies observed that support of channel bandwidth such as 200 or 400 MHz may enable efficient usage of available spectrum by 3GPP technology. Some companies observed that only supporting channelization that are alignemed with IEEE 802.11ad and 802.11ay channelization result in smaller number of supported channels for some regions of the world.
· Some companies have observed that channelization based on granularity of minimum supported channel BW would be benefitial and could provide efficient usage of available specturm. Other companies have observerd that support of channel BW such as 1.6 GHz or 2.4GHz would enable efficient usage of 5 GHz allocation in China and 5 GHz IMT allocation in Europe. Some companies have observed that smaller bandwidth (e.g. 1.6 GHz) allows for more channels (e.g., with 1.6 GHz, 3 channels instead of two) in these regions, easing frequency planning between operators at the cost of reduction in available channel bandwidth per carrier.
· Some companies proposed to support more than one channel bandwidths for a given SCS.
Agreement:
Capture the following observations in the TR (Editorial modifications and changes to references can be made when capturing the observations in the TR):
· Some companies noted SSB SCS selection should consider SCS of data/control channels and enablement of single subcarrier spacing operation.
· Some companies noted support and use of 120 kHz and/or 240 kHz SCS for SSB and 120 kHz subcarrier spacing for CORESET#0 in initial BWP and activation of dedicated BWP with an SCS for data/control different than the initial BWP may enable re-use of existing NR specification and minimize standardization effort.
· It was identified to further investigate considerations of SSB patterns, if needed, considering:
o Unlicensed band operation if LBT is required for SSB, e.g. SSB cycling transmission within a DRS transmission window.
o Beam switching time between SSB,
o Coverage of SSB
o Multiplexing of SSB with CORESET and UL transmissions
Agreement:
Capture the following observations in the TR (Editorial modifications and changes to references can be made when capturing the observations in the TR):
· In order to benefit from higher transmit power, when maximum PSD regulatory requirements exist, RAN1 recommends support of longer PRACH sequence lengths, L=571 and L=1151, defined in Rel-16 NR specification, to be used for NR operating in 52.6 GHz to 71 GHz.
· It is recommended to not support interlace design for PRACH for NR operating in 52.6 GHz to 71 GHz.
· It is recommended to further investigate whether or not to support configurations that enable non-consecutive RACH occasions in time domainto aid LBT processes if LBT is required.
· Some companies noted that PRACH SCS selection should consider SCS of data/control channels and enablement of single subcarrier spacing operation.
· Some companies noted that 120 kHz SCS for PRACH (even if data/control channel may have different SCS) may be sufficient to support NR operating in 52.6 GHz to 71 GHz from coverage perspective.
· It was identified that potential enhancements for PRACH should consider system coverage for PRACH with subcarrier spacing larger than 120 kHz, if supported.
Agreement:
Capture the following observations in the TR (Editorial modifications and changes to references can be made when capturing the observations in the TR):
· It was identified that the potential enhancements to PDCCH monitoring including potential limitation to UE PDCCH configuration,, multiple PDSCH/PUSCH scheduling with a single DCI (using existing DCI formats or new DCI format(s)), spatial relation management for GC-PDCCH, capability related to PDCCH monitoring, and PDCCH coverage should be further investigated for higher subcarrier spacings, including the need for such enhancements.
· It was observed that PDCCH processing capabilities per multiple slots for larger SCS (e.g. 480 or 960 kHz) can maintain scheduling framework same as for smaller SCS (e.g. 120 kHz) when the UE is configured to monitor the PDCCH every multiple slots.
Agreement:
Capture the following observations in the TR (Editorial modifications and changes to references can be made when capturing the observations in the TR):
· Some companies have noted that interlace transmissions for PUSCH do not provide benefit over non-interlaced uplink allocations currently supported by NR for NR operating in 52.6 GHz to 71 GHz, while some companies have noted support of sub-PRB or PRB interlace transmissions for PUSCH may improve transmit power and possibly meets OCB requirements (some companies note OCB requirements can be met without introducing interlacing) when necessary.
· It was identified that for new subcarrier spacing, if agreed, will at least require investigation on the need for enhacnments and standardization, of the following processing timelines:
o Processing capability for PUSCH scheduled by RAR UL grant
o Dynamic SFI and SPS/CG cancellation timing
o Timeline for HARQ-ACK information in response to a SPS PDSCH release/dormancy.
o Minimum time gap for wake-up and Scell dormancy indication (DCI format 2_6)
o BWP switch delay
o Multi-beam operation timing (timeDurationForQCL, beamSwitchTiming, beam switch gap, beamReportTiming, etc.)
o Timeline for multiplexing multiple UCI types
o Minimum of P_switch for search space set group switching
o appropriate configuration(s) of k0 (PDSCH), k1 (HARQ), k2 (PUSCH),
o PDSCH processing time (N1), PUSCH preparation time (N2), HARQ-ACK multiplexing timeline (N3)
o CSI processing time, Z1, Z2, and Z3, and CSI processing units
o Any potential enhancements to CPU occupation calculation
o Related UE capability(ies) for processing timelines
o minimum guard period between two SRS resources of an SRS resource set for antenna switching
· It was identified that new subcarrier spacing, if agreed, may require further investigation of multi-PDSCH/PUSCH scheduling and standardization, if needed. The following aspects should be at least investigated for multi-PDSCH/PUSCH scheduling:
o whether to support a single TB and/or multiple TBs scheduled over multiple slots
o applicable DCI format(s) (including potential new formats, if needed) for multi-PDSCH and multi-PUSCH scheduling
o Enhancement on multiple beam indication and association with multiple PDSCH/PUSCH scheduling
o DM-RS enhancements such as DM-RS bundling, or changes to the time-domain pattern
o HARQ enhancements for multi-PDSCH
o Applicability of Rel-16 multi-PUSCH scheduling
Agreement:
Capture the following observations in the TR (Editorial modifications and changes to references can be made when capturing the observations in the TR):
It is recommended to further investigate potential enhancements to PUCCH to enable higher transmission power when regulatory limits apply. Further potential enhancements to spatial relation management for configured and/or semi-persistent UL signals/channels may be considered.
· Majority of the sources have identified PUCCH format 0, 1, and 4 as potential candidates for enahancement.
· Two sources has identified identified all PUCCH formats as potential candidates for enhancement.
R1-2009718 [103-e-NR-52-71-Waveform-Changes] Discussions Summary #6 Moderator (Intel Corporation)
Decisions: From GTW sessions,
Agreement:
Capture the following observations in the TR (Editorial modifications and changes to references can be made when capturing the observations in the TR):
· It is observed that in Rel-15 NR, absolute time for UE processing requirements generally decrease as subcarrier spacing increases. Some companies noted that introducing smaller UE processing time than Rel-15 and Rel-16, for larger subcarrier spacing, may lead to a more complex UE implementation. Some companies noted that per slot level monitoring for transmission and reception may not likely be the only mode of operation for higher subcarrier spacing, while some companies noted that per slot level monitoring for transmission and reception may be used as a mode of operation in scenarios that require lower latency.
· It is observed that, in general, larger subcarrier spacing may have benefit of short symbol/slot length to support lower latency requirements compared to what was supported for Rel-15 and Rel-16 NR, assuming slot-level monitoring subject to scheduling configurations and potentially UE processing capabilities.
· It is observed that, in general, channel access with shorter symbol duration may access channel earlier when LBT is passed, assuming slot-level monitoring and potentially subject to UE processing capabilities.
o CP needs to consider at least delay spread, timing errors (including Te), and timing alignment errors applicable for a deployment scenario.
o Minimum requirements on timing errors for new SCS values in > 52.6 GHz should be further studied in RAN4 when specifications are developed.
· Extended CP decreases the spectrum efficiency up to 14% compared to normal CP of the same subcarrier spacing.
Agreement:
Capture the following observations in the TR (Editorial modifications and changes to references can be made when capturing the observations in the TR):
· Some companies observed that the relationship between channel bandwidth and initial access aspects should be taken into account for the supported channel bandwidth(s), especially for minimum channel bandwidth. Some companies observed that a wider minimum channel bandwidth supported for a band may help to limit the number of synchronization raster entries in the band, if the same design principle for Rel-15 licensed bands applies (Minimum channel bandwidth and synchronization raster entries will be defined by RAN4).
· Available bandwidth within a given carrier for RMSI transmission for SSB and CORESET multiplexing pattern 2 and 3 is smaller than available bandwidth for multiplexing pattern 1. Some companies observed that the channel bandwidth supported for a band should be wide enough to enable multiplexing e.g. between SSB, CORESET0, and RMSI transmissions in multiplexing pattern 2 and 3. Some companies observed that depending on the supported carrier bandwidth and configured values of O and M, multiplexing pattern 1 can make available more time/frequency resources for RMSI PDSCH in a slot than pattern 2 and 3. Some companies observed that patterns 2 and 3 are more efficient than pattern 1 as it may potentially minimize the broadcast overhead in time.
Agreement:
Capture the following observations in the TR (Editorial modifications and changes to references can be made when capturing the observations in the TR):
· It is recommended to further investigate the need for DL and UL PT-RS enhancement for the subcarrier spacings to be supported in specifications. PT-RS enhancements, if needed, can consider the following:
o support of high MCS values,
o applicability of ICI compensation techniques,
o PT-RS sequence,
o time and frequency resources for PT-RS with OFDM and DFT-s-OFDM waveforms.
· It is recommended to further investigate the need for DL and UL DM-RS enhancements for the subcarrier spacings to be supported in specifications. DM-RS enhancements, if needed, can consider the following:
o coherence bandwidth and its impact to orthogonal codes used for DM-RS,
o frequency domain density and overhead,
o maximum number of DM-RS ports.
· Some companies noted LBT failure may prevent transmission of periodic reference signals, such as P-TRS, and negatively impact performance. Some companies noted deferral of periodic reference signals may be rare and may not significantly impact system performance. Some companies noted aperiodic reference signals could be used to negate the potential impact from LBT failure.
Agreement:
Capture the following observations in the TR (Editorial modifications and changes to references can be made when capturing the observations in the TR):
It is recommended to investigate whether or not enhancements to CSI processing unit (CPU) availability check is needed when the UE is required to process CSI reports corresponding to multiple numerologies across active BWPs in different component carriers.
Agreement:
Capture the following observations in the TR (Editorial modifications and changes to references can be made when capturing the observations in the TR):
It is recommended that both single and multi-carrier operation are supported to support higher data rates. Larger SCS may achieve larger aggregated bandwidth with multi-carrier operation given a maximum number of CCs.
Agreement:
Capture the following observations in the TR (Editorial modifications and changes to references can be made when capturing the observations in the TR):
· It is recommended to further investigate potential enhancements, if needed, to beam management at least considering one or more of potentially narrower beamwidths, CP duration, multiple beam indications for multi-PUSCH/PDSCH scheduling, triggering of reference signals for beam management, enhancements to beam management for random access procedure, intra- and/or inter-cell mobility, and adaptation to LBT failures.
· Minimum requirement on beam switching delay in > 52.6 GHz spectrum should be further studied by RAN4 when specification is further developed.
Agreement:
Capture the following for the conclusion paragraph of the TR:
------------------------------------- Begin ------------------------------------
Study of required changes to NR using existing DL/UL NR waveform to support operation between 52.6 GHz and 71 GHz was conducted. The study included study of applicable numerology including subcarrier spacing, channel BW (including maximum BW), and their impact to FR2 physical layer design to support system functionality considering practical RF impairments, and identification of potential critical problems to physical signal/channels, if any. Study of channel access mechanism, considering potential interference to/from other nodes, assuming beam-based operation, in order to comply with the regulatory requirements applicable to unlicensed spectrum for frequencies between 52.6 GHz and 71 GHz was also conducted.
As an outcome of the study, it is recommended to support 120 kHz subcarrier spacing with normal CP length, and at least one additional subcarrier spacings among 240 kHz, 480 kHz, and 960 kHz subcarrier spacing candidates. It is recommended to consider supporting at most up to three subcarrier spacings including 120 kHz. It is not recommended to consider support of only 240 kHz SCS for PDCCH/PDSCH/PUCCH/PUSCH in addition to 120 kHz. Subcarrier spacing outside 120 kHz to 960 kHz are not supported for any signals and channels. The applicability of the supported subcarrier spacing to particular signals and channels should be further discussed when specifications are developed. It is additionally recommended to limit the maximum FFT size required to 4096 and to limit the maximum of RBs per carrier to 275 RBs. The candidate supported maximum carrier bandwidth(s) for a cell should be between 400 MHz and 2160 MHz. Further investigation of the details of required changes to NR may be needed.
As an outcome of the channel access study, it is recommended to support both channel access with LBT mechanism(s) and a channel access mechanism without LBT for gNB and UE to initiate a channel occupancy. Further investigation of the details of the channel access mechanism may be needed.
------------------------------------- End ------------------------------------
Agreement:
· Support of only 240 kHz SCS for PDCCH/PDSCH/PUCCH/PUSCH in addition to 120 kHz should not be considered
R1-2009668 Summary of 38.808 TR Text Proposal Discussion Moderator (Intel Corporation)
Decision: As email decision posted on Nov.13th, email thread is extended with a new deadline of Nov. 18 with a focus only on finalizing the TR capturing all of the agreements. Final summary for the TR text available in:
R1-2009779 Summary#2 of 38.808 TR Text Proposal Discussion Moderator (Intel Corporation)
R1-2007550 On channel access modes in 60GHz FUTUREWEI
R1-2007559 Discussion on channel access for NR beyond 52.6 GHz Lenovo, Motorola Mobility
R1-2008976 Channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon (rev of R1-2007605)
R1-2007643 Channel access mechanism for NR on 52.6-71 GHz Beijing Xiaomi Software Tech
R1-2007653 Discussion on channel access mechanism vivo
R1-2007791 On Channel access mechanisms InterDigital, Inc.
R1-2007848 Channel Access Mechanism in support of NR operation in 52.6 to 71 GHz CATT
R1-2007884 Channel access mechanism TCL Communication Ltd.
R1-2007918 Channel access mechanisms for NR from 52.6-71GHz AT&T
R1-2009312 Design of NR channel access mechanisms for 60 GHz unlicensed band Nokia, Nokia Shanghai Bell (rev of R1-2007927)
R1-2009380 Channel Access Procedure for NR in 52.6 - 71 GHz Intel Corporation (rev of R1-2008806, rev of R1-2007942)
R1-2007966 On the channel access mechanism for above 52.6GHz ZTE, Sanechips
R1-2007983 Channel Access Mechanism Ericsson
R1-2008046 Considerations on channel access mechanism to support NR above 52.6 GHz LG Electronics
R1-2008091 Discussion on channel access mechanism for above 52.6GHz Spreadtrum Communications
R1-2008157 Channel access mechanism for 60 GHz unlicensed spectrum Samsung
R1-2008251 Discussion on channel access OPPO
R1-2008354 Channel access mechanism for 60 GHz unlicensed spectrum Sony
R1-2008458 Views on Channel Access Mechanisms for Unlicensed Access above 52.6 GHz Apple
R1-2008494 Discussions on channel access mechanism on supporting NR from 52.6GHz to 71 GHz CAICT
R1-2008517 On Channel Access Mechanism and Interference Handling for Supporting NR from 52.6 GHz to 71 GHz Convida Wireless
R1-2008548 Channel Access Mechanism for NR in 60 GHz unlicensed spectrum NTT DOCOMO, INC.
R1-2008563 Discussion on channel access mechanism ITRI
R1-2009362 Channel access mechanism for NR in 52.6 to 71GHz band Qualcomm Incorporated (rev of R1-2008630, rev of R1-2008616)
R1-2008717 Discussion on channel access mechanism for 52.6 to 71GHz unlicensed band Potevio
R1-2008770 Further aspects of channel access mechanisms Charter Communications
[103-e-NR-52-71-Channel-Access] – Jing (Qualcomm)
Email discussion/approval on channel access mechanisms including aspects related to system level simulations until 11/3; address any remaining aspects by 11/11
Additional checkpoint where agreements can be declared: 11/9
R1-2009344 FL summary for channel access of 52.6GHz to 71GHz band Moderator (Qualcomm)
R1-2009363 FL summary#2 for channel access of 52.6GHz to 71GHz band Moderator (Qualcomm)
Agreement:
At least when operating with LBT, MCOT is 5ms, including all the gaps inside
Note: Discussions related to further reductions in MCOT due to potential definition of CAPC will be handled separately.
R1-2009368 FL summary#3 for channel access of 52.6GHz to 71GHz band Moderator (Qualcomm)
Agreement:
Capture the following observations in the TR. Editorial modifications and changes to references can be made when capturing the observations in the TR.
· Comparison of No-LBT (NLBT) and Tx Side ED based Omnidirectional Sensing (TxED-Omni) for Indoor Scenerio A: 6 Companies have compared No-LBT with Tx Side ED based Omni sensing LBT
o Vivo shows tail and median benefits of using TxED-Omni LBT on DL, at high loading. In other cases, including all loads for UL and other loads for DL, TdxED-Omni LBT scheme shows losses. All results are at ED threshold -47.
o Intel shows gains for 5%ile DL throughput at high loads with TxED-Omni LBT. In other cases including all loads for UL and other loads for DL, TdxED-Omni LBT scheme shows losses. All results are at ED threshold -47.
o Ericsson, Huawei, Nokia, Qualcomm and Samsung show loss for TxED-Omni LBT with an EDT of -47 or -48 dB for all cases.
R1-2009408 FL summary#4 for channel access of 52.6GHz to 71GHz band Moderator (Qualcomm)
R1-2009521 FL summary#5 for channel access of 52.6GHz to 71GHz band Moderator (Qualcomm)
Agreement:
Use the CCA check procedure in EN 302 567 (per RAN1 understanding as from RAN1 #102-e) as the baseline for channel access for 60GHz band when LBT is applied. The following can be discussed further during normative work.
· Whether CAPC and contention window adjustment mechanisms are introduced
· Whether ED threshold change is needed, e.g., due to changes in bandwidth, beamforming gain etc.
· Whether contention window range needs to be adjusted
R1-2009572 FL summary#6 for channel access of 52.6GHz to 71GHz band Moderator (Qualcomm)
R1-2009626 FL summary#7 for channel access of 52.6GHz to 71GHz band Moderator (Qualcomm)
Agreement:
Capture the following in the TR:
On the LBT bandwidth (bandwidth over which a single contiguous LBT is performed) relative to channel bandwidth (as defined in RAN4), the following alternatives have been discussed. Further down-selection of one or more of these alternatives (if needed) should be further discussed when specifications are developed.
· Alt 1: LBT bandwidth equals channel bandwidth
· Alt 2: LBT bandwidth equals the minimum of channel bandwidth and the transmission bandwidth (number of RBs for a given transmission)
· Alt 3: LBT bandwidth can be wider than channel bandwidth
· Alt 4: LBT bandwidth can be narrower than the channel bandwidth, with multiple LBT subband within a channel
· Alt 5: LBT bandwidth equals with minimum supported channel bandwidth or multiples of the minimum supported channel bandwidth
Agreement:
Capture the following in the TR:
For operation where LBT is not required, it can be further discussed when specifications are developed
· If RAN1 should introduce additional conditions/mechanisms for no-LBT to be used, or leave it for gNB implementation
· When no-LBT mode is used, if RAN1 should introduce additional restrictions, such as DFS needs to be applied, ATPC needs to be applied, long term sensing needs to be applied, certain duty cycle limitation, certain transmit power limitation, MCOT limits, etc, or leave the restriction for gNB implementation
· When no-LBT mode is used, if RAN1 should introduce mechanism for the system to fallback to LBT mode, or leave it for gNB implementation
R1-2009675 FL summary#8 for channel access of 52.6GHz to 71GHz band Moderator (Qualcomm)
Agreement:
Capture the following observations in the TR. Editorial modifications and changes to references can be made when capturing the observations in the TR.
The following discussion refers to 5th percentile users as ‘tail’ users and 95th percentile users as ‘upper-tail’ users. Remarks mentioning ‘all users’ are applicable to tail, median and upper tail users at once.
· Comparison of No-LBT with directional LBT (TxED-Dir) for Indoor Scenario A: Vivo, Huawei, Nokia, Samsung, Intel, Ericsson provided results
o Vivo results show gain for directional LBT ((TxED-Dir) over No-LBT for DL, high load, for tail , median and upper tail users, and for UL, high load for tail users. For all other cases in this comparison, TxED-Dir underperforms No-LBT. (EDT -47 dBm)
o Nokia, for 100% DL presented low, medium and high load results. For all loads, their results show significant loss for both directional and omni-directional LBT for median and high-end users. Only the tail users may have some benefit from directional LBT (as compared to No-LBT), while omni-LBT provides loss also in this case (EDT -48 dBm).
o Ericsson results show No-LBT outperforms directional LBT with (EDT -47 dBm) and directional LBT with (ED -32 dBm for gNB, ED -41 dBm for UE)
o Samsung results show gain in medium and high loads for directional LBT over No-LBT at (EDT -47 dBm) for all users for DL as well as for UL. At low loads TxED-Dir underperforms No-LBT.
o Intel shows gains for DL throughput at high loads with TxED-Dir LBT for all antenna configurations when BSs are ceiling mounted, and gains for 5%ile DL throughput at high loads when the BS are not ceiling mounted. In other cases, including all loads for UL, TdxED-Dir LBT scheme shows losses. All results are at ED threshold of -48
o Huawei largely shows loss for directional LBT over No-LBT for all loading levels and users, except DL, tail users at high loading where the results are comparable. Huawei’s TxED-Dir uses CW-Max of 127 with EDT of -47 dBm.
Agreement:
Capture the following observations in the TR (Editorial modifications and changes to references can be made when capturing the observations in the TR):
· Comparison of Omni LBT (TxED-Omni) with directional LBT (TxED-Dir) for Indoor Scenario A: Vivo, ZTE, Nokia, Samsung, Intel, Qualcomm, Ericsson, and Huawei, provided results
o For Omni LBT (TxED-Omni) with directional LBT (TxED-Dir) have been done with using the same ED Threshold. Additionally, Ericsson simulated directional LBT with adjusted thresholds (ED -32 dBm for gNB, ED -41 dBm for UE). Multiple companies have evaluated adjustments to ED Threshold with directional sensing either implicitly or explicitly.
o Vivo results show that omni-directional is better than directional LBT in tail and median performance, and marginal difference in other cases. Both omni-directional and directional LBT use the same ED threshold of -47 dBm
o Samsung shows gain at all loading levels for directional LBT over omni-LBT (-47 dBm) for all users, for DL and UL traffic.
o Intel shows that for UL TxED-Dir LBT provides better performance relative to TxED-Omni for low ED thresholds (i.e., -55 and -65 dBm) but losses for high thresholds (i.e., -48 dBm). As for DL, TxED-Dir LBT provides consistently better performances than TxED-Omni. The gain of directionality increases with more directional UE beams.
o Qualcomm results show largely a comparable performance for omni and directional sensing using equal threshold, with small benefit of directionality under gNBs with narrower beams
o Ericsson results show that directional LBT with adjusted thresholds (ED -32 dBm for gNB, ED -41 dBm for UE) and directional LBT with ED -47 dBm, and omni-directional LBT with ED -47 dBm have comparable performance.
o
For 100% DL traffic, Nokia
results show that directional LBT TxED-Dir outperforms TxED-Omni at low as well
as medium loads – for median, tail as well as upper tail users. The results use
EDT -487 dBm
o
For 100% DL traffic, ZTE
shows gains in directional LBT for tail users and median users at ED thresholds -68 dBm
and -62 dBm. The gains are also present in DL+UL Traffic
at ED threshold -68 dBm and -62 dBm.
o Coexistence: ZTE shows that an operator using directional LBT benefits in the presence of an operator using Omni LBT, relative to a deployment where both operators use Omni-LBT. The results use ED threshold -68 dBm.
o Huawei’s results show that directional LBT (TxED-Dir) does not outperform Omni LBT (TxED-Omni)
Agreement:
Capture the following observations in the TR (Editorial modifications and changes to references can be made when capturing the observations in the TR):
· Comparison of No-LBT with receiver assisted LBT for Indoor Scenario A: Ericsson, Huawei, Vivo, provided results
o Different versions of receiver assistance modelled as presented earlier
o Ericsson results uses omni-sensing at receiver. The results do not show benefit for receiver assistance over No-LBT.
o Vivo’s results use an EDT -47 dBm, in the results, RxA-4-Omni gains in both DL and UL relative to No-LBT for tail users at high loads. RxA-4-Omni gains in DL but loses in UL relative to No-LBT for medium and high loads at all other user percentiles and mean.
o Huawei’s Receiver-only LBT (RxA-3) shows tail UPT and mean UPT gain compared to No-LBT in low, medium, and high traffic loads with InH Open Office channel model 40] and InH mixed channel model [40] in both UL and DL.
o In comparison with No-LBT, Huawei shows Receiver-assisted LBT (RxA-2) Tail UPT gain in DL with high traffic load for InH open office channel model and loss in other cases. Also, Huawei shows Receiver-assisted LBT Tail UPT gain in DL with low, moderate and high traffic load for InH mixed channel model and loss in other cases.
Agreement:
Capture the following observations in the TR (Editorial modifications and changes to references can be made when capturing the observations in the TR):
· Comparison of receiver assisted LBT versions with Omni LBT (Tx-ED-omni), and directional LBT (TxED-dir) for Indoor Scenario A: Huawei, Qualcomm, Vivo and Ericsson provided results
o Ericsson results show similar performance of receiver assisted LBT (RxA-1) and omni- directional LBT (TxED-Omni). Nonetheless, the RxA-1 implementation does not model the overhead of information exchange between the transmitter and receiver. Hence, it is expected that the actual performance of RxA-1 is worse than the simulated one
o Huawei’s both flavors of receiver assistance, Rx-Assisted LBT (RxA-2), and Receiver Only LBT (RxA-3) outperform Tx-ED-Omi and Tx-ED-Dir at all loading levels and users percentiles, with larger benefits to tail users
o Qualcomm results show gains with receiver assisted LBT for DL and UL in the median as well as tail, primarily at higher loading levels. (A) The results show receiver assisted LBT RxA-5 Omni @EDT -67dBm and RxA-5 Dir@-67dBm 67dBm outperforms TxED-Omni and TxED-Dir as loading level increases. (B) Qualcomm results show comparable performance of RxA-5 Omni and RxA-5 Dir for the baseline gNB Antenna Configuration. (C) Further, as directionality increases at the gNB with more antenna elements, ( i.e. when gNB Configuration (Mg,Ng,M,N,P) = (1,1,4,8,2) is replaced with (Mg,Ng,M,N,P) = (1,1,8,16,2)) the relative benefits of Rx-Assistance are shown to be larger,. (D) Further as silencing Threshold is decreased from -67 to -72 dBm, the relative gains of Rx-Assistance increase. At 2 gHz BW, a silencing threshold of -72dBm is close to noise floor and may not be achieved as ED but may require a sequence detection mechanism.
o Vivo results show gains with receiver assisted LBT RxA-4-Omni relative to TxED-Omni primarily for uplink, at medium and high loads for all users. For DL, the performance is comparable between RxA-4 Omni and TxED-Omni, except at high load tail, where RxA-4-Omni underperforms.
Agreement:
Capture the following observations in the TR (Editorial modifications and changes to references can be made when capturing the observations in the TR):
For Indoor scenario A:
· Huawei shows Receiver-only LBT (RxA-3) tail UPT and mean UPT gain compared to receiver-assisted LBT (RxA-2) in low, medium, and high traffic loads with InH Open Office channel model [40] and InH mixed channel model [40].
· Ericsson’s results in Coexistence scenario with Operator A doing No-LBT and Operator B doing TxED-Omni LBT at -47 dBm EDT show that the operator B performance does not degrade (i.e. no losses observed) as compared to the case when Operator B coexists with another operator using LBT.
· Ericsson’s results for Dynamic LBT shows that the performance of the network can be improved when the decision to perform LBT is done dynamically per node, as compared to semi-statically operating all nodes with LBT.
Agreement:
Capture the following observations in the TR (Editorial modifications and changes to references can be made when capturing the observations in the TR):
· Comparison of No-LBT with omnidirectional LBT (TxED-Omni) for Indoor Scenario C: Ericsson and HW show loss for TxED-Omni LBT, Charter shows roughly comparable performance
o Ericsson’s results show worse performance for TxED-Omni LBT relative to No-LBT for both threshold -47dBm and -68 dBm. The loss is higher for EDT -68dBm.
o Charter’s low load DL:UL 50:50 results show loss for TxED-Omni LBT over No-LBT. Their medium load DL:UL 5:2 results show gains in DL tail user and UL median user, loss in UL tail user and comparable performance for other cases. Their high load results for DL:UL ~2:1, show small tail gain and median loss for DL and comparable performance for UL.
o Huawei’s results show loss for TxED-Omni LBT over No-LBT at -47dBm EDT for gNB and -32dBm EDT for UE.
· Comparison of omnidirectional LBT (TxED-Omni) with directional LBT (TxED-Dir) for Indoor Scenario C:
o In Huawei and Ericsson’s results, for equal ED threshold, Directional sensing, (TxED-Dir) and Omni sensing (Tx-ED-Omni) show comparable results.
o ZTE show gains for directional LBT in median users as well as tail users at -68 dBm ED threshold for 100% DL traffic
· Comparison of Rx-Assistance LBT schemes with others for Indoor scenario C
o Ericsson results show similar performance of Rx Assistance (RxA-1 -Omni) and TxED-Omni LBT but loss relative to no-LBT at both modelled ED thresholds. There is no benefit of using RxA-1 scheme over TxED-Dir LBT scheme for ED Threshold -47dBm.
o Another form of Rx-Assistance, referred as, Dyn-RxA is shown by Ericsson to provide similar performance as No-LBT for ED Threshold -47 dBm.
o Huawei’s results show consistent loss for receiver assistance scheme RxA-2 compared to No-LBT. RxA-2 is shown to outperform TxED-Omni and TxED-Dir for this scenario.
Agreement:
Capture the following in the TR. Editorial modifications and changes to references can be made when capturing the observations in the TR.
For Outdoor scenario B:
· Ericsson results show loss of TxED-Omni LBT schemes compared to No-LBT, for two ED thresholds (-47 and -68 dBm). TxED-Omni LBT with ED Threshold of -68 dBm dBm and -47 dBm has similar performance. HW shows loss for LBT schemes with respect to no-LBT for 1-site and 7 -site scenarios. Directional and omni LBT are comparable at -47dBm EDT for gNB and -32dBm EDT for UE.
· Huawei results show loss of TxED Omni LBT scheme compared to No-LBT for ED Threshold -47 dBm. TxED Omni and TxED-Dir are shown to have comparable performance. Receiver assisted LBT (RxA-2) is seen to improve tail performance and to a small extent median user performance at high loading levels compared to TxED-Omni, and in all other cases seen to have comparable performance. RxA-2 simulated underperforms No-LBT in all cases. These trends hold for 7-site as well as 1-site simulations.
R1-2009724 FL summary#9 for channel access of 52.6GHz to 71GHz band Moderator (Qualcomm)
Agreement:
Capture the following observations in the TR (Editorial modifications and changes to references can be made when capturing the observations in the TR):
· One company [Ericsson] submitted results for Indoor Scenario B, which is a smaller indoor scenario with 2 operators and 1 gNB each. Their observations for this case are in line with their observations for Indoor Scenario A.
R1-2009760 FL summary#10 for channel access of 52.6GHz to 71GHz band Moderator (Qualcomm)
Agreement:
Capture the following observations in the TR. Editorial modifications and changes to references can be made when capturing the observations in the TR.
The following flavors of channel access schemes have been modeled.
· ‘No-LBT’: No LBT Dynamic TDD: NR operation with no restrictions on channel access mechanism.
· ‘TxED-omni’: Tx side ED Based LBT with Omnidirectional Sensing (‘Tx Omni LBT): Baseline LBT with sensing at the transmitter is expected to closely follow the ETSI En 302 567 based medium access procedure
· ‘TxED-Dir’, Tx Side ED Based LBT with Directional Sensing (‘Tx Directional LBT’)
· Rx Assisted LBT Flavors: Multiple flavors of Rx Assistance have been modelled
o RxA-1: [20, Ericsson], Receiver assisted LBT: the LBT procedure is evaluated at the receiver instead of transmitter. The LBT result is assumed to be available instantly at the transmitter without accounting any overhead for exchanging this information between the transmitter and the receiver
o RxA-2: [4, Huawei/HiSilicon] [40, Huawei/HiSilicon]: Receiver performs directional LBT but transmitter performs Omni LBT. Further details for RxA-2 are as follows. When UE is the receiver, UE receives a RTS from the gNB. Then, UE sends a “message B” to the gNB with CCA measurements results (dBm value of the measured interference) upon a successful LBT procedure. The latency from the reception of RTS to the transmission of “message B” is calculated equal to 4 slots for 120 kHz SCS and 22 slots for 960 kHz SCS. This includes the required time at the UE side for CCA. Then, gNB transmits PDSCH to the UE. The PDSCH processing time is calculated as 3 slots for 120 kHz and 13 slots for 960 kHz. A CAT4 LBT is performed at the gNB side before RTS transmission. When gNB is the receiver, first gNB performs energy measurement at the directions of the UEs that have UL data. Then, gNB selects the UE with the lowest interference level. After, gNB sends PDCCH to schedule PUSCH transmission of that UE. Finally, PUSCH is transmitted after a successful CAT2 LBT. In our simulations, we have considered the preparation time from PDCCH reception to PUSCH transmission equal to 4 slots for 120 kHz SCS and 22 slots for 960 kHz SCS. A processing time for PUSCH at gNB is not modelled. The transmissions are restricted to Rank 1 for DL as well as UL throughout.
o RxA-3: [4, Huawei/HiSilicon] [40, Huawei/HiSilicon]: Only Receiver performs directional LBT procedure. The procedure is similar to RxA-2 except that gNB does not perform any LBT before RTS transmission.
o RxA-4: [6, Vivo]: RTS and CTS type mechanism is deployed after winning contention before transmission. The RTS/CTS type exchange is between serving gNB and the served UEs. The transmitter sends a request, and the receiver feedbacks a confirmation if the request could be successfully decoded. Unlike RTS/CTS mechanism in 802.11ad, both the request and confirmation do not silence any other node. The processing delay for the RTS/CTS is assumed to be zero. There is no LBT before CTS.
o RxA-5: [36, Qualcomm]: Rx Assistance takes the form of protecting ongoing transmissions by silencing based on sensing at the transmitters and protecting intended transmission by silencing based on sensing at the receiver. The receiver also assists by sending silencing signals. Omni and directional sensing is applied at all nodes. In the simulated procedure, the ECCA is performed at the gNB followed by an exchange of request/response transmissions.
· Other LBT Flavors:
o ‘Dyn-RxA’: Dynamic [20, Ericsson], Dynamic LBT: a node operates without LBT unless the receiver experiences a failure in reception due to a drop in SINR, which reflects a presence of interferer. Only then, the node switches to LBT. Besides, when the LBT is switched on, the RAL described in section 2.1.4 of R1-2007983 is used
Agreement:
Capture the tables in Section 3.3 of R1-2009626 in the TR with the following modifications:
Agreement:
It can be further discussed when specifications are developed if and how the ED threshold provided by the ETSI BRAN 302 567 should be modified to account for aspects such as transmit power, LBT bandwidth, beamforming gain, coexistence etc.
· Note: There is no consensus that all of the aspects above need to be considered
Agreement:
When LBT mode is used, it can be further discussed when specifications are developed if a responding device should use a Cat 2 LBT to share the COT, and if yes, how to define the Cat 2 LBT and if a maximum gap is to be introduced between the initiating device and responding device transmissions.
Agreement:
· Support of contention-exempt short control signalling transmission in 60GHz band for regions where LBT is required and short control signaling without LBT is allowed.
o Note: If regulations do not allow short control signaling exemption in a region when operating with LBT, operation with LBT for these short control signals should be supported
· Restrictions to the transmission, such as, on duty cycle (airtime measured over a relatively long period of time), content, TX power, etc. can be discussed when specifications are developed.
Agreement:
It can be further discussed when specifications are developed if 3GPP specifications should define the relationship between the LBT beam and the transmission beam or leave it as implementation. If such relationship is defined, it can also be further discussed when specifications are developed if ED threshold should be adjusted by the choice of LBT beam and transmission beam.
Agreement:
When LBT mode is used, spatial domain multiplexing of different beams is supported. The LBT requirement (if any) for spatial domain multiplexing of multiple beams can be further discussed when specifications are developed. At least the following can be considered while other LBT considerations are not excluded.
· Leave the LBT behaviour for implementation
· One LBT beam covers all transmission beams
· Multiple LBT beams cover multiple transmission beams
Agreement:
When LBT mode is used, time domain multiplexing of DL/UL transmissions in different beams in the same COT is supported. The LBT requirement (if any) for time domain multiplexing of DL/UL transmissions in multiple beams can be further discussed when specifications are developed. At least the following can be considered while other LBT considerations are not excluded
· No additional LBT requirement defined and leave the LBT behaviour for implementation
· Perform directional or omni-directional LBT at the beginning of COT with sensing beam(s) that covers all TDM beams and with no LBT before each beam switching in the middle of COT.
· Perform directional or omni-directional LBT at the beginning of COT with sensing beam(s) that covers all TDM beams or the first transmission beam, and additional directional LBT with sensing beam that covers the next transmission beam for each beam switching in the middle of COT.
Agreement:
Capture the following in TR:
The following receiver assisted channel access and interference management schemes have been considered and can be further investigated when specifications are developed
· Class A. Receiver provides assistance information (signalling) to transmitter only. The following aspects of Class A can be further discussed when specifications are developed
o Applicability in the following potential channel access modes:
§ LBT is performed prior to transmission
§ No LBT is performed prior to transmission
o Details of assistance information (e.g., type, timing, content, how the assistance information is obtained etc.)
o Whether the assistance information can be obtained by LBT performed at the receiver prior to transmission
o Whether the assistance information can be obtained by existing layer 1 and layer 3 measurements with enhancements if needed
o If any specification changes are needed to support Class A
Also, the following receiver assisted channel access schemes have been considered, and considering the system performance and complexity tradeoff, these schemes will not be further investigated in Rel.17
· Class B. Receiver provides assistance information (signalling) to other NR nodes, including non-serving nodes
o In this case, cross RAT coexistence is based on ED
o Class B1. Intra-operator only
o Class B2. Also including inter-operator signalling
§ In this case, cross operator coexistence is based on ED
· Class C. Receiver provides assistance information (signalling) to other NR nodes and nodes from other RAT
Agreement:
Capture observations in Section 3.4.8.4 of R1-2009760 in the TR (Section numbers and other references can be updated when incorporating into the TR)
R1-2007560 Additional evaluations for NR beyond 52.6GHz Lenovo, Motorola Mobility
R1-2007654 Evaluation on different numerologies for NR using existing DL/UL NR waveform vivo
R1-2007792 Evaluation results for above 52.6 GHz InterDigital, Inc.
R1-2007928 Simulation Results for NR from 52.6 GHz to 71 GHz Nokia, Nokia Shanghai Bell
Late submission
R1-2007943 Considerations on performance evaluation for NR in 52.6-71GHz Intel Corporation
R1-2009450 Simulation results for NR above 52.6GHz ZTE, Sanechips (rev of R1-2007967)
R1-2007984 Evaluation results for NR in 52.6 - 71 GHz Ericsson
R1-2008047 Considerations on phase noise compensation to support NR above 52.6 GHz LG Electronics
R1-2008873 Evaluaton results for extending NR to up to 71 GHz Samsung (rev of R1-2008158)
R1-2009615 Discussion on other aspects OPPO (rev of R1-2008252)
R1-2008459 Evaluation results for Physical Layer Design for NR above 52.6GHz Apple
R1-2008549 Potential Enhancements for NR on 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2009157 Performance evaluations for NR above 52.6 GHz Charter Communications, Inc (rev of R1-2008771)
R1-2009610 Link level and System level evaluation for NR system operating in 52.6GHz to 71GHz Huawei, HiSilicon (rev of R1-2009459, rev of R1-2008779)
R1-2009111 Summary of link level evaluation results and related issues on supporting NR from 52.6 GHz to 71 GHz Moderator (vivo)
[103-e-NR-52-71-Evaluations] – Huaming (vivo)
Email discussion/approval on aspects related to link level evaluations until 11/4; address any remaining aspects by 11/12
Additional checkpoint where agreements can be declared: 11/9
R1-2009355 Discussion summary #1 for [103-e-NR-52-71-Evaluations] Moderator (vivo)
R1-2009377 Discussion summary #2 for [103-e-NR-52-71-Evaluations] Moderator (vivo)
R1-2009392 Discussion summary #3 for [103-e-NR-52-71-Evaluations] Moderator (vivo)
R1-2009524 Discussion summary #4 for [103-e-NR-52-71-Evaluations] Moderator (vivo)
R1-2009609 Discussion summary #5 for [103-e-NR-52-71-Evaluations] Moderator (vivo)
Agreement:
Capture the following observations in the TR (updates to references and other editorial modifications can be made for inclusion in the TR):
7 sources ([61, Ericsson], [26, Qualcomm], [56, vivo], [64, OPPO], [21, Apple], [25, NTT DOCOMO], [12, Intel]) reported evaluation results of PSS/SSS detection performance in terms of SINR in dB achieving cell ID detection probability of 90% by one-shot detection from PSS/SSS. 4 sources ([61, Ericsson], [26, Qualcomm], [56, vivo], [21, Apple]) reported PBCH performance in terms of SINR in dB achieving PBCH BLER target of 10%. 2 sources ([5, vivo], [14, 61, Ericsson]) compared link budget of SSB for difference SCS.
· For PSS and SSS detection performance, all evaluated candidate SCSs (120, 240, 480 and 960 kHz) show comparable performances with the non-optional (non-optional to be replaced by references to channel model in Tables to be added when capturing in TR) channel models and delay spread values.
o The performance degrades as the increase of SCS.
o Note: the following is reference when derive the observations.
o 6 out of 7 sources reported minor performance difference (< or ~ 1 dB) between adjacent SCS for all evaluated candidate SCSs (120, 240, 480 and 960 kHz). The other source ([21, Apple]) reported more than 3 dB performance gap of 960 kHz SCS compared to other 120, 240 and 480 kHz SCS. It also reported that the gap of 960 kHz increases as the delay spread increases.
· For PBCH BLER performance, all evaluated candidate SCSs (120, 240, 480 and 960 KHz) show comparable performances with the non-optional (non-optional to be replaced by references to channel model in Tables to be added when capturing in TR) channel models and delay spread.
o The performance degrades as the increase of SCS.
o All 4 sources reported minor performance difference (< or ~ 1 dB) between adjacent SCS for all evaluated candidate SCSs (120, 240, 480 and 960 KHz).
o The performance gap between 120 and 960 kHz is up to ~ 1.8 dB.
· In terms of SSB link budget, smaller SCS have better coverage than larger SCS
o The MCL and MIL difference between 120 kHz SCS and 480 kHz SCS is about 5 dB. The MCL and MIL difference between 120 kHz SCS and 960 KHz SCS is about 8 dB.
Agreement:
· Summary observations #2a in Section 2.1.1.2 of R1-2009609 are agreed to supersede the previously agreed corresponding observations.
Agreement:
· Summary observations #2 in Section 2.1.3 of R1-2009609 are agreed to supersede the previously agreed corresponding observations.
Agreement:
· Summary observations #2a in Section 2.1.4 of R1-2009609 are agreed to supersede the previously agreed corresponding observations.
Agreement:
· Summary observations #2 in Section 2.1.5 of R1-2009609 are agreed to supersede the previously agreed corresponding observations.
Agreement:
· Summary observations #2 in Section 2.3 of R1-2009609 are agreed to supersede the previously agreed corresponding observations.
Agreement:
Capture the following observations in the TR (updates to references and other editorial modifications can be made for inclusion in the TR):
8 sources ([61, Ericsson], [68, Huawei], [26, Qualcomm], [56, vivo], [60, ZTE], [64, OPPO], [25, NTT DOCOMO], [12, Intel]) reported evaluation results of PRACH preamble detection performance in terms of SINR in dB achieving PRACH preamble misdetection probability of 1% with evaluation assumptions and parameters as in Table A.1-1 of TR 38.808. Two sources ([14, 61, Ericsson], [19, OPPO]) compared link budget of PRACH for different SCS.
The following are observed.
· For PRACH preamble detection performances for the same PRACH format, all evaluated candidate SCSs (120, 240, 480 and 960 kHz) show comparable performances
o Note: The following references were used to derive the observations.
o 7 out of 8 sources reported minor performance difference (< or ~ 1 dB) between adjacent SCS for all evaluated candidate SCSs (120, 240, 480 and 960 kHz). The other source ([64, OPPO]) reported minor performances difference among all SCS for TDL-A with 5 and 10ns DS. It reported infinite SINR for 960 kHz SCS and comparable SINR for 120, 240 and 480 kHz SCS in TDL-A with 20ns DS using the metrics of preamble miss detection probability of 1% and the estimated timing error is within [-Tcp/2, Tcp/2].
· For PRACH link budget of the same PRACH format and the same sequence length, maximum isotropic loss (MIL) and maximum coupling loss (MCL) degrade as the subcarrier spacing is increased, negatively impacting coverage.
o Two sources ([14, 61, Ericsson], [19, OPPO]) reported that with UE power limitation of 25 dBm EIRP, the MCL/MIL difference between 120 KHz SCS and 480 KHz SCS is about 4 to 5 dB; the MCL/MIL difference between 120 KHz SCS and 960 KHz SCS is about 8 dB.
o One source ([14, 61, Ericsson]) reported that without UE power limitation of 25 dBm EIRP (but still under regulatory limits), the MCL difference between 120 kHz SCS and 480 kHz SCS is less than 2.5 dB; the MCL difference between 120 kHz SCS and 960 kHz SCS is less than 1 dB.
o One source ([14, 61, Ericsson]) reported that without UE power limitation of 25 dBm EIRPs (but still under regulatory limits), compared to short PRACH sequence length, longer PRACH sequence length improve MCL/MIL significantly for 120 kHz SCS due to wider bandwidth for a given SCS.
Agreement:
Capture the following observations in the TR (updates to references and other editorial modifications can be made for inclusion in the TR):
For CP-OFDM, the following are observed regarding the impact of DMRS to BLER performance.
· One source ([57, InterDigital]) reported performance improvement with increased number of DMRS symbols or increased DMRS density especially for higher modulation order for 960 kHz SCS in TDL-A (5 ns and 10 ns delay spread).
· One source ([14, Ericsson]) reported for 480 kHz SCS and below with large delay spread (TDL-A with 40 ns delay spread), the room for performance improvement with a change to the Rel-15 DMRS design is very limited.
· One source ([12, Intel]) reported a performance drop when frequency domain OCC is enabled especially for higher order modulation such as 64 QAM (MCS 22) for 960 kHz SCS in TDL-A (10ns and 20 ns delay spread) and 480 kHz SCS (20 ns delay spread). The performance gap increases when channel delay spread increases.
· One source ([26, Qualcomm]) reported performance improvement with a new DMRS pattern featured by high frequency density (i.e., every RE) and 2-FD-OCC across adjacent REs for 960 kHz SCS in TDL-A (20 ns and 40 ns delay spread)..
· One source ([10, Nokia]) reported that with Rel-15 DMRS type-1, different delay spread values (10ns and 20ns) have a negligible impact to the demodulation performance of PDSCH for a high SCS (such as 960 kHz).
Agreement:
Capture the following observations in the TR (updates to references and other editorial modifications can be made for inclusion in the TR):
7 sources ([61, Ericsson], [68, Huawei], [26, Qualcomm], [56, vivo], [64, OPPO], [10, Nokia], [21, Apple]) evaluated DFT-S-OFDM PUSCH BLER performance with different SCS.
· Compared to CP-OFDM when CPE-only compensation is enabled, DFT-s-OFDM is more robust under phase noise.
· For low and medium MCSs (QPSK and 16QAM), there’s minor performance difference among evaluated SCSs up to 960 kHz.
· With normal CP, for high MCS (64QAM), the performance improves as the increase of SCS, 120 kHz SCS shows up to ~2.0dB loss compared to other larger SCS.
o Note: the following are references when derive the observations.
o One source ([61, Ericsson]) reported a performance gap of 1.4~1.8 dB between 120 and 960 kHz SCS
o One source ([68, Huawei]) reported a performance gap of 1.3~2.5 dB between 120 and 960 kHz SCS
o One source ([26, Qualcomm]) reported a performance gap of 1.2~1.7 dB between 120 and 960 kHz SCS
o One source ([56, vivo]) reported a performance gap of ~1.4 dB between 120 and 960 kHz SCS
o One source ([10, Nokia]) did not report numerical SINR results in table but provided figures showing approximately similar performance difference (~ 2 dB) between 120 and 960 kHz SCS.
o One source ([21, Apple]) reported a performance gap of more than 7 dB performance gap between 120 kHz SCS and other SCS (240, 480 and 960 kHz) at TDL-A 5 ns DS. It also reported 120 kHz SCS cannot meet the BLER target of 10% at TDL-A 10ns DS and 960 kHz SCS cannot meet the BLER target of 10% at TDL-A 20ns DS.
o Another source ([64, OPPO]) reported 120 and 240 kHz SCS cannot meet the BLER target of 10% for all evaluated DS values.
· For high MCS (64QAM) at large delay spread (TDL-A 40ns or CDL-B 50ns DS), there’s error floor for 960 KHz SCS at least for BLER target 1%.
o Note: the following are reference when derive the observations.
o One source ([26, Qualcomm]) reported an error floor for 960 kHz SCS for BLER target 1%.
o One source ([56, vivo]) reported an error floor for 960 kHz SCS for BLER target 10%
o One source ([64, OPPO]) reported no error floor of 960 kHz SCS for the BLER target of 10% and 1% for CDL-B 50ns but an error floor for 960 kHz SCS at TDL-A 20ns for BLER target 1%
Agreement:
Capture the following observations in the TR (updates to references and other editorial modifications can be made for inclusion in the TR):
For CP-OFDM, with evaluation assumptions and parameters as in Table A.1-1 of TR 38.808, the following are observed when CPE-only compensation based on the existing Rel-15 NR PTRS structure is used for normal CP when delay spread is not large. The performance is measured in terms of SINR in dB achieving BLER target of 10% or 1%.
· For low MCS (QPSK) and medium MCS (16QAM), there is minor performance difference between different SCS values up to 960 kHz.
· For high MCS (64QAM), the performance improves in general as the increase of SCS
· For high MCS (64QAM), 13 sources ([61, Ericsson], [68, Huawei], [26, Qualcomm], [56, vivo], [60, ZTE], [64, OPPO], [10, Nokia], [2, 55, Lenovo], [21, Apple], [18, Samsung], [25, NTT DOCOMO], [12, Intel], [7, InterDigital]) compared performance of 120 and 240 kHz SCS in 400 MHz bandwidth
o for 10% BLER target, there is a performance gap between 120kHz and 240kHz SCS where 240 kHz SCS performs better.
§ Note: the following references are used when derive the observations.
§ One source ([61, Ericsson]) reported better performance of 240 kHz SCS in CDL-D. It also reported both SCS cannot meet 10% BLER target for other evaluated channel model.
§ 3 sources ([68, Huawei], [64, OPPO], [10, Nokia]) reported both SCS cannot meet 10% BLER target
§ 4 sources ([56, vivo], [60, ZTE], [21, Apple], [7, InterDigital]) reported 120 kHz SCS cannot meet 10% BLER target while 240 kHz SCS can
§ One source ([2, 55, Lenovo]) reported better performance of 240 kHz SCS at TDL-A 5 and 10ns. It also reported that both SCS cannot meet 10% BLER target for other evaluated cases.
§ One source ([12, Intel]) reported better performance of 240 kHz SCS in CDL-D. It also reported that both SCS cannot meet 10% BLER target for other evaluated cases.
§ 2 sources ([26, Qualcomm], [18, Samsung]) reported better performance of 240 kHz SCS
§ One source ([25, NTT DOCOMO]) reported comparable performance for both SCS in CDL-D. It also reported better performance of 120 kHz SCS for other evaluated channel model.
· For high MCS (64QAM), 13 sources ([61, Ericsson], [26, Qualcomm], [56, vivo], [60, ZTE], [64, OPPO], [10, Nokia], [2, 55, Lenovo], [21, Apple], [18, Samsung], [25, NTT DOCOMO], [12, Intel], [67, Charter], [7, InterDigital]) compared performance of 240 and 480 kHz SCS in 400 MHz bandwidth
o for 10% BLER target, there is a performance gap between 240kHz and 480kHz SCS where 480 kHz SCS performs better.
§ Note: the following references are used when derive the observations.
§ One source ([61, Ericsson]) reported better performance for 480 kHz SCS in CDL-D. It also reported 240 kHz SCS cannot meet 10% BLER target for other evaluated channel model.
§ 3 sources ([64, OPPO], [10, Nokia], [67, Charter]) reported 240 kHz SCS cannot meet 10% BLER target while 480 kHz SCS can
§ One source ([2, 55, Lenovo]) reported better performance of 480 kHz SCS at TDL-A 5 and 10ns. It also reported 240 kHz SCS cannot meet 10% BLER target for other evaluated cases.
§ One source ([12, Intel]) reported better performance of 480 kHz SCS in CDL-D. It also reported 240 kHz SCS cannot meet 10% BLER target for other evaluated cases.
§ 6 sources ([26, Qualcomm], [56, vivo], [60, ZTE], [21, Apple], [18, Samsung], [7, InterDigital]) reported better performance of 480 kHz SCS
§ One source ([25, NTT DOCOMO]) reported comparable performance for both SCS in CDL-D. It also reported better performance of 240 kHz SCS for other evaluated channel model.
· For high MCS (64QAM), 14 sources ([61, Ericsson], [68, Huawei], [26, Qualcomm], [56, vivo], [60, ZTE], [64, OPPO], [10, Nokia], [2, 55, Lenovo], [21, Apple], [18, Samsung], [25, NTT DOCOMO], [12, Intel], [67, Charter], [7, InterDigital]) compared performance of 480 and 960 kHz SCS in 400 MHz bandwidth
o for 10% BLER target, there is a performance gap between 480kHz and 960kHz SCS where 960 KHz SCS performs better.
§ Note: the following references are used when derive the observations.
§ 7 sources ([61, Ericsson], [60, ZTE], [64, OPPO], [10, Nokia], [2, 55, Lenovo], [67, Charter], [7, InterDigital]) reported a greater than 1 dB gain of 960 kHz SCS
§ 3 sources ([26, Qualcomm], [56, vivo], [18, Samsung]) reported a smaller than 1 dB performance gain of 960 kHz SCS
§ One source ([68, Huawei]) reported better performance of 480 kHz SCS for CDL-B 50ns and better performance of 960 kHz SCS for other evaluated cases. In all comparison, the difference is greater than 1 dB.
§ Two sources ([21, Apple], [12, Intel]) reported a better performance of 480 kHz SCS than 960 kHz SCS at 20ns DS in TDL-A where 960 kHz SCS cannot meet 10% BLER target and comparable performance for both SCS in all other evaluated cases
§ One source ([25, NTT DOCOMO]) reported comparable performance for both SCS in CDL-D. It also reported better performance of 480 kHz SCS in TDL-A 5ns and better performance of 960 kHz SCS in CDL-B 20ns.
o for 1% BLER target, the performance for 960kHz SCS is better than 480kHz SCS.
§ Among sources reported SINR values when both SCS can meet 1% BLER target, the absolute value of the performance gap between 480 kHz and 960 kHz SCS is larger than that for 10% BLER target.
· For high MCS (64QAM), 4 sources ([61, Ericsson], [56, vivo], [10, Nokia], [18, Samsung]) compared performance of 480 and 960 kHz SCS in 1600 or 2000 MHz bandwidth. 4 out of 4 sources reported performance gain around 4 ~ 5 dB of 960 kHz SCS for 10% BLER target. All 4 sources also reported that 480 kHz SCS cannot meet 1% BLER target.
Agreement:
Capture the following observations in the TR (updates to references and other editorial modifications can be made for inclusion in the TR):
For CP-OFDM, with evaluation assumptions and parameters as in Table A.1-1 of TR 38.808 (including optional delay spread value), the following are observed when CPE-only compensation based on the existing Rel-15 NR PTRS structure is used with respect to CP type and large delay spread.
· When delay spread is not large (< 40 ns in TDL-A), there is minor performance difference between normal and extended CP for SCS values up to 960 kHz when compared on the basis of equal MCS (code rate). If comparing on the basis of equal TBS (equal throughput), the performance of ECP is degraded due to higher overhead of ECP.
· Among 11 sources ([61, Ericsson], [68, Huawei], [26, Qualcomm], [56, vivo], [60, ZTE], [64, OPPO], [2, 55, Lenovo], [1, Futurewei], [25, NTT DOCOMO], [12, Intel], [7, InterDigital]) evaluated with large delay spread (i.e. 40 ns in TDL-A and/or 50ns in CDL) based on the existing Rel-15 NR PTRS structure for normal CP, 10 sources observed that for low MCS (QPSK) and medium MCS (16QAM), there is minor performance difference between different SCS values up to 960kHz for 10% BLER target
o The other source ([1, Futurewei]) evaluated SCS 960 kHz with CPE compensation at MCS16 with normal CP in TDL-A channel with 40ns DS. It reported that the BLER for SCS 960 kHz, MCS16, and Normal CP is not acceptable (cannot meet 10% BLER target) for 40ns DS.
· 10 sources ([61, Ericsson], [68, Huawei], [26, Qualcomm], [56, vivo], [60, ZTE], [64, OPPO], [2, 55, Lenovo], [25, NTT DOCOMO], [12, Intel], [7, InterDigital]) evaluated large delay spread (i.e. 40 ns in TDL-A and/or 50ns in CDL) with CPE compensation based on the existing Rel-15 NR PTRS structure with normal CP. Among 10 sources, 5 sources ([14, Ericsson], [68, Huawei], [5, 56, vivo], [2, 55, Lenovo], [25, NTT DOCOMO]) also evaluated extended CP at least for 960 kHz SCS with CPE compensation based on the existing Rel-15 NR PTRS structure.
o 9 out 10 sources observed that for high MCS (64QAM) with normal CP, larger SCS (480 and 960 kHz) performs better than smaller SCS (120 and 240 kHz) when only CPE compensation based on the existing Rel-15 NR PTRS structure is used. The other source ([25, NTT DOCOMO]) reported better performance of smaller SCS.
o 5 out 5 sources observed the performance of 960 kHz SCS with extended CP is significantly improved compared to with normal CP for large delay spread case when compared on the basis of equal MCS (code rate).
o 4 sources ([14, Ericsson], [68, Huawei], [5, vivo], [2, 55, Lenovo]) compared throughput of normal CP and extended CP at least for 960 kHz SCS with CPE compensation based on the existing Rel-15 NR PTRS structure. They all reported worse throughput of extended CP.
Agreement:
· Capture the following observations in the TR (updates to references and other editorial modifications can be made for inclusion in the TR):
· For CP-OFDM, the following are observed with respect to phase noise compensation and PTRS.
· Compared to no phase noise compensation, CPE compensation shows little gain at low and medium MCSs for all the evaluated SCS values; while significant gain is observed for high MCS (64QAM) for all the evaluated SCS values.
o Two sources ([57, InterDigital], [11, Mitsubishi])) reported that increased PTRS density in frequency domain based on Rel-15 configuration does not provide significant performance benefits.
· For a given SCS, the complexity of ICI compensation increases as the number of ICI filter tap increases
· For MCS 22 evaluation of the same SCS, performance gain of ICI compensation with additional complexity of multi-tap filtering compared to CPE-only compensation is observed when there is sufficient number of PTRS in the frequency domain for 120, 240 and 480 kHz SCS.
o Note: the following references are used when derive the observations.
o One source ([61, Ericsson]) showed performance gain of ICI compensation compared to CPE-only compensation for all evaluated SCS
o One source ([68, Huawei]) evaluated ICI compensation and compared with CPE-only compensation. It reported performance gain for all evaluated SCS.
o One source ([26, Qualcomm]) compared the performance of CPE and ICI compensation for 120 kHz SCS reported performance gain of ICI compensation.
o One source ([64, OPPO]) compared the performance of CPE and ICI compensation for all SCS. It reported performance gain of ICI compensation for 240 kHz and 480 kHz SCS. It reported performance gain of ICI compensation in CDL-B but a performance loss in TDL-A for 960 kHz SCS. It also reported that 120 kHz SCS still cannot meet 10% BLER target with ICI compensation.
o One source ([10, Nokia]) reported performance gain of ICI compensation for 120, 240 and 480 kHz SCS. It also reported performance gain of ICI compensation for 960 kHz SCS at 2GHz bandwidth and a performance loss of ICI compensation for 960 kHz SCS at 400MHz bandwidth.
o One source ([65, Apple]) evaluated ICI compensation for different SCS with a new PTRS pattern. It reported improvement of ICI compensation compared to CPE-only compensation.
o One source ([18, Samsung]) evaluated 120 kHz and 240 kHz SCS performance with ICI compensation based on some new PTRS pattern and reported performance improvement.
o One source ([1, Futurewei]) compared ICI performance among SCS. It reported performance gain of multi-tap ICI filter over CPE compensation for 120, 240 and 480 kHz SCS
o One source ([12, Intel]) evaluated performance of de-ICI method for MCS 22 with small RB allocations for 240, 480 and 960 KHz SCS. It is observed that the de-ICI method do not work when there isn’t sufficient number of PTRS tones in the frequency domain.
· For MCS 22 with normal CP when delay spread is not large, it is observed that ICI compensation of multi-tap filtering is required for 120, 240 and/or 480 kHz SCS to achieve comparable performance (< 1 dB difference) to that of 960 kHz SCS with CPE-only compensation for 10% BLER target
o Note: the following references are used when derive the observations.
o 2 sources ([61, Ericsson], [10, Nokia]) reported comparable performance of 480 kHz SCS with ICI compensation and 960 kHz SCS with CPE compensation in 1600 MHz bandwidth
o 2 sources ([64, OPPO], [10, Nokia]) reported comparable performance of 480 kHz SCS with ICI compensation and 960 kHz SCS with CPE compensation in 400 MHz bandwidth
o One source ([68, Huawei]) reported comparable performance of 240 kHz SCS with ICI compensation and 960 kHz SCS with CPE compensation in 400 MHz bandwidth
o One source ([26, Qualcomm]) evaluated and compared 120 KHz SCS with ICI compensation to larger SCS with CPE compensation. It reported that at MCSs 22 and 24, 120 kHz SCS with ICI compensation performs almost equal to 960 kHz SCS with CPE-only compensation in 400 MHz bandwidth.
o One source ([1, Futurewei]) reported comparable performance of 480 kHz SCS with ICI compensation and 960 kHz SCS with CPE compensation in TDL-A 5 and 10ns as well as in CDL-D 30ns in 400 MHz bandwidth.
· At very high MCS (e.g., MCS 26 or MCS 28), three sources ([12, Intel], [26, Qualcomm], [69, Huawei]) compared ICI and CPE compensation using the Rel-15 PTRS.
o Note: the following references are used when derive the observations.
o One source ([12, Intel]) evaluated the phase noise compensation performance with MCS 28 when delay spread is not large. It is observed that de-ICI technique with 3-taps filter for smaller subcarrier spacing (240 kHz) fails even though there are sufficient number of PTRS tones available for ICI covariance construction.
o One source ([26, Qualcomm]) compared the performance of CPE and ICI compensation and reported for MCS 26, 120kHz SCS with ICI compensation suffers from residual ICI and is outperformed by 960kHz SCS with CPE-only compensation when delay spread is not large.
o One source ([68, Huawei]) showed that for MCS 28, de-ICI technique with large number of taps (11, 9 and 7 taps for 120, 240 and 480 kHz SCS respectively) outperforms 960 kHz with CPE compensation only when delay spread is not large. For normal CP, it also reported that 960 kHz with 3-tap ICI compensation has comparable performance to other SCS with larger number of taps (11, 9 and 7 taps for 120, 240 and 480 kHz SCS respectively) for MCS 28 when delay spread is not large. It also reported that with large delay spread (50ns in CDL), ECP and ICI compensation with at least 3 taps filter are needed for 960 kHz SCS to reach 1% BLER target for MCS 26.
· For high MCS (64QAM) with normal CP when delay spread is large (TDL-A with 40 ns and/or CDL-B with 50ns), 4 sources compared performance of smaller SCS (120, 240 and/or 480 kHz) with ICI compensation to that of 960 kHz SCS with CPE compensation and reported worse performance of 960 kHz SCS with CPE compensation for 10% BLER target.
o Note: the following are references used when derive the observations.
o One source ([61, Ericsson]) reported a performance gain of 5 dB in TDL-A 40ns and 0.3 dB in CDL-B 50ns for 480 kHz SCS with ICI compensation compared to 960 kHz SCS with CPE compensation in 1600 MHz bandwidth
o One source ([68, Huawei]) reported a performance gain of 2.6 dB (for 240 kHz SCS) and 1.6 dB (for 120 kHz SCS) in CDL-B 50ns with ICI compensation compared to 960 kHz SCS with CPE compensation
o One source ([64, OPPO]) reported a performance gain of 1 dB in CDL-B 50ns for 480 kHz SCS with ICI compensation compared to 960 kHz SCS with CPE compensation. It also reported the performance of 120 kHz with ICI compensation cannot meet the 10% BLER target.
o One source ([1, Futurewei]) reported the performance of 960 kHz SCS with CPE compensation cannot meet the 10% BLER target. It also reported that the performance of 480 kHz SCS with ICI compensation cannot meet the 10% BLER target in TDL-A 40ns. With ICI compensation, it also reported comparable performance of 120, 240 and 480 kHz SCS in CDL-B 50ns and comparable performance of 120 and 240 kHz SCS in TDL-A 40ns.
· Multiple sources evaluated and compared ICI compensation schemes using the existing Rel-15 NR distributed PTRS structure and/or new PTRS patterns. The results from different sources are not aligned on whether new PTRS patterns perform better than existing Rel-15 PTRS structure when ICI compensation is used.
o Note: the following are reference used when derive the observations.
o One source ([11, Mitsubishi]) evaluated with 120 and 240 kHz SCS and reported that the PN compensation with block-based PTRS and cyclic sequence significantly outperforms in spectral efficiency both CPE compensation and de-ICI Wiener filtering with distributed PTRS, even when the density of the scattered pattern is increased above the Rel.15 defined density.
o One source ([14, Ericsson]) reported that 3-tap direct de-ICI compensation with Rel-15 PTRS outperforms ICI filter approximation approach with clustered PTRS. 3-tap direct de-ICI compensation with a clustered PTRS structure does not offer any performance advantage over the existing Rel-15 NR distributed PTRS structure.
o One source ([23, MediaTek]) reported that with a 3-tap BLS ICI equalizer, a clustered PTRS structure does not offer any performance advantage over the existing Rel-15 NR distributed PTRS structure.
o One source ([62, LG]) reported that the performance of clustered PTRS allocation is worse than that of Rel-15 PTRS based ICI compensation scheme and further showed that the performance of subcarrier nulling allocation is similar or superior (up to 2 dB gain especially in the scenarios with low PTRS overhead, K=4) to that of Rel-15 PTRS based ICI compensation scheme.
o Two sources ([18, Samsung], [65, Apple]) evaluated the performance with some new PTRS patterns (e.g. chunk based PTRS pattern to allow adjacent PTRS symbols in frequency) and reported that the performance with ICI compensation based on new PTRS patterns is better than the Rel-15 pattern with CPE compensation only.
o One source ([26, Qualcomm]) reported that for the same ICI compensation algorithm, the legacy PTRS pattern outperforms the block PTRS pattern. It showed that for ICI compensation (direct de-ICI filtering) with the legacy PTRS pattern, the performance improves with the increasing number of de-ICI filter taps (3 to 5 taps). It also observed that with a fixed transport block size, the performance improves as the PTRS overhead decreases (the performance loss due to increased effective code rate is more pronounced at higher MCSs) and with a fixed effective code rate, the performance slightly improves as the PTRS overhead increases.
· For high MCS (64QAM) with normal CP, 2 sources ([61, Ericsson], [10, Nokia]) compared performance of 480 and 960 kHz SCS in 1600 MHz bandwidth when ICI compensation is used based on Rel-15 PTRS.
o When delay spread is not large, both sources reported a smaller than 1 dB performance gain of 960 kHz SCS for both 10% and 1% BLER target in TDL-A. One source ([61, Ericsson]) reported that for CDL-B, there is up to 1.1 dB gain at 1% BLER target for 960 kHz SCS.
o When delay spread is large (TDL-A with 40 ns DS), one source ([61, Ericsson]) reported 480 kHz SCS performed 3.6 dB better than 960 kHz SCS at 10% BLER target and 960 kHz SCS cannot meet the 1% BLER target.
Agreement:
Capture the following observations in the TR (updates to references and other editorial modifications can be made for inclusion in the TR):
For CP-OFDM, two sources ([14, 61, Ericsson], [68, Huawei]) evaluated PDSCH BLER performance with optional PN models in addition to PN model in Table A.1-1 of TR 38.808. Note that such optional PN models are not confirmed and/or recommended by RAN4 at the time of RAN1#103-e (These observations can be updated if RAN4 input is available).
· When CPE-only compensation is used with an optional PN model at the UE or at BS and UE, it is observed by both sources that there is significantly less dependence of BLER performance on SCS compared to the PN model in Table A.1-1 of TR 38.808. For all test cases, no error floor is observed for smaller SCS with TDL-A or CDL-B/CDL-D for 1% BLER target. There is around 1 to 2 dB performance difference between consecutive SCSs for 1% BLER target.
· However, multiple sources expressed concerns on the validity of such optional PN models given no confirmation and/or recommendation from RAN4. In consequence, there’s a concern on whether and how the observations based on such optional PN models can be used given no RAN4 input on these optional PN models.
Agreement:
· Update BS Antenna Pattern in Table A.2-1 of TR 38.808 as follows.
|
BS Antenna Pattern |
For outdoor scenarios: - Antenna power pattern given in Table 7.3-1 of TR38.901 (with exception of antenna element gain)
For indoor - Antenna power pattern given in Table A.2.1-7 of TR38.802 for ceiling mount (with exception of antenna element gain)
For factory scenarios: Companies to provide information on the antenna orientation and pattern used. |
Agreement:
· Update the indoor A description as follows:
Office box 120m x 50 m, 12 BS per operator, 2 operator, BS height at 3m (ceiling), UE height 1m, x-axis ISD = 20m and y-axis ISD = 25m, where ISD is define by the distance between two adjacent 10m x 10m virtual box, BS randomly deployed within 10m x 10m virtual box, minimum distance between BS of different operators is 2m.”
[103-e-NR-52-71GHz-Eval_results] – Huaming/Jing (vivo/Qualcomm)
Email discussion/approval on collection of simulation results until 11/6
R1-2009356 Collection of evaluation results on supporting NR from 52.6 GHz to 71 GHz Moderator (vivo, Qualcomm)
Agreement:
· Section 2 of R1-2009356 is endorsed for inclusion in the TR (formatting and other minor errors can be corrected when including in the TR).
Please refer to RP-202925 for detailed scope of the WI
R1-2102192 Session notes for 8.2 (Study on supporting NR from 52.6 GHz to 71 GHz) Ad-Hoc Chair (Ericsson)
Including SSB, initial BWP, PRACH, etc.
R1-2101194 Initial access aspects for NR from 52.6 GHz to 71 GHz Samsung
· Proposal 1: Support 480 kHz SCS and 960 kHz SCS for SS/PBCH block after initial access.
· Proposal 2: Whether extra SCS can be supported for SS/PBCH block in initial access depends on the synchronization raster interval.
o If any of 480 kHz or 960 kHz SCS is supported as default SCS of SS/PBCH block in initial access, the CORESET#0 configuration corresponding to the same SCS as SS/PBCH block should be supported.
· Proposal 3: Support new SS/PBCH block pattern for 480 kHz and 960 kHz SCSs.
o At least one symbol should be reserved between neighboring SS/PBCH block for beam sweeping delay.
o Symbols should be reserved for CORESET and HARQ with same SCS as SS/PBCH block.
· Proposal 4: For COREST#0,
o if synchronization raster interval is larger than FR2, additional CORESET#0 RB offsets are needed for 120 kHz SS/PBCH block SCS;
o if 480 kHz and/or 960 kHz SS/PBCH block SCS is supported, at least CORESET#0 configuration table with same SCS as SS/PBCH block should be supported;
o if there are reserved configurations, both multiplexing Pattern 2 and Pattern 3 can be supported in a CORESET#0 configuration table;
o if CORESET#0 bandwidth can be increased, 96 RB can be added to the CORESET#0 configuration table for 120 kHz SS/PBCH block SCS.
· Proposal 5: Discovery burst transmission window should be supported for 60 GHz unlicensed band.
· Proposal 6: Support short PRACH format for all PRACH sequence
lengths 
and all SCSs 
, and
don’t support long PRACH format.
· Proposal 7: Using the RO pattern for SCS = 120 kHz derived from the PRACH configuration table as the reference for larger SCS cases.
· Proposal 8: For RO configuration, both direction 1 (indication on which one(s) of the 8 eighty-slots) and direction 2 (keep 80slots in total but redesign the RACH period and RACH duration location) can be considered.
· Proposal 9: Support non-consecutive RO configuration to alleviate the RACH LBT failure.
Decision: The document is noted.
R1-2101453 Initial access aspects for NR in 52.6 to 71GHz band Qualcomm Incorporated
Proposal 1: for the SSB for NR operation in the frequency between 52.6GHz and 71GHz:
- Use SCS = 120 kHz and 240 kHz for SA mode
o FFS for 480 kHz and 960 kHz
- Use SCS = 120 kHz, 240 kHz, 480 kHz, and 960 kHz for NSA mode
Proposal 2: study the following for different SSB SCSs:
- UE initial search complexity (for SA and NSA modes)
- The effect of the initial search timing resolution on the performance of channels with high SCS (480 and 960 kHz)
Proposal 3: for the SSB for NR operation in the frequency between 52.6GHz and 71GHz and SCS = 480 kHz and 960 kHz, consider defining an SSB pattern consisting of multiple “SSB slots” where SSB symbols for one or more beams are contained in the “SSB slot”
- A beam switching gap of 1 symbol is inserted between SSBs within the “SSB slot”
- Additional control symbols may be defined in the SSB slots with beam switching gaps between control and SSB symbols of different beams
- Additional “gap slots” may be inserted between “SSB slots” to account for URLLC and UL traffic
Proposal 4: consider the following SSB and CORESET0 SCS combinations:
- SSB SCS = 120 kHz, CORESET0 SCS = 120, 480, 960 kHz
- SSB SCS = 240 kHz, CORESET0 SCS = 120 kHz
- SSB SCS = 480/960 kHz, CORESET0 SCS = SSB SCS
Proposal 5: consider ways to have 1 extra bit to indicate the common SCS in the SSB structure or contents in case more than 2 values for the common SCS are allowed
Proposal 6: NR Rel-16 SSB/CORESET0 multiplexing pattern 1 design may be reused with possibly some changes to the table (e.g., the need for < 2.5 ms options for the start of the CORESET0 wrt frame boundary) which depends on the outcome of the SSB pattern design
Proposal 7: SSB/CORESET0 multiplexing pattern 2:
- For the 240 kHz + 120 kHz combination: reuse the same design as in NR Rel-16
- For the 120 kHz + 480/960 kHz combination: the CORESET0 symbols may be placed in the gap symbols between the SSBs (similar to the existing NR Rel-16 design)
Proposal 8: NR Rel-16 SSB/CORESET0 multiplexing pattern 3 design may be reused for the valid combinations of 120 + 120 kHz, 480 + 480 kHz, and 960 + 960 kHz
Proposal 9: consider introducing an SSB/CORESET0 multiplexing pattern for higher SCS SSB (480 and 960 kHz), where a time domain fixed location for the CORESET0 and SIB1 is considered
Proposal 10: consider introducing an SSB/CORESET0 multiplexing pattern for higher SCS SSB (480 and 960 kHz), where TDM grouping of the SSB and the corresponding CORESET0/SIB1 is considered
Proposal 11: consider using the following for the PRACH preamble sequence lengths for higher bands:
- SCS = 120 kHz: 139 and 571
- SCS = 480/960 kHz: 139 only
Proposal 12: for higher bands consider reusing the PRACH formats defined in NR Rel-16 (with appropriate SCS scaling)
Proposal 13: a maximum of 4 FD multiplexed ROs for SCS = 120 kHz and sequence length = 571. For all other SCS and sequence length combinations, a maximum of 8 FD multiplexed ROs can be used
Proposal 14: for higher RACH SCS (480 and 960 kHz), consider including a symbol-level gap between ROs to allow for gNB beam switching delay
Proposal 15: for higher RACH SCS (480 and 960 kHz), consider including a symbol-level gap between POs to allow for gNB beam switching delay
Proposal 16: for higher RACH SCS (480 and 960 kHz), consider the following options for the RA-RNTI:
-
Option
A: using the following equation for the RA-RNTI calculations (
is the maximum 
for the FR used) and defining rules in
case RA-RNTI conflicts with pre-allocated RNTIs or in case multiple ROs have
the same RA-RNTI
o RA-RNTI = (1 + s_id + 14 × t_id + 14 × 
× f_id + 14 × × 8 × ul_carrier_id) mod 216
- Option B: reuse the same RA-RNTI equation in NR Rel-16, divide the RAR window into N segments (each segment is 80 slots using the used SCS), and signal the segment index in the DCI that schedules the MSG2/B
Decision: The document is noted.
R1-2100051 Considerations on initial access for additional SCS in Beyond 52.6GHz FUTUREWEI
R1-2100057 Initial access enhancements for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2100073 Discussion on the initial access aspects for 52.6 to 71GHz ZTE, Sanechips
R1-2100149 Discusson on initial access aspects OPPO
R1-2100200 Initial access signals and channels for 52-71GHz band Huawei, HiSilicon
R1-2100257 Initial access aspects Nokia, Nokia Shanghai Bell
R1-2100299 Some views on initial access aspects for 52.6-71GHz CAICT
R1-2100370 Initial access aspects for up to 71GHz operation CATT
R1-2100429 Discussions on initial access aspects for NR operation from 52.6GHz to 71GHz vivo
R1-2100541 Initial access aspects TCL Communication Ltd.
R1-2100607 Initial access aspects for NR operations in 52.6-71 GHz MediaTek Inc.
R1-2100643 Discussion on initial access aspects for extending NR up to 71 GHz Intel Corporation
R1-2100740 Considerations on initial access for NR from 52.6GHz to 71 GHz Fujitsu
R1-2100781 Further Discussion of Initial Access Aspects AT&T
R1-2100825 Discussion on initial access aspects for NR from 52.6GHz to 71GHz Spreadtrum Communications
R1-2100836 Discussions on initial access aspects InterDigital, Inc.
R1-2100892 Initial access aspects to support NR above 52.6 GHz LG Electronics
R1-2100939 Discussion on initial access aspects supporting NR from 52.6 to 71GHz NEC
R1-2101109 On initial access aspects for NR from 52.6GHz to 71GHz Xiaomi
R1-2101286 Discussion on Initial access aspects for NR beyond 52.6 GHz CEWiT
R1-2101306 Initial Access Aspects Ericsson
R1-2101372 On Initial access signals and channels Apple
R1-2101417 Consideration for NR Initial Access from 52.6 GHz to 71 GHz Convida Wireless
R1-2101605 Initial access aspects for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2101672 Discussion on initial access aspects for NR beyond 52.6GHz WILUS Inc.
R1-2101826 Issue Summary for initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
[104-e-NR-52-71GHz-01] – Daewon (Intel)
Email discussion/approval on initial access aspects with checkpoints for agreements on Jan-28, Feb-02, Feb-05
R1-2101827 Summary #1 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
R1-2101905 Summary #2 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
Decision: From GTW session on Jan 29th,
Proposal:
· Support 480kHz and 960kHz SSB SCS when center frequency and SCS of SSB is explicitly provided to the UE
· FFS: support one or more of 240, 480, 960 kHz SCS SSB for other cases
· FFS: support 240 kHz SCS SSB for access cases when center frequency and SCS of SSB is explicitly provided to the UE
Agreement:
Send an LS to RAN4 to get input on gap required for gNBs and UEs for beam switching and for UL/DL and DL/UL switching.
R1-2102073 [Draft] LS on beam switching gap for 60 GHz band Intel Corporation
Decision: The draft LS is endorsed. Final LS is approved in R1-2102202.
R1-2101970 Summary #3 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
Agreement:
Whether or not to support 240 kHz, 480kHz and 960kHz SCS for SSB and the conditions under which SSB for 240 kHz, 480 kHz and 960 kHz may be supported will be decided no later than RAN1#104bis-e.
Agreement:
For an unlicensed band that requires LBT, further study whether/how to support discovery burst (DB) and discovery burst transmission window (DBTW) at least for 120 kHz SSB SCS
· If DB supported
o FFS: What signals/channels are included in DB other than SS/PBCH block
· If DBTW is supported
o Support mechanism to indicate or inform that DBTW is enabled/disabled for both IDLE and CONNECTED mode UEs
§ FFS: how to support UEs performing initial access that do not have any prior information on DBTW.
o PBCH payload size is no greater than that for FR2
o Duration of DBTW is no greater than 5 ms
o Number of PBCH DMRS sequences is the same as for FR2
· The following points are additionally FFS:
o How to indicate candidate SSB indices and QCL relation without exceeding limit on PBCH payload size
o Details of the mechanism for enabling/disabling DBTW considering LBT exempt operation and overlapping licensed/unlicensed bands
o Whether or not to support DBTW for SSB SCS(s) other than 120 kHz if other SSB SCS(s) are supported
R1-2101971 Summary #4 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
Decision: As per email posted on Feb 6th,
Agreement:
For CORESET#0 and Type0-PDCCH search space configured in MIB:
· Support {SS/PBCH Block, CORESET#0 for Type0-PDCCH} SCS equal to {120, 120} kHz
o Support at least SSB and CORESET#0 multiplexing patterns, number of RBs for CORESET#0, number of symbols (duration of CORESET#0) that are supported in Rel-15/16 for {SS/PBCH Block, CORESET#0 for Type0-PDCCH} SCS = {120, 120} kHz.
§ FFS: Supporting additional values
o FFS: Supported values for SSB to CORESET#0 offset RBs
· If 480kHz SSB SCS that configures CORESET#0 and Type0-PDCCH CSS in MIB is agreed to be supported,
o Support {SS/PBCH Block, CORESET#0 for Type0-PDCCH} SCS equal to {480, 480} kHz
· If 960 kHz SSB SCS that configures CORESET#0 and Type0-PDCCH CSS in MIB is agreed to be supported,
o Support {SS/PBCH Block, CORESET#0 for Type0-PDCCH} SCS equal to {960, 960} kHz
· If 240 kHz SSB SCS is agreed to be supported,
o Support {SS/PBCH Block, CORESET#0 for Type0-PDCCH} SCS equal to {240, 120} kHz
· FFS: any other combinations between one of SSB SCS (120, 240, 480, 960) and one of CORESET#0 SCS (120, 480, 960)
o FFS: initial timing resolution based on low SCS (120 kHz) and its impact on the performance of higher SCS (480/960 kHz)
Agreement:
For 480 kHz and 960 kHz SSB SCS (if agreed)
· Study further on reserving symbol gap between SSB positions with different SSB index (and possibly between SSB position and other signal/channels)
o FFS: whether symbol gap is needed for only 960 kHz or both 480 and 960 kHz.
· Study further on reserving gap for UL/DL switching within the pattern accounting possibility for reserving UL transmission occasions in the SSB pattern
· Study should account for inputs from RAN4
Agreement:
· For initial access and non-initial access use cases, support 120kHz PRACH SCS with sequence length L=571, 1151 (in addition to L=139) for PRACH Formats A1~A3, B1~B4, C0, and C2.
· For non-initial access use cases,
o if 480kHz and/or 960 kHz SSB SCS is agreed to be supported, support 480 and/or 960 kHz PRACH SCS with sequence length L=139 for PRACH Formats A1~A3, B1~B4, C0, and C2, respectively.
§ FFS: support of sequence length L = 571, 1151
· FFS: Support of 480 and/or 960 kHz PRACH SCS for initial access use cases, if 480 and/or 960 kHz SSB SCS is agreed to be supported for initial access
Agreement:
If 480 and/or 960 kHz PRACH SCS is supported, RAN1 should study whether or not the current RA-RNTI calculation and PRACH identification in RAR correctly provides unique identification of PRACH.
Final summary in R1-2102238.
R1-2100430 Discussions on PDCCH monitoring enhancements for NR operation from 52.6GHz to 71GHz vivo
· Proposal 1: For NR operation from 52.6-71GHz, PDCCH monitoring capability in FR1&FR2 should be relaxed from slot level to multi-slot level granularity.
· Proposal 2: To support multi-slot level granularity for PDCCH monitoring capability definition, how to determine multi-slot span pattern should be considered, e.g. fixed or flexible multi-slot pattern.
· Proposal 3: For NR operation from 52.6-71GHz, UE is expected to be mandatory to monitor PDCCH in the first slot of each fixed multi-slot span where the PDCCH monitoring occasions within the slot satisfy the following conditions:
o The duration of coreset associated with the PDCCH monitoring occasions is 1-3 symbols;
o For type 1 CSS with dedicated RRC configuration, type 3 CSS, and USS, the monitoring occasion is within the first 3 OFDM symbols of the slot;
o For type 1 CSS without dedicated RRC configuration and for type 0, 0A, and 2 CSS, the monitoring occasion can be any OFDM symbol(s) of the slot, with the monitoring occasions within a single span of three consecutive OFDM symbols within the slot.
· Proposal 4: For NR operation from 52.6-71GHz, flexible multi-slot span pattern could be considered for definition of optional PDCCH monitoring capability.
· Proposal 5: For a DL BWP with 120KHz SCS in 52.6-71GHz, UE derives the BD/CCE budget as the same as that for 120KHz in FR2 including the budget value.
· Proposal 6: For a DL BWP with 480KHz and 960KHz SCS in 52.6-71GHz, the BD/CCE budget value per slot per serving cell should be determined based on practical UE implementation complexity.
· Proposal 7: For a DL BWP with 480KHz and 960KHz SCS in 52.6-71GHz, the BD/CCE budget value per multi-slot span per serving cell should be defined and it is used for single cell operation scenario.
· Proposal 8: For multi-cell operation, the categorization of scheduling cells to be applied with a total BD/CCE limit should consider PDCCH SCS and BD/CCE limit granularity jointly.
Decision: The document is noted.
R1-2100644 Discussion on PDCCH monitoring enhancements for extending NR up to 71 GHz Intel Corporation
· Proposal 1: On the PDCCH monitoring occasion in a slot
o Case 1-1 is supported for all SCS 120kHz, 480kHz and 960kHz
o Case 2 is supported for SCS 120kHz
o Case 2 is not supported for SCS 480/960kHz
· Proposal 2: Within a period of a SS set configuration
o The parameter ‘duration’ is reinterpreted as a window on which MOs may be configured.
o One slot in every N slots is configured with PDCCH MOs
· Proposal 3: A SS set can be configured with
o DCI format 0_0/0_1, or
o Normal DCI formats for single-TTI scheduling, or
o Normal DCI formats for multi-TTI scheduling
§ FFS separate configuration for multi-PDSCH scheduling and multi-PUSCH scheduling
· Proposal 4: Cross-carrier scheduling of cell with 52.6-71GHz frequency from/to a cell of FR1 and FR2 is allowed by specification, however, additional enhancements are deprioritized unless a clear motivation is identified.
· Proposal 5: Span of 2 or 3 symbols as defined in eURLLC is not supported in 52.6-71GHz frequency
· Proposal 6: To support multi-slot span based UE capability on maximum numbers of BDs/CCEs
o There is no further limitation on maximum numbers of BDs/CCEs in a slot
o The number of slots in a multi-slot span can be configured by RRC, potential values 1, 2, 4, 8
§ FFS: Certain value may not be applicable to a SCS
o FFS: if multi-slot span can be configured for SCS 120kHz
· Proposal 7: It is necessary to pose certain limitation on the BDs/CCEs in two adjacent/consecutive slots that belong to different multi-slot spans.
· Proposal 8: PDCCH overbooking applies per multi-slot span,
o For PCell or PSCell, it is allowed that the configured number of BDs/CCEs in a multi-slot span by the configuration of SS set(s) is larger than the corresponding maximum numbers. Certain dropping rule is defined so that the actual number in the multi-slot span doesn’t exceed the corresponding maximum numbers.
o For a SCell, the gNB should guarantee that the configured numbers of BDs/CCEs in a multi-slot span by the configuration of SS set(s) do not exceed the corresponding maximum numbers.
· Proposal 9: A UE does not expect a CSS set will be dropped in PDCCH overbooking
· Proposal 10: To handling USS dropping in PDCCH overbooking
o A USS set with largest SS set index is dropped
o If the PDCCH MOs of a USS set are configured in multiple slots in the multi-slot span, the USS set in all the multiple slots is dropped slot by slot.
Decision: The document is noted.
R1-2100058 PDCCH monitoring enhancements for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2100074 Discussion on the PDCCH monitoring enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2100150 Discussion on PDCCH monitoring OPPO
R1-2100241 Enhancement on PDCCH monitoring Huawei, HiSilicon
R1-2100258 PDCCH monitoring enhancements Nokia, Nokia Shanghai Bell
R1-2100371 PDCCH monitoring enhancements for up to 71GHz operation CATT
R1-2100608 PDCCH monitoring enhancement for 52.6-71 GHz NR operation MediaTek Inc.
R1-2100817 Discussion on PDCCH monitoring enhancement for NR beyond 52.6 GHz Spreadtrum Communications
R1-2100837 Discussions on PDCCH monitoring enhancements InterDigital, Inc.
R1-2100851 PDCCH enhancement for NR from 52.6GHz to 71GHz Sony
R1-2100893 PDCCH monitoring enhancements to support NR above 52.6 GHz LG Electronics
R1-2101110 PDCCH monitoring enhancement for NR 52.6-71GHz Xiaomi
R1-2101195 PDCCH monitoring enhancements for NR from 52.6 GHz to 71 GHz Samsung
R1-2101307 PDCCH Monitoring Enhancements Ericsson
R1-2101321 Discussion on PDCCH monitoring enhancements for NR above 52.6GHz CEWiT
R1-2101373 PDCCH monitoring enhancements for NR between 52.6GHz and 71 GHz Apple
R1-2101418 Consideration for PDCCH Monitoring for Supporting NR from 52.6 GHz to 71 GHz Convida Wireless
R1-2101454 PDCCH monitoring enhancements for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2101606 PDCCH monitoring enhancements for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
[104-e-NR-52-71GHz-02] – Alex (Lenovo)
Email discussion/approval on PDCCH monitoring enhancements with checkpoints for agreements on Jan-28, Feb-02, Feb-05
R1-2101874 Feature lead summary for [104-e-NR-52-71GHz-02] Email discussion/approval on PDCCH monitoring enhancements Moderator (Lenovo)
Decision: From GTW session on Jan 29th,
Agreement:
Choose one of the following alternatives for defining the multi-slot PDCCH monitoring capability
· Alt 1: A fixed pattern of N slots.
· Alt 2: Use the Rel-16 capability (pdcch-Monitoring-r16, (X, Y) span) as the baseline to define the new capability
o FFS: Values of X and Y and units in which they are defined
o FFS: Whether number of slots within which the number of monitoring occasions is counted is needed and if needed, the value of the number of slots
· Alt 3: A sliding window of N slots for defining multi-slot PDCCH monitoring capability.
o FFS: Increments in which sliding occurs
· Specific numbers for X, Y and N may depend on UE capability and gNB configuration
o Examples:
§ N = [4] slots for 480 kHz SCS and N = [8] slots for 960 kHz SCS
§ X = [4] slots for 480 kHz SCS and X = [8] slots for 960 kHz SCS
R1-2102142 Feature lead summary#2 for [104-e-NR-52-71GHz-02] on PDCCH monitoring enhancements Moderator (Lenovo)
Decision: As per email posted on Feb 5th, no additional proposals are stable enough for consensus. All proposals are gathered in the final summary as starting point for further discussion in next meeting.
R1-2102242 Feature lead summary#3 for [104-e-NR-52-71GHz-02] on PDCCH monitoring enhancements Moderator (Lenovo)
R1-2100059 Enhancements to PUCCH formats 0/1/4 for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2100075 Discussion on the PUCCH enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2100151 Discussion on enhancements for PUCCH format 0/1/4 OPPO
R1-2100239 Enhancement on PUCCH formats Huawei, HiSilicon
R1-2100259 Enhancements for PUCCH formats Nokia, Nokia Shanghai Bell
R1-2100372 Enhancements for PUCCH formats for up to 71GHz operation CATT
R1-2100431 Discussions on PUCCH enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2100487 Discussion on PUCCH Channel enhancements FUTUREWEI
R1-2100609 PUCCH formats 0/1/4 enhancement for 52.6-71 GHz NR operation MediaTek Inc.
R1-2100645 Discussion on PUCCH enhancements for extending NR up to 71 GHz Intel Corporation
R1-2100819 Discussion on enhancements for PUCCH format 0/1/4 for above 52.6GHz Spreadtrum Communications
R1-2100838 Discussions on enhancements for PUCCH formats 0/1/4 InterDigital, Inc.
R1-2100894 Enhancements for PUCCH formats 0/1/4 to support NR above 52.6 GHz LG Electronics
R1-2101196 Enhancements for PUCCH format 0/1/4 for NR from 52.6 GHz to 71 GHz Samsung
R1-2101308 PUCCH enhancements Ericsson
R1-2101374 Enhancements for PUCCH formats 0/1/4 for NR between 52.6GHz and 71 GHz Apple
R1-2101455 Enhancements for PUCCH for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2101607 PUCCH format 0/1/4 enhancements for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2101673 Discussion on PUCCH enhancement for PUCCH format 0/1/4 WILUS Inc.
[104-e-NR-52-71GHz-03] – Steve (Ericsson)
Email discussion/approval on PUCCH format 0/1/4 enhancements with checkpoints for agreements on Jan-28, Feb-02, Feb-05
R1-2101794 FL Summary for Enhancements for PUCCH formats 0/1/4 Moderator (Ericsson)
Decision: From GTW session on Jan 27th,
Agreement:
Tables 1, 2, and 3 in R1-2101794 are agreed as a common set of assumptions for link level simulations and link budget calculations for evaluating enhancements to PUCCH formats 0/1/4 with the following modifications:
Note: Other parameters can be additionally considered in the evaluations
Decision: As per email posted on Feb 5th, above agreement is amended as below:
Tables 1, 2, and 3 in Section 2.3 of R1-2102127 are agreed as a common set of assumptions for link level simulations and link budget calculations for evaluating enhancements to PUCCH formats 0/1/4
Note: Other parameters can be additionally considered in the evaluations
Agreement:
For enhanced (multi-RB) PUCCH Formats 0/1/4 for 120/480/960 kHz SCS, support allocation of N_RB contiguous RBs
· FFS: Values of N_RB for each SCS
· For 480/960 kHz SCS, all REs within each RB are mapped
o Note: PRB and sub-PRB interlaced mapping is not considered further
· For 120 kHz SCS, further discuss the following two alternatives:
o Alt-1: All REs within each RB are mapped
§ Note: PRB and sub-PRB interlaced mapping is not considered further
o Alt-2: Subset of REs within each RB are mapped (sub-PRB interlaced mapping)
R1-2101916 FL Summary#2 for Enhancements for PUCCH formats 0/1/4 Moderator (Ericsson)
R1-2102111 FL Summary#3 for Enhancements for PUCCH formats 0/1/4 Moderator (Ericsson)
Decision: From GTW session on Feb 3rd,
Agreement:
· The configured number of RBs for enhanced PF 0/1/4 is denoted NRB
o The minimum value of NRB is 1 for PF 0/1/4 for all subcarrier spacings
o The maximum value of NRB depends on subcarrier spacing
§ FFS: maximum value for each SCS and each of PF0/1/4
o FFS: Allowed values of NRB within the [min/max] range
o FFS: Details of indication of NRB by cell-specific (for PF0/1) and dedicated signaling (PF0/1/4)
o FFS: Whether or not multiplexing of users with misaligned RB allocations is supported, where "misaligned" also includes users with different # of RBs.
o For PF4:
§ The actual number of RBs used for a PUCCH transmission is equal to NRB, i.e., the actual number of RBs does not vary dynamically based on PUCCH payload
§
NRB
fulfils the following: 
where 
is a set of
non-negative integers
· Note: if frequency hopping is enabled, NRB is the number of RBs per hop
· Note: decisions on the maximum value of NRB for each SCS and PUCCH format shall take into account link budgets based at least on the agreed evaluation assumptions
Agreement:
· For enhanced PF0/1, support Type-1 low PAPR sequences. Further study and strive to select one of the following alternatives:
o Alt-1: A single sequence of length equal to the total number of mapped REs of of the PUCCH resource is used. Cyclic shifts for PF0/1 are defined in the same way as Rel-16 for the case that useInterlacePUCCH-PUSCH is not configured.
o Alt-2: A single sequence of length equal to the number of mapped REs per RB of the PUCCH resource is used, and the sequence is repeated in each RB. At least the following scheme is considered for PAPR/CM reduction:
§ Cycling of cyclic shifts across RBs in a similar way as for Rel-16 for PF0/1 for the case that useInterlacePUCCH-PUSCH is configured
· At least the following aspects should be considered in the study
o Coverage (maximum isotropic loss (MIL)), including
§ Required SNR to fulfil PUCCH detection criterion
§ PAPR/CM as a function of N_RB
o Specification impact
Agreement:
· For DMRS of enhanced PF4, support Type-1 low PAPR sequences. Further study and strive to select one of the following alternatives for sequence construction:
o Alt-1: A single sequence of length equal to the total number of mapped Res of of the PUCCH resource is used. Cyclic shifts are defined in the same was as Rel-15/16 for PF4.
o Alt-2: A single sequence of length equal to the number of mapped Res per PRB of the PUCCH resource is used, and the sequence is repeated in each PRB. At least the following scheme is considered for PAPR/CM reduction:
§ Cycling of cyclic shifts across RBs in a similar way as for Rel-16 for PF0/1 for the case that useInterlacePUCCH-PUSCH is configured
· At least the following aspects should be considered in the study
o Coverage (maximum isotropic loss (MIL)), including
§ Required SNR to fulfil PUCCH detection criterion
§ PAPR/CM as a function of N_RB
o Specification impact
Agreement:
· For UCI of enhanced PF4, support pre-DFT blockwise spreading using OCCs of length 2 and 4 as defined for Rel-16 PF4
· Further study the following and decide in RAN1#104-b:
o Whether or not additional OCC lengths are supported
o Down-select to one of the following alternatives for blockwise spreading
§ Alt-1: Blockwise spreading is performed across all allocated RBs
§ Alt-2: Blockwise spreading and DFT is performed per-RB followed by per-RB PAPR/CM reduction mechanism.
· At least the following aspects should be considered in the study
o Coverage (maximum isotropic loss (MIL)), including
§ Required SNR to fulfil PUCCH detection criterion
§ PAPR/CM as a function of N_RB
o Specification impact
R1-2102127 FL Summary#4 for Enhancements for PUCCH formats 0/1/4 Moderator (Ericsson)
Including timing associated with beam-based operation
R1-2100052 Beam management for shared spectrum access in Beyond 52.6GHz FUTUREWEI
R1-2100060 Beam-management enhancements for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2100076 Discussion on the beam management for 52.6 to 71GHz ZTE, Sanechips
R1-2100152 Discussion on beam management OPPO
R1-2100203 Discussion on the beam management procedures for 52-71GHz band Huawei, HiSilicon
R1-2100260 Beam Management Aspects Nokia, Nokia Shanghai Bell
R1-2100373 Beam management for new SCSs for up to 71GHz operation CATT
R1-2100432 Discussions on beam management for new SCSs for NR operation from 52.6GHz to 71GHz vivo
R1-2100646 Discussion on Beam management aspects for extending NR up to 71 GHz Intel Corporation
R1-2100839 Discussions on beam management for new SCSs InterDigital, Inc.
R1-2100852 Beam management enhancement for NR from 52.6GHz to 71GHz Sony
R1-2100895 Enhancements for beam management to support NR above 52.6 GHz LG Electronics
R1-2101111 Discussion on beam management in NR from 52.6 GHz to 71GHz Xiaomi
R1-2101197 Beam management for new SCSs for NR from 52.6 GHz to 71 GHz Samsung
R1-2101309 Beam Management for New SCSs Ericsson
R1-2101375 On beam management for new SCSs Apple
R1-2101419 On Beam Management for Supporting NR from 52.6 GHz to 71 GHz Convida Wireless
R1-2101456 Beam management for new SCS for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2101608 Beam based operation for new SCSs for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
[104-e-NR-52-71GHz-04] – Youngwoo (InterDigital)
Email discussion/approval on beam management for new SCSs with checkpoints for agreements on Jan-28, Feb-02, Feb-05
R1-2101895 Discussion summary of [104-e-NR-52-71GHz-04] Moderator (InterDigital Inc.)
Decision: From GTW session on Jan 27th,
Agreement:
Agreement:
Rel-15/16 and any Rel-17 beam management enhancements can be considered for 52.6-71 GHz. Whether particular features should be excluded for 52.6-71 GHz can be further discussed.
R1-2102016 Discussion summary#2 of [104-e-NR-52-71GHz-04] Moderator (InterDigital, Inc.)
R1-2102100 Discussion summary#3 of [104-e-NR-52-71GHz-04] Moderator (InterDigital, Inc.)
Agreement:
R1-2102144 Discussion summary#4 of [104-e-NR-52-71GHz-04] Moderator (InterDigital, Inc.)
Agreement:
Further study the following:
Agreement:
Further study the following:
R1-2102243 Discussion summary#5 of [104-e-NR-52-71GHz-04] Moderator (InterDigital, Inc.)
Including defining maximum bandwidth for new SCSs, time line related aspects adapted to each of the new numerologies 480kHz and 960kHz, reference signals, scheduling particularly w.r.t. multi-PDSCH/PUSCH with a single DCI, HARQ, etc.
R1-2101819 Discussion on the data channel enhancements for 52.6 to 71GHz ZTE, Sanechips (rev of R1-2100077)
· Proposal 1: The following options are proposed for channelization for Rel-17 NR beyond 52.6 GHz, wherein Option 2 is preferred.
o Option 1: Align the channelization of Rel-17 NR with Wi-Fi design at least in unlicensed band (e.g. 57 GHz - 71 GHz)
§ Option 1-1: Support a basic unit of 2.16 GHz channel bandwidth
§ Option 1-2: Divide X of 400 MHz, Y of 800 MHz and Z of 1600 MHz per 2.16 GHz bandwidth. Where X = 0 to 5, Y = 0 to 2, and Z = 0 to 1.
§ In other licensed frequency band (e.g. 52.6 GHz - 57 GHz) or in a controlled environment without Wi-Fi devices, it can be designed uniformly with unlicensed band or independently
o Option 2: No need to align the channelization of Rel-17 NR with Wi-Fi design even in unlicensed band. Support the same bandwidth(s) (e.g. 400/800/1600 MHz) in licensed and unlicensed frequency bands
§ Option 2-1: Support a nominal channel bandwidth of 2.16 GHz by the aggregation of above basic bandwidth(s) (e.g. 400/800/1600MHz)
§ Option 2-2: No need to support a nominal channel bandwidth of 2.16 GHz
· Proposal 2: The maximum channel bandwidth for the new SCSs 480/960 kHz can be defined as 1600 MHz.
· Proposal 3: The scheme used in Rel-16 NR-U for one UL grant scheduling multiple PUSCHs can be a starting point, further enhancement on DCI design (e.g., HARQ-ACK codebook construction, CBG transmission and beam indication) should be considered.
· Proposal 4: Reuse the Rel-15 legacy PTRS pattern for 52.6GHz~71GHz.
· Proposal 5: Reuse the Rel-15 legacy DMRS pattern for 52.6GHz~71GHz.
· Proposal 6: Consider to relax the restriction on DMRS ports for PUSCH and PDSCH when PTRS is configured.
· Proposal 7: Consider the impact of phase noise on port number of other reference signals and control signals.
· Proposal 8: For high frequency, a new UE capability for timeline related aspects should be defined based on slot (or symbol)-group granularity.
· Proposal 9: Consider the phase noise estimation and compensation time on timeline design when PTRS is configured.
· Proposal 10: How to interpret k0, k1 and k2 for PUSCH/PDSCH scheduling and HARQ feedback timing indication should be discussed.
Decision: The document is noted.
R1-2101376 PDSCH/PUSCH enhancements for NR between 52.6GHz and 71 GHz Apple
· Proposal 1: Multiple carrier bandwidths should be specified with carrier bandwidths that are multiples of about 400 MHz
· Proposal 2: The maximum channel bandwidth of about 2.16 GHz should be used for co-existence with the existing 802.11ad/ay channel allocation with no overlap between a single NR channel and multiple 802.11ad/ay channels.
· Proposal 3: For 120 kHz and 480 kHz, 2 GHz channel bandwidth transmission can be achieved by carrier aggregation.
· Proposal 4: Modify the UE processing timelines to account for the 480 kHz and 960 kHz SCSs. These should be discussed individually.
· Proposal 5: RAN1 should prioritize the discussion of the critical processing timelines in order of (a) parameter independence (b) priority and (c) sub-agenda item dependence.
· Proposal 6: investigate the need for enhancements and standardization, of the following processing timelines:
o Default PUSCH time Domain resource allocation for normal CP
o UE PDSCH reception preparation time with cross carrier scheduling with different subcarrier spacings for PDCCH and PDSCH
o SRS, PUCCH, PUSCH, PRACH cancellation with dynamic SFI
o ZP CSI Resource set activation/deactivation
o Beam Switch Timing for periodic CSI-RS + aperiodic CSI-RS
o Beam switch timing for aperiodic CSI-RS
o Aperiodic CSI-RS timing offset
o Application delay of the minimum scheduling offset restriction
o SRS triggering after DCI reception
· Proposal 7: multi-PDSCH/PUSCH transmission with a single DCI should support single or multiple non-continuous PDSCHs/PUSCHs in multiple scheduled slots/mini-slots.
· Proposal 8: For the single scheduling DCI, study the DCI fields that should be separate and combined to maximize parameter independence while reducing overhead.
o For PUSCH transmission, the following DCI fields should be discussed: FDRA, TDRA, MCS, NDI, RV, HARQ process number, DAI, priority, and CBGTI.
o For PDSCH transmission, the following DCI fields should be discussed: FDRA, TDRA, MCS1/2, NDI 1/2, RV 1/2, HARQ process number, DAI, PRI, K1, priority, CBGTI, and CBGFI.
· Proposal 9: Specify a multi-slot HARQ procedure to support multi-slot HARQ processing.
· Proposal 10: The FDRA size should be optimized to reduce the FDRA overhead by
o Increasing the RBG sizes or modifying the RIV calculation.
o Enabling signaling of the FDRA to be disabled to support TDMA transmission
· Proposal 11: To account for transmission with large SCSs in low coherence BW channels,
o turn on or off the FD-OCC based on the scenario the channel is in
o configure the UE with a DMRS pattern based on the new SCSs and the coherence bandwidth of the channel
· Proposal 12: RAN1 should support frequency domain power boosting for PTRS where regulations allow and new PTRS patterns to mitigate time varying phase noise with each symbol.
Decision: The document is noted.
R1-2100050 Considerations for higher SCS in Beyond 52.6 GHz FUTUREWEI
R1-2100061 PDSCH/PUSCH scheduling enhancements for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2100153 Discussion on PDSCH/PUSCH enhancements OPPO
R1-2100201 PDSCH/PUSCH enhancments for 52-71GHz band Huawei, HiSilicon
R1-2100261 PDSCH/PUSCH enhancements Nokia, Nokia Shanghai Bell
R1-2100300 Discussions on PDSCH and PUSCH enhancements for 52.6-71GHz CAICT
R1-2100374 PDSCH/PUSCH enhancements for up to 71GHz operation CATT
R1-2100433 Discussions on PDSCH/PUSCH enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2100553 PT-RS enhancements for NR from 52.6GHz to 71GHz Mitsubishi Electric RCE
R1-2100605 On Enhancements of PDSCH Reference Signals MediaTek Inc.
R1-2100647 Discussion on PDSCH/PUSCH enhancements for extending NR up to 71 GHz Intel Corporation
R1-2100741 Considerations on multi-PDSCH/PUSCH with a single DCI and HARQ for NR from 52.6GHz to 71 GHz Fujitsu
R1-2100820 Discussion on PDSCH and PUSCH enhancements for above 52.6GHz Spreadtrum Communications
R1-2101780 Discussions on PDSCH/PUSCH enhancements InterDigital, Inc. (rev of R1-2100840)
R1-2100853 PDSCH/PUSCH enhancements for NR from 52.6GHz to 71GHz Sony
R1-2100896 PDSCH/PUSCH enhancements to support NR above 52.6 GHz LG Electronics
R1-2100940 PDSCH enhancements on supporting NR from 52.6GHz to 71 GHz NEC
R1-2101112 PDSCH and PUSCH enhancements for NR 52.6-71GHz Xiaomi
R1-2101198 PDSCH/PUSCH enhancements for NR from 52.6 GHz to 71 GHz Samsung
R1-2101310 PDSCH-PUSCH Enhancements Ericsson
R1-2101320 Enhancements on Reference Signals for PDSCH/PUSCH for NR beyond 52.6 GHz CEWiT
R1-2101958 PDSCH-PUSCH Enhancement Aspects for NR beyond 52.6 GHz Charter Communications (rev of R1-2101330)
R1-2101457 PDSCH/PUSCH enhancements for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2101609 PDSCH/PUSCH enhancements for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2101776 Summary of PDSCH/PUSCH enhancements (Bandwidth/Timeline/Reference signals) Moderator (vivo)
[104-e-NR-52-71GHz-05] – Huaming (vivo)
Email discussion/approval on defining maximum bandwidth for new SCSs, timeline related aspects adapted to each of the new numerologies 480kHz and 960kHz and reference signals with checkpoints for agreements on Jan-28, Feb-02, Feb-05
R1-2101883 Discussion summary #1 of [104-e-NR-52-71GHz-05] Moderator (vivo)
Agreement:
Agreement:
R1-2102090 [Draft] LS on the maximum/minimum channel bandwidth and channelization for NR operation in 52.6 to 71 GHz vivo
Decision: The draft LS is endorsed. Final LS is approved in R1-2102128.
R1-2102072 Discussion summary #2 of [104-e-NR-52-71GHz-05] Moderator (vivo)
Agreement:
Agreement:
Proposal 5-1a in R1-2102072 is agreed with the following modification:
Decision: As per email posted on Feb 5th,
Agreement:
Further study at least the following aspects of timelines to support both single PDSCH/PUSCH and multi-PDSCH/PUSCH scheduling for NR operation in 52.6 GHz to 71 GHz.
· Time unit and applicability to selected timelines
· Value and/or range of value
· Potential impact on UE capability
Agreement:
· The following UE processing timelines are prioritized for discussion
o PDSCH processing time (N1), PUSCH preparation time (N2), HARQ-ACK multiplexing timeline (N3)
o configuration(s)/default values of k0 (PDSCH), k1 (HARQ), k2 (PUSCH)
o CSI processing time, Z1, Z2, and Z3, and CSI processing units
o Note: the order of the above sub-bullets represents the priority for discussion in descending order
· Companies are encouraged to provide preferred values/ranges of timelines for discussion
Agreement:
FFS: The need for enhancements and standardization, of the following additional processing timelines:
· UE PDSCH reception preparation time with cross carrier scheduling with different subcarrier spacings for PDCCH and PDSCH
· SRS, PUCCH, PUSCH, PRACH cancellation with dynamic SFI
· ZP CSI Resource set activation/deactivation
· Application delay of the minimum scheduling offset restriction
· timing aspects related to cross carrier operation
Agreement:
· At least existing PTRS design for CP-OFDM is supported for NR operation in 52.6 to 71 GHz.
· Companies are encouraged to study the need of potential PTRS enhancement for CP-OFDM with respect to phase noise compensation performance considering at least the following aspects:
o PTRS density/pattern (e.g. distributed, block-based) and sequence (e.g. cyclic sequence)
o Frequency domain power boosting and its impact to PDSCH performance and PDSCH to DMRS EPRE
o Receiver complexity, including possible aspects related to supporting both existing PTRS design and potential PTRS enhancement
o Possible specification impact of supporting potential PTRS enhancement in addition to existing PTRS design
o Note: PTRS overhead should be accounted for in the evaluations, e.g. by showing spectral efficiency results and/or reporting effective coding rate
· Note: the decision to support potential enhanced PTRS design in addition to existing PTRS design will be made based on performance benefit, receiver complexity and specification effort aspects of enhanced PTRS design together and not purely on the considerations of the specification effort caused by supporting potential enhanced PTRS design in addition to existing PTRS design.
Agreement:
Companies are encouraged to study at least the following aspects for potential PTRS enhancement for DFT-s-OFDM for NR operation in 52.6 to 71 GHz
· The need of potential PTRS enhancement
· PTRS pattern with more PTRS groups within one DFT-s-OFDM symbol when a large number of PRBs is scheduled
Agreement:
· Existing DMRS patterns are supported for NR operation in 52.6 to 71 GHz with 120 kHz SCS.
· At least existing DMRS patterns are supported for NR operation in 52.6 to 71 GHz with 480 kHz and/or 960 kHz SCS
· Further study on whether to introduce different DMRS pattern with increased frequency domain density (in number of subcarriers) than the existing DMRS patterns for NR operation in 52.6 to 71 GHz with 480 kHz and/or 960 kHz SCS
· Further study on whether and how to restrict DMRS port configuration (e.g., the number of DMRS ports) as in FR2 for NR operation in 52.6 to 71 GHz with 480 kHz and/or 960 kHz SCS
Agreement:
Further study on at least the following aspects of potential DMRS enhancement with respect to FD-OCC:
· whether to support a configuration of DMRS in which FD-OCC is not applied for 480 kHz and 960 kHz SCS
o Applicability to Type-1 and/or Type-2 DMRS
o Details on whether and how to indicate that FD-OCC is not applied to DMRS port
o Impact to UE multiplexing capacity and inter-UE interference in MU-MIMO
Final summary in:
R1-2102237 Discussion summary #3 of [104-e-NR-52-71GHz-05] Moderator (vivo)
R1-2101799 Summary #1 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
[104-e-NR-52-71GHz-06] – Seonwook (LGE)
Email discussion/approval on scheduling particularly w.r.t. multi-PDSCH/PUSCH with a single DCI, HARQ, with checkpoints for agreements on Jan-28, Feb-02, Feb-05
R1-2101858 Summary #2 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
R1-2101972 Summary #3 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
Agreement:
Agreement:
Agreement:
For generating type-2 HARQ-ACK codebook corresponding to DCI that can schedule multiple PDSCHs, the following alternatives can be considered to DAI counting and will be down-selected in RAN1#104bis-e.
· Alt 1: C-DAI/T-DAI is counted per DCI.
· Alt 2: C-DAI/T-DAI is counted per PDSCH.
· Alt 3: C-DAI/T-DAI is counted per M scheduled PDSCH(s), where M is configurable (e.g., 1, 2, 4, …).
· FFS: Codebook generation details
· FFS: How to signal DAI values (e.g., increase of DAI bits for Alt 2 and Alt 3)
· FFS: Whether to apply time domain bundling of HARQ-ACK feedback
Agreement:
The multi-PUSCH scheduling defined in Rel-16 NR-U is the baseline for multi-PUSCH scheduling in Rel-17.
Agreement:
Final summary in:
R1-2102080 Summary #4 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
R1-2100202 Channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
· Proposal 1: For operation in NR-U-60, the EDT formula adopted from draft v2.1.20 of EN 302 567 as a baseline should be adjusted to account for an LBT BW other than 2 GHz.
· Proposal 2: For operation in NR-U-60, the EDT formula adopted from draft v2.1.20 of EN 302 567 as a baseline should be adjusted such that, for a given RF output power (EIRP), EDT proportionally increases with the beamforming gain of the potential following transmission.
· Proposal 3: For operation in NR-U-60, when LBT is used, adopt the following generalized formula to capture the potential enhancements to the baseline EDT formulae:
o EDT= X+Y-min(Y, Po + a GTX ) [dBm], wherein 0≤a ≤1 [dBm/dBi],
o X is a reference CCA level further adjustable based on LBT BW, e.g. X=-47+10log10(BW/2GHz),
o Y is the maximum EIRP limit, e.g. Y=40 dBm,
o GTX is the effective transmit antenna gain at the potential transmitter [dBi],
o Po is the output power to the transmit antenna array [dBm] such that Pout (EIRP)= Po+GTX.
· Proposal 4: It should be clarified whether antenna gain is counted in the received energy when compared with the EDT.
· Proposal 5: For operation in the 60 GHz band, the LBT bandwidth should be specified relative to the channel bandwidth defined in RAN4 specifications.
· Proposal 6: For operation in the 60 GHz band, the LBT BW can be greater than the carrier BW.
o Support Alt 3 and Alt 5 captured in the TR.
· Proposal 7: For operation in the 60 GHz band, specify the spatial relation between the LBT beam and the transmission beam.
· Proposal 8: For spatial domain multiplexing of different beams, both one LBT beam covering all transmission beams, and multiple LBT beams covering multiple transmission beams are supported.
· Proposal 9: For time domain multiplexing of transmissions in different beams in the same COT, support LBT at the beginning of COT by the initiating device with sensing beam(s) that covers all TDM transmission beams from the initiating device.
· Proposal 10: LBT before subsequent transmissions by the initiating device within the same COT is not supported.
· Proposal 11: For operation in the 60GHz unlicensed band, support LBT before SSB burst transmission.
· Proposal 12：For operation in the 60 GHz band, receiver-side LBT should be supported.
· Proposal 13：For operation in the 60 GHz band, in regions where LBT is not mandated, a gNB/UE can initiate a channel occupancy access using a channel access mechanism without LBT if it is used in conjunction with an interference mitigation scheme.
o Interference mitigation schemes such as ATPC or DFS would be implemented as specified by the region-specific regulations and do not need to be specified by 3GPP.
· Proposal 14：For operation in the 60 GHz band, in regions where LBT is not mandated, support switching between channel access with LBT and channel access without LBT in a serving cell by gNB configuration.
· Proposal 15：For operation in the 60 GHz band, in regions where LBT is not mandated, the serving cell may enable Rx-side LBT using a higher layer configuration to mitigate high levels of interference experienced from hidden nodes.
· Proposal 16：For operation in the 60 GHz band, in regions where LBT is not mandated, MCOT limits should be applied for a channel occupancy initiated without LBT.
· Proposal 17：For operation in the 60 GHz band, in regions where LBT is mandated, support transmission of short control signalling without LBT, and with a duty cycle 10 % within an observation period of 100 ms.
o Short control signaling is defined as a short transmission burst that contains unicast control information without any user plane data
Decision: The document is noted.
R1-2100262 Channel access mechanism Nokia, Nokia Shanghai Bell
Transmitter LBT procedure
· Proposal 1: LBT procedure uses fixed contention window size for random back-off. The size of the fixed contention window is FFS.
· Proposal 2: Reduced number of CAPCs can be considered for the LBT procedure for 60 GHz band. Support for CAPCs is considered together with the design of short control signalling.
· Proposal 3: Energy detection threshold is determined by XThresh = -80 dBm + 10 log10 (LBT Bandwidth (in MHz)) + 10 log10 (EIRPmax / EIRPout), where EIRPout is the maximum peak EIRP of intended transmissions.
· Proposal 4: Energy detection threshold adjustment can be considered for compensating any difference on the transmission and LBT beamforming gains.
· Proposal 5: NR-U design for 60 GHz bands supports transmission of DL and UL control and management signals as short control signalling without LBT. Details are FFS.
· Proposal 6: The design of LBT bandwidth in FR1 can be considered as the baseline for operation on 60GHz unlicensed band, e.g., the minimum supported channel bandwidth can be considered as the LBT bandwidth. Also use of channel bandwidth as LBT bandwidth can be considered further. However, before making final decisions, the basic principles of channelization (numerology) should be agreed first.
· Proposal 7: The multi-channel LBT mechanism specified in Rel-16 NR-U can be considered as a baseline for operation in 60GHz unlicensed band with necessary enhancement.
Beamforming for LBT
· Proposal 8: Leave the choice of the beam width for the directional LBT operation to the vendor-specific implementations. Vendors can use different beamforming techniques for their LBT procedures, as long as global or region and deployment specific requirements (i.e., ETSI EN 302 567) are fulfilled.
Channel access within LBT
· Proposal 9: Channel access without channel sensing is supported for a UE responding to a DL transmission within a gNB initiated COT after a time gap of at most X us.
· Proposal 10: Time gap of X us is longer that PDSCH processing time and PUSCH preparation time.
· Proposal 11: UEs without LBT functionality are also supported.
· Proposal 12: Within a COT, gNB does not need to sense the channel after a beam switch when the time gap to previous channel sensing or transmission covering the beam is less than Y us. The value of Y is for further study.
Receiver assistance in channel access
· Proposal 13: Any Rx assistance scheme should be configurable per UE, so that it could be used only with UEs frequently detecting high interference.
· Proposal 14: For any new Rx assistance schemes, UE processing time similar to PDSCH processing time (N1) or CSI computation time (N2/Z1Z2) should be considered when providing Rx assistance.
· Proposal 15: Rx assistance should not be limited to the beginning of COT only.
Channel access without LBT
· Proposal 16: Channel access mechanism (i.e. whether or not LBT is in use) is part of the cell configuration.
· Proposal 17: Flexible selection of channel access mechanism (LBT or no-LBT) per gNB beam is considered further.
Decision: The document is noted.
R1-2100053 Considerations on channel access for shared spectrum Beyond 52.6 GHz FUTUREWEI
R1-2100062 Channel access mechanisms for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2100078 Discussion on the channel access for 52.6 to 71GHz ZTE, Sanechips
R1-2100154 Discussion on channel access mechanism OPPO
R1-2100301 Discussions on channel access mechanism for 52.6G-71 GHz CAICT
R1-2100375 Channel access mechanism for up to 71GHz operation CATT
R1-2100434 Discussions on channel access mechanism for NR operation from 52.6GHz to 71 GHz vivo
R1-2100542 Channel access mechanism TCL Communication Ltd.
R1-2100648 Discussion on channel access mechanism for extending NR up to 71 GHz Intel Corporation
R1-2100742 Considerations on channel access mechanism for NR from 52.6GHz to 71 GHz Fujitsu
R1-2100755 Channel access for multi-beam operation PANASONIC
R1-2100782 Further Discussion of Channel Access Mechanisms AT&T
R1-2100821 Discussion on channel access mechanism for above 52.6GHz Spreadtrum Communications
R1-2100841 Discussion on channel access mechanisms InterDigital, Inc.
R1-2100854 Channel access mechanism for 60 GHz unlicensed spectrum Sony
R1-2100897 Channel access mechanism to support NR above 52.6 GHz LG Electronics
R1-2100941 Discussion on channel access mechanism supporting NR from 52.6 to 71GHz NEC
R1-2101113 Channel access mechanism for NR on 52.6-71 GHz Xiaomi
R1-2101199 Channel access mechanism for NR from 52.6 GHz to 71 GHz Samsung
R1-2101311 Channel Access Mechanisms Ericsson
R1-2101331 Channel access mechanisms Charter Communications
R1-2101377 Channel access mechanisms for unlicensed access above 52.6GHz Apple
R1-2101420 On Channel Access Mechanism for Extending Current NR to 71 GHz Convida Wireless
R1-2101458 Channel access mechanism for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2101569 Discussion on LBT mode ITRI
R1-2101610 Channel access mechanism for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2101798 FL summary on channel access mechanism for 60GHz band Moderator (Qualcomm)
[104-e-NR-52-71GHz-07] – Jing (Qualcomm)
Email discussion/approval on channel access mechanism with checkpoints for agreements on Jan-28, Feb-02, Feb-05
R1-2101887 Email discussion summary for channel access for 52.6-71GHz Moderator (Qualcomm)
R1-2101942 Email discussion summary#2 for channel access for 52.6-71GHz Moderator (Qualcomm)
The baseline ED threshold can be computed as
Where Pout is RF output power (EIRP) and Pmax is the RF output power limit, Pout≤Pmax.
Decision: As per email posted on Feb 5th,
Agreement:
For LBT for single carrier transmission, consider the following alternatives
· Alt SC.1. gNB/UE performs LBT over the channel bandwidth (or BWP bandwidth)
· Alt SC.2. gNB/UE performs LBT over the transmission bandwidth (from the lowest RB to the highest RB used for the transmission)
· Alt SC.3. Define a unit of LBT bandwidth and gNB/UE performs LBT in all the LBT units (to be transmitted in) in the channel bandwidth
For LBT for multi-carrier transmission in intra-band CA, consider the following alternatives
· Alt CA.1. gNB/UE performs multiple LBT, one for each channel bandwidth separately
· Alt CA.2. gNB/UE performs single LBT over all CCs
· Alt CA.3. gNB/UE performs multiple LBT, one for each CC over the transmission bandwidth (from the lowest RB in to the highest RB used for the transmission in the CC)
· Alt CA.4. gNB/UE performs LBT over the transmission bandwidth over all CCs (from the lowest RB in the lowest CC to the highest RB in the highest CC used for the transmission)
· Alt CA.5. Define a unit of LBT bandwidth and gNB/UE performs LBT in all the LBT units (to be transmitted in) in the channel bandwidth in each CC
Note: supporting more than one alternative for at least multi-carrier transmission in intra-band CA is not precluded.
Agreement:
For energy measurement in 8us deferral period, down-select from the following:
· Alt 1. Two energy measurements are required
· Alt 2. One measurement is required
· Alt 3. Extend the 8us to 10us and perform two measurements, one in each 5us segment
For energy measurement in 5us observation slot, perform single measurement
· FFS minimum duration of the measurement
· FFS location of the measurement
Agreement:
On maximum gap within a COT to allow COT sharing without LBT, down-select from
· Alt 1. No maximum gap defined. A later transmission can share the COT without LBT with any gap within the maximum COT duration
· Alt 2. Define a maximum gap X, such that a later transmission can share the COT without LBT only if the later transmission starts within X from the end of the earlier transmission
o FFS: Value for X
· Alt 3. Define a maximum gap Y, such that a later transmission can share the COT without LBT only if the later transmission starts within Y from the end of the earlier transmission. If the later transmission starts after Y from the end of the earlier transmission, an one-shot LBT is needed to share the COT
o FFS: Value for Y
o FFS: How to define the one-shot LBT
Agreement:
For Cat 2 LBT, down-select from the following alternatives
· Alt 1: Do not introduce Cat 2 LBT for 60GHz unlicensed band operation
· Alt 2: Introduce Cat 2 LBT for 60GHz unlicensed band operation
Agreement:
If Cat 2 LBT is introduced, the following use cases can be further studied:
· Resume transmission after a gap Y: Cat 2 LBT may be used to resume transmission by the initiating device within the COT after a gap Y (FFS the value of Y)
· COT sharing: Cat 2 LBT may be used before transmission by a responding node sharing a COT
· Multi-Beam LBT: Cat 2 LBT may be used before switching to a new transmission beam (not used in earlier part of the COT) in a COT with TDM beams, or resume a previously used transmission beam after a gap Z (FFS the value of Z)
· Rx-Assistance: Cat 2 LBT may be used for sensing at the receiver as a responding device for Rx-Assistance measurements and associated signalling
Other use cases not precluded.
FFS if Cat 2 LBT is mandated for each use case or not.
Agreement:
For receiver to provide assistance, channel sensing and reporting need to be performed. The following set of tools can be considered for further discussion
· Alt 1. Legacy RSSI measurement and reporting with possible enhancements
· Alt 2. AP-CSI report with possible enhancements
· Alt 3. LBT at receiver
o Alt 3.1 eCCA
o Alt 3.2 Cat2 LBT
Agreement:
For a COT with MU-MIMO (SDM) transmission, further consider the follow alternatives (down-select or support both)
· Alt 1: Single LBT sensing at the start of the COT with wide beam ‘cover’ all beams to be used in the COT with appropriate ED threshold
· Alt 2: Independent per-beam LBT sensing at the start of COT is performed for beams used in the COT
Agreement:
Within a COT with TDM of beams with beam switching, down-select one or more of the following LBT operations
· Alt 1: Single LBT sensing with wide beam ‘cover’ all beams to be used in the COT with appropriate ED threshold
o FFS: Details on the definition of "cover"
· Alt 2: Independent per-beam LBT sensing at the start of COT is performed for beams used in the COT
· Alt 3: Independent per-beam LBT sensing at the start of COT is performed for beams used in the COT with additional requirement on Cat 2 LBT before beam switch
Agreement:
Define Type A and Type B multi-channel channel access as:
· Type A: Perform independent eCCA for each channel
· Type B: Identify a primary channel and perform eCCA on the primary channel, while perform Cat 2 LBT for other channels in the last observation slot
Down-selection between
· Alt1: Support Type A multi-channel channel access only
· Alt2: Support both Type A and Type B multi-channel channel access.
Note: How eCCA is performed on each channel, and the BW of the channels over which eCCAs are performed are separately discussed
Agreement:
· SSB transmission with LBT is supported, at least when the conditions for contention exempt short control signalling based SSB transmission is not met
o Note the channel access for SSB with LBT may not be different from a normal COT with multiple beams
o FFS: If any difference from a multi-beam COT LBT needs to be introduced
Final summary in:
R1-2102081 Email discussion summary#3 for channel access for 52.6-71GHz Moderator (Qualcomm)
R1-2101820 Evaluation results for 52.6 to 71GHz ZTE, Sanechips (rev of R1-2100079)
R1-2100155 Discussion on other aspects OPPO
R1-2100263 Simulation Results Nokia, Nokia Shanghai Bell
R1-2100435 Discussions on frequency range definition for 52.6-71GHz vivo
R1-2100842 Efficient beam management based on FR2 InterDigital, Inc.
R1-2101200 Discussion on the synchronization raster for NR from 52.6 GHz to 71 GHz Samsung
R1-2101268 Link level and system evaluation results for 52-71 GHz Huawei, HiSilicon
R1-2101312 NR channelization for 52.6 - 71 GHz band Ericsson
R1-2101611 Potential enhancements for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
Please refer to RP-210862 for detailed scope of the WI
R1-2103980 Session notes for 8.2 (Extending current NR operation to 71GHz) Ad-Hoc Chair (Ericsson)
Including SSB, initial BWP, PRACH, etc.
R1-2102327 Initial access signals and channels for 52-71GHz spectrum Huawei, HiSilicon
R1-2102385 Discussion on initial access aspects OPPO
R1-2102448 Discussion on initial access aspects for NR for 60GHz Spreadtrum Communications
R1-2102514 Discussions on initial access aspects for NR operation from 52.6GHz to 71GHz vivo
R1-2102558 Initial access aspects Nokia, Nokia Shanghai Bell
R1-2102621 Initial access aspects for up to 71GHz operation CATT
R1-2102688 Discussion on initial access of 52.6-71 GHz NR operation MediaTek Inc.
R1-2102715 Considerations on initial access for NR from 52.6GHz to 71 GHz Fujitsu
R1-2102772 Further considerations on initial access for additional SCS in Beyond 52.6GHz FUTUREWEI
R1-2102788 Initial Access Aspects Ericsson
R1-2102977 On initial access aspects for NR from 52.6GHz to 71GHz Xiaomi
R1-2102996 Initial access aspects for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2103021 Discussion on initial access aspects for extending NR up to 71 GHz Intel Corporation
R1-2103096 Discussion on Initial access signals and channels Apple
R1-2103157 Initial access aspects for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2103229 Initial access aspects for NR from 52.6 GHz to 71 GHz Samsung
R1-2103294 Considerations on initial access aspects for NR from 52.6 GHz to 71 GHz Sony
R1-2103339 Initial access aspects to support NR above 52.6 GHz LG Electronics
R1-2103411 NR Initial Access from 52.6 GHz to 71 GHz Convida Wireless
R1-2103442 Further Discussion of Initial Access Aspects AT&T
R1-2103448 Discussions on initial access aspects InterDigital, Inc.
R1-2103472 Initial access aspects Sharp
R1-2103487 Discussion on the initial access aspects for 52.6 to 71GHz ZTE, Sanechips
R1-2103519 Discussion on initial access aspects supporting NR from 52.6 to 71 GHz NEC
R1-2103567 Initial access aspects for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2103691 Discussion on initial access aspects for NR beyond 52.6GHz WILUS Inc.
R1-2103801 Issue Summary for initial access aspects of NR extension up to 71 GHz Moderator (Intel Corporation)
[104b-e-NR-52-71GHz-01] – Daewon (Intel)
Email discussion/approval on initial access aspects with checkpoints for agreements on Apr-15, Apr-20
R1-2103802 Summary #1 of email discussion on initial access aspects of NR extension up to 71 GHz Moderator (Intel Corporation)
R1-2104029 Summary #2 of email discussion on initial access aspects of NR extension up to 71 GHz Moderator (Intel Corporation)
Agreement:
For the case where SSB location and SCS are explicitly provided to the UE (non-initial access) and SSB does not configure Type-0 PDCCH, support 480 kHz and 960 kHz numerologies for the SSB
Agreement:
· For operation with shared spectrum channel access of NR 52.6 – 71 GHz, support discovery burst (DB) and define the DB same as in Rel-16 37.213 Section 4.0
· FFS: Support discovery burst transmission window (DBTW) at least for SSB with 120 kHz SCS with the following requirements
o PBCH payload size is no greater than that for FR2
o Duration of DBTW is no greater than 5 ms
o Number of PBCH DMRS sequences is the same as for FR2
o FFS: applicability of DBTW design for 120kHz to SSB with 480kHz and 960kHz SCS
o Support mechanism to indicate or inform that DBTW is enabled/disabled for both IDLE and CONNECTED mode UEs
§ FFS: how to support UEs performing initial access that do not have any prior information on DBTW.
§ FFS: details of the mechanism for enabling/disabling DBTW considering LBT exempt operation and overlapping licensed/unlicensed bands
§ FFS: details of how to inform UEs of the configuration of DBTW
Agreement:
For SSB with 120kHz SCS for NR 52.6 GHz to 71 GHz,
· 120 kHz SCS: the first symbols of the candidate SS/PBCH blocks have indexes {4, 8,16, 20} + 28×n, where index 0 corresponds to the first symbol of the first slot in a half-frame.
· For carrier frequencies within 52.6 GHz to 71GHz, support at least 𝑛 = 0, 1, 2, 3, 5, 6, 7, 8, 10, 11, 12, 13, 15, 16, 17, 18.
o Other values of n (if any) are FFS, and support of additional n values are subject to support of DBTW for 120kHz SSB
Agreement:
Final summary in R1-2104124.
R1-2102328 Enhancement on PDCCH monitoring Huawei, HiSilicon
R1-2102386 Discussion on PDCCH monitoring OPPO
R1-2102449 Discussion on PDCCH monitoring enhancement for NR beyond 52.6 GHz Spreadtrum Communications
R1-2102515 Discussions on PDCCH monitoring enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2102559 PDCCH monitoring enhancements Nokia, Nokia Shanghai Bell
R1-2102622 PDCCH monitoring enhancements for up to 71GHz operation CATT
R1-2102704 PDCCH monitoring enhancement for 52.6-71 GHz NR operation MediaTek Inc.
R1-2102773 Further considerations on PDCCH monitoring enhancements FUTUREWEI
R1-2102789 PDCCH Monitoring Enhancements Ericsson
R1-2102809 PDCCH monitoring enhancement for NR from 52.6GHz to 71GHz Panasonic
R1-2102978 PDCCH monitoring enhancement for NR 52.6-71GHz Xiaomi
R1-2102997 PDCCH monitoring enhancements for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2103022 Discussion on PDCCH monitoring enhancements for extending NR up to 71 GHz Intel Corporation
R1-2103097 Discussion on PDCCH Enhancements for above 52.6 GHz Apple
R1-2103158 PDCCH monitoring enhancements for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2103230 PDCCH monitoring enhancements for NR from 52.6 GHz to 71 GHz Samsung
R1-2103295 PDCCH enhancement for NR from 52.6GHz to 71GHz Sony
R1-2103340 PDCCH monitoring enhancements to support NR above 52.6 GHz LG Electronics
R1-2103412 PDCCH Monitoring Considerations for Supporting NR from 52.6 GHz to 71 GHz Convida Wireless
R1-2103449 Discussions on PDCCH monitoring enhancements InterDigital, Inc.
R1-2103488 Discussion on the PDCCH monitoring enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2103512 Discussion on PDCCH monitoring enhancements supporting NR from 52.6GHz to 71 GHz NEC
R1-2103568 PDCCH monitoring enhancements for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2103689 Feature lead summary for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
[104b-e-NR-52-71GHz-02] – Alex (Lenovo)
Email discussion/approval on PDCCH monitoring enhancements with checkpoints for agreements on Apr-15, Apr-20
R1-2104057 Feature lead summary #2 for [104b-e-NR-52-71GHz-02] Email discussion/approval on PDCCH Monitoring Enhancements Moderator (Lenovo)
Agreement:
Previous agreement is modifed as follows:
Choose one of the following alternatives for defining the multi-slot PDCCH monitoring capability
· Alt 1: Use a fixed pattern of slot groups as the baseline to define the new capability.
o Each slot group consists of X slots
o Slot groups are consecutive and non-overlapping
o The capability indicates the BD/CCE budget within Y consecutive [symbols or slots] in each slot group separately
o FFS: Supported values/constraints of X and Y, e.g. Y<=X, Y=X
o FFS: Restrictions on location of the Y [symbols or slots] within a slot group, e.g. the Y [symbols or slots] always start at the first slot within a slot group
o FFS: Further definition of capabilities
· Alt 2: Use an (X, Y) span as the baseline to define the new capability
o X is the minimum time separation between the start of two consecutive spans
o The capability indicates the BD/CCE budget within a span of at most Y consecutive [symbols or slots]
o Y <= X
o FFS: Exact values of X and Y and units in which they are defined (e.g., symbols, slots), including cases where a span is longer than one slot or crosses a slot boundary.
o FFS: What is a span pattern, how it is defined and whether it is supported. If it is supported, whether number of slots within which the span pattern is repeated is needed, and if needed, the value of the number of slots.
o FFS: Further definition of capabilities
· Alt 3: Use a sliding window of X slots as the baseline to define the new capability.
o The capability indicates the BD/CCE budget within the sliding window
o The sliding unit of the sliding window is [1] slot.
o FFS: Further definition of capabilities
· Specific numbers for X, Y may depend on UE capability and gNB configuration
o Examples:
§ X = [4] slots for 480 kHz SCS and X = [8] slots for 960 kHz SCS
Decision: As per email decision posted on April 17th,
· For 120 kHz SCS, no multi-slot UE capability for PDCCH monitoring is needed.
Agreement:
· For 120 kHz SCS in 52.6-71 GHz, the BD/CCE budget is the same as that for 120 kHz in FR2.
R1-2102329 Enhancement on PUCCH formats Huawei, HiSilicon
R1-2102387 Discussion on enhancements for PUCCH format 0/1/4 OPPO
R1-2102450 Discussion on enhancements for PUCCH format 0/1/4 for above 52.6GHz Spreadtrum Communications
R1-2102516 Discussions on PUCCH enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2102560 Enhancements for PUCCH formats Nokia, Nokia Shanghai Bell
R1-2102623 Enhancements for PUCCH formats for up to 71GHz operation CATT
R1-2102706 On Enhancements for PUCCH formats 0/1/4 MediaTek Inc.
R1-2102774 Considerations on PUCCH Channel enhancements FUTUREWEI
R1-2103869 Enhancements for PUCCH formats 0/1/4 Ericsson (rev of R1-2102790)
R1-2102998 Enhancements to PUCCH formats 0/1/4 for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2103023 Discussion on PUCCH enhancements for extending NR up to 71 GHz Intel Corporation
R1-2103098 Discussion on Enhancements for PUCCH formats 0/1/4 Apple
R1-2103159 Enhancements for PUCCH for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2103231 Enhancements for PUCCH format 0/1/4 for NR from 52.6 GHz to 71 GHz Samsung
R1-2103296 Considerations on enhancements for PUCCH formats 0/1/4 Sony
R1-2103341 Enhancements for PUCCH formats 0/1/4 to support NR above 52.6 GHz LG Electronics
R1-2103450 Discussions on enhancements for PUCCH formats 0/1/4 InterDigital, Inc.
R1-2103489 Discussion on the PUCCH enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2103569 PUCCH format 0/1/4 enhancements for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2103692 Discussion on PUCCH enhancement for PUCCH format 0/1/4 WILUS Inc.
[104b-e-NR-52-71GHz-03] – Steve (Ericsson)
Email discussion/approval on PUCCH format 0/1/4 enhancements with checkpoints for agreements on Apr-15, Apr-20
R1-2103784 FL Summary for Enhancements for PUCCH formats 0/1/4 Moderator (Ericsson)
R1-2104001 FL Summary 2 for Enhancements for PUCCH formats 0/1/4 Moderator (Ericsson)
Agreement:
· The maximum values for the configured number of RBs, NRB, for enhanced PF0/1/4 are at least:
o 12 RBs for 120 kHz SCS
o 3 RBs for 480 kHz SCS
o 2 RBs for 960 kHz SCS
· FFS: Whether or not the above values need to be revised to support larger values (and any associated signaling impact), e.g., to support lower UE Tx beamforming gain and/or larger UE EIRP and conducted power limits for different UE power classes, different from those in the agreed evaluation assumptions
Decision: As per email decision posted on April 17th,
Agreement:
Down select to one of the following two
alternatives for the configuration of the number of RBs, 
, for enhanced PUCCH formats 0/1/4:
· Alt-1:
o For enhanced PF0/1
§
Support configuration of
all integer values in the range [1 .. max()] for each SCS
o For enhanced PF4
§
Support configuration of
all integer values in the range [1 .. max()] for each SCS that fulfill the requirement 
where 
is a set of non-negative integers.
· Alt-2:
o
Same as Alt-1, but with
coarser granularity, i.e., not all integer values of can be configured
o
FFS: Which values of are supported values in the range [1 ..
max()]
Agreement:
For UCI of enhanced PF4, support pre-DFT blockwise spreading using OCCs of length 2 and 4 only, as in Rel-15/16.
Agreement:
For DMRS of enhanced PF4, a Type-1 low PAPR sequence of length equal to the total number of mapped REs of of the PUCCH resource is used. Cyclic shifts are defined in the same was as Rel-15/16 for PF4 (Alt-1 in agreement from RAN1#104-e).
Agreement:
For UCI of enhanced PF4, support pre-DFT blockwise spreading performed across all allocated RBs (Alt-1 in agreement from RAN1#104-e).
From GTW session:
Agreement:
For addressing the FFS from the prior agreement in RAN1#104bis-e on the maximum values for the configured number RBs, send an LS to RAN4 asking for feasible maximum values for UE_EIRP and UE_P for operation in 52.6-71 GHz.
R1-2104060 [DRAFT] LS to RAN4 on maximum UE conducted power and maximum UE EIRP for operation in the 52.6 – 71 GHz band Ericsson
Decision: As per email decision posted on April 20th, the draft LS is endorsed. Final version is approved in R1-2104061.
Agreement:
User-multiplexing can be considered but as lower priority compared to maximum isotropic loss for PUCCH as a design criterion.
Including timing associated with beam-based operation
R1-2102330 Discussion on the beam management procedures for 52-71GHz spectrum Huawei, HiSilicon
R1-2102388 Discussion on beam management OPPO
R1-2102451 Discussion on beam manangement for above 52.6GHz Spreadtrum Communications
R1-2102517 Discussions on beam management for new SCSs for NR operation from 52.6GHz to 71GHz vivo
R1-2102561 Beam Management Aspects Nokia, Nokia Shanghai Bell
R1-2102624 Beam management for new SCSs for up to 71GHz operation CATT
R1-2102705 Beam management discussion for 52.6-71 GHz NR operation MediaTek Inc.
R1-2102775 Beam management for shared spectrum access in Beyond 52.6GHz FUTUREWEI
R1-2102791 Beam Management for New SCSs Ericsson
R1-2102979 Discussion on beam management in NR from 52.6 GHz to 71GHz Xiaomi
R1-2102999 Beam-management enhancements for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2103024 Discussion on Beam management aspects for extending NR up to 71 GHz Intel Corporation
R1-2103099 Beam Management for New SCSs Apple
R1-2103160 Beam management for new SCS for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2103232 Beam management for new SCSs for NR from 52.6 GHz to 71 GHz Samsung
R1-2103297 Beam management enhancement for NR from 52.6GHz to 71GHz Sony
R1-2103342 Enhancements for beam management to support NR above 52.6 GHz LG Electronics
R1-2103413 On Beam Management for Supporting NR from 52.6 GHz to 71 GHz Convida Wireless
R1-2103451 Discussions on beam management for new SCSs InterDigital, Inc.
R1-2103490 Discussion on the beam management for 52.6 to 71GHz ZTE, Sanechips
R1-2103570 Beam based operation for new SCSs for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2103821 FL Summary for Beam Management for new SCSs Moderator (InterDigital, Inc.)
[104b-e-NR-52-71GHz-04] – Youngwoo (InterDigital)
Email discussion/approval on beam management for new SCSs with checkpoints for agreements on Apr-15, Apr-20
R1-2103911 Discussion Summary #1 for Beam Management for new SCSs Moderator (InterDigital Inc.)
R1-2103912 Discussion Summary #2 for Beam Management for new SCSs Moderator (InterDigital Inc.)
Decision: As per email decision posted on April 17th,
Agreement:
Introduce new parameter values for additional beam switching time delay d, when triggering PDCCH with 120kHz or 480kHz has a smaller subcarrier spacing than AP-CSI-RS or PDSCH
From GTW session
Agreement:
For timeDurationForQCL, beamSwitchTiming and beamReportTiming,
· Following candidate values of FR2 are reused for 120 kHz:
o timeDurationForQCL: 14 and 28 symbols
o beamSwitchTiming: 14, 28, 48, 224 and 336 symbols
o beamReportTiming: 14, 28 and 56 symbols
· For 480 kHz
o Support at least the candidate values for 120 kHz scaled by 4x
o FFS: Support for additional candidate value(s)
· For 960 kHz
o Support at least the candidate values for 120 kHz scaled by 8x
o FFS: Support for additional candidate values(s)
· FFS: UE capability signaling details
· Note: The scaled values 224 and 336 symbols for beamSwitchTiming are used as in Rel-16 (defined in Rel-15 with updates in Rel-16).
Agreement:
For multiple PDSCHs/PUSCHs scheduled by a single DCI, at least for single TRP, support indication of only a single TCI state/SRI in DCI
Including defining maximum bandwidth for new SCSs, time line related aspects adapted to each of the new numerologies 480kHz and 960kHz, reference signals, scheduling particularly w.r.t. multi-PDSCH/PUSCH with a single DCI, HARQ, etc.
R1-2102331 PDSCH/PUSCH enhancements for 52-71GHz spectrum Huawei, HiSilicon
R1-2102389 Discussion on PDSCH/PUSCH enhancements OPPO
R1-2102452 Discussion on PDSCH and PUSCH enhancements for above 52.6GHz Spreadtrum Communications
R1-2102518 Discussions on PDSCH/PUSCH enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2102562 PDSCH/PUSCH enhancements Nokia, Nokia Shanghai Bell
R1-2102569 Discussions on scheduling enhancements for PDSCH and PUSCH CAICT
R1-2102625 PDSCH/PUSCH enhancements for up to 71GHz operation CATT
R1-2102716 Considerations on multi-PDSCH/PUSCH with a single DCI and HARQ for NR from 52.6GHz to 71 GHz Fujitsu
R1-2102776 Considerations on PDSCH/PUSCH enhancements FUTUREWEI
R1-2102792 PDSCH-PUSCH Enhancements Ericsson
R1-2102980 PDSCH and PUSCH enhancements for NR 52.6-71GHz Xiaomi
R1-2103000 PDSCH/PUSCH scheduling enhancements for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2103012 PT-RS enhancements for NR from 52.6GHz to 71GHz Mitsubishi Electric RCE
R1-2103025 Discussion on PDSCH/PUSCH enhancements for extending NR up to 71 GHz Intel Corporation
R1-2103100 Discussion on PDSCH/PUSCH enhancements for above 52.6 GHz Apple
R1-2103161 PDSCH/PUSCH enhancements for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2103233 PDSCH/PUSCH enhancements for NR from 52.6 GHz to 71 GHz Samsung
R1-2103298 PDSCH/PUSCH enhancements for NR from 52.6 GHz to 71 GHz Sony
R1-2103343 PDSCH/PUSCH enhancements to support NR above 52.6 GHz LG Electronics
R1-2103407 Discussion on PDSCH and PUSCH enhancements for 52.6GHz – 71GHZ band CEWiT
R1-2103414 PDSCH Considerations for Supporting NR from 52.6 GHz to 71 GHz Convida Wireless
R1-2103452 Discussions on PDSCH/PUSCH enhancements for 52.6 GHz to 71 GHz Band InterDigital, Inc.
R1-2103463 Discussion on multi-PDSCH/PUSCH scheduling for NR 52.6-71 GHz Panasonic Corporation
R1-2103491 Discussion on the data channel enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2103513 Discussion on PDSCH enhancements supporting NR from 52.6GHz to 71 GHz NEC
R1-2103571 PDSCH/PUSCH enhancements for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2103693 Discussion on multi-PDSCH/PUSCH scheduling for NR from 52.6GHz to 71GHz WILUS Inc.
R1-2103726 PDSCH-PUSCH Enhancement Aspects for NR beyond 52.6 GHz Charter Communications
R1-2103817 Summary of PDSCH/PUSCH enhancements (Bandwidth/Timeline/Reference signals) Moderator (vivo)
[104b-e-NR-52-71GHz-05] – Huaming (Vivo)
Email discussion/approval on defining maximum bandwidth for new SCSs, timeline related aspects adapted to each of the new numerologies 480kHz and 960kHz and reference signals with checkpoints for agreements on Apr-16, Apr-20
R1-2103818 Discussion summary #1 of [104b-e-NR-52-71GHz-05] Moderator (vivo)
R1-2103916 Discussion summary #2 of [104b-e-NR-52-71GHz-05] Moderator (vivo)
R1-2104041 Discussion summary #3 of [104b-e-NR-52-71GHz-05] Moderator (vivo)
Agreement:
A model-based approach is not used to derive the timelines for single PDSCH/PUSCH and multi-PDSCH/PUSCH scheduling for NR operation in 52.6 GHz to 71 GHz.
Agreement:
Continue study at least the following aspects for potential PTRS enhancement for DFT-s-OFDM for NR operation in 52.6 to 71 GHz
· The need of potential PTRS enhancement
· PTRS pattern with more PTRS groups within one DFT-s-OFDM symbol when a large number of PRBs is scheduled
o (Ng = 8, Ns = 4, L = 1), (Ng = 16, Ns = 2, L = 1), (Ng = 16, Ns = 4, L = 1),
o Note: Ng number of PT-RS groups, Ns number of samples per PT-RS group, and PTRS every L number of DFT-s-OFDM symbols
o Other patterns are not precluded
· Other aspects of PTRS enhancements are not precluded from further study
Agreement:
· It is recommended to strictly follow and evaluate at least based on assumptions which are not optional in previous agreed LLS assumptions for study of potential RS enhancements for NR operation in 52.6 to 71 GHz.
o Note: evaluation based on optional model/scenario/parameter values are not precluded from being considered for discussion and decisions
· Companies are encouraged to report results (along with previously reported aspects and cubic metric for power boosting aspects) at least for SINR in dB achieving PDSCH/PUSCH BLER of 10% in a numerical and tabular way (e.g. adapted from LLS result report template in SI).
o Note: other ways of presentation of results (e.g. BLER curve) is not precluded
Agreement:
· In Rel-17, for NR operation in 52.6 – 71 GHz, conclude that increased PTRS frequency density is not supported for CP-OFDM at least for Rel-15 PTRS pattern when the allocated number of RB > 32
· Companies are encouraged to study whether to increase PTRS frequency density for small RB allocations for CP-OFDM for NR operation in 52.6 to 71 GHz with respect to phase noise compensation performance
o CPE and ICI PN compensation
§ Note: Results for CPE compensation-only are to be reported for reference
o (K = 0.5, L = 1), (K = 1, L = 1), (K = 2, L = 1),
§ Note: PTRS per K number of PRBs, and PTRS every L number of OFDM symbols
o Number of RBs: 8, 16, 32
o Other values of K and number of RBs are not precluded
· Study on other aspects of potential PTRS enhancement (e.g., decreased PTRS frequency density) is not precluded
R1-2103344 Summary #1 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
[104b-e-NR-52-71GHz-06] – Seonwook (LGE)
Email discussion/approval on scheduling particularly w.r.t. multi-PDSCH/PUSCH with a single DCI, HARQ, with checkpoints for agreements on Apr-16, Apr-20
R1-2103927 Summary #2 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
R1-2104042 Summary #3 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
Agreement:
· The maximum number of PDSCHs that can be scheduled with a single DCI in Rel-17 is 8 for SCS of 480 and 960 kHz.
o FFS: Further restrictions for 480 kHz to 4
o FFS: A UE capability to select between 4 and 8 for 480 kHz SCS
o Note: Multi-PDSCH scheduling for the case of 120 kHz SCS is still FFS as per prior agreement. This case can be addressed after this FFS has been decided.
· The maximum number of PUSCHs that can be scheduled with a single DCI in Rel-17 is 8.
o FFS: Further restrictions for 120 kHz and 480 kHz SCS
o FFS: A UE capability to select between different values for 120 kHz and 480 kHz SCS
Agreement:
For a DCI that can schedule multiple PDSCHs,
· MCS for the 1st TB: This appears only once in the DCI and applies commonly to the first TB of each PDSCH
· NDI for the 1st TB: This is signaled per PDSCH and applies to the first TB of each PDSCH
· RV for the 1st TB: This is signaled per PDSCH, with 2 bits if only a single PDSCH is scheduled or 1 bit for each PDSCH otherwise and applies to the first TB of each PDSCH
· HARQ process number: This applies to the first scheduled PDSCH and is incremented by 1 for subsequent PDSCHs (with modulo operation, if needed)
· FFS:
o MCS/NDI/RV for the 2nd TB for each PDSCH, including whether scheduling of the 2nd TB for each PDSCH can be supported or not
o Details of resource allocation related fields such as VRB-to-PRB mapping, PRB bundling size indicator, rate matching indicator, and ZP CSI-RS trigger
o Whether/how to signal CBGFI/CBGTI if CBGFI/CBGTI is supported for multi-PDSCH scheduling
o Details of fields that are common with multi-PUSCH scheduling, e.g., TDRA, FDRA, priority indicator, including potential enhancements
Agreement:
· For a DCI that can schedule multiple PUSCHs,
o TDRA: Alt 2 (TDRA table is extended such that each row indicates up to 8 multiple PUSCHs (that can be non-continuous in time-domain). Each PUSCH has a separate SLIV and mapping type. The number of scheduled PUSCHs is implicitly indicated by the number of indicated valid SLIVs in the row of the TDRA table signalled in DCI.), as per agreement made in RAN1#104-e
§ FFS: signaling details
o Note: Alt 2 does not preclude continuous resource allocation in time-domain.
· For a DCI that can schedule multiple PDSCHs,
o TDRA: TDRA table is extended such that each row indicates up to 8 multiple PDSCHs (that can be non-continuous in time-domain). Each PDSCH has a separate SLIV and mapping type. The number of scheduled PDSCHs is implicitly indicated by the number of indicated valid SLIVs in the row of the TDRA table signalled in DCI.
§ FFS: signaling details
o Note: This does not preclude continuous resource allocation in time-domain.
o Note: Multi-PDSCH scheduling for the case of 120 kHz SCS is still FFS as per prior agreement. This case can be addressed after this FFS has been decided.
Agreement:
For enhancements of generating type-1 HARQ-ACK codebook corresponding to DCI that can schedule multiple PDSCHs, the following options can be considered,
· Option 1: The set of candidate PDSCH reception occasions is determined according to each SLIV of each row in the TDRA table and based on extension of K1 set
· Option 1a: The set of candidate PDSCH reception occasions is determined according to each SLIV of each row in the TDRA table
· Option 2: The set of candidate PDSCH reception occasions is determined according to the last SLIV of each row in the TDRA table
· FFS: Codebook generation details, including how to handle the collision with TDD DL/UL configuration and whether/how to extend K1 set based on K1 and slot offset between last PDSCH and other PDSCHs in a row in the TDRA table
Conclusion:
The following is observed for alternative 1 from prior agreement.
· For Alt 1 (C-DAI/T-DAI is counted per DCI) of generating type-2 HARQ-ACK codebook corresponding to DCI that can schedule multiple PDSCHs,
o C-DAI/T-DAI in DL DCI: Same DAI overhead with Rel-16 single-PDSCH DCI
o T-DAI in UL DCI:
§ In case of single codebook handling feedback for both single and multi-PDSCH scheduling, same DAI overhead with Rel-16 UL DCI
§ In case of separate sub-codebooks, need additional DAI field (with same bit-width of DAI with Rel-16 UL DCI), in UL DCI for all serving cells including a serving cell not configured with multi-PDSCH DCI
· Note that DAI field increment for this case is similar for the case in Rel-15 where CBG is configured
o HARQ-ACK codebook generation:
§ A separate sub-codebook can be generated when multi-PDSCH DCI is configured for a serving cell, similar to the way as 2nd sub-codebook is defined to handle CBG-based scheduling
· FFS: whether single codebook or separate sub-codebooks is(are) generated when multi-PDSCH DCI is configured for a serving cell
· FFS: how many sub-codebooks are generated when multi-PDSCH DCI is configured for a serving cell and CBG is configured for the serving cell and/or the other serving cell(s)
§ HARQ-ACK payload size is increased compared to single PDSCH scheduling only, since the number of HARQ-ACK bits corresponding to each DAI of the (sub-)codebook for multi-PDSCH DCI in case of separate sub-codebooks (or for all DL DCIs in case of single codebook) depends on the maximum configured number of PDSCHs for multi-PDSCH DCI across serving cells belonging to the same PUCCH cell group.
§ The number of HARQ-ACK bits for multi-PDSCH DCI in case of separate sub-codebooks, or for all DL DCIs in case of single codebook, does not depend on the number of actually scheduled PDSCHs, rather, it is fixed as the maximum configured number of PDSCHs.
§ FFS: time domain bundling of HARQ-ACK feedback, as per agreement in RAN1#104-e
o Note that multi-PDSCH DCI refers to a DL DCI where at least one entry of the TDRA table allows scheduling more than one PDSCH
Decision: As per email decision posted on April 20th,
The following is observed for alternative 2 from prior agreement.
· For Alt 2a (C-DAI/T-DAI is counted per PDSCH with a single codebook) of generating type-2 HARQ-ACK codebook corresponding to DCI that can schedule multiple PDSCHs,
o C-DAI/T-DAI in DL DCI: Bit-width can be increased (FFS: by how much), in DL DCI not only for multi-PDSCH DCI but also for single-PDSCH DCI for all serving cells including a serving cell not configured with multi-PDSCH DCI
o T-DAI in UL DCI: Bit-width can be increased (FFS: by how much), in UL DCI for all serving cells including a serving cell not configured with multi-PDSCH DCI
o C-DAI/T-DAI in DL DCI and T-DAI in UL DCI shall be designed such that at most 3 consecutive DCI missing can be resolved, same as in Rel-15/16 NR.
§ FFS: details on increment of DAI field size
§ FFS: whether/how to handle the case where different DCI formats (e.g., DCI format 1_0 and DCI format 1_1) have different field sizes for C-DAI/T-DAI
o HARQ-ACK codebook generation:
§ The number of HARQ-ACK bits depends on the number of scheduled PDSCHs.
§ FFS: ordering of the PDSCHs for DAI counting
§ FFS: time domain bundling of HARQ-ACK feedback, as per agreement in RAN1#104-e
o Note that multi-PDSCH DCI refers to a DL DCI where at least one entry of the TDRA table allows scheduling more than one PDSCH
Conclusion:
The following is observed for alternative 3 from prior agreement.
· For Alt 3 (C-DAI/T-DAI is counted per M scheduled PDSCH(s), where M is configurable) of generating type-2 HARQ-ACK codebook corresponding to DCI that can schedule multiple PDSCHs,
o If M equals to the maximum configured number of PDSCHs, Alt 3 is the same with Alt 1, if the same number of codebooks is assumed.
o Else if M equals to 1, Alt 3 is the same with Alt 2.
o Otherwise (i.e., 1<M<the maximum configured number of PDSCHs), Alt 3 is similar to Alt 2, except that
§ The number of HARQ-ACK bits corresponding to each DAI increases by M times.
§ NACK bits may be padded if the number of scheduled PDSCHs is not an integer multiple of M.
§ FFS: details on DAI field size
§ FFS: whether single codebook or separate sub-codebooks is(are) generated when multi-PDSCH DCI is configured for a serving cell
o In addition, new RRC parameter to configure M needs to be introduced.
o Note that multi-PDSCH DCI refers to a DL DCI where at least one entry of the TDRA table allows scheduling more than one PDSCH
Final summary in R1-2104104.
R1-2102332 Channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
R1-2102390 Discussion on channel access mechanism OPPO
R1-2102453 Discussion on channel access mechanism for above 52.6GHz Spreadtrum Communications
R1-2102519 Discussions on channel access mechanism for NR operation from 52.6GHz to 71 GHz vivo
R1-2102563 Channel access mechanism Nokia, Nokia Shanghai Bell
R1-2102570 Discussions on channel access mechanism enhancements for 52.6G-71 GHz CAICT
R1-2102626 Channel access mechanism for up to 71GHz operation CATT
R1-2102689 On the channel access mechanisms for 52.6-71 GHz NR operation MediaTek Inc.
R1-2102717 Considerations on channel access mechanism for NR from 52.6GHz to 71 GHz Fujitsu
R1-2102777 Further considerations on channel access for shared spectrum Beyond 52.6 GHz FUTUREWEI
R1-2102793 Channel Access Mechanisms Ericsson
R1-2102981 Channel access mechanism for NR on 52.6-71 GHz Xiaomi
R1-2103001 Channel access mechanisms for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2103026 Discussion on channel access mechanism for extending NR up to 71 GHz Intel Corporation
R1-2103101 Channel access mechanisms for unlicensed access above 52.6GHz Apple
R1-2103162 Channel access mechanism for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2103234 Channel access mechanism for NR from 52.6 GHz to 71 GHz Samsung
R1-2103299 channel access mechanism for 60 GHz unlicensed spectrum Sony
R1-2103345 Channel access mechanism to support NR above 52.6 GHz LG Electronics
R1-2103415 Channel Access for Supporting NR from 52.6 GHz to 71 GHz Convida Wireless
R1-2103427 Channel access for multi-beam operation Panasonic
R1-2103443 Further Discussion of Channel Access Mechanisms AT&T
R1-2103453 Discussion on channel access mechanisms InterDigital, Inc.
R1-2103492 Discussion on the channel access for 52.6 to 71GHz ZTE, Sanechips
R1-2103520 Discussion on channel access mechanism supporting NR from 52.6 to 71GHz NEC
R1-2103572 Channel access mechanism for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2103631 Discussion on multi-beam operation ITRI
R1-2103694 Discussion on channel access mechanism for NR from 52.6GHz to 71GHz WILUS Inc.
R1-2103727 Channel access mechanisms for above 52.6 GHz Charter Communications
[104b-e-NR-52-71GHz-07] – Jing (Qualcomm)
Email discussion/approval on channel access mechanism with checkpoints for agreements on Apr-16, Apr-20
R1-2103791 Email discussion summary for channel access mechanism for 52.6GHz-71GHz band, ver01 Moderator (Qualcomm Incorporated)
R1-2103941 Email discussion summary for channel access mechanism for 52.6GHz-71GHz band, ver02 Moderator (Qualcomm Incorporated)
R1-2104040 Email discussion summary for channel access mechanism for 52.6GHz-71GHz band, ver03 Moderator (Qualcomm Incorporated)
Working assumption:
For Pout in EDT determination, define Pout as the maximum EIRP of the node determining EDT during a COT.
Agreement:
· Contention Exempt Short Control Signaling rules can be applicable to the transmission of SS/PBCH.
o FFS: What are the other DL signals and channels that can be multiplexed with SS/PBCH transmission under Contention Exempt Short Control Signaling rule
o FFS: Whether this can be applied to all supported SCS or specific SCS.
o FFS: Extension to discovery burst if it is defined including signals other than SS/PBCH
o Note: Restriction for short control signalling transmissions apply (10% over any 100ms interval)
· FFS: Other DL signals/channels can be transmitted with Contention Exempt Short Control Signaling rule, such as PDCCH, broadcast PDSCH, PDSCH without user plain data, CSI-RS, PRS, etc
Working assumption:
For energy measurement in 5us observation slot, when performing single measurement, the location of the measurement within the 5us is left for implementation, i.e., anywhere within the 5us.
Agreement:
For LBT for single carrier transmission, continue down selection between
· Alt SC.1. gNB/UE performs LBT over the channel bandwidth (or BWP bandwidth)
· Alt SC.3. Define a unit of LBT bandwidth and gNB/UE performs LBT in all the LBT units (to be transmitted in) in the channel bandwidth
For LBT for multi-carrier transmission in intra-band CA, continue down selection between
· Alt CA.1. gNB/UE performs multiple LBT, one for each channel bandwidth separately
· Alt CA.2. gNB/UE performs single LBT over all CCs
· Alt CA.5. Define a unit of LBT bandwidth and gNB/UE performs LBT in all the LBT units (to be transmitted in) in the channel bandwidth in each CC
Agreement:
For a COT with MU-MIMO (SDM) transmission, when independent per-beam LBT sensing at the start of COT is performed for beams used in the COT (Alt 2 in earlier agreement) is considered, the following alternatives are further considered
· Alt A: The per-beam LBT for different beams is performed in TDM fashion
o Alt A-1: The node completes one eCCA on one beam, and directly move on to the eCCA on the other beam, with no transmission in the middle
o Alt A-2: The node completes one eCCA on one beam, start transmission with the beam to occupy the COT, then move on to the eCCA on the other beam
o Alt A-3: The node performs eCCA of the different beams simultaneous, round robin between different beams
· Alt B: The per-beam LBT for different beams is performed simultaneously in parallel, assuming the node has the capability to simultaneously sense in different beams
Agreement:
Within a COT with TDM of beams with beam switching, when independent per-beam LBT sensing at the start of COT is performed for beams used in the COT (Alt 2 or Alt 3 in earlier agreement) is considered, the following alternatives are further considered
· Alt A: The per-beam LBT for different beams is performed one after another in time domain
o Alt A-1: The node completes one eCCA on one beam, and directly move on to the eCCA on the other beam, with no transmission in the middle
o Alt A-2: The node completes one eCCA on one beam, start transmission with the beam to occupy the COT, then move on to the eCCA on the other beam
o Alt A-3: The node performs eCCA of the different beams simultaneous, round robin between different beams
· Alt B: The per-beam LBT for different beams is performed simultaneously in parallel, assuming the node has the capability to simultaneously sense in different beams
Agreement:
For regions where LBT is not mandated, gNB should indicate to the UE this gNB-UE connection is operating in LBT mode or no-LBT mode. Down-select between
· Alt 1. Support cell specific (common for all UEs in a cell as part of system information or dedicated RRC signalling or both) gNB indication
· Alt 2. Support both cell specific (common for all UEs in a cell as part of system information or dedicated RRC signalling or both) and UE specific (can be different for different UEs in a cell as part of UE-specific RRC configuration) gNB indication
· FFS: Whether the indication of the decision on applying LBT mode or no-LBT mode is per beam (can be different for different UEs in different beams or can be different for different beam pairs between gNB and the UE) or per cell (can be different for different cells for a UE in carrier aggregation)
· FFS: Whether a gNB and its UE(s) can have different mode
· FFS: Whether L1 signalling can be used for both Alt 1 and Alt 2 for gNB indication
Agreement:
For contention exemption short control signalling based DL transmission of SS/PBCH, further consider if the following signals/channels can be multiplexed with SS/PBCH block transmission.
· RMSI PDCCH and RMSI PDSCH
· Other broadcast PDSCH
· PDSCH without user-plane data
· PDCCH
· CSI-RS
· PRS
· Other signals/channels contained in Discovery Burst (i.e., exemption applies to Discovery Burst)
Note: Total exempted signals/channels should meet the restriction of 10% over any 100ms interval.
FFS: If contention exemption short control signalling based DL transmission is allowed when not multiplexed with SS/PBCH block transmission.
Including analysis or recommendation to RAN#92e (June) on how to introduce the 52.6-71GHz frequency range
R1-2102391 Discussion on other aspects OPPO
R1-2102520 Discussions on frequency range definition and sync raster for 52.6-71GHz vivo
R1-2102564 Extending current NR operation to 71 GHz Nokia, Nokia Shanghai Bell
R1-2102627 Views on Frequency Range for 52.6 to 71 GHz CATT
R1-2102794 NR channelization for 52.6 – 71 GHz band Ericsson
R1-2103102 On How to Introduce the 52.6-71GHz Frequency Range Apple
· Proposal 1: it is proposed to narrow down the list of options to Option 2 and 3a for further discussion.
o Option 2: introduce a new range, FR3, for the new frequency range 52.6-71GHz
o Option 3a: introduce a new FR2a and FR2b notation for 24.25-52.6GHz and 52.6-71GHz respectively
· Proposal 2: the following principles should be considered to define the frequency range of 52.6 GHz to 71 GHz
o Ensure flexibility to either reuse FR2 or introduce 60GHz-specific features and requirements
o Ensure that Layer 1 UE features are considered
o Minimize the need for a specifications update
Decision: The document is noted.
R1-2103235 Discussion on defining frequency range for NR from 52.6 to 71 GHz Samsung
R1-2103346 Link level evaluation results for NR above 52.6 GHz LG Electronics
R1-2103393 Link level and system evaluation results for 52-71 GHz Huawei, HiSilicon
R1-2103418 Discussion on frequency range determination for NR extension up to 71GHz Intel Corporation
R1-2103454 Efficient beam management for NR in 52.6 – 71 GHz InterDigital, Inc.
R1-2103493 Discussion on the frequency range definition for above 52.6GHz ZTE, Sanechips
There are three options for defining the frequency range of 52.6-71 GHz. Among the options below, the impact on RAN1 specs is relatively small no matter which option is adopted. RAN plenary should mainly refer to RAN4's analysis/conclusion to make the final decision.
· Alt 1: Maintain the existing FR2 for 24.25~52.6 GHz, and introduce FR3 for 52.6-71 GHz;
· Alt 2: Maintain the existing FR2 for 24.25~52.6 GHz, and introduce FR2b for 52.6-71 GHz;
· Alt 3: Extend the exiting FR2 to cover 24.25~71 GHz, and introduce FR2a for 24.25~52.6GHz and FR2b for 52.6-71GHz. The extended FR2 comprises FR2a and FR2b.
Decision: The document is noted.
R1-2103573 Views on how to introduce 52.6 - 71 GHz frequency range in NR NTT DOCOMO, INC.
Please refer to RP-210862 for detailed scope of the WI
R1-2106230 Session notes for 8.2 (Extending current NR operation to 71GHz) Ad-Hoc Chair (Ericsson)
Including SSB, initial BWP, PRACH, etc.
R1-2104210 Initial access for Beyond 52.6GHz FUTUREWEI
R1-2104273 Initial access signals and channels for 52-71GHz spectrum Huawei, HiSilicon
R1-2104348 Discussions on initial access aspects for NR operation from 52.6GHz to 71GHz vivo
R1-2104416 Discussion on initial access aspects for NR for 60GHz Spreadtrum Communications
R1-2104452 Initial access aspects Nokia, Nokia Shanghai Bell
R1-2104460 Initial Access Aspects Ericsson
R1-2104507 Initial access aspects for up to 71GHz operation CATT
R1-2104659 Initial access aspects for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2104765 Discusson on initial access aspects OPPO
R1-2104833 Discussion on the initial access aspects for 52.6 to 71GHz ZTE, Sanechips
R1-2104894 Discussion on initial access aspects for extending NR up to 71 GHz Intel Corporation
R1-2105061 Considerations on initial access for NR from 52.6GHz to 71 GHz Fujitsu
R1-2105092 Discussion on Initial access signals and channels Apple
R1-2105156 Considerations on initial access aspects for NR from 52.6 GHz to 71 GHz Sony
R1-2105260 Discussion on initial access aspects supporting NR from 52.6 to 71 GHz NEC
R1-2105297 Initial access aspects for NR from 52.6 GHz to 71 GHz Samsung
R1-2105370 Discussion on initial access of 52.6-71 GHz NR operation MediaTek Inc.
R1-2105419 Initial access aspects to support NR above 52.6 GHz LG Electronics
R1-2105495 Initial access aspects for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2105555 On initial access aspects for NR from 52.6GHz to 71 GHz Xiaomi
R1-2105581 Discussions on initial access aspects InterDigital, Inc.
R1-2105592 NR Initial Access from 52.6 GHz to 71 GHz Convida Wireless
R1-2105630 Initial access aspects Sharp
R1-2105988 On the importance of inter-operator PCI confusion resolution and ANR support in 52.6 GHz and beyond AT&T, NTT DOCOMO, INC., T-Mobile USA (rev of R1-2105660)
R1-2105688 Initial access aspects for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2105786 Further details of initial access for NR above 52.6 GHz Charter Communications
R1-2105868 Discussion on initial access aspects for NR beyond 52.6GHz WILUS Inc.
R1-2105977 Issue Summary for initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
[105-e-NR-52-71GHz-01] – Daewon (Intel)
Email discussion/approval on initial access aspects with checkpoints for agreements on May-24, May-27
R1-2105978 Summary #1 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
R1-2106082 Summary #2 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
R1-2106311 Summary #3 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
Agreement:
For 480kHz/960kHz SSB, select one of the following alternatives:
· ALT 1) First symbols of the candidate SSB have index {X, Y} + 14*n, where index 0 corresponds to the first symbol of the first slot in a half-frame
o value of X and Y are identical for 480kHz and 960kHz
§ FFS: exact value of X and Y
· ALT 2) First symbols of the candidate SSB have index {4, 8, 16,20} + 28*n, where index 0 corresponds to the first symbol of the first slot in a half-frame
· Values of n for 480kHz and 960kHz for ALT 1 and 2
o FFS: whether number of values for ‘n’ depend on LBT operation (i.e. LBT vs no-LBT)
o FFS: exact values of ‘n’ for each SCS
o Values of ‘n’ for one mode of operation shall be strictly a subset of values for another mode of operation, if two mode of operation exist for number of candidate SSBs
o FFS: whether values of ‘n’ shall not be all consecutive integer values (i.e. non-candidate SSB slots are positioned every few candidate SSB slots)
Proposal:
In addition to 120kHz, support 480 kHz SSB for initial access with support of CORESET0/Type0-PDCCH configuration in the MIB with following constraints.
· Limited sync raster entry numbers
o It is assumed that RAN4 supports a channelization design which results in the total number of synchronization raster entries considering both licensed and unlicensed operation in a 52.6 – 71 GHz band no larger than 665 (Note: the total number of synchronization raster entries in FR2 for band n259 + n261 is 602). If the assumption cannot be satisfied, it’s up to RAN4 to decide its applicability to bands in 52.6 – 71 GHz.
· only 480kHz CORESTE#0/Type0-PDCCH SCS supported for 480 kHz SSB SCS.
· SSB time domain candidate resource pattern (within a slot or pair of slots) for 480 and 960kHz SSB are identical
· Prioritize support SSB-CORESET0 multiplexing pattern 1. Other patterns discussed on a best effort basis.
· Note: Strive to minimize specification impact by reusing tables for CORESET#0 and type0-PDCCH CSS set configuration defined for FR2 in Rel-15, as much as possible
Formal objection sustained by: Huawei, MediaTek (would like to discuss at next meeting)
Proposal:
In addition to 120kHz, support both 480 and 960 kHz SSB for initial access with support of CORESET0/Type0-PDCCH configuration in the MIB with following constraints.
· Limited sync raster entry numbers
o It is assumed that RAN4 supports a channelization design which results in the total number of synchronization raster entries considering both licensed and unlicensed operation in a 52.6 – 71 GHz band no larger than 665 (Note: the total number of synchronization raster entries in FR2 for band n259 + n261 is 602). If the assumption cannot be satisfied, it’s up to RAN4 to decide its applicability to bands in 52.6 – 71 GHz.
· only 1 CORESTE#0/Type0-PDCCH SCS supported for each SSB SCS i.e., (480,480) and (960,960).
· SSB time domain candidate resource pattern (within a slot or pair of slots) for 480 and 960kHz SSB are identical
· Prioritize support SSB-CORESET0 multiplexing pattern 1. Other patterns discussed on a best effort basis.
· Note: Strive to minimize specification impact by reusing tables for CORESET#0 and type0-PDCCH CSS set configuration defined for FR2 in Rel-15, as much as possible
Formal objection sustained by: Huawei, MediaTek (object to 960 kHz)
Proposal:
To support ANR and PCI confusion detection for 480/960kHz SCS based SSB, support CORESET#0/Type0-PDCCH configuration in MIB of 480 and 960kHz SSB
·
FFS:
additional method(s) to enable support to obtain neighbour cell PCI and SIB1
contents related to CGI reporting
· Only 1 CORESTE#0/Type0-PDCCH SCS supported for each SSB SCS, i.e., (480,480) and (960,960).
· Prioritize support SSB-CORESET0 multiplexing pattern 1. Other patterns discussed on a best effort basis.
· Note: Strive to minimize specification impact by reusing tables for CORESET#0 and type0-PDCCH CSS set configuration defined for FR2 in Rel-15, as much as possible
· Note: From UE perspective, ANR detection for 480/960kHz SCS based SSB is not supported if the UE does not support 480/960 SCS for SSB.
· Note: for ANR, when reading the MIB, the cell containing the SSB is known to the UE, as defined in 38.133 specification.
Formal objection sustained by: Huawei
Agreement:
For the case agreed in RAN1 #104bis-e where 480/960 kHz SSB location and SCS are explicitly provided to the UE (non-initial access)
· Support configuring CORESET#0/Type0-PDCCH for the purpose of ANR/PCI confusion detection by down selecting from the following two alternatives
o Alt 1) Using dedicated signalling
o Alt 2) Using configuration in MIB
§ Note: for ANR, when reading the MIB, the cell containing the SSB is known to the UE, as defined in 38.133 specification.
Agreement:
For 480kHz and 960kHz PRACH,
· Down-select among option 1 and 2
o
Option
1) The reference slot duration corresponds to 60 kHz SCS. A PRACH slot index, 
, corresponds to one of the starting 480/960 kHz PRACH
slots within the reference slot.
§
FFS:
supported values of the starting PRACH slot index 
within reference slot and whether or not
the ROs for a given PRACH configuration can span more than one PRACH slot if
gaps between consecutive ROs are supported for LBT and/or beam switching
purposes
o Option 2) Each 120kHz RO corresponds to 4 and 8 candidate RO positions for 480kHz and 960kHz PRACH, respectively. Information about the number and locations of 480/960kHz candidate RO(s) are configured or pre-selected within each 120kHz RO. The reference 120kHz RO is determined by the current PRACH configuration method in Rel-15/16 specification.
· Following alternatives are considered on PRACH density
o ALT 1) At least the same density (i.e. number of PRACH slots per reference slot) as for 120kHz PRACH in FR2 is supported
§ FFS: support for higher PRACH slot density (number of PRACH slots per reference slot)
o ALT 2) at least the same RO density (i.e. number of RO per reference slot) as for 120kHz PRACH in FR2 is supported
§ FFS: support for higher RO density
o An “example” illustration of PRACH slots for 480/960kHz is shown below:
· FFS: whether and how to account for LBT in RO configuration (if needed)
· FFS: whether and how to account for beam switching gap in RO configuration (if needed)
Agreement:
FFS: Support DBTW at least for 120kHz
, and DBTW length) are supported by dedicated signaling.
in MIB and DBTW
length after UE reads SIB1 or by comparing the value of in MIB and
default DBTW length of 5 ms before UE reads SIB1.
Agreement:
If DBTW is supported,
at least for 120kHz SSB to not exceed 4Void (not be handled during this e-meeting). No contributions please.
R1-2104211 Enhancements of PUCCH formats for Beyond 52.6GHz FUTUREWEI
R1-2106065 Discussions on PUCCH enhancements for NR operation from 52.6GHz to 71GHz vivo (rev of R1-2104349)
R1-2104417 Discussion on enhancements for PUCCH format 0/1/4 for above 52.6GHz Spreadtrum Communications
R1-2104453 Enhanced PUCCH formats 0/1/4 Nokia, Nokia Shanghai Bell
R1-2104461 PUCCH enhancements Ericsson
R1-2104508 Enhancements for PUCCH formats for up to 71GHz operation CATT
R1-2104660 Enhancements for PUCCH for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2104766 Discussion on enhancements for PUCCH format 0/1/4 OPPO
R1-2104834 Discussion on the PUCCH enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2104895 Discussion on PUCCH enhancements for extending NR up to 71 GHz Intel Corporation
R1-2105093 Discussion on Enhancements for PUCCH formats 0/1/4 Apple
R1-2105157 Further considerations on enhancements for PUCCH formats 0/1/4 Sony
R1-2105298 Enhancements for PUCCH format 0/1/4 for NR from 52.6 GHz to 71 GHz Samsung
R1-2105369 On Enhancements for PUCCH formats 0/1 MediaTek Inc.
R1-2105420 Enhancements for PUCCH formats 0/1/4 to support NR above 52.6 GHz LG Electronics
R1-2105496 Enhancements to PUCCH formats 0/1/4 for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2105582 Discussions on enhancements for PUCCH formats 0/1/4 InterDigital, Inc.
R1-2105689 PUCCH format 0/1/4 enhancements for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2105869 Discussion on PUCCH enhancement for PUCCH format 0/1/4 WILUS Inc.
R1-2105929 Enhancement on PUCCH formats Huawei, HiSilicon
R1-2105961 FL Summary for Enhancements for PUCCH formats 0/1/4 Moderator (Ericsson)
[105-e-NR-52-71GHz-02] – Steve (Ericsson)
Email discussion/approval on PUCCH format 0/1/4 enhancements with checkpoints for agreements on May 25, May 27
R1-2106068 FL Summary for [105-e-NR-52-71GHz-02] Email discussion/approval Moderator (Ericsson)
R1-2106288 FL Summary#2 for [105-e-NR-52-71GHz-02] Email discussion/approval Moderator (Ericsson)
From GTW sessions:
Agreement:
Including timing associated with beam-based operation
Void (not be handled during this e-meeting). No contributions please.
Including defining maximum bandwidth for new SCSs, time line related aspects adapted to each of the new numerologies 480kHz and 960kHz, reference signals, scheduling particularly w.r.t. multi-PDSCH/PUSCH with a single DCI, HARQ, etc.
Only to handle multi-PDSCH/PUSCH with a single DCI and HARQ
R1-2104212 Enhancements to support PDSCH/PUSCH for Beyond 52.6GHz FUTUREWEI
R1-2104274 PDSCH/PUSCH enhancements for 52-71GHz spectrum Huawei, HiSilicon
R1-2104350 Discussions on multi-PDSCH/PUSCH scheduling for NR operation from 52.6GHz to 71GHz vivo
R1-2104418 Discussion on PDSCH and PUSCH enhancements for above 52.6GHz Spreadtrum Communications
R1-2104454 PDSCH/PUSCH enhancements Nokia, Nokia Shanghai Bell
R1-2104462 PDSCH-PUSCH Enhancements Ericsson
R1-2104509 PDSCH/PUSCH enhancements for up to 71GHz operation CATT
R1-2104661 PDSCH/PUSCH enhancements for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2104767 Discussion on PDSCH/PUSCH enhancements OPPO
R1-2104835 Discussion on the PDSCH/PUSCH enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2104896 Discussion on PDSCH/PUSCH enhancements for extending NR up to 71 GHz Intel Corporation
R1-2105062 Considerations on multi-PDSCH/PUSCH with a single DCI and HARQ for NR from 52.6GHz to 71 GHz Fujitsu
R1-2105094 Discussion on multi-PxSCH and HARQ Codebook Enhancements Apple
R1-2105158 PDSCH/PUSCH enhancements for NR from 52.6 GHz to 71 GHz Sony
R1-2105259 Discussion on PDSCH enhancements supporting NR from 52.6GHz to 71 GHz NEC
R1-2105299 PDSCH/PUSCH enhancements for NR from 52.6 GHz to 71 GHz Samsung
R1-2105372 HARQ codebook design for 52.6-71 GHz NR operation MediaTek Inc.
R1-2105396 Discussion on PDSCH/PUSCH enhancements for NR 52.6-71 GHz Panasonic Corporation
R1-2105421 PDSCH/PUSCH enhancements to support NR above 52.6 GHz LG Electronics
R1-2105497 PDSCH/PUSCH scheduling enhancements for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2105556 PDSCH and PUSCH enhancements for NR 52.6-71GHz Xiaomi
R1-2105583 Enhancing PDSCH/PUSCH Scheduling for 52.6 GHz to 71 GHz Band InterDigital, Inc.
R1-2105596 PDSCH Considerations for Supporting NR from 52.6 GHz to 71 GHz Convida Wireless
R1-2105690 PDSCH/PUSCH enhancements for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2105784 PDSCH-PUSCH Enhancement for NR beyond 52.6 GHz Charter Communications
R1-2105870 Discussion on multi-PDSCH/PUSCH scheduling for NR from 52.6GHz to 71GHz WILUS Inc.
R1-2105422 Summary #1 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
[105-e-NR-52-71GHz-03] – Seonwook (LG Electronics)
Email discussion/approval on scheduling particularly w.r.t. multi-PDSCH/PUSCH with a single DCI, HARQ, with checkpoints for agreements on May 24, May 27
R1-2106105 Summary #2 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
Agreement:
· Do not use fallback DCI (i.e., DCI formats 0_0 and 1_0) for multi-PDSCH/PUSCH scheduling.
· Use DCI format 0_1 to schedule multiple PUSCHs with a single DCI.
· Use DCI format 1_1 to schedule multiple PDSCHs with a single DCI.
Decision: As per email decision posted on May 25th,
Conclusion:
For a DCI that can schedule multiple PUSCHs,
· CSI-request: When the DCI schedules M PUSCHs, the PUSCH that carries the aperiodic CSI feedback is M-th scheduled PUSCH for M <= 2, or (M-1)-th scheduled PUSCH for M > 2.
Agreement:
· If a PDSCH among multiple PDSCHs that are scheduled by a single DCI is collided with uplink symbol(s) indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated, the UE does not receive the PDSCH.
o FFS on how to handle HARQ-related issue for the PDSCH (e.g., HARQ process numbering)
· The UE does not expect to be scheduled with multiple PDSCHs by a single DCI, where every PDSCH is collided with uplink symbol(s) indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated.
· If a PUSCH among multiple PUSCHs that are scheduled by a single DCI is collided with downlink symbol(s) indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated, the UE does not transmit the PUSCH.
o FFS on how to handle HARQ-related issue for the PUSCH (e.g., HARQ process numbering)
· The UE does not expect to be scheduled with multiple PUSCHs by a single DCI, where every PUSCH is collided with downlink symbol(s) indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated.
Decision: As per email decision posted on May 27th,
For TDRA in a DCI that can schedule multiple PDSCHs (or PUSCHs),
Agreement:
For enhancements of generating type-1 HARQ-ACK codebook corresponding to DCI that can schedule multiple PDSCHs, the set of candidate PDSCH reception occasions corresponding to a UL slot with HARQ-ACK transmission is determined based on a set of DL slots and a set of SLIVs corresponding to each DL slot belonging to the set of DL slots.
Agreement:
· At least for 120 kHz SCS, for a DCI that can schedule multiple PUSCHs and is configured with the TDRA table containing at least one row with multiple SLIVs,
o If CBG-based (re)transmission is configured, CBGTI field is not present when more than one PUSCHs are scheduled, but is present when a single PUSCH is scheduled, as in Rel-16.
· FFS:
o For 480/960 kHz SCS, whether to apply the same behavior with 120 kHz SCS or not to support CBGTI field configuration in the DCI that can schedule multiple PUSCHs
o For a DCI that can schedule multiple PDSCHs and is configured with the TDRA table containing at least one row with multiple SLIVs, whether/how to configure CBGTI/CBGFI fields
Agreement:
If Alt 1 (C-DAI/T-DAI is counted per DCI) is adopted for generating type-2 HARQ-ACK codebook corresponding to a DCI that can schedule multiple PDSCHs,
Agreement:
If Alt 2 (C-DAI/T-DAI is counted per PDSCH) is adopted for generating type-2 HARQ-ACK codebook corresponding to a DCI that can schedule multiple PDSCHs,
R1-2104213 Channel access for shared spectrum Beyond 52.6 GHz FUTUREWEI
R1-2104275 Channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
R1-2104351 Discussions on channel access mechanism for NR operation from 52.6GHz to 71 GHz vivo
R1-2104419 Discussion on channel access mechanism for above 52.6GHz Spreadtrum Communications
R1-2104455 Channel access mechanism Nokia, Nokia Shanghai Bell
R1-2104463 Channel Access Mechanisms Ericsson
R1-2104510 Channel access mechanism for up to 71GHz operation CATT
R1-2104662 Channel access mechanism for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2104720 Discussions on channel access mechanism enhancements for 52.6G-71 GHz CAICT
R1-2104768 Discussion on channel access mechanism OPPO
R1-2104836 Discussion on the channel access for 52.6 to 71GHz ZTE, Sanechips
R1-2104897 Discussion on channel access mechanism for extending NR up to 71 GHz Intel Corporation
R1-2105063 Considerations on channel access mechanism for NR from 52.6GHz to 71 GHz Fujitsu
R1-2105095 Channel access mechanism Apple
R1-2105145 Channel access for multi-beam operation Panasonic
R1-2105159 Channel access mechanism for 60 GHz unlicensed spectrum Sony
R1-2105261 Discussion on channel access mechanism supporting NR from 52.6 to 71GHz NEC
R1-2105300 Channel access mechanism for NR from 52.6 GHz to 71 GHz Samsung
R1-2105371 On the channel access mechanisms for 52.6-71 GHz NR operation MediaTek Inc.
R1-2105423 Channel access mechanism to support NR above 52.6 GHz LG Electronics
R1-2105498 Channel access mechanisms for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2105557 Discussion on channel access mechanism for NR on 52.6-71 GHz Xiaomi
R1-2105584 Discussion on channel access mechanisms InterDigital, Inc.
R1-2105597 On Channel Access Mechanism for NR from 52.6 GHz to 71 GHz Convida Wireless
R1-2105661 On receiver assisted channel access and directional LBT AT&T
R1-2105691 Channel access mechanism for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2105755 Discussion on multi-beam operation ITRI
R1-2105785 Channel access mechanisms for above 52.6 GHz Charter Communications
R1-2105871 Discussion on channel access mechanism for NR from 52.6GHz to 71GHz WILUS Inc.
[105-e-NR-52-71GHz-04] – Jing (Qualcomm)
Email discussion/approval on channel access mechanism with checkpoints for agreements on May 25, May 27
R1-2105986 Contribution summary of channel access mechanism for 52.6GHz-71GHz band, ver01 Moderator (Qualcomm Incorporated)
R1-2106165 Contribution summary of channel access mechanism for 52.6GHz-71GHz band, ver02 Moderator (Qualcomm Incorporated)
From GTW sessions:
Agreement:
For energy measurement in 8us deferral period, continue down-selection between the following alternatives
· Alt 1. Two energy measurements are required, with one measurement in the first 3us and one measurement in the last 5us
· Alt 2. One measurement is required
o FFS where the measurement is located
Note: By implementation, it is possible to support longer than 8us deferral period (Intend to cover Alt 3 as implementation choice for either Alt 1 or Alt 2)
Agreement:
On maximum gap within a COT to allow COT sharing without LBT, down-select or support both of the following two alternatives
· Alt 1. No maximum gap defined. A later transmission can share the COT without LBT with any gap within the maximum COT duration
· Alt 3. Define a maximum gap Y, such that a later transmission can share the COT without LBT only if the later transmission starts within Y from the end of the earlier transmission. If the later transmission starts after Y from the end of the earlier transmission, an one-shot LBT is needed to share the COT
Agreement:
For regions where LBT is not mandated, gNB should indicate to the UE this gNB-UE connection is operating in LBT mode or no-LBT mode
· Support both cell specific (common for all UEs in a cell as part of system information or dedicated RRC signalling or both) and UE specific (can be different for different UEs in a cell as part of UE-specific RRC configuration) gNB indication
R1-2106193 Contribution summary of channel access mechanism for 52.6GHz-71GHz band, ver03 Moderator (Qualcomm Incorporated)
From GTW sessions:
Agreement:
· Contention Exempt Short Control Signalling rules apply to the transmission of msg1 for the 4 step RACH and MsgA for the 2-step RACH for all supported SCS.
o Note restriction for short control signalling transmissions apply (10% over any 100ms intervals)
o Alt 1: The 10% over any 100ms interval restriction is applicable to all available msg1/msgA resources configured (not limited to the resources actually used) in a cell
o Alt 2: The 10% over any 100ms interval restriction is applicable to the msg1/msgA transmission from one UE perspective
· FFS: Other UL signals/channels can be transmitted with Contention Exempt Short Control Signalling rule, such as msg3, SRS, PUCCH, PUSCH without user plain data, etc
Including analysis or recommendation to RAN#92e (June) on how to introduce the 52.6-71GHz frequency range
R1-2104352 Discussions on frequency range definition and sync raster for 52.6-71GHz vivo
R1-2104456 Extending current NR operation to 71 GHz Nokia, Nokia Shanghai Bell
R1-2104464 Introduction of the 52.6 to 71 GHz frequency range Ericsson
R1-2104511 Views on Frequency Range for 52.6 to 71 GHz CATT
R1-2104769 Discussion on other aspects OPPO
R1-2104837 Discussion on the frequency range definition for above 52.6GHz ZTE, Sanechips
R1-2104898 Discussion on frequency range determination for NR extension up to 71GHz Intel Corporation
R1-2105096 On How to Introduce the 52.6-71GHz Frequency Range Apple
R1-2105301 Discussion on defining frequency range for NR from 52.6 to 71 GHz Samsung
R1-2105373 Frequency range naming discussion for 52.6-71 GHz MediaTek Inc.
R1-2105424 Discussion on frequency range definition to support NR above 52.6 GHz LG Electronics
R1-2105533 Discussion on the frequency range for bands in 52.6-71 GHz Huawei, HiSilicon
R1-2105585 Efficient beam management for NR in 52.6 – 71 GHz InterDigital, Inc.
R1-2105692 Views on how to introduce 52.6 - 71 GHz frequency range in NR NTT DOCOMO, INC.
R1-2105787 Discussion on how to introduce the 52.6-71GHz frequency range Charter Communications
[105-e-NR-52-71GHz-05] – Alex (Lenovo)
Email discussion/approval focusing on analysis or recommendation to RAN#92e (June) on how to introduce the 52.6-71GHz frequency range with checkpoints for agreements on May 25, May 27
R1-2106110 FL Summary for discussion [105-e-NR-52-71GHz-05] on analysis or recommendation to RAN#92e (June) on how to introduce the 52.6-71GHz frequency range Moderator (Lenovo)
From GTW sessions:
Conclusion:
Regarding the impact on specifications maintained by RAN1, there are only relatively small differences between potential options
Conclusion:
RAN1 can adapt to other groups' preferences on the notation for 52.6-71 GHz.
Conclusion:
Regardless of if the frequency range 52.6 to 71 GHz is an extension of FR2 or a new FR, the related UE capabilities and their applicability to the frequency range 52.6 to 71 GHz will have to be analysed on a case by case basis
Conclusion:
From RAN1's perspective, an easy distinction between features, capabilities and other characteristics in the specifications that apply specifically to the following ranges may be useful:
NOTE: The distinction can be realized with or without a designated frequency range (FRx) definition.
Include above conclusion with the note in the LS to RAN.
Conclusion:
Regardless of if the frequency range 52.6 to 71 GHz is an extension of FR2 or a new FR, the application of any of the UE feature introduced for 52.6-71 GHz to existing FR1/FR2 should be discussed case by case.
NOTE: This conclusion will not be included in the LS to RAN.
R1-2106276 DRAFT LS on how to introduce the 52.6-71GHz frequency range DRAFT LS on how to introduce the 52.6-71GHz frequency range (rev of R1-2106109)
Decision: The draft LS is endorsed. Final version is approved in R1-2106277.
Final summary in:
R1-2106278 FL Summary#2 for discussion [105-e-NR-52-71GHz-05] on analysis or recommendation to RAN#92e (June) on how to introduce the 52.6-71GHz frequency range Moderator (Lenovo)
Please refer to RP-211584 for detailed scope of the WI
Please also refer to section 5 of RP-211583 for additional guidance for this e-meeting
R1-2108603 Session notes for 8.2 (Extending current NR operation to 71GHz) Ad-Hoc Chair (Ericsson)
Including SSB, initial BWP, PRACH, etc.
R1-2108206 Issue Summary for initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
R1-2106442 Initial access signals and channels for 52-71GHz spectrum Huawei, HiSilicon
R1-2106579 Discussions on initial access aspects for NR operation from 52.6GHz to 71GHz vivo
R1-2106692 Discussion on initial access aspects for NR for 60GHz Spreadtrum Communications
R1-2106766 Discussions on initial access signals and channels for operation in 52.6-71GHz InterDigital, Inc.
R1-2106795 Considerations on initial access aspects for NR from 52.6 GHz to 71 GHz Sony
R1-2106831 Initial access aspects for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2106873 Initial access aspects for NR from 52.6 GHz to 71 GHz Samsung
R1-2106956 Initial access aspects for up to 71GHz operation CATT
R1-2107000 Discussion on the initial access aspects for 52.6 to 71GHz ZTE, Sanechips
R1-2107032 Considerations on initial access for NR from 52.6GHz to 71 GHz Fujitsu
R1-2107050 Initial Access Aspects Ericsson
R1-2107097 Initial access for Beyond 52.6GHz FUTUREWEI
R1-2107104 Initial access aspects Nokia, Nokia Shanghai Bell
R1-2107112 Further discussion of initial access for NR above 52.6 GHz Charter Communications
R1-2107149 Discussion on initial access aspects supporting NR from 52.6 to 71 GHz NEC
R1-2107176 Initial access aspects for NR from 52.6GHz to 71 GHz Panasonic Corporation
R1-2107237 Discusson on initial access aspects OPPO
R1-2107330 Initial access aspects for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2107435 Initial access aspects to support NR above 52.6 GHz LG Electronics
R1-2107471 Discussion on initial access aspects for NR from 52.6 to 71GHz ETRI
R1-2107517 Discussion on initial access of 52.6-71 GHz NR operation MediaTek Inc.
R1-2107577 Discussion on initial access aspects for extending NR up to 71 GHz Intel Corporation
R1-2107726 Initial access signals and channels Apple
R1-2107789 Initial access aspects Sharp
R1-2107845 Initial access aspects for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2107912 On initial access aspects for NR from 52.6GHz to 71 GHz Xiaomi
R1-2108008 NR SSB design consideration from 52.6 GHz to 71 GHz Convida Wireless
R1-2108148 Discussion on initial access aspects for NR beyond 52.6GHz WILUS Inc.
[106-e-NR-52-71GHz-01] – Daewon (Intel)
Email discussion/approval on initial access aspects with checkpoints for agreements on August 19, 24, 27
R1-2108207 Summary #1 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
From GTW session:
Conclusion:
RAN1 will continue discussions to develop solutions for supporting DBTW
Agreement:
· For 480 and 960kHz PRACH:
o
The reference slot duration corresponds to
60 kHz SCS. A PRACH slot index, 
,
corresponds to one of the starting 480/960 kHz PRACH slots within the reference
slot.
R1-2108363 Summary #2 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
From GTW session:
Agreement:
· For 480kHz and 960kHz sub-carrier spacing, first symbols of the candidate SSB have index {2, X} + 14*n, where index 0 corresponds to the first symbol of the first slot in a half-frame.
· Alt 1: X = 8
· Alt 2: X = 9
R1-2108480 Summary #3 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
R1-2108551 Summary #4 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
R1-2108588 Summary #5 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
From GTW session:
Working assumption:
For 120kHz SSB, the number of candidates SSBs in a half frame is 64.
Agreement:
For 480kHz and 960kHz sub-carrier spacing, first symbols of the candidate SSB have index {2, 9} + 14*n, where index 0 corresponds to the first symbol of the first slot in a half-frame.
R1-2108589 Summary #6 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
Decision: As per email decision posted on Aug 27th,
Agreement:
For DBTW with 120kHz SCS (if supported), support DBTW lengths {0.5, 1, 2, 3, 4, 5} msec
· Note: this should be the same as Rel-16 NR-U DBTW lengths.
Agreement:
For ‘controlResourceSetZero’ configuration for {SSB, CORESET#0/Type0-PDCCH} = {480, 480} kHz and {960, 960} kHz,
· Support the following set of parameters.
|
SS/PBCH block and CORESET multiplexing pattern |
Number of
RBs |
Number of
Symbols |
|
1 |
24 |
2 |
|
1 |
48 |
1 |
|
1 |
48 |
2 |
o Note: the number of entries corresponding the same {mux pattern, number of RB, number of symbol} tuple (listed above) will depend on required RB offsets that needs to be supported based on channel and sync raster design.
· FFS: addition other set of parameters
Agreement:
Do not support PRACH length L=571, 1151 for 960kHz PRACH and at least L =1151 for 480kHz PRACH.
Agreement:
For 480 and 960kHz PRACH:
· At least the same RO density in time domain (i.e. number of specified RO per reference slot according the PRACH configuration index) as for 120kHz PRACH in FR2 is supported
o FFS: Support gap between consecutive ROs in time domain and the details to derive the gap
Agreement:
For 480 and 960kHz PRACH,
· When a PRACH slot can contain all time domain PRACH occasions corresponding to a PRACH Config. Index in Table 6.3.3.2-4 of 38.211 including gap(s) between consecutive PRACH occasions (if supported) to account for LBT and/or beam switching,
o and when number of PRACH slots in a reference slot is 1,
§
for 480kHz and 
for 960kHz PRACH
o and when the number of PRACH slots in a reference slot is 2,
§
for 480kHz and 
for 960kHz PRACH
·
FFS: 
values, when a PRACH slot cannot contain all time domain PRACH
occasions, corresponding to a PRACH Config. Index in Table 6.3.3.2-4 of
38.211 including gap(s) between consecutive PRACH occasions (if supported) to
account for LBT and/or beam switching.
·
FFS: whether to allow for
additional 
values if the maximum that can be configured for the number of FD
RO’s is less than 8 (due to BW limitation)
R1-2106443 Enhancement on PDCCH monitoring Huawei, HiSilicon
R1-2106580 Discussions on PDCCH monitoring enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2106767 Discussions on PDCCH monitoring enhancements InterDigital, Inc.
R1-2106796 PDCCH enhancement for 52.6 to 71 GHz Sony
R1-2106832 PDCCH monitoring enhancements for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2106874 PDCCH monitoring enhancements for NR from 52.6 GHz to 71 GHz Samsung
R1-2106957 PDCCH monitoring enhancements for up to 71GHz operation CATT
R1-2107001 Discussion on the PDCCH monitoring enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2107051 PDCCH Monitoring Enhancements Ericsson
R1-2107098 PDCCH and HARQ support for multi-PDSCH/PUSCH scheduling FUTUREWEI
R1-2107105 PDCCH monitoring enhancements Nokia, Nokia Shanghai Bell
R1-2107113 PDCCH monitoring enhancements Charter Communications
R1-2107153 Discussion on PDCCH monitoring enhancements supporting NR from 52.6GHz to 71 GHz NEC
R1-2107238 Discussion on PDCCH monitoring enhancement OPPO
R1-2107331 PDCCH monitoring enhancements for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2107432 PDCCH monitoring for NR operation from 52.6 to 71 GHz Panasonic
R1-2107436 PDCCH monitoring enhancements to support NR above 52.6 GHz LG Electronics
R1-2107510 PDCCH monitoring enhancement for 52.6-71 GHz NR operation MediaTek Inc.
R1-2107578 Discussion on PDCCH monitoring enhancements for extending NR up to 71 GHz Intel Corporation
R1-2107727 PDCCH Enhancements for above 52.6 GHz Apple
R1-2107790 PDCCH monitoring enhancements Sharp
R1-2107846 PDCCH monitoring enhancements for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2107913 Discussion on PDCCH monitoring enhancement for NR 52.6-71GHz Xiaomi
R1-2108015 PDCCH Monitoring for NR from 52.6 GHz to 71 GHz Convida Wireless
[106-e-NR-52-71GHz-02] – Alex (Lenovo)
Email discussion/approval on PDCCH monitoring enhancements with checkpoints for agreements on August 19, 24, 27
R1-2108233 Feature lead summary #1 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
R1-2108389 Feature lead summary #2 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
R1-2108390 Feature lead summary #3 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
From GTW session:
Agreement:
For reporting the multi-slot PDCCH monitoring capability, at least the following values are supported:
· X=4 slots for SCS 480 kHz
· X=8 slots for SCS 960 kHz
Agreement:
· Alt 1: Use a fixed pattern of slot groups as the baseline to define the new capability.
o Each slot group consists of X slots
o Slot groups are consecutive and non-overlapping
o The capability indicates the BD/CCE budget within Y consecutive slots in each slot group separately
o Further discuss down-selection of Y within 1<=Y<=X/2 (both in units of slot) when X>1
o
FFS: Supported
values/constraints of X and Y, e.g. Y<=X, Y=X
o FFS: Restrictions on location of the Y slots within a slot group, e.g. the Y slots always start at the first slot within a slot group
o FFS: Further definition of capabilities
R1-2108559 Feature lead summary #4 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
From GTW session:
Agreement:
Revise prior agreement including modifications to Alt. 1 as follows:
· Alt. 1: Use a fixed pattern of slot groups as the baseline to define the new capability.
o Each slot group consists of X slots
o Slot groups are consecutive and non-overlapping
o
The capability indicates
the BD/CCE budget within Y consecutive slots in each slot group separately
§ The location of the Y slots within the X slots is maintained across different slot groups
o Further discuss down-selection of Y within 1<=Y<=X/2 (both in units of slot) when X>1
o
FFS: Restrictions on
location of the Y slots within a slot group, e.g. the Y slots always start at
the first slot within a slot group
o FFS: Further definition of capabilities
· FFS: The following issues for the search space configuration discussion
o Whether a slot group is aligned with a slot boundary
o Restrictions on location of the Y slots within a slot group, e.g. whether to restrict the location of a SS to be within the first Y slots within a slot group
Agreement:
· A UE supporting 480 kHz SCS supports multi-slot PDCCH monitoring for 480 kHz SCS.
· A UE supporting 960 kHz SCS supports multi-slot PDCCH monitoring for 960 kHz SCS.
· FFS: whether to apply multi-slot PDCCH monitoring at all times and for all search spaces.
R1-2106444 Enhancement on PUCCH formats Huawei, HiSilicon
R1-2106581 Discussions on PUCCH enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2106693 Discussion on enhancements for PUCCH formats 0/1/4 for above 52.6GHz Spreadtrum Communications
R1-2106768 Discussions on enhancements for PUCCH formats 0/1/4 InterDigital, Inc.
R1-2106797 More considerations on PUCCH enhancements for PUCCH formats 0/1/4 Sony
R1-2106833 Enhancements to PUCCH formats 0/1/4 for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2106875 Enhancements for PUCCH format 0/1/4 for NR from 52.6 GHz to 71 GHz Samsung
R1-2106958 Enhancements for PUCCH formats for up to 71GHz operation CATT
R1-2107002 Discussion on the PUCCH enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2107052 PUCCH enhancements Ericsson
R1-2107099 Resource mapping and sequences for PUCCH formats 0/1/4 for 52.6GHz to 71GHz FUTUREWEI
R1-2107106 Enhanced PUCCH formats 0/1/4 Nokia, Nokia Shanghai Bell
R1-2107239 Discussion on enhancements for PUCCH format 0/1/4 OPPO
R1-2107332 Enhancements for PUCCH for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2107437 Enhancements for PUCCH formats 0/1/4 to support NR above 52.6 GHz LG Electronics
R1-2107509 On Enhancements for PUCCH formats 0/1/4 MediaTek Inc.
R1-2107579 Discussion on PUCCH enhancements for extending NR up to 71 GHz Intel Corporation
R1-2107728 Discussion on Enhancements for PUCCH formats 0/1/4 above 52.6 GHz Apple
R1-2107847 PUCCH format 0/1/4 enhancements for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2108149 Discussion on PUCCH enhancement for PUCCH format 0/1/4 WILUS Inc.
[106-e-NR-52-71GHz-03] – Steve (Ericsson)
Email discussion/approval on enhancements for PUCCH formats 0/1/4 with checkpoints for agreements on August 19, 24, 27
R1-2107774 FL Summary for [106-e-NR-52-71GHz-03] Email discussion/approval on enhancements for PUCCH formats 0/1/4 Moderator (Ericsson)
From GTW session:
Conclusion:
For enhanced (multi-RB) PF4, maintain the same maximum UCI payload limit as in Rel-15/16 (115 bits).
Agreement:
· For enhanced (multi-RB) PF4, the UCI payload is rate matched to the configured number of RBs, N_RB
· Note: This is analogous to Rel-16 for PF2/3 when interlacing is configured when there is a fixed number of RBs for the configured interlace(s).
Agreement:
· Support an RRC parameter to configure the number of RBs for a PUCCH resource for each of enhanced PUCCH formats 0, 1, and 4
· The parameter is provided by dedicated signaling (per UE) per BWP
Decision: As per email decision posted on Aug 20th,
For PF0/1 for PUCCH resource sets prior to RRC configuration, Alt-2 (sub-PRB interlaced mapping) is not supported.
R1-2108433 FL Summary #2 for [106-e-NR-52-71GHz-03] Email discussion/approval on enhancements for PUCCH formats 0/1/4 Moderator (Ericsson)
From GTW session:
Agreement:
In the following, Alt-1 and Alt-2 refer to the RE mapping agreement for 120 kHz from RAN1#105-e:
· For enhanced PF0/1, for PUCCH resources after RRC configuration, Alt-2 (sub-PRB interlaced mapping) is not supported.
· For DMRS of enhanced PF4, only Alt-1 is supported (all REs within each RB are mapped).
· Note: optimization of user multiplexing for enhanced PUCCH format 0/1/4 is not considered in Rel-17.
Agreement:
· For PUCCH resource sets prior to RRC configuration, support a parameter in SIB1 that indicates the number of RBs for enhanced (multi-RB) PUCCH format 0/1
Agreement:
The maximum configured number of RBs, N_RB, for enhanced PF 0/1/4 is given by 16 RBs for 120 kHz SCS.
R1-2108523 FL Summary #3 for [106-e-NR-52-71GHz-03] Email discussion/approval on enhancements for PUCCH formats 0/1/4 Moderator (Ericsson)
Decision: As per email decision posted on Aug 26th,
Agreement:
For the agreed RRC parameter that configures the number of RBs for a PUCCH resource, the value range is given by the following, where N_RB_Max is the maximum number of RBs per SCS value
where 
is a set of non-negative integers
From GTW session:
Agreement:
The maximum configured number of RBs, N_RB, for enhanced PF 0/1/4 is given by 16 RBs for 480 and 960 kHz SCS (same as for 120 kHz SCS).
Agreement:
For enhanced PF0/1 support a single sequence of length equal to the total number of mapped Res of of the PUCCH resource is used. Cyclic shifts for PF0/1 are defined in the same way as Rel-16 for the case that useInterlacePUCCH-PUSCH is not configured.
· Note: this is Alt-1 from the RAN1#104 agreement
Final summary in R1-2108624.
Including timing associated with beam-based operation
R1-2106445 Discussion on the beam management procedures for 52-71GHz spectrum Huawei, HiSilicon
R1-2106582 Discussions on beam management for new SCSs for NR operation from 52.6GHz to 71GHz vivo
R1-2106694 Discussion on beam management for above 52.6GHz Spreadtrum Communications
R1-2106769 Discussions on beam management for new SCSs InterDigital, Inc.
R1-2106798 Beam management enhancement for NR from 52.6GHz to 71GHz Sony
R1-2106834 Beam-management enhancements for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2106876 Beam management for new SCSs for NR from 52.6 GHz to 71 GHz Samsung
R1-2106959 Beam management for new SCSs for up to 71GHz operation CATT
R1-2107003 Discussion on the beam management for 52.6 to 71GHz ZTE, Sanechips
R1-2107053 Beam Management for New SCSs Ericsson
R1-2107101 Views on Beam management for beyond B52.6 GHz FUTUREWEI
R1-2107107 Beam Management Aspects Nokia, Nokia Shanghai Bell
R1-2107155 Beam management enhancement for NR from 52.6GHz to 71GHz NEC
R1-2107240 Discussion on beam management for new SCSs OPPO
R1-2107333 Beam managment for new SCS Qualcomm Incorporated
R1-2107438 Enhancements for beam management to support NR above 52.6 GHz LG Electronics
R1-2107511 Beam management discussion for 52.6-71 GHz NR operation MediaTek Inc.
R1-2107580 Discussion on Beam management aspects for extending NR up to 71 GHz Intel Corporation
R1-2107729 Beam Management for New SCSs Apple
R1-2107848 Beam based operation for new SCSs for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2107914 Discussion on beam management for new SCSs Xiaomi
R1-2108016 On Beam Management for NR from 52.6 GHz to 71 GHz Convida Wireless
[106-e-NR-52-71GHz-04] – Youngwoo (InterDigital)
Email discussion/approval on beam management for new SCSs with checkpoints for agreements on August 19, 24, 27
R1-2108260 Discussion Summary #1 of Beam Management for New SCSs Moderator (InterDigital, Inc.)
From GTW session:
Agreement:
For maxNumberRxTxBeamSwitchDL,
· Support at least 2 and 4 as candidate values for 480 kHz
o FFS: 7
· Support at least 2 as a candidate value for 960 kHz
o FFS: Support for additional candidate value(s) including 4
R1-2108261 Discussion Summary #2 of Beam Management for New SCSs Moderator (InterDigital, Inc.)
From GTW session:
Agreement:
For the threshold
values 48 or 48+ 
mentioned in Clauses 5.2.1.5.1
and 5.2.1.5.1a of 38.214, scale 48 to 4*48 for 480 kHz and 8*48 for 960 kHz.
R1-2108541 Discussion Summary #3 of Beam Management for New SCSs Moderator (InterDigital, Inc.)
R1-2108542 Discussion Summary #4 of Beam Management for New SCSs Moderator (InterDigital, Inc.)
From GTW session:
Agreement:
For maxNumberRxTxBeamSwitchDL,
· For 480 kHz, support 7 as a candidate value for 480 kHz in addition to the agreed candidate values 2 and 4
· For 960 kHz, support one of the following alternatives
o Alt-1: Support 1, 4 and [7] as candidate values for 960 kHz in addition to the agreed candidate values 2
o Alt-2: Support 4 as a candidate value for 960 kHz in addition to the agreed candidate values 2
· No additional candidate values are supported
Working assumption:
For multi-PDSCH scheduling for multi-TRPs, support a single DCI field ‘Transmission Configuration Indication’ as in Rel-16 TCI state indication mechanism for multi-TRPs
Agreement:
For the single TRP case, For multi-PDSCHs scheduled by a single DCI with a single DCI field ‘Transmission Configuration Indication’ that indicates a single TCI state (if the DCI field is present),
R1-2108654 Discussion Summary #5 of Beam Management for New SCSs Moderator (InterDigital, Inc.)
Decision: As per email decision posted on Aug 27th,
Agreement:
For candidate values of timeDurationForQCL, beamSwitchTiming and beamReportTiming,
· Support one of the following alternatives
o Alt-1: No additional candidate values are supported for 120 kHz, 480 kHz and 960 kHz
o Alt-2: 28 and 56 symbols are supported as additional candidate values for 480 kHz and 960 kHz, respectively
· For UE capability signaling, UE reports one value of the candidate values in OFDM symbols per each SCS
Agreement:
o Alt-1: 14 symbols
o Alt-2: 28 symbols
Including defining maximum bandwidth for new SCSs, time line related aspects adapted to each of the new numerologies 480kHz and 960kHz, reference signals, scheduling particularly w.r.t. multi-PDSCH/PUSCH with a single DCI, HARQ, etc.
R1-2106446 PDSCH/PUSCH enhancements for 52-71GHz spectrum Huawei, HiSilicon
R1-2106569 PT-RS enhancements for NR from 52.6GHz to 71GHz Mitsubishi Electric RCE
R1-2106583 Discussions on PDSCH/PUSCH enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2106695 Discussion on PDSCH and PUSCH enhancements for above 52.6GHz Spreadtrum Communications
R1-2106770 PDSCH/PUSCH enhancements for supporting NR from 52.6GHz to 71 GHz InterDigital, Inc.
R1-2106799 PDSCH/PUSCH enhancements for NR from 52.6 GHz to 71 GHz Sony
R1-2106835 PDSCH/PUSCH scheduling enhancements for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2106877 PDSCH/PUSCH enhancements for NR from 52.6 GHz to 71 GHz Samsung
R1-2106960 PDSCH/PUSCH enhancements for up to 71GHz operation CATT
R1-2107004 Discussion on the data channel enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2107033 Considerations on multi-PDSCH/PUSCH with a single DCI and HARQ for NR from 52.6GHz to 71 GHz Fujitsu
R1-2107039 Enhancements of PDSCH/PUSCH Scheduling for 52.6 GHz to 71 GHz Band CEWiT
R1-2107054 PDSCH-PUSCH Enhancements Ericsson
R1-2107100 Enhancements of PDSCH/PUSCH and scheduling for 52.6GHz to 71GHz FUTUREWEI
R1-2107108 PDSCH/PUSCH enhancements Nokia, Nokia Shanghai Bell
R1-2107154 Discussion on PDSCH enhancements supporting NR from 52.6GHz to 71 GHz NEC
R1-2107241 Discussion on PDSCH/PUSCH enhancements OPPO
R1-2107334 PDSCH/PUSCH enhancements for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2107439 PDSCH/PUSCH enhancements to support NR above 52.6 GHz LG Electronics
R1-2107512 Multi-PDSCH scheduling design for 52.6-71 GHz NR operation MediaTek Inc.
R1-2108334 Discussion on PDSCH/PUSCH enhancements for extending NR up to 71 GHz Intel Corporation (rev of R1-2107581)
R1-2107730 Discussion on PDSCH and PUSCH Enhancements for NR above 52.6 GHz Apple
R1-2107829 Discussion on PDSCH/PUSCH enhancements for NR 52.6-71 GHz Panasonic Corporation
R1-2107849 PDSCH/PUSCH enhancements for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2107915 PDSCH and PUSCH enhancements for NR 52.6-71GHz Xiaomi
R1-2108010 Discussion on multiple PDSCHs scheduled by a DCI ITRI
R1-2108017 NR PDSCH design consideration from 52.6 GHz to 71 GHz Convida Wireless
R1-2108150 Discussion on multi-PDSCH/PUSCH scheduling for NR from 52.6GHz to 71GHz WILUS Inc.
[106-e-NR-52-71GHz-05] – Huaming (Vivo)
Email discussion/approval on defining maximum bandwidth for new SCSs, timeline related aspects adapted to each of the new numerologies 480kHz and 960kHz and reference signals with checkpoints for agreements on August 19, 24 and 27
R1-2108212 Summary of PDSCH/PUSCH enhancements (Bandwidth/Timeline/Reference signals) Moderator (vivo)
R1-2108284 Discussion summary #1 of [106-e-NR-52-71GHz-05] Moderator (vivo)
From GTW session:
Agreement:
For NR operation with 480 kHz and/or 960 kHz SCS, value(s) for PDSCH processing time (N1) for PDSCH processing capability 1 and PUSCH preparation time (N2) are to be defined for PDSCH/PUSCH timing capability 1 only.
Agreement:
For NR operation with 480 kHz and/or 960 kHz SCS, only value(s) for CSI computation delay requirement 2 are to be defined.
R1-2108329 Discussion summary #2 of [106-e-NR-52-71GHz-05] Moderator (vivo)
From GTW session:
Agreement:
When defining value ranges and/or default values for k0/k1/k2 for NR operation with 480 and 960 kHz SCS, RAN1 assumes the following definitions (this agreement does not define the following and these definitions may be updated later)
· The value of k0 indicates the slot offset between DCI and its scheduled PDSCH in number of slots
· The value of k1 indicates the slot offset between the slot of the last PDSCH scheduled by the DCI and the slot carrying the HARQ-ACK information corresponding to the scheduled PDSCHs in number of slots
· The value of k2 indicates the slot offset between DCI and its scheduled PUSCH in number of slots
· Note: Default values are indicated by DCI format 1_0 and 0_0
Agreement:
· For 480 kHz and/or 960 kHz SCS, for rank 1 PDSCH at least with DMRS type-1, support a configuration of DMRS where the UE is able to assume that FD-OCC is not applied.
o Note: “FD-OCC is not applied” refers to the UE may assume that a set of remaining orthogonal antenna ports are not associated with the PDSCH to another UE, wherein the set of remaining orthogonal antenna ports are within the same CDM group and have different FD-OCC
o FFS whether applies to DMRS type-2
o Down select between the following options for the indication to UE
§ RRC configuration
§ antenna port(s) field in DCI scheduling the rank 1 PDSCH
Agreement:
For NR operation with 480 and 960 kHz SCS, adopt at least the values of N1, N2 and N3 as in the following tables for single and multi-PDSCH/PUSCH scheduling.
· Note: N1/N2 applies to any PDSCH/PUSCH for multi-PDSCH/PUSCH scheduling
· RAN1 to study (until RAN1#106b-e) and possibly introduce smaller values considering at least the following factors
o PDCCH monitoring capability
o Mix numerology scheduling
o Multi-PDSCH/PUSCH scheduling
o Cross-carrier scheduling
· Note: The decision for the number of HARQ processes should take this agreement into account.
Table 2-2.1 PDSCH processing time arrange for PDSCH processing capability 1
|
|
PDSCH decoding time N1 [symbols] |
|
|
dmrs-AdditionalPosition = pos0 in |
dmrs-AdditionalPosition ≠ pos0 in or if the higher layer parameter is not configured |
|
|
3 (120 kHz) |
20 |
24 |
|
5 (480 kHz) |
80 |
96 |
|
6 (960 kHz) |
160 |
192 |
Table 2-2.2 PUSCH preparation time for PUSCH timing capability 1
|
|
PUSCH preparation time N2 [symbols] |
|
3 (120 kHz) |
36 |
|
5 (480 kHz) |
144 |
|
6 (960 kHz) |
288 |
Table 2-2.3 Minimum gap between the second detected DCI and the beginning of the first PUCCH resources
|
|
HARQ-ACK multiplexing timeline N3 [symbols] |
|
3 (120 kHz) |
20 |
|
5 (480 kHz) |
80 |
|
6 (960 kHz) |
160 |
R1-2108487 Discussion summary #3 of [106-e-NR-52-71GHz-05] Moderator (vivo)
Decision: As per email decision posted on Aug 26th,
Agreement:
Further study and conclude on whether to introduce any PTRS enhancement for CP-OFDM by RAN1#106b.
· Note: details of specification impact for any proposed PTRS enhancement shall be provided to facilitate drawing conclusion in RAN1#106b
Agreement:
Further study and conclude on whether to introduce K=1 for Rel-15 PTRS pattern for CP-OFDM with small (< =32) RB allocation by RAN1#106b.
Agreement:
Further study and conclude on whether to introduce (Ng = 16, Ns = 2, L = 1) and/or (Ng = 16, Ns = 4, L = 1) for DFT-s-OFDM by RAN1#106b.
· Note: Ng number of PT-RS groups, Ns number of samples per PT-RS group, and PTRS every L number of DFT-s-OFDM symbols
· FFS applicable to which RB allocation(s) if agreed to introduce (Ng = 16, Ns = 2, L = 1) and/or (Ng = 16, Ns = 4, L = 1)
From GTW session:
Agreement:
For NR operation with 480 and 960 kHz SCS, adopt at least the values of Z1, Z2 and Z3 as in the following table for single and multi-PDSCH/PUSCH scheduling to maintain the same absolute time duration as that of 120 kHz SCS in FR2.
is
UE reported capability beamReportTiming; KB3 and KB4
is UE reported capability beamSwitchTiming for 480 and 960 kHz SCS
respectively.
Table 2-4. CSI computation delay requirement 2
|
|
Z1 [symbols] |
Z2 [symbols] |
Z3 [symbols] |
|||
|
Z1 |
Z'1 |
Z2 |
Z'2 |
Z3 |
Z'3 |
|
|
3 |
97 |
85 |
152 |
140 |
min(97, X3+ KB2) |
X3 |
|
5 |
388 |
340 |
608 |
560 |
[min(388, X5+ KB3)] |
[X5] |
|
6 |
776 |
680 |
1216 |
1120 |
[min(776, X6+ KB4)] |
[X6] |
Conclusion:
In Rel-17, for NR operation with 480 kHz and/or 960 kHz SCS, new DMRS pattern with increased frequency domain density is not supported.
[106-e-NR-52-71GHz-06] – Seonwook (LGE)
Email discussion/approval on scheduling particularly w.r.t. multi-PDSCH/PUSCH with a single DCI, HARQ, with checkpoints for agreements on August 19, 24 and 27
R1-2107440 Summary #1 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
From GTW session:
Working assumption:
Scheduling multiple PDSCHs by single DL DCI applies to 120 kHz in addition to 480 and 960 kHz at least in FR2-2.
· FFS: Further limitations on maximum number of PDSCHs
Agreement:
Adopt Alt 1 (C-DAI/T-DAI is counted per DCI) for generating type-2 HARQ-ACK codebook corresponding to a DCI that can schedule multiple PDSCHs.
R1-2108333 Summary #2 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
R1-2108370 Summary #3 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
Decision: As per email decision posted on Aug 24th,
Agreement:
· The maximum number of PDSCHs/PUSCHs that can be scheduled with a single DCI in Rel-17 is 8 for SCS of 120, 480 and 960 kHz.
· FFS: Whether UE capability is introduced for restricting the maximum number of PDSCHs or PUSCHs that can be scheduled with a single DCI
Agreement:
If a scheduled PDSCH/PUSCH is dropped due to collision with UL/DL symbol(s) indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated, HARQ process number increment is skipped for the PDSCH/PUSCH and applied only for valid PDSCH(s)/PUSCH(s).
Agreement:
Agreement:
For TDRA in a DCI that can schedule multiple PDSCHs (or PUSCHs),
· A row of the TDRA table can indicate PDSCHs (or PUSCHs) that are in consecutive or non-consecutive slots, by configuring {SLIV, mapping type, scheduling offset K0 (or K2)} for each PDSCH (or PUSCH) in the row of TDRA table.
· Note: Whether and how to reduce RRC overhead is left to RAN2.
Agreement:
For a DCI that can schedule multiple PDSCHs,
· Each of VRB-to-PRB mapping, PRB bundling size indicator, ZP-CSI-RS trigger, and rate matching indicator fields appears only once in the DCI.
· VRB-to-PRB mapping and PRB bundling size indicator fields are applied to all the PDSCHs scheduled by the DCI.
· For ZP-CSI-RS trigger field, the triggered aperiodic ZP CSI-RS is applied to all the slot(s) in which the PDSCH(s) scheduled by the DCI are contained.
· When receiving a PDSCH scheduled by the DCI, the REs corresponding to configured resources in rateMatchPatternGroup1 or rateMatchPatternGroup2 (according to indication of rate matching indicator field) are not available for the scheduled PDSCH.
From GTW session
Working assumption:
For NR FR2-2, two codeword transmission is supported, subject to UE capability.
· RRC parameter configures whether two codeword transmission is enabled or disabled.
o FFS: Details on signaling of MCS/NDI/RV for the second TB in a DCI that can schedule multiple PDSCHs when two codeword transmission is enabled
o FFS: Whether unified or separate parameter to enable/disable 2-TB for single and for multiple PDSCH scheduling
o Strive to minimize the increase in the number of bits in the DCI needed to support this feature
R1-2108550 Summary #4 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
R1-2108590 Summary #5 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
From GTW session:
Agreement:
· For single TRP operation, for 480/960 kHz SCS,
o FFS: A UE does not expect to be scheduled with more than one PDSCH in a slot, by a single DCI or multiple DCIs.
o FFS: A UE does not expect to be scheduled with more than one PUSCH in a slot, by a single DCI or multiple DCIs.
· For single TRP operation, for 120 kHz SCS (same as current specification for FR2-1 for PUSCH),
o Subject to UE capability, a UE can be scheduled with more than one PDSCH in a slot, by a single DCI or multiple DCIs.
o Subject to UE capability, a UE can be scheduled with more than one PUSCH in a slot, by a single DCI or multiple DCIs.
· FFS for multi-TRP operation
· Note: The optimization of HARQ codebook size for Type 1 or Type 2 codebook design is considered as a low priority in Rel-17 (this does not preclude HARQ ACK bundling in time domain).
· The agreement made in RAN1#105-e is revised as follows.
|
Agreement: (RAN1#105-e) For enhancements of generating type-1 HARQ-ACK codebook corresponding to DCI that can schedule multiple PDSCHs, the set of candidate PDSCH reception occasions corresponding to a UL slot with HARQ-ACK transmission is determined based on a set of DL slots and a set of SLIVs corresponding to each DL slot belonging to the set of DL slots. ·
The set of DL slots ·
The set of SLIVs
corresponding to a DL slot (belonging to the set of DL slots) · The Rel-16 procedure is reused for determining the candidate PDSCH reception occasions for the set of SLIVs corresponding to each DL slot belonging to the set of DL slots o Note: The Rel-16 procedure already handles pruning of multiple SLIVs corresponding to a DL slot, for both UEs that are and are not capable of receiving multiple PDSCHs per slot
o FFS impact of time domain bundling, if supported |
Decision: As per email decision posted on Aug 27th,
Agreement:
Consider the following options to construct type-2 HARQ-ACK codebook when CBG operation is configured, and down-select to one of the following options in RAN1#106bis-e.
Agreement:
For NR FR2-2 at least for 480/960 kHz SCS, support 32 as the maximum number of HARQ processes for DL and UL, subject to UE capability.
Final summary in R1-2108636.
R1-2106447 Channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
R1-2106584 Discussions on channel access mechanism for NR operation from 52.6GHz to 71 GHz vivo
R1-2106696 Discussion on channel access mechanism for above 52.6GHz Spreadtrum Communications
R1-2106771 Discussion on channel access mechanisms InterDigital, Inc.
R1-2106800 Channel access mechanism for 60 GHz unlicensed spectrum Sony
R1-2106836 Channel access mechanisms for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2106878 Channel access mechanism for NR from 52.6 GHz to 71 GHz Samsung
R1-2106961 Channel access mechanism for up to 71GHz operation CATT
R1-2107005 Discussion on the channel access for 52.6 to 71GHz ZTE, Sanechips
R1-2107034 Considerations on receiver assistance in channel access Fujitsu
R1-2107055 Channel Access Mechanisms Ericsson
R1-2107102 Channel access for shared spectrum Beyond 52.6 GHz FUTUREWEI
R1-2107109 Channel access mechanism Nokia, Nokia Shanghai Bell
R1-2107111 Channel access mechanisms for NR above 52 GHz Charter Communications
R1-2107150 Discussion on channel access mechanism supporting NR from 52.6 to 71GHz NEC
R1-2107166 Discussions on channel access mechanism enhancements for 52.6-71 GHz CAICT
R1-2107242 Discussion on channel access mechanism OPPO
R1-2107335 Channel access mechanism for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2107386 Channel access for multi-beam operation Panasonic
R1-2107441 Channel access mechanism to support NR above 52.6 GHz LG Electronics
R1-2107518 On the channel access mechanisms for 52.6-71 GHz NR operation MediaTek Inc.
R1-2107582 Discussion on channel access mechanism for extending NR up to 71 GHz Intel Corporation
R1-2107691 Views on Rel. 17 channel access enhancements AT&T
R1-2107731 Channel access mechanisms for unlicensed access above 52.6GHz Apple
R1-2107850 Channel access mechanism for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2107916 Discussion on channel access mechanism for NR on 52.6-71 GHz Xiaomi
R1-2108011 Discussion on multi-beam operation ITRI
R1-2108018 Discussion On Channel Access for NR from 52.6 GHz to 71 GHz Convida Wireless
R1-2108099 Discussion on EDT enhancement in channel access for NR unlicensed operation from 52.6 to 71GHz GDCNI
R1-2108151 Discussion on channel access mechanism for NR from 52.6GHz to 71GHz WILUS Inc.
[106-e-NR-52-71GHz-07] – Jing (Qualcomm)
Email discussion/approval on channel access mechanism with checkpoints for agreements on August 19, 24 and 27
R1-2108223 FL summary for channel access for beyond 52.6GHz band Moderator (Qualcomm Incorporated)
From GTW session:
Agreement:
For energy measurement in 8us deferral period, at least a single measurement within 8us is performed, and the measurement duration is selected from one of the following alternatives:
· Alt 1: At least 3+X us (FFS X, such as X=1).
· Alt 2: At least X us, where X is the same as the minimum measurement duration in a 5 us observation slot and is within the 5 us observation slot.
· Alt 3: At least a contiguous duration of X+Y us where the Y us part of the measurement is done at the end of the first 3 us and X is the same as the minimum measurement duration in a 5 us observation slot and is at the beginning of the 5 us duration.
R1-2108367 FL summary#2 for channel access for beyond 52.6GHz band Moderator (Qualcomm Incorporated)
Conclusion:
There is no consensus in RAN1 to support the functionality of accessing a carrier if there is interference in part of the carrier in frequency.
R1-2108554 FL summary#3 for channel access for beyond 52.6GHz band Moderator (Qualcomm Incorporated)
From GTW session:
Agreement:
On COT sharing from an initiating device transmission to responding device transmission, support both of the following two alternatives
· Alt 1: No maximum gap defined between the initiating device transmission and responding device transmission. A responding device transmission can occur without LBT with any gap within the maximum COT duration
· Alt 3: Define a maximum gap Y, such that a responding device transmission can occur without LBT only if the transmission starts within Y from the end of the initiating device transmission. If the responding device transmission starts after Y from the end of the initiating device transmission, a Cat 2 LBT is needed before the responding device transmission.
o The Cat 2 LBT uses the same sensing structure as the 8 us initial deferral period as in eCCA
o Further down-select between the following options:
§ Option 1: Y=8 us (motivated by need to operate in all regions)
§ Option 2: Y=a multiple number of OFDM symbols
§ Option 3: gNB determines Y (for example, according to local regulation)
Note: Alt. 3 is motivated by the regulations in Japan, but use of Cat. 3 LBT is also an option for operation in Japan and Cat. 2 LBT is not restricted for use only in Japan.
Note: Maximum gap allowed without Cat 2 LBT between two initiating device transmissions is to be separately discussed
Note: Other use cases of Cat 2 LBT will be separately discussed
Agreement:
· For LBT for single carrier transmission, gNB/UE performs LBT over the channel bandwidth (or BWP bandwidth) (Alt SC.1. in earlier agreements)
· For LBT for multi-carrier transmission in intra-band CA, gNB/UE performs multiple LBT, one for each channel bandwidth separately (Alt CA.1. in earlier agreements)
o FFS: Additional support of performing single LBT over all CCs (Alt CA.2. in earlier agreements)
Agreement:
For energy measurement in 8us deferral period, Alt 2 is supported while Alt 1 and Alt 3 can be considered as gNB/UE implementation (Alt. 1/2/3 are defined as per previous agreement)
Agreement:
3GPP specification consider defining at least the relative relationship between all applicable sensing beam(s) and the transmission beam(s) to define sensing beam for LBT, where at least sensing beam(s) “covers” the transmission beam(s), considering following alternatives. Target down-selection by RAN1 #106bis-e
· Alt 1: Specify necessary requirement/test procedure to guarantee sensing beam “covers” the transmission beam
o Some methods to define “cover” have been discussed in RAN1 (may further down select the list) and are considered as acceptable from RAN1 perspective
§ Alt-1A: the angle included in the [3] dB beamwidth of the transmission beam is included in the [X, FFS] dB beamwidth of the sensing beam.
§ Alt-1B: the sensing beam gain measured along the direction of peak transmission direction is at least X [FFS] dB of the transmission beam gain
§ Alt-1C: The sensing beam gain is measured in one or more directions where the transmission beam EIRP is within A [FFS] dB of the peak EIRP. The sensing beam gain measured along the chosen directions is at least X [FFS] dB of the transmission beam gain in those directions.
§ Alt-1D: The sensing beam gain is measured in one or more directions where the transmission beam EIRP is within A [FFS] dB of the peak EIRP and the sensing beam gain measured along the chosen directions is at least X [FFS] dB of the peak sensing beam gain
§ Alt-1E: Sensing beam has the minimum [3] dB beamwidth which at least contains all beam peak directions of transmission beams.
o Sending LS to RAN4 and inform them the above and request them to make the final choice
§ RAN4 choice may not be limited by the list above, but if different method is selected, RAN1 would like to have an opportunity to check as well
· Alt 2. Extending the beam correspondence framework and QCL/TCI/SpatialRelationInfo framework to define “cover” and to indicate sensing beam(s) associated with a transmission beam(s)
o On gNB side sensing beam selection for a DL transmission beam,
§ Option 1: The selection of eligible sensing beam for a transmission beam is left for gNB implementation
· No testing or enforcement introduced in 3GPP spec for this option
§ Option 2: Beam correspondence at gNB side is assumed. Supporting one or more of the following behaviors
· A1. For a gNB transmission beam corresponding to TCI state A for a certain UE, the gNB can use the same beam for sensing
· A2. If TCI B is used as QCL source (Type D) for TCI A for a certain UE, then gNB transmission beam corresponding to TCI B can be used as the sensing beam for transmission with TCI A.
· A3. If TCI C is NOT used as QCL source (Type D) for TCI A for any UE, then gNB cannot use the transmission beam corresponds to TCI C as the sensing beam for transmission with TCI A.
· FFS: How and if to support sensing with a beam without corresponding RS sent? For example, how to use quasi-Omni beam for sensing if there is no SSB transmitted with quasi-omni beam
o On UE side sensing beam selection for a UL transmission beam
§ Beam correspondence is assumed at UE
· FFS: What if beam correspondence is not supported at UE.
§ Supporting one or more of the following behaviors
· If the UE is indicated to transmit with a beam corresponding to a certain SRI, the UE can use the same beam for sensing
· Assuming Rel.17 unified TCI framework, if the UE is indicated to transmit with a beam corresponding to a certain unified TCI, the UE can use the reception beam corresponding to the TCI for sensing
· FFS: How and if to support a wider sensing beam (such as pseudo-omni beam, which is supported in WiFi) to be used for a narrower transmission beam under QCL/TCI framework
o Option 0: Not supported
o Option 1: UE implementation.
§ No testing or enforcement introduced in 3GPP spec for this option
o Option 2: gNB indication.
§ FFS details.
o FFS: How and if to support a multiple sensing beams to be used for a transmission beam under QCL/TCI framework
· Note: Supporting both alternatives or a combination of the two alternatives is not precluded
Decision: As per email decision posted on Aug 27th,
For receiver to provide assistance in channel access, channel sensing and reporting need to be performed. The following schemes can be further considered. Target down-selection by RAN1 #106bis-e
R1-2106585 Discussions on sync raster for NR operation from 52.6GHz to 71 GHz vivo
R1-2106772 Efficient beam management for NR in 52.6 – 71 GHz InterDigital, Inc.
R1-2107006 Evaluation results for above 52.6GHz ZTE, Sanechips
R1-2107056 NR channelization for the 57 – 71 GHz band Ericsson
R1-2107110 Simulation results Nokia, Nokia Shanghai Bell
R1-2107442 Link level evaluation results and complexity analysis for NR FR2-2 PTRS design LG Electronics
R1-2107663 LLS results for enhancement reference signals Huawei, HiSilicon
Please refer to RP-212637 for detailed scope of the WI.
Incoming LS(s) related to this work/study item under agenda item 5: R1-2108702.
R1-2110612 Session notes for 8.2 (Extending current NR operation to 71GHz) Ad-Hoc Chair (Ericsson)
[106bis-e-R17-RRC-60GHz] – Jing (Qualcomm)
Email discussion on Rel-17 RRC parameters for supporting NR from 52.6 GHz to 71 GHz
- 1st check point: October 14
- Final check point: October 19
R1-2110681 Comments collection for RRC parameters for extending NR to 52.6-71GHz WI rapporteur (Qualcomm incorporated)
Document is noted. For consolidation under 8 in [106bis-e-R17-RRC].
Including SSB, initial BWP, PRACH, etc.
R1-2108767 Initial access signals and channels for 52-71GHz spectrum Huawei, HiSilicon
R1-2108782 Initial access for Beyond 52.6GHz FUTUREWEI
R1-2108902 Discussion on initial access aspects for NR for 60GHz Spreadtrum Communications
R1-2108934 Discussion on the initial access aspects for 52.6 to 71GHz ZTE, Sanechips
R1-2108959 Discussions on initial access aspects for NR operation from 52.6GHz to 71GHz vivo
R1-2109032 Considerations on initial access for NR from 52.6GHz to 71 GHz Fujitsu
R1-2109070 Discussion on initial access aspects OPPO
R1-2109120 Discussion on initial access aspects supporting NR from 52.6 to 71 GHz NEC
R1-2109208 Initial access aspects for up to 71GHz operation CATT
R1-2109401 On initial access aspects for NR from 52.6-71 GHz Xiaomi
R1-2109433 Initial Access Aspects Ericsson
R1-2109442 Initial access aspects Nokia, Nokia Shanghai Bell
R1-2109476 Initial access aspects for NR from 52.6 GHz to 71 GHz Samsung
R1-2109557 Remaining issues on initial access of 52.6-71 GHz NR operation MediaTek Inc.
R1-2109598 Discussion on initial access aspects for extending NR up to 71 GHz Intel Corporation
R1-2109665 Initial access aspects for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2109741 Initial access aspects for NR from 52.6 GHz to 71 GHz Panasonic Corporation
R1-2109777 Considerations on initial access aspects for NR from 52.6 GHz to 71 GHz Sony
R1-2109808 Discussion on initial access aspects for NR from 52.6 to 71GHz ETRI
R1-2109897 Initial access aspects for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2109903 Discussion on initial access channels and signals for operation in 52.6-71GHz InterDigital, Inc.
R1-2109961 Initial access aspects to support NR above 52.6 GHz LG Electronics
R1-2109992 Initial access aspects Sharp
R1-2110021 Initial access signals and channels Apple
R1-2110109 NR SSB design consideration for 52.6 GHz to 71 GHz Convida Wireless
R1-2110172 Initial access aspects for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2110320 Discussion on initial access aspects for NR beyond 52.6GHz WILUS Inc.
[106bis-e-NR-52-71GHz-01] – Daewon (Intel)
Email discussion/approval on initial access aspects with checkpoints for agreements on October 14 and 19
R1-2110404 Issue Summary for initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
From Oct 12th GTW session
Working assumption:
· Support DBTW for 120 kHz.
o FFS: Support for 480 kHz and 960 kHz
R1-2110405 Summary #1 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
R1-2110516 Summary #2 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
R1-2110537 Summary #3 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
From Oct 18th GTW session
Conclusion:
Do not support gap between consecutive ROs for 480kHz and 960kHz
R1-2110538 Summary #4 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
Decision: As per email decision posted on Oct 20th,
Agreement:
Same DCI size for DCI 1_0 in CSS regardless of channel access mode (i.e., LBT on/off).
· Existing DCI size alignment in TS38.212 applies to DCI 1_0 and 0_0 in CSS.
Agreement:
Agreement:
No other values of n other than agreed previously is supported for 120kHz SCS, where parameter ‘n’ is the set of values to determine the first symbols of the candidate SSB blocks for 120kHz SCS in agreement from RAN1 #104-bis-e.
Working assumption:
Agreement:
Additionally, support PRACH length L=571 for 480kHz
Agreement:
Support 120 kHz and 480 kHz subcarrier spacing for initial UL BWP for PCell.
Working assumption:
For SCS that DBTW is supported, the following fields are used to indicate parameters related to operation of DBTW
Agreement:
For
120kHz SCS, for 
values:
, at least
support {16, 32, 64}, support
{32, 64} values
without increasing used number of bits, e.g., {16, 32, 64} <
64 indicates DBTW enabled/supported and operation with shared spectrum. =
64. Use of =64 in
shared spectrum is not precluded.
Agreement:
Supported value of n for 480/960kHz SSB slot pattern:
Agreement:
For ‘searchSpaceZero’ configuration for {SSB, CORESET#0/Type0-PDCCH} = {480, 480} kHz and {960, 960} kHz, use the following table for multiplexing pattern 1:
· FFS: The value of X (> 0)
· FFS: whether or not to use different X value depending on whether DBTW is ON/OFF
· FFS: whether or not to use same or different X value for 480 and 960 kHz
·
FFS: whether Y = 
, or Y=
, or whether
to remove entries with Y
|
Index |
|
Number of search space sets per slot |
|
First symbol index |
|
0 |
0 |
1 |
1 |
0 |
|
1 |
0 |
2 |
1/2 |
{0,
if |
|
2 |
X |
1 |
1 |
0 |
|
3 |
X |
2 |
1/2 |
{0,
if |
|
4 |
5 |
1 |
1 |
0 |
|
5 |
5 |
2 |
1/2 |
{0,
if |
|
6 |
0 |
2 |
1/2 |
{0,
if |
|
7 |
X |
2 |
1/2 |
{0,
if |
|
8 |
5 |
2 |
1/2 |
{0,
if |
|
9 |
5 + X |
1 |
1 |
0 |
|
10 |
5 + X |
2 |
1/2 |
{0,
if |
|
11 |
5 + X |
2 |
1/2 |
{0,
if |
|
12 |
0 |
1 |
2 |
0 |
|
13 |
5 |
1 |
2 |
0 |
|
14 |
Reserved |
|||
|
15 |
Reserved |
|||
Final summary in R1-2110634.
R1-2108768 Enhancement on PDCCH monitoring Huawei, HiSilicon
R1-2108783 PDCCH monitoring enhancements FUTUREWEI
R1-2108887 Discussion on PDCCH monitoring enhancements for above 52.6GHz Transsion Holdings
R1-2108935 Discussion on the PDCCH monitoring enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2108960 Discussions on PDCCH monitoring enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2109071 Discussion on PDCCH monitoring enhancement OPPO
R1-2109117 Discussion on PDCCH monitoring enhancements supporting NR from 52.6GHz to 71 GHz NEC
R1-2109209 PDCCH monitoring enhancements for up to 71GHz operation CATT
R1-2109402 PDCCH monitoring enhancement for NR 52.6-71GHz Xiaomi
R1-2109434 PDCCH Monitoring Enhancements Ericsson
R1-2109443 PDCCH monitoring enhancements Nokia, Nokia Shanghai Bell
R1-2109477 PDCCH monitoring enhancements for NR from 52.6 GHz to 71 GHz Samsung
R1-2109560 PDCCH monitoring enhancement for 52.6-71 GHz NR operation MediaTek Inc.
R1-2109599 Discussion on PDCCH monitoring enhancements for extending NR up to 71 GHz Intel Corporation
R1-2109666 PDCCH monitoring enhancements for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2109778 PDCCH enhancement for NR from 52.6GHz to 71GHz Sony
R1-2109898 PDCCH monitoring enhancements for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2109904 Discussions on PDCCH monitoring enhancements InterDigital, Inc.
R1-2109962 PDCCH monitoring enhancements to support NR above 52.6 GHz LG Electronics
R1-2109993 PDCCH monitoring enhancements Sharp
R1-2110022 PDCCH Enhancements for above 52.6 GHz Apple
R1-2110110 PDCCH Monitoring for NR from 52.6 GHz to 71 GHz Convida Wireless
R1-2110173 PDCCH monitoring enhancements for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2110248 PDCCH monitoring enhancements Charter Communications
R1-2110252 PDCCH monitoring for NR operation from 52.6 to 71 GHz Panasonic
[106bis-e-NR-52-71GHz-02] – Alex (Lenovo)
Email discussion/approval on PDCCH monitoring enhancements with checkpoints for agreements on October 14 and 19
R1-2110373 Feature lead summary #1 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
From Oct 12th GTW session
Proposal:
The BD/CCE budget per X-slot window is the default PDCCH monitoring budget per X slots, which is the shared resource for monitoring both (1) type 1 CSS with dedicated RRC configuration, type 3 CSS, and UE-SS; and (2) type 1 CSS without dedicated RRC configuration and for type 0, 0A, and 2. Further adopt one of the following alternatives:
R1-2110521 Feature lead summary #2 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
From Oct 15th GTW session
Proposal:
· Multi-slot PDCCH monitoring is based on slots within a slot group
o Each slot group consists of X consecutive slots
§ Slot groups are consecutive and non-overlapping
§ The start of a slot group is aligned with a subframe boundary
o The reported capability
indicates the BD/CCE budget within XY
consecutive slots in each slot group
§ For reporting the BD/CCE budget, the UE may assume that the location of the Y consecutive slots within the X slots is maintained across different slot groups
§ UE reports its BD/CCE budget for
· Option 1: Y=1 slot and optionally as well Y=X/2 consecutive slots
·
Option 2: both Y=1 slot and Y=X/2 consecutive slots
·
Option 3: both Y=1 slot and Y=X/2 consecutive
slots are supported, FFS a default Y or which Y is mandatory/optional
§ Reporting the BD/CCE budget for X=4/8 slots (for 480/960 kHz resp.) is mandatory, and is optional for X=2/4 slots (for 480/960 kHz resp.)
o Search space configuration
§ Option A
·
A SS can be configured to be within Y
consecutive slots within a slot group of X slots; the Y consecutive slots can
be located anywhere within the slot group of X slots
·
The location of the Y consecutive slots
within the slot group of X slots is maintained across different slot groups
·
BD attempts for all SS sets (Group (1) SS and
Group (2) SS) are restricted to fall within the same Y consecutive slots
§ Option B
·
For Group (1) SS
o A SS can be configured to be within Y consecutive slots within a
slot group of X slots
o The Y consecutive slots can be located anywhere within the slot
group of X slots
o The location of the Y consecutive slots within the slot group of X
slots is maintained across different slot groups
o BD attempts for all Group (1) SSs are restricted to fall within the
same Y consecutive slots
·
For Group (2) SS
o A SS can be configured to be anywhere within a slot group of X slots
§ Option C
· For Group (1) SS
o A SS can be configured to be within Y consecutive slots within a slot group of X slots
o The Y consecutive slots can be located anywhere within the slot group of X slots
o The location of the Y consecutive slots within the slot group of X slots is maintained across different slot groups
o BD attempts for all Group (1) SSs are restricted to fall within the same Y consecutive slots
· For Group (2) SS
o A SS can be configured to be anywhere within a slot group of X slots
o The location of the SS within the slot group of X slots is maintained across different slot groups
Group (1) SS: Type 1 CSS with dedicated RRC configuration and type 3 CSS, UE specific SS
Group (2) SS: Type 1 CSS without dedicated RRC configuration and type 0, 0A, and 2 CSS
R1-2110560 Feature lead summary #3 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
R1-2110582 Feature lead summary #4 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
From Oct 19th GTW session
Proposal:
For Type0-PDCCH monitoring, for 480/960 kHz, down-select between to one of the following two alternatives in the GTW
Agreement:
Group (1) SS: Type 1 CSS with dedicated RRC configuration and type 3 CSS, UE specific SS
Group (2) SS: Type 1 CSS without dedicated RRC configuration and type 0, 0A, and 2 CSS
R1-2108769 Enhancement on PUCCH formats Huawei, HiSilicon
R1-2108784 On Enhancement of PUCCH Resource Set for 52.6GHz to 71GHz FUTUREWEI
R1-2108936 Discussion on the PUCCH enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2108961 Discussions on PUCCH enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2109072 Discussion on enhancements for PUCCH format 0/1/4 OPPO
R1-2109210 Enhancements for PUCCH formats for up to 71GHz operation CATT
R1-2109435 PUCCH enhancements Ericsson
R1-2109444 Remaining items for enhanced PUCCH formats 0/1/4 Nokia, Nokia Shanghai Bell
R1-2109478 Enhancements for PUCCH format 0/1/4 for NR from 52.6 GHz to 71 GHz Samsung
R1-2109600 Discussion on PUCCH enhancements for extending NR up to 71 GHz Intel Corporation
R1-2109667 PUCCH format 0/1/4 enhancements for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2109779 Additional considerations on enhancements for PUCCH formats 0/1/4 Sony
R1-2109905 Discussions on enhancements for PUCCH formats 0/1/4 InterDigital, Inc.
R1-2109963 Enhancements for PUCCH formats 0/1/4 to support NR above 52.6 GHz LG Electronics
R1-2110023 Discussion on Enhancements for PUCCH formats 0/1/4 Apple
R1-2110174 Enhancements for PUCCH for NR in 52.6 to 71GHz band Qualcomm Incorporated
[106bis-e-NR-52-71GHz-03] – Steve (Ericsson)
Email discussion/approval on enhancements for PUCCH formats 0/1/4 with checkpoints for agreements on October 14 and 19
R1-2109436 FL Summary for Enhancements for PUCCH formats 0/1/4 Ericsson
From Oct 12th GTW session
Conclusion:
· Do not re-open the discussion potential RB shortage and frequency hopping distance issues for common PUCCH resource sets prior to dedicated PUCCH resource configuration.
· Note: Whether or not the spec explicitly captures error cases related to a potential RB shortage issue will be separately discussed.
Agreement:
· Reuse the existing Rel-15/16 PUCCH configuration Table 9.2.1-1 in 38.213 for configuration of PUCCH resource sets prior to dedicated PUCCH configuration for multi-RB PUCCH formats 0/1
· As previously agreed, the number of RBs for each PUCCH resource in a set is N_RB which is signaled in SIB1
· The lowest-indexed RB for each PUCCH resource is a function of N_RB
· The following example change to 38.213 Section 9.2.1 can be recommended to the editor of 38.213 to use at the editor’s discretion (subject to resolution of the below FFS on the value of X)
---- Start ----
If 
and a UE is
provided a PUCCH resource by pucch-ResourceCommon and is not provided useInterlacePUCCH-PUSCH
in BWP-UplinkCommon
- the UE determines
the lowest PRB index of the
PUCCH transmission in the first hop as 
and the lowest PRB index of the PUCCH transmission in the
second hop as 
, where 
is the total
number of initial cyclic shift indexes in the set of initial cyclic shift
indexes
- the UE determines
the initial cyclic shift index in the set of initial cyclic shift indexes as 
If 
and a UE is
provided a PUCCH resource by pucch-ResourceCommon and is not provided useInterlacePUCCH-PUSCH
in BWP-UplinkCommon
- the UE determines
the lowest PRB index of the
PUCCH transmission in the first hop as 
and the lowest PRB index of the PUCCH transmission in the
second hop as 
- the UE
determines the initial cyclic shift index in the set of initial cyclic shift
indexes as 
---- End ----
· FFS: Supported value of X. Down-select to one of the following alternatives:
o Alt-1: X = N_RB
§ Note: This alternative is mathematically equivalent to Example Construction 1 discussed in RAN1#106-e.
o Alt-2a: X is a fixed value less than N_RB, e.g., 1, N_RB / 2, …
o Alt-2b: X is configurable, e.g., via SIB1
· FFS: Whether or not the spec explicitly captures either or both of the following error cases related to a potential RB shortage issue:
o Case 1: Some of the RBs of a PUCCH resource fall outside the initial UL BWP
o Case 2: An indicated PUCCH resource with r_PUCCH ≥ 8 overlaps the RBs of a PUCCH resource with r_PUCCH < 8.
· FFS: Whether or not special handling for PUCCH resource set index 15 is necessary.
Decision: As per email decision posted on Oct 15th,
· Update the following RAN1#106-e agreement to clarify that the number of RBs can be configured separately per PUCCH resource
Update of RAN1#106-e Agreement:
§
Support an RRC parameter to
configure the number of RBs for a per PUCCH resource for each of enhanced PUCCH formats
0, 1, and 4
§ The parameter is provided by dedicated signaling (per UE) per BWP
· Update the description of the RRC parameter accordingly within the RRC parameter email thread
Agreement:
· In the RAN1#106bis-e agreement on construction of PUCCH resource sets prior to dedicated PUCCH configuration, the following is supported at least for PUCCH resource set indices 0 .. 14 in Table 9.2.1-1 (Alt-1 in the agreement):
· FFS: Down select to one of the following alternatives for PUCCH resource set index 15
o
Alt-a:
o Alt-b: Alternative handling (to be defined)
Conclusion:
Conclusion:
For enhanced (multi-RB) PF0/1, enhancement to the cyclic shift definition is not supported in Rel-17.
Final summary in:
R1-2110499 FL Summary #2 for [106bis-e-NR-52-71GHz-03] Email discussion/approval on enhancements for PUCCH formats 0/1/4 Moderator (Ericsson)
Including timing associated with beam-based operation.
R1-2108770 Discussion on the beam management procedures for 52-71GHz spectrum Huawei, HiSilicon
R1-2108785 Views on Beam management for Beyond 52.6 GHz FUTUREWEI
R1-2108903 Discussion on beam management for above 52.6GHz Spreadtrum Communications
R1-2108937 Discussion on the beam management for 52.6 to 71GHz ZTE, Sanechips
R1-2108962 Discussions on beam management for new SCSs for NR operation from 52.6GHz to 71GHz vivo
R1-2109073 Discussion on beam management for new SCSs OPPO
R1-2109119 Beam management enhancement for NR from 52.6GHz to 71GHz NEC
R1-2109211 Beam management for new SCSs for up to 71GHz operation CATT
R1-2109403 Discussion on beam management for new SCSs xiaomi
R1-2109437 Beam Management for New SCSs Ericsson
R1-2109445 Beam Management Aspects Nokia, Nokia Shanghai Bell
R1-2109479 Beam management for new SCSs for NR from 52.6 GHz to 71 GHz Samsung
R1-2109561 Beam management discussion for 52.6-71 GHz NR operation MediaTek Inc.
R1-2109601 Discussion on Beam management aspects for extending NR up to 71 GHz Intel Corporation
R1-2109668 Beam based operation for new SCSs for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2109780 Beam management enhancement for NR from 52.6GHz to 71GHz Sony
R1-2109899 Beam-management enhancements for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2109906 Discussions on beam management for new SCSs InterDigital, Inc.
R1-2109964 Enhancements for beam management to support NR above 52.6 GHz LG Electronics
R1-2110024 Beam Management for New SCSs Apple
R1-2110112 Beam management for NR from 52.6 GHz to 71 GHz Convida Wireless
R1-2110175 Beam managment for new SCS Qualcomm Incorporated
[106bis-e-NR-52-71GHz-04] – Youngwoo (InterDigital)
Email discussion/approval on beam management for new SCSs with checkpoints for agreements on October 14 and 19
R1-2109907 Discussion Summary #1 for Beam Management for new SCSs Moderator (InterDigital, Inc.)
From Oct 12th GTW session
Agreement:
For maxNumberRxTxBeamSwitchDL, support 1, 4 and 7 as candidate values for 960 kHz in addition to the agreed candidate value 2.
Agreement:
For additional beam switching time delay d of 120 kHz, support 28 symbols.
R1-2110525 Discussion Summary #3 of Beam Management for New SCSs Moderator (InterDigital, Inc.)
From Oct 18th GTW session
Agreement:
For additional beam switching time delay d of 480 kHz, introduce UE capability signalling which indicates 56 symbols or 112 symbols.
Conclusion:
For candidate values of timeDurationForQCL, beamSwitchTiming and beamReportTiming,
· No additional candidate values are supported for 120 kHz, 480 kHz and 960 kHz
· Note: this is Alt-1 from the RAN1#106 agreement.
R1-2110632 Discussion Summary #4 of Beam Management for New SCSs Moderator (InterDigital, Inc.)
Decision: As per email decision posted on Oct 20th,
Agreement:
Like in Rel-15, a minimum guard period Y between two SRS resources of an SRS resource set for antenna switching is supported for 480 kHz and 960 kHz
Agreement:
The working assumption in RAN1#106-e is confirmed with the following update:
For multi-PDSCH scheduling for multi-TRPs, support a single DCI field ‘Transmission Configuration Indication’ as in Rel-16 TCI state indication mechanism for multi-TRPs
Final summary in R1-2110633.
Including defining maximum bandwidth for new SCSs, time line related aspects adapted to each of the new numerologies 480kHz and 960kHz, reference signals, scheduling particularly w.r.t. multi-PDSCH/PUSCH with a single DCI, HARQ, etc.
R1-2108771 PDSCH/PUSCH enhancements for 52-71GHz spectrum Huawei, HiSilicon
R1-2108786 Discussions on timeline, reference signal, and multi-PxSCH scheduling for 52.6GHz to 71GHz FUTUREWEI
R1-2108904 Discussion on PDSCH and PUSCH enhancements for above 52.6GHz Spreadtrum Communications
R1-2108938 Discussion on the data channel enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2108963 Discussions on PDSCH/PUSCH enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2109033 Considerations on multi-PDSCH/PUSCH with a single DCI and HARQ for NR from 52.6GHz to 71 GHz Fujitsu
R1-2109074 Discussion on PDSCH/PUSCH enhancements OPPO
R1-2109118 Discussion on PDSCH enhancements supporting NR from 52.6GHz to 71 GHz NEC
R1-2109163 PT-RS enhancements for NR from 52.6GHz to 71GHz Mitsubishi Electric RCE
R1-2109212 PDSCH/PUSCH enhancements for up to 71GHz operation CATT
R1-2109404 PDSCH and PUSCH enhancements for NR 52.6-71GHz Xiaomi
R1-2109438 PDSCH-PUSCH Enhancements Ericsson
R1-2109446 PDSCH/PUSCH enhancements Nokia, Nokia Shanghai Bell
R1-2109460 Discussion on PDSCH/PUSCH enhancements for NR 52.6-71 GHz Panasonic Corporation
R1-2109480 PDSCH/PUSCH enhancements for NR from 52.6 GHz to 71 GHz Samsung
R1-2109562 Multi-PDSCH scheduling design for 52.6-71 GHz NR operation MediaTek Inc.
R1-2109602 Discussion on PDSCH/PUSCH enhancements for extending NR up to 71 GHz Intel Corporation
R1-2109669 PDSCH/PUSCH enhancements for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2109838 Enhancements of PDSCH/PUSCH Scheduling for 52.6 GHz to 71 GHz Band CEWiT
R1-2109901 PDSCH/PUSCH scheduling enhancements for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2109908 Discussion on PDSCH/PUSCH enhancements for supporting 52.6 GHz to 71 GHz Band InterDigital, Inc.
R1-2109965 PDSCH/PUSCH enhancements to support NR above 52.6 GHz LG Electronics
R1-2110025 Discussion on PDSCH and PUSCH Enhancements for NR above 52.6 GHz Apple
R1-2110113 PDSCH design consideration for NR from 52.6 GHz to 71 GHz Convida Wireless
R1-2110176 PDSCH/PUSCH enhancements for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2110242 Discussion on multiple PDSCHs scheduled by a DCI ITRI
R1-2110321 Discussion on multi-PDSCH/PUSCH scheduling for NR from 52.6GHz to 71GHz WILUS Inc.
[106bis-e-NR-52-71GHz-05] – Huaming (Vivo)
Email discussion/approval on defining maximum bandwidth for new SCSs, timeline related aspects adapted to each of the new numerologies 480kHz and 960kHz and reference signals with checkpoints for agreements on October 14 and 19
R1-2110398 Summary of PDSCH/PUSCH enhancements (Bandwidth/Timeline/Reference signals) Moderator (vivo)
R1-2110399 Discussion summary #1 of [106bis-e-NR-52-71GHz-05] Moderator (vivo)
From Oct 14th GTW session
Agreement:
For 480 kHz and/or 960 kHz SCS, for rank 1 PDSCH with type-1 or type-2 DMRS, support a configuration of DMRS where the UE is able to assume that FD-OCC is not applied.
· Note: “FD-OCC is not applied” refers to the UE may assume that a set of remaining orthogonal antenna ports are not associated with the PDSCH to another UE, wherein the set of remaining orthogonal antenna ports are within the same CDM group and have different FD-OCC
· Note: The same UE indication method is used for both type-1 and type-2 DMRS
Agreement:
Support an indication to the UE via RRC where the UE is able to assume that FD-OCC is not applied to all the antenna port(s) for DMRS which is(are) applicable for rank 1 PDSCH.
Agreement:
For NR operation with 480 kHz and/or 960 kHz SCS, the value range of k0 is 0 ~ 128.
Agreement:
For NR operation with 480 kHz and/or 960 kHz SCS, the value range for k2 is 0 ~ 128.
R1-2110512 Discussion summary #2 of [106bis-e-NR-52-71GHz-05] Moderator (vivo)
From Oct 19th GTW session
Agreement:
For NR operation with 480 kHz and/or 960 kHz SCS, the value range of k1 indicated in RRC is -1 ~ 127 for DCI format 1_1 and 0 ~ 127 for DCI format 1_2.
· Note: this does not imply that DCI format 1_2 supports multi-PDSCH scheduling
Agreement:
· For NR operation with 480 kHz and/or 960 kHz SCS, j = 11 for 480 kHz and j = 21 for 960 kHz for determination of the default PUSCH time domain resource allocation (in 38.214 Section 6.1.2.1.1).
· When the field k2 is absent in RRC, the UE applies the value 11 when PUSCH SCS is 480 kHz; and the value 21 when PUSCH SCS is 960 kHz for k2.
Conclusion:
There’s no consensus in RAN1 to introduce other values of N1, N2 and N3 for NR operation with 480 and/or 960 kHz SCS in Rel-17.
Conclusion:
There’s no consensus in RAN1 to introduce (Ng = 16, Ns = 2, L = 1) and/or (Ng = 16, Ns = 4, L = 1) for NR operation in FR2-2 with DFT-s-OFDM in Rel-17.
· Note: Ng number of PT-RS groups, Ns number of samples per PT-RS group, and PTRS every L number of DFT-s-OFDM symbols
Decision: As per email decision posted on Oct 20th,
Agreement:
For NR operation with 480 kHz and/or 960 kHz SCS, decide the set of values for PDSCH-to-HARQ_feedback timing indicator field in DCI format 1_0 in RAN1#107-e.
· Option 1: {4, 8, 12, 16, 20, 24, 28, 32} for 480 kHz and {8, 16, 24, 32, 40, 48, 56, 64} for 960 kHz
· Option 2: {7, 8, 9, 10, 11, 12, 13, 14} for 480 kHz and {13, 14, 15, 16, 17, 18, 19, 20} for 960 kHz
· Option 2a: {1, 2, 3, 4, 5, 6, 7, 8} (same as in existing specification)
o Note: the actual slot offset of k1 is the indicated value + offset where offset is ceil(N1/14)
· Other options are not precluded
Agreement:
Remove [] from previous agreed Z3 values for NR operation with 480 and 960 kHz SCS. That is,
For NR operation with 480 and 960 kHz SCS, adopt at least the values of Z1, Z2 and Z3 as in the following table for single and multi-PDSCH/PUSCH scheduling to maintain the same absolute time duration as that of 120 kHz SCS in FR2.
is
UE reported capability beamReportTiming; KB3 and KB4
is UE reported capability beamSwitchTiming for 480 and 960 kHz SCS
respectively.Table: CSI computation delay requirement 2
|
|
Z1 [symbols] |
Z2 [symbols] |
Z3 [symbols] |
|||
|
Z1 |
Z’1 |
Z2 |
Z’2 |
Z3 |
Z’3 |
|
|
5 |
388 |
340 |
608 |
560 |
min(388, X5+ KB3) |
X5 |
|
6 |
776 |
680 |
1216 |
1120 |
min(776, X6+ KB4) |
X6 |
Agreement:
For NR operation with 480 kHz and/or 960 kHz SCS, CSI computation delay requirement 2 is always applied at least for the case of same SCS operation.
· FFS: whether CSI computation delay requirement 2 is always applied in the case of mixed SCS of PDCCH, CSI-RS and PUSCH.
Conclusion:
In Rel-17, for NR operation with 480 and/or 960 kHz SCS, no other values of Z1, Z2 and Z3 is supported.
Conclusion:
In Rel-17, for NR operation in FR2-2, increased PTRS frequency density for Rel-15 PTRS pattern is not supported for CP-OFDM when the allocated number of RB <= 32.
Conclusion:
In Rel-17, for NR operation in FR2-2, PTRS enhancement is not supported for CP-OFDM.
[106bis-e-NR-52-71GHz-06] – Seonwook (LGE)
Email discussion/approval on scheduling particularly w.r.t. multi-PDSCH/PUSCH with a single DCI, HARQ, with checkpoints for agreements on October 14 and 19
R1-2109966 Summary #1 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
From Oct 14th GTW session
Agreement:
Confirm the working assumption from RAN1#106-e with the following modification.
Working assumption: (RAN1#106-e)
Scheduling multiple PDSCHs by single DL DCI applies to 120 kHz in addition to 480 and 960 kHz at least in FR2-2.
·
FFS: Further
limitations on maximum number of PDSCHs
· Note: Further limitations (in addition to what was agreed earlier) on the maximum number of PDSCHs or PUSCHs can be separately discussed for all SCSs.
Proposal:
For generating type-2 HARQ-ACK codebook corresponding to a DCI that can schedule multiple PDSCHs, and if CBG operation is configured within the same PUCCH group,
· At least if the maximum configured number of PDSCHs for multi-PDSCH DCI is the same as the maximum number of CBGs, across serving cells belonging to the same PUCCH cell group,
o HARQ-ACK bits corresponding to CBG-based PDSCH reception and multi-PDSCH reception are merged into the same sub-codebook.
· Otherwise, simultaneous configuration of CBG and multi-PDSCH is not expected by the UE
Proposal:
If time-bundling operation is not supported or not configured if supported, UE does not expect to be configured with both of CBG operation and multi-PDSCH scheduling in the same PUCCH cell group with a Type 2 codebook.
Decision: As per email decision posted on Oct 15th,
Agreement:
For a PDSCH that is scheduled by multi-PDSCH scheduling DCI and is skipped due to collision with semi-static UL symbol(s),
· For Type-1 HARQ-ACK codebook generation, the PDSCH is not considered and the HARQ-ACK bit corresponding to the PDSCH is not reported by UE.
o Note: Rel-16 procedure can be reused to handle this case.
· For Type-2 HARQ-ACK codebook generation, UE reports NACK for the PDSCH.
o FFS on HARQ-ACK bit ordering
· Note: Codebook generation in case time domain bundling is enabled can be separately discussed if time domain bundling is supported.
Agreement:
For generating type-2 HARQ-ACK codebook corresponding to a DCI that can schedule multiple PDSCHs,
· HARQ-ACK bit corresponding to SPS PDSCH release or SCell dormancy indication without scheduled PDSCH, belongs to the first sub-codebook (which is defined in the previous agreement made in RAN1#105-e)
R1-2110523 Summary #2 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
From Oct 19th GTW session
Working assumption:
UE does not expect to be configured with both of CBG operation and multi-PDSCH scheduling in the same PUCCH cell group with a Type 2 codebook.
Agreement:
For two multi-PDSCH (or two multi-PUSCH) scheduling DCIs, UE does not expect any of the scheduled PDSCHs (or PUSCHs) and the scheduling DCI to lead to out-of-order scheduling.
· FFS: whether to allow OOO scheduling for the following two cases:
o for the case of one multi-PDSCH (or multi-PUSCH) scheduling DCI and one single-PDSCH (or single-PUSCH) scheduling DCI, where multi-PDSCH (or multi-PUSCH) scheduling DCI schedules more than one PDSCH (or PUSCH)
o for the case where two multi-PDSCH (or multi-PUSCH) scheduling DCIs end in the same symbol but two multi-PDSCH (or multi-PUSCH) scheduling DCIs have overlapping spans, where the span is defined from the beginning of the first scheduled SLIV till the end of the last scheduled SLIV
· Note: The above FFS aspect applies only to multi-PDSCH and multi-PUSCH scheduling with single DCI
Decision: As per email decision posted on Oct 20th,
For multiple PDSCHs (or PUSCHs) scheduled by a single DCI,
· Rel-15/16 behavior that is described in TS 38.213 Clauses 11 and 11.1 for a PDSCH (or PUSCH) indicated by DCI also applies for multiple PDSCHs (or PUSCHs) schedule by a single DCI.
· If one of multiple PDSCHs (or PUSCHs) scheduled by the DCI collides with a flexible symbol (indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated),
o If that PUSCH is collided with SSB symbols indicated by ssb-PositionsInBurst [or symbol(s) indicated by pdcch-ConfigSIB1 in MIB for a CORESET for Type0-PDCCH CSS set], the HARQ process number increment is skipped for the PUSCH.
o Otherwise, the HARQ process number increment is not skipped for that PDSCH (or PUSCH).
Conclusion:
For a DCI that can scheduled multiple PDSCHs (or PUSCHs), HARQ process number indicated in the DCI is applied to the first valid PDSCH (or PUSCH).
· Note: This is the consequence of previous agreements.
Agreement:
For single TRP operation, for 480/960 kHz SCS,
· A UE does not expect to be scheduled with more than one unicast PDSCH in a slot, by a single DCI or multiple DCIs.
· A UE does not expect to be scheduled with more than one PUSCH in a slot, by a single DCI or multiple DCIs.
Agreement:
For a DCI that can schedule multiple PDSCHs, and if RRC parameter configures that two codeword transmission is enabled,
· MCS for the 2nd TB: This appears only once in the DCI and applies commonly to the 2nd TB of each PDSCH
· NDI for the 2nd TB: This is signaled per PDSCH and applies to the 2nd TB of each PDSCH
· RV for the 2nd TB: This is signaled per PDSCH, with 2 bits if only a single PDSCH is scheduled or 1 bit for each PDSCH otherwise and applies to the 2nd TB of each PDSCH
· FFS: the maximum number of PDSCHs when 2 TB is enabled or when 2 TB is scheduled
Final summary in R1-2110640.
R1-2108772 Channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
R1-2108787 Channel access for shared spectrum for Beyond 52.6 GHz FUTUREWEI
R1-2108905 Discussion on channel access mechanism for above 52.6GHz Spreadtrum Communications
R1-2108939 Discussion on the channel access for 52.6 to 71GHz ZTE, Sanechips
R1-2108964 Discussions on channel access mechanism for NR operation from 52.6GHz to 71 GHz vivo
R1-2109034 Considerations on channel access mechanism for NR from 52.6GHz to 71 GHz Fujitsu
R1-2109075 Discussion on channel access mechanism OPPO
R1-2109121 Discussion on channel access mechanism supporting NR from 52.6 to 71GHz NEC
R1-2109213 Channel access mechanism for up to 71GHz operation CATT
R1-2109268 Channel access mechanism for NR in 60GHz unlicensed band operation TCL Communication Ltd.
R1-2109345 Views on channel access mechanism enhancements for 52.6-71 GHz CAICT
R1-2109405 Discussion on channel access mechanism for NR on 52.6-71 GHz Xiaomi
R1-2109439 Channel Access Mechanisms Ericsson
R1-2109447 Channel access mechanism Nokia, Nokia Shanghai Bell
R1-2109481 Channel access mechanism for NR from 52.6 GHz to 71 GHz Samsung
R1-2109558 On the channel access mechanisms for 52.6-71 GHz NR operation MediaTek Inc.
R1-2109603 Discussion on channel access mechanism for extending NR up to 71 GHz Intel Corporation
R1-2109670 Channel access mechanism for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2109781 Channel access mechanism for 60 GHz unlicensed spectrum Sony
R1-2109902 Channel access mechanisms for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2109909 Discussion on channel access mechanisms InterDigital, Inc.
R1-2109967 Channel access mechanism to support NR above 52.6 GHz LG Electronics
R1-2110026 Channel access mechanisms for unlicensed access above 52.6GHz Apple
R1-2110115 On Channel Access Mechanism for Supporting NR from 52.6 GHz to 71 GHz Convida Wireless
R1-2110177 Channel access mechanism for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2110243 Discussion on multi-beam operation ITRI
R1-2110247 Channel access mechanisms for NR above 52 GHz Charter Communications
R1-2110253 Channel access for multi-beam operation Panasonic
R1-2110322 Discussion on channel access mechanism for NR from 52.6GHz to 71GHz WILUS Inc.
[106bis-e-NR-52-71GHz-07] – Jing (Qualcomm)
Email discussion/approval on channel access mechanism with checkpoints for agreements on October 14 and 19
R1-2110488 Email discussion summary#1 for channel access of 52.6GHz to 71GHz band [106bis-e-NR-52-71GHz-07] Moderator (Qualcomm)
From Oct 14th GTW session
Agreement:
o If the UE is indicated to transmit with a beam corresponding to a certain SRI, the UE can use the same beam for sensing
o Assuming Rel.17 unified TCI framework, if the UE is indicated to transmit with a beam corresponding to a certain unified TCI, the UE can use the reception beam corresponding to the TCI for sensing
R1-2110540 Email discussion summary#2 for channel access of 52.6GHz to 71GHz band [106bis-e-NR-52-71GHz-07] Moderator (Qualcomm)
From Oct 19th GTW session
Proposal:
For the following
· UE does not indicate a capability for beam correspondence with beamCorrespondenceWithoutUL-BeamSweeping ={1}
· UE indicates a capability for beam correspondence with beamCorrespondenceWithoutUL-BeamSweeping ={0} before UL beam management procedure
·
UE chooses to uses a different beam for sensing than the beam used for
transmission,
Specify necessary requirement/test procedure to guarantee sensing beam(s) “covers” the transmission beam(s)
· Some methods to define “cover” have been discussed in RAN1 (may further down select the list) and are considered as acceptable from RAN1 perspective
o Alt-1A: the angle included in the [3] dB beamwidth of the transmission beam is included in the [X, FFS] dB beamwidth of the sensing beam.
o Alt-1B: the sensing beam gain measured along the direction of peak transmission direction is at least X [FFS] dB of the transmission beam gain
o Alt-1C: The sensing beam gain is measured in one or more directions where the transmission beam EIRP is within A [FFS] dB of the peak EIRP. The sensing beam gain measured along the chosen directions is at least X [FFS] dB of the transmission beam gain in those directions.
o Alt-1D: The sensing beam gain is measured in one or more directions where the transmission beam EIRP is within A [FFS] dB of the peak EIRP and the sensing beam gain measured along the chosen directions is at least X [FFS] dB of the peak sensing beam gain
o Alt-1E: Sensing beam has the minimum [3] dB beamwidth which at least contains all beam peak directions of transmission beams.
· Sending LS to RAN4 and inform them the above and request them to make the final choice
o RAN4 choice may not be limited by the list above, but if different method is selected, RAN1 would like to have an opportunity to check as well
o It is up to RAN4 to further decide for gNB or UE separately if such test or requirement is not needed or not practical and leave it for UE implementation
Decision: As per email decision posted on Oct 20th,
Conclusion:
There is no consensus to support explicitly introducing in the spec using single LBT covering multiple CCs under CA.
· Note: This does not rule out gNB/UE implementation to perform single LBT to cover multiple CCs. However, the EDT needs to be selected such that if interference on one of the CCs exceeds the CC EDT, the LBT is declared as failed
Agreement:
Confirm
the WA with the following updates: For energy measurement in 5us observation
slot, when performing single measurement, the location of the measurement within the 5us is left
for implementation, i.e., anywhere within the 5us.
Conclusion:
There is no consensus to support CCA or eCCA based receiver assistance with new RTS/CTS type transmission.
Agreement:
Support extending Rel.16 L3-RSSI to unlicensed operation in FR2-2
· Introduce RRC configuration for reference SCS, measurement duration, and measurement bandwidth
o Extend the reference SCS/CP field (ref-SCS-CP-r16) and measurement duration field (measDurationSymbols-r16) in RMTC-Config
· FFS value range and valid combinations for ref-SCS-CP-r16 and measDurationSymbols-r16
o Introduce parameter in RMTC-Config to indicate the measurement bandwidth
· FFS: Value range for measurement bandwidth
· For the QCL Type-D of L3-RSSI measurement, down-select one or both of the following alternatives
o Alt 1: gNB configures the beam when configures the L3-RSSI measurement
Conclusion:
There is no consensus to support per beam LBT mode or no-LBT mode UE specific gNB indication.
Conclusion:
For regions where LBT is not mandated, there is no consensus to introduce L1 signalling for gNB to indicate to the UE if the operation is in LBT mode or no-LBT mode. Note this is different from the DCI field indicate the LBT type for UL transmission.
Conclusion:
There is no consensus to introduce CWS Adjustment for unlicensed operation in FR2-2.
Conclusion:
There is no consensus to introduce CAPC for unlicensed operation in FR2-2.
R1-2108940 Discussion on RRC parameters for 52.6 to 71GHz ZTE, Sanechips
R1-2108965 Discussions on CSI-RS related issues for NR operation from 52.6GHz to 71GHz vivo
R1-2109214 Some issues on SPS for one DCI scheduling multiple PDSCHs case CATT
R1-2109440 NR channelization for the 57 – 71 GHz band Ericsson
R1-2109448 Simulation results Nokia, Nokia Shanghai Bell
R1-2109756 LLS results for enhancement reference signals Huawei, HiSilicon
R1-2109968 Link level evaluation results for NR FR2-2 PTRS design LG Electronics
Please refer to RP-212637 for detailed scope of the WI.
R1-2112790 Session notes for 8.2 (Extending current NR operation to 71GHz) Ad-Hoc Chair (Huawei)
Rel-17 CRs related to 60GHz
R1-2112425 Introduction of NR extensions to 71 GHz Intel Corporation
Decision: Draft CR to 38.215 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
R1-2112428 Introduction of features to extend current NR operation to 71 GHz Ericsson
Decision: Draft CR to 37.213 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
R1-2112431 Introduction of extensions to 71 GHz 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-2112443 Introduction for extending NR operation to 71 GHz 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-2112468 Introduction of features to extend current NR operation to 71 GHz 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-2112482 Introduction of NR Extending current NR operation to 71GHz 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-52-71GHz] – Jing (Qualcomm)
Email discussion on Rel-17 RRC parameters for supporting NR from 52.6 GHz to 71 GHz
- Email discussion to start on November 15
R1-2112773 Email discussion summary for RRC parameters for 52.6-71GHz Moderator (Qualcomm Incorporated)
Document is noted. For consolidation under 8 in [107-e-R17-RRC].
Including SSB, initial BWP, PRACH, etc.
R1-2110827 Initial access signals and channels for 52-71GHz spectrum Huawei, HiSilicon
R1-2110872 Initial access for Beyond 52.6GHz FUTUREWEI
R1-2110998 Remaining issues on initial access aspects for NR operation from 52.6GHz to 71GHz vivo
R1-2111074 Discussion on the initial access aspects for 52.6 to 71GHz ZTE, Sanechips
R1-2111091 Discussion on initial access aspects for NR for 60GHz Spreadtrum Communications
R1-2111146 Considerations on initial access for NR from 52.6GHz to 71 GHz Fujitsu
R1-2111195 Initial access aspects Nokia, Nokia Shanghai Bell
R1-2111241 Initial access aspects for up to 71GHz operation CATT
R1-2111307 Discussion on initial access aspects OPPO
R1-2111385 Considerations on initial access aspects for NR from 52.6 GHz to 71 GHz Sony
R1-2111463 Initial Access Aspects Ericsson
R1-2111483 Discussion on initial access aspects for extending NR up to 71 GHz Intel Corporation
R1-2111641 Initial access aspects for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2111701 Discussion on initial access aspects supporting NR from 52.6 to 71 GHz NEC
R1-2111725 Initial access aspects for NR from 52.6 GHz to 71 GHz Samsung
R1-2111788 Initial access aspects for NR from 52.6 GHz to 71 GHz Panasonic Corporation
R1-2111832 Discussion on initial access channels and signals for operation in 52.6-71GHz InterDigital, Inc.
R1-2111861 Initial access signals and channels Apple
R1-2111987 Discussion on initial access aspects for NR from 52.6 to 71GHz ETRI
R1-2112011 Initial access aspects Sharp
R1-2112029 NR SSB design consideration for 52.6 GHz to 71 GHz Convida Wireless
R1-2112045 Initial access aspects to support NR above 52.6 GHz LG Electronics
R1-2112096 Initial access aspects for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2112203 Initial access aspects for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2112290 Remaining issues on initial access of 52.6-71 GHz NR operation MediaTek Inc.
R1-2112384 Remaining issues on initial access aspects for NR beyond 52.6GHz WILUS Inc.
[107-e-NR-52-71GHz-01] – Daewon (Intel)
Email discussion/approval on initial access aspects with checkpoints for agreements on November 15 and 19
R1-2112580 Issue Summary for initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation) (rev of R1-2112450)
From Nov 11th GTW session
Agreement
R1-2112614 [Draft] LS on initial access for 60 GHz Intel Corporation
Decision: The final LS is approved in R1-2112805.
Decision: As per email decision posted on Nov 16th,
Agreement
Confirm the following working assumptions:
· (From #106-bis-e) Support DBTW for 120 kHz.
· (From #106-e) For 120kHz SSB, the number of candidates SSBs in a half frame is 64.
Agreement
For SCS that support DBTW, UE derives the
QCL relation between candidate SSBs by the value of 
, where 
is the candidate SSB index.
Conclusion
The bit-width of ssb-PositionsInBurst in SIB1 and ServingCellConfigCommon is kept the same as in Rel-15 (i.e., 16-bits in SIB1 and 64-bits in ServingCellConfigCommon).
Agreement
If multiplexing pattern 3 for 480 and 960 kHz is supported, the TDRA allocation table C is updated as follows:
· Row index 6 (previously reserved) is set to
o Dmrs-TypeA-Position: 2,3
o PDSCH mapping type: Type B
o K0 : 0
o S = 11
o L = 2
Agreement
Finalizing PRACH slot index for 480 and 960 kHz (removal of bracket of previous agreement)
· when number of PRACH slots in a reference slot is 1,
o
for 480kHz and 
for 960kHz PRACH
· when the number of PRACH slots in a reference slot is 2,
o
for 480kHz and 
for 960kHz PRACH
Agreement
Update the Table 8.1-2 in TS38.213 to indicate the Ngap (gap between valid RO and SS/PBCH) for 480 kHz and 960 kHz SCS as follows:
·
for 480 kHz
·
for 960 kHz;
Agreement
For single cell operation or for operation with carrier aggregation in a same frequency band, a UE does not transmit PRACH and PUSCH/PUCCH/SRS in a same slot or when a gap between the first or last symbol of a PRACH transmission in a first slot is separated by less than 𝑁 symbols from the last or first symbol, respectively, of a PUSCH/PUCCH/SRS transmission in a second slot where 𝑁=16 for 𝜇=5, 𝑁=32 for 𝜇=6, and 𝜇 is the SCS configuration for the active UL BWP. For a PUSCH transmission with repetition Type B, this applies to each actual repetition for PUSCH transmission [6, TS 38.214].
Conclusion:
as part of gap between last symbol of PDCCH order reception and
first symbol of the PRACH transmission for FR2-2 uses the same value as FR2-1
(i.e. single value for FR2).
R1-2112451 Summary #1 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
From Nov 17th GTW session
Agreement
· For 480 kHz, slot index, n, that contain SSB are:
o n = {0,1,2,3,4,5,6,7, 8,9,10,11,12,13,14,15, 16,17,18,19,20,21,22,23, 24,25,26,27,28,29,30,31}
· For 960 kHz, slot index, n, that contain SSB are:
o n = {0,1,2,3,4,5,6,7, 8,9,10,11,12,13,14,15, 16,17,18,19,20,21,22,23, 24,25,26,27,28,29,30,31}
Decision: As per email decision posted on Nov 19th,
Agreement
For ‘searchSpaceZero’ configuration for {SSB, CORESET#0/Type0-PDCCH} = {120, 120} kHz,
· use Table 13-12 in TS38.213 for multiplexing pattern 1,
· use Table 13-15 in TS38.213 for multiplexing pattern 3.
Agreement
For ‘searchSpaceZero’ configuration for {SSB, CORESET#0/Type0-PDCCH} = {480, 480} kHz and {960, 960} kHz, parameter X from previous RAN1 agreement is set to:
· X = 1.25 for 480 kHz
· X = 0.625 for 960 kHz
Conclusion:
For FR2-2, support the same mechanism as in Rel-16 for extended RAR window for both 4-step and 2-step RACH.
Agreement
For a Type-2 random access procedure, a UE
transmits a PUSCH, when applicable, after transmitting a PRACH. The UE encodes
a transport block provided for the PUSCH transmission using redundancy version
number 0. The PUSCH transmission is after the PRACH transmission by at least 
symbols where 
for 
and 
for 
, and 
is the SCS configuration for the active UL BWP.
Agreement
For 480 and 960 kHz, supported DBTW lengths are:
· {1.25, 1, 0.75, 0.5, 0.25, 0.125, X} ms, where X = 0.0625 if Q=8 is supported and X is removed if Q=8 is not supported.
Agreement
SSB-PositionQCL-Relation IE to indicate QCL
relationship between SSB positions for FR2-2 are same set of values supported
for 
in MIB.
Agreement
For operation with shared spectrum access, for SS/PBCH block and CORESET#0 multiplexing pattern 3, a UE monitors PDCCH in the Type0-PDCCH CSS set over slots that include Type0-PDCCH monitoring occasions associated with SS/PBCH blocks that are quasi co-located with the SS/PBCH block that provides a CORESET for Type0-PDCCH CSS set.
Agreement
For ‘searchSpaceZero’ configuration for {SSB,
CORESET#0/Type0-PDCCH} = {480, 480} kHz and {960, 960} kHz, parameter Y from
previous RAN1 agreement is Y = 
.
Agreement
· For 480kHz and 960kHz PRACH, reuse the RA-RNTI and MSGB-RNTI formula as FR2 and express the slot indexes t_id based on 120kHz SCS:
o RA-RNTI =1+s_id+14×t_id+14×80×f_id +14×80×8×ul_carrier_id
o MSGB-RNTI = 1 + s_id + 14 × t_id + 14 × 80 × f_id + 14 × 80 × 8 × ul_carrier_id + 14 × 80 × 8 × 2
§ where the subcarrier spacing to determine t_id is based on the value of µ specified in clause 5.3.2 in TS 38.211 [8] for µ = {0, 1, 2, 3}
§ for µ = {5, 6}, t_id is the index of the 120 kHz slot in a system frame that contains the PRACH occasion (0 ≤ t_id < 80).
o Note: As per previous RAN1 agreement, there is only one 480 or 960 kHz PRACH slot in a 120kHz slot, such that RA-RNTI and MSGB-RNTI does not result in ID collision.
· Send LS to RAN2 on the updates on RA-RNTI and MSGB-RNTI.
Decision: As per email decision posted on Nov 20th,
R1-2112734 [Draft] LS on RA-RNTI and MSGB-RNTI for 480 and 960 kHz Intel Corporation
Decision: Final LS is approved in R1-2112832, assuming the removal of “first” in text referring to the captured agreement.
Agreement
·
Same 
values
using the same set of signaling bits are supported for 120, 480, and 960 kHz.
·
Supported values of 
: {16,
32, 64}
o Note:
§ For
operation with shared spectrum channel access, any supported value of can be
indicated and value < 64 indicates DBTW enabled
§
UE is expected to be configured with =64 in
licensed operations
§
For operation with and without shared
spectrum channel access, =64
indicates that the SS/PBCH block index and the candidate SS/PBCH block index
have a one-to-one mapping relationship.
Working assumption
For ‘controlResourceSetZero’ configuration for {SSB, CORESET#0/Type0-PDCCH} = {480, 480} kHz and {960, 960} kHz,
·
After supporting entries for multiplexing
pattern 1 for the agreed pairs of (
, 
)
={(24, 2), (48, 1), (48,2)} (with required RB offsets), if additional entries
are left, support multiplex pattern 3 with 24 PRB and 2 symbol duration, and
multiplexing pattern 3 with 48 PRB and 2 symbol duration.
Working assumption
For ‘controlResourceSetZero’ configuration for {SSB, CORESET#0/Type0-PDCCH} = {480, 480} kHz and {960, 960} kHz,
·
After supporting entries
for multiplexing pattern 1 for the agreed pairs of (, ) ={(24, 2), (48, 1), (48,2)} (with required RB offsets) and
multiplex pattern 3 with 24 and 48 PRB and 2 symbol duration (with required RB
offsets), if additional entries are left, support multiplexing pattern 1 with
96 PRB and 2 symbol duration
o Note: the working assumption can be confirmed once RAN1 agrees on the number of needed SSB-CORESET0 offsets for 24 and 48 RB CORESET0 based on RAN4 channelization design.
Agreement
·
If is
indicated, the same interpretation of ssb-PositionsInBurst in SIB1 or
ServingCellConfigCommon as in Rel-16 is supported, i.e.:
o
A bit set to 1 at position 
indicates
SS/PBCH block index k-1
o
The UE assumes that
a bit at position k > is set
to 0
§ For
ssb-PositionsInBurst in SIB1, the UE assumes that a bit at groupPresence
corresponding to a SS/PBCH block index ≥ is set
to 0
o Note: for ssb-PositionsInBurst in SIB1, position k corresponds to the SS/PBCH block index indicated by a bit in inOneGroup and a bit in groupPresence
· In operation with shared spectrum in 60 GHz, for ssb-PositionsInBurst in ServingCellConfigCommonSIB,
o for MSB k, k≥1, of inOneGroup and MSB m, m≥1, of groupPresense of ssb-PositionsInBurst:
§ if MSB k of inOneGroup and MSB m of groupPresense are set to 1, the UE assumes that SSB(s) within DBTW with ‘candidate SSB index(es)’ corresponding to ‘SSB index’ equal to k-1+(m-1)×8 may be transmitted;
§ if MSB k of inOneGroup or MSB m of groupPresense is set to 0, the UE assumes that SSB(s) within DBTW with ‘candidate SSB index(es)’ corresponding to ‘SSB index’ equal to k-1+(m-1)×8 is not transmitted;
· In operation with shared spectrum in 60 GHz, for ssb-PositionsInBurst in ServingCellConfigCommon,
o ssb-PositionsInBurst bits correspond to supported ‘SSB indices’,
§ and UE assumes that SSB(s) within DBTW with ‘candidate SSB index(es)’ corresponding to indicated bit(s) may be transmitted;
§ and UE assumes that SSB(s) within DBTW with ‘candidate SSB index(es)’ corresponding to not indicated bit(s) are not transmitted
· Note to spec editor: The above three bullets maintain the same behavior as Rel-16 NR-U
Agreement
Update the Table 6.3.3.2-1 in TS 38.211 as follows:
Table 6.3.3.2-1: Supported
combinations of 
and 
, and the
corresponding value of 
.
|
|
|
|
|
|
|
... |
... |
... |
... |
... |
|
139 |
120 |
120 |
12 |
2 |
|
139 |
120 |
480 |
3 |
|
|
139 |
120 |
960 |
2 |
|
|
139 |
480 |
120 |
48 |
2 |
|
139 |
480 |
480 |
12 |
2 |
|
139 |
480 |
960 |
6 |
2 |
|
139 |
960 |
120 |
96 |
2 |
|
139 |
960 |
480 |
24 |
2 |
|
139 |
960 |
960 |
12 |
2 |
|
571 |
120 |
120 |
48 |
2 |
|
571 |
120 |
480 |
12 |
|
|
571 |
120 |
960 |
|
|
|
571 |
480 |
120 |
192 |
2 |
|
571 |
480 |
480 |
48 |
2 |
|
571 |
480 |
960 |
24 |
2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
1151 |
120 |
120 |
|
|
|
1151 |
120 |
480 |
|
|
|
1151 |
120 |
960 |
|
|
Final summary in R1-2112735.
R1-2110828 Enhancement on PDCCH monitoring Huawei, HiSilicon
R1-2110873 PDCCH monitoring enhancements for Beyond 52.6GHz FUTUREWEI
R1-2110999 Remaining issues on PDCCH monitoring enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2111075 Discussion on the PDCCH monitoring enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2111092 Discussion on the PDCCH monitoring enhancements for above 52.6GHz Spreadtrum Communications
R1-2111196 PDCCH monitoring enhancements Nokia, Nokia Shanghai Bell
R1-2111242 PDCCH monitoring enhancements for up to 71GHz operation CATT
R1-2111308 Discussion on PDCCH monitoring enhancement OPPO
R1-2111386 PDCCH enhancement for NR from 52.6GHz to 71GHz Sony
R1-2111419 PDCCH monitoring enhancements Charter Communications
R1-2111464 PDCCH Monitoring Enhancements Ericsson
R1-2111484 Discussion on PDCCH monitoring enhancements for extending NR up to 71 GHz Intel Corporation
R1-2111563 PDCCH monitoring enhancement for NR 52.6-71GHz Xiaomi
R1-2111642 PDCCH monitoring enhancements for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2111673 Discussion on PDCCH monitoring enhancements for above 52.6GHz Transsion Holdings
R1-2111691 Discussion on PDCCH monitoring enhancements supporting NR from 52.6GHz to 71 GHz NEC
R1-2111708 PDCCH monitoring for NR operation from 52.6 to 71 GHz Panasonic
R1-2111726 PDCCH monitoring enhancements for NR from 52.6 GHz to 71 GHz Samsung
R1-2111833 Discussions on PDCCH monitoring enhancements InterDigital, Inc.
R1-2111862 Discussion on PDCCH Enhancements Apple
R1-2112012 PDCCH monitoring enhancements Sharp
R1-2112030 PDCCH Monitoring enhancement for NR from 52.6 GHz to 71 GHz Convida Wireless
R1-2112046 PDCCH monitoring enhancements to support NR above 52.6 GHz LG Electronics
R1-2112097 PDCCH monitoring enhancements for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2112204 PDCCH monitoring enhancements for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2112301 PDCCH monitoring enhancement for 52.6-71 GHz NR operation MediaTek Inc.
[107-e-NR-52-71GHz-02] – Alex (Lenovo)
Email discussion/approval on PDCCH monitoring enhancements with checkpoints for agreements on November 15 and 19
R1-2112414 Feature lead summary #1 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
From Nov 11th GTW session
Agreement
R1-2112626 Feature lead summary #2 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
R1-2112755 Feature lead summary #4 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
From Nov 19th GTW session
· For Group (1) SS: Type 1 CSS with dedicated RRC configuration and type 3 CSS, UE specific SS
o A SS is monitored within Y consecutive slots within a slot group of X slots
o The Y consecutive slots can be located anywhere within the slot group of X slots
§ Note: There is no requirement to align the Y consecutive slots across UEs or with slot n0
o The location of the Y consecutive slots within the slot group of X slots is maintained across different slot groups
o BD attempts for all Group (1) SSs are restricted to fall within the same Y consecutive slots
· For Group (2) SS: Type 1 CSS without dedicated RRC configuration and type 0, 0A, and 2 CSS
o SS monitoring locations can be anywhere within a slot group of X slots, with the following exception
§ BD attempts for Type0-CSS for SSB/CORESET 0 multiplexing pattern 1, and additionally for Type0A/2-CSS if searchSpaceId = 0, occur in slots with index n0 and n0+X0, where n0 is as in Rel-15, X0=4 for 480 kHz SCS and X0=8 for 960 kHz SCS.
· Supported combinations of (X,Y)
o A UE capable of multi-slot monitoring mandatorily supports
§ For SCS 480 kHz: (X,Y) = (4,1)
§ For SCS 960 kHz: (X,Y) = (8,1)
o A UE capable of multi-slot monitoring optionally supports
§ For SCS 480 kHz: (X,Y) = (4,2)
§ For SCS 960 kHz: (X,Y) = (8,4), (4,2), (4,1)
· Working assumption: BD/CCE budget for (4,2), (4,1) is half that of X=8
· A UE capable of multi-slot monitoring mandatorily supports the following PDCCH monitoring within Y slots
o For Y>1: FG3-1 (monitoring Group (1) SSs in the first 3 OFDM symbols of each of the Y slots)
o For 960 kHz SCS For Y=1: FG3-5b with set1 = (7, 3)
§ [FL Note: The first number is the minimum gap in symbols between the start of two spans, the second number is the span duration in symbols (cf. TS 38.822)]
o For 480 kHz SCS For Y=1: FG3-5b with set2 = (4, 3) and (7, 3) with a modification with maximum two monitoring spans in a slot
§ [FL Note: The first number is the minimum gap in symbols between the start of two spans, the second number is the span duration in symbols (cf. TS 38.822)]
o The following supersedes FG3-5b and FG3-1 definition:
o Processing one unicast DCI scheduling DL and one unicast DCI scheduling UL per slot group of X slots per scheduled CC for FDD
o Processing one unicast DCI scheduling DL and 2 unicast DCI scheduling UL per slot group of X slots per scheduled CC for TDD
Working assumption
The following values are adopted as minimum
value of 
for 120/480/960 kHz
· Support only search space set group switching processing capability 1 with the following values
|
|
Minimum UE processing capability 1 [symbols] |
|
3 |
40 |
|
5 |
160 |
|
6 |
320 |
Decision: As per email decision posted on Nov 19th,
Agreement
· SS set overbooking can be allowed with multi-slot PDCCH monitoring capability same as the current specification but applied per slot group, i.e., SS set overbooking is allowed for USS in PCell and PSCell, and UE expects no overbooking for CSS in PCell and PSCell and no overbooking in SCell.
· The dropping rule for multi-slot PDCCH monitoring capability is the same as the current specification but evaluated per slot group, i.e., a UE drops UE specific search space set(s) in a slot group with higher index when SS sets are overbooked.
· Additional dropping rules are not precluded
R1-2110829 Enhancement on PUCCH formats Huawei, HiSilicon
R1-2110874 Discussion on Enhancements of PUCCH formats for Beyond 52.6GHz FUTUREWEI
R1-2111000 Remaining issues on PUCCH enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2111076 Discussion on the PUCCH enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2111197 Remaining items for enhanced PUCCH formats 0/1/4 Nokia, Nokia Shanghai Bell
R1-2111243 Enhancements for PUCCH formats for up to 71GHz operation CATT
R1-2111309 Discussion on enhancements for PUCCH format 0/1/4 OPPO
R1-2111387 Views on enhancements for PUCCH formats 0/1/4 Sony
R1-2111465 PUCCH enhancements Ericsson
R1-2111485 Discussion on PUCCH enhancements for extending NR up to 71 GHz Intel Corporation
R1-2111834 Discussions on enhancements for PUCCH formats 0/1/4 InterDigital, Inc.
R1-2111863 Discussion on Enhancements for PUCCH formats 0_1_4 Apple
R1-2112047 Enhancements for PUCCH formats 0/1/4 to support NR above 52.6 GHz LG Electronics
R1-2112098 PUCCH format 0/1/4 enhancements for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2112205 Enhancements for PUCCH for NR in 52.6 to 71GHz band Qualcomm Incorporated
[107-e-NR-52-71GHz-03] – Steve (Ericsson)
Email discussion/approval on enhancements for PUCCH formats 0/1/4 with checkpoints for agreements on November 15 and 19
Decision: As per email decision posted on Nov 14th,
Agreement
For DMRS of enhanced PF1 support a single sequence of length equal to the total number of mapped REs of the PUCCH resource is used. The spreading factor for DMRS of enhanced PF1 is defined in the same way as Rel-16.
Decision: As per email decision posted on Nov 16th,
Agreement
In the RAN1#106bis-e agreements on construction of PUCCH resource sets prior to dedicated PUCCH configuration, the following is supported for PUCCH resource set index 15 in Table 9.2.1-1:
Decision: As per email decision posted on Nov 19th,
Agreement
Agreement (RAN1#104bis-e):
R1-2111466 FL Summary for Enhancements for PUCCH formats 0/1/4 Ericsson
Including timing associated with beam-based operation.
R1-2110830 Discussion on the beam management procedures for 52-71GHz spectrum Huawei, HiSilicon
R1-2110875 Beam management for Beyond 52.6GHz FUTUREWEI
R1-2111001 Remaining issues on beam management for new SCSs for NR operation from 52.6GHz to 71GHz vivo
R1-2111077 Discussion on the beam management for 52.6 to 71GHz ZTE, Sanechips
R1-2111198 Beam Management Aspects Nokia, Nokia Shanghai Bell
R1-2111244 Beam management for new SCSs for up to 71GHz operation CATT
R1-2111310 Discussion on beam management for new SCSs OPPO
R1-2111388 Beam management enhancement for NR from 52.6GHz to 71GHz Sony
R1-2111467 Beam Management for New SCSs Ericsson
R1-2111486 Discussion on Beam management aspects for extending NR up to 71 GHz Intel Corporation
R1-2111564 Discussion on beam management for new SCSs Xiaomi
R1-2111643 Beam-management enhancements for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2111703 Beam management enhancement for NR from 52.6GHz to 71GHz NEC
R1-2111727 Beam management for new SCSs for NR from 52.6 GHz to 71 GHz Samsung
R1-2111835 Discussions on beam management for new SCSs InterDigital, Inc.
R1-2111864 Beam Management for New SCSs Apple
R1-2112031 Beam management for NR from 52.6 GHz to 71 GHz Convida Wireless
R1-2112048 Enhancements for beam management to support NR above 52.6 GHz LG Electronics
R1-2112099 Beam based operation for new SCSs for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2112206 Beam management for new SCS Qualcomm Incorporated
R1-2112302 Beam management discussion for 52.6-71 GHz NR operation MediaTek Inc.
[107-e-NR-52-71GHz-04] – Youngwoo (InterDigital)
Email discussion/approval on beam management for new SCSs with checkpoints for agreements on November 15 and 19
R1-2111836 Discussion Summary #1 for Beam Management for new SCSs Moderator (InterDigital, Inc.)
From Nov 11th GTW session
Agreement
For Case 2 for single TRP and PDSCH scheduling offset for any scheduled PDSCH < timeDurationForQCL
R1-2112623 Discussion Summary #2 of Beam Management for New SCSs Moderator (InterDigital, Inc.)
R1-2112624 Discussion Summary #3 of Beam Management for New SCSs Moderator (InterDigital, Inc.)
R1-2112814 Discussion Summary #4 of Beam Management for New SCSs Moderator (InterDigital, Inc.)
Decision: As per email decision posted on Nov 20th,
Agreement
For multi-TRP with multi-PDSCH scheduling and offset for any scheduled PDSCH < timeDurationForQCL
· Multiple QCL assumptions are applied as per Rel-16
o The following Rel-16 rules are applied for each PDSCH with scheduling offset < timeDurationForQCL:
§ If a UE is configured with enableDefaultTCI-StatePerCoresetPoolIndex and the UE is configured by higher layer parameter PDCCH-Config that contains two different values of coresetPoolIndex in different ControlResourceSets,
· the UE may assume that the DM-RS ports of PDSCH associated with a value of coresetPoolIndex of a serving cell are quasi co-located with the RS(s) with respect to the QCL parameter(s) used for PDCCH quasi co-location indication of the CORESET associated with a monitored search space with the lowest controlResourceSetId among CORESETs, which are configured with the same value of coresetPoolIndex as the PDCCH scheduling that PDSCH, in the latest slot in which one or more CORESETs associated with the same value of coresetPoolIndex as the PDCCH scheduling that PDSCH within the active BWP of the serving cell are monitored by the UE.
o The Rel-16 rule corresponding to tci-PresentInDCI present and not present is applied for each PDSCH with scheduling offset ≥ timeDurationForQCL.
Agreement
For multi-TRP with multi-PDSCH scheduling and offset for any scheduled PDSCH < timeDurationForQCL
· Multiple QCL assumptions are applied as per Rel-16
o The following Rel-16 rules are applied for each PDSCH with scheduling offset < timeDurationForQCL:
§
If a UE
is configured with enableTwoDefaultTCI-States, and at least one TCI
codepoint indicates two TCI states, the UE may assume that the DM-RS ports of
PDSCH or PDSCH transmission occasions of a serving cell are quasi co-located
with the RS(s) with respect to the QCL parameter(s) associated with the TCI states
corresponding to the lowest codepoint among the TCI codepoints containing two
different TCI states. When the UE is configured
by higher layer parameter repetitionScheme set to 'tdmSchemeA' or is
configured with higher layer parameter repetitionNumber, and
the offset between the reception of the DL DCI and the first PDSCH transmission
occasion is less than the threshold timeDurationForQCL, the mapping of the TCI states to PDSCH
transmission occasions is determined according to clause 5.1.2.1 by replacing
the indicated TCI states with the TCI states corresponding to the lowest
codepoint among the TCI codepoints containing two different TCI states based
on the activated TCI states in the slot with the first PDSCH transmission
occasion.
o The Rel-16 rule corresponding to tci-PresentInDCI present and not present is applied for each PDSCH with scheduling offset ≥ timeDurationForQCL.
Final summary in R1-2112815.
Including defining maximum bandwidth for new SCSs, time line related aspects adapted to each of the new numerologies 480kHz and 960kHz, reference signals, scheduling particularly w.r.t. multi-PDSCH/PUSCH with a single DCI, HARQ, etc.
R1-2110831 PDSCH/PUSCH enhancements for 52-71GHz spectrum Huawei, HiSilicon
R1-2110876 Enhancements to support PDSCH/PUSCH for Beyond 52.6GHz FUTUREWEI
R1-2111002 Remaining issues on PDSCH/PUSCH enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2111078 Discussion on the data channel enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2111147 Considerations on multi-PDSCH/PUSCH with a single DCI and HARQ for NR from 52.6GHz to 71 GHz Fujitsu
R1-2111199 PDSCH/PUSCH enhancements Nokia, Nokia Shanghai Bell
R1-2111245 PDSCH/PUSCH enhancements for up to 71GHz operation CATT
R1-2111311 Discussion on PDSCH/PUSCH enhancements OPPO
R1-2111424 Discussion on PDSCH/PUSCH enhancements for NR 52.6-71 GHz Panasonic Corporation
R1-2111468 PDSCH-PUSCH Enhancements Ericsson
R1-2111487 Discussion on PDSCH/PUSCH enhancements for extending NR up to 71 GHz Intel Corporation
R1-2111565 PDSCH and PUSCH enhancements for NR 52.6-71GHz Xiaomi
R1-2111644 PDSCH/PUSCH scheduling enhancements for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2111692 Discussion on PDSCH enhancements supporting NR from 52.6GHz to 71 GHz NEC
R1-2111728 PDSCH/PUSCH enhancements for NR from 52.6 GHz to 71 GHz Samsung
R1-2111837 Enhancement for PDSCH/PUSCH to support 52.6 GHz-71 GHz band in NR InterDigital, Inc.
R1-2111865 Discussion on PDSCH and PUSCH Enhancements Apple
R1-2112049 PDSCH/PUSCH enhancements to support NR above 52.6 GHz LG Electronics
R1-2112100 PDSCH/PUSCH enhancements for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2112207 PDSCH/PUSCH enhancements for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2112303 Multi-PDSCH scheduling design for 52.6-71 GHz NR operation MediaTek Inc.
R1-2112522 Summary of PDSCH/PUSCH enhancements (Bandwidth/Timeline/Reference signals) Moderator (vivo)
[107-e-NR-52-71GHz-05] – Huaming (vivo)
Email discussion/approval on timeline related aspects adapted to each of the new numerologies 480kHz and 960kHz with checkpoints for agreements on November 15 and 19
Decision: As per email decision posted on Nov 14th,
Agreement
For NR operation with 480 kHz and/or 960 kHz SCS, CSI computation delay requirement 2 is always applied in the case of mixed SCS of PDCCH, CSI-RS and PUSCH.
· Note: this applies when any one of the SCSs for PDCCH, CSI-RS, and PUSCH is 480 kHz or 960 kHz
Agreement
UE behavior where all CPUs are occupied when UE processes the CSI report corresponding to the delay requirement 1 is not applicable for NR operation with 480 kHz and/or 960 kHz SCS.
· The following example change to 38.214 Section 5.2.1.6 can be recommended to the editor to use at the editor’s discretion
--- Unchanged parts omitted ---
if max{ µPDCCH, µCSI-RS,
µUL} ≤ 3, and if
a CSI report is aperiodically triggered without transmitting a PUSCH with
either transport block or HARQ-ACK or both when L = 0 CPUs are occupied,
where the CSI corresponds to a single CSI with wideband frequency-granularity
and to at most 4 CSI-RS ports in a single resource without CRI report and where
codebookType is set to 'typeI-SinglePanel' or where reportQuantity
is set to 'cri-RI-CQI', 
,
--- Unchanged parts omitted ---
Agreement
For NR operation with 480 kHz and/or 960 kHz SCS, scale the corresponding values of 120 kHz SCS by 4 and 8 for 480 kHz and 960 kHz SCS respectively for the following UE timeline parameters for single and multi-PDSCH/PUSCH scheduling to maintain the same absolute time duration as that of 120 kHz SCS in FR2.
· HARQ-ACK information in response to a SPS PDSCH release, N in 38.213 Section 10.2
· HARQ-ACK information in response to a detection of a DCI format 1_1 indicating Scell dormancy, N in 38.213 Section 10.3
· Determination of the resource allocation table to be used for PUSCH, Δ in 38.214 Section 6.1.2.1.1
· UE PDSCH reception preparation time with cross carrier scheduling with different subcarrier spacings for PDCCH and PDSCH, Npdsch in 38.214 Section 5.5
· Application delay of the minimum scheduling offset restriction, Zµ in 38.214 Section 5.3.1
Agreement
From RAN1 perspective, for NR operation with 480 kHz and/or 960 kHz SCS, the value of minimum time gap for wake-up and Scell dormancy indication (DCI format 2_6) is scaled by 4 and 8 of the corresponding value of 120 kHz SCS for 480 kHz and 960 kHz SCS respectively.
· Note: X in 38.213 Section 10.3 and 38.133 Section 8.2.1.2.7.
· Send LS to RAN4 to inform about RAN1’s agreement of the reference values and ask RAN4 to make final decision
R1-2112523 Discussion summary #1 of [107-e-NR-52-71GHz-05] Moderator (vivo)
From Nov 15th GTW session
Agreement
For NR operation with 480 kHz and/or 960 kHz SCS, select the following as the set of values for PDSCH-to-HARQ_feedback timing indicator field in DCI format 1_0.
· {7, 8, 12, 16, 20, 24, 28, 32} for 480 kHz and {13, 16, 24, 32, 40, 48, 56, 64} for 960 kHz
Conclusion
For NR operation with 480 kHz and/or 960 kHz SCS, d1,1 and d2 (to derive Tproc,1 in PDSCH processing time) and d2,1 and d2 (to derive Tproc,2 in PUSCH preparation time) reuse the values for Rel-16.
R1-2112638 [Draft] LS on the minimum time gap for wake-up and Scell dormancy indication for NR operation in 52.6 to 71 GHz Moderator (vivo)
Decision: As per email decision posted on Nov 19th, the draft LS is endorsed. Final version is approved in R1-2112639.
Final summary in R1-2112640.
[107-e-NR-52-71GHz-06] – Seonwook (LGE)
Email discussion/approval on scheduling particularly w.r.t. multi-PDSCH/PUSCH with a single DCI, HARQ, with checkpoints for agreements on November 15 and 19
R1-2112050 Summary #1 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
Decision: As per email decision posted on Nov 14th,
Agreement
· For multi-PDSCH or multi-PUSCH scheduling DCI, FDRA enhancement is deprioritized in Rel-17.
Agreement
· For multi-TRP operation, for 480/960 kHz SCS,
o A UE does not expect to be scheduled with more than one unicast PDSCH in a slot, by a single DCI or multiple DCIs, from the same TRP.
o A UE does not expect to be scheduled with more than one PUSCH in a slot, by a single DCI or multiple DCIs, from the same TRP.
o Note: This does not preclude a UE being scheduled with two PDSCHs (or two PUSCHs) in the same slot from two different TRPs for multi-DCI based multi-TRP mechanism.
R1-2112620 Summary #2 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
From Nov 15th GTW session
Agreement
· For a DCI that can schedule multiple PDSCHs, CBGTI and CBGFI fields are not present in the DCI.
· UE does not expect to be configured with both of CBG operation and multi-PDSCH scheduling in the serving cell with a Type 1 codebook.
· Confirm the working assumption from RAN1#106bis-e with the following modification.
Working assumption: (RAN1#106bis-e)
§ UE does not expect to be configured with both of CBG operation and multi-PDSCH scheduling in the same PUCCH cell group with a Type 2 codebook.
·
If
time bundling operation is supported, this working assumption can be revisited
Agreement
For 480/960 kHz SCS, CBG-based HARQ cannot be configured for uplink and downlink.
Agreement
The maximum number of PDSCHs that can be scheduled with a single DCI in Rel-17 is also 8 when 2 TB is enabled or when 2 TB is scheduled, for SCS of 120, 480 and 960 kHz.
· Note: This is to handle FFS (the maximum number of PDSCHs when 2 TB is enabled or when 2 TB is scheduled) in previous agreement in RAN1#106bis-e.
Decision: As per email decision posted on Nov 16th,
Agreement
For multi-PUSCH scheduling DCI in Rel-17, support intra-slot frequency hopping which is applicable to each of multiple PUSCH transmissions scheduled by the DCI, and do not support inter-slot frequency hopping.
R1-2112703 Summary #3 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
From Nov 17th GTW session
Agreement
For multi-PDSCH scheduling with a single DCI
· Introduce a new RRC parameter, e.g., enableTimeDomainHARQ-Bundling, to enable time domain bundling operation for type-1 HARQ-ACK codebook per serving cell.
o If the RRC parameter enables time domain bundling operation,
§ To determine the set of candidate PDSCH reception occasions,
· A row index is removed if at least one symbol of every PDSCH associated with the row index is configured as semi-static UL. (NOTE: This is similar to the case of slot aggregated PDSCH in Rel-16)
· Pruning procedure in Rel-16 is performed based on the last configured SLIV of each row index.
§ Logical AND operation is applied across all valid PDSCHs associated with a determined candidate PDSCH reception occasion, at least for 1-TB case.
§ FFS: UE does not expect the last scheduled SLIV overlaps with a semi-static UL symbol when parameter enableTimeDomainHARQ-Bundling is configured
Decision: As per email decision posted on Nov 19th,
Agreement
· If a UE is configured with a TDRA table in which one or more rows contain multiple SLIVs for PDSCH for DCI format 1_1, the UE does not expect to be configured with repetitionNumber for the TDRA table, and if pdsch-AggregationFactor is configued in PDSCH-config, it does not apply to DCI format 1_1.
o Note: repetitionNumber cannot be configured with pdsch-TimeDomainAllocationListDCI-1-2 as in Rel-16.
o Note: Under agenda item 8.2.4, in RAN1#106-bis, it was already agreed that within the TDRA table for multi-PDSCH scheduling, the UE does not expect to be configured with the higher layer parameter repetitionNumber.
o Note: These does not preclude pdsch-AggregationFactor can be configured and applies to DCI format 1_2
· If a UE is configured with a TDRA table in which one or more rows contain multiple SLIVs for PUSCH for DCI format 0_1, the UE does not expect to be configured with numberOfRepetitions for the TDRA table, and if pusch-AggregationFactor is configued in PUSCH-config, it does not apply to DCI format 0_1.
o Note: These does not preclude numberOfRepetitions is configured for TDRA table corresponding to DCI format 0_2
o Note: These does not preclude pusch-AggregationFactor can be configured and applies to DCI format 0_2
Agreement
· For type-2 HARQ-ACK codebook generation, HARQ-ACK bit ordering is based on configured SLIV position in the indicated TDRA row index, regardless of the validity of each scheduled PDSCH.
Agreement
· There is no consensus in RAN1 to support that HARQ-ACK information corresponding to different PDSCHs scheduled by a single DCI is carried over multiple PUCCHs in Rel-17.
Agreement
For multi-PDSCH scheduling with a single DCI
· Introduce a new RRC parameter, e.g., numberOfHARQ-BundlingGroups, to configure the number of HARQ bundling groups with value range {1, 2, 4} for type-2 HARQ-ACK codebook per serving cell.
o If the RRC parameter is not configured for a serving cell, time domain bundling for type-2 HARQ-ACK codebook is not enabled for the serving cell.
o The maximum number of PDSCHs allocated to each bundling group is ceil(NPDSCH,MAX/NHBG) where NHBG is the number of bundling groups configured by numberOfHARQ-BundlingGroups for a serving cell and NPDSCH,MAX is the maximum configured number of PDSCHs for the serving cell.
o The PDSCHs corresponding to [configured or valid] SLIVs in a TDRA row index indicated by multi-PDSCH scheduling DCI are allocated to the bundling groups, e.g., if NHBG =4, NPDSCH,MAX =8, and 5 PDSCHs are scheduled, then 2/1/1/1 PDSCHs are assigned to each group, by reusing CBG grouping method.
§ For a group that is empty or is filled with only invalid PDSCH(s), HARQ-ACK bits for the bundling group is set to NACK (same principle as when no time bundling configured)
§ Logical AND operation is applied to across all valid PDSCHs within the same bundling group to generate 1 HARQ-ACK bit per group, at least for 1-TB case
o If the number of HARQ bundling groups is configured as 1 for a serving cell, HARQ-ACK bits corresponding to any DCI for the serving cell belong to the first sub-codebook.
o At least for 1-TB case, if the number of HARQ bundling groups is configured as larger than 1 for a serving cell, HARQ-ACK bits corresponding to multi-PDSCH scheduling case (which implies a multi-PDSCH DCI schedules more than one PDSCH) for the serving cell belong to the second sub-codebook,
§ Where the number of HARQ-ACK bits corresponding to a multi-PDSCH DCI is determined based on the maximum of Q value across all serving cells within the same PUCCH cell group, and Q=maximum configured number of PDSCHs for a cell without numberOfHARQ-BundlingGroups configured or Q=number of configured HARQ bundling groups for a cell with numberOfHARQ-BundlingGroups configured
Final summary in R1-2112714.
R1-2110832 Channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
R1-2110877 Channel access for Beyond 52.6GHz FUTUREWEI
R1-2110894 Discussion on relation between sensing beam and transmission beam GDCNI
Late submission
R1-2111003 Remaining issues on channel access mechanism for NR operation from 52.6GHz to 71 GHz vivo
R1-2111079 Discussion on the channel access for 52.6 to 71GHz ZTE, Sanechips
R1-2111093 Discussion on channel access mechanism for above 52.6GHz Spreadtrum Communications
R1-2111148 Considerations on channel access mechanism for NR from 52.6GHz to 71 GHz Fujitsu
R1-2111200 Channel access mechanism Nokia, Nokia Shanghai Bell
R1-2111246 Channel access mechanism for up to 71GHz operation CATT
R1-2111312 Discussion on channel access mechanism OPPO
R1-2111389 Channel access mechanism for 60 GHz unlicensed spectrum Sony
R1-2111418 Channel access mechanisms for NR above 52 GHz Charter Communications
R1-2111469 Channel Access Mechanisms Ericsson
R1-2111488 Discussion on channel access mechanism for extending NR up to 71 GHz Intel Corporation
R1-2111566 Discussion on channel access mechanism for NR on 52.6-71 GHz Xiaomi
R1-2111645 Channel access mechanisms for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
R1-2111651 Some discussions on channel access mechanism enhancements for 52.6-71 GHz CAICT
R1-2111702 Discussion on channel access mechanism supporting NR from 52.6 to 71GHz NEC
R1-2111707 Channel access for multi-beam operation Panasonic
R1-2111729 Channel access mechanism for NR from 52.6 GHz to 71 GHz Samsung
R1-2111838 Discussion on channel access mechanisms InterDigital, Inc.
R1-2111866 Channel access mechanisms for unlicensed access above 52.6GHz Apple
R1-2112032 Channel Access Mechanism for Supporting NR from 52.6 GHz to 71 GHz Convida Wireless
R1-2112051 Channel access mechanism to support NR above 52.6 GHz LG Electronics
R1-2112101 Channel access mechanism for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2112166 Remaining issue on channel access scheme for above 52.6GHz ASUSTeK
R1-2112172 Discussion on multi-beam operation ITRI
R1-2112208 Channel access mechanism for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2112268 Channel access mechanism for NR in 60GHz unlicensed band operation TCL Communication Ltd.
R1-2112291 On the channel access mechanisms for 52.6-71 GHz NR operation MediaTek Inc.
R1-2112385 Remaining issues on channel access for NR from 52.6GHz to 71GHz WILUS Inc.
[107-e-NR-52-71GHz-07] – Jing (Qualcomm)
Email discussion/approval on channel access mechanism with checkpoints for agreements on November 15 and 19
Decision: As per email decision posted on Nov 14th,
Conclusion
On the gap Y for Cat 2 LBT when COT Sharing is applied, no matter which option is chosen out of options 1/2/3, the UE does not need to know the value for Y, as the UE will follow DCI to determine if Cat 2 LBT is performed
· Note: If Y is specified in 3GPP spec or not is discussed separately
Conclusion
Rel.16 NR-U style Cyclic Prefix extension is not supported for FR2-2 at least for DCI scheduled UL transmission
· FFS: If CP extension is supported for CG-PUSCH in FR2-2
Agreement
For Non-Fallback DCI formats, for FR2-2 operation, for the configuration of the ChannelAccess-CPext field in DCI to indicate the channel access type only, new tables are introduced indicating channel access types for FR2-2, with entries “Type 1 channel access in 4.4.1 of 37.213”, “Type 2 channel access in 4.4.2 of 37.213” and “Type 3 channel access in 4.4.3 of 37.213”.
R1-2112460 Email discussion summary for channel access for beyond 52.6GHz band Moderator (Qualcomm)
R1-2112617 Email discussion summary#2 for channel access for beyond 52.6GHz band Moderator (Qualcomm)
From Nov 15th GTW session
Agreement
For the following situations
· Selecting sensing beam at the gNB
· Selecting sensing beam at the UE when UE does not indicate a capability for beam correspondence with beamCorrespondenceWithoutUL-BeamSweeping ={1}
· Selecting sensing beam at the UE when UE uses a different beam for sensing than the beam used for transmission,
Specify necessary requirement/test procedure to guarantee sensing beam(s) “covers” the transmission beam(s)
· Some methods to define “cover” have been discussed in RAN1
o Alt-1A: the angle included in the [3] dB beamwidth of the transmission beam is included in the [X, FFS] dB beamwidth of the sensing beam.
o Alt-1B: the sensing beam gain measured along the direction of peak transmission direction is at least X [FFS] dB of the transmission beam gain
o Alt-1C: The sensing beam gain is measured in one or more directions where the transmission beam EIRP is within A [FFS] dB of the peak EIRP. The sensing beam gain measured along the chosen directions is at least X [FFS] dB of the transmission beam gain in those directions.
o Alt-1D: The sensing beam gain is measured in one or more directions where the transmission beam EIRP is within A [FFS] dB of the peak EIRP and the sensing beam gain measured along the chosen directions is at least X [FFS] dB of the peak sensing beam gain
o Alt-1E: Sensing beam has the minimum [3] dB beamwidth which at least contains all beam peak directions of transmission beams.
o Alt-1F:
§ Selecting sensing beam at the gNB is up to gNB’s implementation
§ Sensing beam at the UE may use a wider beam for sensing than the beam used for transmission, when the UE does not indicate a capability for beam correspondence with beamCorrespondenceWithoutUL-BeamSweeping ={1}
· Sending LS to RAN4 and inform them the above and request them to make the final choice
o RAN4 choice may not be limited by the list above
o RAN4 can further decide for gNB or UE separately if such test or requirement is not needed or not practical and leave it to gNB or UE implementation
R1-2112706 LS to RAN4 on sensing beam selection RAN1, Qualcomm
Decision: As per email decision posted on Nov 20th, the draft LS is endorsed. Final LS is approved in R1-2112806.
Decision: As per email decision posted on Nov 20th,
Confirm the following working assumption with some clarifications
· For Pout in EDT determination, define Pout as the maximum EIRP of the intended transmissions by the node determining EDT during a COT.
o The node is not expected to transmit in the COT with higher Pout than the Pout used to determine the EDT used to acquire the COT
Agreement
· For LBT purpose, the energy at gNB/UE is measured after antenna and antenna gain is included in the energy measurement.
· The energy measurement is compared with EDT with no further adjustment to EDT standardized in Rel.17
o Note: This does not rule out extra backoff (conservative) EDT being applied as gNB or UE implementation
Agreement
For gNB initiated COT, for Pout in EDT determination at the initiating device (gNB), the Pout of the responding device (UE) is not considered
Agreement
For UE initiated COT, for EDT determination at the initiating device (UE), the Pout of the responding device (gNB) is not considered
Agreement
For
Type 1 channel access, 
is a random number
uniformly distributed between 0 and CW=3
·
By implementation, a node
may choose a larger number for counter N than
Agreement
The minimum measurement duration X within a 5 µs observation slot is left for gNB or UE implementation
· Note: This agreement does not prevent RAN4 from setting minimum requirement for measurement duration X.
Agreement
On COT sharing from an initiating device transmission to responding device transmission, when a maximum gap Y is defined, such that a responding device transmission can occur without LBT only if the transmission starts within Y from the end of the initiating device transmission, and a responding device transmission can occur with Cat 2 LBT if the transmission starts later than Y from the end of the initiating device transmission.
· gNB determines Y as gNB implementation (for example, according to local regulation) and the value of Y will not be captured in 3GPP spec other than requiring Y to be no less than 8 us.
Conclusion
UL to DL COT sharing is supported for FR2-2 unlicensed operation, including from dynamically scheduled UL and CG-PUSCH.
Agreement
For CG-PUSCH to DL COT sharing, extend the duration and offset range to {1, …, 319}.
Conclusion
There is no consensus to support introducing L1-RSSI mechanism for FR2-2 in Rel.17.
Agreement
For a COT with MU-MIMO (SDM) transmission, support both Alt 1 and Alt 2 below:
· Alt 1: Single LBT sensing at the start of the COT with wide beam ‘cover’ all beams to be used in the COT with appropriate ED threshold
· Alt 2: Independent per-beam LBT sensing at the start of COT is performed for beams used in the COT, if the node can perform simultaneous sensing in different beams
Note: On UE side, no UE capability will be introduced for this purpose.
Agreement
Within a COT with TDM of beams with beam switching, at least support Alt 1
· Alt 1 (from previous agreement): Single LBT sensing with wide beam ‘cover’ all beams to be used in the COT
Agreement
Within a COT with TDM of beams with beam switching, Alt 2 is supported if the node has the capability to perform simultaneous sensing in different beams. Alt 3 is allowed as node implementation choice if the node also supports Cat 2 LBT. The use of Alt 2 or Alt 3 is based on node’s implementation.
· Alt 2 from previous agreement: Independent per-beam LBT sensing at the start of COT is performed for beams used in the COT
· Alt 3 from previous agreement: Independent per-beam LBT sensing at the start of COT is performed for beams used in the COT with additional requirement on Cat 2 LBT before beam switch
Agreement
In regions where channel sensing is required and short control signalling exemption is allowed by regulations, contention Exempt Short Control Signaling rules can be applicable to the transmission of discovery burst (as defined in 37.213 6.0)
Conclusion
In Rel.17, there is no consensus to apply contention exemption short control signalling to UL transmissions other than msg1 and msgA.
Final summary in R1-2112820.
R1-2111004 Remaining issues on CSI-RS related issues for NR operation from 52.6GHz to 71GHz vivo
R1-2111080 Discussion on RRC parameters for 52.6 to 71GHz ZTE, Sanechips
R1-2111201 PTRS enhancements for DFTsOFDM Nokia, Nokia Shanghai Bell
R1-2111247 Some issues on SPS for one DCI scheduling multiple PDSCHs case CATT
R1-2111470 NR channelization for the 57 – 71 GHz band Ericsson
R1-2111928 Additional SLS results on channel access Huawei, HiSilicon
Please refer to RP-213540 for detailed scope of the WI.
R1-2200805 Session notes for 8.2 (Extending current NR operation to 71GHz) Ad-Hoc Chair (Huawei) (rev of R1-2200792 )
[107bis-e-R17-RRC-52-71GHz] – Jing (Qualcomm)
Email discussion on Rel-17 RRC parameters for supporting NR from 52.6 GHz to 71 GHz
- Email discussion to start on January 20 and end by January 25
R1-2200804 FL summary for RRC parameter discussion for 52.6 to 71GHz band Moderator (Qualcomm)
Document is noted. For consolidation under 8 in [107bis-e-R17-RRC].
R1-2200808 List of agreements of Rel-17 52.6-71GHz WI (post RAN1#107bis-e) Moderator (Qualcomm)
Including SSB, initial BWP, PRACH, etc.
R1-2200024 On remaining issues for initial access for Beyond 52.6GHz FUTUREWEI
R1-2200044 Remaining issue of initial access signals and channels for 52-71GHz spectrum Huawei, HiSilicon
R1-2200059 Remaining issues for initial access operation in 52.6-71GHz InterDigital, Inc.
R1-2200074 Remaining issues on initial access aspects for NR operation from 52.6GHz to 71GHz vivo
R1-2200142 Remaining issues on Initial access aspects for up to 71GHz operation CATT
R1-2200183 Initial access aspects Nokia, Nokia Shanghai Bell
R1-2200192 Maintenance on initial access aspects for NR from 52.6 GHz to 71 GHz Samsung
R1-2200226 Remaining issues on initial access aspects for NR in FR2-2 NTT DOCOMO, INC.
R1-2200259 Remaining issues on the initial access aspects for 52.6 to 71GHz ZTE, Sanechips
R1-2200273 Discussion on initial access aspects for NR for 60GHz Spreadtrum Communications
R1-2200324 Discussion on remaining issue for initial access aspects OPPO
R1-2200355 Remaining issues on initial access aspects for NR from 52.6 to 71GHz ETRI
R1-2200366 Discussion on initial access aspects for extending NR up to 71 GHz Intel Corporation
R1-2200400 Initial Access Aspects Ericsson
R1-2200409 On remaining issues for initial access Apple
R1-2200494 Initial access aspects Sharp
R1-2200564 Initial access aspects to support NR above 52.6 GHz LG Electronics
[107bis-e-R17-52-71GHz-01] – Daewon (Intel)
Email discussion/approval on initial access aspects
- 1st check point: January 20
- Final check point: January 25
R1-2200688 Issue Summary for initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
Decision: As per email decision posted on Jan 21st,
Conclusion
RRC parameters list to capture changes identified below:
· Add the following note to the comment section of discoveryBurstWindowLength-r17 row in RRC parameter list
o Note: This parameter is to be included in both SIB1 and the common serving cell configuration parameters.
· Support adding “SSB-PositionQCL-Relation-r17” to RRC parameter list as both UE-specific and cell-specific parameter.
· Inform RAN2 (by adding notes to RRC parameter list) that the either the value range of the information element SSB-PositionQCL-Relation-r16 needs to be extended, or a new Rel-17 IE need to be defined to allow configuration of Q = 16, 32, or 64 in SIB2, SIB3, SIB4, MeasObjectNR, and ServingCellConfigCommon for RRM measurements when operating with shared spectrum channel access in FR2-2.
Working assumption
The TP below for TS38.213v17.0.0 is endorsed.
|
=========== Unchanged Text Omitted =========== Table 13-15A: PDCCH monitoring occasions for Type0-PDCCH CSS set - SS/PBCH block and CORESET multiplexing pattern 3 and {SS/PBCH block, PDCCH} SCS {480, 480} kHz or {960, 960} kHz
============ Unchanged Text Omitted ============ |
Agreement
The TP below for TS38.211v17.0.0 is endorsed.
|
*** Unchanged text omitted *** 5.3.2 OFDM baseband signal generation for PRACH The
time-continuous signal
*** Unchanged text omitted *** |
Agreement
The TP below for TS38.214v17.0.0 is endorsed.
|
*** Unchanged text omitted *** 7 UE procedures for transmitting and receiving on a carrier with intra-cell guard bands For
operation with shared spectrum channel access in
FR1, when the UE is configured with any of IntraCellGuardBandsPerSCS
for UL carrier and for DL carrier with SCS configuration *** Unchanged text omitted *** |
R1-2200689 Summary #1 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
From Jan 25th GTW session
Agreement
The TP# 8-1a for TS38.213 in section 3 of R1-2200689 is endorsed.
Decision: As per email decision posted on Jan 25th,
Conclusion
RRC parameters list to capture changes identified below
· New parameter, ra-ResponseWindow-r17, under sub-feature group SSB and RACH
o Value range {sl240, sl320, sl640, sl960, sl1280, sl1920, sl2560}
o Based on previous conclusion:
§ For FR2-2, support the same mechanism as in Rel-16 for extended RAR window for both 4-step and 2-step RACH.
· New parameter, msgB-ResponseWindow-r17, under sub-feature group SSB and RACH
o Value range { sl240, sl640, sl960, sl1280, sl1920, sl2560}
o Based on previous conclusion:
§ For FR2-2, support the same mechanism as in Rel-16 for extended RAR window for both 4-step and 2-step RACH.
· Existing parameter, msgA-PRACH-RootSequenceIndex-r16, under sub-feature group SSB and RACH
o Description:
§ May not need to change the IE, but need to add in the note on the limitation to be used with SCS. Field description requires updating to capture that L = 1151 is not supported for SCS 480 and 960 kHz and L = 571 is not supported for 960 kHz.
o Value range:
§ CHOICE { l571 INTEGER {0..569}, l1151 INTEGER {0..1149}}
· Cell-specific
Final summary in R1-2200690.
R1-2200045 Remaining issues of PDCCH monitoring enhancement for 52-71GHz spectrum Huawei, HiSilicon
R1-2200060 Remaining issues for PDCCH monitoring enhancements InterDigital, Inc.
R1-2200075 Remaining issues on PDCCH monitoring enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2200143 Remaining issues on PDCCH monitoring enhancements for up to 71GHz operation CATT
R1-2200174 PDCCH enhancement for NR from 52.6GHz to 71GHz Sony
R1-2200184 PDCCH monitoring enhancements Nokia, Nokia Shanghai Bell
R1-2200193 Maintenance on PDCCH monitoring enhancements for NR from 52.6 GHz to 71 GHz Samsung
R1-2200227 Remaining issues on PDCCH monitoring enhancements for NR in FR2-2 NTT DOCOMO, INC.
R1-2200260 Remaining issues on the PDCCH monitoring enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2200290 PDCCH monitoring enhancements for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2200325 Discussion on remaining issue for PDCCH monitoring enhancement OPPO
R1-2200367 Discussion on PDCCH monitoring enhancements for extending NR up to 71 GHz Intel Corporation
R1-2200401 PDCCH Monitoring Enhancements Ericsson
R1-2200410 On remaining issues for PDCCH Monitoring Apple
R1-2200459 Remaining issues on PDCCH monitoring enhancement for NR 52.6-71GHz xiaomi
R1-2200495 PDCCH monitoring enhancements Sharp
R1-2200507 Remaining issues on PDCCH enhancement for NR operation from 52.6GHz to 71GHz NEC
R1-2200540 Remaining discussion on PDCCH monitoring enhancement for 52.6-71 GHz NR operation MediaTek Inc.
R1-2200558 Remaining issues of PDCCH monitoring enhancements for above 52.6GHz Transsion Holdings
R1-2200565 PDCCH monitoring enhancements to support NR above 52.6 GHz LG Electronics
R1-2200654 PDCCH monitoring for NR operation from 52.6 to 71 GHz Panasonic
R1-2200671 Remaining issues on PDCCH for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
[107bis-e-R17-52-71GHz-02] – Alex (Lenovo)
Email discussion/approval on PDCCH monitoring enhancements
- 1st check point: January 20
- Final check point: January 25
R1-2200709 Feature lead summary #1 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
From Jan 17th GTW session
Conclusion
· Single-slot PDCCH monitoring for 480 kHz and 960 kHz is not supported.
R1-2200710 Feature lead summary #2 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
Decision: As per email decision posted on Jan 23rd,
Conclusion
A duration of more than 3 OFDM symbols for PDCCH with 480/960 kHz SCS is not supported in Rel-17.
R1-2200711 Feature lead summary #3 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
From Jan 25th GTW session
Agreement
For search space set configuration of multi-slot PDCCH monitoring:
Conclusion
Keep r17monitoringcapability in 38.213, and work on the potential RAN1 spec impact at RAN1#108e.
Decision: As per email decision posted on Jan 25th,
Agreement
Clarify earlier agreement as follows:
· A UE capable of multi-slot monitoring mandatorily supports monitoring Group (2) SSs according to FG 3-1 within each of the Xs slots of a slot-group, such that:
o For type 1 CSS without dedicated RRC configuration and for type 0, 0A, and 2 CSS, the monitoring occasion can be any OFDM symbol(s) of each slot, with the monitoring occasions for any of Type 1- CSS without dedicated RRC configuration, or Types 0, 0A, or 2 CSS configurations within a single span of three consecutive OFDM symbols within each slot of the slot group.
· Continue discussion on whether or not introducing other limitation for Group (2) SSs in RAN1#108-e.
Conclusion
The SSSG switching timer is in units of slots.
Conclusion
Potential indications of UE capability related to a limited support of cross-carrier scheduling e.g. as a function of |μPDCCH − μPDSCH| can be discussed as part of the UE capability discussion.
R1-2200046 Remaining issues of PUCCH enhancement for 52-71GHz spectrum Huawei, HiSilicon
R1-2200061 Remaining issues for enhanced PUCCH formats 0/1/4 InterDigital, Inc.
R1-2200679 Remaining issues on PUCCH enhancements for NR operation from 52.6GHz to 71GHz vivo (rev of R1-2200076 )
R1-2200175 Remaining issues on enhancements for PUCCH formats 0/1/4 Sony
R1-2200185 Finalization of enhanced PUCCH formats 0/1/4 Nokia, Nokia Shanghai Bell
R1-2200194 Maintenance on enhancements for PUCCH format 0/1/4 for NR from 52.6 GHz to 71 GHz Samsung
R1-2200228 Remaining issues on PUCCH format 0/1/4 enhancements for NR in FR2-2 NTT DOCOMO, INC.
R1-2200261 Remaining issues on the PUCCH enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2200326 Discussion on remaining issue for enhancements for PUCCH format 0/1/4 OPPO
R1-2200368 Discussion on PUCCH enhancements for extending NR up to 71 GHz Intel Corporation
R1-2200402 PUCCH enhancements Ericsson
R1-2200446 Remaining issues on PUCCH formats enhancements for beyond 52.6GHz FUTUREWEI
R1-2200566 Enhancements for PUCCH formats 0/1/4 to support NR above 52.6 GHz LG Electronics
[107bis-e-R17-52-71GHz-03] – Steve (Ericsson)
Email discussion/approval on enhancements for PUCCH formats 0/1/4
- 1st check point: January 20
- Final check point: January 25
R1-2200403 FL Summary for Enhancements for PUCCH formats 0/1/4 Ericsson
Decision: As per email decision posted on Jan 23rd,
Conclusion
· For DMRS of enhanced (multi-RB) PF4, do not support Type-1 low PAPR sequences if pi2BPSK is configured for the PUCCH resource.
· No change to 38.211 Section 6.4.1.3.3.1 is needed.
Including timing associated with beam-based operation.
R1-2200047 Remaining issues of beam management enhancement for 52-71GHz spectrum Huawei, HiSilicon
R1-2200062 Remaining issues for beam management for new SCSs InterDigital, Inc.
R1-2200077 Remaining issues on beam management for new SCSs for NR operation from 52.6GHz to 71GHz vivo
R1-2200144 Remaining issues on beam management for new SCSs for up to 71GHz operation CATT
R1-2200176 Remaining issues on beam management enhancement for NR from 52.6GHz to 71GHz Sony
R1-2200186 Beam Management Aspects Nokia, Nokia Shanghai Bell
R1-2200195 Maintenance on beam management for new SCSs for NR from 52.6 GHz to 71 GHz Samsung
R1-2200229 Remaining issues on Beam based operation for new SCSs for NR in FR2-2 NTT DOCOMO, INC.
R1-2200262 Remaining issues on the beam management for 52.6 to 71GHz ZTE, Sanechips
R1-2200291 Beam management for new SCS Qualcomm Incorporated
R1-2200327 Discussion on remaining issue for beam management for new SCSs OPPO
R1-2200369 Discussion on Beam management aspects for extending NR up to 71 GHz Intel Corporation
R1-2200404 Beam Management for New SCSs Ericsson
R1-2200411 Beam Management for New SCSs Apple
R1-2200447 On issues in Beam Management for Beyond 52.6 GHz FUTUREWEI
R1-2200460 Maintenance on beam management for new SCSs xiaomi
R1-2200515 Beam management enhancement for NR from 52.6GHz to 71GHz NEC
R1-2200541 Remaining discussion on beam management for 52.6-71 GHz NR operation MediaTek Inc.
R1-2200567 Enhancements for beam management to support NR above 52.6 GHz LG Electronics
R1-2200672 Remaining issues on beam-management for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
[107bis-e-R17-52-71GHz-04] – Youngwoo (InterDigital)
Email discussion/approval on beam management for new SCSs
- 1st check point: January 20
- Final check point: January 25
R1-2200063 Discussion Summary #1 for Beam Management for new SCSs Moderator (InterDigital, Inc.)
R1-2200760 Discussion Summary #2 of Beam Management for New SCSs Moderator (InterDigital)
Decision: As per email decision posted on Jan 23rd,
Conclusion
Multiple SRIs for multi-PUSCHs by a single DCI are not supported in Rel-17.
Agreement
For maxNumberRxTxBeamSwitchDL, reuse the following candidate values {4, 7, 14} of 120 kHz in FR2-1 for 120 kHz in FR2-2.
Agreement
Support the value of BeamAppTime_r17 for 120 kHz SCS in FR2-2 as the same value for 120 kHz in FR2-1.
Support the value of BeamAppTime_r17 for 480 kHz SCS as 4 times its value for 120 kHz.
Support the value of BeamAppTime_r17 for 960 kHz SCS as 8 times its value for 120 kHz.
R1-2200783 [Draft] LS on a minimum guard period between two SRS resources for antenna switching InterDigital
Decision: As per GTW decision on Jan 25th, the draft LS is endorsed with changing “kindly” to “respectfully”. Final LS is approved in R1-2200796.
Decision: As per email decision posted on Jan 25th,
Agreement
The TP below for section 5.1.5 of TS38.214v17.0.0 is endorsed
============================== Start of TP for TS 38.214 ===============================
5.1.5 Antenna ports quasi co-location
*** Unchanged text omitted ***
When the UE is
configured with CORESET associated with a search space set for cross-carrier
scheduling and the UE is not configured with enableDefaultBeamForCCS,
the UE expects tci-PresentInDCI is set as 'enabled' or tci-PresentDCI-1-2
is configured for the CORESET, and if one or more of the TCI states
configured for the serving cell scheduled by the search space set contains qcl-Type set to
'typeD', the UE expects the time offset between the reception of the detected
PDCCH in the search space set and a the corresponding
PDSCH is larger than or equal to the threshold timeDurationForQCL.
*** Unchanged text omitted ***
If the PDCCH carrying the scheduling DCI is received on one
component carrier, and a the PDSCH
scheduled by that DCI is on another component carrier:
-
The timeDurationForQCL is determined based on the subcarrier spacing of
the scheduled PDSCH. If µPDCCH < µPDSCH
an additional timing delay 
is added to
the timeDurationForQCL, where d is defined in 5.2.1.5.1a-1, otherwise d is zero;
- When the UE is configured with enableDefaultBeamForCCS, if the offset between the reception of the DL DCI and the corresponding PDSCH is less than the threshold timeDurationForQCL, or if the DL DCI does not have the TCI field present, the UE obtains its QCL assumption for the scheduled PDSCH from the activated TCI state with the lowest ID applicable to PDSCH in the active BWP of the scheduled cell.
*** Unchanged text omitted ***
============================== End of TP for TS 38.214 ===============================
Conclusion
From RAN1 perspective, there is no consensus to enhance beam management for shared spectrum operation in Rel-17.
Final summary in R1-2200761.
Including defining maximum bandwidth for new SCSs, time line related aspects adapted to each of the new numerologies 480kHz and 960kHz, reference signals, scheduling particularly w.r.t. multi-PDSCH/PUSCH with a single DCI, HARQ, etc.
R1-2200025 On several study points for PDSCH/PUSCH enhancements for Beyond 52.6GHz FUTUREWEI
R1-2200048 Remaining issues of PDSCH/PUSCH enhancement for 52-71GHz spectrum Huawei, HiSilicon
R1-2200064 Remaining issues for PDSCH/PUSCH enhancements to supporting 52.6-71 GHz band in NR InterDigital, Inc.
R1-2200078 Remaining issues on PDSCH/PUSCH enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2200124 Remaining issues of multi-PDSCH scheduling via a single DCI Fujitsu
R1-2200145 Remaining issues on PDSCH/PUSCH enhancements for up to 71GHz operation CATT
R1-2200187 PDSCH/PUSCH enhancements Nokia, Nokia Shanghai Bell
R1-2200196 Maintenance on PDSCH/PUSCH enhancements for NR from 52.6 GHz to 71 GHz Samsung
R1-2200230 Remaining issues on PDSCH/PUSCH enhancements for NR in FR2-2 NTT DOCOMO, INC.
R1-2200263 Remaining issues on the data channel enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2200267 Discussion on PDSCH/PUSCH enhancements for NR 52.6-71 GHz Panasonic Corporation
R1-2200292 PDSCH/PUSCH enhancements for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2200328 Discussion on remaining issue for PDSCH/PUSCH enhancements OPPO
R1-2200370 Discussion on PDSCH/PUSCH enhancements for extending NR up to 71 GHz Intel Corporation
R1-2200405 PDSCH-PUSCH Enhancements Ericsson
R1-2200412 On remaining issues for PDSCH/PUSCH Enhancements Apple
R1-2200461 Remaining issues on PDSCH and PUSCH enhancements for NR 52.6-71GHz xiaomi
R1-2200508 Remaining issues on PDSCH/PUSCH enhancement for NR operation from 52.6GHz to 71GHz NEC
R1-2200542 Remaining discussion on multi-PDSCH scheduling design for 52.6-71 GHz NR operation MediaTek Inc.
R1-2200568 PDSCH/PUSCH enhancements to support NR above 52.6 GHz LG Electronics
R1-2200631 Discussion on multi-PUSCH scheduling ASUSTeK
R1-2200632 Remaining issues on PDSCH/PUSCH enhancement for NR from 52.6GHz to 71GHz WILUS Inc.
[107bis-e-R17-52-71GHz-05] – Huaming (vivo)
Email discussion/approval on timeline related aspects adapted to each of the new numerologies 480kHz and 960kHz
- 1st check point: January 20
- Final check point: January 25
Decision: As per email decision posted on Jan 21st,
Agreement
For NR operation with 480 kHz and/or 960 kHz SCS, select the following as the set of values for HARQ Feedback Timing Indicator field in successRAR.
----- Start of TP
--- Unchanged parts omitted ---
If the UE detects the DCI format 1_0, with CRC scrambled by the corresponding MsgB-RNTI and LSBs of a SFN field in the DCI format 1_0, if applicable, are same as corresponding LSBs of the SFN where the UE transmitted PRACH, and the UE receives a transport block in a corresponding PDSCH within the window, the UE passes the transport block to higher layers. The higher layers indicate to the physical layer
- an uplink grant if the RAR message(s) is for fallbackRAR and a random access preamble identity (RAPID) associated with the PRACH transmission is identified, and the UE procedure continues as described in clauses 8.2, 8.3, and 8.4 when the UE detects a RAR UL grant, or
- transmission of a PUCCH with HARQ-ACK information having ACK value if the RAR message(s) is for successRAR, where
- a PUCCH resource for the transmission of the PUCCH is indicated by PUCCH resource indicator field of 4 bits in the successRAR from a PUCCH resource set that is provided by pucch-ResourceCommon
-
a slot for the PUCCH transmission is indicated by a HARQ Feedback Timing
Indicator field of 3 bits in the successRAR having a value 
from {1, 2, 3, 4,
5, 6, 7, 8} for 
,
from {7, 8, 12, 16, 20, 24, 28, 32} for 
,
from {13, 16, 24, 32, 40, 48, 56, 64} for 
and, with
reference to slots for PUCCH transmission having duration 
, the slot is
determined as 
, where 
is a
slot of the PDSCH reception, 
is as
defined for PUSCH transmission in Table 6.1.2.1.1-5 of [6, TS 38.214], 
is the
SCS configuration of the active UL BWP, and 
is
provided by Koffset in ServingCellConfigCommon; otherwise, if not
provided, 
- the UE does not expect the first symbol
of the PUCCH transmission to be after the last symbol of the PDSCH reception by
a time smaller than 
msec where 
is the PDSCH processing
time for UE processing capability 1 [6, TS 38.214]
--- Unchanged parts omitted ---
----- End of TP -----
Agreement
For NR operation with 480 kHz and/or 960 kHz SCS, scale the value of N for 120 kHz SCS by 4 and 8 for 480 kHz and 960 kHz SCS respectively, where N symbols are for PDSCH corresponding to SI-RNTI in Clause 5.1 of TS38.214.
· The following example change to 38.214 Section 5.1 can be recommended to the editor to use at the editor’s discretion
----- Start of TP
--- Unchanged parts omitted ---
In
a given scheduled cell, for any PDSCH corresponding to SI-RNTI, the UE is not
expected to decode a re-transmission of an earlier PDSCH with a starting symbol
less than N symbols after the last symbol of that PDSCH, where the value
of N depends on the PDSCH subcarrier spacing configuration m, with
N=13 for m=0, N=13 for m=1, N=20
for m=2, and N=24 for m=3, N=96 for m=5, and N=192 for m=6.
--- Unchanged parts omitted ---
----- End of TP -----
Agreement
For NR operation with 480 kHz and/or 960 kHz SCS, scale 14 symbols for SPS PDSCH cancelation in Clause 5.1 of TS38.214 by 4 and 8 for 480 kHz and 960 kHz SCS respectively.
----- Start of TP
--- Unchanged parts omitted ---
The UE is not expected to decode a PDSCH in a serving cell scheduled by a PDCCH with C-RNTI, CS-RNTI or MCS-C-RNTI and one or multiple PDSCH(s) required to be received according to this Clause in the same serving cell without a corresponding PDCCH transmission if the PDSCHs partially or fully overlap in time except if the PDCCH scheduling the PDSCH ends at least 14*2max{0,μ-3} symbols before the earliest starting symbol of the PDSCH(s) without the corresponding PDCCH transmission, where m and the symbol duration is based on the smallest numerology between the scheduling PDCCH and the PDSCH, in which case the UE shall decode the PDSCH scheduled by the PDCCH. When the PDCCH candidates are associated with a search space set configured with searchSpaceLinking, for the purpose of determining the PDCCH with C-RNTI, CS-RNTI or MCS-C-RNTI scheduling the PDSCH ends at least 14*2max{0,μ-3} symbols before the earliest starting symbol of the PDSCH(s) without the corresponding PDCCH transmission, the PDCCH candidate that ends later in time among the two configured PDCCH candidates is used.
--- Unchanged parts omitted ---
----- End of TP -----
Agreement
For NR operation with 480 kHz and/or 960 kHz SCS, scale 42 symbols for SRS precoding information update in Clause 6.1.1.2 of TS38.214 by 4 and 8 for 480 kHz and 960 kHz SCS respectively.
----- Start of TP
--- Unchanged parts omitted ---
For non-codebook based transmission, the UE can calculate the precoder used for the transmission of SRS based on measurement of an associated NZP CSI-RS resource. A UE can be configured with only one NZP CSI-RS resource for the SRS resource set with higher layer parameter usage in SRS-ResourceSet set to ‘nonCodebook’ if configured.
-
If aperiodic SRS resource set is configured, the associated
NZP-CSI-RS is indicated via SRS request field in DCI format 0_1 and 1_1, as
well as DCI format 0_2 (if SRS request field is present) and DCI format 1_2 (if
SRS request field is present), where AperiodicSRS-ResourceTrigger and AperiodicSRS-ResourceTriggerList (indicating the association between aperiodic SRS
triggering state(s) and SRS resource sets), triggered SRS resource(s) srs-ResourceSetId,
csi-RS (indicating the associated NZP-CSI-RS-ResourceId) are
higher layer configured in SRS-ResourceSet. The
SRS-ResourceSet(s) associated with the SRS request by DCI format 0_1 and
1_1 are defined by the entries of the higher layer parameter srs-ResourceSetToAddModList
and the SRS-ResourceSet(s) associated with the SRS request by DCI format
0_2 and 1_2 are defined by the entries of the higher layer parameter srs-ResourceSetToAddModListDCI-0-2.
A UE is not expected to update the SRS precoding information if the gap
from the last symbol of the reception of the aperiodic NZP-CSI-RS resource and
the first symbol of the aperiodic SRS transmission is less than 
OFDM symbols, where the SCS configuration μ is the smallest
SCS configuration between the NZP-CSI-RS resource and the SRS transmission.
--- Unchanged parts omitted ---
----- End of TP -----
R1-2200684 Discussion summary #1 of [107bis-e-R17-52-71GHz-05] Moderator (vivo)
Decision: As per email decision posted on Jan 25th,
Conclusion
DMRS bundling across multiple PUSCHs scheduled by a single DCI is not supported for NR operation in FR2-2 in Rel-17.
[107bis-e-R17-52-71GHz-06] – Seonwook (LGE)
Email discussion/approval on scheduling particularly w.r.t. multi-PDSCH/PUSCH with a single DCI, HARQ
- 1st check point: January 20
- Final check point: January 25
R1-2200569 Summary #1 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
From Jan 19th GTW session
Agreement
· In NR FR2-2, a UE supporting 32 maximum number of HARQ processes for 480/960 kHz SCS for DL (or for UL) shall support 32 as the maximum number of HARQ processes for 120 kHz SCS for DL (or UL), subject to UE capability.
Agreement
Decision: As per email decision posted on Jan 21st,
Conclusion
For multi-PDSCH or multi-PUSCH scheduling DCI, the following maximum value of a gap is not specified in Rel-17 and up to gNB scheduler.
Conclusion
HARQ process number configured for SPS PDSCH (or CG PUSCH) can be allocated to a PDSCH (or PUSCH) of multi-PDSCH (or multi-PUSCH) scheduling, as long as the timeline condition defined in Rel-15/16 is met.
Agreement
Agreement (RAN1#107-e)
For multi-PDSCH scheduling with a single DCI
· Introduce a new RRC parameter, e.g., enableTimeDomainHARQ-Bundling, to enable time domain bundling operation for type-1 HARQ-ACK codebook per serving cell.
o If the RRC parameter enables time domain bundling operation,
§ To determine the set of candidate PDSCH reception occasions,
· A row index is removed if at least one symbol of every PDSCH associated with the row index is configured as semi-static UL. (NOTE: This is similar to the case of slot aggregated PDSCH in Rel-16)
· Pruning procedure in Rel-16 is performed based on the last configured SLIV of each row index.
§ Logical AND operation is applied across all valid PDSCHs associated with a determined candidate PDSCH reception occasion, at least for 1-TB case.
§ FFS:
UE does not expect the last scheduled SLIV overlaps with a semi-static UL
symbol when parameter enableTimeDomainHARQ-Bundling is configured
Agreement
For multi-PDSCH scheduling with a single DCI and for type-2 HARQ-ACK codebook generation,
Decision: As per email decision posted on Jan 25th,
Conclusion
Conclusion
UE does not expect any of the received PDSCHs (including SPS PDSCH) and the resource for the HARQ-ACK transmission to lead to out-of-order scheduling, for any scheduling DCIs (including multi-PDSCH scheduling DCI).
Agreement
For a DCI that can schedule multiple PDSCHs or multiple PUSCHs,
· It is clarified that NDI/RV fields in the following previous agreements correspond to scheduled PDSCHs indicated by the TDRA information field.
|
Agreement: (RAN1#104-bis) For a DCI that can schedule multiple PDSCHs, · NDI for the 1st TB: This is signaled per PDSCH and applies to the first TB of each PDSCH · RV for the 1st TB: This is signaled per PDSCH, with 2 bits if only a single PDSCH is scheduled or 1 bit for each PDSCH otherwise and applies to the first TB of each PDSCH
Agreement: (RAN1#106bis-e) For a DCI that can schedule multiple PDSCHs, and if RRC parameter configures that two codeword transmission is enabled, · NDI for the 2nd TB: This is signalled per PDSCH and applies to the 2nd TB of each PDSCH · RV for the 2nd TB: This is signalled per PDSCH, with 2 bits if only a single PDSCH is scheduled or 1 bit for each PDSCH otherwise and applies to the 2nd TB of each PDSCH |
· Above clarification also applies to the DCI scheduling multiple PUSCHs, i.e., NDI/RV fields in the DCI correspond to scheduled PUSCHs indicated by the TDRA information field.
· The following example change to 38.214 Sections 5.1.3 and 6.1.4 can be recommended to the editor of 38.214 to use at the editor’s discretion
---------------------------Start of TP for TS 38.214 Clause 5.1.3 -----------------------------------------------
5.1.3 Modulation order, target code rate, redundancy version and transport block size determination
================ Unchanged Text Omitted =======================
When the UE is scheduled with multiple PDSCHs by a DCI, as described in clause 5.1.2.1, the bits of rv field and NDI field, respectively, in the DCI are one-to-one mapped to the scheduled PDSCH(s) indicated by the TDRA information field with the corresponding transport block(s) in the scheduled order, where the LSB bits of the rv field and NDI field, respectively, correspond to the last scheduled PDSCH indicated by the TDRA information field.
---------------------------------------------- End of TP --------------------------------------------------------------
---------------------------Start of TP for TS 38.214 Clause 6.1.4 -----------------------------------------------
6.1.4 Modulation order, redundancy version and transport block size determination
================ Unchanged Text Omitted =======================
When the UE is scheduled with multiple PUSCHs by a DCI, as described in clause 6.1.2.1, the bits of rv field and NDI field, respectively, in the DCI are one to one mapped to the scheduled PUSCH(s) indicated by the TDRA information field with the corresponding transport block(s) in the scheduled order where the LSB bits of the rv field and NDI field, respectively, correspond to the last scheduled PUSCH indicated by the TDRA information field.
---------------------------------------------- End of TP --------------------------------------------------------------
Conclusion
It is clarified that the absence or presence of CBGTI field in the following previous agreement is determined based on scheduled PUSCHs indicated by the TDRA information field (i.e. irrespective of whether this is a valid PUSCH).
|
Agreement: (RAN1#105-e) · At least for 120 kHz SCS, for a DCI that can schedule multiple PUSCHs and is configured with the TDRA table containing at least one row with multiple SLIVs, o If CBG-based (re)transmission is configured, CBGTI field is not present when more than one PUSCHs are scheduled, but is present when a single PUSCH is scheduled, as in Rel-16. |
Agreement
A UE validates, for scheduling activation or scheduling release, a DL SPS assignment PDCCH or a configured UL grant Type 2 PDCCH if the PDCCH indicates a TDRA row index including only one SLIV.
Agreement
For type-1
HARQ-ACK codebook, if 
, the UE determines a number of
HARQ-ACK information bits 
for obtaining a
transmission power for a PUCCH, as follows.
.
The TP below for TS38.213v17.0.0 is endorsed.
-------------------------------------------Start of TP#A1 for TS 38.213 Clause 9.1.2.1 -----------------------------------------------
If a UE is not provided ca-SlotOffset for any serving cell of PDSCH receptions and for the serving cell of corresponding PUCCH transmission with HARQ-ACK information
while
if 
or subslotLengthForPUCCH is provided for the
HARQ-ACK codebook
Set 
– index of a DL slot
overlapping with an UL slot
Set 
to a number of DL slots
overlapping with UL slot 
if subslotLengthForPUCCH
is provided for the HARQ-ACK codebook; otherwise, 
while 
……
if slot 
starts at a same time
as or after a slot for an active DL BWP change on serving cell 
or an active UL BWP
change on the PCell and slot 
is before the slot for
the active DL BWP change on serving cell or the active UL BWP
change on the PCell, or
subslotLengthForPUCCH is provided for the
HARQ-ACK codebook and slot
overlaps with UL slot 
, 
, where 
is a DL slot with a
smallest index among DL slots overlapping with UL slot ,
;
else
while 
if the UE is not
provided enableTimeDomainHARQ-Bundling and is provided tdd-UL-DL-ConfigurationCommon, or tdd-UL-DL-ConfigurationDedicated and, for each
slot from
slot 
to slot , at least
one symbol of the PDSCH time resource derived by row 
is configured
as UL where 
is the k-th
slot timing value in set 
, where is a DL slot with a
smallest index among DL slots overlapping with UL slot , or subslotLengthForPUCCH is provided for the
HARQ-ACK codebook and the end of the PDSCH time resource for row is not within any UL
slot 
, 
or if
HARQ-ACK information for PDSCH time resource derived by row in slot 
cannot be
provided in slot 
;
elseif the UE is provided enableTimeDomainHARQ-Bundling
and tdd-UL-DL-ConfigurationCommon, or tdd-UL-DL-ConfigurationDedicated and, for each slot
, at least
one symbol of eachthe PDSCH
time resource derived by row of set 
is configured
as UL, where 
= 0,1,…,
, 
, and 
is the
cardinality of 
.
;
;
else
;
end if
end while
……
;
end if
end while
end if
;
end while
else
……
end if
-------------------------------------------End of TP#A1 for TS 38.213 Clause 9.1.2.1 -----------------------------------------------
The TP below for TS38.214v17.0.0 is endorsed.
--------------------------------------------Start TP#C1 for TS 38.214 Clause 5.1.2.1.1 -----------------------------------------------
Table 5.1.2.1.1-1: Applicable PDSCH time domain resource allocation for DCI formats 1_0, 1_1, 4_0, 4_1 and 4_2
|
MCCH-RNTI |
Type 0/0B common for broadcast |
1 |
No |
- |
No |
- |
Default A |
|
2 |
No |
- |
No |
- |
Default B |
||
|
3 |
No |
- |
No |
- |
Default C |
||
|
1,2,3 |
Yes |
- |
No |
- |
pdsch-TimeDomainAllocationList provided in PDSCH-ConfigCommon |
||
|
1,2,3 |
No/Yes |
- |
Yes |
- |
pdsch-TimeDomainAllocationList provided in pdsch-Config-MCCH |
||
|
G-RNTI for broadcast |
Type 0/0B common for broadcast |
1 |
No |
- |
No |
- |
Default A |
|
2 |
No |
- |
No |
- |
Default B |
||
|
3 |
No |
- |
No |
- |
Default C |
||
|
1,2,3 |
Yes |
- |
No |
- |
pdsch-TimeDomainAllocationList provided in PDSCH-ConfigCommon |
||
|
1,2,3 |
No/Yes |
- |
Yes |
- |
TimeDomainAllocationList provided in PDSCH-Config-MCCH |
||
|
1,2,3 |
No/Yes |
- |
Yes |
- |
pdsch-TimeDomainAllocationList provided in PDSCH-Config-MTCH |
||
|
C-RNTI, MCS-C-RNTI, CS-RNTI |
Any common search space associated with CORESET 0 |
1, 2, 3 |
No |
- |
- |
- |
Default A |
|
1, 2, 3 |
Yes |
- |
- |
- |
pdsch-TimeDomainAllocationList provided in PDSCH-ConfigCommon |
||
|
C-RNTI, MCS-C-RNTI, CS-RNTI |
Any common search space not associated with CORESET 0
UE specific search space |
1,2,3 |
No |
No |
- |
- |
Default A |
|
1,2,3 |
Yes |
No |
- |
- |
pdsch-TimeDomainAllocationList provided in PDSCH-ConfigCommon |
||
|
1,2,3 |
No/Yes |
Yes |
- |
- |
pdsch-TimeDomainAllocationList provided in PDSCH-Config |
||
|
1,2,3 |
No/Yes |
- |
- |
Yes |
pdsch-TimeDomainAllocationListForMultiPDSCH-r17 provided in PDSCH-Config (Note 2) |
||
|
G-RNTI, G-CS-RNTI (for multicast) |
Type-X common search space for multiast |
1,2,3 |
No |
- |
No |
- |
Default A |
|
1,2,3 |
Yes |
- |
No |
- |
pdsch-TimeDomainAllocationList provided in PDSCH-ConfigCommon (Note 1) |
||
|
1,2,3 |
No/Yes |
- |
Yes |
- |
pdsch-TimeDomainAllocationList provided in pdsch-Config-Multicast (Note 1) |
||
|
Note 1: For a UE that supports multicast, the same TDRA table applies to all G-RNTIs (configured for multicast) if configured on a given serving cell. Note 2: If pdsch-TimeDomainAllocationListForMultiPDSCH-r17 is provided, it is applicable to DCI format 1_1 only. |
|||||||
--------------------------------------------End of TP#C1 for TS 38.214 Clause 5.1.2.1.1 -----------------------------------------------
The TP below for TS38.213v17.0.0 is endorsed.
--------------------------------------------Start of TP#F for TS 38.213 Clause 9.1.2.1 ------------------------------------------------
9.1.2.1 Type-1 HARQ-ACK codebook in physical uplink control channel
=============================== Unchanged Text Omitted ===================================
while
if the UE is
not provided enableTimeDomainHARQ-Bundling and is provided tdd-UL-DL-ConfigurationCommon, or tdd-UL-DL-ConfigurationDedicated and, for each
slot from
slot to slot 
, at least
one symbol of the PDSCH time resource derived by row 
is configured
as UL where 
is the k-th
slot timing value in set , where is a DL slot with a
smallest index among DL slots overlapping with UL slot , or subslotLengthForPUCCH is provided for the
HARQ-ACK codebook and the end of the PDSCH time resource for row is not within any UL
slot , or if pdsch-TimeDomainAllocationListForMultiPDSCH-r17
is
provided and HARQ-ACK information for PDSCH time resource
derived by row in slot cannot be
provided in slot
;
elseif the UE is
provided enableTimeDomainHARQ-Bundling and tdd-UL-DL-ConfigurationCommon, or tdd-UL-DL-ConfigurationDedicated and, for each slot
, at least
one symbol of the PDSCH time resource derived by row of set is configured
as UL, where = 0,1,…,, , and is the
cardinality of .
;
;
else
;
end if
end while
--------------------------------------------End of TP#F for TS 38.213 Clause 9.1.2.1 ------------------------------------------------
The TP below for TS38.214v17.0.0 is endorsed.
----------------------------------------------Start of TP#G for TS 38.214 Clause 6.1 --------------------------------------------------
6.1 UE procedure for transmitting the physical uplink shared channel
=============================== Unchanged Text Omitted ===================================
For uplink, 16 HARQ processes per cell are supported by the UE, or subject to UE capability, a maximum of 32 HARQ processes per cell for the cases of = 5 or = 6. The number of processes the UE may assume will at most be used for the uplink is configured to the UE for each cell separately by higher layer parameter nrofHARQ-ProcessesForPUSCH, and when no configuration is provided the UE may assume a default number of 16 processes.
------------------------------------------------------------End of TP#G----------------------------------------------------------------
Final summary in R1-2200744.
R1-2200026 On Issues in Channel Access for Beyond 52.6 GHz FUTUREWEI
R1-2200049 Remaining issues of channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
R1-2200065 Remaining issues for channel access mechanisms InterDigital, Inc.
R1-2200079 Remaining issues on channel access mechanism for NR operation from 52.6GHz to 71 GHz vivo
R1-2200146 Remaining issues on channel access mechanism for up to 71GHz operation CATT
R1-2200177 Remaining issues on channel access mechanism for 60 GHz unlicensed spectrum Sony
R1-2200188 Remaining issues on Channel access mechanism Nokia, Nokia Shanghai Bell
R1-2200197 Maintenance on channel access mechanism for NR from 52.6 GHz to 71 GHz Samsung
R1-2200231 Remaining issues on Channel access mechanism for NR in FR2-2 NTT DOCOMO, INC.
R1-2200264 Remaining issues on the channel access for 52.6 to 71GHz ZTE, Sanechips
R1-2200293 Channel access mechanism for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2200329 Discussion on remaining issue for channel access mechanism OPPO
R1-2200371 Discussion on channel access mechanism for extending NR up to 71 GHz Intel Corporation
R1-2200406 Channel Access Mechanisms Ericsson
R1-2200413 Remaining issues on channel access mechanisms Apple
R1-2200462 Remaining issues on channel access mechanism for NR on 52.6-71 GHz xiaomi
R1-2200514 Remaining issues on channel access mechanism supporting NR from 52.6 to 71 GHz NEC
R1-2200539 On the channel access mechanisms for 52.6-71 GHz NR operation MediaTek Inc.
R1-2200559 Remaining issues of channel access mechanism for above 52.6GHz Transsion Holdings
R1-2200570 Channel access mechanism to support NR above 52.6 GHz LG Electronics
R1-2200621 Remaining issue on channel access scheme for above 52.6GHz ASUSTeK
R1-2200633 Remaining issue on channel access for NR from 52.6GHz to 71GHz WILUS Inc.
R1-2200662 Discussion on sharing of directional channel occupancy Panasonic
R1-2200673 Remaining issues on channel access for NR from 52.6 GHz to 71GHz Lenovo, Motorola Mobility
[107bis-e-R17-52-71GHz-07] – Jing (Qualcomm)
Email discussion/approval on channel access mechanism
- 1st check point: January 20
- Final check point: January 25
R1-2200703 FL summary#1 for channel access for 52.6 to 71 GHz band Moderator (Qualcomm)
From Jan 19th GTW session
Agreement
Type A multi-channel channel access is supported.
· FFS whether legacy mechanisms such as type A1 is supported
Agreement
Introduce new parameter in RMTC-Config for L3-RSSI to indicate measurement bandwidth.
· The value range for the configured measurement bandwidth should include the maximum and the minimum channel bandwidth and the intermediate channel bandwidths defined by RAN4.
Decision: As per email decision posted on Jan 23rd,
Agreement
· For DL to UL COT sharing, when the UL BWP is wider than the DL BWP, COT sharing based transmission at the UE is only supported if the transmission is within the bandwidth of DL BWP
· For UL to DL COT sharing, when the DL BWP is wider than the UL BWP, COT sharing based transmission at the gNB is only supported if the transmission is within the bandwidth of UL BWP
Conclusion
After the UE reports it LBT capability, UE does not expect the gNB to schedule UL transmission with LBT type it does not support
Agreement
· Clarify that the 5us observation slot is at the end of the 8us deferral period.
o
Note: The 5us observation slot is the
sensing slot 
in 37.213
· The TP below for TS 37.213 v17.0.0 is endorsed
*** <Beginning of TP for TS 37.213 v17.0.0> ***
4.4.1 Type 1 channel access procedures
This clause describes channel access procedures to be performed by a gNB/UE where the time duration spanned by the sensing slots that are sensed to be idle before a transmission(s) is random based on a fixed contention window size. The clause is applicable to any transmission initiating a channel occupancy by the gNB/UE.
The
gNB/UE may transmit a transmission after first sensing the channel to be idle
during the sensing slot duration of a defer duration 
and after the
counter 
is zero in step 4.
The counter is adjusted by
sensing the channel for additional sensing slot duration(s) according to the
steps below:
1) set 
, where 
is a random number
uniformly distributed between 0 and 
, and go to step 4;
2) if 
and the gNB/UE
chooses to decrement the counter, set 
;
3) sense the channel for an additional sensing slot duration, and if the channel is idle for the additional sensing slot duration, go to step 4; else, go to step 5;
4) if 
, stop; else, go to step
2.
5) sense the channel until either it is
detected busy within an additional defer duration or it is detected
to be idle for the sensing slot of the additional defer duration ;
6) if the channel is sensed to be idle during
the sensing slot duration of the additional defer duration , go to step 4; else, go
to step 5;
In
the above procedures, is the contention
window and 
.
The
defer duration is 
and includes a sensing
slot duration 
at the end of the 8 μs for performing as least a
single measurement to determine whether the channel is idle.
A
gNB/UE shall not transmit on a channel for a Channel Occupancy Time that
exceeds 
.
4.4.2 Type 2 channel access procedures
This clause describes channel access procedures to be performed by a gNB/UE where the time duration spanned by sensing slots that are sensed to be idle before a DL/UL transmission(s) is deterministic.
A
gNB/UE may transmit a transmission(s) on a channel immediately after which includes ends with
a sensing slot with of a duration 
where the channel
is sensed to be idle.
*** <End of TP for TS 37.213 v17.0.0> ***
Agreement
In Rel-17, the same ED threshold determination mechanism is used for UL to DL COT sharing and for UL transmission without COT sharing with UE as initiating device.
· FFS: Spec impact for UL to DL COT sharing mechanism.
R1-2200753 FL summary#2 for channel access for 52.6 to 71 GHz band Moderator (Qualcomm)
Decision: As per email decision posted on Jan 25th,
Agreement
On measDurationSymbols and reference SCS/CP for L3-RSSI
· On measDurationSymbols-r16 with ref-SCS-CP-r16=120KHz, extend measDurationSymbols-r16 to {1,14,28,42,70,140}
· On measDurationSymbols-r16 with ref-SCS-CP-r16=480KHz (if supported), extend measDurationSymbols-r16 to {1,14,28,42,70,140, 560}
· On measDurationSymbols-r16 with ref-SCS-CP-r16=960KHz (if supported), extend measDurationSymbols-r16 to {1,14,28,42,70,140, 560,1120}
Final summary in R1-2200803.
R1-2200265 Discussion on RRC parameters for 52.6 to 71GHz ZTE, Sanechips
R1-2200407 NR channelization for the 57 – 71 GHz band Ericsson
R1-2200652 Discussion on the channel raster and sync raster in FR2-2 Huawei, HiSilicon
R1-2202783 Session notes for 8.2 (Maintenance on Supporting NR from 52.6GHz to 71 GHz) Ad-Hoc Chair (Huawei)
[108-e-R17-RRC-52-71GHz] – Jing (Qualcomm)
Email discussion on Rel-17 RRC parameters for supporting NR from 52.6 GHz to 71 GHz
- 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
R1-2202687 Email discussion summary for RRC parameters for NR beyond 52.6GHz Moderator (Qualcomm Incorporated)
Document is noted. For consolidation under 8 in [108-e-R17-RRC].
Including SSB, initial BWP, PRACH, etc.
R1-2200952 Remaining issue of initial access signals and channels for 52-71GHz spectrum Huawei, HiSilicon
R1-2200987 On the remaining issues in initial access for Beyond 52.6GHz FUTUREWEI
R1-2201032 Remaining issues for initial access operation in 52.6-71GHz InterDigital, Inc.
R1-2201085 Remaining issues on initial access aspects for NR operation from 52.6GHz to 71GHz vivo
R1-2201265 Discussion on remaining issue for initial access aspects OPPO
R1-2201351 Remaining issues on Initial access aspects for up to 71GHz operation CATT
R1-2201388 Remaining issues on the initial access aspects for 52.6 to 71GHz ZTE, Sanechips
R1-2201470 Remaining issues on initial access aspects for NR in FR2-2 NTT DOCOMO, INC.
R1-2201541 Discussion on initial access aspects for NR for 60GHz Spreadtrum Communications
R1-2201596 Maintenance on initial access aspects for NR from 52.6 GHz to 71 GHz Panasonic Corporation
R1-2201662 Initial access aspects Nokia, Nokia Shanghai Bell
R1-2201688 Discussion on initial access aspects for extending NR up to 71 GHz Intel Corporation
R1-2201734 Initial Access Aspects Ericsson
R1-2201764 On remaining issues for initial access Apple
R1-2201901 Remaining issues on initial access aspects supporting NR from 52.6 to 71 GHz NEC
R1-2202004 Maintenance on initial access aspects for NR from 52.6 GHz to 71 GHz Samsung
R1-2202129 Initial access aspects for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2202189 Initial access aspects Sharp
R1-2202335 Initial access aspects to support NR above 52.6 GHz LG Electronics
R1-2202501 Issue Summary for initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
[108-e-NR-52-71GHz-01] – Daewon (Intel)
Email discussion for maintenance on initial access aspects
- 1st check point: February 25
- Final check point: March 3
R1-2202502 Summary #1 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
From Feb 22nd GTW session
Working assumption
· Use 1 bit for Q in MIB
o SubcarrierSpacingCommon field will be used to convey value of {32, 64} for operation with shared spectrum channel access
o Note that this is revising the working assumption made in RAN1#107-e on “use 2 bits for Q, {SubcarrierSpacingCommon, spare bit in MIB}”
Decision: As per email decision posted on Feb 24th,
Conclusion
Update the ssb-PositionQCL in RRC to {32, 64} values.
· For reference, the following are list of RRC IEs that references ssb-PositionQCL in release 16.
o SIB2:: ssb-PositionQCL-Common-r16
o SIB3:: ssb-PositionQCL-r16
o SIB4:: ssb-PositionQCL-Common-r16
o SIB4:: ssb-PositionQCL-r16
o MeasObjectNR:: ssb-PositionQCL-Common-r16
o MeasObjectNR:: ssb-PositionQCL-r16
o ServingCellConfigCommon:: ssb-PositionQCL-r16
R1-2202503 Summary #2 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
Decision: As per email decision posted on Feb 26th,
Agreement
· Text Proposal #1-3 (for 38.213, Section 4.1) in section 3 of R1-2202503 is endorsed.
Conclusion
· For operation with shared spectrum channel access, support default DBTW length of 5ms if discoveryBurstWindowLength is not provided in FR2-2.
· No change to specification is needed
Working Assumption
· The following table is used for set of resource blocks and slot symbols of CORESET for Type0-PDCCH search space set when {SS/PBCH block, PDCCH} SCS is {120, 120}, {480, 480}, and {960, 960} kHz for FR2-2.
o FFS: whether/how to define X, if defined, candidate values {56, 76}
· Text Proposal #4-2D (for 38.213, Section 13) in section 3 of R1-2202503 is endorsed
· Note: this working assumption can be revisited once RAN4 finalizes the further details of the channelization.
|
Index |
SS/PBCH block and CORESET multiplexing pattern |
Number of RBs |
Number of Symbols |
Offset (RBs) |
|
0 |
1 |
24 |
2 |
0 |
|
1 |
1 |
24 |
2 |
4 |
|
2 |
1 |
48 |
1 |
0 |
|
3 |
1 |
48 |
1 |
14 |
|
4 |
1 |
48 |
1 |
28 |
|
5 |
1 |
48 |
2 |
0 |
|
6 |
1 |
48 |
2 |
14 |
|
7 |
1 |
48 |
2 |
28 |
|
8 |
1 |
96 |
1 |
0 |
|
9 |
1 |
96 |
1 |
X |
|
10 |
1 |
96 |
2 |
0 |
|
11 |
1 |
96 |
2 |
X |
|
12 |
3 |
24 |
2 |
-20 if -21 if |
|
13 |
3 |
24 |
2 |
24 |
|
14 |
3 |
48 |
2 |
-20 if -21 if |
|
15 |
3 |
48 |
2 |
48 |
Agreements
· Text Proposal #5-1A (for 38.215, Section 5.1.3) in section 3 of R1-2202503 is endorsed.
· Text Proposal #7-2B (for 38.211, Section 5.3.2) in section 3 of R1-2202503 is endorsed.
· Text Proposal #7-3B (for 38.211, Section 7.4.3.1) in section 3 of R1-2202503 is endorsed.
· Text Proposal #7-4B (for 38.213, Section 13) in section 3 of R1-2202503 is endorsed.
Final summary in R1-2202683.
R1-2200953 Remaining issues of PDCCH monitoring enhancement for 52-71GHz spectrum Huawei, HiSilicon
R1-2200988 On the remaining issues in multi-slot PDCCH monitoring for Beyond 52.6GHz FUTUREWEI
R1-2201033 Remaining issues for PDCCH monitoring enhancements InterDigital, Inc.
R1-2201086 Remaining issues on PDCCH monitoring enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2201266 Discussion on remaining issue for PDCCH monitoring enhancement OPPO
R1-2201352 Remaining issues on PDCCH monitoring enhancements for up to 71GHz operation CATT
R1-2201389 Remaining issues on the PDCCH monitoring enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2201471 Remaining issues on PDCCH monitoring enhancements for NR in FR2-2 NTT DOCOMO, INC.
R1-2201542 Remaining issues on the PDCCH monitoring enhancements for 52.6 to 71GHz Spreadtrum Communications
R1-2201593 Remaining Issues on PDCCH monitoring Enhancements in FR2-2 TCL Communication
R1-2201663 PDCCH monitoring enhancements Nokia, Nokia Shanghai Bell
R1-2201689 Discussion on PDCCH monitoring enhancements for extending NR up to 71 GHz Intel Corporation
R1-2201735 PDCCH Monitoring Enhancements Ericsson
R1-2201765 On remaining issues for PDCCH Monitoring Apple
R1-2201899 Remaining issues on PDCCH enhancement for NR operation from 52.6GHz to 71GHz NEC
R1-2201914 Remaining issues on PDCCH monitoring enhancement for NR 52.6-71GHz Xiaomi
R1-2202005 Maintenance on PDCCH monitoring enhancements for NR from 52.6 GHz to 71 GHz Samsung
R1-2202072 Remaining discussion on PDCCH monitoring enhancement for 52.6-71 GHz NR operation MediaTek Inc.
R1-2202130 PDCCH monitoring enhancements for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2202190 PDCCH monitoring enhancements Sharp
R1-2202234 Remaining issues of PDCCH monitoring enhancements for above 52.6GHz Transsion Holdings
R1-2202273 PDCCH monitoring for NR operation from 52.6 to 71 GHz Panasonic
R1-2202336 PDCCH monitoring enhancements to support NR above 52.6 GHz LG Electronics
R1-2202409 Remaining issues on PDCCH for NR from 52.6 GHz to 71GHz Lenovo
[108-e-NR-52-71GHz-02] – Alex (Lenovo)
Email discussion for maintenance on PDCCH monitoring enhancements
- 1st check point: February 25
- Final check point: March 3
R1-2202412 Feature lead summary #1 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
R1-2202413 Feature lead summary #2 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
Decision: As per email decision posted on Feb 25th,
Agreement
The following TP for Clause 13 of TS38.213v17.0.0 is endorsed
---- Start of TP ----
13 UE procedure for monitoring Type0-PDCCH CSS sets
--- unchanged text omitted ---
For operation without
shared spectrum channel access and for the SS/PBCH block and CORESET
multiplexing pattern 1, a UE monitors PDCCH in the Type0-PDCCH CSS set over two
slots 
.
--- unchanged text omitted ---
---- End of TP ----
Conclusion
for 480 kHz SCS is not
supported for multi-slot monitoring.
Agreement
For group common DCI formats, only the following periodicities are applicable:
|
|
120 kHz (same as FR2) |
480 kHz |
960 kHz |
|
DCI format 2_0 |
sl1, sl2, sl4, sl5, sl8, sl10, sl16, sl20 |
sl4, sl8, sl16, sl20, sl32, sl40, sl64, sl80 |
sl8, sl16, sl32, sl40, sl64, sl80, sl128, sl160 |
|
DCI format 2_1 |
sl1, sl2, sl4 |
sl4, sl8, sl16 |
sl8, sl16, sl32 |
|
DCI format 2_4 |
sl1, sl2, sl4, sl5, sl8, sl10 |
sl4, sl8, sl16, sl20, sl32, sl40 |
sl8, sl16, sl32, sl40, sl64, sl80 |
|
Highlighted: New periodicity values to be introduced for 480/960 kHz SCSs |
|||
Agreement
In unit of slots, the supported values for searchSpaceSwitchTimer-r17 and PDCCHSkippingDuration for 480 kHz and 960 kHz are respectively 4x and 8x of their supported values for 120 kHz.
Decision: As per email decision posted on Feb 26th,
Agreement
For multi-slot PDCCH monitoring for 480/960 kHz SCSs, the boundary of SSSG switching is always aligned with the boundary of a slot group.
Agreement
For operation with shared spectrum channel access, define 160/640/1280 slots as the maximum value of searchSpaceSwitchTimer for 120/480/960 kHz SCS, respectively.
Decision: As per email decision posted on Mar 1st,
· A UE does not expect to be configured with Rel-16 SSSG switching parameters (such as searchSpaceSwitchTimer and SearchSpaceSwitchTrigger) and Rel-17 SSSG switching parameters (such as searchSpaceSwitchTimer-r17 and searchSpaceGroupIdList-r17) per cell simultaneously.
· Note: This behaviour is reflected in a RAN2 power saving CR for 38.331 (R2-2203058) and may therefore not require additional specification text.
R1-2202712 Feature lead summary #3 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
From Mar 1st GTW session
Working assumption
For the purpose of BD/CCE budget
determination for PDCCH monitoring for 
, if more than one of the PDCCH monitoring 
capability combinations supported by a UE comply with all
configured search space sets, then the UE selects Xs and thereby 
and 
values corresponding to the complying combination with the largest and values.
Note1: This determination of Xs may be independent of the size of monitoringSlotsWithinSlotGroup discussed in the context of search space configuration
R1-2202713 Feature lead summary #4 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
From Mar 2nd GTW session
Agreement
Revise the RAN1#107bis-e agreement/working assumption:
For search space set configuration of multi-slot PDCCH monitoring:
} slots§
The
configured duration is restricted to be an integer multiple of XsL slots at least for Group (1) SSs
§ The maximum duration is one less slot group of L slots than the configured periodicity
slots should be
no larger than 
according to at
least one of the 
supported by a
UE
slots should be
no larger than M, where M is FFS
Decision: As per email decision posted on Mar 3rd,
Agreement
· The following TP for TS 38.213 Clause 10 is endorsed:
|
If a UE is provided monitoringCapabilityConfig for an active DL BWP of a serving cell, the UE obtains an indication to monitor PDCCH on the active DL BWP of the serving cell for a maximum number of PDCCH candidates and non-overlapping CCEs - per slot, as in Tables 10.1-2 and 10.1-3, if monitoringCapabilityConfig = r15monitoringcapability, or - per span, as in Tables 10.1-2A and 10.1-3A, if monitoringCapabilityConfig = r16monitoringcapability -
per group of If the UE is not provided monitoringCapabilityConfig for μ ∈ {0,1,2,3}, the UE monitors PDCCH on the active DL BWP of a serving cell for a maximum number of PDCCH candidates and non-overlapping CCEs per slot. If the UE is not provided monitoringCapabilityConfig
for μ ∈ {5,6}, the UE monitors PDCCH on the active DL BWP of a serving
cell for a maximum number of PDCCH candidates and non-overlapping CCEs per
group of Before the UE is provided dedicated higher layer parameters, the UE is not expected to monitor PDCCH with μ = 6. |
Note: Spec editor may place the sentence "Before the UE is provided dedicated higher layer parameters, the UE is not expected to monitor PDCCH with μ = 6." in a more appropriate location.
· Capture the following description in the RRC parameter spreadsheet to RAN2, with monitoringCapabilityConfig being an optional field:
o monitoringCapabilityConfig
Configures either Rel-15 PDCCH monitoring capability or Rel-16 PDCCH monitoring capability or Rel-17 PDCCH monitoring capability for PDCCH monitoring on a serving cell (see TS 38.213 [13], clause 10.1). Value r15monitoringcapablity enables the Rel-15 monitoring capability, and value r16monitoringcapablity enables the Rel-16 PDCCH monitoring capability. Value r17monitoringcapablity enables the Rel-17 PDCCH monitoring capability. When present, the network configures this field with r17monitoringcapablity for a BWP with SCS configured as 480 or 960 kHz SCS.
Agreement
Confirm the working assumption: BD/CCE budget of 960 kHz for (Xs, Ys) = (4,2), (4,1) is half that of X=8 (i.e. 10/16).
Agreement
·
For serving cells configured with 480 or 960
kHz SCS, the serving cells with the same SCS and 
value
are grouped together to determine a total BD/CCE budget for that group and the
per-cell BD/CCE budget within the group.
· Support UE capability signaling for 4 additional cases :
· For the case with Rel-15 monitoring capability, Rel-16 monitoring capability and Rel-17 monitoring capability on different serving cells (case 7) or any combination of 2 of the capabilities (i.e. case 5, and case 6), the UE will report one or more combination of (pdcch-BlindDetectionCA-R15, pdcch-BlindDetectionCA-R16, pdcch-BlindDetectionCA-R17) as UE capability. If UE reports more than one combination of (pdcch-BlindDetectionCA-R15, pdcch-BlindDetectionCA-R16, pdcch-BlindDetectionCA-R17), as in Rel-16, the gNB configures which combination for the UE to use for scaling PDCCH monitoring capability if the number of CCs configured is larger than the reported capability.
· FFS: Extension to NR-DC scenario
R1-2200954 Remaining issues of PUCCH enhancement for 52-71GHz spectrum Huawei, HiSilicon
R1-2201034 Remaining issues for enhanced PUCCH formats 0/1/4 InterDigital, Inc.
R1-2201267 Discussion on remaining issue for enhancements for PUCCH format 0/1/4 OPPO
R1-2201390 Remaining issues on the PUCCH enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2201736 PUCCH enhancements Ericsson
[108-e-NR-52-71GHz-03] – Steve (Ericsson)
Email discussion for maintenance on PUCCH formats 0/1/4 enhancements
- 1st check point: February 25
- Final check point: March 3
R1-2201737 FL Summary for Enhancements for PUCCH formats 0/1/4 Ericsson
Decision: As per email decision posted on Feb 25th,
Agreement
· Text Proposal #2a (for 38.212, Section 6.3.1.6) in section 2 of R1-2201737 is endorsed.
· Text Proposal #3-1 (for 38.211, Section 6.3.2.4.2) in section 3.1 of R1-2201737 is endorsed.
· Text Proposal #3-2 (for 38.213, Section 9.2.1) in section 3.2 of R1-2201737 is endorsed.
Including timing associated with beam-based operation.
R1-2200955 Remaining issues of beam management enhancement for 52-71GHz spectrum Huawei, HiSilicon
R1-2200989 Remaining issues in Beam Management for Beyond 52.6GHz FUTUREWEI
R1-2201035 Remaining issues for beam management for new SCSs InterDigital, Inc.
R1-2201087 Remaining issues on beam management for new SCSs for NR operation from 52.6GHz to 71GHz vivo
R1-2201268 Discussion on remaining issue for beam management for new SCSs OPPO
R1-2201353 Remaining issues on beam management for new SCSs for up to 71GHz operation CATT
R1-2201391 Remaining issues on the beam management for 52.6 to 71GHz ZTE, Sanechips
R1-2201472 Remaining issues on Beam based operation for new SCSs for NR in FR2-2 NTT DOCOMO, INC.
R1-2201577 Remaining issues on beam management enhancement for NR Beyond 52.6GHz Sony
R1-2201664 Beam Management Aspects Nokia, Nokia Shanghai Bell
R1-2201690 Discussion on Beam management aspects for extending NR up to 71 GHz Intel Corporation
R1-2201738 Beam Management for New SCSs Ericsson
R1-2201766 Beam Management for New SCSs Apple
R1-2201942 Maintenance on beam management for new SCSs Xiaomi
R1-2202006 Maintenance on beam management for new SCSs for NR from 52.6 GHz to 71 GHz Samsung
R1-2202073 Remaining discussion on beam management for 52.6-71 GHz NR operation MediaTek Inc.
R1-2202131 Beam management for new SCS Qualcomm Incorporated
R1-2202337 Enhancements for beam management to support NR above 52.6 GHz LG Electronics
[108-e-NR-52-71GHz-04] – Youngwoo (InterDigital)
Email discussion for maintenance on beam management for new SCSs
- 1st check point: February 25
- Final check point: March 3
R1-2201036 Discussion Summary #1 for Beam Management for new SCSs Moderator (InterDigital, Inc.)
From Mar 2nd GTW session
Agreement
TP#1 below is endorsed for TS 38.214
· RAN1 continues discussion to down-select between the following Alt1 and Alt2.
o Alt1) The applied TCI states can be updated using unified TCI framework within the span of multi-PDSCH
o Alt2) The applied TCI states cannot be updated using unified TCI framework within the span of multi-PDSCH
o Note: coordination with Rel-17 MIMO WI is allowed as necessary
TP#1
|
5.1.5 Antenna ports quasi co-location *** Unchanged text omitted *** When the UE is configured with a single slot PDSCH, the indicated TCI state should be based on the activated TCI states in the slot with the scheduled PDSCH. When the UE is configured with a multi-slot PDSCH or the UE is configured with higher layer parameter [pdsch-TimeDomainAllocationListForMultiPDSCH-r17], the indicated TCI state should be based on the activated TCI states in the first slot with the scheduled PDSCH(s), and UE shall expect the activated TCI states are the same across the slots with the scheduled PDSCH(s). When the UE is configured with CORESET associated with a search space set for cross-carrier scheduling and the UE is not configured with enableDefaultBeamForCCS, the UE expects tci-PresentInDCI is set as 'enabled' or tci-PresentDCI-1-2 is configured for the CORESET, and if one or more of the TCI states configured for the serving cell scheduled by the search space set contains qcl-Type set to 'typeD', the UE expects the time offset between the reception of the detected PDCCH in the search space set and a corresponding PDSCH is larger than or equal to the threshold timeDurationForQCL. *** Unchanged text omitted *** |
Final summary in R1-2202875.
Including defining maximum bandwidth for new SCSs, time line related aspects adapted to each of the new numerologies 480kHz and 960kHz, reference signals, scheduling particularly w.r.t. multi-PDSCH/PUSCH with a single DCI, HARQ, etc.
R1-2202490 Remaining issues of PDSCH/PUSCH enhancement for 52-71GHz spectrum Huawei, HiSilicon (rev of R1-2200956)
R1-2200990 Remaining issues in PDSCH/PUSCH enhancements for Beyond 52.6GHz FUTUREWEI
R1-2201037 Remaining issues for PDSCH/PUSCH enhancements to supporting 52.6-71 GHz band in NR InterDigital, Inc.
R1-2201088 Remaining issues on PDSCH/PUSCH enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2201269 Discussion on remaining issue for PDSCH/PUSCH enhancements OPPO
R1-2201354 Remaining issues on PDSCH/PUSCH enhancements for up to 71GHz operation CATT
R1-2201392 Remaining issues on the data channel enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2201433 Discussion on PDSCH/PUSCH enhancements for NR 52.6-71 GHz Panasonic Corporation
R1-2201436 Remaining issues of multi-PDSCH scheduling via a single DCI Fujitsu
R1-2201473 Remaining issues on PDSCH/PUSCH enhancements for NR in FR2-2 NTT DOCOMO, INC.
R1-2201665 PDSCH/PUSCH enhancements Nokia, Nokia Shanghai Bell
R1-2201691 Discussion on PDSCH/PUSCH enhancements for extending NR up to 71 GHz Intel Corporation
R1-2201739 PDSCH-PUSCH Enhancements Ericsson
R1-2201767 On remaining issues for PDSCH PUSCH Enhancements Apple
R1-2201900 Remaining issues on PDSCH enhancement for NR operation from 52.6GHz to 71GHz NEC
R1-2201915 Remaining issues on PDSCH and PUSCH enhancements for NR 52.6-71GHz Xiaomi
R1-2202007 Maintenance on PDSCH/PUSCH enhancements for NR from 52.6 GHz to 71 GHz Samsung
R1-2202074 Remaining discussion on multi-PDSCH scheduling design for 52.6-71 GHz NR operation MediaTek Inc.
R1-2202132 PDSCH/PUSCH enhancements for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2202283 Discussion on multi-PUSCH scheduling ASUSTeK
R1-2202338 PDSCH/PUSCH enhancements to support NR above 52.6 GHz LG Electronics
[108-e-NR-52-71GHz-05] – Huaming (vivo)
Email discussion for maintenance on timeline related aspects adapted to each of the new numerologies 480kHz and 960kHz
- 1st check point: February 25
- Final check point: March 3
R1-2202560 Discussion summary #1 of [108-e-NR-52-71GHz-05] Moderator (vivo)
Decision: As per email decision posted on Feb 25th,
Agreement
Support the following values for cg-minDFI-Delay
· SCS 120 kHz: 7, m*14,
· SCS 480 kHz: 7*4, m*14*4,
· SCS 960 kHz: 7*8, m*14*8,
where m = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32}
[108-e-NR-52-71GHz-06] – Seonwook (LGE)
Email discussion for maintenance on scheduling particularly w.r.t. multi-PDSCH/PUSCH with a single DCI, HARQ
- 1st check point: February 25
- Final check point: March 3
R1-2202339 Summary #1 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
Decision: As per email decision posted on Feb 26th,
Agreement
R1-2202679 Summary #2 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
From Mar 1st GTW session
Working assumption
The TP#1 below for TS 38.213 section 9.1.3.1 is endorsed.
|
If
a UE is provided numberOfHARQ-BundlingGroups and is not provided harq-ACK-SpatialBundlingPUCCH
for a serving cell |
Decision: As per email decision posted on Mar 1st,
Agreement
· When re-transmission of DL SPS is indicated by DCI format 1_1, the PDCCH indicates a TDRA row index including only one SLIV.
· When re-transmission of UL CG is indicated by DCI format 0_1, the PDCCH indicates a TDRA row index including only one SLIV.
Agreements
· Text Proposal TP#B (for 38.213, Clause 9.1.2.1) in section 4.2 of R1-2202679 is endorsed.
· Text Proposal TP#C (for 38.214, Clause 6.1) in section 4.3 of R1-2202679 is endorsed.
· Text Proposal TP#E (for 38.213, Clause 10.3) in section 4.5 of R1-2202679 is endorsed.
· Text Proposal TP#H (for 38.214, Clauses 5.1 and 6.1) in section 4.8 of R1-2202679 is endorsed.
Decision: As per email decision posted on Mar 2nd,
Conclusion
For a DCI that can schedule multiple PUSCHs, it is clarified that the following M is counted based on scheduled PUSCHs indicated by the TDRA information field.
· CSI-request: When the DCI schedules M PUSCHs, the PUSCH that carries the aperiodic CSI feedback is M-th scheduled PUSCH for M <= 2, or (M-1)-th scheduled PUSCH for M > 2.
Note: Aperiodic CSI feedback will be dropped if M-th scheduled PUSCH for M <= 2 (or (M-1)-th scheduled PUSCH for M > 2) is collided with semi-static DL or SSB symbols.
Decision: As per email decision posted on Mar 3rd,
Agreement
The following TP for TS 38.214 Clause 6.1.2.1 is endorsed
-------------------------------------------Start of TP#F1 for TS 38.214 Clause 6.1.2.1-----------------------------------------------
6.1.2.1 Resource allocation in time domain
If a UE is configured with pusch-TimeDomainAllocationListForMultiPDUSCH-r17
in which one or more rows contain multiple SLIVs for PUSCH on a UL BWP of a
serving cell, the UE does not apply pusch-AggregationFactor,
if configured, to DCI format 0_1 on the UL BWP of the serving cell
and the UE does not expect to be configured with numberOfRepetitions
in pusch-TimeDomainAllocationListForMultiPDUSCH-r17.
------------------------------------------------------------End of TP#F1----------------------------------------------------------------
Agreement
The following TP for TS 38.214 Clause 5.1.3.2 is endorsed
-------------------------------------------Start of TP#J1 for TS 38.214 Clause 5.1.3.2 -----------------------------------------------
5.1.3.2 Transport block size determination
In case the
higher layer parameter maxNrofCodeWordsScheduledByDCI indicates that two
codeword transmission is enabled, then one of the two transport blocks is
disabled by DCI format 1_1 if IMCS = 26 and if rvid
= 1 for the corresponding transport block. When the UE is
configured with higher layer parameter [pdsch-TimeDomainAllocationListForMultiPDSCH-r17],
either the first or the second transport block of all scheduled PDSCHs is
disabled by the DCI format 1_1 if IMCS = 26 and if rvid = 2[RV
bits] are set to ‘1’ for the corresponding transport block of all
scheduled PDSCHs. If both transport blocks are enabled, transport
block 1 and 2 are mapped to codeword 0 and 1 respectively. If only one
transport block is enabled, then the enabled transport block is always mapped
to the first codeword.
------------------------------------------------------------End of TP#J1----------------------------------------------------------------
Agreement
For multi-PDSCH scheduling via a single DCI with 'tdmSchemeA' for single DCI based multi-TRP mechanism,
· If at least one of the repetitions of the PDSCH collides with semi-static UL symbols, the corresponding PDSCH (i.e., both repetitions) is considered as invalid.
o Note: No specification impact on Type-1 HARQ-ACK codebook construction is expected, as a consequence of this agreement.
o Note: This is not applied for the case when the multi-PDSCH DCI schedules only a single PDSCH.
Agreement
When a DCI format indicates TCI state update without scheduling PDSCH reception, the PDCCH indicates a TDRA row index including only one SLIV.
Agreement
For generating type-2
HARQ-ACK codebook corresponding to a DCI that can schedule multiple PDSCHs, if 
, the UE determines a number of HARQ-ACK information bits 
for obtaining a transmission power for a PUCCH, considering at
least the followings.
, 
(in 
formula) corresponding to the DCI in PDCCH monitoring occasion
is given by 2 if harq-ACK-SpatialBundlingPUCCH is not
provided and the DCI schedules two codewords, or given by 1 otherwise.
for a serving cell
or not configured with numberOfHARQ-BundlingGroups but configured
with PDSCH-TimeDomainResourceAllocationListForMultiPDSCH for a serving
cell, 
., (in 
formula)
corresponding to the DCI in PDCCH monitoring occasion is given by 2*X
(X= the number of
TBGs, each including at least one valid PDSCH which are constructed based
on the PDSCH(s) scheduled by the DCI) if harq-ACK-SpatialBundlingPUCCH
is not provided and the DCI schedules two codewords, or given by X
otherwise. (in formula) corresponding to the DCI in PDCCH monitoring
occasion is given by 2*Y(Y= the number of valid PDSCH receptions scheduled by the DCI)
if harq-ACK-SpatialBundlingPUCCH is not provided and the DCI
schedules two codewords, or given by Y otherwise.
Final summary in R1-2202796.
R1-2200957 Remaining issues of channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
R1-2200991 Remaining Issues in Channel Access for Beyond 52.6 GHz FUTUREWEI
R1-2201038 Remaining issues for channel access mechanisms InterDigital, Inc.
R1-2201089 Remaining issues on channel access mechanism for NR operation from 52.6GHz to 71 GHz vivo
R1-2201270 Discussion on remaining issue for channel access mechanism OPPO
R1-2201355 Remaining issues on channel access mechanism for up to 71GHz operation CATT
R1-2201393 Remaining issues on the channel access for 52.6 to 71GHz ZTE, Sanechips
R1-2201474 Remaining issues on Channel access mechanism for NR in FR2-2 NTT DOCOMO, INC.
R1-2201543 Remaining issues on channel access mechanism for 52.6GHz to 71 GHz Spreadtrum Communications
R1-2201578 Remaining issues on channel access mechanism for 60 GHz unlicensed spectrum Sony
R1-2201594 Remaining issues on channel access for NR in 60GHz unlicensed band TCL Communication
R1-2201666 Remaining issues on channel access mechanism Nokia, Nokia Shanghai Bell
R1-2201692 Discussion on channel access mechanism for extending NR up to 71 GHz Intel Corporation
R1-2201740 Channel Access Mechanisms Ericsson
R1-2201768 Remaining details on channel access mechanisms for unlicensed access above 52.6GHz Apple
R1-2201902 Remaining issues on channel access mechanism supporting NR from 52.6 to 71 GHz NEC
R1-2201916 Remaining issues on channel access mechanism for NR on 52.6-71 GHz Xiaomi
R1-2202008 Maintenance on channel access mechanism for NR from 52.6 GHz to 71 GHz Samsung
R1-2202065 Remaining issue for channel access mechanisms for 52.6-71 GHz NR operation MediaTek Inc.
R1-2202133 Channel access mechanism for NR in 52.6 to 71GHz band Qualcomm Incorporated
R1-2202235 Remaining issues of channel access mechanism for above 52.6GHz Transsion Holdings
R1-2202244 Remaining issue on channel access scheme for above 52.6GHz ASUSTEK COMPUTER (SHANGHAI)
R1-2202275 Discussion on sharing of directional channel occupancy Panasonic
R1-2202340 Channel access mechanism to support NR above 52.6 GHz LG Electronics
R1-2202410 Remaining issues on channel access for NR from 52.6 GHz to 71GHz Lenovo
R1-2202484 Remaining issue on channel access for NR from 52.6GHz to 71GHz WILUS Inc.
[108-e-NR-52-71GHz-07] – Jing (Qualcomm)
Email discussion for maintenance on channel access mechanism
- 1st check point: February 25
- Final check point: March 3
R1-2202493 FL summary on channel access for NR beyond 52.6GHz, version 1 Moderator (Qualcomm Incorporated)
From Feb 24th GTW session
Agreement
For the QCL Type-D of L3-RSSI measurement for unlicensed operation in FR2-2, if explicit TCI state is configured, use the TCI state.
· Use the QCL type-D of the latest PDSCH reception or latest CORESET monitoring for RSSI measurement, if the explicit TCI state is not configured.
· A dynamic update mechanism for TCI-State in RMTC-Config is not further considered in Rel.17
· The explicit TCI state is configured at least in RMTC-Config
· Note: For inter-frequency L3-RSSI measurement, the TCI state configured is with respect to the target frequency TCI state
· Note2: For a given L3-RSSI measurement occasion, the UE needs to identify the last PDSCH reception or last configured CORESET monitoring (whichever is later) before the L3-RSSI measurement occasion, and use the QCL Type-D of that for L3-RSSI monitoring
Decision: As per email decision posted on Feb 25th,
Agreement
· CO-Duration maximum value is increased to 4480 to support 5ms maximum COT under 960 kHz.
· Support using 120 kHz, 480 kHz, and 960 kHz as the reference SCS for CO-Duration definition
o Note this may not have any additional spec impact
Agreement
Support 480 kHz and 960 kHz as reference SCS/CP for L3-RSSI.
Decision: As per email decision posted on Feb 26th,
Agreement
For Type 1 channel access, if the count-down reaches 0, but the gNB/UE is not yet ready to transmit, the gNB/UE stops sensing, and resume sensing for one sensing slot, right before the targeted transmission start time. If the sensing slot is sensed as idle, the Type 1 channel access on that channel is declared as successful and the transmission can start. If the sensing slot is sensed as busy, the Type 1 channel access on that channel is declared as failed.
· Text Proposal 2.13-B (for 37.213, Section 4.4.1) in section 2.13 of R1-2202493 is endorsed.
Agreement
When independent per-beam LBT sensing is performed at gNB, a transmission is allowed to occur on a beam if the corresponding LBT procedure has been successful before the channel occupancy start time.
· Note: For multi-beam transmission, channel occupancy start time corresponding to all Tx beams is aligned.
· FFS: When independent per-beam LBT sensing is performed at UE.
R1-2202685 FL summary on channel access for NR beyond 52.6GHz, version 2 Moderator (Qualcomm Incorporated)
Decision: As per email decision posted on Mar 3rd,
Agreement
For LBT for single carrier UL transmission, UE performs LBT over a BW that at least includes the active UL BWP bandwidth
· The BW that at least includes the active UL BWP bandwidth is captured as “channel” in 37.213
Agreement
For LBT for single carrier DL transmission to a UE, gNB performs LBT over a bandwidth that at least includes the active DL BWP bandwidth configured for that UE.
· This does not rule out gNB implementation to perform LBT over a wider bandwidth
· The BW that at least includes the active DL BWP bandwidth is captured as “channel” in 37.213
For LBT for single carrier DL transmission to multiple UEs, from each UE point of view, gNB performs LBT over a bandwidth that at least includes the active DL BWP bandwidth configured for that UE.
· This does not rule out gNB implementation to perform LBT over a wider bandwidth that includes the active DL BWP of multiple UEs
Agreement
For the multi-channel channel access procedure, each time the gNB/UE attempts to acquire a COT
· the gNB/UE shall re-initialize the counter for each channel
· the initial value of the counter is independently determined for each channel
· count-down process is independent for each channel
· Start of the channel occupancy time in all channels is aligned.
· To acquire a new COT, the applied Type 1 channel access process for a new COT shall not start before the end of the previous COT.
Agreement
For licensed band operation, the IE channeAccessMode2-r17 should not be included
· Note: UE identifies this is licensed band from the band number in SIB1
· Note: This naturally implies that for licensed band operation, the UE will not be configured to operate in LBT mode.
Agreement
For unlicensed operation (or shared spectrum channel access), if gNB indicates to the UE this gNB-UE connection is operating in LBT mode, the periodic CSI-RS should be validated by COT duration or dynamically granted PDSCH or aperiodic CSI-RS over the same set of symbols
Conclusion
There is no consensus to support transmitting DL burst not multiplexed with DRS with Contention Exempt Short Control Signaling based transmission
Agreement
Support gNB as the initiating device to resume transmission within maximum COT without a Cat 2 LBT, no matter how long the gap is from the previous transmission from initiating device or responding device
· Note: This is motivated by regions where LBT is not required before each transmission (say outside Japan)?
· Note: This should only be used when allowed by local regulation
Agreement
Support gNB as the initiating device to resume transmission with a Cat 2 LBT if there is gap longer than Y us from the previous transmission from initiating device or responding device
· Note this is motivated by regions where LBT is required before each transmission (say Japan)
· Y is left for initiating device implementation and should comply with local regulation but no less than 8us
Agreement
Before the UE reports it LBT capability, gNB is allowed to schedule UL transmission with Type 1 channel access
· If the UE does not support Type 1 channel access, the UE should not transmit
Final summary in R1-2202876.
R1-2201394 Discussion on RRC parameters for 52.6 to 71GHz ZTE, Sanechips
R1-2202437 Discussion on the channel raster and sync raster in FR2-2 Huawei, HiSilicon
R1-2205561 Session notes for 8.2 (Maintenance on Supporting NR from 52.6GHz to 71 GHz) Ad-Hoc Chair (Huawei)
R1-2205124 Summary of preparation phase email discussion for Rel.17 FR2-2 maintenance Moderator (Qualcomm)
Draft LS to RAN2 on updates to the RRC parameters, covering the following agreements:
· [109-e-R17-FR2-2-01]
o Text Proposal #3-2A for TS38.331 in section 3 of R1-2205138 is endorsed and recommended to RAN2.
· [109-e-R17-FR2-2-02]
o Agreement: Add parameter pdcch-BlindDetectionCA-CombIndicator-r17 to the updated RRC parameter spreadsheet.
· [109-e-R17-FR2-2-03]
o Agreement: Support the following values of aperiodicTriggeringOffset-r17 for SCS 480 and 960 kHz, where the value indicates the number of slots. {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31}*4.
· [109-e-R17-FR2-2-05]
o Agreement: To correct the value range for duration-r17 and offset-r17 in cg-COT-Sharing-r17 to 319 as per the agreement in RAN1#107-e, and to correct the value range for the size of the cg-COT-SharingList-r17 to 50,722.
R1-2205379 Draft LS to RAN2 on RRC parameter update for NR up to 71GHz Moderator (Qualcomm)
Decision: As per email decision posted (under [109-e-R17-FR2-2-01]) on May 17th, the draft LS and its attachment are endorsed. Final LS is approved in R1-2205380.
R1-2203079 Remaining issue of initial access signals and channels for 52-71GHz spectrum Huawei, HiSilicon
R1-2203290 Remaining issues on initial access aspects for 52.6 to 71GHz ZTE, Sanechips
R1-2203369 Remaining issues for initial access operation in 52.6-71GHz InterDigital, Inc.
R1-2203430 Remaining issues on Initial access aspects for up to 71GHz operation CATT
R1-2203508 Maintenance on initial access for NR operation from 52.6GHz to 71GHz vivo
R1-2203858 Maintenance on initial access aspects for NR from 52.6 GHz to 71 GHz Samsung
R1-2203986 Discussion on remaining issue for initial access aspects OPPO
R1-2204110 Initial Access Aspects Ericsson
R1-2204201 Remaining issues for initial access aspects Apple
R1-2204338 Remaining issues on initial access aspects for NR in FR2-2 NTT DOCOMO, INC.
R1-2204599 Initial access aspects Nokia, Nokia Shanghai Bell
R1-2204611 Remaining issues of initial access aspects to support NR above 52.6 GHz LG Electronics
R1-2204766 Discussion on initial access aspects for extending NR up to 71 GHz Intel Corporation
[109-e-R17-FR2-2-01] – Daewon (Intel)
Email discussion under 8.2.1 for maintenance on initial access aspects, for issues 1-1, 1-4, 1-5 and 1-6 in R1-2205124
- 1st check point: May 13 (any RRC impact by May 12)
- Final check point: May 18
R1-2205138 Summary #1 of email discussion on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
Decision: As per email decision posted on May 13th,
Agreement
· Text Proposal #1-1 (for TS38.213 v17.1.0, clause 13) in section 3 of R1-2205138 is endorsed, without the empty row.
· Text Proposal #3-1 (for TS38.213 v17.1.0, clause 13) in section 3 of R1-2205138 is endorsed.
· Text Proposal #3-2A for TS38.331 in section 3 of R1-2205138 is endorsed and recommended to RAN2.
Send LS to RAN2 asking to update the description. To be handled in LS on RRC parameter update.
Final summary in R1-2205532.
R1-2203080 Remaining issues of PDCCH monitoring enhancement for 52-71GHz spectrum Huawei, HiSilicon
R1-2203291 Remaining issues on PDCCH monitoring enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2203370 Remaining issues for PDCCH monitoring enhancements InterDigital, Inc.
R1-2203431 Remaining issues on PDCCH monitoring enhancements for up to 71GHz operation CATT
R1-2203509 Maintenance on PDCCH monitoring enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2203859 Maintenance on PDCCH monitoring enhancements for NR from 52.6 GHz to 71 GHz Samsung
R1-2203987 Discussion on remaining issue for PDCCH monitoring enhancement OPPO
R1-2204075 Remaining issues on PDCCH monitoring Panasonic
R1-2204111 PDCCH Monitoring Enhancements Ericsson
R1-2204202 On remaining issues for PDCCH Monitoring Apple
R1-2204339 Remaining issues on PDCCH monitoring enhancements for NR in FR2-2 NTT DOCOMO, INC.
R1-2204514 PDCCH monitoring enhancements Sharp
R1-2204566 Remaining Issues on PDCCH Monitoring Enhancements in FR2-2 TCL Communication
R1-2204578 Remaining issues of PDCCH monitoring enhancements for above 52.6GHz Transsion Holdings
R1-2204600 Remaining issues on PDCCH monitoring enhancements Nokia, Nokia Shanghai Bell
R1-2204612 Remaining issues of PDCCH monitoring enhancements to support NR above 52.6 GHz LG Electronics
R1-2204706 Remaining discussion on PDCCH monitoring enhancement for 52.6-71 GHz NR operation MediaTek Inc.
R1-2204767 Discussion on PDCCH monitoring enhancements for extending NR up to 71 GHz Intel Corporation
R1-2204979 PDCCH monitoring enhancements for NR in 52p6 to 71GHz band Qualcomm Incorporated
[109-e-R17-FR2-2-02] – Alex (Lenovo)
Email discussion under 8.2.2 for maintenance on PDCCH monitoring enhancements, for issues 2-1/2-8, 2-4, 2-5/2-7/2-9, 2-10, 2-12, 2-13, 2-15 (RRC) and issue 8-1 in R1-2205124
- 1st check point: May 13 (any RRC impact by May 12)
- Final check point: May 18
R1-2205279 Feature lead summary #1 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
Decision: As per email decision posted on May 13th,
Agreement
· For SCS 120 kHz, searchSpaceSwitchDelay supports values {40, 41, …, 52}.
· For SCS 480 kHz, searchSpaceSwitchDelay supports values {160, 164, …, 208}.
· For SCS 960 kHz, searchSpaceSwitchDelay supports values {320, 328, …, 416}
· Include above value ranges in the RRC sheet provided to RAN2.
Agreement
· Text Proposal 2-10-1 (for TS38.213 v17.1.0, clause 10) in section 2.7 of R1-2205279 is endorsed.
Agreement
Add parameter pdcch-BlindDetectionCA-CombIndicator-r17 to the updated RRC parameter spreadsheet which will be Send to RAN2 in an LS during RAN1#109-e.
To be handled in LS on RRC parameter update.
Agreement
For search space set configuration of multi-slot PDCCH monitoring, for Group (2) SSs
· For Type0/0A/2 CSS
· For Type1 CSS without dedicated RRC
o The number of slots configured for multi-slot PDCCH monitoring in monitoringSlotsWithinSlotGroup-r17 per group of L slots should be no larger than 1
Decision: As per email decision posted on May 17th,
Agreement
For a UE
configured with multiple SSSGs switching and multi-slot based PDCCH monitoring,
the UE determines the applicable 
combination in a BWP based on all configured SS sets in the BWP.
· Note: No spec change may be required for this agreement.
· Note: The gNB can configure SS sets in multiple SSSGs using different values of L
Conclusion
Switching between SSSGs with different
combinations of is supported by BWP switching.
R1-2205280 Feature lead summary #2 for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
Decision: As per email decision posted on May 19th,
Agreement
· The UE capability framework agreed in RAN1#108-e for CA is extended to the case of NR-DC considering different combinations of Rel-17 (per-slot group) monitoring, Rel-15 (per-slot) monitoring, and Rel-16 (per-span) monitoring within different cell groups.
· Suggest the contents under the bullets for NR-DC cases 4/5/6/7 in Proposal 2-12.2 in R1-2205280 as possible implementation of this agreement to the spec editors.
R1-2205518 Correction to BD/CCE budget allocation over multiple serving cells for multi-DCI multi-TRP for FR2-2 Ericsson (rev of R1-2205466)
Decision: As per email decision posted on May 21st,
Agreement
· The text Proposal (for TS38.213 v17.1.0, clause 10) in R1-2205518 is endorsed.
Agreement
· For the UE capability parameters for carrier aggregation according to Cases 4,5,6,7 agreed in RAN1#108e, support the following value ranges:
Final summary in R1-2205523.
R1-2203081 Remaining issues of PDSCH/PUSCH enhancement for 52-71GHz spectrum Huawei, HiSilicon
R1-2203292 Remaining issues on data channel enhancements for 52.6 to 71GHz ZTE, Sanechips
R1-2203371 Remaining issues for PDSCH/PUSCH enhancements to supporting 52.6-71 GHz band in NR InterDigital, Inc.
R1-2203401 Discussion on PDSCH/PUSCH enhancements for NR 52.6-71 GHz Panasonic
R1-2203432 Remaining issues on PDSCH/PUSCH enhancements for up to 71GHz operation CATT
R1-2203510 Maintenance on PDSCH/PUSCH enhancements for NR operation from 52.6GHz to 71GHz vivo
R1-2203678 Remaining issues of PDSCH/PUSCH enhancements for 52.6 to 71GHz NEC
R1-2203708 Remaining issues of multi-PDSCH/PUSCH scheduling via a single DCI Fujitsu Limited
R1-2203784 Remaining issues on PDSCH and PUSCH enhancements for NR 52.6-71GHz xiaomi
R1-2203860 Maintenance on PDSCH/PUSCH enhancements for NR from 52.6 GHz to 71 GHz Samsung
R1-2203988 Discussion on remaining issue for PDSCH/PUSCH enhancements OPPO
R1-2204112 PDSCH-PUSCH Enhancements Ericsson
R1-2204190 Discussion on multi-PXSCH scheduling ASUSTeK
R1-2204203 On remaining issues for PDSCH PUSCH Enhancements Apple
R1-2204340 Remaining issues on PDSCH/PUSCH enhancements for NR in FR2-2 NTT DOCOMO, INC.
R1-2204601 Remaining issues on PDSCH/PUSCH enhancements Nokia, Nokia Shanghai Bell
R1-2204613 Remaining issues of PDSCH/PUSCH enhancements to support NR above 52.6 GHz LG Electronics
R1-2204707 Remaining discussion on multi-PDSCH scheduling design for 52.6-71 GHz NR operation MediaTek Inc.
R1-2204768 Discussion on PDSCH/PUSCH enhancements for extending NR up to 71 GHz Intel Corporation
R1-2204980 PDSCH and PUSCH enhancements Qualcomm Incorporated
[109-e-R17-FR2-2-03] – Huaming (vivo)
Email discussion under 8.2.3 for maintenance on RS and timeline, for issues 3-2, 3-3 and 3-4 in R1-2205124
- 1st check point: May 13 (any RRC impact by May 12)
- Final check point: May 18
Decision: As per email decision posted on May 13th,
Conclusion
No issue is identified in RAN1 to adopt 64 as agreed in RAN2 for maxSchedulingK0/2-SchedulingOffset-r17 for SCS 480 and 960 kHz.
Agreement
Support the following values of aperiodicTriggeringOffset-r17 for SCS 480 and 960 kHz, where the value indicates the number of slots.
{0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31}*4.
Summary in
R1-2205136 Discussion summary #1 of [109-e-R17-FR2-2-03] Moderator (vivo)
[109-e-R17-FR2-2-04] – Seonwook (LGE)
Email discussion under 8.2.3 for maintenance on scheduling and HARQ, for issues 4-1, 4-2, 4-3, 4-5, 4-10, 4-11, 4-12, 4-13, 4-16, 4-18, 4-21 in R1-2205124
- 1st check point: May 13 (any RRC impact by May 12)
- Final check point: May 18
R1-2205191 Summary #1 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
Decision: As per email decision posted on May 13th,
Agreement
Update the previous agreement made in RAN1#106bis-e, as follows:
Agreement: (RAN1#106bis-e)
For multiple PDSCHs (or PUSCHs) scheduled by a single DCI,
· Rel-15/16 behavior that is described in TS 38.213 Clauses 11 and 11.1 for a PDSCH (or PUSCH) indicated by DCI also applies for multiple PDSCHs (or PUSCHs) schedule by a single DCI.
· If one of multiple PDSCHs (or PUSCHs) scheduled by the DCI collides with a flexible symbol (indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated),
o If that PUSCH is collided with SSB symbols
indicated by ssb-PositionsInBurst [or
symbol(s) indicated by pdcch-ConfigSIB1 in MIB for a CORESET for
Type0-PDCCH CSS set], the HARQ process number increment is skipped
for the PUSCH.
o Otherwise, the HARQ process number increment is not skipped for that PDSCH (or PUSCH).
Agreement
Adopt the following text proposal to TS38.213 v17.1.0 Clause 9.
· Reason for change
o The following agreement is not captured in current specification.
|
Agreement: (RAN1#106-e) · For a DCI that can schedule multiple PUSCHs, o Priority indicator and open loop power control parameter set indication fields are applied to all of scheduled PUSCHs. · For a DCI that can schedule multiple PDSCHs, o Priority indicator field is applied to all of scheduled PDSCHs. |
----------------------------------------------Start of text proposal to TS38.213 v17.1.0 --------------------------------------------
9 UE procedure for reporting control information
< Unchanged parts are omitted >
If
in an active DL BWP a UE monitors PDCCH for detection of DCI format that
includes a priority indicator field, a priority index can be provided by the
priority indicator field. If a UE indicates a capability to monitor, in an
active DL BWP, PDCCH for detection of DCI format that includes a priority
indicator field, the DCI format can schedule a PUSCH
transmission(s) of any priority, or a PDSCH
reception(s) and/or trigger a PUCCH
transmission with corresponding HARQ-ACK information of any priority, and DCI
format 1_1 or DCI format 1_2 can indicate a TCI state update and trigger a
PUCCH transmission with corresponding HARQ-ACK information of any priority.
--------------------------------------------End of Text proposal to TS38.213 v17.1.0 --------------------------------------------
Agreement
For single TRP or multi-TRP operation, for 480/960 kHz SCS,
· A UE does not expect to receive more than one unicast PDSCH in a slot on a serving cell from the same TRP.
· A UE does not expect to transmit more than one PUSCH in a slot on a serving cell from the same TRP.
Decision: As per email decision posted on May 18th,
Conclusion
For a DCI that can schedule multiple PDSCHs or multiple PUSCHs,
|
Conclusion (RAN1#107bis-e) · UE does not expect any of the scheduled PDSCHs (or PUSCHs) and the scheduling DCIs to lead to out-of-order scheduling, also for the case of one multi-PDSCH (or multi-PUSCH) scheduling DCI and one single-PDSCH (or single-PUSCH) scheduling DCI, where multi-PDSCH (or multi-PUSCH) scheduling DCI schedules more than one PDSCH (or PUSCH). o This may not have specification impact. · Note: It is separately discussed whether the scheduled PDSCHs (or PUSCHs or SLIV) is based on configured SLIV or valid SLIV.
Agreement (RAN1#108-e) · The case where two multi-PDSCH (or multi-PUSCH) scheduling DCIs end in the same symbol but two multi-PDSCH (or multi-PUSCH) schedulings have overlapping spans, where the span is defined from the beginning of the first scheduled SLIV till the end of the last scheduled SLIV, is considered as out-of-order scheduling and is not expected by UE. o This applies also when one of two DCIs is single-PDSCH (or single-PUSCH) scheduling DCI, including the case that one DCI schedules multi-slot PDSCH (or PUSCH repetition type A or B). o Note: This doesn’t apply when each of two DCIs schedules multi-slot PDSCH (or PUSCH repetition type A or B) as in Rel-15/Rel-16 o Note: This doesn’t apply when each of the two DCIs schedules single PDSCH (or single PUSCH) as in Rel-15/Rel-16 · Note: It is separately discussed whether the scheduled SLIV is based on configured SLIV or valid SLIV. |
Agreement
· Text Proposal #4-2-2 (for TS38.213 v17.1.0, clause 9.1.3) in section 3 of R1-2205191 is endorsed.
· Text Proposal #4-3 (for TS38.213 v17.1.0, clause 9.1.2.1) in section 4 of R1-2205191 is endorsed.
Conclusion
|
Agreement (RAN1#107-e) · If a UE is configured with a TDRA table in which one or more rows contain multiple SLIVs for PDSCH for DCI format 1_1, the UE does not expect to be configured with repetitionNumber for the TDRA table, and if pdsch-AggregationFactor is configued in PDSCH-config, it does not apply to DCI format 1_1. o Note: repetitionNumber cannot be configured with pdsch-TimeDomainAllocationListDCI-1-2 as in Rel-16. o Note: Under agenda item 8.2.4, in RAN1#106-bis, it was already agreed that within the TDRA table for multi-PDSCH scheduling, the UE does not expect to be configured with the higher layer parameter repetitionNumber. o Note: These does not preclude pdsch-AggregationFactor can be configured and applies to DCI format 1_2 · If a UE is configured with a TDRA table in which one or more rows contain multiple SLIVs for PUSCH for DCI format 0_1, the UE does not expect to be configured with numberOfRepetitions for the TDRA table, and if pusch-AggregationFactor is configued in PUSCH-config, it does not apply to DCI format 0_1. o Note: These does not preclude numberOfRepetitions is configured for TDRA table corresponding to DCI format 0_2 o Note: These does not preclude pusch-AggregationFactor can be configured and applies to DCI format 0_2 |
Conclusion
· If type-1 HARQ-ACK codebook is configured, the intersection of predefined K1 values for DCI 1_0 and the extended K1 set for DCI 1_1/1_2 is applicable to DCI 1_0.
· The current specification already covers the behavior. Hence no specification change is necessary.
R1-2205475 Summary #2 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
Decision: As per email decision posted on May 19th,
Conclusion
If type-1 HARQ-ACK codebook with time domain bundling is configured, UE does not expect to be scheduled with a PDSCH (scheduled by multi-PDSCH DCI) and to receive SPS PDSCH for a PDSCH reception occasion within a slot.
· Note: This applies only when the PDSCH (scheduled by multi-PDSCH DCI) associated with the last SLIV is invalid due to collision with semi-static UL symbol(s).
· Note: No spec change is needed.
Agreement
· Text Proposal #4-11 (for TS38.213 v17.1.0, clause 9.1.3.1) in section 7 of R1-2205475 is endorsed.
Final summary in R1-2205549.
R1-2203056 Remaining Details in Channel access for Beyond 52.6 GHz FUTUREWEI
R1-2203082 Remaining issues of channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
R1-2203293 Remaining issues on channel access for 52.6 to 71GHz ZTE, Sanechips
R1-2203372 Remaining issues for channel access mechanisms InterDigital, Inc.
R1-2203433 Remaining issues on channel access mechanism for up to 71GHz operation CATT
R1-2203511 Maintenance on channel access mechanism for NR operation from 52.6GHz to 71 GHz vivo
R1-2203679 Remaining issues on channel access mechanism supporting NR from 52.6 to 71 GHz NEC
R1-2203785 Remaining issues on channel access mechanism for NR on 52.6-71 GHz xiaomi
R1-2203861 Maintenance on channel access mechanism for NR from 52.6 GHz to 71 GHz Samsung
R1-2203989 Discussion on remaining issue for channel access mechanism OPPO
R1-2204113 Channel Access Mechanisms Ericsson
R1-2204204 Remaining details on channel access mechanisms for unlicensed access above Apple
R1-2204341 Remaining issues on Channel access mechanism for NR in FR2-2 NTT DOCOMO, INC.
R1-2204546 Remaining issue on channel access for NR from 52.6GHz to 71GHz WILUS Inc.
R1-2204567 Remaining Issues on Channel Access for NR in 60GHz Unlicensed Band TCL Communication
R1-2204579 Remaining issues of channel access mechanism for above 52.6GHz Transsion Holdings
R1-2204602 Remaining issues on channel access mechanism Nokia, Nokia Shanghai Bell
R1-2204614 Remaining issues of channel access mechanism to support NR above 52.6 GHz LG Electronics
R1-2204636 Remaining issue on channel access scheme for above 52.6GHz ASUSTeK
R1-2204769 Discussion on Channel Access Mechanism for extending NR up to 71 GHz Intel Corporation
R1-2204826 Remaining issues on channel access for NR from 52.6 GHz to 71GHz Lenovo
R1-2204981 Channel access enhancements Qualcomm Incorporated
[109-e-R17-FR2-2-05] – Jing (Qualcomm)
Email discussion under 8.2.4 for maintenance on channel access mechanism
- Issues 5-1, 5-2, 5-3, 5-4, 5-5, 5-6, 5-7, 5-8, 5-9/5-16, 5-11, 5-12, 5-13, 5-14, 5-18, 5-19, 5-20, 5-21, 5-25, 5-26, 5-27, 5-28, 5-29, 5-31, 5-33, 5-35, as well as issues 2-16/17/18/19 and issue 4-Y in R1-2205124
- Aim to conclude on whether issues are essential or not by May 13
- Including discussion on LS in R1-2203027 if needed
- 1st check point: May 13 (any RRC impact by May 12)
- Final check point: May 18
R1-2205125 FL summary#1 of email discussion for channel access for Rel.17 FR2-2 Moderator (Qualcomm)
Decision: As per email decision posted on May 13th,
Agreement
For UL to DL COT sharing, support using type 2 channel access or type 3 channel access at gNB to share the COT
· The channel access type to use (Type 2 or Type 3) is left for gNB implementation.
Agreement
Before a UE reports it LBT capability, the UE does not expect the gNB to schedule UL transmission with Type 2 channel access.
Agreement
When both cell-specific channel access mode and UE-specific channel access mode are provided, the UE follows the UE-specific channel access indication
· FFS: TP (May be captured by RAN2 spec)
Agreement
RAN1 to send an LS to RAN2 to correct the value range for duration-r17 and offset-r17 in cg-COT-Sharing-r17 to 319 as per the agreement in RAN1#107-e, and to correct the value range for the size of the cg-COT-SharingList-r17 to 50,722.
Agreement
· Text Proposal 5-21-2-A (for TS37.213 v17.1.0, clause 4.0) in section 5-21 of R1-2205125 is endorsed.
Agreement
If the UE is configured to operate in no LBT mode
· The UE should ignore the channel access field, if present, in fallback DCI
· The UE does not expect channel access field to be configured in non-fallback DCI
Agreement
· Text Proposal 5-29-1-A (for TS37.213 v17.1.0, clause 4.4) in section 5-29 of R1-2205125 is endorsed.
· Text Proposal 5-31-1-B (for TS38.212 v17.1.0, clause 6.3.2.1.3) in section 5-31 of R1-2205125 is endorsed.
· Text Proposal 5-33-1-A (for TS38.214 v17.1.0, clause 5.1.5) in section 5-33 of R1-2205125 is endorsed.
Conclusion
In Rel.17, gNB sensing beam dependent rules are not introduced for UL transmission sharing gNB COT.
Conclusion
In Rel.17, gNB sensing beam dependent cancellation rules are not introduced for DL reception validation.
Conclusion
In Rel.17, gNB sensing beam dependent PDCCH monitoring skipping rules are not introduced.
Decision: As per email decision posted on May 19th,
Agreement
When independent per-beam LBT sensing is performed at gNB or UE, each time the gNB or UE attempts to acquire a COT
· Apply independent Type 1 channel access to each beam
· the gNB/UE shall re-initialize the counter for each beam
· the initial value of the counter is independently determined for each beam
· count-down process is independent for each beam
· Start of the channel occupancy time in all beam is aligned.
· To acquire a new COT, the applied Type 1 channel access process for a new COT to each beam shall not start before the end of the previous COT.
· Text Proposal 5-4-2-A below is endorsed for TS37.213 v17.1.0 clause 4.4.6
o Note to editor: Editor may need to decide if there is a better location in spec to place the TP
TP 5-4-2-A:
· Reason for change: Define the procedure to perform independent LBT over different beams
· Summary of change: Add a section to define the procedure to perform independent LBT over different sensing beams
· Consequence if not approved: The functionality not supported in the spec yet
================= TP for 37.213 17.1.0====================
4.4.6 Channel access procedures for transmission(s) on multiple channels
If a gNB/UE intends to
transmit a transmission(s) that starts at the same time on a set of channels 
, the gNB/UE
performs the channel access procedures described in Clause 4.4.1 on each
channel 
independently.
When the channel access procedures in Clause 4.4.1 are applied on any channel , the
corresponding counter 
in step 1
shall be initialized independently and the corresponding sensing on the
channel 
shall be
performed after the end of any previous transmission(s) by the gNB/UE occupying
any channel 
.
4.4.6A Channel access procedures for transmission(s) on multiple beams
When the gNB/UE intends to
transmit a transmission(s) starting at the same time across
multiple transmission beams, if the gNB/UE performs sensing on the
corresponding sensing beam(s) independently, the gNB/UE performs the channel
access procedures described in Clause 4.4.1 on each sensing beam independently.
When the channel access procedures in Clause 4.4.1 are applied on any sensing
beam, the corresponding counter in step
1 shall be initialized independently and the corresponding sensing on the
sensing beam shall be performed after the end of any previous transmission(s)
by the gNB/UE occupying any beam.
=============End of TP=====================================
Agreement
When a UE performing a CG transmission shares its COT with a gNB, the gNB transmission shall contain transmission to the UE that initiated the channel occupancy and can include non-unicast and/or unicast transmissions where any unicast transmission that includes user plane data is only transmitted to the UE that initiated the channel occupancy.
· TP 5-11-3-A below is endorsed for TS37.213 v17.1.0 clause 4.4.4A
TP 5-11-3-A
· Reason for change: CG-UL to DL COT sharing does not support serving unicast data to non-initiating UE
· Summary of change: Add description on what can be transmitted by gNB in a shared COT
· Consequence if not approved: The functionality not supported in the spec yet
==============TP for 37.213 17.1.0===================
4.4.4A Channel access procedures in a shared channel occupancy
If a gNB shares a channel occupancy initiated by a UE using the channel access procedures described in clause 4.4.1 on a channel, the gNB may transmit a transmission that follows a UL transmission on scheduled resources or a PUSCH transmission on configured resources by the UE as follows:
- The transmission shall contain transmission to the UE that initiated the channel occupancy and can include non-unicast and/or unicast transmissions where any unicast transmission that includes user plane data is only transmitted to the UE that initiated the channel occupancy.
===============End of TP==========================
Agreement
TP 5-12-2-A below is endorsed for TS37.213 v17.1.0 clause 4.4.2
TP 5-12-2-A:
· Reason for change: Clarify UE does not expect to be indicated with Type 2 channel access when the UE does not have the capability
· Summary of change: Clarify UE does not expect to be indicated with Type 2 channel access when the UE does not have the capability
· Consequence if not approved: Not clearly defined in spec yet
==============TP for 37.213 17.1.0===================
4.4.2 Type 2 channel access procedures
This clause describes channel access procedures to be performed by a gNB/UE where the time duration spanned by sensing slots that are sensed to be idle before a DL/UL transmission(s) is deterministic.
A gNB/UE may transmit a
transmission(s) on a channel immediately after 
which
includes a sensing slot with a duration 
where the
channel is sensed to be idle.
The UE does not expect to be indicated with Type 2 channel access procedures if the UE does not indicate the corresponding capability.
===============End of TP==========================
Conclusion
When channel access mode is provided to the UE indicating LBT mode is used, it is up to gNB implementation whether LBT at gNB side is actually used for channel access in regions where LBT is not mandated.
Agreement
Send LS to RAN4 with the text proposal in TP 5-19-1-A as recommendation for RAN4 TS38.133
TP 5-19-1-A:
· Reason for change: Clarify the QCL behavior of RSSI measurement
· Summary of change: Clarify the QCL behavior of RSSI measurement for 38.133
· Consequence if not approved: QCL behavior not captured in spec yet
==============TP for 37.213 17.1.0===================
9.2A.7 Intra-frequency RSSI and Channel occupancy measurements
9.2A.7.1 Intra-frequency RSSI measurements
An RSSI measurement is defined as an intra-frequency measurement provided that the RSSI measurement bandwidth is fully contained within the current carrier bandwidth of the UE.
The UE physical layer shall be capable of performing the RSSI measurements, defined in TS 38.215 [4] on one or more serving carriers operating with CCA, TS 37.213 [33], if the carrier(s) are indicated by higher layers [2], and report the RSSI measurements to higher layers. The UE physical layer shall provide to higher layers a single RSSI sample for each OFDM symbol within each configured RSSI measurement duration [2] occurring with a configured RSSI measurement timing configuration periodicity [2], rmtc-Periodicity.
For performing RSSI measurement in FR2-2, UE can assume the configured RSSI measurement resources are QCL-ed with TypeD to the DL RS associated with the TCI state provided in the RMTC configuration. If no TCI state is provided in the RMTC configuration, UE can assume the configured RSSI measurement resources are QCL-ed with TypeD to one of the latest received PDSCH and the latest monitored CORESET in the active BWP of the current carrier.
*** < Unchanged parts are omitted> ***
9.3A.8 Inter-frequency RSSI measurements
An RSSI measurement is defined as an inter-frequency measurement provided that the RSSI measurement bandwidth is not contained within the current carrier bandwidth of the UE.
The UE physical layer shall be capable of performing the RSSI measurements, defined in TS 38.215 [4] on one or more inter-frequency carriers operating with CCA, TS 37.213 [33], if the carrier(s) are indicated by higher layers [2], and report the RSSI measurements to higher layers. The UE physical layer shall provide to higher layers a single RSSI sample for each OFDM symbol within each configured RSSI measurement duration [2] occurring with a configured RSSI measurement timing configuration periodicity [2], rmtc-Periodicity. The requirements apply if rmtc-SubframeOffset [2] is configured.
For performing RSSI measurement in FR2-2, UE can assume the configured RSSI measurement resources are QCL-ed with TypeD to the DL RS associated with the TCI state provided in the RMTC configuration. If the configured RSSI measurement resources are not confined within the bandwidth of any serving cell, UE can assume that the measurement resources are QCL-ed with TypeD to the DL RS associated with the TCI state of the active BWP of the carrier on which the RMTC configuration is provided. If no TCI state is provided in the RMTC configuration, UE can assume the configured RSSI measurement resources are QCL-ed with TypeD to one of the latest received PDSCH and the latest monitored CORESET in the active BWP of the carrier on which the RMTC configuration is provided.
===============End of TP==========================
Agreement
· If a UE is scheduled to transmit a set of consecutive UL transmissions without gaps including PUSCH using one or more UL grant(s), PUCCH using one or more DL grant(s), or SRS with one or more DL grant(s) or UL grant(s)
o UE does not expect different channel access types to be indicated for different UL transmissions
o The UE transmits the first of the scheduled UL transmissions in the set after accessing the channel using the channel access type indicated in the DCI
o The UE may continue transmit the remaining UL transmissions in the set without any LBT.
o TP 5-28-2-A below is endorsed for TS37.213 v17.1.0 clause 4.4
· Note: If a UE is scheduled to transmit a set of consecutive UL transmission bursts with gaps including PUSCH using one or more UL grant(s), PUCCH using one or more DL grant(s), or SRS with one or more DL grant(s) or UL grant(s)
o Each transmission burst is handled separately as the proposal above, and there is no requirement for the channel access field to be the same across bursts
o If type 1 channel access is indicated for an earlier burst, and the next burst is also indicated as type 1 channel access, the 2nd burst can be transmitted using UE COT resuming as discussed in proposal 5-8-1
TP 5-28-2-A
· Reason for change: Clarify the channel access for consecutive UL transmission from one or multiple grants
· Summary of change: Clarify the channel access for consecutive UL transmission from one or multiple grants
· Consequence if not approved: Not defined yet in spec
==============TP for 37.213 17.1.0===================
4.4 Channel access procedures for frequency range 2-2
** Unchanged part omitted****
When a UE is scheduled by a DCI to transmit a UL transmission(s), the scheduling DCI may indicate the corresponding channel access procedures for the UL transmission(s) as described in [10]. The UE determines based on the DCI if Type 1, or Type 2, or Type 3 channel access procedures described in Clause 4.4.1, Clause 4.4.2 and Clause 4.4.3, respectively, is applicable.
For contiguous UL transmission(s), the following are applicable:
- A UE is not expected to be indicated with different channel access types for any consecutive UL transmissions without gaps in between the transmissions.
- If the UE cannot access the channel for a transmission in the set prior to the last transmission according to one of Type 1 or Type 2 channel access procedures, the UE shall attempt to transmit the next transmission according to the channel access type indicated in the corresponding UL grant or DL assignment.
- If a UE is scheduled to transmit a set of consecutive UL transmissions without gaps including PUSCH using one or more UL grant(s), PUCCH using one or more DL grant(s), or SRS with one or more DL grant(s) or UL grant(s) and the UE transmits one of the scheduled UL transmissions in the set after accessing the channel according to one of Type 1, Type 2, or Type 3 channel access procedures, the UE may continue transmission of the remaining UL transmissions in the set, if any.
===============End of TP==========================
Agreement
TP 5-31-4-A below is endorsed for TS37.213 v17.1.0 clause 4.4.4A
TP 5-31-4-A
· Reason for change: Add description of CG-UL to DL COT sharing
· Summary of change: Add description of CG-UL to DL COT sharing
· Consequence if not approved: Not defined yet in spec
==============TP for 37.213 17.1.0===================
4.4.4A Channel access procedures in a shared channel occupancy
For the case where a gNB shares a channel occupancy initiated by a UE with configured grant PUSCH transmission, the gNB may transmit a transmission that follows the configured grant PUSCH transmission by the UE as follows:
- The UE is configured by cg-COT-SharingList-r17 where cg-COT-SharingList-r17 provides a table configured by higher layer. Each row of the table provides a channel occupancy sharing information given by higher layer parameter CG-COT-Sharing-r17. One row of the table is configured for indicating that the channel occupancy sharing is not available.
- If the 'COT sharing information' in CG-UCI detected in slot n indicates a row index that corresponds to a CG-COT-Sharing-r17 that provides channel occupancy sharing information, the gNB can share the UE channel occupancy starting from slot n+O, where O=offset-r17 slots, for a duration of D=duration-r17 slots where duration-r17, and offset-r17 are higher layer parameters provided by CG-COT-Sharing-r17.
===============End of TP==========================
R1-2205378 FL summary#1 of email discussion for channel access for Rel.17 FR2-2 Moderator (Qualcomm)
Decision: As per email decision posted on May 21st,
Agreement
· Text Proposal 5-21-4-A (for TS37.213 v17.1.0, clause 4.4) in section 5-21 of R1-2205378 is endorsed.
R1-2205581 Draft LS to RAN4 on TCI assumption for RSSI measurement in FR2-2 Qualcomm
Decision: As per email decision posted on May 24th, the draft LS is endorsed. Final LS is approved in R1-2205582.
For any other maintenance issues on supporting NR from 52.6GHz to 71 GHz
R1-2203294 Remaining issues on beam management for 52.6 to 71GHz ZTE, Sanechips
R1-2203373 Remaining issues for beam management for new SCSs InterDigital, Inc.
R1-2203512 Maintenance on beam management vivo
R1-2204114 Remaining issues for beam management Ericsson
R1-2204342 Remaining issues on beam based operation for new SCSs for NR from 52.6 to 71 GHz NTT DOCOMO, INC.
R1-2204603 Supported values for SSSG switching delay for 480 kHz and 960 kHz SCS Nokia, Nokia Shanghai Bell
R1-2204615 Remaining issues of beam management to support NR above 52.6 GHz LG Electronics
R1-2204896 Remaining issues of PUCCH enhancement and beam management enhancement for 52-71GHz spectrum Huawei, HiSilicon
[109-e-R17-FR2-2-06] – Steve (Ericsson)
Email discussion for maintenance on whether there is ambiguity on the determination of number of RBs for PUCCH Format 4, and if so any necessary correction, until May 13
R1-2205291 FL Summary for [109-e-R17-FR2-2-06] Email discussion on whether there is ambiguity on the determination of number of RBs for PUCCH Format 4 Moderator (Ericsson)
Decision: No consensus.
[109-e-R17-FR2-2-07] – Youngwoo (InterDigital)
Email discussion for maintenance on beam management for new SCSs, for issue 7-1 (introduction of beam switching gap) in R1-2205124, until May 13
R1-2205244 Discussion Summary #1 of Beam Management for New SCSs Moderator (InterDigital)
Decision: Email thread is closed waiting for RAN4 feedback on the issue.
R1-2208134 Session notes for 8.2 (Maintenance on Supporting NR from 52.6GHz to 71 GHz) Ad-Hoc Chair (Huawei)
[110-R17-FR2_2] 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 – Jing (Qualcomm)
R1-2205743 Remaining details for Beyond 52.6 channel access FUTUREWEI
R1-2205770 Discussion on timeline of CSI request for 52-71GHz spectrum Huawei, HiSilicon
R1-2206080 Discussion on remaining issues of channel access for 52.6 to 71GHz ZTE, Sanechips
R1-2206082 Clarification on Contention Exempt Short Control Signalling rules for UL in TS 37.213 ZTE, Sanechips
R1-2206086 Correction on UE PDSCH processing procedure time for operation with shared spectrum channel access in FR2-2 in TS 38.214 ZTE, Sanechips
R1-2206180 Remaining issues for NR 52.6 GHz to 71 GHz InterDigital, Inc.
R1-2206293 Discussion on remaining issue short control signaling OPPO
R1-2206294 Draft CR on resolving issue for short control signaling OPPO
R1-2206362 Correction on channel access procedures upon detection of a common DCI for frequency range 2-2 CATT
R1-2206364 Corrections on Random Access Response Grant Content field for frequency range 2-2 CATT
R1-2206365 Corrections on the value of slot configuration period for the features extending NR operation to 71 GHz CATT
R1-2206533 Discussion on remaining issues on TCI states for the scheduled PDSCHs by a DCI Intel Corporation
R1-2206534 [draft CR] Correction on the activated TCI states for the scheduled PDSCHs by a DCI Intel Corporation
R1-2206537 Discussion on Channel Access Indication within Fall-back and RAR UL Grant DCIs Intel Corporation
R1-2206538 [draft CR] correction on support of channel access indication within the fall-back DCIs Intel Corporation
R1-2206539 [draft CR] correction on support of channel access indication within the UL RAR grant Intel Corporation
R1-2206540 Discussion on Applicability of the Short Control Signalling Exemption Intel Corporation
R1-2206541 [draft CR] Correction on short control signaling LBT exemption applicability Intel Corporation
R1-2206542 Discussion on Pout and EDT Threshould for Independent per-beam LBT Operation Intel Corporation
R1-2206543 [draft CR] Correction on EDT threshold calculation for per-beam LBT operation Intel Corporation
R1-2206615 Correction on the bit length of ChannelAccess-CPext-CAPC field in DCI 0-1 and DCI 1-1 for FR 2-2 Xiaomi
R1-2206733 Correction on short control signaling constrain vivo
R1-2206734 Correction on the indication of channel access Types vivo
R1-2206735 Remaining issues on channel access mechanism for NR operation from 52.6GHz to 71 GHz vivo
R1-2206792 Draft CR for multi-beam channel access procedure in FR2-2 Samsung
R1-2206793 Draft CR for HARQ-ACK timing parameters for FR2-2 Samsung
R1-2206794 Draft CR for aperiodic CSI triggering offset for FR2-2 Samsung
R1-2206976 Remaining issues on channel access mechanism Nokia, Nokia Shanghai Bell
R1-2206977 Correction on ChannelAccess-Cpext field in fallback DCIs 0_0 and 1_0 Nokia, Nokia Shanghai Bell
R1-2206978 Correction on ChannelAccess-Cpext field in random access response Nokia, Nokia Shanghai Bell
R1-2207018 Corrections on Short Control Signaling Nokia, Nokia Shanghai Bell
R1-2207026 Draft CR for aperiodic CSI triggering offset in FR2-2 LG Electronics
R1-2207028 Remaining issues of channel access mechanism to support NR above 52.6 GHz LG Electronics
R1-2207029 Draft CR for independent per-beam sensing and LBT procedure for UE in FR2-2 LG Electronics
R1-2207030 Draft CR on channel access indication for RAR grant in FR2-2 LG Electronics
R1-2207031 Draft CR for channel access indication within fallback-DCI in FR2-2 LG Electronics
R1-2207098 Correction on UE resuming a UE initiated COT Nokia, Nokia Shanghai Bell
R1-2207179 Draft CR on ChannelAccess-Cpext in Fallback DCI Qualcomm Incorporated
R1-2207180 Draft CR on ChannelAccess-Cpext in RAR UL Grant Qualcomm Incorporated
R1-2207181 Draft CR on sensing exempted transmission of first message of RACH Qualcomm Incorporated
R1-2207182 Draft CR on BW parameter in EDT determination and ED Value cap Qualcomm Incorporated
R1-2207183 Draft CR on UL transmission with LBT per sensing beam Qualcomm Incorporated
R1-2207184 Draft CR on EDT determination rule for COT with SDM or TDM transmission with per beam LBT Qualcomm Incorporated
R1-2207185 Draft CR on rule for resuming a transmission after a gap within MCOT Qualcomm Incorporated
R1-2207186 Draft CR on rule for channel access type upgrade Qualcomm Incorporated
R1-2207187 Discussion paper on Maintenance for NR from 52.6GHz to 71 GHz Qualcomm Incorporated
R1-2207309 Maintenance on Supporting NR from 52.6GHz to 71GHz Apple
R1-2207380 Draft CR on channel access type indication by fallback DCI in FR2-2 NTT DOCOMO, INC.
R1-2207381 Draft CR on spatial domain filter for sensing in FR2-2 NTT DOCOMO, INC.
R1-2207382 Discussion on remaining issues for NR in FR2-2 NTT DOCOMO, INC.
R1-2207468 Draft CR on LBT-type indication in RAR UL grant Ericsson
R1-2207469 Discussion on LBT-type indication in RAR UL grant Ericsson
R1-2207470 Draft CR on LBT-type indication in Fallback DCIs Ericsson
R1-2207471 Discussion on LBT-type indication in Fallback DCIs Ericsson
R1-2207472 Discussion on L3-RSSI measurements and LS to RAN4 Ericsson
R1-2207473 Discussion on configuration to enable LBT for all transmissions Ericsson
R1-2207495 Correction on CSI-RS validation ASUSTeK
R1-2207524 Corrections on the timeline of CSI request in TS38.214 Huawei, HiSilicon
R1-2207595 Remaining issue on channel access for NR from 52.6GHz to 71GHz WILUS Inc.
R1-2207642 Remaining issues of channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
R1-2207663 Corrections to ED threshold for use with Type 2 channel access procedure in FR2-2 in TS37.213 Huawei, HiSilicon
R1-2207664 Corrections to the conditions for channel sensing in FR2-2 in TS37.213 Huawei, HiSilicon
R1-2207753 FL summary #1 of PDSCH/PUSCH enhancement (RS and timeline) Moderator (vivo)
Agreement
Support the value range of reportSlotOffsetList-r17, reportSlotOffsetListDCI-0-1-r17 and reportSlotOffsetListDCI-0-2-r17 for 480kHz and 960kHz SCS to INTEGER (0..128).
· Send an LS to RAN2 – Huaming (vivo) --> see approved LS in R1-2208040.
R1-2207964 DRAFT LS to RAN2 on reportSlotOffsetList parameter for NR up to 71GHz Moderator (vivo)
R1-2207965 Draft CR Corrections on timeline of CSI request for 480kHz and 960kHz SCS in TS38.214 Moderator (vivo), Huawei, HiSilicon
Decision: The draft CR is endorsed. Final CR is agreed in R1-2208007: CR#0298 (38.214, Cat-F, Rel-17).
R1-2207966 Draft CR Correction on UE PDSCH processing procedure time for operation with shared spectrum channel access in FR2-2 in TS 38.214 Moderator (vivo), ZTE, Sanechips
Decision: The draft CR to TS38.214 is endorsed in principle. Final CR is agreed in R1-2208008: CR#0299 (38.214, Cat-F, Rel-17).
R1-2207967 Draft CR Corrections on the value of slot configuration period in TS 38.213 for the features extending NR operation to 71 GHz Moderator (vivo), CATT, Nokia
Decision: The draft CR to TS38.213 is endorsed in principle. Final CR is agreed in R1-2208009: CR#0335 (38.213, Cat-F, Rel-17).
R1-2207968 Draft CR Correction for aperiodic CSI triggering offset for FR2-2 in TS 38.214 Moderator (vivo), LG Electronics, Samsung
Decision: The draft CR to TS38.214 is endorsed in principle. Final CR is agreed in R1-2208010: CR#0300 (38.214, Cat-F, Rel-17).
PDCCH monitoring enhancements
R1-2206081 Draft CR on multi-slot PDCCH monitoring for TS 38.213 ZTE, Sanechips
R1-2206363 Corrections for PDCCH monitoring occasion for DCI format 2_1 for the features extending NR operation to 71 GHz CATT
R1-2206791 Draft CR for multi-slot PDCCH monitoring in FR2-2 Samsung
R1-2207021 On UE capability parameters for CA with per-slot group monitoring Nokia, Nokia Shanghai Bell
R1-2207023 Discussion on default value of duration-r17 in FR2-2 LG Electronics
R1-2207024 Draft CR for SSSG switching with multiple cells in FR2-2 LG Electronics
R1-2207025 Discussion on SSSG switching with multiple cells in FR2-2 LG Electronics
R1-2207465 Discussion on UE capability name alignment Ericsson
R1-2207466 Draft CR on Group 2 search space configuration Ericsson
R1-2207467 Discussion on Group 2 search space configuration Ericsson
R1-2207948 FL Summary for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
Agreement
· Send an LS to RAN2 to request that 38.331 captures the following: If duration-r17 is absent, the UE assumes the duration in slots is equal to L (where L is the configured length of the bitmap monitoringSlotsWithinSlotGroup-r17).
Comeback for the draft LS on Thursday – include this in the LS prepared by Huaming.
R1-2208039 [DRAFT] LS to RAN2 on RRC parameter impact for NR up to 71GHz Moderator (vivo)
Decision: The draft LS response in R1-2208039 is endorsed. Final LS is approved in R1-2208040.
R1-2206732 Correction on multi-slot PDCCH monitoring in CA scenario with mixed capability types vivo
R1-2207464 Draft CR on UE capability name alignment Ericsson
Agreement
· The draft CRs in R1-2206732 and R1-2207464 are endorsed.
Final CR (38.213, Rel-17, CR#0342, Cat F) is agreed in:
R1-2208055 Correction on multi-slot PDCCH monitoring in NR-DC and CA scenarios with mixed capability types Moderator (Lenovo), vivo, Ericsson
R1-2207519 Corrections on PDCCH monitoring enhancement for 52-71GHz spectrum Huawei, HiSilicon
R1-2208088 Corrections on PDCCH monitoring enhancement for 52-71GHz spectrum Huawei, HiSilicon, Ericsson, Lenovo
Agreement
· Endorse the draft CR in R1-2208088 with the deletion of a “c”.
Final CR (38.213, Rel-17, CR#0346, Cat F) is agreed in:
R1-2208089 Corrections on PDCCH monitoring enhancement for 52-71GHz spectrum Huawei, HiSilicon, Ericsson, Lenovo
Issues on initial access aspect
R1-2205768 Remaining issue of initial access signals and channels for 52-71GHz spectrum Huawei, HiSilicon
R1-2206083 Correction on the subcarrier offset k_SSB in TS 38.211 ZTE, Sanechips
R1-2206084 Correction on the tables for determining PDCCH monitoring occasions in TS 38.213 ZTE, Sanechips
R1-2206087 Correction on CD-SSB frequency indication using NCD-SSB in TS 38.213 ZTE, Sanechips
R1-2206088 Discussion on CD-SSB frequency indication using NCD-SSB ZTE, Sanechips
R1-2206730 Correction on indication of cell defined SSB from non-cell defined SSB vivo
R1-2206731 Remaining issues on CD-SSB frequency indication in initial access vivo
R1-2206789 Discussion for cell-defining SSB indication using non-cell-defining SSB in FR2-2 Samsung
R1-2206790 Draft CR for cell-defining SSB indication using non-cell-defining SSB in FR2-2 Samsung
R1-2207082 Initial access aspects Nokia, Nokia Shanghai Bell
R1-2207696 Summary of issues on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
R1-2208051 Summary#2 of issues on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
R1-2208179 Correction on CD-SSB frequency indication using NCD-SSB in TS 38.213 Moderator (Intel Corporation)
Agreement
Endorse the TP below for TS38.213
----- Start of TP -----
13 UE procedure for monitoring Type0-PDCCH CSS sets
<Unchanged parts are omitted>
If
a UE detects a first SS/PBCH block and determines that a CORESET for
Type0-PDCCH CSS set is not present, and for 
for FR1 or
for 
for FR2, the
UE may determine the nearest (in the corresponding frequency direction) global
synchronization channel number (GSCN) of a second SS/PBCH block having a
CORESET for an associated Type0-PDCCH CSS set as 
. 
is the GSCN
of the first SS/PBCH block, 
in FR1
and FR2-1, 
3 in FR2-2,
and 
is a GSCN
offset provided by Table 13-16 for FR1 and Table 13-17 for FR2. If the UE
detects the second SS/PBCH block and the second SS/PBCH block does not provide
a CORESET for Type0-PDCCH CSS set, as described
in clause 4.1, the
UE
may ignore the information related to GSCN of SS/PBCH block locations for
performing cell search.
<Unchanged parts are omitted>
----- End of TP -----
Final CR (38.213, Rel-17, CR#0359, Cat F) is agreed in
R1-2208241 Correction on CD-SSB frequency indication using NCD-SSB in TS 38.213 Moderator (Intel Corporation), Samsung, ZTE, Sanechips
R1-2206083 Correction on the subcarrier offset k_SSB in TS 38.211 ZTE, Sanechips
R1-2206084 Correction on the tables for determining PDCCH monitoring occasions in TS 38.213 ZTE, Sanechips
Agreement
· TP for TS38.211 in R1-2206083 and TP for TS38.213 in R1-2206084 are endorsed.
Final CRs are agreed in
R1-2208033 Correction on the tables for determining Type0 PDCCH monitoring occasions Moderator (Intel Corporation), ZTE, Sanechips
(38.213, Rel-17, CR#0337, Cat F)
R1-2208034 Correction on the subcarrier offset, kssb Moderator (Intel Corporation), ZTE, Sanechips
(38.211, Rel-17, CR#0100, Cat F)
R1-2205769 Corrections on HARQ codebook generation for 52-71GHz spectrum Huawei, HiSilicon
R1-2206160 Correction on Type-1 HARQ-ACK codebook determination in TS 38.213 Fujitsu
R1-2206535 Discussion on Type-2 HARQ-ACK CB generation when both of spatial bundling and time bundling are configured Intel Corporation
R1-2206536 [draft CR] Correction on Type-2 HARQ-ACK CB generation when both of spatial bundling and time bundling are configured Intel Corporation
R1-2206736 Correction on division of TBGs for Type-2 codebook vivo
R1-2206737 Correction on time domain bundling with spatial bundling for Type-2 codebook vivo
R1-2206738 Remaining issues on Type-2 codebook for multi-PDSCH scheduling vivo
R1-2207027 Draft CR for type-1 HARQ-ACK codebook for multi-PDSCH scheduling LG Electronics
R1-2207269 Draft CR for spatial HARQ-ACK bundling for type-2 codebook with multi-PDSCH scheduling Nokia, Nokia Shanghai Bell
R1-2207717 On spatial HARQ-ACK bundling for type-2 codebook with multi-PDSCH scheduling Nokia, Nokia Shanghai Bell (rev of R1-2207608)
R1-2207724 Summary #1 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
R1-2207794 Discussion Summary #1 of Beam Management for New SCSs Moderator (InterDigital, Inc.)
R1-2208026 Summary #2 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
Agreement
· Proposal 2 in section 3 of R1-2208026 is endorsed, with deletion of “if applicable”.
Final CR (38.213, Rel-17, CR#0349, Cat F) is agreed in:
R1-2208154 Correction on Type-2 HARQ CB generation when both of spatial bundling and time bundling are configured Moderator (LG Electronics), vivo, Fujitsu, ZTE, Huawei, InterDigital, Intel
Agreement
· Proposal 3 in section 4 of R1-2208026 is endorsed.
Final CR (38.213, Rel-17, CR#0350, Cat F) is agreed in:
R1-2208155 Correction on Type-2 HARQ CB generation when time bundling is configured but spatial bundling is not configured Moderator (LG Electronics), vivo, Fujitsu, ZTE, InterDigital, Intel
Agreement
· TP#J in section 7.10 of R1-2208026 is provided to the specifications editors for their alignment CRs.
R1-2207722 FL summary#1 on CRs submitted to Rel-17 60GHz band channel access aspect Moderator (Qualcomm)
R1-2207723 FL summary#2 on CRs submitted to Rel-17 60GHz band channel access aspect Moderator (Qualcomm)
R1-2208006 FL summary#3 on CRs submitted to Rel-17 60GHz band channel access aspect Moderator (Qualcomm)
Agreement
For FR2-2,
R1-2208213 Draft CR on ChannelAccess-Cpext in Fallback DCI Moderator (Qualcomm)
Agreement
Endorse the draft CR for TS38.212 R1-2208213 with the following changes:
· Delete: “If agreement is reached” in the reason for change
· Change “in FR2-2 if ChannelAccessMode-r17 is provided” to “if ChannelAccessMode2-r17 is provided for operation in a cell in frequency range 2-2”
Final CR (38.212, Rel-17, CR#0118, Cat F) is agreed in:
R1-2208244 CR on ChannelAccess-Cpext in Fallback DCI Qualcomm Incorporated
MCC: Sourcing to be updated to Moderator (Qualcomm)
R1-2208214 Draft CR on ChannelAccess-Cpext in RAR UL Grant Moderator (Qualcomm)
Decision: Comeback at the next meeting for the final CR to TS38.213 corresponding to the agreement above.
Proposal 10-4
The following TP is agreed for TS37.213.
When a gNB/UE(s) is
required by regulations to sense a channel(s) for availability for performing
transmission(s) on the channel(s) or when a gNB provides UE(s) with higher
layer parameters channelAccessMode2-r17 by SIB1 or dedicated configuration
indicating that the channel access procedures would be performed by UE before
transmission(s) on a channel(s), the channel access procedures described in
this clause for accessing the channel(s) on which the transmission(s) are
performed by the gNB/UE(s), are applied.
· Send LS to RAN2 to ask RAN2 to implement in their specs that in region where LBT is mandated, the parameter channelAccessMode2-r17 is expected to be configured.
R1-2208230 Draft LS on condition to apply channel access procedure OPPO
Decision: The draft LS is endorsed. Final version is approved in R1-2208231.
Post meeting
[Post-110-R17-FR2_2] Email endorsement of CR on channel sensing in FR2-2
R1-2208215 Corrections to the conditions for channel sensing in FR2-2 in TS37.213 Moderator (Qualcomm), Huawei, HiSilicon
Decision: As per email decision posted on Sept 1st, the draft CR is endorsed with the following modification on “summary of changes”:
- Delete the “UE” from the condition of “When a gNB/UE(s) is required by regulations to sense a channel(s) for availability” and add “by UE” in the condition of “when a gNB provides UE(s) with higher layer parameters channelAccessMode2-r17” in Clause 4.4 of TS 37.213 v17.2.0
Final CR (Rel-17, 37.213, CR#0035r1, Cat F) is agreed in:
R1-2208309 Corrections to the conditions for channel sensing in FR2-2 in TS37.213 Moderator (Qualcomm), Huawei, HiSilicon, Ericsson
R1-2206085 Correction on a reference SCS configuration for co-DurationList in TS 38.213 ZTE, Sanechips
Agreement
· Endorse the draft CR R1-2206085.
Final CR (38.213, Rel-17, CR#0348, Cat F) is agreed in:
R1-2208112 Correction on a reference SCS configuration for co-DurationList in TS 38.213 Moderator (Qualcomm), ZTE, Sanechips
Final summary in:
R1-2208198 FL summary#4 on CRs submitted to Rel-17 60GHz band channel access aspect Moderator (Qualcomm)
R1-2210679 Session notes for 8.2 (Maintenance on Supporting NR from 52.6GHz to 71 GHz) Ad-Hoc Chair (Huawei)
[110bis-e-R17-FR2-2-01] – Jing (Qualcomm)
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-2210392 Summary of preparation phase email discussion for maintenance of NR in 52.6 to 71GHz band Moderator (Qualcomm)
Decision: As per email decision posted on Oct 12th,
Conclusion of [110bis-e-R17-FR2-2-01]:
For Rel-17 maintenance, the following the issues described in R1-2210392 are to be handled at RAN1#110bis-e:
· For initial access aspect: IA-1
· For PDCCH aspect: PDCCH-2, PDCCH-4, PDCCH-1 (incl. whether this should be handled in UE features)
· For PUCCH aspect: PUCCH-1 (as recommendation for editor’s alignment CR)
· For RS and timeline aspect: RS-1, RS-2. Additionally RS-3 (as recommendation for editor’s alignment CR)
· For scheduling and HARQ: HARQ-1-1, HARQ-1-2, HARQ-2, HARQ-3, HARQ-4, HARQ-5, HARQ-6. Additionally HARQ-7 (as recommendation for editor’s alignment CR)
· For beam management aspect: BM-1
· For channel access aspect: CA-1, CA-2, CA-3, CA-4, CA-6. Additionally CA-10 and CA-11 (as recommendation for editor’s alignment CR)
From AI 5
/To be handled using NWM – please use 110bis-e-NWM-R17-FR2-2-02 as the document name
R1-2208349 LS reply on TCI assumption for RSSI measurement for FR2-2 RAN4, Apple
[110bis-e-R17-FR2-2-02] – Hong (Apple)
Email discussion on RAN4 LS in R1-2208349 by October 14
R1-2210568 FL summary #1 on TCI assumption for RSSI measurement for FR2-2 Moderator (Apple)
Decision: As per email decision posted on Oct 15th,
Agreement
For RAN4 LS in R1-2208349, the following response is agreed:
· When a UE has no serving cell in FR2-2, the UE does not expect that a TCI-state is provided in RMTC-Config for inter-frequency RSSI measurement on FR2-2.
· For a UE that has no serving cell in FR2-2 and configured with inter-frequency RSSI measurement in FR2-2, it is up to UE implementation how to determine the spatial domain filter for the inter-frequency RSSI measurement in FR2-2.
R1-2210569 {Draft] Reply LS on TCI assumption for RSSI measurement for FR2-2 Apple
Decision: As per email decision posted on Oct 19th, the draft LS is endorsed. Final LS is approved in R1-2210590.
R1-2209436 Draft CR for indicating GSCN ranges where CD-SSB does not exist using NCD-SSB in FR2-2 LG Electronics
R1-2209437 Discussion on how to indicate GSCN ranges where CD-SSB does not exist using NCD-SSB in FR2-2 LG Electronics
[110bis-e-R17-FR2-2-03] – Daewon (Intel)
Email discussion for maintenance on initial access aspects for FR2-2 for issue IA-1 in R1-2210392
- Check points: October 14, October 19
R1-2210347 Summary of issues on initial access aspect of NR extension up to 71 GHz Moderator (Intel Corporation)
Decision: As per email decision posted on Oct 15th,
Conclusion
· No consensus on TP#1-1 in R1-2210347. The draft CR in R1-2209436 is not pursued in Rel-17.
R1-2208710 Draft CR on multi-slot PDCCH monitoring for TS 38.213 ZTE, Sanechips
R1-2208931 Discussion corrections for BD/CCE budge of scheduling cell(s) for the features extending NR operation to 71 GHz CATT
R1-2208932 Correction on BD/CCE budge of scheduling cell(s) for the features extending NR operation to 71 GHz CATT
R1-2208933 Correction on the total serving cell(s) number when r17monitoringcapability of monitoringCapabilityConfig is configured for the features extending NR operation to 71 GHz CATT
R1-2208936 Discussion on PDCCH monitoring occasion for DCI format 2_1 for the features extending NR operation to 71 GHz CATT
R1-2208937 CR for PDCCH monitoring occasion for DCI format 2_1 for the features extending NR operation to 71 GHz CATT
R1-2209177 Draft CR on Group 2 search space configuration Ericsson
R1-2209178 Discussion on Group 2 search space configuration Ericsson
R1-2209438 Draft CR for SSSG switching with multiple cells in FR2-2 LG Electronics
R1-2209439 Discussion on SSSG switching with multiple cells in FR2-2 LG Electronics
[110bis-e-R17-FR2-2-04] – Alex (Lenovo)
Email discussion for maintenance on PDCCH monitoring enhancements for FR2-2 for issues PDCCH-2, PDCCH-4 and PDCCH-1 (incl. whether this should be handled in UE features) in R1-2210392
- Check points: October 14, October 19
R1-2210409 FL Summary for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
From Oct 12th GTW session
Agreement
Capture in TS38.213 the description on the number of slots for multi-slot PDCCH monitoring for Group (2) search spaces, according to the past RAN1 agreement.
R1-2210458 FL summary #1 for email discussion [110bis-e-R17-FR2-2-04] on PDCCH monitoring enhancements Moderator (Lenovo)
Decision: As per email decision posted on Oct 15th,
Agreement
· The draft CR in R1-2209438 is endorsed in principle.
R1-2210543 Correction for SSSG switching with multiple cells in FR2-2 Moderator (Lenovo), LG Electronics
Decision: (TS38.213, Rel-17, CR#0374, Cat F) is agreed.
R1-2210459 FL summary #2 for email discussion [110bis-e-R17-FR2-2-04] on PDCCH monitoring enhancements Moderator (Lenovo)
Decision: As per email decision posted on Oct 19th, the 3 following draft CRs are endorsed in principle:
· R1-2210539 Correction for multi-slot PDCCH monitoring in FR2-2 Moderator (Lenovo, ZTE, Sanechips, Ericsson)
o Final CR (TS38.213, Rel-17, CR#0372, Cat F) is agreed in R1-2210540.
· R1-2210541 Correction for BD/CCE budget of scheduling cell(s) in FR2-2 Moderator (Lenovo), CATT
o Final CR (TS38.213, Rel-17, CR#0373, Cat F) is agreed in R1-2210542.
· R1-2210642 Correction on BD/CCE decoding with release-specific number of serving cell(s) for NR operation in FR2-2 Moderator (Lenovo), CATT, Huawei, Ericsson
o Final CR (TS38.213, Rel-17, CR#0382, Cat F) is agreed in R1-2210643.
R1-2208596 Correction on the parameter indicating the number of PRBs for common PUCCH vivo
[110bis-e-R17-FR2-2-05] – Steve (Ericsson)
Email discussion for maintenance for PUCCH formats 0/1/4 for FR2-2 for issue PUCCH-1 in R1-2210392
- Until October 14
R1-2210328 FL Summary for AI 8.2 – Enhancements for PUCCH Formats 0/1/4 Moderator (Ericsson)
Decision: As per email decision posted on Oct 15th,
For alignment TS38.213 CR:
· Text proposal provided in R1-2208596 is endorsed for the editorial corrections.
Final summary in:
R1-2210462 FL Summary#2 for AI 8.2 – Enhancements for PUCCH Formats 0/1/4 Moderator (Ericsson)
R1-2208708 Correction on frequency resource for CSI-RS for tracking in TS 38.214 ZTE, Sanechips
R1-2208709 Correction on UE PUSCH preparation procedure time in TS 38.214 ZTE, Sanechips
R1-2209440 Draft CR for RRC parameter to disable DMRS FD-OCC in FR2-2 LG Electronics
[110bis -e-R17-FR2-2-06] - Huaming (vivo)
Email discussion for maintenance on RS and timeline for FR2-2 for issues RS-1, RS-2, and RS-3 (as recommendation for editor’s alignment CR) in R1-2210392
- Check points: October 14, October 19
R1-2210395 FL summary #1 of PDSCH/PUSCH enhancement (RS and timeline) Moderator (vivo)
Decision: As per email decision posted on Oct 15th,
Agreement
· The draft CR in R1-2208708 is endorsed in principle.
Final CR (TS38.214, Rel-17, CR#0351, Cat F) is agreed in:
R1-2210583 Correction on frequency resource for CSI-RS for tracking in TS 38.214 Moderator (vivo), ZTE, Sanechips
Agreement
· The draft CR in R1-2208709 is endorsed in principle.
Final CR (TS38.214, Rel-17, CR#0352, Cat F) is agreed in:
R1-2210584 Correction on UE PUSCH preparation procedure time for operation with shared spectrum channel access in FR2-2 in TS 38.214 Moderator (vivo), ZTE, Sanechips
For alignment TS38.214 CR:
· Text proposal provided in R1-2209440 is endorsed for the editorial corrections.
R1-2208464 Discussion on the type 1 HARQ codebook generation for multiple PDSCH scheduling Huawei, HiSilicon
R1-2208597 Correction on generation of Type-1 codebook with time domain bundling vivo
R1-2208598 Correction on RRC parameters for time domain bundling of HARQ-ACK for multi-PDSCH scheduling in TS38.213 vivo
R1-2209006 Correction on Type-1 HARQ-ACK codebook determination in TS 38.213 Fujitsu
R1-2209007 Discussion on Type-1 HARQ-ACK codebook Fujitsu
R1-2209441 Draft CR for type-1 HARQ-ACK codebook when time domain bundling is configured LG Electronics
R1-2209442 Discussion on type-1 HARQ-ACK codebook when time domain bundling is configured LG Electronics
R1-2209443 Draft CR on RRC parameters for HARQ-ACK time domain bundling LG Electronics
R1-2209694 Discussion on multi-PDSCH/PUSCH scheduling by a single DCI Samsung
R1-2209695 Draft CR to support up to 32 HARQ process numbers Samsung
R1-2209696 Draft CR for ZP CSI-RS rate-matching Samsung
R1-2209870 Draft CR on DL PDSCH validity for multi-PDSCH scheduling via single DCI mTRP in FR2-2 NTT DOCOMO, INC.
R1-2209871 Discussion on remaining issues for NR in FR2-2 NTT DOCOMO, INC.
R1-2210220 Corrections on TDRA for multiple PUSCH scheduling in TS38.214 Huawei, HiSilicon
R1-2210221 Corrections on TDRA for multiple PUSCH scheduling in TS38.212 Huawei, HiSilicon
[110bis -e-R17-FR2-2-07] - Seonwook (LGE)
Email discussion for maintenance on scheduling/HARQ for FR2-2 for issues HARQ-1-1, HARQ-1-2, HARQ-2, HARQ-3, HARQ-4, HARQ-5, HARQ-6, and HARQ-7 (as recommendation for editor’s alignment CR) in R1-2210392
- Check points: October 14, October 19
R1-2210270 Summary #1 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
R1-2210363 Summary #2 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
From Oct 12th GTW session
Agreement
For multi-PDSCH scheduling DCI,
bits,
where I is the number of entries in the higher layer parameter TimeDomainAllocationListForMultiPDSCH.Comeback to check draft LS – Seonwook (LGE)
R1-2210460 DRAFT LS to RAN2 on RRC parameter impact for multi-PDSCH scheduling Moderator (LG Electronics)
Decision: As per email decision posted on Oct 17th, the draft LS to RAN2 is endorsed. Final LS is approved in R1-2210591.
Agreement
For pseudo code of type-1 HARQ-ACK codebook generation when time domain bundling is configured, adopt interpretation 2:
·
Interpretation 2: “a PDSCH associated with
occasion 
”is a
PDSCH of which the corresponding HARQ-ACK information is mapping to occasion 
· Further discuss whether there is specification impact, if so discuss the corresponding TP.
R1-2210457 Summary #3 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
Decision: As per email decision posted on Oct 15th,
Agreement
For alignment TS38.212 CR:
· Text proposal provided TP#G in section 11.7 of R1-2210457 for RRC parameter corrections is endorsed for the editorial corrections.
For alignment TS38.213 CR:
· Text proposal provided in R1-2208598 for RRC parameter corrections is endorsed for the editorial corrections.
For alignment TS38.214 CR:
· Text proposal provided in Draft CR3 in Appendix of R1-2209694 for RRC parameter corrections is endorsed for the editorial corrections.
R1-2210603 Correction to support up to 32 HARQ process numbers for FR2-2 Moderator (LG Electronics), Samsung, ZTE
Decision: As per email decision posted on Oct 18th, draft CR is endorsed. Final CR is agreed in R1-2210604 (TS38.212, Rel-17, CR#0126, Cat F).
R1-2210605 Correction on ZP CSI-RS rate-matching for multi-PDSCH scheduling Moderator (LG Electronics), Samsung, ZTE
Decision: As per email decision posted on Oct 18th, draft CR is endorsed. Final CR is agreed in R1-2210606 (TS38.214, Rel-17, CR#0354, Cat F).
R1-2210607 Correction on TDRA for multiple PUSCH scheduling in TS 38.214 Moderator (LG Electronics), Huawei, HiSilicon, ZTE
Decision: As per email decision posted on Oct 18th, draft CR is endorsed. Final CR is agreed in R1-2210608 (TS38.214, Rel-17, CR#0355, Cat F).
R1-2210609 Correction on TDRA for multiple PUSCH scheduling in TS 38.212 Moderator (LG Electronics), Huawei, HiSilicon, ZTE
Decision: As per email decision posted on Oct 18th, draft CR is endorsed. Final CR is agreed in R1-2210610 (TS38.212, Rel-17, CR#0127, Cat F).
R1-2210594 Summary #4 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
Decision: As per email decision posted on Oct 19th,
Agreement
· TP#D1 (for Issue #5) in R1-2210594, is endorsed in principle.
R1-2209818 Corrections on Type 1 HARQ codebook generation in TS38.213 Huawei, HiSilicon
Decision: As per email decision posted on Oct 19th, considering the different views on issue#1-1, the draft CR in R1-2209818 is not pursued in Rel-17.
Corresponding draft CR for issue #5:
R1-2210766 Correction on DL PDSCH validity for multi-PDSCH scheduling via single DCI mTRP in FR2-2 Moderator (LG Electronics), NTT DOCOMO
Decision: As per email decision posted on Oct 19th, draft CR is endorsed. Final CR is agreed in R1-2210767 (TS38.214, Rel-17, CR#0367, Cat F).
Conclusion
The “if the PDSCH is associated with the last SLIV in the TDRA row” in TS 38.213, clause 9.1.2.1, is always satisfied.
Conclusion
For the case where a DCI format schedules more than one PDSCH and only one scheduled PDSCH does not overlap with an uplink symbol indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated, ojACK = HARQ-ACK information bit corresponding to TB(s) of the only one PDSCH.
R1-2208680 Remaining issues for NR 52.6 GHz to 71 GHz InterDigital, Inc.
R1-2208681 Corrections on a minimum guard period between two SRS resources for antenna switching InterDigital, Inc.
R1-2209005 Correction on minimum guard period Y between two SRS resources of an SRS resource set for antenna switching Fujitsu
R1-2209179 Draft CR on minimum guard period between SRS resources Ericsson
R1-2209180 Discussion on minimum guard period between SRS resources Ericsson
R1-2209821 Corrections on SRS switching gap for 480/960KHz SCS for 52-71GHz spectrum Huawei, HiSilicon
R1-2209869 Draft CR on SRS for DL CSI acquisition in FR2-2 NTT DOCOMO, INC.
R1-2209871 Discussion on remaining issues for NR in FR2-2 NTT DOCOMO, INC.
[110bis-e-R17-FR2-2-08] – Youngwoo (InterDigital)
Email discussion for maintenance on beam management for new SCSs for FR2-2 for issue BM-1 in R1-2210392
- Check points: October 14, October 19
R1-2210313 Discussion Summary #1 of Beam Management for New SCSs Moderator (InterDigital, Inc.)
From Oct 12th GTW session
Agreement
· Agree on the following TP for TS38.214
|
6.2.1.2 UE sounding procedure for DL CSI acquisition *** Unchanged text omitted *** For 1T2R, 1T4R or 2T4R, or 1T6R or 1T8R, 2T6R, 2T8R, 4T8R, the UE shall not expect to be configured or triggered with more than one SRS resource set with higher layer parameter usage set as 'antennaSwitching' in the same slot. For 1T=1R, 2T=2R or 4T=4R, the UE shall not expect to be configured or triggered with more than one SRS resource set with higher layer parameter usage set as 'antennaSwitching' in the same symbol. The value of Y is defined by Table 6.2.1.2-1. Table 6.2.1.2-1: The minimum guard period between two SRS resources of an SRS resource set for antenna switching
|
Continue discussion on the issue raised by Qualcomm in R1-2210313 at RAN1#110bis-e, for example how to handle aperiodic SRS resources with 7 and 14 symbol gap.
Decision: As per email decision posted on Oct 15th,
Conclusion
· There is no consensus to support additional specification enhancement for handling aperiodic SRS resources with 7 and 14 symbol gap.
Corresponding draft CR for the above agreement:
R1-2210663 Correction on a minimum guard period between two SRS resources for antenna switching Moderator (InterDigital, Inc.), Fujitsu, Ericsson, Huawei, HiSilicon, NTT DOCOMO, INC., Samsung, ZTE
Decision: As per email decision posted on Oct 18th, draft CR is endorsed. Final CR is agreed in R1-2210705 (TS38.214, Rel-17, CR#0363, Cat F).
Final summary in R1-2210471.
R1-2208463 Remaining issues of channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
R1-2208476 Corrections to multi beam channel access in TS37.213 Huawei, HiSilicon
R1-2208477 Corrections to channel access field in RAR UL grant in FR2-2 in TS38.213 Huawei, HiSilicon
R1-2208594 Correction on the short control signaling constraint vivo
R1-2208595 Correction on the indication of channel access Types vivo
R1-2208704 Correction on on ChannelAccess-Cpext in RAR UL Grant in TS 38.213 ZTE, Sanechips
R1-2208705 Clarification on Contention Exempt Short Control Signalling rules for UL in TS 37.213 ZTE, Sanechips
R1-2208826 Discussion on remaining issue short control signaling OPPO
R1-2208827 Draft CR on resolving issue for short control signaling OPPO
R1-2208934 Discussion on channel access procedures upon detection of a common DCI for frequency range 2-2 CATT
R1-2208935 Correction on channel access procedures upon detection of a common DCI for frequency range 2-2 CATT
R1-2209031 Discussion on Applicability of the Short Control Signalling Exemption Intel Corporation
R1-2209032 [draft] correction for short control signaling LBT exemption applicability in TS 37.213 Intel Corporation
R1-2209250 Correction on the bit length of ChannelAccess-CPext-CAPC field in DCI 0-1 and DCI 1-1 for FR 2-2 xiaomi
R1-2209430 Remaining issues on channel access mechanism Nokia, Nokia Shanghai Bell
R1-2209432 Correction on ChannelAccess-Cpext field in random access response Nokia, Nokia Shanghai Bell
R1-2209444 Remaining issues of channel access mechanism to support NR above 52.6 GHz LG Electronics
R1-2209445 Draft CR for multi-beam channel access procedure in FR2-2 LG Electronics
R1-2209446 Discussion on multi-beam channel access procedure in FR2-2 LG Electronics
R1-2209447 Draft CR on channel access indication for RAR grant in FR2-2 LG Electronics
R1-2209692 Draft CR for ChannelAccess-Cpext in RAR UL grant in FR2-2 Samsung
R1-2209693 Draft CR for multi-beam channel access procedure in FR2-2 Samsung
R1-2209819 Corrections to ED threshold for use with Type 2 channel access procedure in FR2-2 in TS37.213 Huawei, HiSilicon
R1-2209845 Corrections to per-beam ED threshold for multi-beam COT in FR2-2 in TS37.213 Huawei, HiSilicon
R1-2209868 Draft CR on spatial domain filter for sensing in FR2-2 NTT DOCOMO, INC.
R1-2209940 Draft CR on unified short control signaling exemption and channel access type upgrade Qualcomm Incorporated
R1-2209941 Draft CR on ChannelAccess-Cpext field in UL RAR grant Qualcomm Incorporated
R1-2209942 Draft CR on UL transmission with LBT per sensing beam Qualcomm Incorporated
R1-2209943 Draft CR on EDT determination rule for COT with SDM or TDM transmission with per beam LBT Qualcomm Incorporated
R1-2209944 Discussion paper on Maintenance for NR from 52.6GHz to 71 GHz Qualcomm Incorporated
R1-2210053 Correction on UE resuming a UE initiated COT Nokia, Nokia Shanghai Bell
R1-2210055 Correction on Short Control Signaling Nokia, Nokia Shanghai Bell
R1-2210094 Correction on CSI-RS validation ASUSTeK
R1-2210135 Remaining issue on channel access for NR from 52.6GHz to 71GHz WILUS Inc.
R1-2210136 Draft CR on channel access after failure of Type 2 channel access for FR2-2 WILUS Inc.
R1-2210137 Draft CR on channel access procedure upon detection of a common DCI for FR2-2 WILUS Inc.
R1-2210168 Draft CR on channel access type indication in non-fallback DCI NTT DOCOMO, INC.
[110bis-e-R17-FR2-2-09] – Jing (Qualcomm)
Email discussion for maintenance on channel access mechanism for FR2-2 for issues CA-1, CA-2, CA-3, CA-4, CA-6 in R1-2210392. Issues CA-10 and CA-11 in R1-2210392 to be discussed as recommendation for editor’s alignment CR
- Check points: October 14, October 19
R1-2210391 FL Summary on Maintenance of Channel Access Mechanisms for NR in 52.6 to 71GHz band Moderator (Qualcomm)
R1-2210393 Summary#1 on email discussion on maintenance of channel access for NR in 52.6 to 71GHz band Moderator (Qualcomm)
Agreement
· The TP 2-1B in section 2.1 of R1-2210393 is endorsed.
· Corresponding draft CR in
R1-2210531 Correction for ChannelAccess-Cpext in RAR UL grant in FR2-2 Qualcomm (Moderator), Samsung, LG Electronics, DoCoMo, Huawei/HiSilicon, ZTE/Sanechips
Decision: As per email decision posted on Oct 19th, draft CR is endorsed in principle. Final CR is agreed in R1-2210532 (TS38.213, Rel-17, CR#0370, Cat F).
Agreement
· TP 2-2B below is endorsed
==== Start of TP 2-2B for 38.212 ====
7.3.1.1.2 Format 0_1
<Unchanged Part Omitted>
- ChannelAccess-CPext-CAPC – 0, 1, 2, 3, 4, 5 or 6 bits.
The bitwidth for this field is determined as 
bits, where I is the number of entries in the higher layer parameter ul-AccessConfigListDCI-0-1 or in Table
7.3.1.1.1-4A if channelAccessMode-r16 = "semiStatic" is
provided, for operation in
a cell with shared spectrum channel access in frequency
range 1, or for operation in frequency range 2-2 if ChannelAccessMode2-r17
is provided;
otherwise 0 bit. One or more entries from Table 7.3.1.1.2-35 or Table 7.3.1.1.2-35A are configured by the higher layer
parameter ul-AccessConfigListDCI-0-1.
<Unchanged Part Omitted>
7.3.1.2.2 Format 1_1
<Unchanged Part Omitted>
-
ChannelAccess-CPext – 0, 1, 2, 3
or 4 bits. The bitwidth for this field is determined as bits, where I is the
number of entries in the higher layer
parameter ul-AccessConfigListDCI-1-1 or in Table
7.3.1.1.1-4A if channelAccessMode-r16 = "semiStatic" is
provided, for operation in a cell with shared spectrum channel access in frequency
range 1, or for operation in frequency range 2-2 if ChannelAccessMode2-r17
is provided; otherwise 0 bit. One or more entries from
Table 7.3.1.2.2-6 or Table 7.3.1.2.2-6A
are configured by the higher layer parameter ul-AccessConfigListDCI-1-1.
<Unchanged Part Omitted>
==== End of TP 2-2B for 38.212 ====
R1-2210533 Correction on channel access type indication in non-fallback DCI Moderator (Qualcomm), NTT DOCOMO, Huawei, HiSilicon, ZTE, Sanechips
Decision: As per email decision posted on Oct 19th, draft CR is endorsed in principle. Final CR is agreed in R1-2210534 (TS38.212, Rel-17, CR#0125, Cat F).
Agreement
· Endorse the TP below for TS38.214
5.1.5 Antenna ports quasi co-location
<Unchanged Part Omitted>
A UE that has indicated a capability beamCorrespondenceWithoutUL-BeamSweeping set to '1', as described in [13, TS 38.306], can determine a spatial domain filter to be used while performing the applicable channel access procedures described in [16, TS 37.213] prior to a UL transmission on the channel as follows:
- if UE is indicated with an SRI corresponding to the UL transmission, the UE may use a spatial domain filter that is same as the spatial domain transmission filter associated with the indicated SRI,
- if UE is configured with SRS-spatialRelationInfo for the UL transmission, the UE may use a spatial domain filter that is same as the spatial domain filter associated with referenceSignal in the corresponding SRS-spatialRelationInfo
- if UE is configured with TCI-State configurations with DLorJointTCIState or UL-TCIState, the UE may use a spatial domain transmit filter that is same as the spatial domain receive filter the UE may use to receive the DL reference signal associated with the indicated TCI state.
<Unchanged Part Omitted>
==== End of TP ====
R1-2210535 Correction on spatial domain filter for sensing for SRS transmission in FR2-2 Moderator (Qualcomm), NTT DOCOMO, Huawei, HiSilicon, ZTE, Sanechips
Decision: As per email decision posted on Oct 19th, draft CR is endorsed in principle. Final CR is agreed in R1-2210536 (TS38.214, Rel-17, CR#0347, Cat F).
Comeback on TP for TS38.213 for related changes to PUCCH – Jing (Qualcomm).
R1-2210537 Correction on spatial domain filter for sensing for PUCCH transmission in FR2-2 Moderator (Qualcomm), NTT DOCOMO, Nokia, Nokia Shanghai Bell, Huawei, HiSilicon, ZTE, Sanechips
Decision: As per email decision posted on Oct 19th, draft CR is endorsed in principle. Final CR is agreed in R1-2210538 (TS38.213, Rel-17, CR#0371, Cat F).
R1-2208706 Alignment CR on the parameter names in TS 38.213 ZTE, Sanechips
R1-2208707 Alignment CR on the parameter names in TS 38.214 ZTE, Sanechips
R1-2208828 Draft CR on editorial correction for higher-layer parameter setting OPPO
Decision: As per email decision posted on Oct 15th,
For alignment TS38.214 CR:
· Text proposal provided in R1-2208828 is endorsed for the editorial corrections.
For alignment TS38.213 CR:
· Text proposal provided in R1-2208706 is endorsed for the editorial corrections.
Note: the same change may need to be applied for Rel.16 spec as well.
MCC post meeting: the proposed second editorial correction is for a Rel-16 parameter introduced by Rel-16 NR-U, therefore WI code NR_unlic should be used for Rel-16 CR; as well for Rel-17 mirrored CR
For alignment TS38.214 CR:
· Text proposal provided in R1-2208707 is endorsed for the editorial corrections.
Note: the same change may need to be applied for Rel.16 spec as well.
MCC post meeting: the proposed editorial correction is for a Rel-16 parameter introduced by Rel-16 NR-U, therefore WI code NR_unlic should be used for Rel-16 CR; as well for Rel-17 mirrored CR
Decision: As per email decision posted on Oct 19th,
Conclusion
When independent per-beam LBT sensing is performed at UE, whether a transmission is allowed to occur on a subset of beams, where all of the corresponding LBT procedures for the subset of beams have been successful, is left for UE implementation.
· FFS spec impact, if any
Conclusion
Conclude that when independent per-beam LBT sensing is performed at UE, EDT determination is not further optimized in Rel-17.
· No spec impact expected
Final summary in R1-2210394.
R1-2212832 Session notes for 8.2 (Maintenance on Supporting NR from 52.6GHz to 71 GHz) Ad-Hoc Chair (Huawei)
Endorsed and contents incorporated below.
[111-R17-FR2_2] – Jing (Qualcomm)
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-2212585 Preparation phase discussion summary for FR2-2 maintenance Moderator (Qualcomm)
Maintenance on PDCCH monitoring enhancements for FR2-2
R1-2212434 FL Summary for B52.6 GHz PDCCH monitoring enhancements Moderator (Lenovo)
PDCCH monitoring occasion for DCI format 2_1 (issue PDCCH-1 in R1-2212434)
R1-2211156 Discussion on the correction for PDCCH monitoring occasion for DCI format 2_1 for the features extending NR operation to 71 GHz CATT
R1-2211157 Correction for PDCCH monitoring occasion for DCI format 2_1 for the features extending NR operation to 71 GHz CATT
Conclusion:
PDCCH monitoring relaxations are not supported for DCI format 2_1 for a UE configured with monitoringSlotsWithinSlotGroup with 480/960 kHz.
Definition of configured DL-CCs number for BD/CCE budget (issue PDCCH-2 in R1-2212434)
R1-2211158 Discussion on the corrections of the definition of configured DL-CCs number for BD/CCE budget of scheduling cell(s) for the features extending NR operation to 71 GHz CATT
R1-2211159 Corrections of the definition of configured DL-CCs number for BD/CCE budget of scheduling cell(s) for the features extending NR operation to 71 GHz CATT
Agreement (Nov 15th session)
Draft CR R1-2211159 is endorsed in principle, with further discussion on whether the word “associated” should be deleted or the wording changed.
Agreement (Nov 16th session)
Draft CR R1-2211159 is endorsed without change.
Final CR (TS 38.213, Rel-17, CR#0425, Cat F) is agreed in:
R1-2212907 Correction of number of configured DL-CCs for BD/CCE budget for FR2-2 Moderator (Lenovo), CATT
Clarification of multi-slot monitoring in groups of slots (issue PDCCH-3 in R1-2212434)
R1-2211947 Discussion on per-slot group monitoring within a duration Ericsson
R1-2211948 Draft CR on per-slot group monitoring within a duration Ericsson
Agreement (Nov 15th session)
Draft CR R1-2211948 is endorsed in principle, with further discussion on revising the use of L to avoid confusion with other use of L in the specification
Agreement (Nov 16th session)
Draft CR R1-2211948 is endorsed with changing symbol 
to 
.
Final CR (TS 38.213, Rel-17, CR#0426, Cat F) is agreed in:
R1-2212908 Correction on per-slot group monitoring within a duration for FR2-2 Moderator (Lenovo), Ericsson
Maintenance on scheduling/HARQ for FR2-2
R1-2212588 Summary #1 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
R1-2212763 Summary #2 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
Last DCI determination for multi-PDSCH scheduling and single PDSCH scheduling in same MO (issue HARQ-1 in R1-2212763)
R1-2211635 Discussion on last DCI determination for multi-PDSCH scheduling and single PDSCH scheduling ZTE
R1-2212818 Summary #3 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
Conclusion
For type-2 HARQ-ACK codebook, gNB implementation can handle the case of the last DCI determination for PUCCH resource determination when multi-PDSCH scheduling is configured and two DCIs scheduling PDSCHs in the same scheduled cell are transmitted in the same monitoring occasion.
Frequency hopping for PUSCH and SRS in FR2-2 (issue HARQ-2 in R1-2212763)
R1-2211954 Draft CR on frequency hopping for PUSCH and SRS in FR2-2 NTT DOCOMO, INC.
Agreement
· Draft CR R1-2211954 is endorsed in principle.
Final CR (Rel-17, TS 38.214, CR#0375, Cat F) is agreed in:
R1-2212764 CR on frequency hopping for PUSCH and SRS in FR2-2 Moderator (LG Electronics), NTT DOCOMO, Ericsson
Final summary in R1-2212979.
Maintenance on beam management for new SCSs for FR2-2
R1-2212740 Discussion Summary #1 of Beam Management for New SCSs Moderator (InterDigital, Inc.)
Multi-PUSCH scheduling in unified TCI in FR2-2 (issue BM-1 in R1-2212740)
R1-2211956 Draft CR on multi-PUSCH scheduling in unified TCI in FR2-2 NTT DOCOMO, INC.
Conclusion
For Rel-17 unified TCI framework, the applied TCI states can be updated using unified TCI framework within the span of multi-PDSCH/PUSCH.
· No additional specification support is needed.
Maintenance on channel access mechanism for FR2-2
R1-2212586 FL summary for channel access mechanism of FR2-2 maintenance, ver 01 Moderator (Qualcomm)
R1-2212587 FL summary for channel access mechanism of FR2-2 maintenance, ver 02 Moderator (Qualcomm)
Control of SCSt based msg1/msgA transmission (issue CA-1 in R1-2212586)
R1-2210918 Remaining issues of channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
R1-2210970 Discussions on support of short control signaling in FR2-2 vivo
R1-2211166 Discussion on the remaining issues on channel access CATT
R1-2211273 Clarification on Contention Exempt Short Control Signalling rules for UL in TS 37.213 ZTE, Sanechips
R1-2211379 Discussions on remaining issues on Channel Access for NR extension up to 71 GHz Intel Corporation
R1-2211454 Discussion on remaining issue for short control signaling OPPO
R1-2211455 Draft CR on resolving issue for short control signaling OPPO
R1-2211944 Draft CR on configuration to enable LBT for msg1 and msgA Ericsson
R1-2211945 Discussion on configuration to enable LBT for msg1 and msgA Ericsson
R1-2211952 Discussion on remaining issues for NR in FR2-2 NTT DOCOMO, INC.
R1-2212019 Discussion on SCSt based msg1/msgA transmission in FR2-2 Samsung
R1-2212082 Discussion Paper on Maintenance for NR from 52.6GHz to 71 GHz Qualcomm Incorporated
R1-2212083 Draft CR on Short Control Signaling Exemption for UL Transmissions Qualcomm Incorporated
R1-2212296 Draft CR on channel access type indication for DCI format x_2 in FR2-2 LG Electronics
R1-2212297 Draft CR on short control signaling exemption and LBT type determination within a COT LG Electronics
R1-2212395 Correction on short control singnling based on msg1 and msg A CATT
R1-2212403 Remaining issues on channel access mechanism Nokia, Nokia Shanghai Bell
R1-2212404 Correction on Short Control Signaling Nokia, Nokia Shanghai Bell
R1-2212470 Corrections to enable/disable short control signaling transmission in TS37.213 Huawei, HiSilicon
Agreement
Introduce ra-ChannelAccess-r17 in SIB1 and other relevant RRC indicator fields (if needed) to control msg1/msgA transmission with and without LBT
· The TP CA-1-4 below is provided as an example of the expected RAN1 specification change.
· Send LS to RAN2 to request introducing ra-ChannelAccess-r17 in SIB1 and other relevant RRC indicator fields (if needed). If configured, indicating UE should perform LBT before msg1/msgA transmission. Ask RAN2 to confirm whether RAN2 is able to introduce this RRC change and confirm to RAN1.
· Note: gNB is responsible to configure the ra-ChannelAccess-r17 properly to comply with local regulation
====TP CA-1-4 for 37.213===============
4.4.5 Exempted transmissions from sensing
In regions where channel sensing is required to access a channel for transmission and short control signalling exemption is allowed by regulation, a gNB/UE may transmit the following transmission(s) on a channel without sensing the channel:
- Transmission(s) of the discovery burst by the gNB
- If the higher layer parameter ra-ChannelAccess-r17 is not configured, transmission(s) of the first message in a random access procedure by the UE
===End of TP CA-1-4======================
R1-2212964 DRAFT LS to RAN2 on msg1/msgA transmission channel access control in SIB1 Moderator (Qualcomm)
Decision: The draft LS in R1-2212964 is endorsed. Final LS is approved in R1-2212965.
Channel Access Type upgrade within gNB COT (issue CA-2 in R1-2212586)
R1-2210918 Remaining issues of channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
R1-2210970 Discussions on support of short control signaling in FR2-2 vivo
R1-2211166 Discussion on the remaining issues on channel access CATT
R1-2212396 Correction on UE resuming a UE initiated COT CATT
R1-2212437 Draft CR on channel access procedure upon detection of a common DCI for FR2-2 WILUS Inc.
R1-2212471 Corrections to support LBT upgrade to Type 2/3 within gNB COT in TS37.213 Huawei, HiSilicon
Channel Access Type for resuming UE COT after a gap (issue CA-3 in R1-2212586)
R1-2210918 Remaining issues of channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
R1-2211160 Discussion on channel access procedures upon detection of a common DCI for frequency range 2-2 CATT
R1-2211161 Correction on channel access procedures upon detection of a common DCI for frequency range 2-2 CATT
R1-2211166 Discussion on the remaining issues on channel access CATT
R1-2212403 Remaining issues on channel access mechanism Nokia, Nokia Shanghai Bell
R1-2212405 Correction on UE resuming a UE initiated COT Nokia, Nokia Shanghai Bell
Independent Per Beam LBT procedure in a multi-Beam COT (issue CA-4 in R1-2212586)
R1-2210918 Remaining issues of channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
R1-2211379 Discussions on remaining issues on Channel Access for NR extension up to 71 GHz Intel Corporation
R1-2212469 Corrections to multi beam channel access in TS37.213 Huawei, HiSilicon
DCI Format 0_2, 1_2 (issue CA-5 in R1-2212586)
R1-2212295 Remaining issues of channel access mechanism to support NR above 52.6 GHz LG Electronics
Exclude CSI-RS validation when in discovery burst (issue CA-6 in R1-2212586)
R1-2212198 Correction on CSI-RS validation ASUSTeK
PDCCH ordered PRACH (issue CA-7 in R1-2212586)
R1-2211952 Discussion on remaining issues for NR in FR2-2 NTT DOCOMO, INC.
R1-2211953 Draft CR on channel access type for PDCCH ordered PRACH in FR2-2 NTT DOCOMO, INC.
TCI State for L3-RSSI measurement (issue CA-8 in R1-2212586)
R1-2211946 Discussion on L3-RSSI measurements and LS to RAN4 Ericsson
Agreement
For intra-frequency and inter-frequency RSSI measurements for FR2-2, when a UE has a serving cell in FR2-2, the UE does not expect to be configured with an explicit TCI-state in RMTC-Config with a reference serving cell in FR1 or FR2-1.
· Send an LS to RAN4 regarding the understanding above in RAN1
R1-2212826 DRAFT LS to RAN4 on L3-RSSI measurement for NR up to 71GHz Moderator (Qualcomm)
Decision: The draft LS in R1-2212826 is endorsed with the following revisions:
· Add “to RAN2” in the title
· Add “To RAN2” in the action
Final LS is approved in R1-2212830.
Channel measurement and Interference Measurement subject to validation (issue CA-9 in R1-2212586)
R1-2211275 Correction on channel measurement and interference measurement in FR2-2 in TS 38.214 ZTE, Sanechips
Cg-minDFI-Delay in FR2-2 (issue CA-10 in R1-2212586)
R1-2211274 Correction on cg-minDFI-Delay in FR2-2 in TS 38.213 ZTE, Sanechips
Agreement
· Endorse draft CR in R1-2211274 as editorial for the editor’s alignment CR.
Channel Occupancy Duration maximum value (issue CA-11 in R1-2212586)
R1-2210918 Remaining issues of channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
Channel Access Procedure after failure of Type 2 channel access (issue CA-12 in R1-2212586)
R1-2212435 Remaining issue on channel access for NR from 52.6GHz to 71GHz WILUS Inc.
R1-2212436 Draft CR on channel access after failure of Type 2 channel access for FR2-2 WILUS Inc.
R1-2302052 Session notes for 8.2 (Maintenance on Supporting NR from 52.6GHz to 71 GHz) Ad-Hoc Chair (Huawei)
[112-R17-FR2_2] – Jing (Qualcomm)/Timo (Nokia)
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
Maintenance on PDCCH monitoring enhancements for FR2-2
R1-2301758 Corrections to r17 PDCCH monitoring capability for CA and DC in TS38.213 Huawei, HiSilicon
R1-2302092 FL summary on PDCCH monitoring for Rel.17 FR2-2 Maintenance Moderator (Lenovo)
Agreement
The draft CR in R1-2301758 is endorsed. The sentence “According to the latest spec of TS38.331,” in reason for change is deleted.
Final CR (Rel-17, 38.213,CR0448, Cat F) is agreed in
R1-2302143 Corrections to r17 PDCCH monitoring capability for CA and DC Moderator (Lenovo), Huawei, HiSilicon
Maintenance on RS and timeline for FR2-2
R1-2301750 Corrections to aperiodic CSI-RS timing for mixed numerologies configuration in TS38.214 Huawei, HiSilicon
R1-2301997 FL summary of PDSCH/PUSCH enhancement (RS and timeline) Moderator (vivo)
Agreement
Endorse the draft CR to TS38.214 in R1-2301750.
Final CR (Rel-17, 38.214,CR0396, Cat F) is agreed in
R1-2302110 Corrections to aperiodic CSI-RS timing for mixed numerologies configuration in TS38.214 Moderator (vivo), Huawei, HiSilicon
Maintenance on scheduling/HARQ for FR2-2
R1-2301857 Summary #1 of PDSCH/PUSCH enhancements (Scheduling/HARQ) Moderator (LG Electronics)
Issue#1: DCI size determination
R1-2301840 Discussion on DCI field sizes for multiple PxSCHs scheduled by single DCI Ericsson (rev of R1-2300910)
R1-2300911 Draft CR on DCI field sizes for multiple PxSCHs scheduled by single DCI Ericsson
R1-2302098 Draft CR on DCI field sizes for multiple PDSCHs scheduled by single DCI Moderator (LG Electronics)
Agreement
Endorse the draft CR to TS38.212 in R1-2302098.
Final CR (Rel-17, 38.212,CR0137, Cat F) is agreed in
R1-2302141 CR on DCI field sizes for multiple PDSCHs scheduled by single DCI Moderator (LG Electronics), Ericsson
MCC: To delete "draft" from CR title before submission to plenary.
Issue#2: PDCCH validation for SPS and CG Type 2
R1-2300640 Discussion on DL SPS & UL CG operation via DCI format 1_1&0_1 for the features extending NR operation to 71 GHz CATT
R1-2300641 Draft CR for DL SPS & UL CG operation via DCI format 1_1&0_1 for the features extending NR operation to 71 GHz CATT
R1-2301812 Draft CR on PDCCH validation for SPS and CG Type 2 Ericsson Inc. (rev of R1-2301527)
R1-2301840 Discussion on DCI field sizes for multiple PxSCHs scheduled by single DCI Ericsson (rev of R1-2300910)
R1-2302099 Draft CR on PDCCH validation for CG Type 2 Moderator (LG Electronics), Ericsson
Comeback on Thursday
Agreement
Endorse the draft CR to TS38.213 for Rel-16 in R1-2302099.
Note: No cat A as this CR was already implemented in Rel-17 specification (R1-2202949)
Final CR (Rel-17, 38.213,CR0451, Cat F) is agreed in
R1-2302183 CR on PDCCH validation for CG Type 2 Moderator (LG Electronics), Ericsson
Issue#3: K2 indication for multi-PUSCH scheduling DCI
R1-2300912 Discussion on K2 indication for multiple PUSCHs scheduled by single DCI Ericsson
R1-2300913 Draft CR on K2 indication for multiple PUSCHs scheduled by single DCI Ericsson
R1-2302100 Draft CR on K2 indication for multi-PUSCH scheduling DCI Moderator (LG Electronics), Ericsson
Agreement
Endorse the draft CR to TS38.214 in R1-2302100.
Final CR (Rel-17, 38.214,CR0399, Cat F) is agreed in
R1-2302142 CR on K2 indication for multi-PUSCH scheduling DCI Moderator (LG Electronics), Ericsson
MCC: To delete "draft" from CR title before submission to plenary.
R1-2302101 DRAFT LS to RAN2 on K2 indication for multi-PUSCH scheduling Moderator (LG Electronics)
Decision: The draft LS to RAN2 in R1-2302101 is endorsed. Final LS is approved in R1-2302144.
Issue#4: RRC parameters for multi-PXSCH scheduling
R1-2300498 Correction on RRC parameters for TDRA tables for multi-PXSCH scheduling in TS38.214 vivo
R1-2300642 Draft CR for editorial correction of pdsch-TimeDomainAllocationListForMultiPDSCH-r17 for the features extending NR operation to 71 GHz CATT
R1-2300914 Discussion on TCI state indication for multiple PDSCHs scheduled by single DCI Ericsson
R1-2300915 Draft CR on TCI state indication for multiple PDSCHs scheduled by single DCI Ericsson
R1-2300916 Discussion on TDRA for multiple PUSCHs scheduled by single DCI Ericsson
R1-2300917 Draft CR on TDRA for multiple PUSCHs scheduled by single DCI Ericsson
Note: R1-2300917 is handled with R1-2300621 and R1-2300622 under agenda 7.2.
Agreement
For alignment TS38.214 CR:
· Text proposal provided in R1-2300498 is endorsed for the editorial corrections.
Maintenance on channel access mechanism for FR2-2
R1-2301972 Summary #1 of Channel Access Procedures Moderator (Nokia)
R1-2302109 Summary #2 of Channel Access Procedures Moderator (Nokia)
R1-2302153 Correction on channel measurement and interference measurement in FR2-2 in TS 38.214 Moderator (Nokia), ZTE, Sanechips
R1-2302154 Corrections to ChanneAccess-CPext field in DCI formats x_2 in TS38.212 Moderator(Nokia), Huawei, HiSilicon, vivo, LG Electronics
R1-2302155 DRAFT LS to RAN2 on reference subcarrier spacing for FR2-2 Moderator (Nokia)
R1-2302184 Corrections to ChanneAccess-CPext field in DCI formats x_2 in TS38.212 Moderator (Nokia), Huawei, HiSilicon, vivo, LG Electronics
Issue CA-1 Support of Type 1 LBT to Type 2 or Type 3 LBT upgrade when back in gNB COT for FR2-2 unlicensed operation in R17.
R1-2300258 Discussion on remaining issue for LBT upgrade within gNB COT OPPO
R1-2300259 Draft CR on resolving issue for LBT upgrade within gNB COT OPPO
R1-2300643 The remaining issues on channel access mechanism CATT
R1-2300645 Draft CR on channel access type update within gNB COT CATT
R1-2300709 Discussion on LBT type update upon detection of DCI format 2-0 for FR2-2 ZTE, Sanechips
R1-2300710 Draft CR on LBT type update upon detection of DCI format 2-0 for FR2-2 in TS 37.213 ZTE, Sanechips
R1-2301103 Draft CR on LBT type determination within a COT LG Electronics
R1-2301386 Remaining issues for channel access for NR beyond 52.6GHz Qualcomm Incorporated
R1-2301731 Draft CR on channel access procedure upon detection of a common DCI for FR2-2 WILUS Inc.
Conclusion
· Strive to conclude on issue CA-1 at RAN1#112bis.
Issue CA-2 UE resumes COT after a gap
R1-2300643 The remaining issues on channel access mechanism CATT
R1-2300644 Draft CR on UE resuming a UE initiated COT CATT
R1-2301386 Remaining issues for channel access for NR beyond 52.6GHz Qualcomm Incorporated
R1-2301728 Discussion on UE resuming a UE-initiated COT Nokia, Nokia Shanghai Bell
R1-2301729 Correction on UE resuming a UE-initiated COT Nokia, Nokia Shanghai Bell
Conclusion
· No correction is needed for this issue in Rel-17.
Issue CA-3 UE averaging of channel/interference measurements across different transmission bursts
R1-2300711 Discussion on channel measurement and interference measurement in FR2-2 ZTE, Sanechips
R1-2300712 Correction on channel measurement and interference measurement in FR2-2 in TS 38.214 ZTE, Sanechips
Agreement
Endorse the 38.214 Draft CR in R1-2300712.
Final CR (Rel-17, 38.214,CR0400, Cat F) is agreed in
R1-2302153 Correction on channel measurement and interference measurement in FR2-2 in TS 38.214 Moderator (Nokia), ZTE, Sanechips
Issue CA-4 CSI-RS validation in DRS burst
R1-2301652 Correction on CSI-RS validation ASUSTeK
Conclusion
· No correction is needed for this issue in Rel-17.
Issue CA-5 CO-DurationsPerCell-r17 reference SCS clarification
R1-2301705 Remaining issues of channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
Agreement
The values 120/480/960 kHz can be configured as reference subcarrier spacing in CO-DurationsPerCell-r17, and the values 15/30/60 kHz cannot be configured as reference subcarrier spacing in CO-DurationsPerCell-r17.
· Send an LS to RAN2 informative of the clarification
Comeback for the draft LS – Timo (Nokia)
R1-2302155 DRAFT LS to RAN2 on reference subcarrier spacing for FR2-2 Moderator (Nokia)
Decision: The draft LS is endorsed. Final LS is approved in R1-2302185.
Issue CA-6 Multi-beam COT minimum gap
R1-2301705 Remaining issues of channel access mechanism for 60 GHz unlicensed operation Huawei, HiSilicon
R1-2301706 Corrections to multi beam channel access in TS37.213 Huawei, HiSilicon
Conclusion
· No correction is needed for this issue in Rel-17.
Issue CA-7 Introduce channel access type indication in DCI 0_2/1_2 for operation in FR2-2
R1-2301707 Corrections to ChanneAccess-CPext field in DCI formats x_2 in TS38.212 Huawei, HiSilicon
R1-2301102 Draft CR on channel access type indication for DCI format x_2 in FR2-2 LG Electronics
Agreement
Agree a TP to 38.212 based on Draft CR in R1-2301707, further accommodating the edits below:
--------- Start of TP --------
- ChannelAccess-CPext-CAPC – 0, 1, 2, 3, 4, 5
or 6 bits. The bitwidth for this field is determined as 
bits, where I is the
number of entries in the higher layer
parameter ul-AccessConfigListDCI-0-2 or in Table
7.3.1.1.1-4A if channelAccessMode-r16 = "semiStatic" is
provided, for operation in a cell with shared spectrum channel access in
frequency range 1, or the number of entries in the high layer
parameter ul-AccessConfigListDCI-0-1 for operation
in
frequency range 2-2 if ChannelAccessMode2-r17 is provided; otherwise 0
bit. One or more entries from Table 7.3.1.1.2-35 are
configured by the higher layer parameter ul-AccessConfigListDCI-0-2 in
frequency range 1. One
or more entries from Table 7.3.1.1.2-35A
are configured by the higher layer parameter ul-AccessConfigListDCI-0-1 in
frequency range 2-2.
- ChannelAccess-CPext-CAPC – 0, 1, 2, 3, 4, 5
or 6 bits. The bitwidth for this field is determined as bits, where I is the
number of entries in the higher layer
parameter ul-AccessConfigListDCI-1-2 or in Table
7.3.1.1.1-4A if channelAccessMode-r16 = "semiStatic" is
provided, for operation in a cell with shared spectrum channel access in
frequency range 1, or the number of entries in the high layer
parameter ul-AccessConfigListDCI-1-1 for operation
in
frequency range 2-2 if ChannelAccessMode2-r17 is provided; otherwise 0
bit. One or more entries from Table 7.3.1.1.2-35 are
configured by the higher layer parameter ul-AccessConfigListDCI-1-2 in
frequency range 1. One
or more entries from Table 7.3.1.1.2-35A
are configured by the higher layer parameter ul-AccessConfigListDCI-1-1 in
frequency range 2-2.
--------- End of TP --------
Draft CR in
R1-2302154 Corrections to ChanneAccess-CPext field in DCI formats x_2 in TS38.212 Moderator(Nokia), Huawei, HiSilicon, vivo, LG Electronics
Agreement
The draft CR in R1-2302154 is endorsed. Final CR (Rel-17, 38.212, CR0138, Cat F) is agreed in R1-2302184.
Issue CA-8 Corrections to spatial domain filter determination for type 2 channel access in COT resumption in TS37.213
R1-2301757 Corrections to spatial domain filter determination for type 2 channel access in COT resumption in TS37.213 Huawei, HiSilicon
Conclusion
· No correction is needed for this issue in Rel-17.
Issue CA-9 Clarify if Type 2 LBT fails, use Type 1 LBT instead
R1-2301730 Draft CR on channel access after failure of Type 2 channel access for FR2-2 WILUS Inc.
Conclusion
· No correction is needed for this issue in Rel-17.
Final summary in R1-2302156.
is
even}, {7, if 
