3GPP TSG RAN WG2 Meeting #130            	                      R2-2503417
St Julian’s, Malta, 19-23 May 2025
Agenda Item:	8.10.2
Source:	Xiaomi
Title:	Discussion on Rel-19 SON/MDT open issues
Document for:	Discussion and Decision

Conclusion
In this contribution, we propose:
MRO for LTM
Proposal 1: RAN2 to follow RAN3’s agreement to use NW-based solution for LTM candidate cell list, i.e. add a list indicating which LTM candidates the UE had in the SHR. 

MRO for CHO with candidate SCGs
Proposal 2: To align with RAN2#129bis agreement, RAN2 to explicitly capture target PSCell ID (without measurements) in SHR for successful CHO with candidate SCGs in RRC CR. Network can associate this ID with measurements retrieved from neighbour cell measurement results based on implementation. 
Proposal 3: (RRC-1) It’s not needed to adopt a correlation solution between SHR and SPR in case of both reports being generated in a CHO with candidate SCG execution scenario. 

MRO for SDT
Proposal 4: For SDT, the maximum value of 172800 in timeSinceSdtExecution IE only indicate 172800 seconds or longer. The FFS “FFS for the case beyond this value and the understanding from UE and network side, as for value beyond this range NW cannot recognize the right SDT configuration” can be removed.

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

Source:	CATT 
Title:	MRO Enhancements for Rel-18 Mobility
Agenda Item:	8.10.2
Document for:	Discussion and Decision
1. 

Conclusion
According to the discussion in section 2, we propose:
LTM
MRO for SCG LTM
Proposal 1: MRO enhancement for SCG LTM is not considered in Rel-19 SON/MDT.
Enhance RLF report for LTM MRO
Proposal 2: Include TCI state ID from LTM cell switch command in RLF report for RACH-less LTM failure.
Enhance SHR for LTM MRO
Proposal 3: The legacy SHR trigger conditions based on T310 threshold and T304 threshold can be applied to LTM.
Proposal 4: Include L3 measurement results of serving cell, target cell and other LTM candidate cell(s) in SHR for LTM MRO.
Enhance RACH report for LTM
Proposal 5: Enhance raPurpose in RACH report to support successful RACH-based LTM execution. The detail can be discussed further, e.g., whether to reuse legacy raPurpose or introduce a new raPurpose.
Proposal 6: A new raPurpose in RACH report is introduced to indicate the network-based early TA acquisition.
Proposal 7: RAN2 to discuss how to log the RACH information of network-based early TA acquisition to avoid the impact on the legacy RACH information logging (e.g., RACH information for handover):
Option 1: one entry in RACH report to log the RACH information of all network-based early TA acquisition before one LTM execution;
Option 2: one entry in RACH report to log the RACH information of all network-based early TA acquisition before LTM configuration release;
Option 3: log the RACH information of network-based early TA acquisition per candidate cell in one or multiple entries.
Other issues
Proposal 8: To address the issue of frequent overriding RLF report/SHR for subsequent LTM, recording multiple reports can be considered as a candidate solution.
Proposal 9: Indication information is needed in RLF report/SHR to indicate whether it’s L1 measurement based LTM or L3 measurement based LTM.

CHO with candidate SCG(s)
Enhance RLF report for CHO with candidate SCG(s)
Proposal 10: Enhance RLF report for CHO with candidate SCGs to include the information for each candidate PSCell, i.e., execution condition configuration, first fulfilled event and time duration between two events fulfilled, if any.
Both SHR and SPR being generated in a CHO with candidate SCG
Proposal 11: (RRC-1) Correlation of the SHR and SPR is needed in case of both reports being generated in a CHO with candidate SCG execution scenario.
Proposal 12: (RRC-1) Two reports for SHR and SPR separately, and the association information is added in the two reports when both SHR and SPR being generated in a CHO with candidate SCG execution scenario. FFS detailed association information.
Proposal 13: (RRC-1) UE logs the overlapped information only in SHR when both SHR and SPR being generated in a CHO with candidate SCG execution scenario.
4. 

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

Agenda item:	8.10.2
Source:	Nokia
Title:	MRO for LTM and near failure handling for CHO with candidate SCGs
WID/SID:	NR_ENDC_SON_MDT_Ph4-Core – Rel-19
Document for:	Discussion and Decision
1	

Conclusion
This document has made the following observation and proposals for TA optimization:
Observation 1: Timely and correct early TA acquisition is crucial for LTM to guarantee its benefits, namely a RACH-less cell switch for minimum handover interruption time.
Proposal 1: RAN2 agrees that optimization of timing of ETA is a crucial part of MRO for LTM
Proposal 2: RAN2 agrees to log additional information regarding TAs that were unnecessarily acquisitioned. 
Proposal 3: RAN2 to discuss adding the following information into RLF report: TA difference between TA provided by network in Cell Switch Command for which the RACH-less LTM failed, and TA received in RAR for recovery/re-establishment. 
Proposal 4: RAN2 to discuss signalling that allows the UE to indicate that the use of the UE measurement-based TA is preferred.

This document has made the following proposals for MRO for CHO with candidate SCGs:
Proposal 5: RAN2 to discuss and decide on a correlation mechanism for SHR and SPR generated for the same CHO with candidate SCG execution, for example by introducing a coexistence flag in each report. 
Proposal 6: RAN2 to agree that there is a need to distinguish if the T310 started before or after fulfilment of the first execution conditions for CHO with Candidate SCG(s) and an indication about this in SHR and SPR.

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

Agenda item:	 8.10.2
Source:		Lenovo
Title:		Discussion on MRO enhancements for LTM
Document for:		Discussion and Decision
1	

Conclusion
In this paper, MRO enhancements for LTM are discussed. We have the following proposals:
Proposal 1: RACH information for early TA acquisition can be included in RA report.
Proposal 2: One entry can be used to log both RACH information related with early TA acquisition and RACH information related with RACH based access (e.g. LTM failure recovery or RRC re-establishment) in RA report.
Proposal 3: A new RA purpose to indicate the RA procedure was triggered for early TA acquisition can be introduced in RA report.

3GPP TSG-RAN WG2 #130	R2-2503932
St. Julian's, Malta, 19th – 23rd May 2025
                                               
Source:		NEC
Agenda item:		8.10.2	MRO enhancements for Rel-18 mobility features
Title:	MRO enhancement for LTM
Document for:		Discussion and decision

Conclusion
In this paper, we discuss on how to optimize the case of LTM failure due to invalid/outdated TA, and have the following proposal:
Proposal 1: In case of LTM cell switch failure, UE includes in RLF report the difference between the TA value in the cell switch command and the TA value obtained during the successful LTM recovery procedure.

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

Agenda item:	8.10.2
Source:	Samsung
Title:	Remaining issues for MRO enhancements 
Document for:	Discussion and Decision

Conclusion
Based on the discussion, we have the following observation and proposals.
MRO for LTM
Open issue in LTE RRC CR
Proposal 1: When the LTM based recovery fails and the UE selects E-UTRA cell and receives RRCConnectionSetup, timeUntilReconnection refers to the first failure. This need to be captured in running 36.331 CR.
Issue with logging L1 measurements for LTM in RRC CR
Observation 1: L3 filtered beam measurements are included for all the candidates in RLF report and SHR. 
Proposal 2: L1 measurements for LTM are logged only for the candidates for which LTM-SSB-Config-r18 is configured.
MRO for SCG LTM
Proposal 3: L1 measurements for LTM candidates can be reported in SCGFailureInformation/SPR.
Capability for LTM
Proposal 4: Define separate UE capability parameters with signalling for RLF report and SHR for MRO of LTM cell switch.
MRO for CHO with Candidate SCG(s)
Open issue in NR RRC CR
Observation 2: There is no new measurement added in SHR or SPR due to CHO with candidate SCG(s).
Proposal 5: No special handling is needed to avoid duplication of information in SHR and SPR.
RLF due to the CHO and associated CPAC conditions cannot be met simultaneously.
Proposal 6: For CHO with candidate SCG(s), to optimise RLF due to the execution conditions for candidate PCell and the associated candidate PSCell cannot be met simultaneously, UE logs the following in RLF report:
a)  List of fulfilled execution conditions before the RLF is encountered.
b) Time elapsed between each of the fulfilled execution conditions and RLF.

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

Title: 	Discussion on MRO for mobility
Source: 	Huawei, HiSilicon
Agenda item:	8.10.2
Document for:	Discussion and Decision

Conclusion
Based on the discussions above, we have the following proposals:
Proposal 1: (LTERRC-1) It is proposed to remove the condition below:
3>	if the last RRCReconfiguration message including the reconfigurationWithSync for the SCG was received to enter the PSCell in which the SCG failure was declared:
Proposal 2: (LTERRC-2) When the LTM based recovery fails and the UE selects E-UTRA cell and receives RRCConnectionSetup, timeUntilReconnection need to refer to the first failure.
Proposal 3: (LTERRC-3) It is proposed to have separate containers for all the fields i.e. PerRAInfoList-r16, PerRAInfoList-v1660 and PerRAInfoList-v1800.
Proposal 4: For RACH-less access based on network TA, include the following information in RLF report:
Time period between the reception of the PDCCH order and the reception of HO command MAC CE related to the failed LTM cell switch
Proposal 5: It is proposed RAN2 to agree to enhance the RLF report with the beam information contained in the LTM cell switch command.
Proposal 6: It is proposed RAN2 to agree that the legacy MRO for CHO is reused for triggered CHO-only in terms of RLF and SHR report, i.e. no special handling for CHO-only.

3GPP RAN WG2 Meeting #130	R2-2504270
St.Julians, Malta May 19th – 23rd, 2025             	revision of R2-2502604
Agenda Item:	8.10.2
Source:	Ofinno
Title:	Discussion on MRO for LTM
Document for:	Discussion, Decision                        

Conclusions
The contribution discussed aspects related to open issues for MRO for LTM. The following observations and proposals are made:
For measurement information in MRO
Proposal 1: Indicate in RLF report/ SHR report whether the LTM to the target cell is based on L3 measurement or L1 measurement. 
Proposal 2: Indicate in RLF report/ SHR report whether the neighbor cell (i.e., LTM candidate cells) measurements is based on L3 measurement or L1 measurement.
For RLF report:
Proposal 3: Indicate in RLF-report whether the UE received TA from cell switch command for the candidate cell.
Proposal 4: Introduce a UE capability for indicating whether a UE supports an RLF report for LTM.
For SHR report:
Proposal 5: Indicate whether RACH-less access is based on CG or DG based on one of:
Explicit indication whether RACH-less access is based on CG or DG
Explicit indication whether CG for RAHC-less access is valid or invalid
Proposal 6: Indicate index of SSB where the CG is determined to be valid/ invalid. 
Proposal 7: Indicate whether a neighbour cell is an LTM candidate cell or not.
Proposal 8: A UE logs the time elapsed between receiving PDCCH order for triggering RACH (for early UL synchronization) on a candidate cell, and receiving LTM cell switch command MAC CE for cell switch to the same candidate cell.

TDoc file reading error

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

Agenda Item:	8.10.2
Source: 	ASUSTeK
Title:  	Discussion on random access report for LTM
Document for:	Discussion and Decision

Conclusion
We have the following proposals for LTM-related RA reports:
Proposal 1:	RA reports for LTM shall include the following cases:
RACH for Early UL synchronization on a candidate cell.
NW-triggered RACH-based LTM towards a target cell.
UE-triggered RACH-based LTM towards a selected Cell after failed LTM execution.
Proposal 2:	Discuss whether to reuse current values of raPurpose (e.g., reconfigurationWithSync) or introduce new values of raPurpose for LTM-related RA reports.
Proposal 3:      A single RA report is used to indicate random access information for all early UL synchronization on the same candidate cell.

TDoc file reading error

3GPP TSG-RAN WG2 Meeting #130	R2-2504558
St.Julians, Malta,  May 19th – 23rd , 2025
Source:                Qualcomm Incorporated 
Title:	MRO enhancements for mobility
Agenda Item:	8.10.2
Document for:	Discussion and Decision
Introduction & 

Conclusion
Enhance MHR to include a “HO-type” (i.e., LTM or L3 HO). 
UE indicates to gNB in RLF Report if RACH-less LTM is attempted or not before RACH-based LTM failure.
UE indicates to gNB in SHR if RACH-less LTM is attempted or not before RACH-based LTM successful RACH-based LTM recovery.
There is no need to avoid duplication of information in case of two reports generate CHO with candidate SCGs, i.e.in SHR and SPR.

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

Agenda Item:	8.10.2
Source: 	LG Electronics
Title:  	Remaining MRO issues for MOB

Document for:	Discussion

Conclusion
It is proposed to discuss and decide on the following proposals:
Proposal 1: RAN2 discuss to avoid duplication of CHO and CPAC evaluation results when two separate reports (RLF report and SCG failure information) are generated based on the the following options:
Option 1: The UE checks whether the CHO and CPAC evaluation results have already been reported, and excludes them if so.
Option 2: The UE removes CHO and CPAC evaluation results after logging them once in any report.
Proposal 2:	In the RLF report for MCG LTM, RAN2 should revisit and decide whether the UE should explicitly log the access type.
Proposal 3:	In the RLF report for MCG LTM, the UE logs not only the access type but also the commanded access type which was indicated LTM CSC if the access type is different from the commanded access type.

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

Agenda Item:	8.10.2
Source:	Ericsson
Title:	Further considerations on MRO for LTM and CHO with candidate SCG
Document for:	Discussion/Decision	

Conclusion
In the previous sections we made the following observations: 
Observation 1	No matter if the HO is a pure Rel.16 CHO or the Rel.18 CHO with candidate SCG, the UE will always log the timeSinceCHO-Reconfiguration as the time gap since receiving the condRRCReconfig, according to the existing specification.
Based on the discussion in the previous sections we propose the following:
Proposal 1	RAN2 to consider the case of LTM cell switch failure due to outdated/wrong TA calculated by UE.
Proposal 2	The UE logs the TA received from RAR in the target cell in the RLF report.
Proposal 3	UE logs available L1 measurement results in the SHR for the serving cell, the target cell and other LTM candidate cells when the UE is LTM configured.
Proposal 4	UE reports the time gap between the reception of the last configuration of the CHO with candidate SCG configuration and the RLF/HOF.
Proposal 5	RAN2 to agree on the following alternatives to include target PSCell ID in the SHR:
a.	Explicit inclusion of the target PSCell ID in the SHR.
b.	Include a flag in the ChoWithCandidateSCG IE to indicate the target PCell and PSCell pair to which UE executed the CHO with candidate SCG procedure.

3GPP TSG-RAN WG2 Meeting #130	R2-2504618
St Julian’s, Malta, May 19th – 23rd, 2025
                         
Source:	vivo
Title:	Discussion on open issues about CHO with candidate SCGs
Agenda Item:	8.10.2
Document for:	Discussion and Decision

Conclusion
Based on the above analysis, we make the following proposals:
Proposal 1: For CHO with candidate SCGs, the NW can correlate the SHR and SPR based on the existing source/target cells information and the new paring information (in ChoWithCandidateSCGInfo). Thus no additional correlation information is needed.
Proposal 2: For CHO with candidate SCGs, no need to consider avoiding duplicated information in SHR and SPR.

TDoc file reading error