3GPP TSG RAN2 Meeging #131	R2-250xxxx

Bangalore, India, 25th – 29nd Aug , 2025

Agenda item:	8.1.3

Title:	Summary Report of [Post130][602][Maint] Spatial Relation Info list extension (ZTE)

Source:	ZTE Corporation

Document for:	Discussion and Decision

Introduction

This summary report is for the following post meeting email discussion:

Companies providing input to this email discussion are requested to leave contact information below.

Company	Name	Email Address
MediaTek	Pasi Laitinen (For phase 2: Mutai Lin)	pasi.laitinen@mediatek.com (For phase 2: morton.lin@mediatek.com)
ZTE	Fei Dong	Dong.fei@zte.com.cn
Nokia	Andrew Lappalainen	andrew.lappalainen@nokia.com
CATT	Da Wang	wangda@catt.cn
Ericsson	Håkan Palm	hakan.l.palm@ericsson.com
Huawei	David Lecompte	david.lecompte@huawei.com

Discussion

BackGround

In the current TS 38.331-gj0, the rel-16 PUCCH spatial relation info list has been extended on the top of rel-15 PUCCH spatial relation info list which is shown as below:

–	PUCCH-Config

The IE PUCCH-Config is used to configure UE specific PUCCH parameters (per BWP).

PUCCH-Config information element

-- ASN1START

-- TAG-PUCCH-CONFIG-START

PUCCH-Config ::= SEQUENCE {

resourceSetToAddModList SEQUENCE (SIZE (1..maxNrofPUCCH-ResourceSets)) OF PUCCH-ResourceSet OPTIONAL, -- Need N

resourceSetToReleaseList SEQUENCE (SIZE (1..maxNrofPUCCH-ResourceSets)) OF PUCCH-ResourceSetId OPTIONAL, -- Need N

resourceToAddModList SEQUENCE (SIZE (1..maxNrofPUCCH-Resources)) OF PUCCH-Resource OPTIONAL, -- Need N

resourceToReleaseList SEQUENCE (SIZE (1..maxNrofPUCCH-Resources)) OF PUCCH-ResourceId OPTIONAL, -- Need N

format1 SetupRelease { PUCCH-FormatConfig } OPTIONAL, -- Need M

format2 SetupRelease { PUCCH-FormatConfig } OPTIONAL, -- Need M

format3 SetupRelease { PUCCH-FormatConfig } OPTIONAL, -- Need M

format4 SetupRelease { PUCCH-FormatConfig } OPTIONAL, -- Need M

schedulingRequestResourceToAddModList SEQUENCE (SIZE (1..maxNrofSR-Resources)) OF SchedulingRequestResourceConfig

OPTIONAL, -- Need N

schedulingRequestResourceToReleaseList SEQUENCE (SIZE (1..maxNrofSR-Resources)) OF SchedulingRequestResourceId

OPTIONAL, -- Need N

multi-CSI-PUCCH-ResourceList SEQUENCE (SIZE (1..2)) OF PUCCH-ResourceId OPTIONAL, -- Need M

dl-DataToUL-ACK SEQUENCE (SIZE (1..8)) OF INTEGER (0..15) OPTIONAL, -- Need M

spatialRelationInfoToAddModList SEQUENCE (SIZE (1..maxNrofSpatialRelationInfos)) OF PUCCH-SpatialRelationInfo

OPTIONAL, -- Need N

spatialRelationInfoToReleaseList SEQUENCE (SIZE (1..maxNrofSpatialRelationInfos)) OF PUCCH-SpatialRelationInfoId

OPTIONAL, -- Need N

/OMIT FOR SHORT/

spatialRelationInfoToAddModListSizeExt-v1610 SEQUENCE (SIZE (1..maxNrofSpatialRelationInfosDiff-r16)) OF PUCCH-SpatialRelationInfo

OPTIONAL, -- Need N

spatialRelationInfoToReleaseListSizeExt-v1610 SEQUENCE (SIZE (1..maxNrofSpatialRelationInfosDiff-r16)) OF PUCCH-SpatialRelationInfoId

OPTIONAL, -- Need N

spatialRelationInfoToAddModListExt-v1610 SEQUENCE (SIZE (1..maxNrofSpatialRelationInfos-r16)) OF PUCCH-SpatialRelationInfoExt-r16

OPTIONAL, -- Need N

spatialRelationInfoToReleaseListExt-v1610 SEQUENCE (SIZE (1..maxNrofSpatialRelationInfos-r16)) OF

PUCCH-SpatialRelationInfoId-r16 OPTIONAL, -- Need N

/OMIT FOR SHORT/

...

PUCCH-SpatialRelationInfo information element

-- ASN1START

-- TAG-PUCCH-SPATIALRELATIONINFO-START

PUCCH-SpatialRelationInfo ::= SEQUENCE {

pucch-SpatialRelationInfoId PUCCH-SpatialRelationInfoId,

servingCellId ServCellIndex OPTIONAL, -- Need S

referenceSignal CHOICE {

ssb-Index SSB-Index,

csi-RS-Index NZP-CSI-RS-ResourceId,

srs PUCCH-SRS

},

pucch-PathlossReferenceRS-Id PUCCH-PathlossReferenceRS-Id,

p0-PUCCH-Id P0-PUCCH-Id,

closedLoopIndex ENUMERATED { i0, i1 }

}

PUCCH-SpatialRelationInfoExt-r16 ::= SEQUENCE {

pucch-SpatialRelationInfoId-v1610 PUCCH-SpatialRelationInfoId-v1610 OPTIONAL, -- Need S

pucch-PathlossReferenceRS-Id-v1610 PUCCH-PathlossReferenceRS-Id-v1610 OPTIONAL, --Need R

...

}

PUCCH-SRS ::= SEQUENCE {

resource SRS-ResourceId,

uplinkBWP BWP-Id

}

-- TAG-PUCCH-SPATIALRELATIONINFO-STOP

-- ASN1STOP

According to above structure in the ASN.1, the spatialRelationInfoToAddModListSizeExt-v1610 is configured to extend the original list size (i.e. spatialRelationInfoToAddModList), and the spatialRelationInfoToAddModListListExt-v1610 is to extend the configuration of each entry in both original list and the size extension list.

In the field description of above three ToAddModList, there are two sentences to describe the relationship among those AddModList：

spatialRelationInfoToAddModList, spatialRelationInfoToAddModListSizeExt , spatialRelationInfoToAddModListExt

Configuration of the spatial relation between a reference RS and PUCCH. Reference RS can be SSB/CSI-RS/SRS. If the list has more than one element, MAC-CE selects a single element (see TS 38.321 [3], clause 5.18.8 and TS 38.213 [13], clause 9.2.2). The UE shall consider entries in spatialRelationInfoToAddModList and in spatialRelationInfoToAddModListSizeExt as a single list, i.e. an entry created using spatialRelationInfoToAddModList can be modified using spatialRelationInfoToAddModListSizeExt (or deleted using spatialRelationInfoToReleaseListSizeExt) and vice-versa. If the network includes spatialRelationInfoToAddModListExt, it includes the same number of entries, and listed in the same order, as in the concatenation of spatialRelationInfoToAddModList and of spatialRelationInfoToAddModListSizeExt.

The colored sentences make some confusion on alignment between UE and NW vendor among different companies, that is, how to understand the ‘single list’ and the ‘concatenation’ list, so as to some extension.

For aligning the understandings between UE vendor and NW vendor, rapporteur suggests to the confirm below aspects:

1: single list and concatenation list

2: Adding

3: Modifying

4: Releasing

Single list and Concatenation list

In the field description, there are two terms to describe the relationship between original list and size extension list, one is single list, and the other one is the concatenation list, and such vague description cause a lot of trouble for companies to understand how to incorporate them into operations.

*******************************************************************************************************************************

spatialRelationInfoToAddModList, spatialRelationInfoToAddModListSizeExt , spatialRelationInfoToAddModListExt

Configuration of the spatial relation between a reference RS and PUCCH. Reference RS can be SSB/CSI-RS/SRS. If the list has more than one element, MAC-CE selects a single element (see TS 38.321 [3], clause 5.18.8 and TS 38.213 [13], clause 9.2.2). The UE shall consider entries in spatialRelationInfoToAddModList and in spatialRelationInfoToAddModListSizeExt as a single list, i.e. an entry created using spatialRelationInfoToAddModList can be modified using spatialRelationInfoToAddModListSizeExt (or deleted using spatialRelationInfoToReleaseListSizeExt) and vice-versa. If the network includes spatialRelationInfoToAddModListExt, it includes the same number of entries, and listed in the same order, as in the concatenation of spatialRelationInfoToAddModList and of spatialRelationInfoToAddModListSizeExt.

*******************************************************************************************************************************

Rapporteur realizes that the key point of causing such vagueness is about the true intention of the sentence concerning the term of ‘concatenation list’, it may have two interpretations on the intention:

Interpretation 1:If the network includes spatialRelationInfoToAddModListExt in RRCReconfiguration message, it includes the same number of entries, and listed in the same order, as in the concatenation of spatialRelationInfoToAddModList and of spatialRelationInfoToAddModListSizeExt by considering the entries those are newly configured and already maintained at UE side.

Interpretation 2: If the network includes spatialRelationInfoToAddModListExt in a RRCReconfiguration message, it shall include the same number of entries, and listed in the same order, as in the concatenation of spatialRelationInfoToAddModList and of spatialRelationInfoToAddModListSizeExt in the same message.

How NW to configure or reconfigure those three lists for pucch-SpatialRelationInfo is subject to how we interpret this sentence.

In the first interpretation, the spatialRelationInfoToAddModListExt is allowed to be contained in RRCReconfiguration message solely (e.g. without other two list present). This interpretation requires UE and NW maintain a strictly aligned concatenation of spatialRelationInfoToAddModList and of spatialRelationInfoToAddModListSizeExt, that is , to align the entry order and entry number of the concatenation list maintained at UE side and NW side respectively. In this sense, the delta configuration in a flexible way shall be avoided as much as possible since the UE side and NW side need to maintain an aligned concatenation list all the time.

In the second interpretation, for each instance of (re)configuration for spatialRelationInfoToAddModListExt, the original list and/or size extension list shall be present as well. Specifically, if both the original list and size extension list are present , then they shall be concatenated for one-to-one mapping to the entries of spatialRelationInfoToAddModListExt. In this interpretation, it restricts the NW to mandatory provide spatialRelationInfoToAddModList and/or spatialRelationInfoToAddModListSizeExt in the same message if the spatialRelationInfoToAddModListExt is present in a RRC reconfiguration message.

Q1-1: For understanding about the description of concatenation list, which interpretation is correct? (Interpretation 1 or Interpretation 2)

Company	Interpretation 1/Interpretation 2/Others	If answer is others, please explain why
MediaTek	Interpretation 2	The spatialRelationInfoToAddModListExt does not provide full content for a PUCCH spatial relation info element. It provides only element ID and RS-Id. For this reason, this list cannot be used without spatialRelationInfoToAddModList/spatialRelationInfoToAddModListSizeExt for element configuration. It could be used for element reconfiguration (of RS-Id only), but that is not the intention.
ZTE	Interpretation 2	NW have no idea how UE maintains the already configured PUCCH-spatialRelationInfo and, if any, the corresponding PUCCH-SpatialRelationInfoExt, what NW can guarantee to always provide the spatialRelationInfoToAddModListExt together with spatialRelationInfoToAddModList/spatialRelationInfoToAddModListSizeExt in one message, to make everything clear for both sides.
Nokia	Interpretation 2	Same understanding as MediaTek.
CATT	Interpretation 2	Same understanding as others.
Ericsson	Interpretation 2	Same understanding as others.
Qualcomm	Interpretation 2
Huawei	Interpretation 2	The so-called interpretation 1 is clearly contradicting with the text.

Compare between two interpretations, the first interpretation is a general understanding by all means, and the second interpretation is to make a restriction to NW behavior on the reconfiguration/configuration of spatialRelationInfoToAddModListExt. So in rapporteur understanding, if the interpretation 2 is the correct understanding, then we may need a clarification in the current spec.

Q1-2: If the answer of Q1-1 is interpretation 2, Whether the clarification in the specification is needed?

Company	Yes/No	Comments
MediaTek	No	There is no need for clarification, as it should be clear already due to the reason we explained in Q1-1. But, if majority wants a clarification, we could add something like following to make interpretation 2 more clearly visible in the spec: " If the network includes spatialRelationInfoToAddModListExt, it includes the same number of entries, and listed in the same order, as in the concatenation of included spatialRelationInfoToAddModList and of included spatialRelationInfoToAddModListSizeExt."
ZTE	Yes	It is good to have the explicit clarification in the specification for avoiding some improper configuration method caused by the interpretation 1: For example, currently, UE have been solely configured by NW with spatialRelationInfoToAddModList with full number of entries, and hence, in this case, only 8 pucch-SpatialRelationInfo are maintained by UE, If NW would like to configure one more pucch-SpatialRelationInfo, according to the interpretation 1, NW need to configure UE in the following way: Sending RRCReconfiguration containing spatialRelationInfoToAddModListSizeExt with one entry, alone with the spatialRealtionInfoToAddmodListExt which is containing 9 entries, the first 8 entries is empty, and the 9th entry contains the pucch-SpatialRelationInfoId-v1610 =9. Such configuration method may cause the confusing in the UE, so it is better to clarify in the specification for avoiding the misinterpretation.
Nokia	No	We think the understanding is already clear (but we are OK to have some minor clarification if it is preferred by most companies).
CATT	No	We also think current spec is already clear.
Ericsson	No	We also think current spec is already clear.
Qualcomm	No
Huawei	No	The specification is already clear. If there would be any doubt, that doubt would apply in many other places, while no one ever raised such a problem before.

All companies have reached the consensus, the interpretation 2 is correct, and there is no need to have modification on the current specification. In this sense, rapporteur thinks we can follow the majorities, the clarification can be captured in the chair notes. No more clarification shall be captures in the specification.

Proposal 1 (easy agreement): It is clarified in the chair notes that “If the network includes spatialRelationInfoToAddModListExt in a RRCReconfiguration message, it shall include the same number of entries, and listed in the same order, as in the concatenation of included spatialRelationInfoToAddModList and included spatialRelationInfoToAddModListSizeExt in the same message”

To Add

In this subclause, it is suggested companies to think about how to add the new entry of the spatial relation info into the list in some special scenario.

According to online discussion, the following scenario causes the different understandings from companies :

Scenario: the maximum number of PUCCH-spatialRelationInfo entries have been created using the original list (i.e. spatialRelationInfoToAddModList)

spatialRelationInfoToAddModList SEQUENCE (SIZE (1..maxNrofSpatialRelationInfos)) OF PUCCH-SpatialRelationInfo

Under this scenario, some companies think this list cannot be used for creating more elements as the maximum number of entries for this list have been reached while some other companies think this list can still be used for creating more entries. In the latter case, this list would be used together with spatialRelationInfoToAddModListExt as only spatialRelationInfoToAddModListExt can provide ID values larger than maxNrofSpatialRelationInfos for the newly added entries.

Rapporteur understands it may depend on how UE vendor to implement original list and size extension list, for instance: check the maximum number of each list separately, or just check the sum of the maximum number of original list and the maximum number of size extension list.

Q2: For adding new entries into PUCCH spatial relation info list, whether the spatialRelationInfoToAddModList can be used to add more entries if there are 8 entries have already been created by it?

Company	Yes/No	Comments
MediaTek	Yes	It can be used, but it seems the original intention is to use spatialRelationInfoToAddModListSizeExt (together with spatialRelationInfoToAddModListExt) in such scenario. After all, "size extension" refers here to "configuring more than 8 elements".
ZTE	No	It cannot be used, as explained by MTK, the original intention is to use spatialRelationInfoToAddModListSizeExt, if configuring the entries over the maximum value is allowed, which may result in the confusing about the meaning of ‘maxNrofSpatialRelationInfo’ in spatialRelationInfoToAddModList SEQUENCE (SIZE (1..maxNrofSpatialRelationInfos)) OF PUCCH-SpatialRelationInfo
Nokia	No	In a scenario where more than 8 PUCCH spatial relation entries are configured, then all three of spatialRelationInfoToAddModList, spatialRelationInfoToAddModListSizeExt, and spatialRelationInfoToAddModListExt should be configured. (This is also evident by the field description for pucch-SpatialRelationInfoId within PUCCH-SpatialRelationInfo since pucch-SpatialRelationInfoId is restricted to [1..8] while pucch-SpatialRelationInfoId-v1610 is restricted to [9..64].) PUCCH-SpatialRelationInfo field descriptions pucch-SpatialRelationInfoId When pucch-SpatialRelationInfoId-v1610 is configured, the UE shall ignore pucch-SpatialRelationInfoId (without suffix). If pucch-SpatialRelationInfoId-v1610 is absent, the UE shall use the pucch-SpatialRelationInfoId (without suffix).
CATT	Yes	For the scenario, mentioned by Nokia, if to add more than 8 PUCCH spatial relation entries, then all three lists should be configured. But if to add less than 8 PUCCH spatial relation entries, we think the spatialRelationInfoToAddModList can be used together with spatialRelationInfoToAddModListExt. The ID in spatialRelationInfoToAddModListExt can refer to the actual ID of adding entries.
Ericsson	Yes	Agree, with MTK and CATT.
Qualcomm	No	Similar view weith Nokia.
Samsung	No	Agree with CATT. But, the answer should be ”NO” because the question is whether legacy spatialRelationInfoToAddModList (probably only) is used to configure more than 8 PUCCH spatial relation entries.
Huawei	Yes	MTK's comment looks not correct. The first sentence of CATT comment does not say whether it is "using a single RRC message" or "in total in the UE configuration possibly using more than one RRC message". If it is "using a single RRC message", we agree. If it is "in total in the UE configuration possibly using more than one RRC messag", we do not agree. According to the field description: - an entry created with the ToAddModList can be modified with the ToAddModListSizeExt, and vice-versa, so the UE does not remember whether an entry was created using ToAddModList or ToAddModListSizeExt. - when ToAddModListSizeExt is present, each of its entry corresponds to one entry of either ToAddModList or ToAddModListSizeExt, the one which is in the same position in the concatenation of ToAddModList and ToAddModListSizeExt (i.e., what is in the message, what is in the UE storage does not matter for this correspondance) - there is no such restriction as expressed, and there is no UE procedure that does not work in this case.

According to the above discussion, some companies have different views on the question. it seems

1: Three companies think the original list cannot be used for this scenario as the total number of entries established by the orignal list has been reaching the maximum number..

2: Five companies think the original list (i.e. Rel-15 toAddModList) still can be used together with the listExt even though the configured number of entries have been reached the predefined maximum number(i.e.maxNrofSpatialRelationInfos), among those companies, one company points out the original intention is to use the size extension ToAddModList (i.e. Rel-16 ToAddModList)

It can be seen that there is still some misalignment between companies, and we need more discussion in RAN2#131 meeting for the clarification.In this sense, rapporteur suggest to propose the below proposal based on the majorities’ view”

Proposal 2: In the case where there are 8 entries have already been created by the patialRelationInfoToAddModList (i.e.Rel-15 ToAddModlist), it is allowed for NW to use the spatialRelationInfoToAddModList for adding more elements alone if the available Id of the added entry is no more than 8, or together with spatialRelationInfoToAddModListExt if the available Id of the added entry is greater than 8.

To Modify

In this subclause, rapporteur thinks the main misalignment is from the following description:

*******************************************************************************************************************************

The UE shall consider entries in spatialRelationInfoToAddModList and in spatialRelationInfoToAddModListSizeExt as a single list, i.e. an entry created using spatialRelationInfoToAddModList can be modified using spatialRelationInfoToAddModListSizeExt (or deleted using spatialRelationInfoToReleaseListSizeExt) and vice-versa. If the network includes spatialRelationInfoToAddModListExt , it includes the same number of entries, and listed in the same order, as in the concatenation of spatialRelationInfoToAddModList and of spatialRelationInfoToAddModListSizeExt.

*******************************************************************************************************************************

In rapporteurs’ understanding, whether such flexible delta configuration indicated by yellow highlighted wording is workable is depending on how we interpreter the green highlighted wording (i.e. the Q1).

If the interpretation 1 is the answer to Q1, then this kind of flexible behavior may cause some ambiguities, that is , which ToAddModList an entry belongs to if the entry was created by one ToAddModList but modified later by the other ToAddModList which impacts on the entry location when concatenating these two lists.

If the interpretation 2 is the answer to Q1, there is no any issue can be foreseen as NW always provide the valid Id value when performing the delta configuration and UE can identify the entry that needs to be modified according to the received Id value.

Q3: For modifying the entries those have been configured to the UE, whether it is allowed that an entry created using one ToAddModList is modified by using the other ToAddModlist?

Company	Yes/No	Comments
MediaTek	Yes	It is clearly said in the spec: "an entry created using spatialRelationInfoToAddModList can be modified using spatialRelationInfoToAddModListSizeExt".
ZTE	Yes	According to the current description, it is allowed as long as the interpretation 2 is the correct interpretation.
Nokia	Yes	Same understanding as others.
CATT	Yes	Same understanding as others.
Ericsson	Yes	Same understanding as others.
Qualcomm	Yes
Samsung	Yes
Huawei	Yes	It is totally explicit.

Proposal 3(Easy Agreement): RAN2 confirms that an entry created using spatialRelationInfoToAddModList can be modified using spatialRelationInfoToAddModListSizeExt, and vise versa. No spec change is needed.

To Release

In this subclause, rapporteur thinks the ToRelease behaviour is some kind of broken from specification perspective due to the insufficient Id value range (i.e. only from 1 to 8 for at most 64 entries) of spatialRelationInfoToReleaseList/spatialRelationInfoToReleaseListSizeExt and non-definition of PUCCH-SpatialRelationInfoId-r16 in spatialRelationInfoToReleaseListExt.

spatialRelationInfoToReleaseList SEQUENCE (SIZE (1..maxNrofSpatialRelationInfos)) OF PUCCH-SpatialRelationInfoId

OPTIONAL, -- Need N

spatialRelationInfoToReleaseListSizeExt-v1610 SEQUENCE (SIZE (1..maxNrofSpatialRelationInfosDiff-r16)) OF PUCCH-SpatialRelationInfoId

OPTIONAL, -- Need N

spatialRelationInfoToReleaseListExt-v1610 SEQUENCE (SIZE (1..maxNrofSpatialRelationInfos-r16)) OF

PUCCH-SpatialRelationInfoId-r16 OPTIONAL, -- Need N

//

PUCCH-SpatialRelationInfoId ::= INTEGER (1..maxNrofSpatialRelationInfos)

PUCCH-SpatialRelationInfoId-r16 ::= INTEGER (1..maxNrofSpatialRelationInfos-r16)

PUCCH-SpatialRelationInfoId-v1610::= INTEGER (maxNrofSpatialRelationInfos-plus-1..maxNrofSpatialRelationInfos-r16)

//

maxNrofSpatialRelationInfos INTEGER ::= 8

maxNrofSpatialRelationInfos-plus-1 INTEGER ::= 9

maxNrofSpatialRelationInfos-r16 INTEGER ::= 64

maxNrofSpatialRelationInfosDiff-r16 INTEGER ::= 56 -- Difference between maxNrofSpatialRelationInfos-r16 and maxNrofSpatialRelationInfos

Regarding the original ToReleaseList and size extension ToReleaseList , both of them just use the same PUCCH-SpatialRelationInfoId whose value range is from 1 to 8, as a result, both of them have no ability to release the entries with an Id value larger than 8, so it is not precise to have the following description since, for realizing the highlighted wording , the prerequisite condition is that those two ToReleaseLists can cover the whole Id value range:

*******************************************************************************************************************************

The UE shall consider entries in spatialRelationInfoToAddModList and in spatialRelationInfoToAddModListSizeExt as a single list, i.e. an entry created using spatialRelationInfoToAddModList can be modified using spatialRelationInfoToAddModListSizeExt (or deleted using spatialRelationInfoToReleaseListSizeExt) and vice-versa. If the network includes spatialRelationInfoToAddModListExt , it includes the same number of entries, and listed in the same order, as in the concatenation of spatialRelationInfoToAddModList and of spatialRelationInfoToAddModListSizeExt.

*******************************************************************************************************************************

Q4: Do company agree to remove the highlighted bracket since both original ToReleaseList and size extension ToReleaseList cannot release the entries with an Id value larger than 8?.

Company	Yes/No	Comments
MediaTek	No	The text in brackets only intends to say that even if an element was added by using legacy Rel-15 addMod list, it can be deleted using Rel-16 size extension rel list. So, the UE does not need to remember which addMod list originally provided the element when the UE is releasing an element upon handling a rel list. The text in brackets is also in line with the guidance given by RRC spec rapporteur in RAN2#130 that an ID is just a value and there is no type checking in ASN.1. So, our preference is to keep the text in brackets. But, if majority wants to remove it, we can agree on majority's view.
ZTE	Yes	If both spatialRelationInfoToReleaseListSizeExt and spatialRelationInforToReleaseList can cover the whole Id values, it has no any ambiguities, otherwise, this is defined by i.e, it is not clear how to release the entries whose Id value more than 8 by using those two ToRleaseList.
Nokia	No	We agree with MediaTek’s understanding. Actually, we wonder if deleting the highlighted text might cause further confusion in the future (e.g. in the scenario where the UE receives an initial configuration based on the Rel-15 spatialRelationInfoToAddModList but network later removes the configuration with Rel-16 spatialRelationInfoToReleaseListSizeExt), so it could be better to err on the side of caution and keep it.
CATT	No	We think text in bracket is correct and prefer to keep it.
Ericsson	No	Text in bracket is correct and prefer to keep. Only reason to release is that it is (strictly) misplaced in the ToAddMod field description.
Qualcomm	No
Samsung	Yes	We think that the bracket is working assuming that UE ignore those entries receiving pucch-SpatialRelationInfoId-v1610 i.e. spatialRelationInfoToReleaseListSizeExt will remove only the entries having only pucch-SpatialRelationInfoId (without suffix). However, given that there is spatialRelationInfoToReleaseList, there is no need to use spatialRelationInfoToReleaseListSizeExt-v1610 to remove 0-7 (pucch-SpatialRelationInfoId). Eventually, it would cause confusion who doesn't know our discusison. We have opposite interpretation from Nokia that if we keep this sentence, it would cause exactly the same confusion (i.e in the scenario where the UE receives an initial configuration based on the Rel-15 spatialRelationInfoToAddModList but network later removes the configuration with Rel-16 spatialRelationInfoToReleaseListSizeExt. We would like to ask if companies want to allow this scenario the UE receives an initial configuration based on the Rel-15 spatialRelationInfoToAddModList but network later removes the configuration with Rel-16 spatialRelationInfoToReleaseListSizeExt.
Huawei	No, but	the bracket seems to say that any entry created using spatialRelationInfoToAddModList can be deleted using spatialRelationInfoToReleaseListSizeExt, but such entries that were created together with spatialRelationInfoToAddModListExt including pucch-SpatialRelationInfoId-v1610 can only be deleted with spatialRelationInfoToReleaseListExt. It would be more accurate to say that: an entry created using spatialRelationInfoToAddModList can be deleted using spatialRelationInfoToReleaseListSizeExt, if its ID is in the range of elements of spatialRelationInfoToReleaseListExt, or using spatialRelationInfoToReleaseListExt otherwise, and an entry created using spatialReleationInfoToAddModListSizeExt can be deleted using spatialRelationInfoToReleaseList, if its ID is in the range of elements of spatialRelationInfoListExt, or using spatialRelationInfoToReleaseListExt otherwise. Answer to Samsung's question: this is allowed of course.

According to the companies’ comments, majorities do not want to remove the description in the bracket, but companies have different views on how we implement such description:

1: Two companies have different views on the scenario whether the rel-16 ToReleaseList can be used for releasing the entries which is initially configured by the Rel-15 ToAddModList(i.e., there is no any entires has been configured by the size extension ToAddModlist).

2: One company thinks this description is displaced into the wrong places. (which shall be in the description of ToReleaseList)

3: One company thinks this description shall be refined for the target of being more accurate.

Above all, rapporteur obtain the following conclusion on this issue:

- The description of releasing entries in the bracket is still kept in the specification.

- How and where to capture this description shall continue being discussed during online in RAN2#131 meeting.

Proposal 4: The releasing of the entries from spatialRelationInfoToAddModList and spatialRelationInfoToAddModListSizeExt shall be specified in the RRC specification, FFS: whether to keep the current description as it is or elaborate it for accuracy and clarity.

The third ToReleaseList (i.e.spatialRelationInfoToReleaseListExt-v1610) indicates PUCCH-SpatialRelationInfoId-r16 which can cover the whole Id value range of entries, but PUCCH-SpatialRelationInfoId-r16 is not defined anywhere which means PUCCH-SpatialRelationInfoId-r16 is not associated with any entries of PUCCH spatial relation info from specification perspective.

During online discussion, the views are categorized in below:

- From NW perspective, the issue is not critical as the ToReleaseList is just a value list transferring from NW to the UE regardless of the Id parameter is defined or not.

- From UE perspective, whether it is valid depending on the UE implementation when receiving the ToReleaseList with a undefined PUCCH-SpatialRelationInfoId-r16, if it is not valid from UE perspective, then RRC Reestablishment will be triggered.

Both sides’ POV is valid , so rapporteur would like to ask:

Q5: Whether the clarification in RRC specification for PUCCH-SpatialRelationInfoId-r16 is needed, such as, UE shall release the corresponding entries when receiving the spatialRelationInfoToReleaseListExt-v1610 with the PUCCH-SpatialRelationInfoId-r16 ?

Company	Yes/No	Comments
MediaTek	No
ZTE	Yes	From UE perspective, undefined pucch-SpatialRelationInfoId-r16 means nothing, from safety perspective, it is supported to have an explicit clarification in the RRC specification.
Nokia	No	We think the interpretation is obvious already and no further clarification is necessary unless the majority of companies think it will cause some misunderstanding. If only a few companies are concerned, maybe the understanding can be captured in the chair’s notes.
CATT	No
Ericsson	No
Qualcomm	No
Samsung	See comments	If majority doesn't want any clarificaiton, we could live at it is. The reason why we supported the clarification, it is odd to not define but to use it in general. It is simple description that PUCCH-SpatialRelationInfoId-r16 is equivalent to pucch-SpatialRelationInfoId or pucch-SpatialRelationInfoId-v1610. If we have such definition, one might not be puzzeld with the definition of PUCCH-SpatialRelationInfoId-r16 without knowing how ASN.1 work. How about we capturing the following in the chair’s note? PUCCH-SpatialRelationInfoId-r16 is equivalent to pucch-SpatialRelationInfoId or pucch-SpatialRelationInfoId-v1610.
Huawei	No

According to the comments from companies, the majorities would like not to capture the clarification in the specification. In order to keep the aligned understanding between UE and NW, rapporteur make the following proposal for the easy agreement.

Proposal 5(Easy Agreement): RAN2 clarifies that the PUCCH-SpatialRelationInfoId-r16 is equivalent to pucch-SpatialRelationInfoId or pucch-SpatialRelationInfoId-v1610 when UE receiving the spatialRelationInfoToReleaseListExt-v1610

Conclusion

According to the comments from companies, the following proposals can be obtained：

Easy Agreements：

Proposal 1 (easy agreement): RAN2 clarifies that “If the network includes spatialRelationInfoToAddModListExt in a RRCReconfiguration message, it shall include the same number of entries, and listed in the same order, as in the concatenation of included spatialRelationInfoToAddModList and included spatialRelationInfoToAddModListSizeExt in the same message”. No spec change is needed.

Proposal 3(Easy Agreement): RAN2 confirms that an entry created using spatialRelationInfoToAddModList can be modified using spatialRelationInfoToAddModListSizeExt, and vise versa. No spec change is needed.

Proposal 5(Easy Agreement): RAN2 clarifies that the PUCCH-SpatialRelationInfoId-r16 is equivalent to pucch-SpatialRelationInfoId or pucch-SpatialRelationInfoId-v1610 when UE receiving the spatialRelationInfoToReleaseListExt-v1610. No spec change is needed.

Need Discussion in RAN2#131:

Proposal 2: In the case where there are 8 entries have already been created by the patialRelationInfoToAddModList (i.e.Rel-15 ToAddModlist), it is allowed for NW to use the spatialRelationInfoToAddModList alone for adding more elements if the available Id of the added entry is no more than 8, or together with spatialRelationInfoToAddModListExt if the available Id of the added entry is greater than 8.

Proposal 4: The releasing of the entries from spatialRelationInfoToAddModList and spatialRelationInfoToAddModListSizeExt shall be specified in the RRC specification, FFS: whether to keep the current description as it is or elaborate it for accuracy and clarity.

References

[1] R2-2502884 Issues On R16 PUCCH Spatial Relation Info List ZTE, Samsung

[2] R2-2503855	Corrections on Spatial Relation Info list and sizeExt list for PUCCH	ZTE, Samsung, Qualcomm, CATT, MediaTek	CR