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

Agenda item:	8.20.2
Source:	Nokia, Nokia Shanghai Bell
Title:	RTP Retransmissions for XR
WID/SID:	NR_XR_Ph3-Core - Release 19
Document for:	Discussion and Decision
1	

Conclusion
This contribution has discussed the SA4 LS on RTP Retransmissions for XR and has observed that identifying RTX PDUs would be beneficial to the RAN and can easily be done if two QoS flows are setup (one for the source stream and another one for the retransmissions streams).

3GPP TSG-RAN WG2 Meeting #130                                                                    R2-2503578
St. Julians, Malta, May 19th – 23rd , 2025

		
Source:	CATT 
Title:	Views on LS on RTP retransmission (S4-250739)
Agenda Item:	8.20.2
Document for:	Discussion and Decision

Conclusion
According to the analysis in section 2, we have the observations as below:
Observation 1：Whether a separate QoS flow is necessary for RTP retransmission PDUs depends on how many and how often RTP PDUs need to be retransmitted, but this is not clear according to the SA4 LS.
Observation 2: It’s up to gNB implementation to map different QoS flows to same/different DRBs, and also up to gNB implementation to achieve the corresponding scheduling to fulfill the QoS requirement. No additional assistance information from application layer seems to be really necessary.
Observation 3: RAN2 work is postponed until SA2 determines what enhancement is needed for mapping between QoS flow and DRB.
And we propose:
Proposal 1: RAN2 to reply to SA4 with the following information:
Whether a separate QoS flow is necessary for RTP retransmission PDUs depends on how many and how often RTP PDUs need to be retransmitted, but this is not clear according to the SA4 LS.
It’s up to gNB implementation to map different QoS flows to same/different DRBs, and also up to gNB implementation to achieve the corresponding scheduling to fulfill the QoS requirement. No additional assistance information from application layer seems to be really necessary.
RAN2 work is postponed until SA2 determines what RAN enhancement is needed for mapping between QoS flow and DRB.

3GPP TSG-RAN WG2 Meeting #130	R2-2504117
St.Julian's, Malta, 19-23 May, 2025

Agenda item:	8.20.2
Source: 	Huawei, HiSilicon
Title: 	Discussion on LS S4-250739 for RTP retransmission
Document for:	Discussion and Decision
1. 

Conclusion
In this contribution, we discussed the LS from SA4 on RTP retransmission. The following proposals were made:
Proposal 1: RAN2 to reply to SA4 that there is no additional benefit to RAN from receiving application layer retransmission information if the retransmission PDUs and the source PDUs are mapped to distinct QoS flows and no RAN impact is needed. 
4. 

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

Agenda item:	8.20.2
Source:	Nokia
Title:	UE usage of the RAT restrictions
WID/SID:	ECRATU - Release 19
Document for:	Discussion and Decision
1	

Conclusion
Observation 1: UE implementing ECRATU and supporting 2G/3G/4G/5G has to implement also ECRATU for all the supported radio technologies before it can indicate NAS support for the feature
Observation 2: Adding separate capabilities in AS does not help as NW NAS would still consider UE supporting the feature completely
Observation 3: UE not implementing part of ECRATU (e.g. omitting 2G) does not work as there is no way for NW to know which UE will follow the requests (e.g., ECRATU message) and which UE cannot
Proposal 1a: Work together with interested companies to bring CRs for 2G/3G ECRATU to plenary
Proposal 1b: Ask CT1 to implement separate capabilities purely for IOT reasons for ECRATU support for 2G and/or 3G and possibly also separate capabilities for 4G/5G