3GPP TSG-RAN WG2 #130	                                  R2-2503361
St Julian, Malta, 19-23 May 2025 

Agenda Item:	8.7.1
Source:	Qualcomm Incorporated
Title:	List of open issues in MAC 
Document for: Discussion 
1.  

Summary
Based on the discussion above, the following is the list of open issues for discussion at the RAN2#130 meeting. 
-	[MAC-01] SR priority adjustment
	The current agreement is to evaluate the potential spec impact of SR priority adjustment and then decide whether to adopt it (i.e. only if it is simple enough to capture).  Companies can use the following TP as the baseline for further discussion:



	
- 	[MAC-02] Impact of congestion (i.e. PSI-based SDU discard) on priority adjustment
-	[MAC-03] DSR cancelation in DC configuration
-	[MAC-04] Which type of ID should be used to identify a QoS flow, e.g. DRB ID + QFI ID or some other identifier
-	[MAC-05] Whether the Rate Control MAC CE includes single or multiple QoS flows
-	[MAC-06] Any additional fields that should be included in the Rate Control MAC CE
-	[MAC-07] Format of the Rate Control MAC CE
-	[MAC-08] Handling of triggered UL rate queries (e.g. multiplexing, transmission and cancelation, etc)
-	[MAC-09] How UE should handle the Rate Control MAC CE in DC configuration
-	[MAC-10] Behavior of bitRateQueryProhibitTimer
-	[MAC-11] Whether to apply the same design for UL rate control design to DL data transmission
-	[MAC-12] How to indicate in the Rate Control MAC CE that a query from UE is for available bit rate
-	[MAC-13] Priority fallback with consideration of PDU Set integrated handling

TDoc file reading error

TDoc file reading error

3GPP TSG-RAN WG2 Meeting #130	R2-2503438
St Julian’s, Malta, 19 – 23 May 2025

Agenda item:		8.7.1
Source:	Xiaomi
Title:	Open issues of Rel-19 XR UE capabilities
Document for:		Discussion and Decision

Conclusion
In this contribution, we discuss open issues of Rel-19 XR UE capabilities and propose the following 
Proposal 1: An optional UE capability with signalling (e.g. delayStatusReportNonDelayReportingData-r19) is introduced to indicate the support of including non-delay-reporting data ahead of delay-reporting data in the buffer size calculation for enhanced delay status report. A UE supporting this feature shall also indicate support of enhanced delay status report (enhancedDelayStatusReport-r19). The capability is per UE, not FDD-TDD DIFF, not FR1-FR2 DIFF.
Proposal 2: An optional UE capability with signalling (e.g. ul-RateQuery-r19) is introduced to indicate the support of bit rate query message (in UL Rate Control MAC CE) from the UE to the gNB. A UE supporting this feature shall also indicate support of UL rate control MAC CE (ul-RateControl-r19). The capability is per UE, not FDD-TDD DIFF, not FR1-FR2 DIFF.
Company contributions can focus on following open issues:
Open issue 1: the pre-requisite of enhanced delay status report
Open issue 2: whether to have separate or joint UE capability for UE Tx and Rx operations for unnecessary retransmission avoidance.
Open issue 3: whether RAN2 to define the UE capability for UAI for a ratio of gap occasions.

3GPP TSG-RAN WG2 Meeting #130	R2-2503563
Saint Julian’s, Malta, 19 – 23 May 2025	


Agenda item:	8.7.1
Source:	Nokia, Qualcomm (Rapporteurs)
Title:	Rapporteur Inputs
WID/SID:	NR_XR_Ph3-Core - Release 19
Document for:	Discussion and Decision
1	

Conclusion
This contribution has provided:
-	The list of XR agreements reached in RAN2 so far;
-	An update to the workplan;
-	A brief overview of the status in RAN1, RAN3, RAN4 and SA2.

3GPP TSG-RAN WG2 Meeting #130	R2-2503565
Saint Julian’s, Malta, 19 – 23 May 2025	


Agenda item:	8.7.1
Source:	Nokia (Rapporteur)
Title:	Stage 2 Open Issues
WID/SID:	NR_XR_Ph3-Core - Release 19
Document for:	Discussion and Decision
1	

Conclusion
One open issue has been identified:
Stage 2-1: PDU Set Based Handling without QoS parameters.
And to solve it, the following was proposed:
Proposal 1 (Stage2-1): send an LS to SA2 to clarify PDU set handling when the gNB is not provided with any PDU Set QoS Parameters from the SMF but still being provided with PDU Set information from the UPF.

3GPP TSG-RAN WG2 Meeting #130		R2-2503767
St. Julian’s, Malta, 19th – 23rd May 2025
Source:	vivo
Title:	Discussion summary and list of RLC open issue for R19 XR
Agenda Item:	8.7.1
Document for:	Discussion and Decision

Conclusion
In this contribution, we discuss some open issues related to RLC running CR for XR and collect the open issues for XR enhancements in RLC. Based on the discussion, the following proposals have been achieved:
Open issue RLC-1 (essential): Terminology for avoiding unnecessary retransmission, e.g. “obsolete”, or “outdated”, or “discard”
Proposal 1: (10/13) Use the term of “discard” for avoiding unnecessary retransmission, e.g. “stopReTxDiscardedSDU”, “t-RxDiscard”.
Other specifications will be updated accordingly, e.g. the corresponding RRC parameter(s), and corresponding description in TS 38.300. 
Rapporteur: The latest running CR will reflect this proposal. Companies have concern/different views on it could provide your further comments during the meeting. 
Open issue RLC-2 (not essential, but important): whether further changes are needed for SR triggered by t-RxDiscard expires.
Rapporteur suggests to follow the majority, i.e. there is no need on further change for SR triggered by t-RxDiscard expires. 
Rapporteur: The latest running CR will reflect this suggestion. Companies have concern/different views on it could provide your further comments during the meeting. 
Open issue RLC-3 (essential): whether use the terminology of “autonomous retransmission” or others.
Proposal 2: (7/13) The term “remaining time based retransmission” is used for autonomous retransmission in RLC. 
Other specifications will be updated accordingly, e.g. the corresponding RRC parameter(s), and corresponding description in TS 38.300. 
Rapporteur: The latest running CR will reflect this proposal. Companies have concern/different views on it could provide your further comments during the meeting. 
Open issue RLC-4 (essential): whether merge the autonomous retransmission procedure in clause 5.x into 5.3.2 or capture it separately.
Rapporteur suggests to follow the clear majority, i.e. merge autonomous retransmission procedure in 5.x into section 5.3.2 “retransmission”. 
Rapporteur: The latest running CR will reflect this suggestion. Companies have concern/different views on it could provide your further comments during the meeting. 
Other open issues:
Proposal 3: RAN2 to consider the above open issues related to RLC for XR: RLC-5 to RLC-12. 

3GPP TSG-RAN WG2 Meeting #130	R2-2503788
St Julian's, Malta, 19th – 23st May, 2025
Agenda Item:	 8.7.1
Source:	 Huawei, HiSilicon
Title:	 Summary of [POST129bis][503][XR] RRC running CR and open issues (Huawei)
Document for:  Discussion and Decision
1	

Conclusion
No proposals formulated 

Annex A:	Achieve of discussion in RAN2#129
This section is used to collect comments for the running CR in R2-250xxxx Running RRC CR for R19 XR_v00_Rapp. 
Question0: Any comments on the running CR?

A.1	LCP enhancements
For LCP with additional priority, during RAN2#128, it was agreed that As an optional capability, the UE can also support to fallback to default priority in the 2nd round of LCP.
Then, with the introduction of the UE capability, another qustion to ask is whether the network can configure the UE to enable the fallback to the default priority in the 2nd round of LCP
Companies are invited to answer the following question
Question1: Do companies think we should introduce RRC configuration to enable/disable the fallback to default priority in the 2nd stage of LCP?

A.2	DSR enhancements
For DSR enhancements, during RAN2#128, it was agreed in RAN2 that The UE may also support including non-delay critical data ahead of delay critical data in the buffer size calculation for DSR, which is a capability indicated to the NW.
Then, with the introduction of the UE capability, another qustion to ask is whether the network can configure the UE to inlcude the non-delay criticla data ahead of delay critical data in the buffer size calculation for DSR.
Companies are invited to answer the following question
Question2: Do companies think we should introduce RRC configuration to enable/disable the inclusion of non-delay critical data ahead of delay critical data in the buffer size calculation for DSR?

Currently, the maximum number of entries in the reporting threshold configuration is 4 as a placeholder, i.e., as many as 4 reporting thresholds can be configured by the RRC. 

Companies are invited to provide their view on the maximum number of thresholds for the list of reporting thresholds. Rapp recommends that issues like MAC CE size, PSDB, report accuracy should be considered
Question3: What should be the maximum number of configurable reporting thresholds in the enhanced DSR configuration?
A.3	Available data rate query
Regarding to the bit rate query, during RAN2#129, it was agreed as a working assumption that 
Working assumption:
Support rate query MAC CE with the target to use same design that we will agree for rate indication MAC CE.
The rate query MAC CE is configurable by the network, i.e. the network may turn it off completely (same as legacy).
In legacy R15, for the support of recommended bit rate query, the following was supported in the MAC spec

Then, in the RRC spec, the bit rate query prohibit timer was introduced in the logical channel configuration.

Following the agreement in this meeting (to follow the legacy configurability in the RRC by the network), rapp would like to ask the following question
Quesiton4: Do companies think we should follow the legacy, i.e., 
to introduce a prohibit timer for the UL transmission of the data rate query MAC CE?
to enable/disable the rate query MAC CE by the presence of the prohibit timer in the RRC configuration?


we have agreed that the available data rate indication shall be carried in the granularity of QoS flow level, with two possible options pending for further discussion

If the answer to the qustion4 is yes, the rapporteur would like to ask the following question
Quesiton5: If the answer to the question above is yes, should the prohibit timer be configured in the QoS flow level?

TDoc file reading error