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-200xxxx	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 --------------------------------------

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)

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.

[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-200xxxx	Email discussion/approval on special states/indications in “available RB set indication” and COT duration indication/determination (NR-U DL Signals and Channels)	Moderator (Lenovo)

TP to capture agreement on reference starting point for determining remaining channel occupancy duration (by Apr 29). Feature lead to provide candidate TP.

[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)

Proposal:

For operation with shared spectrum channel access, if the UE is configured by higher layers to receive CSI-RS in a set of symbols in a slot, AND

if the UE is not configured with neither SFI-index field nor COT duration field; AND

if the UE does not detect a DCI format indicating to the UE to receive CSI-RS or PDSCH in a subset of symbols from the set of symbols,

the UE cancels the CSI-RS reception in the set of symbols in the slot.

RAN1 to clarify in RAN#101 whether RAN1 supports the case where UE is not configured with SFI-index field but with any of the following: COT duration, SS-switching trigger and RB-sets in DCI 2_0, and defines at least that CSI-RS are cancelled outside of indicated COT if the case is supported.

[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

Agreement:

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

Agreement:

Draft LS in [100bis-e-NR-unlic-NRU-DL_Signals_and_Channels-02_Draft-LS-Q5_v01] is agreed

Agreement:

The text proposal for Section 11.1.1 of TS38.213 in [100bis-e-NR-unlic-NRU-DL_Signals_and_Channels-04_Draft-TP-Q3-Q4_v01] is agreed.

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.

FFS points in agreement for DCI 0_0 in a CSS and corresponding TP for the entire agreement to be finalized by 4/29

Agreement:

Adopt TP#1 in Section 2.2 of [Draft R1-20xxxxx 100b-e-NR-unlic-NRU-ULSignalsChannels-01_v28 – Moderator] 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.

[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:

Support TP#1 in [Draft R1-20xxxxx 100b-e-NR-unlic-NRU-ULSignalsChannels-02_v15 – Moderator] 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.

Further discuss the alternatives, and if consensus can be reached this meeting, FL to update TP#1 by 4/30.

Agreement:

Support TP#3 in [Draft R1-20xxxxx 100b-e-NR-unlic-NRU-ULSignalsChannels-02_v15 – Moderator] for 38.214 Section 6.2.1

[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 [Draft R1-20xxxxx 100b-e-NR-unlic-NRU-ULSignalsChannels-03_v15 – Moderator] for 38.212 Section 6.3.1.6

Agreement:

Adopt TP#3 in [Draft R1-20xxxxx 100b-e-NR-unlic-NRU-ULSignalsChannels-03_v15 – Moderator] for 38.213 Section 9.2.2

Agreement:

Support TP#4,5,6,7 in [Draft R1-20xxxxx 100b-e-NR-unlic-NRU-ULSignalsChannels-03_v15 – Moderator] for 38.211,212,213,214 respectively

The following would be recommended for discussion until the 28th.

FL to update TP#1 according to company feedback. Further discuss updated TP#1 until 4/28.

FL to draft TP to capture the consensus that the UE shall expect that useInterlacePUCCH-PUSCH is configured the same way for all configured BWPs of a serving cell. Endorsement of TP by 4/28.

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)

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.

Would a text proposal be needed for the above or is the plan to leave it to the editor? If a TP is needed, it can be discussed until 4/28.

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.

Discuss the exact TP taking TP#9 in R1-2001534 as the starting point (until 4/28)

Discuss if the second change in TP7 of R1-2001534 is agreeable, possibly with some modifications until 4/28

[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)

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.

Further discussion on TPs for Sections 4.2.1 and 4.1.3 of 37.213 based on the inputs until 4/29

Further discussion on TPs based on TP1 in R1-2002247 and the comments in the email discussion until 4/29

Finalize TP for the editorial corrections for COT sharing indication in CG-UCI until 4/29

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

Proposal:

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 for the above.

Agreement:

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

Change citation of TS 38.104 in TS 38.213 Subclause 4.1 in relation to the definition of L_max to a citation of TS 38.213 Clause X, and further develop the TP for 38.213 Clause X until 4/29.

Prepare a TP for when/if a UE receives more than one SS/PBCH block that corresponds to the same SS/PBCH block index within a discovery burst transmission window.

[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

Issue 2.1

Proposal:

Identify cases where a combination of N and/or existing CP extension applied to msgA PUSCH can enable gap-less msgA.

Examples:

N = 0 when MsgA PUSCH has the same SCS and bandwith as MsgA PRACH

N = 1 and CP extension when MsgA PUSCH does not have the same SCS and bandwith as MsgA PRACH

Proposal:

Re-use existing N parameter values for NR-U msgA, i.e., N=2 for μ=0 or μ=1, N=4 for μ=2 or μ=3.

If no consensus, adopt existing Rel-16 values for N (i.e., N=2 for μ=0 or μ=1, N=4 for μ=2 or μ=3),.

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.

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).

I believe 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)

Develop TP by 4/29

[100b-e-NR-unlic-NRU-InitAccessProc-04] Email approval of the reply LS for R1-2001237 by 4/23 - Zhipeng (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-200xxxx	[DRAFT] LS Response on NR-U PRACH root sequence for 2-step RA	Ericsson

[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)

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

TP(s) according to the agreement above will be discussed until 4/29.

Prepare TP(s) for 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) until 4/29

Agreement:

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

Draft TPs for TS 38.213 Clause 9.2.3 based on TP draft in FL summary until 4/29

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).

Develop TP for TS 38.213 Clause 9.1.4 until 4/29, starting from the draft below or an equivalent TP using a reference to the SPS release.

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

[Enhanced Type-2 HARQ codebook (A7): T-DAI interpretation in case of TB and CBG sub-codebooks for the non-scheduled group.]

Proposal:

Clarify that codebook generation procedures in 38.213 clause 9.1.3.3 are applied separately for the first sub-codebook and the second sub-codebook

Handling of T-DAI for the non-scheduled group

Alt0: as in 38.213 v16.1.0

Alt1: Clarify that a UE is not expected to generate HARQ-ACK information if T-DAI for the non-scheduled group in DCI 1_1 is smaller than T-DAI received for any of the two sub-codebooks (TB, CBG) in earlier DCIs scheduling the same group if NFI was not toggled for the group.

Alt2: Introduce 2 additional bits for T-DAI field in DCI format 1_1 when NFI-TotalDAI-Included-r16 is configured and PDSCH-CodeBlockGroupTransmission is configured for at least one serving cell, i.e. T-DAI is provided for the non-scheduled group for both sub-codebooks

Alt3: UE is not expected to be configured with NFI-TotalDAI-Included-r16 when PDSCH-CodeBlockGroupTransmission is configured for at least one serving cell

Proposed conclusion:

No clarification is needed. TS38.213v16.1.0 clause 9.1.3.3 tells the UE to use the T-DAI signaled for the non-scheduled group for both sub-codebooks of the non-scheduled 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.

Develop a TP by 4/29

Agreement:

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

Develop a TP by 4/29

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.

Develop a TP by 4/29

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

Develop a TP by 4/29

[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.

Develop TP by 4/29

Proposal:

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)

Develop corresponding TP(s) until 4/28.

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

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)

[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

[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

Proposal1:

Discuss the following TP as starting point, including whether it is necessary given that similar text has been captured in 37.213

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

===================TP for 38.214 6.1.2.3.1================

6.1.2.3.1 Transport Block repetition for uplink transmissions of PUSCH repetition Type A with a configured grant

*** Unchanged text is omitted ***

For both Type 1 and Type 2 PUSCH transmissions with a configured grant, when the UE is configured with repK > 1, the UE shall repeat the TB across the repK consecutive slots applying the same symbol allocation in each slot, except if the UE is provided with higher layer parameters cg-nrofSlots-r16 and cg-nrofPUSCH-InSlot-r16, in which case the UE repeats the TB in the repK earliest consecutive transmission occasion candidates within the same configuration. For operation with shared spectrum channel access, where the UE is provided with higher layer parameters cg-nrofSlots-r16 and cg-nrofPUSCH-InSlot-r16 and repK>1, the UE shall perform the transmission of the first repetition in the earliest transmission occasion for which the related channel procedure described in 37.213 is successful. A Type 1 or Type 2 PUSCH transmission with a configured grant in a slot is omitted according to the conditions in Subclause 11.1 of [6, TS38.213].

*** Unchanged text is omitted ***

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

Proposal2:

Discuss whether following TP is needed or not.

---

If a UE receives an ACK for a given HARQ process in CG-DFI in a PDCCH ending in symbol i to terminate a transport block repetition in a PUSCH transmission with a configured grant on a given serving cell with the same HARQ process after symbol i, the UE is expected to terminate the repetition of the transport block in a PUSCH transmission starting from a symbol j if the gap between the end of PDCCH of symbol i and the start of the PUSCH transmission in symbol j is equal to or more than N2 symbols. The value N2 in symbols is determined according to the UE processing capability defined in Clause 6.4, and N2 and the symbol duration are based on the minimum of the subcarrier spacing corresponding to the PUSCH and the subcarrier spacing of the PDCCH indicating CG-DFI.

---

Proposal3:

Discuss the following TP as starting point,

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

The procedures described in this clause apply to PUSCH transmissions of PUSCH repetition Type A with a Type 1 or Type 2 configured grant.

If cg-RetransmissionTimer is provided, the redundancy version for uplink transmission with a configured grant is determined by the UE.

The higher layer parameter repK-RV defines the redundancy version pattern to be applied to the repetitions. If the parameter repK-RV is not provided in the configuredGrantConfig and cg-RetransmissionTimer is not provided, the redundancy version for uplink transmissions with a configured grant shall be set to 0. Otherwise If the parameter repK-RV is provided in the configuredGrantConfig and cg-RetransmissionTimer is not provided, for the nth transmission occasion among K repetitions, n=1, 2, …, K, it is associated with (mod(n-1,4)+1)th value in the configured RV sequence. If a configured grant configuration is configured with Configuredgrantconfig-StartingfromRV0 set to ‘off’, the initial transmission of a transport block may only start at the first transmission occasion of the K repetitions. Otherwise, the initial transmission of a transport block may start at

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

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

Agreement:

Adopt “updated TP#1” in Section 2 of R1-200xxxx (summary document v27) for Section 12 of TS 38.213

Agreement:

Adopt “updated TP#2” in Section 2 of R1-200xxxx (summary document v27) for Section 6.1.2.2.3 of TS 38.214

Agreement:

Adopt “further updated TP#3” in Section 2 of R1-200xxxx (summary document v27) for Section 7 of TS 38.214

Agreement:

R1-200xxxx [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

Does the above agreement need a TP? If so, it would be good to finalize this by 4/28.

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

[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

Agreement:

Adopt the text proposal in Section 2 of R1-200xxxx ([WB-02] PDCCH_ver19_Moderator) 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

Others

R1-2001764	Discussion on the other remaining issues	OPPO

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