3GPP TSG-RAN WG2 Meeting #130	R2-2503381
St.Julians, Malta, May. 19th – 23rd, 2025
												
Agenda item:		8.6.2
Source:		Lenovo
Title:		Some issues for Inter-CU LTM
Document for:		Discussion and Decision

Conclusion
In this contribution, the following proposals are given based on the discussion:
Fast Recovery
Observation 1: Intra-gNB LTM based recovery is not supported for L3 HO/CHO failure in legacy Rel-18. Namely, after L3 HO/CHO failure, if the selected cell is configured with Rel-18 LTM, UE transmits re-establishment request directly.
Proposal 1: After inter-CU LTM failure, RAN2 to discuss whether fast failure recovery can be performed if the selected candidate cell has the same Rel-19 ID as source.
Proposal 2: After Inter-CU LTM failure occurs, if the selected candidate cell is configured with CHO candidate configuration, UE performs CHO.
UE based TA measurement
Proposal 3: Source gNB is responsible for UE measured TA ID assignment for each candidate cell. 
Proposal 4: The candidate gNB should provide the information whether UE based TA can be used for the cell switch between the candidate cells belonging the candidate gNB.
Coexistence of Inter-CU MCG LTM and Subsequent CPAC
Proposal 5: Subsequent CPAC can be configured while Inter-CU MCG LTM or SCG LTM is configured.
Proposal 6: The configuration for subsequent CPAC should be released by network via explicit indication after Inter-CU MCG LTM as legacy.
Coexistence of Inter-CU SCG LTM and MCG failure recovery
Proposal 7: Inter-CU SCG LTM switch is allowed to be triggered while MCG failure recovery procedure is ongoing as legacy Intra-CU SCG LTM.
Proposal 8: Once source SN activates Inter-CU LTM switching while MCG failure recovery procedure is ongoing, source SN indicates it to MN. Then, MN transmits the response of MCGFailureInforamtion to target SN.
Security in Inter-CU mobility
Proposal 9: Regarding inter-CU security change, MAC signalling should enable UE to distinguish if key derivation is to applied (same as previous NCC value means horizontal derivation and a different NCC means vertical derivation), or not (in which case the NCC is not included in the MAC CE).
Proposal 10: If a NAS AKA is run (and NH, NCC pair becomes available), then a fresh RRC signalling including keySetChangeIndicator is sent to the UE. No new Specification impact.
Proposal 11: When the security Algorithm change is required, it is performed using layer 3 handover. No new specification impact.

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

Source:	CATT
Title:	Discussion on inter-CU LTM
Agenda Item:    8.6.2
Document for:  Discussion and Decision

Conclusion
Based on the previous analysis in Section 2, our observations and proposals are summarized as follows:
Observation 1: UE behaviour on reverting back to the source PCell configuration upon fast recovery failure has been covered by the legacy procedure text.
Observation 2: UE needs to revert back to the source PCell configuration upon T304 expires caused by LTM cell switch execution procedure which requires a security key refresh. The related UE behaviour is missing in the RRC running CR.

On the inclusion of appliedLTM-CandidateID
Proposal 1a: (RRC-2) UE needs to include appliedLTM-CandidateID in RRCReconfigurationComplete upon all cases of LTM execution, i.e.,
Upon R18 intra-CU MCG/SCG LTM
Upon inter-CU MCG LTM
Upon inter-CU SCG LTM
Upon intra-CU CLTM
Proposal 1b: (RRC-2) The appliedLTM-CandidateID is sent to the node which generated the candidate configuration to UE, i.e.,
included in RRCReconfigurationComplete to MN upon inter-CU MCG LTM
included in RRCReconfigurationComplete to MN upon inter-CU SCG LTM.
included in RRCReconfigurationComplete to MN upon intra-CU MCG LTM 
included in RRCReconfigurationComplete to SN upon intra-CU SCG LTM
Proposal 1c: TP in Annex 1 is adopted if p1a and p1b are agreed.

Further details on fast recovery
Proposal 2: (RRC-8) Support the LTM fast recovery to a candidate cell that different R19 ID from the target cell after inter-CU LTM failure.
Proposal 3a: (RRC-8) If the selected cell has same R19 ID as the source cell after the inter-CU MCG LTM failure, UE perform LTM fast recovery to the selected cell with the key update using the received NCC included in the LTM cell switch command and the selected cell’s PCI and frequency.
Proposal 3b: If the selected cell has same R19 ID as the target cell after the inter-CU MCG LTM failure, UE performs LTM fast recovery to the selected cell with the security key update using the NCC in the LTM cell switch command and the selected cell’s PCI and frequency.
Proposal 4a: (RRC-6) Rely on legacy procedure text for the UE behaviour on reverting back to the source PCell configuration upon fast recovery failure, i.e., the related change in the running CR should be removed.
Proposal 4b: (RRC-6) Upon T304 expires caused by LTM cell switch execution procedure which requires a security key refresh, UE needs to revert back to the source PCell configuration but keeps NCC received in the LTM command.
Proposal 4c: (RRC-6) TP in Annex 2 is adopted if P4b is agreed.

On the interaction for the configuration of inter-CU SCG LTM candidate
Proposal 5a: The legacy field maxNumberLTM-CandidatesSCG in the inter-node RRC message can be used to indicate the maximum number of the candidate configuration for SCG LTM no matter intra-CU or inter-CU. Additional indication for inter-CU SCG LTM is not needed.
Proposal 5b: Send LS to RAN3 if P5a is agreed. 

Clarification on the SK-counter list
Proposal 6: Confirm that the SK counter list is only applied to inter-CU SCG LTM.

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

Agenda Item:	8.6.2
Source:	MediaTek Inc.
Title:	Fast recovery for inter-CU LTM
Document for:	Discussion and Decision
1	

Conclusion
Based on the discussion in the previous sections we propose the following:
Proposal 1	Rel-19 inter-CU LTM related UE variable VarLTM-ServingCellNoSecurityChange is reverted back to its value in the source PCell when T304 expires.
Proposal 2	Similarly as in Rel-18, also in Rel-19 the UE always reverts back to the previous PCell configuration when T304 expires.

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


Agenda Item:	8.6.2
Source: 	OPPO
Title: Discussion on open issues for inter-CU LTM
Document for:	Discussion and Decision

Conclusion
Based on the discussion in section2, we have following observation proposals:
Proposal 1	Upon T304 expiry, if attemptLTM-Switch is configured and the LTM procedure requires a security key refresh, the UE revert back to the UE configuration used in the source PCell.
Proposal 2	A list of sk-counter is not needed in case of inter-CU MCG LTM with SCG configuration.
Proposal 3	To avoid SkgNB reuse issue, the NW reconfigures the sk-counter for subsequent intra-CU MCG LTM after the execution of MCG LTM with SCG configuration.
Proposal 4	In case of inter-CU LTM failure, LTM candidate cell with different Rel-19 ID from the target cell can be selected for fast failure recovery. The Rel-19 ID of the selected candidate cell can be same or different with the source cell.
Proposal 5	If the selected candidate cell has the same Rel-19 ID as source cell, the security key of the source cell is reused.
Proposal 6	If the selected candidate cell has different Rel-19 ID from source cell and target cell, the NCC value received in LTM cell switch command MAC CE is used for security key update.
Proposal 7	NCC value field is optional present in Enhanced LTM Cell Switch Command MAC CE.
Proposal 8	The Enhanced LTM Cell Switch Command MAC CE is used to trigger R19 LTM, either with or without security key update.
Proposal 9	In Enhanced LTM Cell Switch Command MAC CE, a separate Oct is introduced to include NCC value.

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

Source: 	Xiaomi
Title:  	Remaining issues of inter-CU LTM
Agenda Item:	8.6.2
Document for:	Discussion and Decision

Conclusions
According to the analysis given above, we have the following observations and proposals:
2.1	LTM based failure recovery
o	(RRC-8) FFS if fast failure recovery with different Rel-19 IDs is allowed.
Observation 1: (RRC-8) If there is no AS Key update in the recovery procedure, the Case 1(the selected candidate cell has the same Rel-19 ID as source for recovery after inter-CU LTM failure) is not feasible. Because the UE cannot fully revert back to source configuration after inter-CU LTM execution.
Observation 2: (RRC-8) To support the key update during recovery for Case 1, the source gNB needs to generate the new KgNB*(s) for LTM candidate cells belonging to the source before the LTM execution. And these new KgNB*(s) can only be used for recovery procedure.
Observation 3: (RRC-8) After inter-CU LTM failure, other candidate gNBs (except for the source gNB) also have the new KgNB*(s) for the UE. The new KgNB*(s) of other candidate gNBs can be used for failure recovery. 
Proposal 1a: (RRC-8) For inter-CU LTM failure (the R19 set ID is different between the target cell and source cell), if the selected candidate cell has the different Rel-19 ID of source, the UE performs fast failure recovery. 
Proposal 1b: (RRC-8) For inter-CU LTM failure (the R19 set ID is different between the target cell and source cell), RAN2 can discuss whether to support the LTM based fast failure recovery with AS Key update, if the selected candidate cell has the same Rel-19 ID as source cell.
Proposal 1c: (RRC-8) If RAN2 supports the case in P1b, RAN2 needs to send an LS to SA3 and RAN3 to ask whether the source gNB can generate the new KgNB*(s) for LTM candidate cells belonging to the source only for LTM based failure recovery.
o	 (RRC-6) Editor’s Note: FFS on which point in time, for fast recovery, the UE reverts back to the previous PCell configuration.
Proposal 2a: (RRC-6) “which point in time, for fast recovery, the UE reverts back to the previous PCell configuration” depends on whether the KgNB*(s) computed by the source gNB is per candidate cell or per candidate gNB:
•	(If it is per candidate cell): Upon inter-CU LTM failure, the UE reverts back to the previous source PCell configuration.
•	(If it is per candidate gNB): Upon inter-CU LTM failure, the UE keeps the target configuration. Then if the recovery attempt fails, the UE reverts back to the previous source PCell configuration.
Proposal 2b: (RRC-6) RAN2 can send an LS to RAN3 to ask whether the KgNB*(s) computed by the source gNB is per candidate cell or per candidate gNB in the LTM configuration update procedure.

2.2 Security issues of inter-MN LTM
o	(MAC-19) FFS whether NCC is optional present in Enhanced LTM Cell Switch Command MAC CE. FFS for which cases should this Enhanced LTM Cell Switch Command MAC CE is used, e.g. whether only for inter-CU case with security key update.
Proposal 3: (MAC-19) The NCC is mandatory present in Enhanced LTM Cell Switch Command MAC CE. And the Enhanced LTM Cell Switch Command MAC CE is used only for LTM with security key update.
o	(RRC-7) Editor’s note: FFS whether the list of sk-counters can be used only for the case of inter-MN LTM.
Proposal 4: (RRC-7) The list of sk-counters can be used only for the case of inter-SN LTM. For inter-MN LTM, the UE does not use the list of sk-counters.

2.3	Open issue: RRC-2
o	(RRC-2) Editor’s Note: FFS if appliedLTM-CandidateId needs to be included in both MCG and SCG RRCReconfigurationComplete message.
Proposal 5: (RRC-2) The appliedLTM-CandidateId needs to be included in both MCG and SCG RRCReconfigurationComplete message.

3GPP TSG-RAN WG2 Meeting #130		R2-2503617
St. Julian’s, Malta, 19th – 23rd May 2025
Source:	vivo
Title:	Discussion on inter-CU LTM
Agenda Item:	8.6.2
Document for:	Discussion and Decision

Conclusion
In this paper, we discuss the remaining open issues for inter-CU LTM. We have the following observations and proposals:
LTM fast recovery (RRC-8)
Proposal 1: (RRC-8) After RLF or intra-CU LTM failure, if the selected candidate cell has a Rel-19 ID differs from the source cell, the UE cannot perform LTM fast recovery.
Proposal 2: (RRC-8) After intra-CU LTM failure, if the selected candidate cell has the same Rel-19 ID as the source cell, the UE performs LTM fast recovery (same as in Rel-18).
Proposal 3: (RRC-8) After inter-CU LTM failure, if the selected candidate cell has the same Rel-19 ID as the source cell, the UE cannot perform LTM fast recovery. 
Proposal 4: (RRC-8) After inter-CU LTM failure, if the selected candidate cell has a Rel-19 ID differs from the source cell, the UE performs LTM fast recovery.
Proposal 5: (RRC-8) After L3 HO or CHO failure, if the selected candidate cell has the same Rel-19 ID as the source cell, the UE cannot perform LTM fast recovery (same as in Rel-18). 
Proposal 6: (RRC-8) After L3 HO or CHO failure (without security key update), if the selected candidate cell has a different Rel-19 ID as the source cell, the UE cannot perform LTM fast recovery (same as the intra-CU LTM cell switch failure case). 
Proposal 7: (RRC-8) After L3 HO or CHO failure (with security key update), if the selected candidate cell has a different Rel-19 ID as the source cell, the UE performs LTM fast recovery (same as the inter-CU LTM cell switch failure case). 

appliedLTM-CandidateId included in both MCG and SCG RRCReconfigurationComplete message (RRC-2)
Proposal 8: (RRC-2) appliedLTM-CandidateId is included in both MCG and SCG RRCReconfigurationComplete message.

CFRA resource in LTM Cell Switch Command MAC CE
Observation 1: For inter-CU LTM, the target cell needs to identify which UE is performing CFRA-based RACH and which CFRA resources are being used when the CFRA resources are shared among multiple UEs.    
Proposal 9: For inter-CU LTM, a target cell specific CFRA resource pool could be provided by target gNB-DU to source gNB-DU,  and the CFRA resource are assigned by S-DU in the LTM cell switch command MAC CE. 
Proposal 10: Send an LS to inform RAN3 to support the CFRA resources included in the LTM Cell Switch Command MAC CE assigned by S-DU for inter-CU LTM.

Coexistence of inter-CU LTM with MIMO 2TA
Observation 2: Mismatch issue will occur when the TCI state ID indicated in the LTM Cell Switch Command MAC CE is associated with one TAG while the TA value in the RACH RAR is associated with another TAG, assuming the co-existence between RACH-based LTM and R19 MIMO two TA is supported.
Proposal 11: RAN2 selects from the following three options to address the mismatch issue that the TCI state ID indicated in the LTM Cell Switch Command MAC CE and TA value in the RAR within the RACH-based LTM procedure are associated with different TAGs:
Option 2: Target DU sends a new TCI state in RACH Msg 4.
Option 3: If the mismatch issue occurs, UE follows the TCI state associated with the RACH-based LTM procedure. Otherwise, UE follows the indicated TCI state in the LTM cell switch command.
Option 4: UE selects the SSB associated with the same TAG ID as the TAG ID associated with the indicated TCI state in LTM Cell Switch Command MAC CE during the RACH-based LTM procedure.
Proposal 12: If Option 3 in Proposal 11 is agreed, send an LS to RAN1 to inform the mismatch issue between the TCI state in LTM MAC CE and TA value in RAR and provide the corresponding solution.
Proposal 13: Send an LS to ask RAN1 whether Rel-19 MIMO 2TA can be configured with inter-CU LTM using PDCCH-order based TA measurement.

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

Agenda item:	8.6.2
Source: 	China Telecom
Title:	Discussion on remaining issues of Inter-CU LTM
WID/SID:	NR_Mob_Ph4-Core
Document for:	Discussion and Decision

Conclusion
In this contribution, we discuss remaining issues on inter-CU LTM in Rel-19. We kindly ask RAN2 to consider the corresponding proposals listed as below.
Proposal 1: Regarding MCG LTM with SN addition, RAN2 to confirm that there is no restriction on only supporting MCG LTM with SN addition within the same SN. The related Editor’s note could be deleted.
Proposal 2: RAN2 confirms not to support the fast recovery with different Rel-19 set ID from the target.

3GPP TSG-RAN-WG2 Meeting #130	R2-2503744
, MT, 19th– 23rd May, 2025
Agenda item	:		8.6.2
Source	: 	Sharp
Title	: 	Discussion on issues for supporting inter-CU LTM
Document for	:	Discussion and Decision

Conclusion
In this paper, we made the following observations and proposals;
Observation 1. ltm-Config (which doesn’t contain inter-CU LTM candidate configuration) for MCG and ltm-ConfigNRDC can be simultaneously configured.
Proposal 1. When the UE is configured with intra-CU MCG LTM and inter-CU SCG LTM, the UE has independent UE variables for each of ltm-Config and ltm-ConfigNRDC.
Proposal 2. ltm-Config for SCG and ltm-ConfigNRDC cannot be simultaneously configured.
Proposal 3. Intra-CU SCG LTM candidate configuration can be mixture into ltm-ConfigNRDC if ltm-ConfigNRDC is configured.
Observation 2. It is wasteful if UE releases ltm-Config for SCG by explicit signalling from SN before ltm-ConfigNRDC is configured by MN, from the perspective of radio resource efficiency.
Proposal 4. UE autonomously releases the contents of ltm-Config for SCG when the ltm-ConfigNRDC is configured.
Proposal 5. To select the appropriate sk-Counter, UE needs to select the first sk-Counter value in the sk-CounterList associated with the ltm-NoSecurityChangeID within the VarLTM-ServingCellNoSecurityChange as above TP1.
Proposal 6. The list of sk-Counters is not used for inter-MN LTM.
Proposal 7. UE can perform fast recovery if it is reconfigurationWithSync (inter-CU LTM) failure and if the selected candidate cell has the same Rel-19 ID as source cell.
Proposal 8. UE cannot perform fast recovery if it is reconfigurationWithSync (inter-CU LTM) failure and if the selected candidate cell has a different Rel-19 ID from both of source cell and target cell.
Proposal 9. UE sends the selected configuration ID and the selected sk-Counter via MN RRCReconfigurationComplete message upon inter-CU SCG LTM execution as above TP2.
Proposal 10. RAN2 confirms that Rel-19 CLTM can co-exist with Rel-18 LTM.
Proposal 11. CLTM configuration can coexist with inter-CU MN LTM configuration in case of non-DC.
Proposal 12. By following the rationale in Rel-18, when the inter-CU LTM is triggered at the MAC entity of the UE, the MAC entity of the UE notifies the RRC layer of the UE.
Proposal 13. RAN2 further discuss: 
The case when the RRC layer of the UE receives the L3 HO command and the MAC entity of the UE receives the LTM CSC MAC CE to execute the inter-CU LTM, and
The execution priority of L3 HO and inter-CU LTM.

3GPP TSG-RAN WG2 Meeting #130	R2-2503747
St. Julians, Malta, May 19th – 23rd, 2025
Agenda Item:	8.6.2
Source: 	Fujitsu
Title:	Discussion on inter-CU LTM
Document for:	Discussion and Decision

Conclusion
We have the following observations and proposals.
Observation 1: If the UE does not revert back to the source PCell configuration before performing fast LTM recovery, this leads to increasing complexity of the specifications and impact on UE implementation.
Observation 2: If the UE reverts back to the source PCell configuration before performing fast LTM recovery, keystream reuse issue happens if the UE selects the same target cell again for fast LTM recovery. However, this can be avoided by UE implementation.
Observation 3: If the UE selects a cell which does not belong to the source gNB or the target gNB, additional signalling for transferring the NCC value from the source gNB to the selected gNB is needed to perform fast LTM recovery.
Observation 4: 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: The UE reverts back to the source PCell configuration after inter-CU LTM cell switch failure
Proposal 2: The UE shall ensure that it does not perform fast LTM recovery if it selects the same target cell.
Proposal 3: RAN2 not to support fast LTM recovery after the UE fails LTM cell switch which requires security key refresh if the selected cell has a different Rel-19 ID from the target cell or the source cell
Proposal 4: RAN2 should discuss whether it supports the fast LTM recovery if the selected cell has the same Rel-19 ID as the source cell.
Proposal 5: RAN2 to discuss a solution to solve the data loss issue when the UE performs fast LTM recovery to an intra-DU LTM candidate cell after inter-DU LTM cell switch failure.

3GPP TSG-RAN WG2 #130                                             	    R2-2503804                                                              
St. Julian’s, Malta, May 19th – 23rd, 2025                                                 	     
Agenda item:	   8.6.2
Source: 		Qualcomm Incorporated
Title: 	Discussion on inter-CU LTM
Document for:	Discussion
1	

Conclusion
This contribution discussed aspects related to inter-CU LTM. The following observations and proposals have been made:
Observation 1: Due to the NCC delivery via the new Rel-19 LTM CSC MAC CE for inter-CU LTM, UE cannot have the valid security parameter for candidate cells whose Rel-19 ID is different from target cell during subsequent inter-CU LTMs. Therefore, LTM recovery towards those candidate cells won’t be possible.
Proposal 1: RAN2 agree to NOT support the LTM recovery to a candidate cell with different Rel-19 ID from the target cell.
Observation 2: Unlike Rel-18 intra-CU LTM where reverting back to source cell configuration suffices upon T304 expiry, Rel-19 inter-CU LTM has dependency for reverting UE configuration w.r.t. the selected cell being one of candidate cells and its Rel-19 ID.
Proposal 2: RAN2 decide the following for inter-CU LTM failure (upon T304 expiry and while T311 running):
If the selected cell is one of the candidate cells and it has the same Rel-19 ID as target cell, then UE performs LTM recovery.
Else, UE reverts back to the source cell configuration and performs RRC re-establishment.

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

Agenda item:		8.6.2	Inter-CU LTM
Title:		Discussion on inter-CU LTM
Source:		NEC
Document for:		Discussion and Decision
1. 

Conclusion
In this contribution we discussed some issues related to inter-CU LTM and made the following proposals.
Proposal 1a (RRC-8): If reconfiguration failure for inter-CU LTM cell switch, and if the selected candidate cell has the different Rel-19 ID as the source cell, the UE performs fast failure recovery. 
Proposal 1b (RRC-8): If reconfiguration failure for inter-CU LTM cell switch, and if the selected candidate cell has the same Rel-19 ID as the source cell, the UE does not perform fast failure recovery.
Proposal 2 (RRC-2): For inter-CU SCG LTM, to assist the MN to identify the target SN, UE includes the identity of applied LTM candidate configuration in the MN RRCReconfigurationComplete message.
Proposal 3 (RRC-2): For inter-CU SCG LTM, to assist the SN to identify the applied LTM candidate configuration, UE includes the identity of applied LTM candidate configuration in the embedded SN RRCReconfigurationComplete message.
Proposal 4: Support in Rel-19 that the UE triggers PDCP recovery for an AM DRB, if one of its associated RLC bearer is released in case of LTM cell switch without L2 reset. And RAN2 to agree the corresponding TP in Annex.
4. 

3GPP TSG-RAN WG2 #130	R2-2503858
Malta, May 19th – 23rd, 2025						    	 

Agenda item:	8.6.2
Source: 	Ericsson
Title:  	Inter-CU LTM and Fast Recovery
Document for:	Discussion and Decision

Conclusion
In the previous sections we made the following observations: 
Observation 1	In case of inter-SN LTM, the SN RRCReconfigurationComplete message will just simply be received by the MN via the ULInformationTransferMRDC, and the MN will simply forward it to the SN.
Observation 2	Subsequent LTM needs to be supported also for the case of inter-MN LTM.
Observation 3	The support of fast recovery for the case of inter-CU LTM is challenging as there are several cases that needs to be considered.

Based on the discussion in the previous sections we propose the following:
Proposal 1	Use the term “LTM” for anything which is common for LTM and CLTM while the term “CLTM” is only used for something which apply only to CLTM.
Proposal 2	RAN2 to discuss how the UE informs the MN about the selected sk-counter in case of inter-SN LTM.
a.	The selected sk-counter is always included in the SN RRCReconfigurationComplete message and the SN forward the sk-counter to the MN.
b.	The selected sk-counter is included within the ULInformationTransferMRDC when an inter-SN LTM is executed.
Proposal 3	The list of sk-counter is used also for the case of inter-MN LTM.
Proposal 4	RAN2 to revert the previous agreement and to agree that fast recovery is only possible in case of RLF and LTM cell switch failure, when the UE selects a cell which Rel-19 ID is the same as the one of the source PCell.

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

Source:                    	DENSO CORPORATION
Title:  	Discussion on inter-CU LTM
Document for:        	Discussion and decision
Agenda Item:         	8.6.2	Inter-CU LTM

Summary and proposal
This paper discussed the procedure for mixture of inter-CU LTM and intra-CU LTM. In summary, the followings were proposed:
Proposal 1: The UE reverts back to the security configuration (i.e. security key, the value of NCC and the VarLTM-ServingCellNoSecurityChangeID) used in the source cell after reconfiguration with sync failure.
Proposal 2: The UE can select all candidate cells during fast failure recovery after inter-CU LTM failure. 

TDoc file reading error

TDoc file reading error

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

1.	

Conclusion
In this paper, we have made the following observations and proposals:
Inter-CU LTM cell switch completion
Proposal 1. For both MCG and SCG RRCReconfigurationComplete message, the appliedLTM-CandidateId is included.
Proposal 2. The selectedSK-Counter is included into the RRCReconfigurationComplete message if a new sk-Counter value has been selected due to the LTM cell switch execution procedure regardless of whether the LTM cell switch is triggered on MCG or SCG.
Proposal 3. Adopt TP1 if Proposal 1 and Proposal 2 are agreed.

Security update for inter-CU MCG LTM with DC
Proposal 4. RAN2 confirm that a single value of sk-Counter is provided within RRCReconfiguration-v1560-IEs of the RRCReconfiguration message to the UE for the SN key update in inter-CU MN LTM with unchanged SN (i.e., follow the legacy R15 RRC reconfiguration with sync procedure).
Observation 1. Redundant SN security update during subsequent intra-CU MCG LTM cell switches can result in redundant PDCP reestablishment at the PDCP entities associated with SN and consequently data interruption can occur.
Proposal 5. SN security update during subsequent MCG LTM cell switches with DC (i.e., SN is not changed) is performed only if MN security update is performed during an MCG LTM cell switch.
Proposal 6. RAN2 consider TP2 or TP3 as an implementation of Proposal 5.

LTM based recovery for inter-CU LTM cell switch failure
Proposal 7. RAN2 to conclude when the UE shall revert back after inter-CU LTM cell switch failure, based on the following options:
Option 1: The UE doesn’t revert back to the source PCell configuration upon T304 expiry if the LTM cell switch procedure required security key refresh (i.e. inter-CU LTM). The UE reverts back to the previously connected PCell configuration if the selected cell is not associated with the R19 ID of the target cell.
Option 2: The UE reverts back to the source PCell configuration except for the state variables upon T304 expiry.
Proposal 8. RAN2 to consider TP4 (Option 1) and TP5 (Option 2) as an implementation of Proposal 7.
Proposal 9. The fast failure recovery to a candidate cell with different Rel-19 IDs than the target cell is NOT allowed.
Proposal 10. UE keeps the LTM configuration as result of the LTM recovery based on inter-CU candidate cell.

4.	

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

Agenda item:	8.6.2
Source:	Nokia
Title:	On remaining issues for inter-CU LTM
WID/SID:	NR_Mob_Ph4 - Release 19
Document for:	Discussion and Decision
1	

Conclusion
In this paper, we analyzed the remaining open issues for Inter-CU LTM and made the following observations and proposals.
Proposals related to Open Issues of Inter-CU LTM 
Issue-1 :Fast Recovery candidate nodes
Observation 1: Update of security configuration at all candidate nodes can be easily integrated in current procedure and brings the benefit of recovery possibility at all candidate nodes for Inter-CU switch failure.
Observation 2: Update of security configuration at the time of switching can be second option which involves additional delay in switching.
Proposal 1: Remove the FFS and Confirm that Fast recovery to any candidate CU is supported after Inter-CU LTM switch failure. 
Issue-2 :Revert back to Source configuration for Inter-CU Failure
Proposal 2: On Inter-CU LTM switch failure UE revert back to source cell configuration except the PDCP variables for SRB2. FFS whether additional Inter node signaling needed to handle the PDCP SN difference.
Issue 3: LTM Switch failure due to security issues
Observation 3: The LTM switch failure due to alteration of NCC (due to security attacks) on cell switch command is not known to the NW for Inter-CU cell-switch scenario.
Proposal 3: Inclusion of applied-NCC value in RRC message after LTM switch failure is supported.

Issue 4: Inter CU Fast recovery for RLF prior to first LTM switch
Observation 5:  Prior to first LTM switch all the candidate nodes are prepared with Target security key configurations based on the current NCC value.
Observation 6: In case of RLF prior to first LTM switch the fast recovery is possible at UE using its current NCC value.
Proposal 4: Fast Recovery to Inter-CU candidates is supported for RLF prior to first LTM switch.
Issue 5: Inter CU Fast recovery for RLF prior to first LTM switch
Proposal 5: SK-counter list configured for LTM candidates are only used for Inter-SN LTM. FFS in above EN is removed.
Remaining Issues of Inter-CU LTM 
Observation 7: In some Inter-CU LTM scenarios subsequent mobility is not needed at some candidate cells. Release of configuration of other candidates is preferred in this case.
Proposal 6: Non-subsequent LTM towards selected candidates is supported for Inter-CU LTM.
Observation 8: Support of CG-based inter-CU LTM may lead to excessive PUSCH resource reservation.
Proposal 7: To avoid excessive resource reservation overhead for CG-based RACH-less LTM, PUSCH resources can be shared among multiple UEs. PUSCH resource sharing among UEs should be coordinated by the source node.
Remaining Issues of DC LTM 
RRC Open Issues with Text Proposal
Proposal 8A: RAN2 to consider the TP in Annexure to discuss and clarify how the inter-CU SCG LTM configuration received in ltm-ConfigNRDC is maintained at the UE.
Proposal 8B: RAN2 to consider the TP  in the Annexure to update and clarify the field descriptions for inter-CU SCG LTM in the RRC running CR.
Other Remaining Issues 
Observation 9: In the case of inter-CU SCG LTM, it is likely that in many scenarios the SCG configuration prepared by all or some of the candidate SNs may have identical SCG configuration. In such a case, the MCG part of the inter-CU SCG LTM candidate configuration prepared by the source MN remains unchanged.
Proposal 9:  RAN2 to discuss the inter-CU SCG LTM scenario with identical SCG configuration and agree to have a new indication in ltm candidate configuration to enable the UE to avoid replacing the current MCG configuration during inter-CU SCG LTM cell switch.
Observation 10: For the intra-CU MCG LTM with SCG unchanged, MRDC-SecondaryCellGroupConfig ReleaseAndAdd need not have to be performed.
Proposal 10: RAN2 to discuss the intra-CU MCG LTM scenario with SCG unchanged and agree on introducing a new indication in ltm candidate configuration to avoid SCG release and add procedure.
Proposal 11: RAN2 to discuss signaling procedure to handle blind PSCell addition/change when two candidate LTM configurations have same MCG (PCell) but different SCG (PScell).
Co-existence Issue : SCG LTM And CHO 
Proposal 12: RAN2 to discuss the UE behaviour for handling of SCG LTM cell switch command received during CHO execution for PCell.

4	

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

Agenda Item:	8.6.2
Source:	Huawei, HiSilicon
Title:	Inter-CU LTM
Document for: Discussion and Decision
1	

Conclusion
This contribution makes the following proposals:
Fast recovery
Proposal 1a: In inter-CU LTM cell switch failure, the UE can perform recovery to a candidate cell with at Rel-19 ID different from the target cell.
Proposal 1b: In inter-CU LTM cell switch failure, if the selected cell for recovery has the same Rel-19 ID as the source cell, the UE performs key update and PDCP re-establishment.
Proposal 2: In source cell RLF case, support fast recovery if the selected cell for recovery has a different Rel-19 ID from the source cell. Discuss the following two solutions:
Solution 1: introduce a new MAC CE for NCC delivery independently of LTM cell switch.
Solution 2: the UE obtains a new NCC from the selected cell during the CBRA procedure.
Enhanced LTM cell switch command MAC CE
Proposal 3: In the Rel-19 Enhanced LTM Cell Switch Command MAC CE, the NCC value is mandatory present. For the case when the key update is not needed, the network sends a Rel-18 LTM cell switch command MAC CE.
MCG LTM
Proposal 4: For Rel-19 MCG LTM, at LTM cell switch execution, the (target) MN indicates the target LTM candidate configurations ID to the SN.
Proposal 5: For Rel-19 MCG LTM, if there are SN-terminated bearers in the target LTM candidate configuration, the target MN provides the SN key to the SN at LTM cell switch execution.
Coexistence of intra-CU and inter-CU SCG LTM
Proposal 6: When there are inter-SN and intra-SN LTM candidate cells for SCG LTM, it is the MN that configures all the LTM candidates (with a MN RRC message).
SCG LTM UL grant handling
Proposal 7: For inter-CU SCG LTM, the network ensures that the UE does not skip the UL grant for RACH-less cell switch, regardless whether SRB3 is configured.
4	

TDoc file reading error

TDoc file reading error

3GPP RAN WG2 Meeting #130	R2-2504262
St.Julians, Malta May 19th – 23rd, 2025             
Agenda Item:	8.6.2
Source:	Ofinno
Title:	Discussion on open issues of inter-CU LTM
Document for:	Discussion, Decision                        

Conclusions
The contribution discussed aspects related to remaining open issue for inter-CU LTM. The following observations and proposals are made:
For identified open issues:
Observation 1: (RRC-7) Configuring only one sk-Counter in the LTM candidate configurations for MCG LTM with SCG leads to reuse of sk-Counter during subsequent LTMs.
Proposal 1: (RRC-7) For MCG LTM with SCG, network configures a list of sk-Counter based on of the of the following options:
	Option 1: network configures a list of sk-Counter in all LTM candidate configurations, and UE uses the first entry in the list of sk-Counter for generating the SN key when security key update is performed in MCG.
	Option 2: network configures a list of sk-Counter corresponding to each R19 ID of candidate cells for MCG LTM, and UE uses the first entry in the list of sk-Counter corresponding to the R19 ID of the MCG candidate cell, for generating the SN key when security key update is performed in MCG
	Option 3: network configures a R19 ID of an SCG candidate cell in all LTM candidate configurations for MCG LTM. The UE uses the first entry in the list of sk-counter corresponding to the R19 ID of the SCG candidate cell, for generating the SN key when security key update is performed in MCG.
Proposal 2: (RRC-7) UE removes the entry from the list of sk-Counter once it is used to generate the SN key.
Proposal 3: (RRC-8): Fast failure recovery to a candidate cell with different Rel-19 ID (from the serving/ target cell) is not supported.
For other open issues:
Observation 2: early TA acquisition is supported for candidate PSCell of SCG LTM while not supported for a candidate PSCell of SCG within MCG LTM.

Proposal 4: RAN2 discuss whether to support early TA acquisition for a candidate PSCell of SCG within MCG LTM.

Observation 3: a CG resource of a candidate cell for LTM is wasted until the UE execute the LTM cell switch procedure for the candidate cell.
Proposal 5: RAN2 discuss dynamic management of CG resource of candidate cell for LTM.
Proposal 6: LTM candidate configuration for MCG LTM with SCG is not considered for LTM fast recovery. 

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

Agenda Item:	8.6.2
Source: 	Rakuten 
Title:  	Remaining issues of Inter-CU LTM

Document for:	Discussion, Decision

Conclusion
We have the following observations:
Observation 1	UE determining a successful reception of its first UL data at the gNB, based on the dynamic grants being scheduled and concluding the success of the LTM cell switch may not be appropriate as the dynamic grants may not have been scheduled based on the reception of the first UL data.
We have the following proposals: 
Proposal 1	RAN2 asks RAN1 regarding which beam should be considered as current beam i.e the beam associated with the PDCCH or the one associated with PDSCH.
Proposal 2	RAN2 sends an LS to RAN3 to re-consider the gNB-DU initiated LTM candidate cell re-configuration in Release 19.
Proposal 3	The UE initiates a fresh scheduling request with the new serving gNB-DU, despite allocation of the dynamic grants, to ensure that the first UL data was successfully received at the gNB.
Proposal 4	If the new serving gNB-DU issues dynamic grant corresponding to the new scheduling request, the UE concludes that the UL transmission was successful and the RACH-less LTM is completed successfully.

3GPP TSG-RAN WG2 Meeting #130	R2-2504389
St.Julians, Malta,  May 19th – 23rd , 2025
Agenda item:	8.6.2
Source:	CMCC
Title:	Discussion on inter-CU LTM
Document for:	Discussion, Decision

Conclusion
In this contribution, we discuss inter-CU LTM related issue. Following are the proposals and observations made in this contribution:
Observations:
Observation: The same NCC value is shared among different CUs/gNBs in CHO.
Observation 2: CHO candidate cells are invisible to each other, while for LTM, candidate cells are visible to each other, which may result in high probability of security exposure.
Observation 3: The content of appliedLTM-CandidateId is LTM-CandidateId, which is configured by MN in inter-CU SCG LTM.
Proposals:
Proposal 1: Fast failure recovery with different Rel-19 IDs can be supported. 
Proposal 2: For LTM fast recovery to the candidate cell requiring security key updating, UE should revert back to the PCell’s configuration if T304 expires.
Proposal 3: CSI-RS resources can be indicated in LTM cell switch command for RACH-based intra-CU/inter-CU LTM.
Proposal 4: appliedLTM-CandidateId is only included in MCG RRCReconfigurationComplete message.
Proposal 5: Network triggered SN change/PsCell change and (S-)CPAC can be configured to UE, when (SN initiated) inter-CU SCG LTM is configured.
-	When performing network triggered SN change/PsCell change or (S-)CPAC, the UE does not autonomously release inter-CU LTM configurations, unless these are explicitly released by the network.
-	The RRCReconfiguration message to execute an SN change/PsCell change/(S-)CPAC procedure may reconfigure inter-CU LTM configurations.
-	For the execution order between (S-)CPAC and inter-CU SCG LTM, similar principle for CHO and inter-CU MCG LTM is reused.

3GPP TSG-RAN WG2 Meeting #130	R2-2504423
St. Julians, Malta, May. 19th – 23rd, 2025
Agenda item:	8.6.2
Source:	ETRI
Title:	Remaining open issues on inter-CU LTM
Document for:	Discussion, Decision

Conclusions
In this paper, we discuss CLTM related issue. Following are proposals made in this paper:

Proposal 1: The Enhanced LTM CSC MAC CE always contains an NCC value field
Proposal 2: The Enhanced LTM CSC MAC CE is used when the R19 set IDs of the target cell and the source cell are different. Otherwise, the legacy LTM CSC MAC CE is used.
Proposal 3: if the UE selects a candidate cell whose Rel-19 ID is different from the source cell after intra-CU LTM, the UE performs RRC reestablishment procedure. (i.e., the fast recovery is not supported)
Proposal 4: if the UE selects a candidate cell whose Rel-19 ID is different from the target cell after inter-CU LTM, the UE performs RRC reestablishment procedure. (i.e., the fast recovery is not supported)

TDoc file reading error

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

Agenda item:	8.6.2
Source:	Samsung
Title:	Further Considerations to Support Inter-CU LTM
WID/SID:	NR_Mob_Ph4-Core
Document for:	Discussion and Decision

Conclusion
In this contribution, we address the fast recovery, and have the following proposals:
Proposal 1: RAN2 is kindly asked to agree to support the fast recovery without security key change.
Proposal 2: RAN2 is kindly asked to clarify the correct behaviour when the UE selects the cell under the same CU as source cell after inter-CU LTM failure (e.g., performing re-establishment vs. fast recovery).

Proposal 3: the fast recovery without security key update cannot be supported for the case of selecting a cell under different CU from source/target cell. 

Proposal 4: RAN2 is kindly asked to discuss the timing of “reverting back” operation after inter-CU LTM failure by considering the following two options:
Option 1: “revert back” after T304 expiry (legacy)
Option 2: determine “revert back” when a cell is selected, i.e., skip “revert back” if the selected cell is under the same CU as the target cell, otherwise, “revert back” to the source cell. 
Proposal 5: RAN2 is kindly asked to agree that after the fast recovery failure, the UE should revert back to the configuration of the source cell triggering the LTM cell switch.
Proposal 6: Legacy cell switch command MAC CE is used for case where security key refresh is not needed (e.g. intra CU case). New cell switch command MAC CE is used for case where security key refresh is needed (e.g. inter CU case).