3GPP TSG-RAN WG2 Meeting #130	R2-2503743
St. Julians, Malta, May 19th – 23rd, 2025
Agenda Item:	7.0.2.22
Source: 	Fujitsu
Title:	Data loss issue on fast LTM recovery
Document for:	Discussion and Decision

Conclusion
We have the following observations and proposals.
2.1	Issue on fast LTM recovery to intra-DU cell after inter-DU LTM failure
Observation 1: In the case of fast LTM recovery to an intra-DU cell after inter-DU LTM cell switch failure, data loss issue will be caused. This is because:
1. At the failed inter-DU LTM cell switch, RLC re-establishment and PDCP data recovery for AM DRB is performed. But PDCP data recovery also fails due to LTM cell switch failure.
2. When the UE reverts back to the source PCell configuration, RLC SDUs, SDU segments and PDUs cannot be retrieved as they are already discarded.
3. If the UE performs fast LTM recovery to an intra-DU cell, PDCP data recovery is not performed even though RLC SDUs, SDU segments and PDUs are already discarded.
Proposal 1: RAN2 to confirm the data loss issue caused by fast LTM recovery to an intra-DU cell after inter-DU LTM cell switch failure needs to be solved.

2.2	Discussion for solving the issue
Observation 2: One possible solution for Rel-18 is leaving it to the NW implementation, i.e., the NW will be able to configure attemptLTM-Switch only when:
each candidate cell belongs to separate DU, i.e., ltm-NoResetID and ltm-ServingCellNoReserID are not configured, or
all candidate cells belong to the same DU.
Proposal 2: If RAN2 confirms that the solution in Observation 2 is reasonable, RAN2 to decide either add a NOTE to TS 38.331 or TS 38.300.
Proposal 3: RAN2 to discuss whether a different solution is necessary or not for Rel-19.
Proposal 4: If RAN2 decides a different solution is necessary for Rel-19, RAN2 to add this issue in Rel-19 RRC open issue list and discuss a solution in Rel-19 mobility session.

3GPP TSG-RAN WG2 Meeting #130	R2-2504123
St Julian’s, Malta, May 19 – 23, 2025
              
Agenda Item:	7.0.2.22
Source:	Ericsson
Title:	Clarification of pdcch-RACH-AffectedBandsList-r18 and related capabilities
Document for:	Discussion, Decision
1	

Conclusion
Based on the discussion in the previous sections we propose the following:
Proposal 1	pdcch-RACH-AffectedBandsList-r18 field description is updated to clarify that:
	the feature set entry where the UE includes this capability corresponds to the serving cell that may be impacted during PDCCH-ordered RACH transmission;
	the feature set entry includes a list where each entry in the list corresponds to a target band for RACH transmission;
	PDCCH ordered RACH of which the resources are not fully contained in any of UE's configured UL BWP(s) of active serving cells.
Proposal 2	pdcch-RACH-AffectedBandsList field name is updated to pdcch-RACH-TargetBandsList.
Proposal 3	pdcch-RACH-PrepTimeList-r18 and pdcch-RACH-SwitchingTimeList-r18 field descriptions are updated to clarify that:
	the feature set entry where the UE includes this capability corresponds to the serving cell that may be impacted during PDCCH-ordered RACH transmission;
	the feature set entry includes a list where each entry in the list corresponds to a target band for RACH transmission;
Proposal 4	pdcch-RACH-PrepTimeList-r18 and pdcch-RACH-SwitchingTimeList-r18 field descriptions are updated to clarify that when an entry in the list is set to notSupported, the UE does not support the feature for that target band. If the entire field is missing, the UE does not support the feature in any target band.
Proposal 5	The capability values for pdcch-RACH-PrepTimeList-r18 and pdcch-RACH-SwitchingTimeList-r18 must be set consistently.
Proposal 6	RAN2 to agree on the CR provided in Annex.

Annex (CR to TS 38.306)
3GPP TSG- Meeting #	
, ,  – 



START OF CHANGE

END OF CHANGE

TDoc file unavailable

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


Agenda item:	7.0.2.22
Source:	Nokia
Title:	Corrections to Rel-18 LTM (interruptions during RACH and LTM Recovery to the source cell)
WID/SID:	NR_Mob_enh2-Core - Release 18
Document for:	Discussion and Decision
1	

Conclusion
This document has made the following observations and proposals:
Observation 1: RAN4 confirms the source band of the band pair represents a specific source band that encounters an interruption or does not encounter it. It has nothing to do with the band wherein the PDCCH order was received.
Observation 2: Interruption is indicated for the bands which are not a part of CA band combination with the band towards which RACH is attempted. 
Observation 3: In Rel-18 fast recovery procedure, the fast recovery is triggered even if the selected cell is same as the current serving cell (i.e. source cell).
Observation 4: LTM recovery to the source cell will lead to the use of serving cell’s configuration from the candidate configuration list, not the latest source cell configuration that was used directly before the failure. 

Proposal 1: Adopt the changes to TS 38.306 related to pdcch-RACH-AffectedBandsList-r18 which have been shown in Annex A.
Proposal 2: RAN2 to confirm that LTM Fast recovery procedure is not applicable if the selected cell for recovery is same as current serving cell.

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

Agenda Item:	7.0.2.22
Source:	Huawei, HiSilicon
Title:	Handling of radio and RLC bearers in LTM with NR-DC
Document for:	Discussion and Decision
1	

Conclusion
We have the following proposals for LTM.
Proposal 1: Discuss how to handle RBs for LTM in NR-DC
a)	option 1: modify the UE behaviour i.e., at MCG LTM cell switch execution, the UE may only release MCG RLC bearers (unless the SCG is explicitly released) and radio bearers using the master key, and at SCG LTM cell switch execution, the UE may only release SCG RLC bearers and radio bearers using the secondary
b)	option 2: modify MN-SN signalling for:
-	the SN to ask the MN to always provide the full MN RB configuration to the SN for SCG LTM
-	the MN to ask the SN to always provide the full SN RB configuration to the MN for MCG LTM
and assume that the MN/SN includes/updates them in the LTM reference or candidate configurations.
Proposal 2: If option 1 is selected, agree the draft CR in annex.
Proposal 3: When a DRB is only in a subset of LTM candidate configurations, the network ensures that keystream reuse cannot happen by changing the key before triggering LTM cell switch that will establish this bearer, and by not configuring the UE to perform LTM recovery.
5	Draft CR

3GPP TSG-RAN WG2 Meeting #130	R2-25xxxxx
Saint Julians, Malta, 19 - 23 May 2025





5.3.5.18.6	LTM cell switch execution
Upon the indication by lower layers that an LTM cell switch procedure is triggered, or upon performing LTM cell switch following cell selection performed while timer T311 was running, as specified in 5.3.7.3, the UE shall:
1>	if the LTM cell switch is triggered on the MCG:
2>	release/clear all current dedicated and common radio configurations which have neither been received via SRB1 within mrdc-SecondaryCellGroup, nor via SRB3 except for the following:
-	the radio bearer configuration (configured via RadioBearerConfig)
-	the logicalChannelIdentity and logicalChannelIdentityExt of RLC bearers configured in RLC-BearerConfig and the associated RLC entities, their state variables, buffers, and timers, except for triggering the associated RLC entities to reset the variable RETX_COUNT its initial value, as specified in TS 38.322 [4];
-	the bh-LogicalChannelIdentity of BH RLC channels configured in BH-RLC-ChannelConfig and the associated RLC entities, their state variables, buffers, and timers, except for triggering the associated RLC entities to reset the variable RETX_COUNT its initial value, as specified in TS 38.322 [4];
-	the UE variables VarLTM-ServingCellNoResetID and VarLTM-ServingCellUE-MeasuredTA-ID;
-	the ltm-Config;
-	the MCG C-RNTI;
-	the AS security configurations associated with the master key;
-	the logged measurement configuration;
1>	else, if the LTM cell switch is triggered on the SCG:
2>	release/clear all current dedicated and common radio configurations which have been received either via SRB1 within mrdc-SecondaryCellGroup, or via SRB3 except for the following:
-	the radio bearer configuration (configured via RadioBearerConfig IE)
-	the logicalChannelIdentity and logicalChannelIdentityExt of RLC bearers configured in RLC-BearerConfig and the associated RLC entities, their state variables, buffers, and timers, except for triggering the associated RLC entities to reset the variable RETX_COUNT its initial value, as specified in TS 38.322 [4];
-	the bh-LogicalChannelIdentity of BH RLC channels configured in BH-RLC-ChannelConfig and the associated RLC entities, their state variables, buffers, and timers, except for triggering the associated RLC entities to reset the variable RETX_COUNT its initial value, as specified in TS 38.322 [4];
-	the UE variables VarLTM-ServingCellNoResetID and VarLTM-ServingCellUE-MeasuredTA-ID;
-	the ltm-Config;
-	the AS security configurations associated with the secondary key;
1>	for each SRB/DRB in the current UE configuration:
2>	if the LTM cell switch is triggered on the MCG and the SRB/DRB using the master key; or
2>	if the LTM cell switch is triggered on the SCG and the SRB/DRB using the secondary key:
3>	keep the associated PDCP and SDAP entities, their state variables, buffers and timers;
3>	release all fields related to the SRB/DRB configuration except for srb-Identity and drb-Identity;
NOTE 00:	For all radio bearers and RLC bearers included in the LTM candidate configuration to be applied at an LTM cell switch execution (i.e., as derived from the LTM reference configuration and the LTM candidate configuration), even if those radio bearers and RLC bearers were configured before the LTM cell switch execution, the network includes fields as specified for the initial setup of radio bearers and RLC bearers and sets the values previously stored by the UE for the fields that cannot be modified according to presence conditions or field descriptions.
1>	apply the default L1 parameter values as specified in corresponding physical layer specifications except for the parameters for which values are provided in SIB1;
1>	use the default values specified in 9.2.3 for timers T310, T311 and constants N310, N311 associated with the cell group for which the LTM cell switch procedure is triggered, where T310, N310, and N311 are for both MCG and SCG, and T311 is only for the MCG;
1>	apply the default MAC Cell Group configuration as specified in 9.2.2 for the cell group for which the LTM cell switch procedure is triggered;
1>	for each srb-Identity in the current UE configuration:
2>	apply the default SRB configuration defined in 9.2.1 for the corresponding SRB;
1>	if the LTM-Candidate IE in ltm-Config indicated by lower layers or for the selected cell in accordance with 5.3.7.3 does not contain the field ltm-NoResetID and if the UE does not have any value stored of ltm-ServingCellNoResetID within VarLTM-ServingCellNoResetID; or
1>	if the value of field ltm-NoResetID contained within the LTM-Candidate IE in ltm-Config indicated by lower layers or for the selected cell in accordance with 5.3.7.3 is not equal to the value of ltm-ServingCellNoResetID within VarLTM-ServingCellNoResetID:
2>	for each logicalChannelIdentity and logicalChannelIdentityExt that is part of the current UE configuration for the cell group for which the LTM cell switch procedure is triggered:
3>	if servedRadioBearer is set to drb-Identity:
4>	after the end of this procedure, re-establish the corresponding RLC entity as specified in TS 38.322 [4], after applying the LTM configuration in ltm-CandidateConfig within the LTM-Candidate IE in ltm-Config;
2>	for each bh-LogicalChannelIdentity that is part of the current UE configuration for the cell group for which the LTM cell switch procedure is triggered:
3>	after the end of this procedure, re-establish the corresponding RLC entity as specified in TS 38.322 [4], after applying the LTM configuration in ltm-CandidateConfig within the LTM-Candidate IE in ltm-Config;
2>	for each drb-Identity value that is part of the current UE configuration:
3>	if this DRB is an AM DRB:
4>	after the end of this procedure, trigger the PDCP entity of this DRB to perform data recovery as specified in TS 38.323 [5], after applying the LTM configuration in ltm-CandidateConfig within LTM-Candidate IE in ltm-Config;
2>	if the value of field ltm-NoResetID contained within the LTM-Candidate IE in ltm-Config indicated by lower layers or for the selected cell in accordance with 5.3.7.3 is not equal to the value of ltm-ServingCellNoResetID within VarLTM-ServingCellNoResetID:
3>	replace the value of ltm-ServingCellNoResetID in VarLTM-ServingCellNoResetID with the value of ltm-NoResetID in the LTM-Candidate in ltm-Config indicated by lower layers or for the selected cell in accordance with 5.3.7.3;
1> if the LTM-Candidate IE in ltm-Config indicated by lower layers or for the selected cell in accordance with 5.3.7.3 contains the field ltm-UE-MeasuredTA-ID:
2>	if the value of ltm-UE-MeasuredTA-ID is not equal to the value of ltm-ServingCellUE-MeasuredTA-ID within VarLTM-ServingCellUE-MeasuredTA-ID:
3>	replace the value of ltm-ServingCellUE-MeasuredTA-ID in VarLTM-ServingCellUE-MeasuredTA-ID with the value received within ltm-UE-MeasuredTA-ID;
3>	for each LTM-Candidate IE in ltm-Config:
4>	if the value of ltm-UE-MeasuredTA-ID within LTM-Candidate IE is equal to the value of ltm-ServingCellUE-MeasuredTA-ID within VarLTM-ServingCellUE-MeasuredTA-ID:
5>	inform lower layers that the UE is configured with UE-based TA measurements for the LTM-Candidate;
4>	else:
5>	inform lower layers that the UE is not configured with UE-based TA measurements for the LTM-Candidate;
NOTE 0:	The UE is not expected to perform UE-based TA measurements for an SpCell.
1>	if ltm-ConfigComplete is not included within the LTM-Candidate IE in ltm-Config indicated by lower layers or for the selected cell in accordance with 5.3.7.3:
2>	consider ltm-ReferenceConfiguration in ltm-Config, associated with the cell group for which the LTM cell switch procedure is triggered, to be the current UE configuration for the fields and configurations to be released by the actions above in this procedure;
2>	if measConfig is included within ltm-ReferenceConfiguration in ltm-Config;
3>	perform the measurement configuration procedure as specified in clause 5.5.2 by considering the measConfig within ltm-ReferenceConfiguration in ltm-Config as the received measConfig:
NOTE 1:	When the UE considers the reference configuration to be the current UE configuration, the UE should store fields and configurations that are part of the reference configuration but should not execute any actions or procedures triggered by the reception of an RRCReconfiguration message which are described in clause 5.3.5.3, unless specified otherwise in this clause.
1>	if the LTM cell switch is triggered by an indication from lower layers:
2>	apply the RRCReconfiguration message in ltm-CandidateConfig within LTM-Candidate IE in ltm-Config identified by the LTM candidate configuration identity received from lower layers according to clause 5.3.5.3;
1>	else (LTM cell switch triggered upon cell selection performed while timer T311 was running):
2>	apply the RRCReconfiguration message in ltm-CandidateConfig within LTM-Candidate IE in ltm-Config related to the LTM candidate configuration identity for the selected cell (i.e., in accordance with 5.3.7.3) according to clause 5.3.5.3;





NOTE 2:	When ltm-ConfigComplete is not included for an LTM candidate configuration, before an LTM cell switch is triggered a UE implementation may generate and store an RRCReconfiguration message by applying the received LTM candidate configuration on top of the LTM reference configuration, and the stored RRCReconfiguration message is applied when the LTM cell switch is triggered. It is up to the UE to ensure that the RRC reconfiguration applied at the time of LTM cell switch is in accordance with the latest LTM reference configuration and LTM candidate configuration.