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

Agenda item:	8.7.5
Source:	Qualcomm Incorporated
Title:	Discussion on RLC 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:
Status report
Observation 1.	To take full advantage of the polling enhancement in reducing RLC round-trip time, it is important to enhance the corresponding status reports too.
Proposal 1.	When sending a poll, the transmitter includes an indication whether it is a time-critical poll (i.e. triggered due to remaining time below a threshold).
Proposal 2.	Upon receiving a time-critical poll, the receiver triggers a time-critical status report without the restriction by t-StatusProhibit (or apply a shorter t-StatusProhibit).
Proposal 3.	When the remaining value of t-RxDiscard is below a configured threshold, the receiver sends a time-critical status report without the restriction by t-StatusProhibit (or apply a shorter t-StatusProhibit). 
Avoiding unnecessary retransmissions
Observation 2. 	If a low-latency DRB is configured with active discard, it may not be possible for RETX_COUNT to reach maxReTxThreshold.
Observation 3. 	maxReTxThreshold can’t be too small either (e.g. to match the average number of retransmissions before discard), or it can result in false triggering of RLF. 
Proposal 4. 	[RLC-06] Define a new RLF trigger for DRBs configured with active discard, e.g. RLF is triggered after N active discards (expiry of PDCP discard timer) within the last M SDUs or last T msec.
UE capabilities
Observation 4. 	Retransmission of outdated SDUs can still be avoided even if only the receiver side enhancements are applied. 
Proposal 5.	[capability-02] Define separate UE capabilities for transmitter and receiver enhancements for avoiding unnecessary retransmissions.
Impact of discard on PDCP SN gap report
Observation 5.	There may be more lost PDCP SN gap reports in Rel-19, which can cause extra delay in the delivery of other SDUs to the upper layers and degrading mobility performance.
Observation 6.	It is inefficient to have UE send an SN gap report after every mobility event, as a lost report is less frequent than the average case.
Proposal 6. 	[RLC-12] UE triggers a PDCP SN gap report when it receives a status report in which an SDU indicated in a previous SN gap report is negatively acknowledged.  

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

Source:	CATT 
Title:	Further Consideration on XR-specific RLC Enhancement
Agenda Item:	8.7.5       
Document for:	Discussion and Decision

Conclusion
According to the analysis in section 2, it is proposed:
Proposal 1: (RLC-9) The network defines the discardTimer appropriately which would consider the initial HARQ transmission including the remaining time.
Proposal 2: (RLC-7) For the autonomous retransmission and legacy retransmission, they will be transmitted in the order SN of RLC SDU or segment, no further spec impact will be introduced.
Proposal 3: (RLC-7) It is not necessary to increase the RETX_COUNT when autonomous retransmission is performed.
Proposal 4:  (RLC-8) Only a single enhanced polling will be triggered per RLC SDU.
Observation 1: In legacy procedure, the retransmission will be triggered by negative acknowledgement in the status report and max retransmission will be indicated to high layer if RETX_COUNT = maxRetxThreshold.
Proposal 5: (RLC-6) There is no specification impact foreseen for RLF.

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

Agenda item:		8.7.5
Source:	Xiaomi
Title:	RLC AM retransmission enhancements
Document for:		Discussion and Decision

Conclusion
In this contribution, we discuss open issues of RLC AM retransmission enhancements, and propose the following:
Avoid unnecessary RLC retransmissions
Proposal 1: (RLC-6) There is no specification impact on RLF detection due to avoiding unnecessary retransmission at Tx side.
Proposal 2: (RLC-10) It is up to network implementation on whether to configure stopReTxDiscardedSDU / t-RxDiscard and related network behavior.
Timely RLC retransmission
Proposal 3: (RLC-7) Existing RLC procedure for RETX_COUNT is applicable for autonomous retransmission. No specification change is needed.
Proposal 4: (RLC-8) To avoid excessive polling, polling is triggered if the remaining time till discardTimer expiry becomes less than polling threshold for the PDCP SDU for which the corresponding PDCP Data PDU has already been submitted to lower layers for a time duration over a configured threshold.
Proposal 5: (RLC-9) No additional specification impacts are needed to prevent too early and/or unnecessary retransmissions due to polling enhancement.
Proposal 6: (PDCP-2) The UE shall trigger remaining-time-based RLC retransmission and polling in PDCP PDU level, no matter pdu-SetDiscard is configured or not. No specification change is needed.
Proposal 7: (RRC-3, RRC-4) Autonomous retransmission and enhanced polling are not applicable for discard for PDUs with low importance, which uses a separate timer discardTimerForLowImportance. No specification change is needed.

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

Agenda Item:	8.7.5
Source:	OPPO
Title:	Discussion on RLC re-transmission related enhancements 
Document for:	Discussion, Agreement

Conclusion
We have the following observations:
Observation 1	Both autonomous retransmission and retransmission avoidance influence retransmission behavior, thereby affecting the handling of RETX_COUNT.
Observation 2	The incrementing of RETX_COUNT is triggered when 1) the previous retransmission failed and 2) the retransmission is triggered again.
Observation 3	The RETX_COUNT parameter, which tracks the number of consecutive failed retransmissions, serves as an indicator of UL channel quality. When RETX_COUNT reaches the maxRetxThreshold, the UE may determine that UL channel conditions have degraded sufficiently to trigger a radio link failure (RLF) declaration.
Observation 4	For SDU discarding, the retransmission is not performed even when the previous retransmission fails, and RETX_COUNT will not be incremented.
Observation 5	SDU discard will impact RLC-based RLF detection, i.e., the maxRetxThreshold as the bottom line of UL transmission quality cannot be reached due to RETX_COUNT is not incremented for failed retransmissions.
Observation 6	In the current UE implementation, maxRetxThreshold is set to 32 by default as the bottom line, so the RLF miss-detection issue will happen a lot with the PDU discard is for the short delay budget data.
Observation 7	Autonomous retransmission is performed without NACK reception, i.e., the retransmission is not due to previous retransmission failure.
Observation 8	If Tx/Rx discard is configured to the UE, whether the peer-side operation is applied is fully up to the network implementation.
Observation 9	When all the SDUs in Tx buffer are indicated as discard, there is no need to do the polling.
Observation 10	The issue is same in R18 and R19 context, which means it is not a critical issue for R19 as well.
Observation 11	During the RLC discard enhancement discussion, R2 concluded no special handling to avoid PDCP control PDU discard is needed.
Observation 12	Unnecessary retransmission avoidance and timely retransmission are independent features introduced based on different motivations.
Observation 13	For unnecessary retransmission avoidance, Tx side and Rx side packet discarding can operate independently for different traffic directions.
Observation 14	For timely retransmission, as 2 independent thresholds are agreed for autonomous retransmission and polling, autonomous retransmission and polling enhancement can be supported independently.
Observation 15	Based on the Rx-timer discarding at the Rx side, if Tx side decides SDU discarding first, there may be: 1) window stalling at the Tx side during Rx_timer running; 2) additional specification impact at the Tx RLC of NACK feedback to the discarded SDUs.
Observation 16	Based on the Rx-timer discarding at the Rx side, if Rx side decides SDU discarding first, there may be: 1) data loss; 2) misalignment between MAC HARQ and RLC ARQ, i.e., HARQ NACK and ARQ ACK for the same packet.
Observation 17	A simple Tx to Rx indication via a data PDU without a Data field adds no complexity to the current procedure and effectively addresses all issues discussed in Observations 1 and 2.

We have the following proposals:
Proposal 1	(RLC-6) RAN2 to discuss whether/how to solve RLC-based RLF miss-detection issue (i.e., maxRetxThreshold cannot be reached) caused by in-flight PDU discard enhancement.
Proposal 2	(RLC-6) RAN2 to discuss solve RLC-based RLF miss-detection issue caused by SDU discard via adjusting either RETX_COUNT or maxRetxThreshold when SDU discard happens.
Proposal 3	(RLC-7) RETX_COUNT is not incremented for autonomous retransmission.
Proposal 4	(RLC-8) One polling will triggered per RLC SDU based on the enhanced polling mechanism. The Editor’s Note can be removed with no additional specification impact.
Proposal 5	(RLC-9) R2 confirm polling enhancement will not cause “too early and/or unnecessary retransmission”, the Editor’s Note can be removed with no additional specification impact.
Proposal 6	(RLC-10) RAN2 not pursue the limitations for the configuration of Tx and Rx side discard.
Proposal 7	(RLC-11) No need to handle the case “if there are only SDUs buffered whose transmissions have been stopped due to discard indication from PDCP, there is no SDU to retransmit the poll with”
Proposal 8	(RLC-12) No special handling is needed in R19 for PDCP SN gap report during UE mobility.
Proposal 9	RAN2 to discuss introducing separate capabilities for SDU discard at the Tx side, SDU discard at the Rx side, autonomous retransmission, and polling enhancement.
Proposal 10	RAN2 to discuss use data PDU with no Data field, i.e., only header with SN number to indicate the discard information from Tx to Rx side.

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

Agenda item:		8.7.5
Source:		Samsung
Title:			Discussion on RLC Enhancements for XR
Document for:	Discussion & Decision
1 

Conclusion
Based on the discussion above, request RAN2 to consider the following proposals:
Proposal 1: When the indicated RLC SDU for discard has a sequence number equal to POLL_SN and all other RLC SDU(s) with sequence number < POLL_SN is already acknowledged or discarded, stop and reset t-PollRetransmit, if running. (Adopt TP 1) 
Proposal 2: Upon receiving ACK for an obsolete RLC SDU, the transmitting side of an AM RLC entity does not send an indication of successful delivery of the RLC SDU to the upper layers. (Adopt TP 2) 
Proposal 3: RAN2 agree to the following approach in order to address PDCP SN gap reporting for AM DRBs during mobility (Adopt TP 3):
For AM DRBs configured by upper layers to send a PDCP SN gap report in the uplink, when a PDCP SN gap report was previously transmitted during mobility but its successful delivery has not been confirmed by lower layers, the transmitting PDCP entity triggers a PDCP SN gap report that includes the same set of previously discarded PDCP SDUs, apart from newly discarded PDCP SDUs, if any.
A separate configuration “sn-GapReportMobility” is used for R19 AM DRBs for this purpose to distinguish from the legacy configuration. 
Proposal 4: RAN2 to discuss if R18 condition for triggering PDCP SN gap report “the discarded PDCP SDU(s) have not been submitted by any RLC entity to lower layers” needs an update in context of R19 AM RLC enhancements (i.e. stopReTxDiscardedSDU).
Proposal 5: Based on P4, RAN2 to agree if in context of R19 AM RLC enhancements (i.e. stopReTxDiscardedSDU), condition for triggering PDCP SN gap report should be updated as: (Adopt TP4)
at least one byte for the discarded PDCP SDU(s) have not been submitted by any RLC entity to lower layers
4 Annex: Text Proposals
TP 1

TP 2

TP 3

TP 4

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

Conclusions
Based on the discussion above, RAN2 is requested to agree the following proposals:
Autonomous retransmission may increase RETX_COUNT, same as legacy retransmission.
RAN2 to consider one of the following options:
Option 1: Only a single autonomous retransmission will be triggered per RLC SDU. (No other enhancement)
Option 2: Another set of polling parameters is used when the remaining time is below the threshold.
A poll is always transmitted at the expiry of t-PollRetransmit for the following two cases:
In both the transmission buffer and the retransmission buffer, the transmission and retransmission of all the RLC SDUs or RLC SDU segments are stopped.
In the retransmission buffer, the transmission and retransmission of all the RLC SDUs or RLC SDU segments are stopped when no new RLC SDU or RLC SDU segment can be transmitted.
When there is no other RLC SDUs or RLC SDU segments whose transmission and retransmission are not stopped, one of the following RLC SDUs are considered for retransmission:
The RLC SDU which has been stopped for transmission or retransmission and with the highest SN among the RLC SDUs submitted to lower layer; or 
Any RLC SDU which has been stopped for transmission or retransmission and which has not been positively acknowledged.
Status report triggered by t-RxDiscard shall not trigger a retransmission.

TDoc file reading error

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

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

Conclusion
This document has proposed the following:
Proposal 1 (RRC-3, RRC-4): expiry of discardTimerForLowImportance does not trigger autonomous RLC retransmission, nor early polls.
Proposal 2 (RRC-x): the remaining time thresholds (for both autonomous retransmission and polling) are configured per PDCP entity.  
Proposal 3 (RLC-9): to minimize autonomous retransmissions, allow the network to send frequent ACKs, by introducing a possibility to configure the UE not to consider SDUs for retransmission based on received NACKs (to eradicate the problem of premature NACKs). 
Proposal 4 (RLC-9): RAN2 to discuss possible enhancements in LCP regarding high priority RLC Status PDUs. 
Proposal 5 (RLC-5): autonomous retransmission data is either not included in data volumes, or is reported separately.
Proposal 6: to allow the transmitting PDCP to reliably know how high-numbered PDCP SDUs it can proceed to transmit, the agreed RLC ACK no longer indicating successful delivery is combined with regular PDCP status reporting. 
Proposal 7 (RLC-11):	If the transmitting window is stalled when t-PollRetransmit expires, the poll is re-sent in a retransmitted SDU, even if only SDUs discarded by PDCP are buffered.
Proposal 8 (RLC-11):	When an RLC ACK or a PDCP-discard indication for an SDU is received, if the transmitting window is not stalled, t-PollRetransmit is stopped if, after the reception, all SDUs previously submitted to lower layer have been either ACKed or their transmissions have been stopped due to discard indication from PDCP.
Proposal 9 (RLC-12): RAN2 agree that unnecessary starting of t-Reordering at PDCP-mobility target RAN node because of PDCP-SN-gap information missing in the RAN is a problem to be solved in Rel.19.
Proposal 10 (RLC-12): as part of PDCP entity re-establishment, for AM DRBs configured by upper layers to send a PDCP SN gap report in the uplink, the transmitting PDCP entity shall re-transmit any previously (prior to the PDCP entity re-establishment) transmitted PDCP SN Gap report(s) for which the successful delivery has not been confirmed by lower layers.

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

Source: KDDI Corporation
Title:　 Considerations on open issues for RLC enhancements
Agenda Item:	8.7.5	RLC enhancements
Document for:	Discussion

Conclusion
The followings are proposed.
Proposal 1: RAN2 confirm that avoiding unnecessary retransmissions may have a marginal impact on RLF detection.
Proposal 2: RAN2 agrees that the specification should only support the case where both stopReTxObsoleteSDU and DL t-RxDiscard are configured, and that other cases should not be supported.
Proposal 3: RAN2 agrees that discard the polling trigger in the case where there are only SDUs buffered whose transmissions have been stopped due to discard indication from PDCP, there is no SDU to retransmit the poll with.
Proposal 4: RAN2 agrees that autonomous retransmissions should trigger an increment of the RETX_COUNT.
Proposal 5: RAN2 study the following options:
Option1: Multiple polling with enhancements at Rx based solution, shorter Status PDU Prohibit timer.
Option2: Single pooling with enhancements at Tx based solution with poll prohibit timer.
Proposal 6: RAN2 confirm that polling enhancement does not lead to early/unnecessary retransmissions.

4. 

3GPP TSG-RAN WG2 Meeting #130		R2-2503624
St. Julian’s, Malta, 19th – 23rd May 2025
Source:	vivo
Title:	Discussion on RLC remaining issues for XR
Agenda Item:	8.7.5
Document for:	Discussion and Decision

Conclusion
In this contribution, we discuss the two directions of RLC AM enhancements, and we have the following observations and proposals:
Enhancements to ensure timely RLC retransmissions
Proposal 1: (PDCP-2) The transmitting RLC entity shall trigger RLC autonomous retransmission and polling for each PDCP SDU independently based on the configured threshold, regardless of whether PDU-setDiscard is configured. 
Proposal 2: (RLC-7) Autonomous retransmission will increase RETX_COUNT by 1, the same as legacy ARQ procedures.
Proposal 3: (RLC-8) Similar to autonomous retransmission, polling shall only be triggered once per RLC SDU when its remaining time falls below a specified threshold.
Proposal 4: (RLC-9) No additional conditions are needed for the polling enhancement.
Proposal 5: The threshold for enabling autonomous retransmission is expected to be lower than the threshold for enabling polling enhancement when both are configured to the UE for the same RLC entity. 
Proposal 6: The transmitting side of an AM RLC entity shall prioritize transmission of AMD PDUs for autonomous retransmission over AMD PDUs for ARQ-based retransmission.

Enhancements to avoid unnecessary retransmissions
Observation 1: Without Tx to Rx indication, stalling of the Tx and Rx window may occur, particularly in cases where PDU set discard is enabled.
Observation 2: Without the Tx to Rx indication, unnecessary STATUS reports with NACK indication for obsolete RLC SDUs will be sent to the Tx side, leading to resource wastage.
Observation 3: HFN asynchronization between the transmitting PDCP entity and receiving PDCP entity may occur when the feature of avoiding unnecessary retransmission is configured.
Proposal 7: (Capability Open issue 2) Define separate UE capabilities for transmitter and receiver enhancements to avoid unnecessary retransmissions.
Proposal 8: (RLC-6) RAN2 should discuss the following approaches for triggering RLF when avoiding unnecessary retransmission is enabled:
Approach 1: Triggering RLF when the RLC entity receives consecutive N SDU discard indications from the PDCP entity.
Approach 2: Triggering RLF when the RLC entity receives a total of N SDU discard indications from the PDCP entity within the configured time window.
Proposal 9: (RLC-10) The network implementation should ensure:
If DL stop retransmission obsolete SDU is supported, the DL t-RxDiscard should be configured;
If UL stopReTxObsoleteSDU is configured, timer based Rx discard should be activated in the network .
Proposal 10: (RLC-11) polling will only be triggered if there is an AMD PDU that can be transmitted when t-PollRetransmit expires.
Proposal 11: (RLC-11) If P8 is agreeable, RAN2 to adopt the TP provided in Annex.
Proposal 12: Indication about obsolete SDUs from Tx side to Rx side is needed for the combined approach.
Proposal 13: The indication from the Tx side to the Rx side should include the sets of SNs or the SN range associated with the outdated RLC SDUs.
Proposal 14: The receiving RLC entity should indicate to the receiving PDCP entity the SN of obsolete RLC SDUs when t-RxDiscard (the new Rx RLC timer to determine obsolete RLC SDUs) expires.

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

Agenda Item:	8.7.5
Source: 	Canon Research Centre France
Title:	Discussion on RLC AM Enhancements 
Document for:	Discussion

Conclusion
In this contribution, we conclude the following observations and proposals:
Proposal 1: Stopping the retransmission of a RLC PDU due to remaining time condition shall not trigger an RLF.
Observation 1: Any retransmission that occurs after the PSDB shall be avoided.
Proposal 2: Remaining time of an RLC SDU is determined based on discardTimer at PDCP.
Proposal 3: Enhancements are also introduced at the RX RLC side to speed up RLC polling.
Proposal 4: A RX RLC entity can be configured to not take into account t-Reassembly timer to report a RLC SDU (or RLC SDU segment) as lost or having an unknown status.       
Proposal 5: Enhance the polling bit signalling to indicate a low remaining time condition.
Observation 2: UEs can be sorted into 5 categories:
UEs with no retransmission enhancement capacity
UEs with polling enhancement capability
UEs with autonomous retransmission capability
UEs with both polling and autonomous capabilities, but configurable with only one capability active at a time
UEs with both polling and autonomous capabilities able to be simultaneously configured with both capabilities active.

Proposal 6: RAN2 to specify UE configuration by the network according to the 5 UE categories.
Proposal 7: The network configures the thresholds triggering autonomous retransmission and enhanced polling without constraints.

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


Agenda item:	8.7.5
Source:	Apple
Title:	Views on Avoidance of Unnecessary RLC Retransmissions
WID/SID:	NR_XR_Ph3-Core
Document for:	Discussion / Decision

Conclusions
This paper presents some of our views on RLC-AM enhancements relating to unnecessary retransmission of discarded RLC SDUs. We have the following proposals:
Proposal 1: When all RLC SDUs with SNs between (and including) TX_Next_Ack and POLL_SN are already positively/negatively acknowledged or discarded by PDCP, the transmitter should stop and reset the running t-PollRetransmit.
Proposal 2: The receiver should transmit the status report triggered by the expiration of t-RxDiscard immediately, even if t-StatusProhibit is still running.

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


Agenda item:	8.7.5
Source:	Apple
Title:	Discussions on Fast RLC Retransmission
WID/SID:	NR_XR_Ph3-Core
Document for:	Discussion / Decision

Conclusions
This paper presents our views on some of the remaining issues related to Rel-19 RLC-AM enhancements to support faster retransmission. We have the following proposals:
Proposal 1: RETX_COUNT associated to a RLC SDU is also incremented when autonomous retransmission for this RLC SDU is performed.
Proposal 2: To avoid unnecessary autonomous retransmission, a triggered autonomous retransmission for a RLC SDU should be cancelled, if this RLC SDU is positively acknowledged before the autonomous retransmission is performed.
Proposal 3: To handle potential issues of excessive polling, different t-PollRetransmit timer can be applied based on the poll triggering events (e.g. if the poll is triggered by the presence of an urgent packet).

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

Conclusions
Based on the above analysis, we have the following proposals:
Proposal 1: If the discardTimer at PDCP is reused to determine the remaining time, there is no concern regarding the too early and/or unnecessary retransmission. 
Proposal 2: Polling enhancement is needed to enable the UE to poll the RLC status based on the PDU set. 

3GPP TSG RAN WG2 Meeting #130	R2-2503818
St.Julians, Malta, May 19th – 23th, 2025
Agenda item:	8.7.5
Source:	Quectel
Title:	Details on XR RLC autonomous retransmission
Document for:	Discussion

Conclusion
Based on the discussion above, the following proposals are suggested:
Proposal 1: The autonomous retransmission is configured per RB.
Proposal 2: when the remaining time is below the threshold, PDCP indicates to RLC for the PDCP PDU which is not acknowledged by RLC status report.
Proposal 3: PDCP entity shall not indicate to RLC when the remaining timer is below the threshold for the unimportant PDCP SDU.
Proposal 4: Upon receiving the indication from PDCP, RLC shall insert this indicated RLC SDU into the retransmission buffer if this RLC SDU does not exist in buffer for initial transmission and buffer for retransmission.
Proposal 5: If the positive acknowledgement is received before the uplink grant which is for autonomous retransmission, this autonomous retransmission shall be cancelled.

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

Agenda Item:	8.7.5 (NR_XR_Ph3-Core)
Source: 	LG Electronics Inc.
Title:         	Remaining open issues on RLC enhancements for XR
Document for: 	Discussion and Decision

Conclusion
Based on the above discussions, we present the following observations and proposals:
Observation 1. In 5G NR, multiple polling is already transmitted for one transmission opportunity and it is not a problem so far.
Observation 2. If The transmitting PDCP entity shall re-transmit any previously (prior to the PDCP entity re-establishment) transmitted PDCP SN Gap report(s) for which the successful delivery has not been confirmed by lower layers, unnecessary PDCP SN gap report retransmission can occur. 

Proposal 1. RETX_COUNT handling is not changed even when avoiding unnecessary retransmission is introduced, i.e., if the SDU is not considered for retransmission due to a discard indication from PDCP, RETX_COUNT for the SDU is NOT incremented by negative acknowledgement as the current RLC running CR.
Proposal 2. Add RRC configuration guidance for the stopReTxObsoleteSDU and t-RxDiscard, i.e., if stopReTxObsoleteSDU is configured, the t-RxDiscard is configured at the peer receiving entity.
Proposal 3. No enhancement for poll retransmission after t-PollRetransmit timer expires, i.e., when t-PollRetransmit timer expires, if there are only SDUs buffered whose transmissions have been stopped due to discard indication from PDCP, no SDU to retransmit the poll is selected as in the current RLC running CR.
Proposal 4. Remaining-time based RLC retransmission does not increment RETX_COUNT, but a simple text is added in the RLC specification as in the following TP. 
Proposal 5. Even if polling is included based on the remaining time, no special handling to avoid multiple polling and too early/unnecessary retransmission is introduced. 
Proposal 6. If pdu-SetDiscard is configured, remaining-time based RLC retransmission and polling are triggered for all SDUs in the PDU set.
Proposal 7. If PSI based SDU discard is activated, remaining-time based RLC retransmission is not triggered.
Proposal 8. No enhancement is needed for PDCP SN gap report handling during UE mobility.
Proposal 9. If the proposal 8 is not agreeable, the UE retransmits a PDCP SN gap report when an SDU indicated in a previous SN gap report is negatively acknowledged in a PDCP status report.

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

Agenda Item:	8.7.5
Source:	InterDigital
Title:	Discussion on RLC enhancements
WID/SID:	NR_XR_Ph3-Core - Release 19
Document for:	Discussion 
1. 

Conclusion
In this contribution, the following proposals are made for timely RLC retransmission and avoiding unnecessary RLC retransmission of RLC enhancement:

Proposal 1:	Status Report based retransmission of an RLC SDU (segment) is prioritized over autonomous retransmission of any other RLC SDU (segment).
Proposal 2:	Disregard the autonomous re-transmission trigger in the RETX_COUNT incrementing.
Proposal 3: 	When the remaining time of the RLC SDU falls below a specified threshold, polling is triggered for an RLC SDU at the earliest when the last segment of the RLC SDU is being transmitted.
Proposal 4:	Upon remaining time based RLC polling for one or multiple RLC SDUs has been met, polling is enabled in only one AMD PDU in one transmission opportunity.
Proposal 5:	Introduce a prohibit timer for remaining time based RLC polling, which is started when polling bit for remaining time based RLC polling is included in an AMD PDU.
Proposal 6:	When the Status Report is triggered by the expiry of t-RxDiscard, the ACK_SN is set to first RLC SDU which is not considered as obsolete in the receiving RLC entity.

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

Agenda item:		8.7.5
Source:		Lenovo
Title:		AM RLC enhancement
Document for:		Discussion and Decision

Conclusion
In this contribution, we discuss the RLC AM enhancement for XR traffic with small delay budget. We have the following observation and proposals:
Observation 1. When the receiver RLC entity abandons the outdated RLC SDU based on new timer, it sends the fake ACK for the outdated RLC SDU to the transmitter RLC entity, which impacts at least DL packet error rate measurement. 

Proposal 1. (RLC-11) A poll is not included in a RLC SDU due to the expiry t-PollRetransmit, trigger of an enhanced poll or window stalling when stopReTxDiscardedSDU is configured and only SDUs whose (re)transmissions have been stopped, remain in the buffer.
Proposal 2. RAN2 to discuss capturing an additional note in the spec to prevent the discrepancy in the information provided in a status report when the duration of the new timer and t-Reassembly are set to the same value.
Proposal 3. RAN2 to discuss the issue on DL packet error rate measurement due to the fake ACK of the abandoned RLC SDUs in the RLC status report.
Proposal 4. (RLC-9) If PSI based-discard is activated, the discardTimerforLowImportance is not considered for autonomous retransmission and/or enhanced polling.
Proposal 5. RAN2 to discuss whether to introduce a new RLC control PDU or enhance AMD PDU for including polling based on remaining time.
Proposal 6. (RLC-8) RAN2 to agree that only one enhanced poll is triggered per RLC SDU.
Proposal 7. RAN2 to agree that enhancedPollingThreshold is configured with a greater value than autonomousReTxThreshold, if both autonomous retransmission and enhanced polling are configured simultaneously. 
Proposal 8. (RLC-9) RAN2 to agree to cancel the triggered enhanced polling and autonomous retransmission based on the reception of status report. 
Proposal 9. (RLC-7) RAN2 to agree that autonomous retransmission is counted into RETX_COUNT.
Proposal 10. (RLC-7) RAN2 to agree that autonomous retransmission should not be triggered if the maximum number of RLC retransmission has been reached and RLF is yet to be indicated.

3GPP TSG-RAN2#129bis										            R2-2503974
St Julian, Malta, 19th – 23rd May, 2025                            
Source: 			ZTE Corporation, Sanechips
Title: 	RLC enhancements for XR
Agenda item:	8.7.5
Document for: Discussion and Decision

Conclusion
The following proposals are made: 
Observation 1: Based on the current agreement, when indicated from upper layer (e.g. PDCP) to discard a particular RLC SDU, if stopReTxObsoleteSDU is configured, the receiving PDCP entity cannot receive the discarded SDU.
Observation 2: Based on the current specification, when the PDCP SDU(s) are discarded in PDCP but the discarded PDCP SDU(s) have been submitted by RLC to lower layers, it shall not trigger the a PDCP SN gap report.
Observation 3: Based on the current specification, transmitting PDCP entity already considers the RLC entity information, it is reasonable to also consider the RLC parameter(e.g. stopReTxObsoleteSDU) when necessary.
Proposal 1: If stopReTxObsoleteSDU is configured, PDCP SN gap report can be triggered even when the transmitting AM RLC entity has submitted the discarded RLC SDU or a segment thereof to the lower layers.

Observation 4: Based on the current RLC running CR, when indicated from upper layer (e.g. PDCP) to discard a particular RLC SDU, if the RLC SDU or a segment thereof has been submitted to the lower layers, it will not been discarded, and will not be transmitted.
Observation 5: Based on the current RLC running CR, If the receiving side timer based discarding mechanism has not been activated, the transmitting window maybe stalling. It is a critical issue to be solved.
Proposal 2 (RLC 10): RAN2 discuss which of the following option is used to deal with the Transmitting window stalling:
Option 1: Transmitting window stalling is avoided based on t-RxDiscard mechanism
Option 2: Transmitting RLC entity discards the SDU when it stops (re)transmission of the SDU

Observation 6: Unnecessary (re)transmission avoidance and RLC SN gap report are both determined in transmitting RLC entity, option 2 is more easy to be specified.
Proposal 3 (RLC 10): If option 2 is agreed, an RLC SN gap report is supported, which uses RLC control PDU including the SN(s) of Discarded RLC SDU(s) and/or Discarded RLC SDU segment(s).

3GPP TSG-RAN WG2 #130                                          R2-2504032	
Malta, MT, May 19h – 23rd, 2025                             
Agenda Item:	8.7.5 RLC AM Enhancements
Source:	NEC
Title:	Remaining details on RLC AM enhancements
Document for:	Discussion, Decision
1.

Conclusion
In this contribution, we provided the following observations and proposals regarding the details of RLC AM enhancement: 

Proposal 1: Update the section “SDU discard procedures” to allow the transmitting side of an AM RLC entity to discard the indicated RLC SDU without exception, consequently outdated SDU is discarded, not pending for retransmission, and not for triggering polling etc.

Proposal 2: RAN2 discuss if the feature “skip outdated/abandoned SDU” should be supported by UE/enabled by NW jointly or independently for DL and UL directions:
If go with independent way: a enable bit is needed for UL direction, two capability bits are needed 
If go with joint way: enable bit is not needed, presence of new timer configuration will implicitly enable the feature in both DL and UL directions and one capability bit is enough

Proposal 3: RAN2 discuss following options regarding RLF and RETX_COUNT for enhanced AM RLC entity
Option1: RETX_COUNT and RLF trigger part is skipped (our preference) 
Option2: keep RETX_COUNT and RLF trigger part, auto-retransmission is not counted into RETX_COUNT
Option3: keep RETX_COUNT and RLF trigger part, auto-retransmission is counted into RETX_COUNT

Proposal 4: RAN2 confirm that excessive polling will lead to neither excessive SR nor excessive signalling overhead
proposal 5: only for these RLC SDUs or RLC SDU segments waiting for acknowledgment in the TX buffer, remaining time-based polling could be triggered 

Proposal 6: In case “there are only SDUs buffered whose transmissions have been stopped due to discard indication from PDCP, there is no SDU to retransmit the poll with”, RAN2 confirm no need to poll or retransmit the poll for any acknowledgement (no spec change)

3GPP TSG-RAN WG2 Meeting #30 	                R2-2504056
St.Julians, Malta, May 19th – 23rd, 2025
	
Agenda Item: 	8.7.5
Source:		Sony, Canon
Title:	 Timely retransmissions for RLC AM   
Document for:	Discussion & Decision

Conclusion
In this contribution, we have provided a discussion on how to reduce the time gap between the initial transmission and the re-transmissions for timely retransmissions in RLC AM, and we have the following proposals.

Proposal 1: After Rx side receives polling information, the Rx side should bypass/ignore the t-Reassembly timer for any SDU or segments of SDU if the t-Reassembly timer is running when generating status report.

Proposal 2: If proposal 1 is agreed, for any SDU or segments of SDU with bypassed t-Reassembly timer or still stuck in the lower layer retransmissions should be reported as UNKNOWN status in the status report (SR) by indicating/ redefining the corresponding reserved bit as 1 (R = 1).

3GPP TSG-RAN WG2 Meeting #130	R2-2504118
St Julien's, Malta, 19th – 23rd May, 2025
Agenda Item:	8.7.5
Source:	Huawei, HiSilicon
Title:	Discussion on RLC AM enhancements
Document for: Discussion and Decision
1	

Conclusion
This contribution makes the following proposals:
Autonomous retransmission
Proposal 1: Only RLC SDU for which no feedback was received is considered for autonomous retransmission by a Tx RLC entity.
Proposal 2: Prohibit timer should be introduced for preventing redundant retransmission, which is started when the an RLC SDU is submitted to lower layers.
Proposal 3: If pdu-SetDiscard is configured, the autonomous retransmission is triggered for the RLC SDU (segment) only when all RLC SDUs within the same PDU set have been submitted to lower layers.
Proposal 4: RAN adopts the TP in Appendix A for preventing unnecessary retransmission introduced by autonomous retransmission. 
Proposal 5: RAN2 confirms that there is no specification impact to meet the agreement “Autonomous retransmission is not triggered if the RLC SDU (segment) is already pending for retransmission”. 
Proposal 6: (RLC-7) RAN2 confirms that the RETX_COUNT is increased by autonomous retransmission and there is no additional specification modification. 
Polling enhancements
Proposal 7: (RLC-8) RAN2 supports to send a poll with a single AMD PDU even if multiple indications for polling triggering are received.
Proposal 8: (RLC-11) If there is no available RLC SDU to carry the poll when the poll is triggered based on the remaining time, RLC SDU delivered to the lower layer with highest SN or any not ACKed RLC SDU can be considered for retransmission, similar as in the legacy t-pollRetransmit expiry case as given in Appendix B. 
4. 

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

Agenda Item:	8.7.5
Source:	Ericsson, Qualcomm Incorporated, ZTE Corporation, MediaTek Inc., Xiaomi
Title:	Discussion on UE Capabilities for Unnecessary Retransmission Avoidance
Document for:	Discussion, Decision
1	

Conclusion
Based on the discussion in the previous sections, we have the following observations:
Observation 1	All the solutions for RLC AM enhancements should have per-UE capabilities with signalling.
Observation 2	From an operation standpoint, the Tx-side and Rx-side aspects are independent with the Rx-side aspect being more essential.
Observation 3	Independent aspects of a solution should not be bundled into a single UE capability.
Based on the discussion in the previous sections, we propose the following:
Proposal 1	Define an (optional) per-UE capability with signalling for the Rx-side aspect, where an outdated SDU is abandoned based on a new RLC timer and the abandoned SDUs are positively acknowledged in an RLC status report.
Proposal 2	Define an (optional) per-UE capability with signalling for the Tx-side aspect, where the Tx side stops transmissions for an outdated SDU based on an indication from the PDCP. A UE supporting this feature shall also indicate the support of Rx-side aspect.

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

Agenda Item:	8.7.5
Source: 	CMCC	
Title:  	Discussion on the left issue of RLC enhancements
WID/SID:	          NR_XR_Ph3-Core
Document for:	Discussion and Decision
 

Conclusion
In this contribution, we discussed the RLC enhancements related issues. We propose:
Proposal 1: If the RLC transmitting side receives the NACK for the single autonomous retransmission in the STATUS report, the retranmsission couter RETX_COUNT could be incremented by one. If the RETX_COUNT reaches maxRetxThreshold and RLC indicates to upper layers that max retransmission has been reached as legacy. 
Observation 1: The purpose of polling enhancement is to fasten the polling mechanism for delay-critical data. The polling should be triggered immediately without waiting the accumulated number of PDU or Bytes exceed the threshold pollPDU or pollByte when the remaining time of an RLC SDU or an RLC SDU segment falls below a threshold as agreed last meeting.
Proposal 2: The multiple pollings may be included in one transmission opportunity and no enhancement is need to avoid excessive polling. 
Proposal 3: The indication for RLC failure from RLC to upper layer shall not be triggered due to the retransmissions discarding.
Proposal 4: The control PDU, e.g. STATUS PDU and data to be retransmitted should be reported with the shortest reporting threshold in DSR. 
Proposal 5:  It is unnecessary for automatic retransmission and polling enhancement to apply to discard for PDUs with low importance.
 

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

Agenda Item:	8.7.5
Source:	HONOR
Title:	Discussion on RLC enhancements
Document for:	Discussion and Decision
1. 

Conclusions
(Open issue RLC-2) Update RX_Highest_Status
Proposal 1: (RLC-2) The RX_Highest_Status should be updated because the abandoned RLC SDUs determined by t-RxDiscard are positively acknowledged.
(Open issue RLC-9) Status report for polling enhancement
Proposal 2: (RLC-9) Enhanced poll distinguished with usual poll can be introduced.
Proposal 3: (RLC-9) An SR should be triggered without the restriction by t-StatusProhibit when receiving an enhanced poll.
4. 

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

Source:                    	DENSO CORPORATION
Title:  	Discussion on RLC enhancements
Document for:        	Discussion and decision
Agenda Item:         	8.7.5		RLC enhancements

Conclusion
In this contribution, we provided the following observations and proposals.
Observation 1:	RX_Next may be updated to a value larger than RX_Highest_Status after the expiry of t-RxDiscard. In such a scenario, it would be beneficial to set ACK_SN to the same value as updated RX_Next in the STATUS PDU in order to provide positive acknowledgements of more RLC SDUs.
Proposal 1:	(RLC-2) When the t-RxDiscard expires, the SR should be triggered after RX_Highest_Status is updated to the latest value (e.g., the same value as the updated RX_Next).
Proposal 2:	An RLC entity can stop t-Reassembly which is still running for the discarded RLC SDU when t-RxDiscard expires.
Observation 2:	When an SN gap is detected, if an RLC entity starts t-RxDiscard without starting t-Reassembly, there is a possibility that the RLC SDU may be discarded without a retransmission being requested by the SR based on t-Reassembly.
Proposal 3:	If there is still an SN gap even after t-RxDiscard has expired and RX_Next has been updated, an RLC entity can start t-Reassembly as well as t-RxDiscard.

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

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

Conclusion
This document has proposed the following:
Proposal 1 (RRC-3, RRC-4): expiry of discardTimerForLowImportance does not trigger autonomous RLC retransmission, nor early polls.
Proposal 2 (RRC-x): the remaining time thresholds (for both autonomous retransmission and polling) are configured per PDCP entity.  
Proposal 3 (RLC-9): to minimize autonomous retransmissions, allow the network to send frequent ACKs, by introducing a possibility to configure the UE not to consider SDUs for retransmission based on received NACKs (to eradicate the problem of premature NACKs). 
Proposal 4 (RLC-9): RAN2 to discuss possible enhancements in LCP regarding high priority RLC Status PDUs. 
Proposal 5 (RLC-5): autonomous retransmission data is either not included in data volumes, or is reported separately.
Proposal 6: to allow the transmitting PDCP to reliably know how high-numbered PDCP SDUs it can proceed to transmit, the agreed RLC ACK no longer indicating successful delivery is combined with regular PDCP status reporting. 
Proposal 7 (RLC-11):	If the transmitting window is stalled when t-PollRetransmit expires, the poll is re-sent in a retransmitted SDU, even if only SDUs discarded by PDCP are buffered.
Proposal 8 (RLC-11):	When an RLC ACK or a PDCP-discard indication for an SDU is received, if the transmitting window is not stalled, t-PollRetransmit is stopped if, after the reception, all SDUs previously submitted to lower layer have been either ACKed or their transmissions have been stopped due to discard indication from PDCP.
Proposal 9 (RLC-12): RAN2 agree that unnecessary starting of t-Reordering at PDCP-mobility target RAN node because of PDCP-SN-gap information missing in the RAN is a problem to be solved in Rel.19.
Proposal 10 (RLC-12): as part of PDCP entity re-establishment, for AM DRBs configured by upper layers to send a PDCP SN gap report in the uplink, the transmitting PDCP entity shall re-transmit any previously (prior to the PDCP entity re-establishment) transmitted PDCP SN Gap report(s) for which the successful delivery has not been confirmed by lower layers.