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

Agenda item:	8.7.4.2
Source:	Qualcomm Incorporated
Title:	Discussion on DSR enhancements
WID/SID:	NR_XR_Ph3-Core
Document for:	Discussion and decision

Conclusion
Based on the above analysis, we respectively request RAN2 to discuss and agree to the following proposals:
[capability-01] Pre-requisite of Rel-19 DSR
Proposal 1.	A UE supporting Rel-19 DSR is not required to support Rel-18 DSR. 

DSR cancelation in DC
Observation 1. 	In DC, no enhancements are needed when a pending DSR is canceled because all its associated PDCP SDUs have been discarded or included in a MAC PDU.
Observation 2.	In DC, UE may cancel a pending DSR only within an individual MAC entity if the cancelation is due to transmission of a DSR MAC CE, unless the UE is capable of dynamically coordinating between its two MAC entities.
Proposal 2.	[MAC-03] For Rel-19, define an optional UE capability, which is per band combination, for the support of canceling pending DSRs in both MAC entities when an associated DSR MAC CE is sent in one of the MAC entities.  
Proposal 3.	[MAC-03] For UEs that support the capability defined in Proposal 1, network configures UE whether it shall cancel pending DSRs in both MAC entities when an associated DSR MAC CE is sent in one of the MAC entities.
Proposal 4.	For Rel-18, make the following changes:
Clarify in the normative text that pending DSRs in both MAC entities are cancelled when the corresponding DSR cancelation conditions are met in any MAC entity. 
Add a note to allow UE implementation whether to support cancelling pending DSRs in both MAC entities when an associated DSR MAC CE is sent in one of the MAC entities.
Proposal 5.	Adopt the TP for Rel-18 in the Appendix if Proposal 3 is agreed.
Appendix – TP for Rel-18 DSR cancelation
5.4.9	Delay status reporting
(text omitted)
After a DSR is triggered, it is considered as pending until it is cancelled. The MAC entity shall cancel a pending DSR, when all the PDCP SDUs associated with the DSR have been discarded, or when a MAC PDU is transmitted and this MAC PDU includes a DSR MAC CE that contains the delay information of all the PDCP SDUs associated with the DSR (as described in the clause 6.1.3.72), or when a MAC PDU is transmitted and this MAC PDU includes all the PDCP SDUs associated with the DSR.
NOTE 2:	It is up to UE implementation whether the MAC entity includes a DSR MAC CE in a MAC PDU if the MAC PDU can accommodate all PDCP SDUs associated with all the pending DSRs but is not sufficient to additionally accommodate the DSR MAC CE plus its subheader.

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


Source:	CATT 
Title:	Consideration on DSR Enhancement
Agenda Item:	8.7.4.2
Document for:	Discussion and Decision

Conclusion
According to the analysis in section 2, we propose:
Proposal 1: (PDCP-1) All PDCP/RLC control PDUs and retransmission data should always be associated to the smallest configured reporting threshold.
Proposal 2: (PDCP-1) For cases where the calculated buffer size for the smallest configured reporting threshold only contains PDCP/RLC Control PDUs and/or retransmission data, it is UE implementation to set the remaining time field for this reporting threshold in the DSR MAC CE.
Proposal 3: (UE capability-01) UE supporting R19 enhanced DSR will separately report the capability for R18 DSR.

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

Agenda Item:	8.7.4.2
Source: 	OPPO
Title:  	Discussion on DSR enhancements for XR
Document for:	Discussion and Decision

Conclusion
Based on the discussion above, we made the following observations and proposals:
[UE Cap-1] The pre-requisite of enhanced delay status report
From UE implementation perspective, considering UE behaviour for Rel-18 DSR is actually a special case of Rel-19 DSR, it is not possible for a UE only support Rel-19 DSR without Rel-18 DSR.
[UE Cap-1] From UE capability signalling perspective, no need to have the pre-requisite for the capability of Rel-19 DSR.
[PDCP-1, RLC-5] Control PDUs and retransmitted data
If first reported portion adopted, additional effort is needed for cross-layer/entity interaction for the cases including
1/ LCHs within one LCG have delay-reporting data but the first reported portions of these LCHs are different;
2/ LCH within one LCG but does not have delay-reporting data.
[PDCP-1, RLC-5] For Rel-19 DSR data volume calculation, all PDCP/RLC control PDUs and retransmission data should always be considered into the first configured portion of the associated LCG.
[PDCP-1, RLC-5] In case of only PDCP/RLC Control PDUs and/or retransmission data without delay-reported data contained in the first configured portion of the associated LCG, RAN2 discusses the alternatives to set its remaining time field in the DSR MAC CE:
Alt-1: A reserved value (e.g., 0);
Alt-2: The smallest reporting threshold (i.e., dsr-ReportingThreshold, i=1).
[MAC-03] DSR cancellation in case of DC
Although the current MAC specification is written from MAC entity perspective, cross-MAC entity interaction has been supported.
[MAC-03] RAN2 confirms that the MAC entity cancels a pending DSR in case that all PDCP SDUs associated with the DSR is transmitted by its own or other MAC entity.
[MAC-03] For DSR cancellation in case of DC in Rel-19, RAN2 chooses either one between the following two alternatives 
Alt-1: No MAC specification change;
Alt-2: Option-2 in R2-2500894, i.e., the MAC entity shall cancel a pending DSR when a MAC PDU is transmitted by any MAC entity and this MAC PDU includes all the PDCP SDUs associated with the DSR.

4. 

3GPP TSG-RAN2 Meeting #130	R2- 2503476
St.Julian’s, Malta, May 19th – 23rd, 2025

Agenda item:		8.7.4.2 (NR_XR_Ph3)
Source:	LG Electronics Inc.
Title: 	Remaining issues on DSR enhancement for XR
Document for:	Discussion and Decision
1.	

Conclusion
In this contribution, it is discussed for the DSR enhancement for XR. This document includes following proposals.
Proposal 1. The PDCP entity should consider followings for delay-reporting PDCP data volume calculation associated with the first configured reporting threshold:
-	the PDCP Control PDUs;
-	for AM DRBs, the PDCP SDUs to be retransmitted according to clause 5.1.2 and clause 5.13;
-	for AM DRBs, the PDCP Data PDUs to be retransmitted according to clause 5.5.
Proposal 2. The RLC entity should consider followings for delay-reporting RLC data volume calculation associated with the first configured reporting threshold:
RLC data PDUs that are pending for retransmission (RLC AM).
Estimated size of STATUS PDU.
Proposal 3. If there is only PDCP/RLC control PDUs and/or retransmission data for an LCG, the delay information is not needed to be reported in R19 DSR MAC CE. No spec impact.
Proposal 4. If the delay-reporting data volume associated with shortest reporting threshold only includes the PDCP/RLC control PDU and retransmitted data, the remaining time field is set to 0.
Proposal 5. For DC case, no further enhancements on DSR due to transmission of DSR MAC CE in the other MAC entity and this DSR MAC CE with the delay information of all the PDCP SDUs associated with the DSR.
Proposal 6. For Rel-19, cancel the DSR when a MAC PDU is transmitted in any MAC entity and this MAC PDU includes all the PDCP SDUs associated with the DSR.

4.	

3GPP TSG-RAN WG2 Meeting #130											R2-2503510
St. Julians, Malta, May 19th – 23rd, 2025
Agenda Item:	8.7.4.2
Source: 	Sharp
Title:  	Open Issues on DSR Enhancements
Document for: 	Discussion

Conclusions
Based on the discussion above, RAN2 is requested to agree the following proposals:
It is up to NW implementation to configure thresholds to avoid the empty DSR issue (no specification impact).
Consider Control PDU and PDUs/SDUs to be retransmitted as the data volume of the smallest reported dsr-ReportingThreshold for the PDCP entity.
If there is no delay-reporting PDCP SDUs in a PDCP entity, Control PDU is not considered as PDCP data volume for DSR.
If there is no delay-reporting PDCP SDUs in a PDCP entity, PDUs/SDUs to be retransmitted are not considered as PDCP data volume for DSR.
RLC data volume calculation and PDCP data volume calculation on Control PDU and PDUs/SDUs to be retransmitted are consistent with each other.
If dsr-ReportNonDelayCriticalData is configured, PDCP indicates non-delay reporting PDCP PDUs associated with the i:th dsr-ReportingThreshold as the delay-reporting RLC SDUs associated with the i-th dsr-ReportingThreshold.
Remove all the description related to non-delay reporting RLC SDU from RLC specification.
RAN2 to confirm that New DSR MAC CE is always used when at least one LCG is configured with multiple thresholds.
If at least one LCG is configured with dsr-ReportingThresList, any LCG configured with a triggering threshold shall be configured with at least one reporting threshold.

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

Agenda item:	8.7.4.2
Source: 	Fujitsu
Title: 	Discussions on DSR enhancements
Document for:	Discussion and decision

Conclusion
In this contribution, we have discussed the further details of the DSR enhancements. We have the following proposals: 
Observation 1: For the LCG configured with multiple reporting thresholds but with only one pair of remaining time and buffer size to be reported, or for the LCG configured with only one reporting threshold, the enhanced DSR format can include just one pair of remaining time information and buffer size information for this LCG. 
Proposal 1: Enhanced DSR is always used in case there is at least one LCG configured with multiple reporting thresholds.
Proposal 2: Both PDCP and RLC consider Control PDU and/or retransmitted data into the shortest configured reporting threshold.
Proposal 3: The value of the remaining time field in the enhanced DSR MAC CE is set to 0, if there are only control PDUs and/or retransmitted data to be reported for the shortest configured reporting threshold of the LCG. 

3GPP TSG-RAN WG2 Meeting #130	R2-2503623
St. Julian's, Malta, 19th – 23rd May 2025
Source:	vivo
Title:	Remaining issues on DSR enhancements for XR
Agenda Item:	8.7.4.2
Document for:	Discussion and Decision

Conclusion
In this contribution, we have discussed remaining issues regarding DSR. Based on the discussions, there are the following observations:
Observation 1	(MAC-03) For a LCG corresponding to split DRB in case of DC, the DSRs of both legs are generated based on the data in the common PDCP buffer and the data in the respective dedicated RLC buffers.
Observation 2	(MAC-03) In case of DC, the RLC buffer size and the remaining time of the data in dedicated RLC buffer can be different between two legs due to differentiated channel quality variation /uplink resource allocation between the two legs.

Based on the above discussions and the observations, we have the following proposals:
Proposal 1	(PDCP-1/RLC-5) Both PDCP/RLC control PDUs and the retransmission data should be counted into the delay-reporting data volume of the smallest reported threshold included in the DSR.
Proposal 2	(PDCP-1/RLC-5) The PDCP/RLC control PDUs and retransmission data of an LCH without other delay-reporting data should be counted into the data volume of the shortest reported threshold of the corresponding LCG.
Proposal 3	(MAC-03) In case of DC, DSR cancellation of one leg does not trigger DSR cancellation of the other leg.
Proposal 4	(MAC-03) In case of DC, each MAC entity determines DSR cancellation independently based on the existing DSR cancellation conditions as defined in R18.
Proposal 5	(Capability Open issue 1) It is left to UE implementation whether a UE supporting enhanced DSR also supports legacy DSR.

TDoc file reading error

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


Agenda item:	8.7.4.2
Source:	Apple
Title:	On Data Volume Calculations for Rel-19 DSR
WID/SID:	NR_XR_Ph3-Core
Document for:	Discussion / Decision

Conclusions
This paper presented our views on the reporting threshold association for data volume calculation, with considerations of PDCP/RLC Control PDUs and retransmissions. We have the following proposals:
Proposal 1: For Rel-19 DSR data volume calculation, all PDCP/RLC control PDUs and retransmission data should always be associated to the smallest configured reporting threshold, which is the i-th dsr-ReportingThreshold with i=1.
Proposal 2: For cases where the calculated buffer size for the smallest configured reporting threshold only contains PDCP/RLC Control PDUs and/or retransmission data, RAN2 selects one of the following alternatives to set the remaining time field for this reporting threshold in the DSR MAC CE:
Alt. 1: Set the remaining time field in DSR MAC CE as 0;
Alt. 2: Set the remaining time field in DSR MAC CE as the i-th dsr-ReportingThreshold with i=1 (i.e. the smallest reporting threshold);
Alt. 3: Leave it to UE implementation.

3GPP TSG-RAN WG2 Meeting #130	R2-2503794
St.Julians, Malta, May 19th – 23rd, 2025	
Agenda item:	8.7.4.2 
Source:	China Telecom
Title:	Discussion on Remaining Issues of DSR Enhancements
Document for:	Discussion and Decision

Conclusions
Based on the above analysis, we have the following proposals:
Proposal 1: For data volume calculation, both PDCP/RLC Control PDUs and retransmitted data should be associated to the shortest configured reporting threshold (Option 2 is preferred). 
Proposal 2: Set the remaining time field as the smallest reporting threshold. 

3GPP TSG-RAN WG2 Meeting #130	R2-2503834
Malta, 19 – 23 May, 2025	


Agenda item:	8.7.4.2
Source:	InterDigital
Title:	DSR enhancements for UL scheduling
WID/SID:	NR_XR_Ph3-Core - Release 19
Document for:	Discussion and Decision
1	

Conclusion
This document has made the following proposals:
Proposal 1: New DSR MAC CE format will always be used when at least one LCG is configured with one or more reporting thresholds.
Observation 1: In Release 18, if an LCG has no pending DSR(s) when the DSR MAC CE is being built, the DSR is not reported for that LCG. Hence, control PDU(s)/Re-Tx data alone would never be reported for an LCG.
Proposal 2: The control PDUs and re-transmission data for an LCG are only reported in the new DSR MAC CE provided that there is a pending DSR for the LCG.
Proposal 3: The additional delay critical data amount from control PDUs and re-transmission data is included into the smallest reported threshold in the new DSR MAC CE.

3GPP TSG-RAN WG2 #130 meeting	R2-2503885
St Julian's, Malta, 19th May – 23rd May, 2025

Source:		NEC
Agenda item:		8.7.4.2	DSR enhancements
Title:		Remaining issues on DSR enhancements
Document for:		Discussion and decision
1. 

Summary
This contribution provides our analysis on the enhancement of DSR, and has the following proposals:
Proposal 1: To address the “empty DSR” issue, RAN2 agrees that the enhanced DSR is triggered when there is data with remaining time below both the trigger threshold and the largest configured report threshold.
Proposal 2: RAN2 discusses to revise the definition of a PDCP SDU associated with a DSR, or introduce a new definition of a PDCP SDU associated with an enhanced DSR.
Proposal 3: For an LCH or LCG, triggered BSR should be cancelled when the buffer size reported in enhanced DSR equals the total buffer size (i.e., “delay-reporting buffer size + non-delay-reporting buffer size” equals “total buffer size”).
Proposal 4: RAN2 to discuss the following options if the UL-SCH resources cannot accommodate an enhanced DSR MAC CE plus its subheader:
Option 1: Trigger an SR.
Option 2: Merge pairs of delay information. 
Option 3: Report at most one pair of delay information for an LCG.
Proposal 5: RAN2 confirms that only enhanced DSR MAC CE shall be used when at least one LCG is configured with multiple reporting thresholds.

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

Agenda item:	8.7.4.2
Source:		Lenovo
Title:			Enhanced delay status reporting for XR 
Document for:	Discussion and Decision

Conclusion
In this contribution, we discuss delay status reporting enhancements. We have the following proposals:
Proposal 1: RAN2 to agree to report PDCP Data PDUs/SDUs to be retransmitted in the delay-reporting data volume in smallest reported range/threshold. 
Proposal 2: RAN2 to agree to report PDCP control PDUs in the smallest reported threshold.

3GPP TSG-RAN2#130									         R2-2503973
St Julian, Malta, 19th – 23rd May, 2025	             
Source: 			ZTE Corporation, Sanechips
Title: 	DSR enhancements for XR
Agenda item:	8.7.4.2
Document for: 	Discussion and Decision

Conclusion and proposals
The following observations/proposals are made: 
Observation 1: If the remaining time of retransmitted data is put in the smallest reported threshold, it may lead the retransmitted data more easily outdated.
Observation 2: Including the retransmitted data in the smallest configured threshold will not increase the load of Multiple Entry DSR MAC CE.
Proposal 1(RLC-5): During DSR data volume calculation, the retransmitted data is put in the data volume related to the smallest configured threshold.
Proposal 2(RRC-7): In field description of DSR triggering threshold, capture the restriction that “at least one configured reporting threshold should be no lower than the DSR triggering threshold”.
Proposal 3(RRC-7): UE shall not report data volume with remaining time larger than the largest reporting threshold in the DSR.
Observation 3: The new DSR MAC CE is compatible with the legacy DSR MAC CE. The UE can identify whether the DSR MAC CE is a new DSR MAC CE or legacy DSR MAC CE based on the value of the reserved bit if the UE supports the new DSR MAC CE, no new LC-ID is necessary for the new DSR MAC CE.
Proposal 4(RRC-7): New DSR MAC CE will (always) be used when at least one LCG is configured with multiple thresholds, and not define new LC-ID for the new DSR MAC CE.
Observation 4: only the condition “when a MAC PDU is transmitted and this MAC PDU includes all the PDCP SDUs associated with the DSR” in the DSR cancellation cases need to be clarified for DC configuration.  
Proposal 5(MAC-03): The pending DSR is canceled in the following cases:
when all the PDCP SDUs associated with the DSR have been discarded. 
when a MAC PDU is transmitted and this MAC PDU includes a DSR MAC CE that contains the delay information of all the PDCP SDUs associated with the DSR. 
when all the PDCP SDUs associated with the DSR have been transmitted.  

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

Agenda item:	8.7.4.2
Source: 	Huawei, HiSilicon
Title: 	Remaining open issues on DSR enhancements in XR
Document for:	Discussion and Decision
1. 

Conclusion
In this contribution, we analyzed the potential aspects for DSR enhancements. The following observations and proposals were made:
Buffer size calculation for control signalling and retransmission [PDCP Issue 1]
Proposal 1:	(PDCP-1) The Option A (i.e. option of “smallest reported threshold”) should be applied, where all the PDCP/RLC control PDU and PDCP/RLC retransmitted PDU/SDU are calculated to the buffer size for the smallest reported threshold.
DSR cancellation in Dual Connectivity [Open issue no.: MAC-03]
Observation 1:	The MAC specification specifies the behaviour from a MAC entity perspective, and one MAC entity cannot cancel the pending DSR according to an event happening in another MAC entity.
Observation 2:	One MAC entity cancels the pending DSR according to an event happening in another MAC entity by inter-MAC interaction can cause sever complexity to UE implementation.
Observation 3:	The solution for DSR cancellation in DC should not impact on UE complexity.
Proposal 2:	(MAC-03) In Dual Connectivity case, a MAC entity can cancel the pending DSR if the volume of delay-critical data associated with the DSR is zero even though no MAC PDU including PDCP SDUs associated with the DSR was transmitted.
Proposal 3:	(MAC-03) In current spec, for Dual Connectivity case, the BSR can already be cancelled if a BSR MAC CE is sent, and there is no spec impact for BSR.
Co-existence between Rel-18 and Rel-19 DSR MAC CE [RRC Open Issue 7]
Observation 4:	Since Rel-18 triggering threshold by itself is also a reporting threshold, it is sufficient for the UE to use Rel-19 new DSR MAC CE as long as at least one LCG is configured with Rel-19 reporting threshold(s). There is no impact to PDCP and RLC specifications.
Proposal 4:	(RRC-7) New DSR MAC CE will (always) be used when at least one LCG is configured with Rel-19 reporting threshold(s) (rather than all LCGs are configured with multiple reporting thresholds).
Proposal 5:	(RRC-7) When the R19 DSR MAC CE is used which includes LCG(s) configured only with triggering threshold, the triggering threshold is reused as the reporting threshold for these LCGs.
UE capability for DSR enhancement [Open Issue 1 in UE cap running CR]
Proposal 6:	(UE-Cap-1) UE supporting enhancedDelayStatusReport-r19 supports delayStatusReport-r18 as pre-requisite.
Rel-19 DSR on BSR cancellation
Proposal 7:	(Others) RAN2 to specify that all triggered BSRs can be cancelled if amount of data to be reported in the BSR is already indicated by the DSR included in the same MAC PDU, as given in Appendix. 
4. 

3GPP TSG-RAN2 Meeting #130			R2-2504374
St. Julian, Malta, 19th-23rd May

Agenda item:	8.7.4.2
Title:	Further consideration on DSR enhancement for XR
Source:	CMCC
Document for:	Discussion

Conclusion
Based on the abovementioned analysis and observations, the following is proposed.
Threshold configuration:
Observation 1: NW may configure a triggering threshold lower than all reporting threshold to avoid any possible discarding and have a clear insight into the potential delay-critical data in the buffer queue.
Proposal 1: There is no restriction and no specification impact on the time relationship of configured and reporting thresholds, which is entirely up to NW implementation.
Data volume calculation:
Proposal 2a: As legacy, C-PDU and SDU/Data PDU to be retransmitted alone will not trigger DSR.
Proposal 2b: If DSR is triggered, due to its importance, C-PDU can be reported in the smallest reported threshold.
Observation 2a: Since it's unclear whether the SDUs/data PDUs to be retransmitted always have low remaining time, and they may not be as critical as C-PDUs, putting all of them in the smallest configured reporting threshold could mislead the network about the presence of truly delay-critical data.
Observation 2b: In UE implementation, the data volume of C-PDU and retransmitting SDU/data PDUs only needs to added to the smallest reported threshold after UE calculates the data volume for that threshold.
Proposal 2c: The retransmitting SDU/data PDU is also reporting the smallest reported threshold.
Observation 3: In case of UL congestion and PSI-based discarding is activated, the benefit of reporting low importance data is doubtful as such data may be discarded before the next UL grant.
Proposal 3: The data in low importance PDU set is not considered in data volume calculation if PSI-based discarding is activated.
Non-delay-critical-reporting data:
Proposal 4: Capture “UE should ensure the ordering of data in buffer is consistent with actual data transmission behaviour by its implementation, when UE determines non-delay-reporting data ahead of delay-reporting data for delay-reporting data volume calculation.” in PDCP running CR.
UE behavior when UL grant cannot accommodate DSR:
Proposal 5a: If UL grant cannot accommodate the intact enhanced Rel-19 DSR, UE may use legacy DSR instead.
Proposal 5b: If UL grant cannot accommodate even the intact legacy DSR, UE may only report delay status on LCG(s) with least remaining time.

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

Agenda item:	8.7.4.2
Source:	Nokia, Nokia Shanghai Bell
Title:	DSR enhancements
WID/SID:	NR_XR_Ph3-Core - Release 19
Document for:	Discussion and Decision
1	

Conclusion
Remaining issues on DSR enhancements are discussed in this contribution with the following observations/proposals proposed:
Observation 1: if an LCG is with only control PDUs and/or retransmission SDUs/PDUs, there can be no DSR pending for that LCG, hence the LCG is not reported in the DSR (as in legacy).
Proposal 1: PDCP control PDUs and retransmission data are included in the buffer size calculation corresponding to the smallest reported threshold.
Proposal 2: a UE supporting enhancedDelayStatusReport-r19 shall also support delayStatusReport-r18.
Proposal 3: it is possible to configure some LCGs with reporting threshold while some other LCGs without and the Rel-19 DSR format is used if any LCG is configured with reporting threshold.
Proposal 4: when in DC, if a DSR is triggered on both MAC entities and it is cancelled because a DSR MAC CE is sent and the DSR MAC CE includes delay status information of all the PDCP SDUs associated with a pending DSR, the DSR is cancelled only on the MAC entity where the DSR MAC CE is transmitted (legacy behaviour). 

3GPP TSG-RAN WG2 Meeting #130	R2-2504435
St Julian’s, Malta, 19 – 23 May, 2025	
Agenda item:	8.7.4.2
Source:	Samsung
Title:	Remaining Issues on DSR enhancements in Rel-19 XR
Document for:	Discussion & Decision

Conclusion
Based on the discussion above, we have the following observation and proposals:
Proposal 1. For Rel-19 DSR, all PDCP/RLC control and retransmitted data is associated to the smallest configured reporting threshold, which is the i-th dsr-ReportingThreshold with i=1.
Proposal 2. For Rel-19 DSR, when the smallest configured reporting threshold is associated with only PDCP/RLC Control and/or retransmitted data, set the remaining time field associated to the threshold to 0.
Observation 1: The agreement that mandates explicit reporting threshold configuration introduces unnecessary duplicated configuration/signalling overhead, when there is only one reporting threshold configured with the same value as triggering threshold.
Proposal 3. In Rel-19 DSR, if an LCG with triggering threshold is not configured with reporting threshold, the triggering threshold is used as reporting threshold for the LCG.
Observation 2: COUNT-based modelling is better than the other options in modelling the “ahead of” condition, since 1) it clearly captures the criteria on how to determine one SDU is ahead of another, and thus 2) saving the efforts to interpret a condition requiring more interpretation, and 3) achieving a unified UE behavior across different UE vendors.
Proposal 4. Using COUNT-based modelling to model the “ahead of” condition between non-delay-reporting data and delay-reporting data.

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

Agenda Item:	8.7.4.2
Source:	HONOR
Title:	Discussion on DSR enhancements
Document for:	Discussion and Decision
1. 

Conclusions
Proposal 1: (PDCP Issue 1) Consider Control PDU and retransmission data as the data volume of the smallest reported threshold for the PDCP entity and RLC entity.
4. 

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

Source:                    	DENSO CORPORATION
Title:  	Discussion on DSR enhancements for XR
Document for:        	Discussion and decision
Agenda Item:         	8.7.4.2		DSR enhancements

Conclusion
In this contribution, we provided the following proposals.
Proposal 1:	(PDCP-1, RLC-5) Both PDCP and RLC entities consider control PDUs and data to be retransmitted as delay-reporting data volume associated with the smallest configured reporting threshold.
Proposal 2:	If only control PDUs and data to be retransmitted are associated with the smallest configured reporting threshold for an LCG, the corresponding remaining time field for the LCG can be set to zero.

3GPP TSG-RAN WG2 Meeting #130	R2-2504574
St.Julians, Malta, May 19-23, 2025
Source:	III
Title:	Discussion on XR DSR enhancements
Agenda item:	8.7.4.2
Document for:	Discussion

Conclusion
The related proposals and observations from above discussions are below:
Observation 1: 'Both PDCP and RLC consider Control PDU and retransmitted data in the shortest reporting threshold included in the DSR' may not cover situations where the LCH contains only the control PDU and retransmitted data.
Proposal 1: Both PDCP and RLC consider Control PDU and retransmitted data into the shortest threshold.
Observation 2: If the DSR includes non-delay critical data, managing the DSR in XR will lead to resource utilization synchronization challenges between the UE and gNB.
Observation 3: For DSRs that include non-delay critical data in XR, a real-time feedback mechanism between the UE and gNB is required to enhance resource allocation efficiency and synchronization.
Proposal 2: When the DSR includes non-delay critical data, the real-time feedback mechanism should be discussed.

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


Agenda Item:	8.7.4.2
Source:	Ericsson
Title:	Discussion on DSR enhancements
Document for:	Discussion, Decision
1	

Conclusion
In the previous sections we made the following observations: 
Observation 1	If an LCG has multiple reporting thresholds configured, a single threshold DSR should only be used for reporting when this creates no ambiguity for the network scheduler.
Based on the discussion in the previous sections we propose the following: 
Proposal 1	PDCP Control PDUs, the PDCP SDUs to be retransmitted, and the PDCP Data PDUs to be retransmitted are to be reported in the lowest remaining time threshold configured. If no delay reporting data is present in this threshold use a reserved value for indicating the remaining time, e.g. 1ms.
Proposal 2	New DSR MAC CE will (always) be used when at least one LCG is configured with multiple thresholds and the LCG has data in more than one threshold.
Proposal 3	BSR cancellation should not have dependencies to DSR transmission.