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

Agenda item:	8.7.4.1
Source:	Qualcomm Incorporated
Title:	Discussion on LCP 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:
[MAC-01] Priority adjustment for SR
Observation 1. 	There are use cases where priority adjustment for an SR can help expedite its successful transmission.  
Observation 2. 	If a pending SR can use an SR configuration that matches the additional priority of its triggering logical channel, it has more benefits than using additional priority only for intra-UE prioritization. 
Observation 3. 	Adjusting SR configuration has the same level of spec impact as priority adjustment in intra-UE prioritization. 
Proposal 1.	[MAC-01] A pending SR can use an SR configuration that matches the additional priority of its triggering LCH, if the LCH has priority adjustable data. 
[MAC-02] Impact of congestion on priority-adjustment
Proposal 2.	[MAC-02] If an LCH with priority p is in congestion (i.e. PSI based discard has been activated), then no other LCHs are allowed to upgrade their priorities to priority p, even if they meet the priority adjustment criteria.
Proposal 3. 	[MAC-02] If an LCH is in congestion (i.e. PSI based discard has been activated), PDUs with low importance are not considered for priority adjustment.

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


Source:	CATT 
Title:	Consideration on LCP enhancement
Agenda Item:	8.7.4.1
Document for:	Discussion and Decision

Conclusion
According to the analysis in section 2, we propose:
Proposal 1: (MAC-01) The additional priority of LCH could be considered for the priority of SR in intra-UE prioritization.
Proposal 2: (MAC-01) The procedure on the determination of additional priority of LCH that triggered SR could be added in 5.4.1 UL Grant reception section in MAC spec, it is, the additionalPriority of this logical channel shall be applied if the smallest remaining value of the running PDCP discardTimers among its data available for this logical channel evaluated at the time of the first symbol of this transmission is below the configured threshold.
Proposal 3: It is suggested not to consider the retransmission priority adjustment in intra-UE prioritization, the retransmission priority will follow the priority of new transmission in LCP procedure.
Proposal 4: (MAC-02) Not to consider discardTimerForLowImportance for PSI-based SDU discard on LCP priority adjustment.
Proposal 5:  (MAC-13) Do not consider priority adjustment on PDU set level in enhanced LCP procedure.

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

Agenda Item:	8.7.4.1
Source: 	OPPO
Title:  	Discussion on LCH priority adjustment for XR
Document for:	Discussion and Decision

Conclusion
Based on the discussion above, we made the following observations and proposals:
[MAC-01] SR priority adjustment
[MAC-01] The additional LCP priority is NOT used for SR priority determination in intra-UE prioritization.
[MAC-13] Priority fallback with consideration of PDU Set integrated handling
Considering the impact of PDU set on LCH priority adjustment would cause more negative impacts on the fairness of other LCHs.
The Rel-19 DSR can already help NW to have the knowledge on the PDU set to schedule the sufficient UL resources.
[MAC-13] LCH priority adjustment in MAC layer does not consider the impact of PDU set integrated handling. No additional specification impact is needed.
Impact on SRB
Up to network implementation to avoid SRB impact due to LCH prioritization-based LCP enhancement, i.e., configure higher priority for LCH of SRBs than LCH with LCH priority-adjusted data.
4. 

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

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

Conclusion
In this contribution, it is discussed for the LCP enhancement for XR. This document includes following proposals.
Proposal 1. For priority determination of SR, always apply the legacy priority, i.e., no need to apply the additional priority.
Proposal 2. No further enhancement on LCP procedure is needed based on PSI-based discard activation.
Proposal 3. No further consider PDU set discard in LCP enhancements.
4.	

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

Conclusions
Based on the discussion above, RAN2 is requested to agree the following proposals:
RAN2 to confirm the RAN2 Working Assumption: No Bj enhancement is introduced.
Additional priority is configured only if remainingTimeThreshold for DSR is configured.

3GPP TSG RAN WG2 Meeting #130                                                            R2-2503522
St Julian's, Malta, May 19th - 23rd, 2025
Agenda item:	8.7.4.1
Source:	Ofinno
Title:	LCP Enhancements for XR
Document for:	Discussion and decision

Conclusion
Based on the analysis above, we have made the following observations and proposals:
Proposal 1	Confirm the working assumption “No Bj enhancement is introduced” as an agreement.
Due to the additional priority adjustment feature without considering the data importance, the low importance data might instead be prioritized over the high importance data for the resource allocation, allowing it to be transmitted unexpectedly early and delaying the high importance data, which results in prolonged or unresolved congestion in UL.
Proposal 2	For the evaluation of the remaining time on determining whether to apply the additional priority for a LCH, the UE should not consider low importance data in the LCH, instead should only consider the high importance data (i.e., non-low importance data) in the LCH.

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

Source:	vivo
Title:	On Bj adjustments for LCH priority-adjusted data transmission
Agenda Item:	8.7.4.1
Document for:	Discussion and Decision

Conclusion
In this contribution, we have discussed allowing LCH priority-adjusted data transmission for an LCH when its Bj is negative and impact on the transmission of the LCHs of lower priorities. Based on the discussions, there are the following observations:
Observation 1	Fixed lower Bj bound (i.e. 0) can result in that some capacity of UL grants allocated for the intention of LCH priority-adjusted data transmission is used for the data transmission of other LCHs of lower priorities.
Observation 2	By allowing LCH priority-adjusted data transmission when its Bj is negative, the LCHs with LCH priority-adjusted data temporarily borrows some radio resources from the LCHs of lower priorities, for quick transmission of LCH priority-adjusted data.
Observation 3	The borrowed radio resources by the LCHs with LCH priority adjusted-data will be returned to the LCHs of lower priorities when the congestions are resolved for the LCHs with LCH priority-adjusted data.
Based on the above discussions and the observations, we have the following proposals regarding LCH priority-adjusted data transmission when Bj is negative:
Proposal 1	Support to temporarily allow UE to transmit LCH priority-adjusted data for an LCH when its Bj is negative.
Proposal 2	Introduce a configurable negative bound for Bj per LCH for LCH priority-adjusted data transmission.
Proposal 3	If a negative Bj bound is configured for an LCH, the UE can transmit the LCH priority-adjusted data of the LCH when the corresponding Bj is above its negative Bj bound.
Proposal 4	The negative Bj bound of an LCH is configured via a negative coefficient (in range [-1.0, 0)) of maximum Bj value (i.e. PBR × BSD) of the LCH. The negative Bj bound for the LCH is “negative Bj coefficient × PBR × BSD”.
Proposal 5	If the above proposals are agreeable, RAN2 to consider the text proposals for RRC and MAC attached in Annex A and Annex B.

Annex A：Text proposal for RRC
Baseline of the TP: R2-250xxxx Running RRC CR for R19 XR_v02_Rapp.docx in [2].

*************************************************start of change********************************************************
6.3.2	Radio resource control information elements
–	LogicalChannelConfig
The IE LogicalChannelConfig is used to configure the logical channel parameters.
LogicalChannelConfig information element
-- ASN1START
-- TAG-LOGICALCHANNELCONFIG-START

LogicalChannelConfig ::=            SEQUENCE {
    ul-SpecificParameters               SEQUENCE {
        priority                            INTEGER (1..16),
        prioritisedBitRate                  ENUMERATED {kBps0, kBps8, kBps16, kBps32, kBps64, kBps128, kBps256, kBps512,
                                            kBps1024, kBps2048, kBps4096, kBps8192, kBps16384, kBps32768, kBps65536, infinity},
        bucketSizeDuration                  ENUMERATED {ms5, ms10, ms20, ms50, ms100, ms150, ms300, ms500, ms1000,
                                                            spare7, spare6, spare5, spare4, spare3,spare2, spare1},
        allowedServingCells                 SEQUENCE (SIZE (1..maxNrofServingCells-1)) OF ServCellIndex
                                                                                                            OPTIONAL,   -- Cond PDCP-CADuplication
        allowedSCS-List                     SEQUENCE (SIZE (1..maxSCSs)) OF SubcarrierSpacing                   OPTIONAL,   -- Need R
        maxPUSCH-Duration                   ENUMERATED {ms0p02, ms0p04, ms0p0625, ms0p125, ms0p25, ms0p5, ms0p01-v1700, spare1}
                                                                                                                OPTIONAL,   -- Need R
        configuredGrantType1Allowed         ENUMERATED {true}                                                   OPTIONAL,   -- Need R
        logicalChannelGroup                 INTEGER (0..maxLCG-ID)                                              OPTIONAL,   -- Need R
        schedulingRequestID                 SchedulingRequestId                                                 OPTIONAL,   -- Need R
        logicalChannelSR-Mask               BOOLEAN,
        logicalChannelSR-DelayTimerApplied  BOOLEAN,
        ...,
        bitRateQueryProhibitTimer       ENUMERATED {s0, s0dot4, s0dot8, s1dot6, s3, s6, s12, s30}               OPTIONAL,    -- Need R
        [[
        allowedCG-List-r16                  SEQUENCE (SIZE (0.. maxNrofConfiguredGrantConfigMAC-1-r16)) OF ConfiguredGrantConfigIndexMAC-r16
                                                                                                                OPTIONAL,   -- Need S
        allowedPHY-PriorityIndex-r16        ENUMERATED {p0, p1}                                                 OPTIONAL    -- Need S
        ]],
        [[
        logicalChannelGroupIAB-Ext-r17      INTEGER (0..maxLCG-ID-IAB-r17)                                      OPTIONAL,   -- Need R
        allowedHARQ-mode-r17                ENUMERATED {harqModeA, harqModeB}                                   OPTIONAL    -- Need R
        ]]




					



    }                                                                                                       OPTIONAL,   -- Cond UL
    ...,
    [[
    channelAccessPriority-r16           INTEGER (1..4)                                                      OPTIONAL,   -- Need R
    bitRateMultiplier-r16               ENUMERATED {x40, x70, x100, x200}                                   OPTIONAL    -- Need R
    ]]
}

-- TAG-LOGICALCHANNELCONFIG-STOP
-- ASN1STOP



*************************************************end of change********************************************************

Annex B：TP for MAC 
Baseline of the TP: draft R2-250xxxx R19 XR MAC running CR_final_r1.docx in [3].
*************************************************start of change********************************************************
5.4.3.1.3	Allocation of resources
Before the successful completion of the Random Access procedure initiated for DAPS handover, the target MAC entity shall not select the logical channel(s) corresponding to non-DAPS DRB(s) for the uplink grant received in a Random Access Response or the uplink grant for the transmission of the MSGA payload. The source MAC entity shall select only the logical channel(s) corresponding to DAPS DRB(s) during DAPS handover.
The MAC entity shall, when a new transmission is performed:
1>	allocate resources to the logical channels as follows:


2>	logical channels selected in clause 5.4.3.1.2 for the UL grant with Bj > 0 are allocated resources in a decreasing priority order. If the PBR of a logical channel is set to infinity, the MAC entity shall allocate resources for all the data that is available for transmission on the logical channel before meeting the PBR of the lower priority logical channel(s);

2>	decrement Bj by the total size of MAC SDUs served to logical channel j above;
2>	if any resources remain



all the logical channels selected in clause 5.4.3.1.2 are served in a strict decreasing priority order (regardless of the value of Bj) until either the data for that logical channel or the UL grant is exhausted, whichever comes first. ogical channels with equal priority should be served equally.
NOTE 1:	The value of Bj can be negative.
If the MAC entity is requested to simultaneously transmit multiple MAC PDUs, or if the MAC entity receives the multiple UL grants within one or more coinciding PDCCH occasions (i.e. on different Serving Cells), it is up to UE implementation in which order the grants are processed.
The UE shall also follow the rules below during the scheduling procedures above:
-	the UE should not segment an RLC SDU (or partially transmitted SDU or retransmitted RLC PDU) if the whole SDU (or partially transmitted SDU or retransmitted RLC PDU) fits into the remaining resources of the associated MAC entity;
-	if the UE segments an RLC SDU from the logical channel, it shall maximize the size of the segment to fill the grant of the associated MAC entity as much as possible;
-	the UE should maximise the transmission of data;
-	if the MAC entity is given a UL grant size that is equal to or larger than 8 bytes (when eLCID is not used) or 10 bytes (when eLCID is used) while having data available and allowed (according to clause 5.4.3.1) for transmission, the MAC entity shall not transmit only padding BSR and/or padding.
The MAC entity shall:
1>	if the MAC entity is configured with enhancedSkipUplinkTxDynamic with value true and the grant indicated to the HARQ entity was addressed to a C-RNTI, or if the MAC entity is configured with enhancedSkipUplinkTxConfigured with value true and the grant indicated to the HARQ entity is a configured uplink grant:
2>	if there is no UCI to be multiplexed on this PUSCH transmission as specified in TS 38.213 [6]; and
2>	if there is no aperiodic CSI requested for this PUSCH transmission as specified in TS 38.212 [9]; and
2>	if the MAC PDU includes zero MAC SDUs; and
2>	if the MAC PDU includes only the periodic BSR and there is no data available for any LCG, or the MAC PDU includes only the padding BSR:
3>	not generate a MAC PDU for the HARQ entity.
1>	else if the MAC entity is configured with skipUplinkTxDynamic with value true and the grant indicated to the HARQ entity was addressed to a C-RNTI, or the grant indicated to the HARQ entity is a configured uplink grant:
2>	if there is no aperiodic CSI requested for this PUSCH transmission as specified in TS 38.212 [9]; and
2>	if the MAC PDU includes zero MAC SDUs; and
2>	if the MAC PDU includes only the periodic BSR and there is no data available for any LCG, or the MAC PDU includes only the padding BSR:
3>	not generate a MAC PDU for the HARQ entity.
Logical channels shall be prioritised in accordance with the following order (highest priority listed first):
-	MAC CE for C-RNTI, or data from UL-CCCH;
-	MAC CE for (Enhanced) BFR, or MAC CE for Configured Grant Confirmation, or MAC CE for Multiple Entry Configured Grant Confirmation;
-	MAC CE for Sidelink Configured Grant Confirmation;
-	MAC CE for LBT failure;
-	MAC CE for SL LBT failure according to clause 5.31.2;
-	MAC CE for Timing Advance Report;
-	MAC CE for Delay Status Report;
-	MAC CE for SL-BSR prioritized according to clause 5.22.1.6;
-	MAC CE for (Extended) BSR, with exception of BSR included for padding;
-	MAC CE for (Enhanced) Single Entry PHR, or MAC CE for (Enhanced) Multiple Entry PHR or MAC CE for Single Entry PHR with assumed PUSCH, or MAC CE for Multiple Entry PHR with assumed PUSCH, or MAC CE for Enhanced Single Entry PHR for multiple TRP or MAC CE for Enhanced Multiple Entry PHR for multiple TRP, or MAC CE for Enhanced Single Entry PHR for multiple TRP STx2P or MAC CE for Enhanced Multiple Entry PHR for multiple TRP STx2P;
-	MAC CE for Positioning Measurement Gap Activation/Deactivation Request;
-	MAC CE for the number of Desired Guard Symbols;
-	MAC CE for Case-6 Timing Request;
-	MAC CE for (Extended) Pre-emptive BSR;
-	MAC CE for SL-BSR, with exception of SL-BSR prioritized according to clause 5.22.1.6 and SL-BSR included for padding;
-	MAC CE for IAB-MT Recommended Beam Indication, or MAC CE for Desired IAB-MT PSD range, or MAC CE for Desired DL Tx Power Adjustment;
-	data from any Logical Channel, except data from UL-CCCH;
-	MAC CE for Recommended bit rate query;
-	MAC CE for BSR included for padding;
-	MAC CE for SL-BSR included for padding.
NOTE 2:	Prioritization among MAC CEs of same priority is up to UE implementation.
The MAC entity shall prioritize any MAC CE listed in a higher order than 'data from any Logical Channel, except data from UL-CCCH' over NR sidelink transmission.

*************************************************end of change********************************************************

TDoc file reading error

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

Agenda item:	8.7.4.1
Source: 	Huawei, HiSilicon, ZTE Corporation, Samsung, Sharp, NEC, CATT
Title: 	TP for using additional LCP priority for SR priority determination
Document for:	Discussion and Decision
1. 

Conclusion
RAN2 is requested to discuss the observations and include following TP to Section 5.4.1 of the MAC specification:
Observation 1:  The additional priority of an LCH should be considered for the SR (triggered by DSR) priority determination when the DSR is not included into the MAC-PDU related to the overlapping UL grant.
Observation 2:	For intra-UE prioritization procedure, the actual SR transmission time should be considered to determine whether to apply the additional or default priority of the LCH that triggered the SR.
Proposed TP: [MAC-01]
When the MAC entity is configured with lch-basedPrioritization, the MAC entity considers the value of additionalPriority, if configured, as the priority for the logical channel triggering an SR, if the running PDCP discardTimer of an PDCP SDU buffered for the LCH has the remaining value below additionalPriorityThreshold at the time of the SR transmission. 
4. 

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


Agenda item:	8.7.4.1
Source:	Apple
Title:	Discussions on Delay-based LCP Enhancements
WID/SID:	NR_XR_Ph3-Core
Document for:	Discussion / Decision

Conclusions
This paper discusses our views on some of the remaining issues relating to LCH priority adjustment. We have the following observations and proposals:
Observation 1: When PDU Set Discarding is configured, if a LCH fallback its priority without considering the PDU Set dependency of packets that are still in the buffer, the effort of LCH priority adjustment may be in vain from Application point of view, as the already transmitted packets of a PDU Set may become useless even if they are successfully delivered on time.
Observation 2: Both LCP and DSR enhancement should have a unified considerations about PDU Set Discarding, as they belong to the same WI objective related to UL scheduling for XR, and PDU Set discarding is configured based on the QoS requirement of PSIHI.
Observation 3: The LCH priority fallback procedure should follow the same principle of DSR cancellation, and DSR cancellation takes PDU Set discarding into account.

Proposal 1: If PDU Set Discarding is configured, when there is still other PDCP SDUs in the buffer that belong to the same PDU Set that is already considered urgent, the LCH does not fall back to the default priority even if the remaining value of PDCP discardTimer of these PDCP SDUs are larger than priorityAdjustmentThreshold.

Proposal 2: For the potential impacts of PSI-based discarding, RAN2 can discuss the following options:
Option 1: When PSI-based discarding is activated a DRB, priority adjustment for the corresponding LCH is disabled.
Option 2: When PSI-based discarding is activated a DRB, priority adjustment is applied only if there is at least one more important packet in the buffer has a remaining time smaller than the threshold.

Proposal 3: RAN2 does not enhance Bj handling in Rel-19 if we cannot identify a simple and comprehensive solution that can deal with both negative Bj and positive but small Bj.
Proposal 4: If RAN2 decides to have Bj enhancement, the following solution can be considered: For a LCH with upgraded priority, the Bj of which is set based on Bj = max(Bj, Bj_Temp) before the resource allocation procedure, where Bj_Temp is pre-configured by the network.

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

Conclusions
Based on the above analysis, we have the following proposals:
Proposal 1: Additional priority is used for SR priority determination with the limited specification impact. 
Proposal 2: In case of UL congestion, LCP adjustments should take into account both the remaining time and the data importance. 
Proposal 3: Only one timer is used for the PDU set to reduce the complexity. 

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

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

Summary
This contribution provides our analysis on the enhancements of LCP procedure, and has the following proposals:
Proposal 1: If an additional priority is applied for an LCH, only priority-adjusted data of the LCH can be transmitted when Bj < 0. 
Proposal 2: Maximize the transmission of a PDU Set during delay-awareness LCP procedure when the additional priority is applied for an LCH.
Proposal 3: RAN2 to discuss whether an LCH with priority-adjusted data should be served before one without such data during LCP when both have equal priority. 
Proposal 4: Different configured UL grant configurations can apply different strategies of whether to apply delay-awareness LCP mechanism.
Proposal 5: It can be left to the network’s implementation to configure the priorities of LCHs with delay-critical data and LCHs for SRBs other than SRB 0.
Proposal 6: [MAC-01] Additional priority is applied to SR priority determination during intra-UE prioritization.

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

Agenda item:	8.7.4.1
Source:		Lenovo
Title:			Open issues on Intra-UE prioritization/LCP enhancements
Document for:	Discussion and Decision

Conclusion
In this contribution, we discuss enhancements to the uplink scheduling. We have the following proposals:
Proposal 1: RAN2 to further discuss the detailed UE behaviour/specification wording for considering an additional priority configured for a LCH when determining the priority of a SR in case of a collision.
Proposal 2: RAN2 to discuss whether the LCP enhancements are only applicable for high importance packets in case of UL congestion, e.g., PSI-based discard is activated.
Proposal 3: RAN2 to discuss, whether LCH priority adjustment procedure considers PDU Sets/PDU Set remaining time if pdu-SetDiscard is configured during the complete LCP procedure, e.g. not only for priority fallback behaviour before 2nd round of LCP.

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

Agenda Item:	8.7.4.1 
Source:	ITRI
Title:	Discussion on enhanced LCP for XR 
Document for:	Discussion and Decision 
1 

Conclusion
Based on the discussion in the previous section we propose the following: 
Proposal 1: Not to consider the Bj relaxation for LCH with priority-adjusted data in Rel-19 LCP. 
Proposal 2: There is no impact on SR priority determination during intra-UE prioritization due to adjusted priority. However, a compromise (e.g., a note clarification) is accepted based on the majority’s decision. 
4 

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

Conclusion and proposals
The following proposals are made: 
Proposal 1 (MAC-01): RAN2 confirms that “LCH priority-adjusted data” is all data in a logical channel having data with remaining time less than or equal to the remaining time threshold configured for LCP.
Proposal 2 (MAC-01): For “LCH priority-adjusted data”, the additional LCP priority is also used for SR priority determination. Add a note for this in the MAC specification.
Proposal 3: Confirm the working assumption that No Bj enhancement is introduced.

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

Agenda item:	8.7.4.1
Source: 	Huawei, HiSilicon
Title: 	Remaining open issues of LCP enhancements
Document for:	Discussion and Decision
1. 

Conclusion
Proposal 1:	(MAC-02) Additional priority should be applied on the LCH if the smallest remaining time is less than the priorityAdjustmentThreshold for the LCH as agreed. This also includes the case where the LCH priority-adjusted data with the smallest remaining time of discardTimer is queued behind other data (e.g., non-delay-critical data) and the UL grant is not large enough to include the LCH priority-adjusted data for transmission, no enhancement for this case is needed.
4. 

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

Agenda item:	8.7.4.1
Title:	Further consideration on LCP enhancement for XR
Source:	CMCC 
Document for:	Discussion

Conclusion
Based on the abovementioned analysis and observations, the following is proposed.
Bj enhancement:
Observation 1: The reason for a negative Bj mainly stems from the increment of Bj is too small, usually caused by the time to the last Bj increment is too short or the last LCP allocates too much resource for LCH j.
Observation 2: Fairness issue caused by ignoring negative Bj can be solved by compensating the additional Bj increment later, e.g., using less time T for Bj increment, or a long-term token bucket after UE ignoring negative Bj.
Proposal 1: To avoid the negative Bj impact on delay-critical data when PBR is sufficient, RAN2 may consider to enlarge the time T for Bj increment and compensate the irregular Bj increment later.
Intra-UE prioritization:
Observation 3: Using SR configuration with short periodicity is helpful to send DSR in time and avoid potential data discarding.
Observation 4: Looking up for a proper SR configuration among LCHs is complicated and there is no guarantee that a proper SR configuration exists, e.g., the LCH is already configured with the SR configuration that has the shortest periodicity or no LCH has SR resource configuration with shorter periodicity.
Proposal 2: NW can configure an additional SR resource configuration with shorter periodicity per LCH for pending DSR.
Proposal 3: The additional LCH priority is applied in UL grant prioritization if the LCH has delay-critical data, regardless of whether the priority falls back in the 2nd round of LCP or it is an initial transmission or retransmission.
PSI and PSIHI impact on LCP:
Proposal 4: In case PSI-based discard is activated, the additional priority is not applied to low importance PDU set in both rounds of LCP for that LCH.
Observation 5: Regarding the definition of delay-critical data, PDU set with at least one PDCP SDU whose remaining time is less than the same threshold for PDCP SDU is also considered as delay-critical data.
Proposal 5a: In the 1st round of LCP, PSIHI has no specification impact on LCH priority determination as PDU set and PDCP SDU use the same remaining time threshold.
Proposal 5b: In the 2nd round of LCP, if pdu-SetDiscard is configured, the priority of LCH should fall back to the original priority if there is neither PDCP SDU nor PDCP SDU within a PDU set whose remaining is less than the threshold.

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

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

Conclusion
Remaining issues on LCP are discussed in this contribution with the following proposals proposed:
Proposal 1: no enhancement needed for Bj handling for LCH priority adjustment.
Proposal 2: LCH priority adjustment should not impact SR priority determination.
Proposal 3: confirm that remaining time of low priority data is not considered for LCP priority adjustment since it does not use discardTimer.

3GPP TSG-RAN WG2 Meeting #130	R2-2504537
St.Julians, Malta,  May 19th – 23rd , 2025
Source:				ETRI
Title:					Discussion on LCP enhancements for XR
Agenda Item:		8.7.4.1	LCP enhancements 
Document for:		Discussion and Decision
1. 

Conclusion
In the discussion we made the following observations:
Observation 1) In the 1st round of resource allocation in the LCP procedure, the legacy Bj procedure restricts the priority to delay-critical data.
Observation 2) When the proportion of delay-critical data is low, fairness is generally provided when observed over a long period.
Observation 3) Using negative Bj when allocating resources to LCH priority adjusted data  results in prioritizing the transmission of this delay-critical data, for which LCH priority has been temporarily boosted.
Observation 4) Fairness issues arise when the proportion of delay-critical data is high; therefore, it is necessary to aim for configurations that maintain a low proportion of delay-critical data within LCHs.

We propose the followings:
Proposal 1) A negative Bj value is allowed in the 1st round resource allocation for LCH priority adjusted data within the LCP procedure.
Proposal 2) The UE may be configured to allow a specific LCH to utilize a negative Bj value for its delay-critical data.
Proposal 3) LCH adjusted priority is applied for SR priority determination.

4. 

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


Agenda Item:	8.7.4.1
Source:	Ericsson, InterDigital, LG Electronics, Fujitsu
Title:	Discussion on Bj enhancement
Document for:	Discussion, Decision
1	

Conclusions of evaluations
Legacy LCP mechanism has a problem to support multiple flows and keep XR traffic (AR video) delays low when load from other traffic increases, without starving the other traffic (e.g. eMBB) and thus impose huge delays on that traffic.
Delay enhanced LCP without Bj enhancement can only keep the AR delays low if the AR PBR is set to a high value together with a delay threshold or if the delay threshold is configured on the less time critical traffic.
Bj enhanced LCP can keep the AR delays low and stable but also provide the high reduction in Object delays with multiple possible PBR configurations. 
Bj enhancement shall be incorporated in the Rel19 LCP enhancements to achieve the most flexible and high performing LCP solution.
2.2 Bj enhancement in specification  
The simplest solution to implement the Bj enhancement is to add a new condition in the resource allocation procedure so that logical channels which have applied additionalPriority are no longer limited by the Bj > 0 condition. A TP for this is provided in Appendix 1.
Implement the TP provided in Appendix 1.
3	Conclusion
In the previous sections we made the following observations: 
Observation 1	All configurations of legacy LCP that provide low and stable XR video delays significantly increase the Object delays.
Observation 2	LCP enhancements that only adjust the priority requires to set the delay threshold on the less time critical traffic and limit the possible configurations.
Observation 3	Bj enhancements enable multiple configurations to keep AR delays low and stable while also provide large reduction in Object delays.
Observation 4	Bj enhancements allow a single LCP configuration to perform well over varying user bit rates.
Based on the discussion in the previous sections we propose the following: 
Proposal 1	Bj enhancement shall be incorporated in the Rel19 LCP enhancements to achieve the most flexible and high performing LCP solution.
Proposal 2	Implement the TP provided in Appendix 1.

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


Agenda Item:	8.7.4.1
Source:	Ericsson
Title:	Discussion on LCP enhancement
Document for:	Discussion, Decision
1	

Conclusion
Based on the discussion in the previous sections we propose the following: 
Proposal 1	Enhanced LCP feature should have similar handling of PDU Sets as the DSR feature with respect to PDU Set integrated handling.
Proposal 2	Intra-UE prioritization shall not use the additional LCP priority for SR priority determination.
Proposal 3	If priority adjustment is agreed to impact the SR priority determination, then applying legacy or new behaviour should be controlled by network configuration.

3GPP TSG-RAN WG2 Meeting #130	R2-2504619
St Julian’s, Malta, 19 – 23 May 2025	
Agenda item:	8.7.4.1
Source:	Samsung
Title:	Finalising LCP design for XR Ph3
Document for:	Discussion & Decision

Conclusion
RAN2 is kindly asked to discuss and agree the following proposals:
Proposal 1a. For the case of intra-UE overlapping resources prioritization linked to Scheduling Request triggered by logical channels that have LCH priority-adjusted data to be transmitted, RAN2 to specify (using the TP in R2-2503690 as baseline) whether the priority of the LCH which triggered the SR used for the intra-UE prioritization is that from the point in time when the SR was triggered, or the current priority at the time of transmission.
Proposal 1b. For the case of intra-UE overlapping resources prioritization linked to Scheduling Request, RAN2 to discuss whether to capture the cause of SR triggering in the specifications i.e. make it clear that SR in question was triggered according to the BSR/DSR procedures (as the additional priority would only be relevant in this case).
Proposal 2. RAN2 to confirm the Working Assumption of not allowing an LCH with an upgraded priority to be transmitted in the 1st round of LCP when Bj is negative i.e. stick to legacy behaviour.
Proposal 3. RAN2 to consider prioritizing LCH with LCH priority-adjusted data over comparatively less important/urgent MAC CEs.
Proposal 4. Assuming RAN2 agrees to prioritizing LCH with LCH priority-adjusted data over BSR MAC CEs where beneficial, when determining the priority of the BSR MAC CE relative to data in order to compare it with the priority of the data, the priority should be that of the logical channel that resulted in the most recent BSR trigger prior to MAC PDU assembly, and whose data cannot all be included in the MAC PDU.
Proposal 5. Handling of any concerns to do with XR traffic potentially delaying SRBs traffic is left to network implementation.