Maintenance of NR-based Access to Unlicensed Spectrum

Physical Layer Signals and Channels

Initial access signals/channels

R1-2001649	Remaining issues on initial access signals and channles	vivo

R1-2001702	Remaining issues on the initial access signals for NR-U	ZTE, Sanechips

R1-2001756	Discussion on the remaining issues of initial access signal/channel	OPPO

R1-2001932	Remaining issues of initial access signals and channels for NR-U	LG Electronics

R1-2002028	Initial access signals and channels	Ericsson

R1-2002114	Initial access signals and channels for NR-U	Samsung

R1-2002224	Remaining issues on Initial Access Signals and Channels for NR-U	Nokia, Nokia Shanghai Bell

R1-2002262	Remaining issues on initial access signals/channels	Spreadtrum Communications

R1-2002575	Maintainance on the initial access signals and channels	Huawei, HiSilicon

[100b-e-NR-unlic-NRU-InitSignalChannel-01] Email discussion/approval on k_SSB indication in PBCH for SSB on sync raster and off-sync raster by 4/22; if necessary, followed by endorsing the corresponding TP by 4/28 – Jing (Qualcomm)

R1-2002915	Email discussion summary on email discussion on k_SSB indication in PBCH for SSB on sync raster and off-sync raster	Moderator (Qualcomm Incorporated)

Agreement:

Adopt the following text proposal for Section 7.4.3.1 of TS 38.211:

------------------------------------TP for 38.211, 7.4.3.1----------------------------------

7.4.3.1	Time-frequency structure of an SS/PBCH block

In the time domain, an SS/PBCH block consists of 4 OFDM symbols, numbered in increasing order from 0 to 3 within the SS/PBCH block, where PSS, SSS, and PBCH with associated DM-RS are mapped to symbols as given by Table 7.4.3.1-1.

In the frequency domain, an SS/PBCH block consists of 240 contiguous subcarriers with the subcarriers numbered in increasing order from 0 to 239 within the SS/PBCH block. The quantities and represent the frequency and time indices, respectively, within one SS/PBCH block. The UE may assume that the complex-valued symbols corresponding to resource elements denoted as 'Set to 0' in Table 7.4.3.1-1 are set to zero. The quantity in Table 7.4.3.1-1 is given by . The quantity is the subcarrier offset from subcarrier 0 in common resource block to subcarrier 0 of the SS/PBCH block, where is obtained from the higher-layer parameter offsetToPointA and the 4 least significant bits of are given by the higher-layer parameter ssb-SubcarrierOffset and for SS/PBCH block type A the most significant bit of is given by in the PBCH payload as defined in clause 7.1.1 of [4, TS 38.212]. For operation with shared spectrum channel access, 4 least significant bits of are given by the higher-layer parameter ssb-SubcarrierOffset and the most significant bit of is given by in the PBCH payload as defined in clause 7.1.1 of [4, TS 38.212]. If , ; otherwise, . If ssb-SubcarrierOffset is not provided, is derived from the frequency difference between the SS/PBCH block and Point A.

------------------------------------------------------------------------------------------------

Agreement:

Adopt the following text proposal for Section 4.1 of TS 38.213

------------------------------------ Text Proposal for 38.213, Section 4.1----------------------------

*** Unchanged text omitted ***

is either provided by ssbPositionQCL-Relationship-r16 or, if ssbPositionQCL-Relationship-r16 is not provided, obtained from a MIB provided by a SS/PBCH block according to Table 4-1 with <24 as defined in clause 7.4.3.1 of [4, 38.211].

*** Unchanged text omitted ***

-------------------------------------- End Text Proposal --------------------------------------

R1-2002997	draft LS to RAN2 on NR-U ARFCN restriction for CGI reading	Qualcomm Incorporated

Final LS for draft LS in R1-2002997 approved in R1-2003032

DL signals and channels

R1-2001532	Maintainance on DL signals and channels	Huawei, HiSilicon

R1-2001650	Remaining issues on physical DL channel design in unlicensed spectrum	vivo

R1-2001703	Remaining issues on the DL channels for NR-U	ZTE, Sanechips

R1-2001757	Discussion on the remaining issues of DL signals and channels	OPPO

R1-2001902	Remaining issues on DL signals and channels for NR-U	MediaTek Inc.

R1-2001933	Remaining issues of DL signals and channels for NR-U	LG Electronics

R1-2001985	DL signals and channels for NR-unlicensed	Intel Corporation

R1-2002029	DL signals and channels	Ericsson

R1-2002054	Maintenance for DL signals and channels for NR-U	Panasonic Corporation

R1-2002115	DL signals and channels for NR-U	Samsung

R1-2002225	Remaining issues on DL signals and channels	Nokia, Nokia Shanghai Bell

R1-2002275	Remaining issues in DL signals and channels	Spreadtrum Communications

R1-2002320	Remaining issues of DL signals and channels	Apple

R1-2002381	Remaining issues and corrections on DL signals and channels for NR-U	Sharp

R1-2002528	TP for DL signals and channels for NR-U	Qualcomm Incorporated

R1-2002630	Text proposal for search space group switching	Google Inc.

R1-2002685	Feature lead summary for NR-U DL Signals and Channels	Moderator (Lenovo)

[100b-e-NR-unlic-NRU-DL_Signals_and_Channels-01] Email discussion/approval on processing time for switching and default SS group, including BWP switching by 4/24; if necessary, followed by endorsing the corresponding TPs by 4/30 – Alex (Lenovo)

R1-2002786	Summary of email discussion [100b-e-NR-unlic-NRU-DL_Signals_and_Channels-01] on SS group sets	Moderator (Lenovo)

Agreement:

Define two capabilities of P values

SSSG switching Capability-1: P=25 symbols for µ = 0/1/2 SCS

SSSG switching Capability-2: P=10/12/22 symbols for µ = 0/1/2 SCS

Introduce a UE capability to signal support of SSSG switching Capability-2 in addition to SSSG switching Capability-1

Introduce a RRC configuration parameter to indicate the P value to be applied by a UE for SSSG switching (no lower than the reported capability by the UE).

Agreement:

The smallest subcarrier spacing of the corresponding active BWP across CCs within a CC group and the CC in which a DCI format 2_0 triggering group switching is detected, if any, is used to determine the first slot of search space set group switching for all CCs within a CC-group.

Agreement:

SS set group 0, if configured, is applicable for a UE at least after RRC (re)configuration of SS set group by searchSpaceGroupIdList-r16.

Agreement:

Adopt the text proposal in R1-2003042 for Section 10.4 of TS 38.213v16.1.0.

[100b-e-NR-unlic-NRU-DL_Signals_and_Channels-02] Email discussion/approval on special states/indications in “available RB set indication” and COT duration indication/determination by 4/23; if necessary, followed by endorsing the corresponding TPs by 4/29 – Alex (Lenovo)

R1-2002787	Summary of email discussion [100b-e-NR-unlic-NRU-DL_Signals_and_Channels-02] on available RB set indication and COT duration	Moderator (Lenovo)

Agreement:

The text proposal in R1-2003041 for TS 38.213v16.1.0, clause 11.1.1, is agreed

[100b-e-NR-unlic-NRU-DL_Signals_and_Channels-03] Email discussion/approval on CSI-RS measurements including validity/presence of periodic/semi-persistent CSI-RS by 4/24; if necessary, followed by endorsing the corresponding TPs by 4/30 – Alex (Lenovo)

Agreement:

RAN1 to decide in RAN#101e whether R16 supports the case where UE is not configured with SFI-index field but configured with any of the following: CO-duration, SS-switching trigger and RB-sets indication in DCI format 2_0

[100b-e-NR-unlic-NRU-DL_Signals_and_Channels-04] Email discussion/approval on the following from prior meetings by 4/23 – Alex (Lenovo)

Capture "For search space switching, limit the switching to USS and Type-3 CSS."

Align the terminology on the RB set indicator/Available RB set Indicator in TS38.213 and TS38.212.

Align RRC parameter list with TS38.213:

Configurations of availableRB-SetPerCell-r16, CO-DurationPerCell-r16 and SearchSpaceSwitchTrigger-r16 should be added in SlotFormatCombinationsPerCell,

Propose to RAN2 to discard the “groupId” parameter defined under searchSpaceSwitchTrigger-r16, and remove the CHOICE structure

R1-2002789	Summary of email discussion [100b-e-NR-unlic-NRU-DL_Signals_and_Channels-04] on capturing prior agreements	Moderator (Lenovo)

Agreement:

Recommend to RAN2 to discard the “groupId” parameter defined under searchSpaceSwitchTrigger-r16, and remove the CHOICE structure.

Agreement:

Draft LS in R1-2003039 is agreed with the final LS in R1-2003040

Agreement:

Adopt the following TP for Section 10.4 of TS 38.213:

“A UE can be provided a group index for a respective Type3-PDCCH common search space set or a UE specific search space set by searchSpaceGroupIdList-r16 for PDCCH monitoring on a serving cell.”

UL signals and channels

R1-2001533	Maintainance on uplink signals and channels	Huawei, HiSilicon

R1-2001651	Remaining issues on physical UL channel design in unlicensed spectrum	vivo

R1-2001704	Remaining issues on the UL channels for NR-U	ZTE, Sanechips

R1-2001758	Discussion on the remaining issues of UL signals and channels	OPPO

R1-2001875	Remaining issues on UL signals and channels for NR-U	Fujitsu

R1-2001903	Remaining issues on UL signals and channels for NR-U	MediaTek Inc.

R1-2001934	Remaining issues of UL signals and channels for NR-U	LG Electronics

R1-2001973	Remaining issues for UL signals and channels for NR-U	Lenovo, Motorola Mobility

R1-2001986	UL signals and channels for NR-unlicensed	Intel Corporation

R1-2002030	UL signals and channels	Ericsson

R1-2002075	TP for SRS configuration	CATT

R1-2002116	UL signals and channels for NR-U	Samsung

R1-2002192	Remaining Issues on UL Signals and Channels for NR-U	Nokia, Nokia Shanghai Bell

R1-2002246	UL signals and channels	ETRI

R1-2002276	Remaining issues in UL signals and channels	Spreadtrum Communications

R1-2002321	Remaining issues of UL signals and channels	Apple

R1-2002365	TPs on uplink signals in NRU	NEC

R1-2002382	Remaining issues on UL signals/channels for NR-U	Sharp

R1-2002433	Remaining issues on UL signals and channels for NR-U	NTT DOCOMO, INC.

R1-2002529	TP for UL signals and channels for NR-U	Qualcomm Incorporated

R1-2002036	Feature Lead Summary for UL Signals and Channels	Ericsson

[100b-e-NR-unlic-NRU-ULSignalsChannels-01] Email discussion/approval on the following issues

by 4/23; if necessary, followed by endorsing the corresponding TPs by 4/29 – Steve (Ericsson)

Finalize design for FDRA field of DCI 0_0 for UL resource allocation Type 2

Editorial correction on interlace configuration

Agreement:

For PUSCH scheduled by DCI 0_0 received in a CSS when UL resource allocation Type 2 is configured, PUSCH is allocated to the RB set of the active UL BWP that intersects the RB set of the active DL BWP in which DCI 0_0 is received. If there is no intersection, PUSCH is allocated to RB Set 0 of the active UL BWP.

FFS1: PUSCH allocation within the active UL BWP corresponding to an UL carrier without intra-cell guard bands

FFS2: Whether or not the first bullet is modified to “…the active DL BWP in which the first REG of the received DCI 0_0 is located,” in order to facilitate a CORESET not confined to a single RB set.

Agreement:

Adopt TP#1 in Section 2.2 of R1-2002912 for TS 38.211, Section 4.4.4.6

Agreement:

For PUSCH scheduled by DCI 0_0 received in a USS when UL resource allocation Type 2 is configured, PUSCH is allocated to the RB set(s) of the active UL bandwidth part indicated by the Y bits in the FDRA field of DCI 0_0.

Agreement:

Adopt TP#2 in Section 3.1 of R1-2002912 for TS 38.212, Section 7.3.1.1.1

Agreement:

Adopt TP#3 in Section 3.1 of R1-2002912 for TS 38.214, Section 6.1.2.2.3

[100b-e-NR-unlic-NRU-ULSignalsChannels-02] Email discussion/approval on the following issues

by 4/24; if necessary, followed by endorsing the corresponding TPs by 4/30 – Steve (Ericsson)

Capture UE procedure related to FDRA field in RAR UL grant

Editorial correction on SRS

Agreement:

Adopt TP#1 in R1-2002913 for 38.213 Section 8.3 and TP#2 for 38.214 Section 6.1.2.2.3 where the last bullet of TP#1 is modified as follows:

The UE assumes the RB set allocation in the active UL BWP for a PUSCH scheduled by the RAR UL grant is given by [FFS: rule for for RB set allocation]

FFS: PUSCH allocation rule within the interlaces indicated by the frequency domain resource allocation field

Agreement:

To resolve the FFS in TP#1, support one of the following two alternatives for the PUSCH allocation rule.

When UL resource allocation Type 2 is configured, the UE assumes that PUSCH is allocated as follows:

Alt-1: PUSCH is allocated to the RB set of the active UL BWP that intersects the RB set of the active DL BWP in which the DCI 0_1 that schedules the PDSCH containing the RAR UL grant is received. If there is no intersection, PUSCH is allocated to RB Set 0 of the active UL BWP.

Alt-2: PUSCH is allocated to the initial UL BWP if the active UL BWP fully overlaps the initial UL BWP, otherwise PUSCH is allocated to RB Set 0 of the active UL BWP.

FFS: Rule for PUSCH allocation for an UL carrier without intra-cell guard bands.

Agreement:

Adopt TP#3 in R1-2002913 for 38.214 Section 6.2.1

Agreement:

Adopt TP#1 and TP#2 in Section 2.1 of R1-2003056 for TS 38.213, Section 8.3 and TS 38.214, Section 6.1.2.2.3 respectively

[100b-e-NR-unlic-NRU-ULSignalsChannels-03] Email discussion/approval on the following issues

by 4/22; if necessary, followed by endorsing the corresponding TPs by 4/28 – Steve (Ericsson)

Rule for interlaced PUCCH allocation for a carrier without guard bands

Editorial (but critical) corrections on PUCCH

Agreement:

Adopt TP#2 in R1-2002914 for 38.212 Section 6.3.1.6

Agreement:

Adopt TP#3 in R1-2002914 for 38.213 Section 9.2.2

Agreement:

Adopt TP#4,5,6,7 in R1-2002914 for 38.211,212,213,214 respectively

Agreement:

Adopt TP#1v1 and TP#8v1 in R1-2003057 for 38.213, Section 9.2.1

Physical Layer Procedure

Channel access procedures

R1-2002284	Feature lead summary on NR-U channel access procedures	Moderator (Nokia)

R1-2001534	Maintainance on the channel access procedure	Huawei, HiSilicon

R1-2001652	Remaining issues on the channel access procedures	vivo

R1-2001705	Remaining issues on the channel access procedure for NR-U	ZTE, Sanechips

R1-2001759	Discussion on the remaining issues of channel access procedure	OPPO

R1-2001935	Remaining issues of channel access procedure for NR-U	LG Electronics

R1-2001987	Channel access mechanism for NR-unlicensed	Intel Corporation

R1-2002031	Channel access procedures	Ericsson

R1-2002117	Channel access procedures for NR-U	Samsung

R1-2002193	Remaining Issues on Channel Access Procedures for NR-U	Nokia, Nokia Shanghai Bell

R1-2002247	Remaining issues on channel access procedures for NR-U	ETRI

R1-2002383	Remaining issues and corrections on channel access procedure for NR-U	Sharp

R1-2002405	Remaining issues on channel access for NR-U operation	MediaTek Inc.

R1-2002434	Remaining issues on channel access procedures for NR-U	NTT DOCOMO, INC.

R1-2002465	TP on shared spectrum in NR-U	NEC

R1-2002530	TP for Channel access procedures for NR unlicensed	Qualcomm Incorporated

R1-2002632	Remaining issues on channel access procedure for NR-U	WILUS Inc.

R1-2002684	COT sharing information in CG-UCI	Lenovo, Motorola Mobility

[100b-e-NR-unlic-NRU-ChAcc-01] Email discussion/approval on clarifications to LBT with consecutive UL transmissions by 4/23; if necessary, followed by endorsing the corresponding TPs by 4/28 – Timo (Nokia)

R1-2003062	Feature lead summary#2 on email discussion [100b-e-NR-unlic-NRU-ChAcc-01]	Moderator (Nokia)

Agreement:

For LBT type and CP extension, after failing to transmit first PUSCH(s) of a set scheduled by a single UL grant,

If a UE fails to access the channel with UL Type 2B channel access, Type 2A UL channel access shall be used for the following consecutively scheduled transmissions.

If a UE fails to access the channel prior to the first of the consecutive UL transmissions, it shall use “0” CP extension for the subsequent UL transmissions irrespective of the CP extension indicated in the scheduling grant.

Agreement:

Back-to-back transmission of GC-PUSCH and dynamically scheduled PUSCH is supported in NR-U with restrictions similar to those in LTE LAA.

Agreement:

Adopt TP #2.1 and TP#2.2 in R1-2003062 for TS 37.213, Section 4.2.1.0.1

[100b-e-NR-unlic-NRU-ChAcc-02] Email discussion/approval on clarifications to UL to DL COT sharing by 4/24; if necessary, followed by endorsing the corresponding TPs by 4/29 – Timo (Nokia)

R1-2003063	Feature lead summary#2 on email discussion [100b-e-NR-unlic-NRU-ChAcc-02]	Moderator (Nokia)

Agreement:

For at least PUSCH transmissions with configured grants, a UE is allowed to choose between the ED threshold given by ul-toDL-CO-SharingED-Threshold-r16 and the default one. Whether a spec change is required needs further discussion. Discuss and decide the possible TPs in the next meeting.

Agreement:

Adopt TP#2.3-1 in R1-2003063 (cover sheet information in Section 3) for Section 4.2.1 of TS 37.213

Agreement:

Adopt TP#2.3-2 in R1-2003063 (cover sheet information in Section 3) for Section 4.1.3 of TS 37.213

Agreement:

Adopt TP#2.4 in R1-2003063 (cover sheet information in Section 3) for Section 4.1.3 of TS 37.213

Enhancements to initial access procedure

R1-2001535	Maintainance on the initial access procedures	Huawei, HiSilicon

R1-2001653	Remaining issues on initial access procedure for NR-U	vivo

R1-2001706	Remaining issues on the initial access procedure for NR-U	ZTE, Sanechips

R1-2001760	Discussion on the remaining issues of enhancements to initial access procedure	OPPO

R1-2001936	Remaining issues of initial access and mobility for NR-U	LG Electronics

R1-2001988	Enhancements to initial access and mobility for NR-unlicensed	Intel Corporation

R1-2002032	Enhancements to initial access procedures	Ericsson

R1-2002118	Initial access procedures for NR-U	Samsung

R1-2002248	Remaining issues on initial access procedure for NR-U	ETRI

R1-2002263	Remaining issues on initial access procedure	Spreadtrum Communications

R1-2002278	On Enhancements to Initial Access Procedures for NR-U	Nokia, Nokia Shanghai Bell

R1-2002407	Remaining issues on initial access procedure for NR-U operation	MediaTek Inc.

R1-2002531	TP for Initial access and mobility procedures for NR-U	Qualcomm Incorporated

R1-2001701	Feature lead summary on NR-U enhancement to initial access procedures	Moderator (Charter Communications, Inc)

[100b-e-NR-unlic-NRU-InitAccessProc-01] Email discussion/approval on following issues related to SS/PBCH blocks by 4/24; if necessary, followed by endorsing the corresponding TPs by 4/29 – Amitav (Charter)

Finalize remaining details of parameter Q signalling and interpretation

Correct the citation of TS 38.104 in TS 38.213 Subclause 4.1 in relation to the definition of L_max

R1-2002849	Draft [100b-e-NR-unlic-NRU-InitAccessProc-01]	Moderator (Charter Communications)

Agreement

For RRM measurement configuration from MeasObjectNR and SIB2/SIB4, network always provides a common Q value (ssb-PositionQCL-Common-r16) per frequency to UE.

For SCell addition, SCG addition, and reconfiguration with sync, the Q value of the cell to be added is always provided to UE via dedicated RRC signaling, i.e. ssb-PositionQCL-r16 in ServingCellConfigCommon.

An LS is to be sent to RAN2 and RAN4 for the above.

Agreement:

LS on Signaling of Q Parameter for NR-U agreed in R1-2003044

Agreement:

Send an LS to RAN4 asking them to remove the word “candidate” in TS 38.133 V16.0.0 subclause 8.1.1.

Agreement:

LS on removing the word “candidate” in Subclause 8.1.1 of TS 38.133 v16.3.0 approved in R1-2002992

Agreement:

TP1 in R1-2002849 is agreed for TS 38.213

Agreement:

TP1 in R1-2002849 is agreed for TS 38.213

Agreement:

Adopt the following text proposal for TS 38.213 (correction of TP2 in R1-2002849)

======================= Start of TP2 for Clause 4.1 of TS 38.213 =================

============================ Unchanged Text Omitted ========================

The UE assumes that within a discovery burst transmission window, a number of transmitted SS/PBCH blocks on a serving cell is not larger than . The UE can determine an SS/PBCH block index according to , or according to where is the candidate SS/PBCH block index. The UE assumes that within a discovery burst transmission window, a number of transmitted SS/PBCH blocks on a serving cell is not larger than and a number of transmitted SS/PBCH blocks with the same SS/PBCH block index is at most one.

=========================== Unchanged Text Omitted ========================

======================= End of TP2 for Clause 4.1 of TS 38.213 ==================

Agreement:

TP4 in R1-2002849 is agreed for TS 38.213

[100b-e-NR-unlic-NRU-InitAccessProc-02] Email discussion/approval on following issues related to RA procedure by 4/24; if necessary, followed by endorsing the corresponding TPs by 4/29 – Amitav (Charter)

MsgA PRACH-PUSCH gap for NR-U

Remaining details of RACH occasion validation for FBE access

Agreement:

Update TS 38.213 for RACH occasion validation in FBE mode to also cover the cases when UE is not provided tdd-UL-DL-ConfigurationCommon, and for Type-2 RA procedure.

Use the TP in TP7 of R1-2001706 as the starting point for further refinement.

Agreement:

Adopt the following text proposal for TS 38.213

------------------------------------------------- < Start of text proposal for 38.213> ------------------------------------------------

8.1 Random access preamble

< Unchanged parts are omitted >

For unpaired spectrum,

- if a UE is not provided tdd-UL-DL-ConfigurationCommon, a PRACH occasion in a PRACH slot is valid if it does not precede a SS/PBCH block in the PRACH slot and starts at least symbols after a last SS/PBCH block reception symbol, where is provided in Table 8.1-2, and if ChannelAccessMode-r16 = semistatic is provided, does not overlap with a set of consecutive symbols before the start of a next channel occupancy time where there shall not be any transmissions, as described in [15, TS 37.213].

- the index of the SS/PBCH block is provided by ssb-PositionsInBurst in SIB1 or in ServingCellConfigCommon

- If a UE is provided tdd-UL-DL-ConfigurationCommon, a PRACH occasion in a PRACH slot is valid if

- it is within UL symbols, or

- it does not precede a SS/PBCH block in the PRACH slot and starts at least symbols after a last downlink symbol and at least symbols after a last SS/PBCH block symbol, where is provided in Table 8.1-2, and if ChannelAccessMode-r16 = semistatic is provided, does not overlap with a set of consecutive symbols before the start of a next channel occupancy time where there shall not be any transmissions, as described in [15, TS 37.213]

- the index of the SS/PBCH block is provided by ssb-PositionsInBurst in SIB1 or in ServingCellConfigCommon.

< Unchanged parts are omitted >

8.1A PUSCH for Type-2 random access procedure

< Unchanged parts are omitted >

A PUSCH occasion is valid if it does not overlap in time and frequency with any PRACH occasion associated with either a Type-1 random access procedure or a Type-2 random access procedure. Additionally, if a UE is provided tdd-UL-DL-ConfigurationCommon, a PUSCH occasion is valid if

- it is within UL symbols, or

- it does not precede a SS/PBCH block in the PUSCH slot and starts at least symbols after a last downlink symbol and at least symbols after a last SS/PBCH block symbol, where is provided in Table 8.1-2, and if ChannelAccessMode-r16 = semistatic is provided, does not overlap with a set of consecutive symbols before the start of a next channel occupancy time where there shall not be any transmissions, as described in [15, TS 37.213].

< Unchanged parts are omitted >

------------------------------------------------------- < End of text proposal> --------------------------------------------------------

Conclusion:

A UE can transmit in a PRACH resource in the channel occupancy of a Fixed Frame Period only if a UE detects any DL transmission in the serving cell before the PRACH resource in the same FFP.

Note: TS 37.213 editor to check if this is already covered

[100b-e-NR-unlic-NRU-InitAccessProc-03] Email discussion/approval on following issues related to RRM/RLM by 4/23; if necessary, followed by endorsing the corresponding TPs by 4/28 – Amitav (Charter)

TP to 38.215 for RSSI definition

Finalize the number of OFDM symbols for RSSI measurement duration configuration

Agreement:

1 symbol duration is included for each numerology (approx. 71 us, 35 us, 17 us respectively).

This is a natural consequence of previous agreement: The L1 averaging duration of RSSI measurements (within a configured measurement duration) is limited to 1 OFDM symbol of a configured reference subcarrier spacing.

Retain LTE LAA values {sym1, sym14, sym28, sym42, sym70} at least for 15 kHz numerology

Measurement duration can be no more than 5 ms for each numerology (requires sym70, sym140, sym280/sym240 respectively)

[100b-e-NR-unlic-NRU-InitAccessProc-04] Email approval of the reply LS for R1-2001237 by 4/23 - Zhipeng (Ericsson)

R1-2002852	Summary of [100b-e-NR-unlic-NRU-InitAccessProc-04] for Reply LS on NR-U PRACH Root Sequence for 2-Step RA	Moderator (Ericsson)

Agreement:

Respond to the LS from RAN2 in R1-2001237 with the following action:

RAN1 respectfully requests that RAN2 reflect in their specifications that the two new PRACH root sequences (of length 571 and 1151) are supported in 2-step RA with shared spectrum channel access.

R1-2002853	[DRAFT] LS Response on NR-U PRACH root sequence for 2-step RA	Ericsson

Final LS agreed in R1-2002853

[100b-e-NR-unlic-NRU-InitAccessProc-05] Email approval of the corresponding TP to address LS from RAN2 in R1-2001506 by 4/23 - Jing (Qualcomm)

R1-2002996	Summary of email discussion on LSB of SFN validation	Moderator (Qualcomm Incorporated)

Agreement:

Adopt the text proposal in Section 2.1 of R1-2002996 for Section 4.2.1 of TS 37.213

Agreement:

Adopt TP2 in Section 2.2 of R1-2002996 for 38.212, Section 7.3.1.2.1

HARQ enhancement

R1-2001536	Maintainance on HARQ-ACK enhancement	Huawei, HiSilicon

R1-2001654	Remaining issues on HARQ operation for NR-U	vivo

R1-2001707	Remaining issues on the HARQ for NR-U	ZTE, Sanechips

R1-2001761	Discussion on the remaining issues of HARQ enhancements	OPPO

R1-2001904	Remaining issues on HARQ operation for NR-U	MediaTek Inc.

R1-2001937	Remaining issues of HARQ procedure for NR-U	LG Electronics

R1-2001974	Remaining issues for HARQ enhancement for NR-U	Lenovo, Motorola Mobility

R1-2001989	Enhancements to HARQ for NR-unlicensed	Intel Corporation

R1-2002033	HARQ enhancement	Ericsson

R1-2002119	HARQ enhancement for NR-U	Samsung

R1-2002227	Remaining issues on NR-U HARQ scheduling and feedback	Nokia, Nokia Shanghai Bell

R1-2002249	HARQ enhancement	ETRI

R1-2002306	One shot HARQ ACK feedback	InterDigital, Inc.

R1-2002384	Remaining issues and corrections on HARQ enhancement for NR-U	Sharp

R1-2002532	TP for Enhancements to Scheduling and HARQ Operation for NR-U	Qualcomm Incorporated

R1-2002631	Text proposal for enhanced dynamic HARQ procedures	Google Inc.

R1-2002696	Feature lead summary#1 on NR-U HARQ	Moderator (Huawei)

[100b-e-NR-unlic-NRU-HARQ-01] Email discussion/approval on following issues related to Type-3 HARQ-ACK codebook by 4/23; if necessary, followed by endorsing the corresponding TPs by 4/29 – David (Huawei)

Remaining details on triggering Type-3 HARQ-ACK codebook feedback with a DCI that does not schedule a PDSCH

Clarification to remove unintended limitations on Type-3 HARQ-ACK codebook usage (when no NNK1 value was received, when the UE is configured with semi-static codebook)

Clarification that Type-3 HARQ-ACK codebook feedback should be generated for all configured serving cells

Agreement:

No new DCI field is introduced for requesting Type-3 HARQ-ACK feedback without scheduling a PDSCH

For DCI Format 1_1:

To signal Type-3 HARQ-ACK codebook request without scheduling PDSCH with one-shot HARQ-ACK request field with value 1 in DCI Format 1_1 with CRC scrambled by C-RNTI or MCS-C-RNTI, use all ‘0’ FDRA for resourceAllocationType0 and all ‘1’ FDRA for resourceAllocationType 1 if resourceAllocation = dynamicSwitch is not provided, or use all “0” or all “1” FDRA if resourceAllocation = dynamicSwitch is provided. In this case, the UE does not consider the DCI format as indicating an active DL BWP provided by dormant-BWP or by first-non-dormant-BWP-ID-for-DCI-inside-active-time, if any.

FFS: When DCI Format 1_1 is scrambled by CS-RNTI

Agreement:

Approve the TP#1 and TP#2-Alt2 in R1-2003029 for TS 38.213

Agreement:

The slot where the PDCCH/DCI is transmitted/received is taken as a reference for K1

Agreement:

For a DCI requesting one-shot HARQ-ACK feedback without scheduling PDSCH, reuse the minimum processing latency for SPS release DCI

FFS: whether to specify the processing time for 120 kHz SCS, considering NR-U UE feature groups discussion and possible extension of type-3 HARQ-ACK codebook to licensed bands operation (FR1 or FR2 or both).

Agreement:

Adopt TP#1 in R1-2003028 for 38.212, clause 7.3.1.2.2

Agreement:

Adopt TP#2 in R1-2003028 for 38.213, clauses 9.1.4, 9.2.3 and 10.3

Agreement:

Adopt the following TP for TS 38.213 Clause 9.1.4 with the reason for change as given below

Reason for change: missing implementation of agreement that the UE reports HARQ-ACK information for all configured serving cells in Type-3 HARQ-ACK codebook, otherwise a UE may only report HARQ-ACK information for activated serving cells with ambiguity during cell activation/deactivation periods.

================== Beginning of text proposal ===================

9.1.4	Type-3 HARQ-ACK codebook determination

If a UE is provided pdsch-HARQ-ACK-OneShotFeedback-r16, the UE determines a Type-3 HARQ-ACK codebook according to the following procedure.

Set to the number of serving cells configured to the UE.

================== End of text proposal ===================

[100b-e-NR-unlic-NRU-HARQ-02] Email discussion/approval on following issues related to Type-2 enhanced HARQ-ACK codebook by 4/24; if necessary, followed by endorsing the corresponding TPs by 4/30 – David (Huawei)

How to determine NFI, number of requested groups and PUCCH occasions i(g) and i((g+1) mod 2) when multiple DCIs provide these values

How is T-DAI interpreted in DCI 1_1 for the non-scheduled group when two sub-codebooks (for TB and CBG) are configured

Second HARQ-ACK information generation in case of toggled NFI for the non-scheduled group in a DCI scheduling PDSCH for another group

Agreement:

Adopt the following TP for TS 38.213 Clause 9.1.3.3 with the reason for change given below

Reason for change: for second HARQ-ACK information generation in case of toggled NFI for the non-scheduled group in a DCI scheduling PDSCH for another group, it is unclear which PDCCH monitoring occasion corresponds to m=0, which could result in HARQ-ACK codebook size mismatch between gNB and UE.

TP for TS 38.213 Clause 9.1.3.3

============= Unchanged part omitted =============

If and , generate second HARQ-ACK information, as described in Clause 9.1.3.1, by setting for all and all and, after the completion of the and loops for the pseudo-code for the second HARQ-ACK codebook generation in Clause 9.1.3.1, setting .

============= Unchanged part omitted =============

Agreement:

The 1 MSB bit is the NFI for the scheduled PDSCH group, and the 1 LSB bit is the NFI for the non-scheduled PDSCH group.

Agreement:

It is not expected to receive DCIs with q=0 pointing to the same PUCCH transmission occasion for different PDSCH groups

Conclusion:

It is not expected to receive a DCI with q=0 after receiving a DCI with q=1 pointing to the same PUCCH transmission occasion.

No TP needed

Conclusion:

It is not expected to receive DCIs on different cells in the same monitoring occasion if the DCI formats indicate the same PDSCH group and different values of h(g). It is not expected to receive DCIs on different cells in the same monitoring occasion if the DCI formats indicate different values of q.

No TP needed

Agreement:

If a first DCI format scheduling PDSCH reception and providing the first indication for a PUCCH transmission occasion in a slot does not include a New_Feedback indicator field, the value of h(g) for this PDSCH reception is set only if h(g) is provided by another DCI format providing a value of h(g), and the same value of g and a value of k indicating the same PUCCH transmission occasion in the slot. This first DCI determines m=0.

Agreement:

Clarify that g (scheduled group) and q (number of requested groups) are obtained from the last non-fallback DCI format 1_1 providing these values for a PUCCH transmission occasion

Agreement:

Adopt TP#1 in R1-2003030 for TS 38.212 v16.1.10

Agreement:

Adopt TP#2 in R1-2003030 for TS 38.213 v16.1.10

[100b-e-NR-unlic-NRU-HARQ-03] Email discussion/approval on handling of SPS with enhanced dynamic codebook and with NNK1 by 4/24; if necessary, followed by endorsing the corresponding TPs by 4/30 – David (Huawei)

Agreement:

The HARQ-ACK bit(s) corresponding to SPS PDSCH is(are) appended to the end of a dynamic HARQ-ACK codebook with PDSCH grouping, without belonging to any group.

Agreement:

It is clarified that in a DCI activating SPS PDSCH, the NFI, DAI, q fields are only interpreted for the PDSCH scheduled by the DCI and are not interpreted for the SPS PDSCHs.

No TP is needed

Agreement:

DCI format 1_1 should not simultaneously indicate a NNK1 value and activate a SPS configuration (CRC scrambled with CS-RNTI and NDI=0)

DCI format 1_1 should not simultaneously indicate a NNK1 value and request feedback of Type-3 HARQ-ACK codebook (one-shot HARQ-ACK request field with value 1)

FFS: DCI format 1_1 should not simultaneously indicate a NNK1 value and indicate Scell dormancy

FFS: DCI format 1_1 should not simultaneously indicate a NNK1 value and indicate SPS release

Agreement:

Adopt TP#1 in R1-2003031 for TS 38.213

Agreement:

Adopt TP#2 in R1-2003031 for TS 38.213 with the modification of a sub-bullet to “the PDSCH-to-HARQ_feedback timing indicator field, if present, does not provide an inapplicable value from dl-DataToUL-ACK”

Configured grant enhancement

R1-2001657	Feature lead summary on NRU configured grant enhancement	Moderator (vivo)

R1-2001537	Maintainance on the configured grant procedures	Huawei, HiSilicon

R1-2001655	Remaining issues on the enhancements to configured grant	vivo

R1-2001708	Remaining issues on the configured grant for NR-U	ZTE, Sanechips

R1-2001762	Discussion on the remaining issues of configured grant enhancements	OPPO

R1-2001814	Remaining issues on configured grant enhancement for NR-U	Sony

R1-2001938	Remaining issues of configured grant for NR-U	LG Electronics

R1-2001975	Remaining issues for configured grant enhancement for NR-U	Lenovo, Motorola Mobility

R1-2001990	Enhancements to configured grants for NR-unlicensed	Intel Corporation

R1-2002034	Configured grant enhancement	Ericsson

R1-2002120	Configured grant enhancement for NR-U	Samsung

R1-2002162	Clarification on NR-U configured grant enhancement	Panasonic Corporation

R1-2002194	Remaining Issues on Configured Grant Enhancement for NR-U	Nokia, Nokia Shanghai Bell

R1-2002435	Remaining issues on configured grant enhancement for NR-U	NTT DOCOMO, INC.

R1-2002533	TP for Enhancements to configured grants for NR-U	Qualcomm Incorporated

R1-2002633	Remaining issue on configured grant for NR-U	WILUS Inc.

R1-2002737	Feature lead summary#2 on NRU configured grant enhancement	Moderator (Vivo)

R1-2002745	Summary of prep email discussion on NRU-CG	Moderator (Vivo)

R1-2002984	Editorial corrections on NRU-CG to 38.213	Moderator (Vivo)

[100b-e-NR-unlic-NRU-CG-01] Email discussion/approval on following issues by 4/23; if necessary, followed by endorsing the corresponding TPs by 4/28 – Rakesh (Vivo)

RRC value ranges for RRC parameters

Correction related to semiPersistentOnPUSCH

Clarification on offset-r16

TP on CG-UCI transmission

R1-2002982	Feature lead summary of [100b-e-NR-unlic-NRU-CG-01] Email discussion	Moderator (Vivo)

Agreement:

Adopt the text proposal in Section 1.1 of R1-2002982 for TS 38.211

Agreement:

For sharing of channel occupancy from UL to DL

For the value of X, follow the same value range as for O and D with the step size of [14] symbols

The maximum value of O and D is 39 slots

“no COT sharing” is indicated by a specific row in the table, e.g. index 0

Agreement:

Adopt the text proposal in Section 1.3 of R1-2002982 for TS 38.213

Agreement:

Adopt the text proposal in Section 1.4 of R1-2002982 for TS 37.213

Agreement:

Adopt the text proposal in Section 1.5 of R1-2002982 for TS 38.213

Agreement:

Adopt the text proposal in Section 1.6 of R1-2002982 for TS 38.213

[100b-e-NR-unlic-NRU-CG-02] Email discussion/approval on following issues by 4/24; if necessary, followed by endorsing the corresponding TPs by 4/29 – Rakesh (Vivo)

PUSCH repetition transmission related issues for NRU configured grant

RV determination for CG repetition

R1-2002983 Feature lead summary of [100b-e-NR-unlic-NRU-CG-02] Email discussion	Moderator (Vivo)

Agreement:

Adopt the text proposal in Section 1.2 of R1-2002983 for TS 38.214

Agreement:

Adopt the text proposal in Section 1.3 of R1-2002983 for TS 38.214

Draft LS to RAN2 to check on RV for first repetition (until 5/6)

Wide-band operation

R1-2001940	Summary on maintenance of wide-band operation for NR-U	Moderator (LG Electronics)

R1-2001538	Maintainance on the wideband operation procedures	Huawei, HiSilicon

R1-2001656	Remaining issues on wideband operation in NR-U	vivo

R1-2001709	Remaining issues on the wideband operation for NR-U	ZTE, Sanechips

R1-2001763	Discussion on the remaining issues of wide-band operations	OPPO

R1-2001905	Remaining issues on wideband operation for NR-U	MediaTek Inc.

R1-2001939	Remaining issues of wide-band operation for NR-U	LG Electronics

R1-2001991	Wideband operation for NR-unlicensed	Intel Corporation

R1-2002035	Wideband operation	Ericsson

R1-2002121	Wide-band operation for NR-U	Samsung

R1-2002198	Remaining issues on Rel-16 NR-U wideband operations	Panasonic

R1-2002226	Remaining issues on Wideband operation in NR-U	Nokia, Nokia Shanghai Bell

R1-2002277	Remaining issues in wide-band operation	Spreadtrum Communications

R1-2002322	Remaining issues of wideband operation	Apple

R1-2002385	Remaining issues on wide-band operation for NR-U	Sharp

R1-2002534	TP for Wideband operation for NR-U operation	Qualcomm Incorporated

R1-2002722	Summary#2 on maintenance of wide-band operation for NR-U	Moderator (LG Electronics)

[100b-e-NR-unlic-NRU-WB-01] Email discussion/approval on following issues related to RB set and intra-cell guard band configuration by 4/23; if necessary, followed by endorsing the corresponding TPs by 4/28 – Seonwook (LGE)

Corrections based on RAN1 and RAN2 agreements, and for RB set index within a BWP

Handling of the case where “no guard band” is configured, without considering signaling aspects

R1-2002754	Summary of email discussion [100b-e-NR-unlic-NRU-WB-01] on RB set configuration for NR-U wide-band operation	Moderator (LG Electronics)

R1-2002955	Summary#2 of email discussion [100b-e-NR-unlic-NRU-WB-01] on RB set configuration for NR-U wide-band operation	Moderator (LG Electronics)

Agreement:

Adopt “updated TP#1” in Section 4 of R1-2002754 for Section 12 of TS 38.213

Agreement:

Adopt “updated TP#2” in Section 4 of R1-2002754 for Section 6.1.2.2.3 of TS 38.214

Agreement:

Adopt “further updated TP#3” in Section 4 of R1-2002754 for Section 7 of TS 38.214

Agreement:

R1-2002908 [Draft] LS on intra-cell guard band configuration for NR-U	LG ELectronics

Agreement:

For a DL cell without intra-cell guard bands

The bit-width of available RB-set indicator (if configured) in DCI format 2_0 is equal to 1

UE does not expect to be configured with search space with freqMonitorLocations-r16

Agreement:

Adopt updated TP#1 in Section 4 of R1-2002955 for Section 11.1.1 of TS 38.213

Agreement:

Adopt TP#2 in Section 4 of R1-2002955 for Section 10.1 of TS 38.213

Agreement:

To support UL bandwidth part wider than 20 MHz with no intra-cell guard band, UE can be configured with zero GBs by setting GB width to 0 when configuring intraCellGuardBandUL-r16 (e.g., such gNB creates 4 RB-sets in 80MHz UL carrier).

Inform RAN2 of this agreement

Agreement:

For an UL carrier without intra-cell guard bands when the parameter useInterlacePUCCH-PUCCH is configured in any of BWP-UplinkCommon and BWP-UplinkDedicated:

The UL carrier can be configured with non-overlapping RB set(s)

For each RB set except for RB set 0, the starting CRB index is given by startCRB-r16

For RB set 0, the starting CRB index is given by

The UE expects nrofCRBs-r16 set to 0 for all GBs between two adjacent RB sets within the UL carrier.

The UE expects N RBs contained in each interlace of each RB set, wherein 10 <= N <= 11.

For 30 kHz SCS, the number of RBs within any RB set is between 50 and 55, and for 15 kHz SCS, the number of RBs within any RB set is between 100 and 110

Note: This configuration may be used for the case where transmission only occurs in a BWP if LBT is successful in all RB sets within the BWP (from RAN1#99 agreement)

Note: It’s up to gNB’s configuration to fulfill RAN4 requirement with e.g., on maximum transmission bandwidth configuration, spectral emission mask, and so on.

Note: In order to reuse existing PUCCH/PUSCH resource allocation mechanisms, this proposal applies to all supported carrier bandwidths except 10 MHz

FFS: Whether BWP can be configured to be partially overlapping with a RB set

[100b-e-NR-unlic-NRU-WB-02] Email discussion/approval on following issues related to CORESET and search space configuration by 4/24; if necessary, followed by endorsing the corresponding TPs by 4/29 – Seonwook (LGE)

PDCCH candidate and CCE mapping for search space configured with freqMonitorLocations-r16 (Note: Discussion on PDCCH dropping rule is deprioritized)

Corrections for CORESET and search space configured with freqMonitorLocations-r16

R1-2002755	Summary of email discussion [100b-e-NR-unlic-NRU-WB-02] on CORESET and search space configuration for NR-U wideband operation	Moderator (LG Electronics)

R1-2002956	Summary#2 of email discussion [100b-e-NR-unlic-NRU-WB-02] on CORESET and search space configuration for NR-U wideband operation	Moderator (LG Electronics)

Agreement:

Adopt the text proposal in Section 4 of R1-2002755 for Section 10.1 of TS 38.213

Agreement:

The number of PDCCH candidates per aggregation level configured by nrofCandidates or nrofCandidates-SFI within a SearchSpace IE applies to each of RB sets configured by freqMonitorLocations-r16.

nrofCandidates-SFI is 1 for a search space configured with freqMonitorLocations-r16

Agreement:

Adopt the text proposal in Section 2 of R1-2002956 for Section 10.1 of TS 38.213.

Others

R1-2001764	Discussion on the other remaining issues	OPPO

R1-2002576	Other Maintainance for NR-U	Huawei, HiSilicon