3GPP TSG-RAN WG2 Meeting #123	R2-10xxxxx

Toulouse, France, August, 2023

Agenda Item:	7.20.1

Source:	Ericsson

Title:	Post 123 MIMOevo RRC

Document for:	Discussion, Decision

Introduction

[Post123][851][MIMOevo] RRC running CR for MIMO evo (Ericsson)

Scope: Long email discussions after the meeting, to update the RRC running CR for Rel-18 MIMO evo, taking into account a) current noted running CR R2-2308342, b) related contributions to this RAN2 meeting, and c) additional input from R1 (if needed/if any), as well as comments received during this email discussions

Intended outcome: Email discussion report if needed, and updated RRC running CR; can also list some open issues in the email report, as an input to the next step discussions

Deadline: Long

Sept 22th	Deadline Long Email Discussions. Long email discussions are in normal case expected to start at or after Sept 1st

Contact Information

Respondents to the email discussion are kindly asked to fill in the following table.

Company	Name	Email Address
Ericsson	Helka-Liina Määttänen	Helka-liina.maattanen@ericsson.com
NTT Docomo	Riki Okawa	riki.ookawa.rp@nttdocomo.com
Samsung	Shiyang Leng	shiyang.leng@samsung.com
CATT	zhangbufang	zhangbufang@catt.cn
ZTE	Fei Dong	Dong.fei@zte.com.cn

mTRP uTCI

RAN2 has received the L1 parameters in R1-2306271. The running CR captures most of the parameters in R2-2308342 and in R2-2308358 the RAN1 excel with rapporteur comments together with the field name used in the running CR can be found.

Parameter ControlResourceSet

RAN2 Parent IE	Parameter name in the spec	New or existing?	Description	Value range	Comment
ControlResourceSet	applyIndicatedTCIState-r18	New	This parameter is used to inform the UE shall apply the first, the second, both, or none of the indicated joint/DL TCI states to PDCCH reception(s) a CORESET for S-DCI based MTRP operation	{the first, the second, both, none}	From RAN1 perspective, it is up to RAN2 to introduce a new RRC parameter with values {the first, the second, both} and use it along with the legacy parameter followUnifiedTCIstate or introduce a new RRC parameter with values {the first, the second, both, none} without using the legacy parameter followUnifiedTCIstate.

In Running RRC CR the parameter applyIndicatedTCIState-r18 is implemented as follows in IE ControlResourceSet:

ControlResourceSet ::= SEQUENCE {

controlResourceSetId ControlResourceSetId,

frequencyDomainResources BIT STRING (SIZE (45)),

duration INTEGER (1..maxCoReSetDuration),

cce-REG-MappingType CHOICE {

interleaved SEQUENCE {

reg-BundleSize ENUMERATED {n2, n3, n6},

interleaverSize ENUMERATED {n2, n3, n6},

shiftIndex INTEGER(0..maxNrofPhysicalResourceBlocks-1) OPTIONAL -- Need S

},

nonInterleaved NULL

},

precoderGranularity ENUMERATED {sameAsREG-bundle, allContiguousRBs},

tci-StatesPDCCH-ToAddList SEQUENCE(SIZE (1..maxNrofTCI-StatesPDCCH)) OF TCI-StateId OPTIONAL, -- Cond NotSIB-initialBWP

tci-StatesPDCCH-ToReleaseList SEQUENCE(SIZE (1..maxNrofTCI-StatesPDCCH)) OF TCI-StateId OPTIONAL, -- Cond NotSIB-initialBWP

tci-PresentInDCI ENUMERATED {enabled} OPTIONAL, -- Need S

pdcch-DMRS-ScramblingID INTEGER (0..65535) OPTIONAL, -- Need S

...,

[[

rb-Offset-r16 INTEGER (0..5) OPTIONAL, -- Need S

tci-PresentDCI-1-2-r16 INTEGER (1..3) OPTIONAL, -- Need S

coresetPoolIndex-r16 INTEGER (0..1) OPTIONAL, -- Need S

controlResourceSetId-v1610 ControlResourceSetId-v1610 OPTIONAL -- Need S

]],

[[

followUnifiedTCI-State-r17 ENUMERATED {enabled} OPTIONAL -- Need R

]],

[[

applyIndicatedTCI-State-r18 ENUMERATED {first, second, both} OPTIONAL -- Cond FollowUTCI

]]

}

ControlResourceSet field descriptions
applyIndicatedTCI-State This field indicates, for PDCCH reception on this CORESET, if UE applies the first, the second or both "indicated" DL only TCI or joint TCI as specified in TS 38.214 [19], clause 5.1.5.

Conditional Presence	Explanation
NotSIB-initialBWP	The field is absent in SIB1/SIB20 and in the PDCCH-ConfigCommon of the initial BWP in ServingCellConfigCommon, if SIB1/SIB20 is broadcasted. Otherwise, it is optionally present, Need N.
FollowUTCI	The field is absent if the field followUnifiedTCI-State is present. Otherwise, it is optionally present, Need R.

The implementation assumes that "none" has same meaning as field absent and value “none” is not separately implemented. From code perspective, difference is that if we have value “none” explicitly and the condition FollowUTCI, the UE can never be configured with “none” and the parameter followUnifiedTCI-State present.

Question 1 Please state if you agree with the above implementation of parameter ControlResourceSet ?

Company	Yes/no	Comments
Ericsson	yes
Docomo	Yes
Samsung	See comment	In the field description, RAN1 reference for PDCCH reception is TS 38.213 [13], clause 10.1. In our understanding, RAN1’s options are 1) Using followUnifiedTCI-State-r17 + applyIndicatedTCI-State (first, second, both) 2) Not using followUnifiedTCI-State-r17 + applyIndicatedTCI-State (first, second, both, none) Functional wise, reusing or not reusing the Rel-17 parameter followUnifiedTCI-State-r17 should be the same. We wonder if Rel-17 followUnifiedTCI-State-r17 would be the pre-requisition of supporting Rel-18 enhanced unified TCI framework for sDCI based mTRP operation. If not, we can go with option2 which is simpler, and for option 2 the absence of applyIndicatedTCI-State can indicate “none”. We are flexible to follow majority view.
CATT	Agree with SS, option 2 is clearer, but no strong view. BTW, if we go with option 1, we may also need to specify something in the R17 field followUnifiedTCI-State to represent the “none” case.
ZTE	Yes	It seems the option 2 is determined to be implemented. We are fine

Conclusion:

Seems that the R17 field followUnifiedTCI-State is to be used for sTRP only, similar to SRS. Hence these tso parameters should not be configured at the same time and it is cleaner to assume:

2)	Not using followUnifiedTCI-State-r17 + applyIndicatedTCI-State (first, second, both, none)

Hence, to add value ‘None’ but to keep the condition.

Parameter applyIndicatedTCIState-r18 for PUCCH

RAN2 Parent IE	Parameter name in the spec	New or existing?	Description	Value range	Comment
PUCCH-Resource and PUCCH-ResourceGroup-r16	applyIndicatedTCIState-r18	New	This parameter is used to inform the UE shall apply the first, the second, or both of the indicated joint/UL TCI states to PUCCH transmission(s) corresponding to a PUCCH resource or PUCCH resource group. For M-DCI based MTRP operation, the candidate values can be {the first, the second}, and the first and the second indicated joint/UL TCI states correspond to the indicated joint/UL TCI states specific to coresetPoolIndex value 0 and value 1, respectively.	{the first, the second, both}	From RAN1 perspective, it is up to RAN2 to introduce a new RRC parameter with values {the first, the second, both} and use it along with the legacy parameter followUnifiedTCIstate or introduce a new RRC parameter with values {the first, the second, both, none} without using the legacy parameter followUnifiedTCIstate.

The L1 parameter excel asks to enable configuration of the parameter applyIndicatedTCIState-r18 for a PUCCH Resource via the resource itself and additionally via the PUCCH resource group. The implementation enables to configure the parameter applyIndicatedTCIState-r18 for a PUCCH Resource with different values for one UE in one RRC configuration unless additional restrictions are added. This would result in an error case.

One PUCCH resource should not be configured with two different way for applyIndicatedTCIState-r18 operation for one UE in one RRC configuration.

The intention to enable both per resource and per group configuration seems to be saving of some RRC bits in some possible RRC configurations. It is suggested that RAN2 considers whether it is enough to configure the parameter per resource as that results in simpler and less error prone ASN1 code.

Question 2 Please state if you agree it is enough to configure the parameter applyIndicatedTCIState-r18 per PUCCH resource?

Company	Yes/no	Comments
Ericsson	yes
Docomo	Yes	Configuration per PUCCH resource looks enough. RAN1 agreed to leave details on signalling to RAN2, thus we can decide not to introduce per-PUCCH-resource-group parameter. Agreement On unified TCI framework extension for S-DCI based MTRP, use RRC configuration to inform that the UE shall apply the first one, the second one, or both of the indicated joint/UL TCI states to a PUCCH resource/group Note: Detail of the RRC configuration is left to RAN2 design
Samsung	Yes	According to the current specification, PUCCH-ResourceGroup is just a list for adding and releasing groups of PUCCH resources that can be updated simultaneously for spatial relations with a MAC CE. It means PUCCH-ResourceGroup is just a group of PUCCH-Resource having the similar functionalities so configure the parameter applyIndicatedTCIState-r18 per PUCCH resource (applying it for both PUCCH-resource and PUCCH-ResourceGroup where this field is configured) is enough.
CATT	Yes	Agree with the rapporteur.
ZTE	Yes

Conclusion

Configure the parameter applyIndicatedTCIState-r18 per PUCCH resource (applying it for both PUCCH-resource and PUCCH-ResourceGroup where this field is configured) is enough.

Parameter applyIndicatedTCIState-r18 for CSI

RAN2 Parent IE	Parameter name in the spec	New or existing?	Description	Value range	Comment
CSI-AssociatedReportConfigInfo	applyIndicatedTCIState-r18	New	This parameter is used to inform the UE shall apply the first or the second indicated joint/DL TCI states to an aperiodic CSI-RS resource or an aperiodic CSI-RS resource set. For M-DCI based MTRP operation, the first and the second indicated joint/DL TCI states correspond to the indicated joint/DL TCI states specific to coresetPoolIndex value 0 and value 1, respectively.	{the first, the second}

The parameter applyIndicatedTCIState-r18 is implemented as follows in IE CSI-AssociatedReportConfigInfo:

CSI-AssociatedReportConfigInfo ::= SEQUENCE {

reportConfigId CSI-ReportConfigId,

resourcesForChannel CHOICE {

nzp-CSI-RS SEQUENCE {

resourceSet INTEGER (1..maxNrofNZP-CSI-RS-ResourceSetsPerConfig),

qcl-info SEQUENCE (SIZE(1..maxNrofAP-CSI-RS-ResourcesPerSet)) OF TCI-StateId

OPTIONAL -- Cond Aperiodic

},

csi-SSB-ResourceSet INTEGER (1..maxNrofCSI-SSB-ResourceSetsPerConfig)

},

csi-IM-ResourcesForInterference INTEGER(1..maxNrofCSI-IM-ResourceSetsPerConfig) OPTIONAL, -- Cond CSI-IM-ForInterference

nzp-CSI-RS-ResourcesForInterference INTEGER (1..maxNrofNZP-CSI-RS-ResourceSetsPerConfig) OPTIONAL, -- Cond NZP-CSI-RS-ForInterference

...,

[[

resourcesForChannel2-r17 CHOICE {

nzp-CSI-RS2-r17 SEQUENCE {

resourceSet2-r17 INTEGER (1..maxNrofNZP-CSI-RS-ResourceSetsPerConfig),

qcl-info2-r17 SEQUENCE (SIZE(1..maxNrofAP-CSI-RS-ResourcesPerSet)) OF TCI-StateId

OPTIONAL -- Cond Aperiodic

},

csi-SSB-ResourceSet2-r17 INTEGER (1..maxNrofCSI-SSB-ResourceSetsPerConfigExt)

} OPTIONAL, -- Cond NoUnifiedTCI

csi-SSB-ResourceSetExt INTEGER (1..maxNrofCSI-SSB-ResourceSetsPerConfigExt) OPTIONAL -- Need R

]],

[[

applyIndicatedTCI-State-r18 ENUMERATED {first, second} OPTIONAL -- Need R

]]

}

CSI-AssociatedReportConfigInfo field descriptions
ap-CSI-MultiplexingMode Indicates if the behavior of transmitting aperiodic CSI on the first PUSCH repetitions corresponding to two SRS resource sets configured in srs-ResourceSetToAddModList or srs-ResourceSetToAddModListDCI-0-2 with usage 'codebook' or 'noncodebook' is enabled or not.
applyIndicatedTCI-State This field indicates, for an aperiodic CSI-RS resource set, if UE applies the first or the second "indicated" DL only TCI or joint TCI as specified in TS 38.214 [19], clause 5.1.5. If the field coresetPoolIndex is configured in IE controlResourceSet used to schedule the aperiodic CSI-resource set, the value ‘first’ corresponds to the “indicated” joint/UL TCI states specific to coresetPoolIndex value 0 and the value ‘second’ correspond to the value 1, respectively.

The coresetPoolIndex is per BWP and aperiodic CSI-RS resource is not per BWP as CSI-MeasConfig defined NZP-CSI-RS resources per serving cell. Hence the field description is formulated as “the coreset which is used to schedule the DCI triggering the aperiodic CSI-resource set”.

Further, in R2-2307696 Samsung, a capability related aspect is brought up that UE might support per resource or per resource set indication of applyIndicatedTCIState:

According to the RAN1 agreements, the new UE capability to indicate the supporting the Rel-18 TCI framework for sDCI based mTRP operation on AP CSI-RS. UE indicate whether it supports ‘per CSI-RS resource set’ or ‘per CSI-RS resource’

Agreement in RAN1#113 On unified TCI framework extension for M-DCI based MTRP, an RRC configuration can be provided to an aperiodic CSI-RS resource set or a CSI-RS resource in an aperiodic CSI-RS resource set to inform that the UE shall apply the first or the second indicated joint/DL TCI state to the aperiodic CSI-RS resource set or to the CSI-RS resource in the aperiodic CSI-RS resource set, if the aperiodic CSI-RS resource set for CSI/BM is configured to follow unified TCI state The first and the second indicated joint/DL TCI states correspond to the indicated joint/DL TCI states specific to coresetPoolIndex value 0 and value 1, respectively. Above applies at least if the offset between the last symbol of the PDCCH carrying the triggering DCI and the first symbol of the aperiodic CSI-RS resources in the aperiodic CSI-RS resource set is equal to or larger than a threshold (if the threshold is needed) Support of ‘per CSI-RS resource set’ or ‘per CSI-RS resource’ RRC configuration is up to UE capability

For detail RRC signaling support, RAN2 should consider these aspects. From our understanding, RAN1 suggested the new RRC parameter (applyIndicatedTCIState-r18) in CSI-AssociatedReportConfigInfo IE [3], it means the new RRC parameter is applied to CSI-RS resource set rather than the CSI-RS resource. In this case, how to handle supporting per CSI-RS resource should be further studied. One option would be configuring the new RRC parameter in both places (csi-SSB-ResourceSet and csi-SSB-Resource).

Hence, different from the excel input which is currently implemented, there is a suggestion to instead configure the parameter in both csi-SSB-ResourceSet and csi-SSB-Resource. However, as the feature is only for aperiodic CSI, the configuration should be specific to AP CSI. One option is to extend the current configuration in IE CSI-AssociatedReportConfigInfo to a list such that it can apply to either the set or each resource individually.

Question 3 Please state if you agree the above suggested implementation of parameter applyIndicatedTCIState-r18 in IE CSI-AssociatedReportConfigInfo or to extend it as a list?

Company	Answer	Comments
Ericsson	Consider extending to a list
Samsung	Extend to a list	UE feature list (R1-2308521) includes UE capability with candidate value {per resource, per resource set, both}. need to allow NW to configure this field for either per resource, per resource set, or both based on the UE capability. Another point is the relationship between applyIndicatedTCIState-r18 and qcl-info. If applyIndicatedTCIState-r18 is present, NW should not configure qcl-info for each CSI resource.
CATT	Extend to a list, but	Some clarification may be needed for the field qcl-info. In R17 unified TCI for sTRP or ICBM, absent of the field means to apply the unified TCI state (only one). But for R18 mTRP, UE need to further decide the corresponding TCI state to be applied based on the newly introduced R18 IE. qcl-info, qcl-info2 List of references to TCI-States for providing the QCL source and QCL type for each NZP-CSI-RS-Resource listed in nzp-CSI-RS-Resources of the NZP-CSI-RS-ResourceSet indicated by resourceSet within nzp-CSI-RS. Each TCI-StateId refers to the TCI-State which has this value for tci-StateId and is defined in tci-StatesToAddModList or in dl-OrJointTCI-StateList in the PDSCH-Config included in the BWP-Downlink corresponding to the serving cell and to the DL BWP to which the resourcesForChannelMeasurement (in the CSI-ReportConfig indicated by reportConfigId above) belong to. First entry in qcl-info corresponds to first entry in nzp-CSI-RS-Resources of that NZP-CSI-RS-ResourceSet, second entry in qcl-info corresponds to second entry in nzp-CSI-RS-Resources, and so on (see TS 38.214 [19], clause 5.2.1.5.1). When this field is absent for aperiodic CSI RS, the UE shall use QCL information included in the "indicated" DL only/Joint TCI state as specified in TS 38.214
ZTE	Okay with conclusion	Regarding the samsungs comments, we are not crystal clear about the the meaning of ‘none’ in the UE capability? Does it mean UE does not support the AP-RS to follow unified TCI state? If so, then how about the case of CORESET, PUCCH, etc..

Conclusion

Following choice structure was made in order to differentiate on element and set, although it may be that the list needs to be given for all elements. This can be revisited.

applyIndicatedTCI-State-r18 CHOICE {

perset-r18 ENUMERATED {first, second}

perresource-r18 SEQUENCE (SIZE(1..maxNrofAP-CSI-RS-ResourcesPerSet)) OF ENUMERATED {first, second}

For QCL, to follow principle we used in Rel-17 I added(can be revisited):

qcl-info, qcl-info2

List of references to TCI-States for providing the QCL source and QCL type for each NZP-CSI-RS-Resource listed in nzp-CSI-RS-Resources of the NZP-CSI-RS-ResourceSet indicated by resourceSet within nzp-CSI-RS. Each TCI-StateId refers to the TCI-State which has this value for tci-StateId and is defined in tci-StatesToAddModList or in dl-OrJointTCI-StateList in the PDSCH-Config included in the BWP-Downlink corresponding to the serving cell and to the DL BWP to which the resourcesForChannelMeasurement (in the CSI-ReportConfig indicated by reportConfigId above) belong to. First entry in qcl-info corresponds to first entry in nzp-CSI-RS-Resources of that NZP-CSI-RS-ResourceSet, second entry in qcl-info corresponds to second entry in nzp-CSI-RS-Resources, and so on (see TS 38.214 [19], clause 5.2.1.5.1). When this field is absent for aperiodic CSI RS, the UE shall use QCL information included in the "indicated" DL only/Joint TCI state as specified in TS 38.214 or in TS 38.213 [13], clause 10.1

Parameter applyIndicatedTCIState-r18 for SRS

RAN2 Parent IE	Parameter name in the spec	New or existing?	Description	Value range	Comment
SRS-ResourceSet	applyIndicatedTCIState-r18	New	This parameter is used to inform the UE shall apply the first or the second indicated joint/UL TCI states to an SRS resource set. For M-DCI based MTRP operation, the first and the second indicated joint/UL TCI states correspond to the indicated joint/UL TCI states specific to coresetPoolIndex value 0 and value 1, respectively.	{the first, the second}	When two SRS resource sets for CB/NCB are configured, the UE does not expect the following 。 to be configured with the first indicated UL/joint TCI state which is to be applied to the second SRS resource set 。 to be configured with the second indicated UL/joint TCI state which is to be applied to the first SRS resource set

The parameter applyIndicatedTCIState-r18 is implemented in IE SRS-ResourceSet following the excel. The excel did not indicate any relation with this parameter and the followUnifiedTCI-StateSRS and hence none is implemented. There may be some doubt whether there is actually a need to specify a relation between these two parameters.

Question 4 Please state if you think there is a need to specify relation the parameter applyIndicatedTCIState-r18 and the followUnifiedTCI-StateSRS in IE SRS-ResourceSet?

Company	Yes/no	Comments
Ericsson	No(?)
Docomo	Yes	Is it the same case as 3.1? Guess the unified approach with 3.1 is straightforward. [Ericsson] Initially I added the restriction but got comment from our Ran1 delegate that it is not needed. Hope other companies could check with their RAN1.
Samsung	No	applyIndicatedTCIState-r18 and followUnifiedTCI-StateSRS are configured separately for r18 mTRP and r17 sTRP respectively, no need to link the two.
CATT	No, and	We need to add some clarification on the absence condition for the field srs-TCI-State in the field description.
ZTE	Okay for the conclusion

Conlcusion

Seems the same limitatation exists as in coreset, applyIndicatedTCIState-r18 and followUnifiedTCI-StateSRS are configured separately for r18 mTRP and r17 sTRP. Hence, it would be good to place the same restriction that these are not configured together. -Cond is added:

FollowUTCI	The field is absent if the field followUnifiedTCI-State is present. Otherwise, it is optionally present, Need R.

CSI-CJT

RAN2 Parent IE	Parameter name in the spec	New or existing?	Description	Value range	Comment
CSI-ReportConfig	numberOfSDCombinations	New	N_L: Number of combinations for (L1,L2,…,LNTRP)	1,2,4	May not be needed and, depending on RAN2 design, can be inferred from the {Ln} list
CSI-ReportConfig	numberOfSDCombinations-PS	New	N_L: Number of combinations for (alpha1,alpha2,…,alphaNTRP)	1,2,4	May not be needed and, depending on RAN2 design, can be inferred from the {alphan} list

Question 4 Please state if you agree that values for numberOfSDCombinations and numberOfSDCombinations-PS can be derived from list size paramCombination-CJT-L-r18 or paramCombination-CJT-PS-aplha-r18?

Company	Yes/no	Comments
Ericsson	Yes
Docomo	Yes	Seems ok, but paramCombination-CJT-PS-aplha-r18 has not been included in the parameter list. We can wait before concluding and keep not implementing N_L (moderator’s suggestion is not to implement N_L parameter though). [Ericsson] I see it in row 30. Are we talking about same parameter? [Docomo] That is my bad, I missed it. Thanks!
Samsung	Yes	There two parameters are not needed.
CATT	Yes
ZTE	Yes

Conlcusion

Do not use numberOfSDCombinations and numberOfSDCombinations-PS

CSI-TDCP

RAN2 Parent IE	Parameter name in the spec	New or existing?	Description	Value range	Comment
CSI-ReportConfig	Y	New	1,2,3,4
CSI-ReportConfig	Phase	New	Phase reporting	{ON,OFF}
CSI-ReportConfig	D	New	delay value(s) for Y delay/lag values Candidate values for a given delay: 4 symbols, 1,2,3,4,5,6,10 slots Note: D=10 slots is only applicable to SCS >=30kHz	[{D1,…,DY}]	[113] Agreement For the Rel-18 TRS-based TDCP reporting, for a configured value of Y and a set of configured delay values {D1, …, DY}, for the n-th delay Dn (n=1, …, Y), the respective TDCP calculation is defined as wideband normalized correlation between two TRS symbols separated by Dn symbols

In Running RRC CR the following is implemented:

–	CSI-ReportConfig

The IE CSI-ReportConfig is used to configure a periodic or semi-persistent report sent on PUCCH on the cell in which the CSI-ReportConfig is included, or to configure a semi-persistent or aperiodic report sent on PUSCH triggered by DCI received on the cell in which the CSI-ReportConfig is included (in this case, the cell on which the report is sent is determined by the received DCI). See TS 38.214 [19], clause 5.2.1.

CSI-ReportConfig information element

-- ASN1START

-- TAG-CSI-REPORTCONFIG-START

CSI-ReportConfig ::= SEQUENCE {

reportConfigId CSI-ReportConfigId,

carrier ServCellIndex OPTIONAL, -- Need S

resourcesForChannelMeasurement CSI-ResourceConfigId,

csi-IM-ResourcesForInterference CSI-ResourceConfigId OPTIONAL, -- Need R

nzp-CSI-RS-ResourcesForInterference CSI-ResourceConfigId OPTIONAL, -- Need R

reportConfigType CHOICE {

periodic SEQUENCE {

reportSlotConfig CSI-ReportPeriodicityAndOffset,

pucch-CSI-ResourceList SEQUENCE (SIZE (1..maxNrofBWPs)) OF PUCCH-CSI-Resource

},

semiPersistentOnPUCCH SEQUENCE {

reportSlotConfig CSI-ReportPeriodicityAndOffset,

pucch-CSI-ResourceList SEQUENCE (SIZE (1..maxNrofBWPs)) OF PUCCH-CSI-Resource

},

semiPersistentOnPUSCH SEQUENCE {

reportSlotConfig ENUMERATED {sl5, sl10, sl20, sl40, sl80, sl160, sl320},

reportSlotOffsetList SEQUENCE (SIZE (1.. maxNrofUL-Allocations)) OF INTEGER(0..32),

p0alpha P0-PUSCH-AlphaSetId

},

aperiodic SEQUENCE {

reportSlotOffsetList SEQUENCE (SIZE (1..maxNrofUL-Allocations)) OF INTEGER(0..32)

}

},

reportQuantity CHOICE {

none NULL,

cri-RI-PMI-CQI NULL,

cri-RI-i1 NULL,

cri-RI-i1-CQI SEQUENCE {

pdsch-BundleSizeForCSI ENUMERATED {n2, n4} OPTIONAL -- Need S

},

cri-RI-CQI NULL,

cri-RSRP NULL,

ssb-Index-RSRP NULL,

cri-RI-LI-PMI-CQI NULL

},

reportFreqConfiguration SEQUENCE {

cqi-FormatIndicator ENUMERATED { widebandCQI, subbandCQI } OPTIONAL, -- Need R

pmi-FormatIndicator ENUMERATED { widebandPMI, subbandPMI } OPTIONAL, -- Need R

csi-ReportingBand CHOICE {

subbands3 BIT STRING(SIZE(3)),

subbands4 BIT STRING(SIZE(4)),

subbands5 BIT STRING(SIZE(5)),

subbands6 BIT STRING(SIZE(6)),

subbands7 BIT STRING(SIZE(7)),

subbands8 BIT STRING(SIZE(8)),

subbands9 BIT STRING(SIZE(9)),

subbands10 BIT STRING(SIZE(10)),

subbands11 BIT STRING(SIZE(11)),

subbands12 BIT STRING(SIZE(12)),

subbands13 BIT STRING(SIZE(13)),

subbands14 BIT STRING(SIZE(14)),

subbands15 BIT STRING(SIZE(15)),

subbands16 BIT STRING(SIZE(16)),

subbands17 BIT STRING(SIZE(17)),

subbands18 BIT STRING(SIZE(18)),

...,

subbands19-v1530 BIT STRING(SIZE(19))

} OPTIONAL -- Need S

} OPTIONAL, -- Need R

timeRestrictionForChannelMeasurements ENUMERATED {configured, notConfigured},

timeRestrictionForInterferenceMeasurements ENUMERATED {configured, notConfigured},

codebookConfig CodebookConfig OPTIONAL, -- Need R

dummy ENUMERATED {n1, n2} OPTIONAL, -- Need R

groupBasedBeamReporting CHOICE {

enabled NULL,

disabled SEQUENCE {

nrofReportedRS ENUMERATED {n1, n2, n3, n4} OPTIONAL -- Need S

}

},

cqi-Table ENUMERATED {table1, table2, table3, table4-r17} OPTIONAL, -- Need R

subbandSize ENUMERATED {value1, value2},

non-PMI-PortIndication SEQUENCE (SIZE (1..maxNrofNZP-CSI-RS-ResourcesPerConfig)) OF PortIndexFor8Ranks OPTIONAL, -- Need R

...,

[[

semiPersistentOnPUSCH-v1530 SEQUENCE {

reportSlotConfig-v1530 ENUMERATED {sl4, sl8, sl16}

} OPTIONAL -- Need R

]],

[[

semiPersistentOnPUSCH-v1610 SEQUENCE {

reportSlotOffsetListDCI-0-2-r16 SEQUENCE (SIZE (1.. maxNrofUL-Allocations-r16)) OF INTEGER(0..32) OPTIONAL, -- Need R

reportSlotOffsetListDCI-0-1-r16 SEQUENCE (SIZE (1.. maxNrofUL-Allocations-r16)) OF INTEGER(0..32) OPTIONAL -- Need R

} OPTIONAL, -- Need R

aperiodic-v1610 SEQUENCE {

reportSlotOffsetListDCI-0-2-r16 SEQUENCE (SIZE (1.. maxNrofUL-Allocations-r16)) OF INTEGER(0..32) OPTIONAL, -- Need R

reportSlotOffsetListDCI-0-1-r16 SEQUENCE (SIZE (1.. maxNrofUL-Allocations-r16)) OF INTEGER(0..32) OPTIONAL -- Need R

} OPTIONAL, -- Need R

reportQuantity-r16 CHOICE {

cri-SINR-r16 NULL,

ssb-Index-SINR-r16 NULL

} OPTIONAL, -- Need R

codebookConfig-r16 CodebookConfig-r16 OPTIONAL -- Need R

]],

[[

cqi-BitsPerSubband-r17 ENUMERATED {bits4} OPTIONAL, -- Need R

groupBasedBeamReporting-v1710 SEQUENCE {

nrofReportedGroups-r17 ENUMERATED {n1, n2, n3, n4}

} OPTIONAL, -- Need R

codebookConfig-r17 CodebookConfig-r17 OPTIONAL, -- Need R

sharedCMR-r17 ENUMERATED {enable} OPTIONAL, -- Need R

csi-ReportMode-r17 ENUMERATED {mode1, mode2} OPTIONAL, -- Need R

numberOfSingleTRP-CSI-Mode1-r17 ENUMERATED {n0, n1, n2} OPTIONAL, -- Need R

reportQuantity-r17 CHOICE {

cri-RSRP-Index-r17 NULL,

ssb-Index-RSRP-Index-r17 NULL,

cri-SINR-Index-r17 NULL,

ssb-Index-SINR-Index-r17 NULL

} OPTIONAL -- Need R

]],

[[

semiPersistentOnPUSCH-v1720 SEQUENCE {

reportSlotOffsetList-r17 SEQUENCE (SIZE (1.. maxNrofUL-Allocations-r16)) OF INTEGER(0..128) OPTIONAL, -- Need R

reportSlotOffsetListDCI-0-2-r17 SEQUENCE (SIZE (1.. maxNrofUL-Allocations-r16)) OF INTEGER(0..128) OPTIONAL, -- Need R

reportSlotOffsetListDCI-0-1-r17 SEQUENCE (SIZE (1.. maxNrofUL-Allocations-r16)) OF INTEGER(0..128) OPTIONAL -- Need R

} OPTIONAL, -- Need R

aperiodic-v1720 SEQUENCE {

reportSlotOffsetList-r17 SEQUENCE (SIZE (1.. maxNrofUL-Allocations-r16)) OF INTEGER(0..128) OPTIONAL, -- Need R

reportSlotOffsetListDCI-0-2-r17 SEQUENCE (SIZE (1.. maxNrofUL-Allocations-r16)) OF INTEGER(0..128) OPTIONAL, -- Need R

reportSlotOffsetListDCI-0-1-r17 SEQUENCE (SIZE (1.. maxNrofUL-Allocations-r16)) OF INTEGER(0..128) OPTIONAL -- Need R

} OPTIONAL -- Need R

]],

[[

codebookConfig-v1730 CodebookConfig-v1730 OPTIONAL -- Need R

]],

[[

groupBasedBeamReporting-r18 SEQUENCE {

nrofReportedGroups-r18 ENUMERATED {n1, n2, n3, n4}

} OPTIONAL, -- Need R

reportQuantity-r18 TDCP-r18 OPTIONAL, -- Need R

codebookConfig-r18 CodebookConfig-r18 OPTIONAL -- Need R

]]

}

CSI-ReportPeriodicityAndOffset ::= CHOICE {

slots4 INTEGER(0..3),

slots5 INTEGER(0..4),

slots8 INTEGER(0..7),

slots10 INTEGER(0..9),

slots16 INTEGER(0..15),

slots20 INTEGER(0..19),

slots40 INTEGER(0..39),

slots80 INTEGER(0..79),

slots160 INTEGER(0..159),

slots320 INTEGER(0..319)

}

PUCCH-CSI-Resource ::= SEQUENCE {

uplinkBandwidthPartId BWP-Id,

pucch-Resource PUCCH-ResourceId

}

PortIndexFor8Ranks ::= CHOICE {

portIndex8 SEQUENCE{

rank1-8 PortIndex8 OPTIONAL, -- Need R

rank2-8 SEQUENCE(SIZE(2)) OF PortIndex8 OPTIONAL, -- Need R

rank3-8 SEQUENCE(SIZE(3)) OF PortIndex8 OPTIONAL, -- Need R

rank4-8 SEQUENCE(SIZE(4)) OF PortIndex8 OPTIONAL, -- Need R

rank5-8 SEQUENCE(SIZE(5)) OF PortIndex8 OPTIONAL, -- Need R

rank6-8 SEQUENCE(SIZE(6)) OF PortIndex8 OPTIONAL, -- Need R

rank7-8 SEQUENCE(SIZE(7)) OF PortIndex8 OPTIONAL, -- Need R

rank8-8 SEQUENCE(SIZE(8)) OF PortIndex8 OPTIONAL -- Need R

},

portIndex4 SEQUENCE{

rank1-4 PortIndex4 OPTIONAL, -- Need R

rank2-4 SEQUENCE(SIZE(2)) OF PortIndex4 OPTIONAL, -- Need R

rank3-4 SEQUENCE(SIZE(3)) OF PortIndex4 OPTIONAL, -- Need R

rank4-4 SEQUENCE(SIZE(4)) OF PortIndex4 OPTIONAL -- Need R

},

portIndex2 SEQUENCE{

rank1-2 PortIndex2 OPTIONAL, -- Need R

rank2-2 SEQUENCE(SIZE(2)) OF PortIndex2 OPTIONAL -- Need R

},

portIndex1 NULL

}

PortIndex8::= INTEGER (0..7)

PortIndex4::= INTEGER (0..3)

PortIndex2::= INTEGER (0..1)

TDCP-r18 ::= SEQUENCE {

delayDSetofLenghtY-r18 SEQUENCE (SIZE (1.. maxNrofdelayD-r18)) OF DelayD,

phaseReporting-r18 ENUMERATED {enable} OPTIONAL -- Need R

}

DelayD ::= ENUMERATED { symb4, slot1, slot2, slot3, slot4, slot5, slot6, slot10 }

-- TAG-CSI-REPORTCONFIG-STOP

-- ASN1STOP

TDCP field descriptions
delayDSetofLenghtY Configures a set of Y delay values for TDCP reporting, see reference XXX. The symb4 denotes 4 symbols, the slot1 denotes 1 slot, the slot2 denotes 2 slots and so on. The value slot 10 is applicable only to SCS >=30kHz. The parameter Y, see reference XXX, is given by the length of the set of D values.
phaseReporting Configures the UE for phase reporting for TDCP reporting see reference XXX.

Seems that the value of Y can be deferred from the list length of delayDSetofLenghtY-r18.

Question 5 Please state if you agree to jointly encode parameters Y and D?

Company	Yes/no	Comments
Ericsson	yes
Docomo	Yes
Samsung	Yes
CATT	Yes
ZTE	Yes

Conlcusion

The value of Y can be deferred from the list length of delayDSetofLenghtY-r18

CSI-Doppler

In R2-2307696 Samsung, it is suggested to encode parameters d and m together:

For high/medium speed UE, UE-side CSI prediction and reporting of time-domain channel properties is introduced as one of the CSI enhancements. The RRC parameters d and m for AP CSI-RS resource for CSI prediction are copied below followed with description in TS38.214 CR [4].

Subject to UE capability, a UE configured with a CSI-ReportConfig with the higher layer parameter N4 and reportQuantity set to 'cri-RI-PMI-CQI' is assumed to support UE-side CSI prediction. The reported PMI indicates predicted precoder matrices associated with consecutive slot intervals, each with duration of slots, where the value of is configured by N4. If the UE is configured with an aperiodic CSI-RS resource set for channel measurement, the value, in number of slots, of the time unit is configured by higher layer parameter d, where is defined in Clause 5.2.1.4.1. If the UE is configured with a periodic or semi-persistent CSI-RS resource set for channel measurement, the value of is equal to the periodicity of the CSI-RS resource. The earliest of the slot intervals starts at slot , where is the uplink slot in which the CSI is reported and the slot offset is configured by higher layer parameter delta. … A UE configured with a CSI-ReportConfig with the higher layer parameter N4 and reportQuantity set to 'cri-RI-PMI-CQI', is expected to be configured with aperiodic CSI-RS resources or with a single periodic or semi-persistent CSI-RS resource in the resource set for channel measurement. For an aperiodic CSI-RS resource set for channel measurement, the CSI-RS resources are triggered by the same triggering instance and the separation between two consecutive CSI-RS resources is slots, which is configured by higher layer parameter in the NZP-CSI-RS-ResourceSet. The UE shall assume that the antenna port with the same port index of the aperiodic CSI-RS resources is the same. If interference measurement is performed on CSI-IM, only one resource is configured in the corresponding csi-IM-ResourceSet.

Based on the description, d is the length of a slot interval, during which UE predicts CSI, and m is the separation between 2 consecutive AP CSI-RS resource, where and slots. Since d and m are coupled, one parameter can be introduced to configure values of the two, i.e., d-m with values {1-1, 1-2, 2-2}.

Proposal 6: For CSI-Doppler, one parameter d-m is used to configure values of d and m, i.e., d-m with values {1-1, 1-2, 2-2}.

The running RRC CR implements currently the parameter d as unitDurationDD-r18 in IE CodebookConfig-r18 under typeII-Doppler-r18 and parameter m as aperiodicResourceOffset-r18 in IE NZP-CSI-RS-ResourceSet.

Question 6 Please state whether to jointly configure parameters d and m and in which IE those should be placed(whether separate or jointly coded)?

Company	Yes/no	Comments
Ericsson	As in running CR	Open to change after further checking/majority view
Docomo	No	d and m are separate parameters although the value range of d is depending on value m. That dependency can be instead captured in the field description for d, e.g., if 1 is configured on m, this shall be 1.
Samsung	No strong view	Flexible to follow majority view
CATT	No strong view
ZTE	No strong view

Conclusion

Move parameter m (aperiodicResourceOffset-r18) from IE NZP-CSI-RS-ResourceSet to IE CodebookConfig-r18 under typeII-Doppler-r1 and specify relation in field description.

UL codebook

RAN2 Parent IE	Parameter name in the spec	New or existing?	Description	Value range	Comment
PUSCH-Config	ULcodebookFC-N1N2	New	Supported combination of a pair of parameters (N1, N2 Only applicable to CodebookType='Codebook1'	(4,1), (2,2)	Whether ULcodebookFC-N1N2 and CodebookType are merged or not is up to RAN2
PUSCH-Config	CodebookType	New	Codebook type Codebook1 corresponds to Ng=1 Codebook2 corresponds to Ng=2 Codebook3 corresponds to Ng=4 Codebook4 corresponds to Ng=8 Ng represents the number of antenna port-groups	{Codebook1, Codebook2, Codebook3, Codebook4}	This is an example. The details are up to RAN2 Whether ULcodebookFC-N1N2 and CodebookType are merged or not is up to RAN2

In Running RRC CR the following is implemented:

–	PUSCH-Config

The IE PUSCH-Config is used to configure the UE specific PUSCH parameters applicable to a particular BWP.

PUSCH-Config information element

-- ASN1START

-- TAG-PUSCH-CONFIG-START

PUSCH-Config ::= SEQUENCE {

****fields omitted****

]]

codebookTypeUL-r18 SetupRelease { CodebookTypeUL-r18 } OPTIONAL -- Need M

]]

}

****fields omitted****

CodebookTypeUL-r18 ::= CHOICE {

codebook1-r18 ENUMERATED {ng1n4n1, ng1n2n2}

codebook1-r18 ENUMERATED {ng2}

codebook2-r18 ENUMERATED {ng4}

codebook3-r18 ENUMERATED {ng8}

}

Question 7 Please state whether you agree with the current implementation of UL codebook?

Company	Yes/no	Comments
Ericsson	Yes
Docomo	Yes
Samsung	See comment	For codebook1-r18, RAN1 parameters are (Ng,N1,N2). We suggest to align/reflect parameter name N1,N2 which is missing in the current version. For instance, we can follow the Rel.15 description for typeI-MultiPanel in IE CodebookConfig, copied below, where parameter name is indicated by ng-n1-n2. typeI-MultiPanel SEQUENCE { ng-n1-n2 CHOICE { two-two-one-TypeI-MultiPanel-Restriction BIT STRING (SIZE (8)), two-four-one-TypeI-MultiPanel-Restriction BIT STRING (SIZE (16)), …. } One option with typo fixed: CodebookTypeUL-r18 ::= CHOICE { codebook1-r18 ng-n1-n2 codebook2-r18 ENUMERATED {ng2} codebook3-r18 ENUMERATED {ng4} codebook4-r18 ENUMERATED {ng8} } ng-n1-n2 ::= ENUMERATED {one-four-one, one-two-two}
CATT	Yes
Ericsson2	yes	The codebooks are given in 38.211 with the following form using those exact value names of CB1: Table 6.3.1.5-9: Precoding matrix W for codebook1=ng1n4n1 and single-layer transmission using eight antenna ports. Table 6.3.1.5-17: Precoding matrix W for codebook1=ng1n2n2 and single-layer transmission using eight antenna ports. Table 6.3.1.5-29: Intermediate precoding matrix W' for codebook2 and single-layer transmission using eight antenna ports. Table 6.3.1.5-39: Intermediate precoding matrix W’ for codebook3 and single-layer transmission using eight antenna ports. Table 6.3.1.5-47: Precoding matrix W’ for codebook4 and transmission using eight antenna ports. From this perspective, the current form below (with typos fixed) seems OK: CodebookTypeUL-r18 ::= CHOICE { codebook1-r18 ENUMERATED {ng1n4n1, ng1n2n2} codebook2-r18 ENUMERATED {ng2} codebook3-r18 ENUMERATED {ng4} codebook4-r18 ENUMERATED {ng8} } However, we anticipate further discussion of antenna port groups and if/how they are explicitly captured in the RAN1 specs during the next RAN1 meeting. This may affect whether the port groups ng1/ng2/ng4/ng8 are referenced in CodebookTypeUL. So our suggestion would be to fix the typos and further discuss whether changes are needed to this field. Also another aspect which speaks against of aligning DL and UL, is taht in DL there is no panels and in UL there is no large antenna arrays hence the N1 N2 of DL antenna codebooks that refer to the array is not as such applicable in UL.
ZTE	Yes with samsung’s comments

Conclusion

Correct typos and update if further RAN1 input.

CodebookConfig-r18

In Running RRC CR the following is implemented:

–	CodebookConfig

The IE CodebookConfig is used to configure codebooks of Type-I and Type-II (see TS 38.214 [19], clause 5.2.2.2)

CodebookConfig information element

-- ASN1START

-- TAG-CODEBOOKCONFIG-START

CodebookConfig ::= SEQUENCE {

codebookType CHOICE {

type1 SEQUENCE {

subType CHOICE {

typeI-SinglePanel SEQUENCE {

nrOfAntennaPorts CHOICE {

two SEQUENCE {

twoTX-CodebookSubsetRestriction BIT STRING (SIZE (6))

},

moreThanTwo SEQUENCE {

n1-n2 CHOICE {

two-one-TypeI-SinglePanel-Restriction BIT STRING (SIZE (8)),

two-two-TypeI-SinglePanel-Restriction BIT STRING (SIZE (64)),

four-one-TypeI-SinglePanel-Restriction BIT STRING (SIZE (16)),

three-two-TypeI-SinglePanel-Restriction BIT STRING (SIZE (96)),

six-one-TypeI-SinglePanel-Restriction BIT STRING (SIZE (24)),

four-two-TypeI-SinglePanel-Restriction BIT STRING (SIZE (128)),

eight-one-TypeI-SinglePanel-Restriction BIT STRING (SIZE (32)),

four-three-TypeI-SinglePanel-Restriction BIT STRING (SIZE (192)),

six-two-TypeI-SinglePanel-Restriction BIT STRING (SIZE (192)),

twelve-one-TypeI-SinglePanel-Restriction BIT STRING (SIZE (48)),

four-four-TypeI-SinglePanel-Restriction BIT STRING (SIZE (256)),

eight-two-TypeI-SinglePanel-Restriction BIT STRING (SIZE (256)),

sixteen-one-TypeI-SinglePanel-Restriction BIT STRING (SIZE (64))

},

typeI-SinglePanel-codebookSubsetRestriction-i2 BIT STRING (SIZE (16)) OPTIONAL -- Need R

}

},

typeI-SinglePanel-ri-Restriction BIT STRING (SIZE (8))

},

typeI-MultiPanel SEQUENCE {

ng-n1-n2 CHOICE {

two-two-one-TypeI-MultiPanel-Restriction BIT STRING (SIZE (8)),

two-four-one-TypeI-MultiPanel-Restriction BIT STRING (SIZE (16)),

four-two-one-TypeI-MultiPanel-Restriction BIT STRING (SIZE (8)),

two-two-two-TypeI-MultiPanel-Restriction BIT STRING (SIZE (64)),

two-eight-one-TypeI-MultiPanel-Restriction BIT STRING (SIZE (32)),

four-four-one-TypeI-MultiPanel-Restriction BIT STRING (SIZE (16)),

two-four-two-TypeI-MultiPanel-Restriction BIT STRING (SIZE (128)),

four-two-two-TypeI-MultiPanel-Restriction BIT STRING (SIZE (64))

},

ri-Restriction BIT STRING (SIZE (4))

}

},

codebookMode INTEGER (1..2)

},

type2 SEQUENCE {

subType CHOICE {

typeII SEQUENCE {

n1-n2-codebookSubsetRestriction CHOICE {

two-one BIT STRING (SIZE (16)),

two-two BIT STRING (SIZE (43)),

four-one BIT STRING (SIZE (32)),

three-two BIT STRING (SIZE (59)),

six-one BIT STRING (SIZE (48)),

four-two BIT STRING (SIZE (75)),

eight-one BIT STRING (SIZE (64)),

four-three BIT STRING (SIZE (107)),

six-two BIT STRING (SIZE (107)),

twelve-one BIT STRING (SIZE (96)),

four-four BIT STRING (SIZE (139)),

eight-two BIT STRING (SIZE (139)),

sixteen-one BIT STRING (SIZE (128))

},

typeII-RI-Restriction BIT STRING (SIZE (2))

},

typeII-PortSelection SEQUENCE {

portSelectionSamplingSize ENUMERATED {n1, n2, n3, n4} OPTIONAL, -- Need R

typeII-PortSelectionRI-Restriction BIT STRING (SIZE (2))

}

},

phaseAlphabetSize ENUMERATED {n4, n8},

subbandAmplitude BOOLEAN,

numberOfBeams ENUMERATED {two, three, four}

}

}

}

CodebookConfig-r16 ::= SEQUENCE {

codebookType CHOICE {

type2 SEQUENCE {

subType CHOICE {

typeII-r16 SEQUENCE {

n1-n2-codebookSubsetRestriction-r16 CHOICE {

two-one BIT STRING (SIZE (16)),

two-two BIT STRING (SIZE (43)),

four-one BIT STRING (SIZE (32)),

three-two BIT STRING (SIZE (59)),

six-one BIT STRING (SIZE (48)),

four-two BIT STRING (SIZE (75)),

eight-one BIT STRING (SIZE (64)),

four-three BIT STRING (SIZE (107)),

six-two BIT STRING (SIZE (107)),

twelve-one BIT STRING (SIZE (96)),

four-four BIT STRING (SIZE (139)),

eight-two BIT STRING (SIZE (139)),

sixteen-one BIT STRING (SIZE (128))

},

typeII-RI-Restriction-r16 BIT STRING (SIZE(4))

},

typeII-PortSelection-r16 SEQUENCE {

portSelectionSamplingSize-r16 ENUMERATED {n1, n2, n3, n4},

typeII-PortSelectionRI-Restriction-r16 BIT STRING (SIZE (4))

}

},

numberOfPMI-SubbandsPerCQI-Subband-r16 INTEGER (1..2),

paramCombination-r16 INTEGER (1..8)

}

}

}

CodebookConfig-r17 ::= SEQUENCE {

codebookType CHOICE {

type1 SEQUENCE {

typeI-SinglePanel-Group1-r17 SEQUENCE {

nrOfAntennaPorts CHOICE {

two SEQUENCE {

twoTX-CodebookSubsetRestriction1-r17 BIT STRING (SIZE (6))

},

moreThanTwo SEQUENCE {

n1-n2 CHOICE {

two-one-TypeI-SinglePanel-Restriction1-r17 BIT STRING (SIZE (8)),

two-two-TypeI-SinglePanel-Restriction1-r17 BIT STRING (SIZE (64)),

four-one-TypeI-SinglePanel-Restriction1-r17 BIT STRING (SIZE (16)),

three-two-TypeI-SinglePanel-Restriction1-r17 BIT STRING (SIZE (96)),

six-one-TypeI-SinglePanel-Restriction1-r17 BIT STRING (SIZE (24)),

four-two-TypeI-SinglePanel-Restriction1-r17 BIT STRING (SIZE (128)),

eight-one-TypeI-SinglePanel-Restriction1-r17 BIT STRING (SIZE (32)),

four-three-TypeI-SinglePanel-Restriction1-r17 BIT STRING (SIZE (192)),

six-two-TypeI-SinglePanel-Restriction1-r17 BIT STRING (SIZE (192)),

twelve-one-TypeI-SinglePanel-Restriction1-r17 BIT STRING (SIZE (48)),

four-four-TypeI-SinglePanel-Restriction1-r17 BIT STRING (SIZE (256)),

eight-two-TypeI-SinglePanel-Restriction1-r17 BIT STRING (SIZE (256)),

sixteen-one-TypeI-SinglePanel-Restriction1-r17 BIT STRING (SIZE (64))

}

}

}

} OPTIONAL, -- Need R

typeI-SinglePanel-Group2-r17 SEQUENCE {

nrOfAntennaPorts CHOICE {

two SEQUENCE {

twoTX-CodebookSubsetRestriction2-r17 BIT STRING (SIZE (6))

},

moreThanTwo SEQUENCE {

n1-n2 CHOICE {

two-one-TypeI-SinglePanel-Restriction2-r17 BIT STRING (SIZE (8)),

two-two-TypeI-SinglePanel-Restriction2-r17 BIT STRING (SIZE (64)),

four-one-TypeI-SinglePanel-Restriction2-r17 BIT STRING (SIZE (16)),

three-two-TypeI-SinglePanel-Restriction2-r17 BIT STRING (SIZE (96)),

six-one-TypeI-SinglePanel-Restriction2-r17 BIT STRING (SIZE (24)),

four-two-TypeI-SinglePanel-Restriction2-r17 BIT STRING (SIZE (128)),

eight-one-TypeI-SinglePanel-Restriction2-r17 BIT STRING (SIZE (32)),

four-three-TypeI-SinglePanel-Restriction2-r17 BIT STRING (SIZE (192)),

six-two-TypeI-SinglePanel-Restriction2-r17 BIT STRING (SIZE (192)),

twelve-one-TypeI-SinglePanel-Restriction2-r17 BIT STRING (SIZE (48)),

four-four-TypeI-SinglePanel-Restriction2-r17 BIT STRING (SIZE (256)),

eight-two-TypeI-SinglePanel-Restriction2-r17 BIT STRING (SIZE (256)),

sixteen-one-TypeI-SinglePanel-Restriction2-r17 BIT STRING (SIZE (64))

}

}

}

} OPTIONAL, -- Need R

typeI-SinglePanel-ri-RestrictionSTRP-r17 BIT STRING (SIZE (8)) OPTIONAL, -- Need R

typeI-SinglePanel-ri-RestrictionSDM-r17 BIT STRING (SIZE (4)) OPTIONAL -- Need R

},

type2 SEQUENCE {

typeII-PortSelection-r17 SEQUENCE {

paramCombination-r17 INTEGER (1..8),

valueOfN-r17 ENUMERATED {n2, n4} OPTIONAL, -- Need R

numberOfPMI-SubbandsPerCQI-Subband-r17 INTEGER(1..2) OPTIONAL, -- Need R

typeII-PortSelectionRI-Restriction-r17 BIT STRING (SIZE (4))

}

}

}

}

CodebookConfig-v1730 ::= SEQUENCE {

codebookType CHOICE {

type1 SEQUENCE {

codebookMode INTEGER (1..2) OPTIONAL -- Need R

}

}

}

CodebookConfig-r18 ::= SEQUENCE {

codebookType CHOICE {

type2 SEQUENCE {

typeII-CJT-r18 SEQUENCE { numberOfCMR-r18 INTEGER (1..4),

n1-n2-codebookSubsetRestrictionList-r18 SEQUENCE (SIZE (1..4)) OF CBSR-r18 OPTIONAL, -- Need R

paramCombination-CJT-r18 INTEGER (1..7),

paramCombination-CJT-L-r18 SEQUENCE (SIZE (1..4)) OF INTEGER (1-16) OPTIONAL, -- Need R

restrictedCMR-Selection-r18 ENUMERATED {enable} OPTIONAL, -- Need R

valueOfO3-r18 ENUMERATED {n1, n4} OPTIONAL, -- Need R

numberOfPMI-SubbandsPerCQI-Subband-r18 INTEGER(1..2) OPTIONAL, -- Need R

typeII-RI-Restriction-r18 BIT STRING (SIZE (4))

}

typeII-CJT-PortSelection-r18 SEQUENCE {

paramCombination-CJT-PS-r18 INTEGER (1..5),

paramCombination-CJT-PS-alpha-r18 SEQUENCE (SIZE (1..4)) OF INTEGER (1-20) OPTIONAL, -- Need R

valueOfO3-r18 ENUMERATED {n1, n4} OPTIONAL, -- Need R

valueOfN-CJT-r18 ENUMERATED {n2, n4} OPTIONAL, -- Need R

numberOfPMI-SubbandsPerCQI-Subband-r18 INTEGER(1..2) OPTIONAL, -- Need R

typeII-PortSelectionRI-Restriction-r18 BIT STRING (SIZE (4))

}

typeII-Doppler-r18 SEQUENCE {

n1-n2-codebookSubsetRestriction-r18 CBSR-r18,

paramCombination-Doppler-r18 INTEGER (1..9),

td-dd-config-r18 TD-DD-Config-r18 OPTIONAL, -- Need R

numberOfPMI-SubbandsPerCQI-Subband-r18 INTEGER(1..2) OPTIONAL, -- Need R

predictionDelay-r18 ENUMERATED {m0,n0,n1,n2 } OPTIONAL, -- Need R

typeII-RI-Restriction-r18 BIT STRING (SIZE (4))

}

typeII-DopplerPortSelection-r18 SEQUENCE {

paramCombinationDoppler-PS-r18 INTEGER (1..8),

valueOfN-Doppler-r18 ENUMERATED {n2, n4} OPTIONAL, -- Need R

numberOfPMI-SubbandsPerCQI-Subband-r18 INTEGER(1..2) OPTIONAL, -- Need R

predictionDelay-r18 ENUMERATED {m0,n0,n1,n2 } OPTIONAL, -- Need R

typeII-PortSelectionRI-Restriction-r18 BIT STRING (SIZE (4))

}

}

}

codebookMode-r18 INTEGER (1..2) OPTIONAL -- Need R

}

CBSR-r18 ::= CHOICE {

two-one BIT STRING (SIZE (16)),

two-two BIT STRING (SIZE (43)),

four-one BIT STRING (SIZE (32)),

three-two BIT STRING (SIZE (59)),

six-one BIT STRING (SIZE (48)),

four-two BIT STRING (SIZE (75)),

eight-one BIT STRING (SIZE (64)),

four-three BIT STRING (SIZE (107)),

six-two BIT STRING (SIZE (107)),

twelve-one BIT STRING (SIZE (96)),

four-four BIT STRING (SIZE (139)),

eight-two BIT STRING (SIZE (139)),

sixteen-one BIT STRING (SIZE (128))

}

TD-DD-Config-r18 ::= SEQUENCE {

vectorLengthDD-r18 ENUMERATED {n1,n2,n4,n8 }

unitDurationDD-r18 ENUMERATED {n1,nm} OPTIONAL, -- Need R

tdCQI-r18 ENUMERATED {n11,n12,n2 } OPTIONAL -- Need R

}

-- TAG-CODEBOOKCONFIG-STOP

-- ASN1STOP

Question 8 Please indicate whether you agree that CodebookConfig is critically extended? If not, please give alternative ASN1 code. (also if you have other ASN1 alternative suggestions for this part, you may give it here)

Company	Yes/no	ASN1 alternative
Ericsson	yes
Samsung	see comment	1. For CJT n1-n2-CBSR, wonder if RAN1 comments need to be captured or not “n1-n2 can be separated out from n1-n2-CBSR-CJT-r18, since n1-n2 is common for all CSI-RS resources.” network configures up to numberOfCMR elements in n1-n2-codebookSubsetRestrictionList-r18 with same n1-n2 “One of the NTRP configured CSI-RS resources must be configured with CBSR, while the remaining (NTRP –1) configured CSI-RS resources can be optionally (upto gNB) configured with CBSR.” n1-n2-codebookSubsetRestrictionList-r18 always include at least one element. 2. Some parameters are defined as mandatory, while some parameters are optional. Based on RAN1 RRC list, it is hard to tell which one is mandatory or optional for each code-book type. 3. See more bubble comments in draft CR [Rapp] For point 3, most comments were addressed while others may need further discussion.
CATT	Agree to use the critical extension

Conclusion

As baseline assumption CodebookConfig is critically extended.

Field description for n1-n2-codebookSubsetRestrictionList includes configuration restriction for same n1-n2 for each element.

Optionality of n1-n2-codebookSubsetRestrictionList is removed to ensure at least one element is included.

Optionality and field description need further review and it can be considered to send LS from next meeting for RAN1 to review the optionality of the parameters, FFS other things.

Other

Question 9 Please indicate any other comments for running CR review?

Company	Topic/parameter	Comments
CATT	Unified TCI extension	Even not indicated in the RRC parameter list, we think similar indication like applyIndicatedTCIState should be added within the PDCCH-ConfigCommon to indicate whether/which TCI state to be applied for corset 0, based on the following RAN1 agreements. Agreement On unified TCI framework extension for S-DCI based MTRP: If a CORESET other than a CORESET with index 0 is associated only with USS sets and/or Type3-PDCCH CSS sets, the CORESET is configured by RRC to apply the first one, the second one, or both of the indicated joint/DL TCI states to PDCCH reception on the CORESET If a CORESET other than a CORESET with index 0 is associated at least with CSS sets other than Type3-PDCCH CSS sets, the CORESET is configured by RRC to apply the first one, the second one, both, or none of the indicated joint/DL TCI states to PDCCH reception on the CORESET For a CORESET with index 0: If the CORESET is associated with SS#0 for Type 0/0A/2 CSS sets, the CORESET is configured by RRC to apply the first one, the second one, or none of the indicated joint/DL TCI state to PDCCH reception on the CORESET Otherwise, the CORESET is configured by RRC to apply the first one, the second one, both, or none of the indicated joint/DL TCI states to PDCCH reception on the CORESET Note: RAN1 already agrees to use RRC configuration to inform that the UE shall apply the first one, the second one, both, or none of the indicated joint/DL TCI states to a CORESET in S-DCI based MTRP. Note: There is no consensus in RAN1 on whether to reuse the Rel-17 RRC parameter followUnifiedTCIstate as a part of above RRC configuration, and whether to reuse followUnifiedTCIstate is up to RAN2 design