Monitoring suboptimal successful handovers in mobility robustness optimization procedures

Abstract

A first cell receives information indicating that a user equipment has had a handover from the first cell to a second cell that was successful and including a cause indicating a near failure event associated with the handover. The first cell determines, based at least on the cause, a measurement to accumulate. The first cell accumulates a number of near failure events for the cause by incrementing the determined measurement.

Description

Monitoring Suboptimal Successful HandoversTECHNICAL FIELD

[0001] Examples of embodiments herein relate generally to wireless communications in cellular networks and, more specifically, relate to monitoring handovers in cellular networks.BACKGROUND

[0002] Mobility Robustness Optimization (MRO) in cellular systems refers to a set of strategies and techniques designed to enhance the performance of mobile networks, particularly in the context of user mobility. MRO ensures that users experience seamless connectivity and high-quality service while moving between different coverage areas. Here’s an overview of its key components:

[0003] Key aspects of MRO include the following.

[0004] 1) MRO aims to improve the overall user experience by reducing call drops, optimizing handovers, and minimizing latency. This is especially important in high-speed environments, such as urban areas with high traffic.

[0005] 2) Handover management is performed. In particular, MRO focuses on both handovers (e.g., between cells) within the same base station and handovers between (e.g., cells of) different base stations of user equipment (wireless and mobile devices) to maintain connectivity. It is noted that a same base station would be intra-gNB and different base stations would be inter-gNB. There are multiple cells in a given gNB. Furthermore, algorithms are implemented to determine the optimal time to initiate a handover, considering factors like signal strength, quality of service (QoS) metrics, and user speed.

[0006] 3) Radio resource management is addressed. This includes efficient management of radio resources that ensures that users receive adequate bandwidth even while moving. This includes adjusting resources based on real-time demand and network conditions. This further includes distributing user traffic evenly across available cells to prevent congestion and improve overall network performance.

[0007] 4) MRO techniques help in maintaining QoS parameters like throughput, latency, and packet loss rates during user mobility. This is essential for applications like video streaming and VoIP.

[0008] 5) In 5G (fifth generation) and beyond, MRO leverages network slicing to create virtual networks tailored for specific use cases, ensuring that mobility requirements are met without compromising the performance of other slices.

[0009] 6) Utilizing machine learning and data analytics, predictive models can forecast user movement patterns, allowing the network to preemptively adjust resources and manage handovers more effectively.

[0010] 7) MRO algorithms optimize the criteria for selecting and reselecting cells based on user movement patterns, signal quality, and network conditions to ensure users are always connected to the best available resource.

[0011] 8) Addressing interference caused by adjacent cells, especially in dense urban environments, is an aspect of MRO used to maintain signal integrity and service quality.

[0012] Mobility Robustness Optimization is a vital component of modern cellular networks, especially as user expectations for seamless connectivity rise. By focusing on effective handover management, resource allocation, and QoS maintenance, MRO ensures that mobile networks can accommodate diverse and dynamic user needs. There are, however, still challenges that could be addressed for areas such as handover of user equipment.BRIEF SUMMARY

[0013] This section is intended to include examples and is not intended to be limiting.

[0014] An example of a method includes receiving, at a first cell, information indicating that a user equipment has had a handover from the first cell to a second cell that was successful and including a cause indicating a near failure event associated with the handover. The method includes determining, by the first cell based at least on the cause, a measurement to accumulate. The method also includes accumulating by the first cell a number of near failure events for the cause by incrementing the determined measurement.

[0015] An additional example includes a computer program, comprising instructions for performing the method of the previous paragraph, when the computer program is run on anapparatus. The computer program according to this paragraph, wherein the computer program is a computer program product comprising a computer-readable medium bearing the instructions embodied therein for use with the apparatus. Another example is the computer program according to this paragraph, wherein the program is directly loadable into an internal memory of the apparatus.

[0016] An example of an apparatus includes one or more processors and one or more memories storing instructions that, when executed by the one or more processors, cause the apparatus at least to perform: receiving, at a first cell, information indicating that a user equipment has had a handover from the first cell to a second cell that was successful and including a cause indicating a near failure event associated with the handover; determining, by the first cell based at least on the cause, a measurement to accumulate; and accumulating by the first cell a number of near failure events for the cause by incrementing the determined measurement.

[0017] A further example is computer program product that includes a computer- readable storage medium bearing instructions that, when executed by an apparatus, cause the apparatus to perform at least the following: receiving, at a first cell, information indicating that a user equipment has had a handover from the first cell to a second cell that was successful and including a cause indicating a near failure event associated with the handover; determining, by the first cell based at least on the cause, a measurement to accumulate; and accumulating by the first cell a number of near failure events for the cause by incrementing the determined measurement.

[0018] In another example, an apparatus comprises means for: receiving, at a first cell, information indicating that a user equipment has had a handover from the first cell to a second cell that was successful and including a cause indicating a near failure event associated with the handover; determining, by the first cell based at least on the cause, a measurement to accumulate; and accumulating by the first cell a number of near failure events for the cause by incrementing the determined measurement.BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The accompanying drawings use reference numerals, where the same reference numerals may be used to refer to like parts throughout, but parts having the same reference numeral can differ in operation and components. In the attached drawings:

[0020] FIG. 1, split over FIGS. 1A and IB, illustrates examples of almost late (FIG. 1A) and almost early (FIG. IB) successful handovers;

[0021] FIG. 2A illustrates multiple causes for an SHR related intra-RAT handover;

[0022] FIG. 2B illustrates a configuration of thresholds related to the multiple causes in FIG. 2A;

[0023] FIG. 2C illustrates content of the reported SHR;

[0024] FIG. 3 is a signaling diagram for monitoring intra-5GS mobility;

[0025] FIG. 4 is a signaling diagram for monitoring intra-5GS mobility with SHR followed by RLF report;

[0026] FIG. 5 is a signaling diagram for monitoring inter-system mobility with SHR (cause=T310);

[0027] FIG. 6 is a signaling diagram for monitoring inter-system mobility with SHR (cause=T304);

[0028] FIG. 7 is a signaling diagram for monitoring inter-system mobility with SHR followed by RLF report;

[0029] FIG. 8 is a flowchart of Intra-System / Inter-System Monitoring Enhancement Logic; and

[0030] FIG. 9 is a block diagram of one possible and non-limiting exemplary system in which the exemplary embodiments may be practiced.DETAILED DESCRIPTION OF THE DRAWINGS

[0031] Abbreviations that may be found in the specification and / or the drawing figures are defined below, at the end of the detailed description section.

[0032] The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily tobe construed as preferred or advantageous over other embodiments. All of the embodiments described in this Detailed Description are exemplary embodiments provided to enable persons skilled in the art to make or use the examples.

[0033] When more than one drawing reference numeral, word, or acronym is used within this description withand in general as used within this description, the “ / ” may be interpreted as “or”, “and”, or “both”. As used herein, “at least one of the following: ” and “at least one of ” and similar wording, where the list of two or more elements are joined by “and” or “or,” mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0034] As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises”, “comprising”, “has”, “having”, “includes” and / or “including”, when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.

[0035] It is noted that capital and lowercase words or phrases are considered to be the same herein. For instance, the words Slice, slice, and SLICE are the same, as are the phrases Network Repository Function, network repository function, and NETWORK REPOSITORY FUNCTION.

[0036] Any flow diagram (e.g., FIG. 8) or signaling diagram (e.g., FIGS. 3-7) herein is considered to be a logic flow diagram, and illustrates the operation of an exemplary method, results of execution of computer program instructions embodied on a computer readable memory, and / or functions performed by logic implemented in circuitry. For methods, flow diagrams, and signaling diagrams, the orders of method steps, blocks in the flow, or signaling are not critical and instead are examples.

[0037] Technical context is now provided for technical areas related to the understanding of the examples. One topic of interest concerns Mobility Robustness Optimization (MRO).

[0038] Mobility Robustness Optimization (MRO) procedures were originally defined for mobility failure procedures in 3 GPP R16 (third generation partnership project, release 16).Subsequent enhancements were added to detect and optimize what are called sub-optimal successful handover events. It is noted that DAPS handover, used in the description below, is a handover procedure that maintains the source gNB connection after reception of an RRC (radio resource control) message for handover and until releasing the source cell after successful random access (using the random access channel, RACH) to the target gNB.

[0039] Sub-optimal successful handover events are defined where ordinary handovers, DAPS (Dual Active Protocol Stack) handovers, or conditional handovers succeed, but there is an opportunity to improve the procedure. For example, these successful procedures may happen too early or too late depending on the conditions. It is applicable for intra-system and inter-system mobility. Intra-system mobility involves a handover between two different base stations using the same RAT (radio access technology), whereas inter-system mobility involves a handover between two different base stations using different RATs (radio access technologies).

[0040] In more detail, the terminology for different handovers may be described as follows:

[0041] 1) Intra-system Handover: handover that does not involve a CN (core network) change (e.g., EPC, evolved packet core, or 5GC, fifth generation core).

[0042] 2) Inter-system Handover: handover that involves a CN change (EPC or5GC).

[0043] In the intra-system cases described herein, both versions may be applicable, and the access network (e.g., RAN, radio access network) changes (or) the access network remains the same - in both cases, the core remains the same. In the inter-system cases described herein, the core network changes and the access network also changes.

[0044] FIG. 1, split over FIGS. 1A and IB, illustrates suboptimal handovers, with examples for “Almost Too Late” in FIG. 1 A and “Almost Too Early” in FIG. IB successful handovers. The handover being performed is to handover a UE from a source cell (Celli) to a target cell (Cell2). It is noted that PCells (primary cells) appear in a special case where dual connectivity is enabled, but the examples herein are applicable to the general case where no dual connectivity is used. Typically, for a handover to be performed, there are rules where the targetcell has to be better than the source cell in some metric and using at least a threshold. The UE connects to the target cell using a RACH (random access channel).

[0045] In the timeline for FIG. 1 A, the UE is in connected mode in Celli (primary cell #1) at time 110. The UE sees a RLF (radio link failure) and starts timer T310 at time 115. At time 120, the UE gets a HO (handover) command to Cell2, and the HO succeeds from Celli to Cell2 in time 125. In time 130, the UE sends an SHR (Successful handover report) with cause T310. Block 135 indicates that the HO command is received late after the UE detects out of synch (synchronization), but the UE recovers. If the HO command had been delayed a bit more, this would have resulted in a HO failure. So, the cause value = T310 in SHR corresponds to the “Almost Too Late HO” scenario.

[0046] In the timeline for FIG. IB, the UE is in connected mode in Celli (primary cell #1) at time 140. The UE gets a HO (handover) command to Cell2, and timer T304 is started. See time 145. In time 150, there is a RACH (random access channel) to the target cell fails, since the source cell is still good and the target is not so good yet. In time 155, the HO to the target succeeds. In time 160, the UE sends an SHR (Successful handover report) with cause T304. Block 170 indicates that the HO command is received early, when the source has not deteriorated and the target hasn’t become very good yet. The UE attempts RACH on the target cell and fails. The UE finally recovers and syncs to the target. If the HO command had been sent a bit earlier, it would have failed. So, the cause value = T304 in SHR and this corresponds to “Almost Too Early HO” scenario.

[0047] One of the functions of Mobility Robustness Optimization (MRO) is to detect a sub-optimal but successful handover event. The aim is to identify underlying conditions during successful ordinary handovers, successful DAPS handovers, or successful conditional handovers.

[0048] For analysis of successful handover, the UE may collect Successful Handover Reports (SHRs) based on configuration by network, if stored, and makes the SHRs available to the network as specified in 3GPP TS 38.331. As specified in TSA 38.331 Rel-17, the SHR related intra-RAT handover may be generated by one or multiple of the following causes, as illustrated in FIG. 2A. These causes are described herein, although attention is paid mainly to the causes for T304, T310, and T312. It is noted that these timers may also be referred to using alowercase “t”: t304, t310, and t312. Moreover, the number by itself might be used, e.g., timer 304 instead of timer t304.

[0049] Information about these timers is as follows.

[0050] 1) The “t304-cause” indicates whether the UE shall generate the SHR upon successfully completing the handover but while accessing to the target cell the T304 was running and the ratio between the value of the elapsed time of the timer T304 and the configured value of the T304 timer is greater than the threshold of thresholdPercentageT304.

[0051] 2) The “t310-cause” indicates whether the UE shall generate the SHR upon successfully completing the handover to the target cell while during the execution the handover the T310 was running in source cell and the ratio between the value of the elapsed time of the timer T310 and the configured value of the T310 timer, is greater than the threshold of thresholdPercentageT310.

[0052] 3) The “t312-cause” indicates whether the UE shall generate the SHR upon successfully completing the handover to the target cell while the T312 associated to the measurement identity of the target cell was running at the time of initiating the execution and if the ratio between the value of the elapsed time of the timer T312 and the configured value of the T312 timer, is greater than thresholdPercentageT312.

[0053] 4) The “sourceDAPS-Failure” field indicates whether the UE shall generate the SHR upon successfully completing the DAPS handover to the target cell and if a radio link failure was experienced in the source Cell while executing the DAPS handover.

[0054] The configuration of the related thresholds as specified in 3GPP TS 38.331 are illustrated in FIG. 2B. For Rel-18, the SHR concept is currently extended towards inter-RAT handover, i.e., handovers between NR and E-UTRA. Hereto, it was agreed that for the direction from NR to E-UTRA an SHR can only be triggered by the t310-cause and t312-cause, while the opposite RAT change from E-UTRA to NR only the t304-cause is applicable.

[0055] The content of the reported SHR defined in 3GPP TS 38.331 is illustrated in FIG. 2C. The UE stores the SHR until the SHR is fetched by the network or for 48 hours after the SHR is recorded. For SHR collected during intra-NR handover, if the target NR node fetches the SHR from the UE and the trigger of SHR is T310 / T312, the target NR node may forward the information to the source NR node, i.e., the node handling the cell reported as source cell in thisSHR, by using the ACCESS AND MOBILITY INDICATION message over Xn or by means of the uplink RAN (radio access network) configuration transfer procedure and downlink RAN configuration transfer procedure over NG.

[0056] If the NG-RAN node that fetches the SHR from the UE is neither the source node nor the target node of the handover, the node forwards the information to the node(s) which configured the SHR trigger causing the SHR to be generated, by using the ACCESS AND MOBILITY INDICATION message over Xn or by means of the uplink RAN configuration transfer procedure and downlink RAN configuration transfer procedure over NG.

[0057] In case of failure shortly after successful Handover, the same mobility event may generate both a SHR and an RLF report. In this case, the node(s), which configured the SHR trigger causing the SHR, may take the duplication into account, e.g., ignore the SHR.

[0058] Upon retrieval of an SHR, the receiving node may analyze whether its mobility configuration needs adjustment. The SHR report can be collected for intra-NR handover and for handover from NR to E-UTRA (Evolved Universal Terrestrial Radio Access).

[0059] Now that the technical context has been described, problems in these areas are described. As indicated above, there are two categories of MRO procedures for both intra-RAT and inter-RAT mobility.

[0060] 1) Category- 1 : MRO related to failed mobility procedures (originally specified in R16).

[0061] 2) Category-2: MRO related to successful, but sub-optimal mobility procedures (added in R17 / R18).

[0062] Corresponding to these Category- 1 MRO procedures, monitoring functionality / measurements was also added in 3GPP TS 28.552 for intra and inter RAT handover in chapter 5.1.1.25.1 and 5.1.1.25.2 , respectively.

[0063] These measurements could be used to quantify these failures and derive statistical significance of each type of failure and take appropriate actions / optimizations in the various thresholds related to the HO procedure. These measurements are based on the RLF Report and address the monitoring of the following types of failures:

[0064] 1) too early handovers;

[0065] 2) too late handovers; and / or

[0066] 3) handover to the wrong cell.

[0067] These suboptimal handovers are addressed herein.

[0068] An overview is presented now and additional details are presented below. Methods are proposed of monitoring of the risky or failed but recovered mobility cases which finally resulted in success handover via providing new performance measurements for at least the following scenarios:

[0069] 1) “Almost too early” Handover; and / or

[0070] 2) “Almost too late” Handover.

[0071] These near failure cases which are pegged based on successful handover report (SHR) received from the UE with the t310 / t312-cause cause and t304-cause, respectively. The measurements are pegged (that is, incremented) per the source and target Cell pair. This is, operations herein may be performed for multiple pairs of cells, such as a pair of first and second cells, and at least one or both of the first cell or second cell are different between the multiple pairs of cells.

[0072] A new measurement is proposed herein for the so-called near failure event followed shortly after successful handover with RLF in the target cell, characterized by an SHR followed by an RLF Report in the Target cell. For instance, three counters are proposed each (i.e., for a total of six counters) for intra-5GS and inter-system Handover procedures.

[0073] Referring to FIG. 3, this figure is a signaling diagram for monitoring intra- 5GS mobility. This addresses a call flow-1 intra-5GS mobility with SHR [Almost Too Early / Almost Too Late HO], The signaling is between a UE 10 that is connected to a source gNB 70-1 (e.g., a RAN cell #1), where the target gNB 70-2 (e.g., a RAN cell #2) is the target to which the HO is to be made. The RAN cells #1 and #2 are cells that are formed by the corresponding gNB.

[0074] In step 0, the UE is in the RRC connected state and is involved in measurement control and reports, which result in the source gNB 70-1 making a HO decision in step 1. Steps 2-4 involve preparation for the handover to the target gNB 70-2, where the source gNB 70-1 sends a HO request using the Xn interface (step 2), the target gNB 70-2 performs admission control (step 3), and the target gNB 70-2 responds with a HO request acknowledgement (Ack) over the Xn interface (step 4).

[0075] Descriptions of some important steps are as follows.

[0076] Steps 5 / 6: The source gNB 70-1 sends (step 5) the HO Command to the UE 10 requesting the UE to synchronize with the identified target cell / gNB. The configuration includes information (e.g., time periods and potentially other information) for the timers T304, T310, T312 and includes an SHR trigger. The UE starts (see reference 301) the timer T304 and attempts to synchronize (step 6) with the target gNB 70-2.

[0077] Steps 7-9: As part of the synchronization process, the UE 10 detects out-of- synchronization for a brief period (starting and stopping T310), which means the SHR trigger is met in step 7, and the SHR is collected and stored in step 8. The UE attempts measurements on the target cell (starting and stopping T312). As these are defined as part of the SHR trigger, the UE collects these in the Successful HO Report and indicates the same to the Target gNB. In step 9, the UE sends RRC Reconfiguration Complete messaging, with parameters of HO Complete and successHO-InfoA vailable to the target gNB 70-2.

[0078] Steps 10-12: The target gNB 70-2 then collects the SHR from the UE (via step 10 using RRC and a UE Information Request with a parameter of SHR, and a response from the UE in step 11 of UE Information Response with the parameters of Successful HO report with SHR-cause and timesinceSHR). The target gNB 70-2 then shares the same with the Source gNB over the Xn interface and via an Access Mobility Indication (Ind) using a parameter of Successful HO Report.

[0079] Step 13: The Source gNB may then collect the measurements that are defined herein. FIG. 8 and corresponding text describes this part.

[0080] FIG. 4 is a signaling diagram for monitoring intra-5GS mobility with SHR followed by an RLF report. The signaling here adds a retrieving gNB 70-3 (e.g., a RAN cell #3), which is involved because of a RLF that happens after the UE 10 performs a HO to the target gNB, the retrieving gNB 70-3 (e.g., its RAN cell #3) is the best cell, and is used so the UE 10 can send at least the SHR.

[0081] In step 1 , there is a successful intra RAT (radio access technology) HO, but the T310 / T312 trigger is met. The UE stores the SHR in step 2, and there is a RLF for the UE shortly after a successful HO in step 3, which causes the UE to also store the RLF report in step 4. The UE sends (after successful HO to the retrieving gNB 70-3, in step 5) a NR RLF reporthaving the parameter of Target C-RNTI (Cell-Radio Network Temporary Identifier). The retrieving gNB indicates (step 6) to the target gNB 70-2 with FAILURE INDICATION messaging with parameters of NR RLF Report Container with Target C-RNTI. The target gNB 70-2 sends (step 7) a HO Report to forward to the source gNB 70-1 the NR RLF Report Container with Target C-RNTI. The UE 10 sends, in step 8 to the retrieving gNB 70-3, NR SHR T310 / 312 messaging with the parameter of Target C-RNTI. The retrieving gNB 70-3 in step 9 sends an Access and Mobility Indication to the source gNB 70-1, with the parameters of NR SHR T310 / 312 with Target C-RNTI. Step 10 involves the Source gNB collecting the measurements that are defined herein. FIG. 8 and corresponding text describes this part.

[0082] Important steps to comment on for this figure are as follows. In this case, the source gNB receives both the SHR and RLF Report. The source gNB may then monitor these and peg (i.e., increment) the counters that are defined below with respect to FIG. 8. The counting logic is given in FIG. 8 and the actual counter definition is provided in text for that figure.

[0083] Referring to FIG. 5, this figure is a signaling diagram for monitoring intersystem mobility with SHR (cause=T310). This example has a source gNB 70-1 using one RAT (e.g., 5G) and a target ng-eNB 70-2 using a different RAT (e.g., LTE, long term evolution). The ng-eNB 70-2 is referred to as a next-generation eNodeB, which is an enhanced version of a 4G (fourth generation) eNodeB (evolved NodeB). The ng-eNB 70-2 connects 5GUEs to 5G CN (Core Network) using a 4G LTE air interface. The air interfaces are different. In this example, the RAN cell #1 uses a RAT and air interface for 5G, and the RAN cell #2 uses a RAT and air interface for LTE.

[0084] In step 0, the UE is in the RRC connected state and is involved in measurement control and reports, which result in the UE 10 detecting (step 1) an out-of-sync and starts timer T310. Reference 501 indicates there is a late HO, and the source gNB 70-1 sends (step 2) RRC reconfiguration messaging with parameters of HO command and SHR trigger. In step 3, the UE stops T310, and evaluates and creates the SHR. In step 4, the UE successfully performs a HO to the target ng-eNB 70-2. Reference 502 indicates the UE moves back to NR sometime later and indicates the presence of SHR. Based on this, the source gNB 70-1 sends in step 5, using RRC signaling, messaging of UE Information Request with SHR. The UE 10sends, using RRC signaling in step 6, messaging of UE Information Response with SHR with a cause of T310. In step 7, the source gNB may then monitor these and peg (i.e., increment) the counters that are defined below with respect to FIG. 8. The counting logic is given in FIG. 8 and the actual counter definition is provided in text for that figure.

[0085] Important steps discussed are as follows. In this case, the source gNB receives both the SHR and RLF Report. The source gNB may then monitor these and peg the counters that are defined below with respect to FIG. 8.

[0086] Turning to FIG. 6, this figure is a signaling diagram for monitoring intersystem mobility with SHR (cause=T304). This example has the source base station as being a source ng-eNB 70-1 (with RAN cell #1) of one RAT (e.g., LTE) and the target gNB 70-2 (e.g., with RAN cell #2) of a second RAT (e.g., 5G). The air interfaces are different. The steps in FIG. 6 are similar to the steps in FIG. 3 and will not be described in more detail.

[0087] Referring to FIG. 7, this figure is a signaling diagram for monitoring intersystem mobility with SHR followed by RLF report. This example describes signaling between the UE 10, source gNB 70-1 (e.g., with RAN cell #1), target ng-eNB 70-2 (e.g., with RAN cell #2), retrieving gNB 70-3 (e.g., with RAN cell #3), and reconnecting ng-eNB 70-4 (e.g., with RAN cell #4). The source gNB 70-1 and retrieving gNB 70-3 use a different RAT (e.g., 5g) and different air interface than do the target ng-eNB 70-2 and the reconnecting ng-eNB 70-4, which use the RAT and air interface based on LTE. This example has an RLF after successful HO to a ng-eNB 70-2, then a connection to the reconnecting ng-eNB 70-4. The SHR is communicated via the retrieving gNB 70-3.

[0088] The first four steps are similar to the first four steps in FIG. 5. In step 5, the UE 10 sends messaging of an LTE RLF Report with a parameter of Target C-RNTI to the reconnecting ng-eNB 70-4, to which the UE is currently connected. The reconnecting ng-eNB sends (step 6) messaging of a Failure Indication to the target ng-eNB 70-2 with the parameters of LTE RLF Report Container with the Target C-RNTI. The target ng-eNB 70-2 sends (step 7) a HO report with the target C-RNTI and time since failure extracted from the LTE Report to the source gNB 70-1. The UE in step 8 sends messaging of NR SHR T310 / 312 with parameters of the target C-RNTI, and time from generating until reporting the SHR. This is sent to the retrieving gNB 70-3, which then sends (step 9) messaging of Access and Mobility Indicationwith parameters of NR SHR T310 / 312 along with the target C-RNTI and time from generating until reporting SHR. Step 10 is where the source gNB may then monitor these and peg the counters that are defined below with respect to FIG. 8.

[0089] Turning to FIG. 8, this figure is a flowchart of intra-system / inter-system monitoring enhancement logic. This is assumed to be performed by the source gNB 70-1. Block 805 is an indication of a measurement period start in gNB-CU-CP (gNB central unit-control plane). A central unit (CU) is used for a functional split in a gNB, where there is a CU and a DU (distributed unit). The Central Unit (CU) is a logical node that includes the gNB functions like transfer of user data, mobility control, radio access network sharing, positioning, session management, and the like, except those functions allocated exclusively to the DU. The CU controls the operation of DUs over a mid-haul interface. The Distributed Unit (DU) is a logical node that includes a subset of the gNB functions, depending on the functional split option. Its operation is controlled by the CU.

[0090] Step 810 is a first checking location. This block checks the cause value received in SHR. Using step 810, the gNB selects one of blocks 815, 820, or 825 to perform. Note that it is possible none of those blocks need to be performed, but this is not addressed in this figure.

[0091] As briefly described above, there are six new counters that may be used. Each of these counters may be incremented (e.g., “pegged”) based on the corresponding cause. Three of the counters are for the intra-system case, and three of the counters are for the inter-system case.

[0092] In block 815, the SHR-cause is equal to “t304-cause”. In response, the gNB 70-1 increments (block 830) a first counter HO. IntraSys. AlmostTooEarly (for Intra-System Case) or increments a second counter HO. InterSys. AlmostTooEarly (for Inter-system case). These keep track of the count of the “Almost Too Early” suboptimal handovers.

[0093] In block 820, the SHR-cause is equal to “t310-cause” or “t312-cause”. In response, in block 835, the gNB 70-1 increments a third counter HO. IntraSys. AlmostTooLate (for Intra-System Case) or increments a fourth counter HO. InterSys. AlmostTooLate (for Intersystem case). These counters keep track of the count of the “Almost Too Late” suboptimal handovers.

[0094] In block 825, the SHR-cause is equal to “t304-cause” or “t310-cause” or "t312-cause" and also the UE declares an RLF within the time period less or equal than T_UE Context store timer. It is noted that all three timers apply only for intra-system handovers. For inter-system handovers, only timer 312 or timer T310 apply. The T_UE Context store timer may be described through the following. The UE could remain stable in the target gNB for an hour. It is important know whether it was a normal RLF or RLF after HO. The Context store timer is for determining whether it is a HO problem or not, and would be set as a threshold before after which a normal HO is assumed and before which a RLF after HO is assumed. In block 840, the gNB 70-1 increments a fifth counter HO. IntraSys. NearFailureRLF (for IntraSystem Case) or increments a sixth counter HO. Inter Sys. NearFailureRLF (for Inter-system case). These counters keep track of the count of “Near Failure” suboptimal handovers.

[0095] At some point, the measurement period will end. This is illustrated by block 845, Measurement Period End. After the measurement period ends, block 850 may be performed.

[0096] In block 850, eased on the new measurements introduced herein, the operator could take the following actions (and these are merely examples):

[0097] 1) In case of "Almost Too Early" handovers, the network could alter the HO initiation thresholds so that handovers could be started later;

[0098] 2) In case of "Almost Too Late" handovers, the network could modify (e.g., optimize) the HO initiation thresholds to ensure that handovers happen sooner.

[0099] 3) In case of "SHR Followed by RLF Report" cases, the operator could root cause the reason for the RLF and ensure that the RLF doesn't happen or reduces in frequency.

[0100] The above actions could be analyzed location-wise (say at cell level or TAI, tracking area identity, level) and local actions / policies could be implemented. Also, other patterns (like, for example, near-failures over time) could be derived by the operator and improvement actions taken.

[0101] Blocks 860 and 870 are another way of examining parts of this flowchart. The blocks 815, 820, and 825 may be viewed as individual causes indicating near failure events associated with the HO. See block 860. For instance, the SHR-cause equal to t304-cause in block 815 indicates an almost-too-early near failure event. A near failure event associated with aHO is an event that does not cause a failure for the circumstances involved in the handover but is an event that could cause a failure of the handover under different circumstances. Block 870 determines a measurement to accumulate and accumulates the number of near failure events for the cause. The measurement may be based only the cause, but also may include two measurements, each based on a cause but also based on the intra-system case or the inter-system case. Furthermore, individual measurements may be based on a counter, but other techniques may also be used.

[0102] It is possible to address this via certain rules. Consider Handover near failures related to MRO for intra-system mobility.

[0103] a) This measurement provides the number of handover near failure events related to MRO detected during the intra-system mobility within 5GS, see 3GPP TS 38.300 clause 15.5.2. The measurement includes separate counters for various handover near failure types, classified as "Intra-system almost too early handover" and "Intra-system almost too late handover" and “Near failure event followed with RLF report”.

[0104] b) The measurements of almost too early handovers and almost too late handovers events may be obtained respectively by accumulating the number of near failure events detected by gNB during the intra-system mobility within 5GS. The counter for almost too early handovers event may be triggered based on the Successful Handover Report received from UE with SHR-cause equal to “t304-cause”, see 3GPP TS 38.331 clause 6.2.2. The counter may be triggered in source NR cell CU and reported per source and target NR cell CU pair. The counter for almost too late handovers event is triggered based on the Successful Handover Report received from UE with SHR-cause equal to “t310 / 312-cause”, see 3GPP TS 38.331 clause 6.2.2. The counter is triggered in source NR cell CU and reported per source and target NR cell CU pair.

[0105] As the UE stores the SHR until the SHR is fetched by the network or for 48 hours after the SHR is recorded, the network may identify the point in time successful handover to which the SHR is related with backward compatibility based on timeS inceSHR IE reported within the SHR, see 3GPP TS 38.331 clause 6.2.2.

[0106] The measurement of “Near failure event followed with RLF report” may be obtained by accumulating the number of near failure events detected by gNB during the intra-system mobility within 5GS which are followed shortly after successful handover with RLF detected by UE in the target NR cell CU. The counter for “Near failure event followed with RLF report” may be triggered when trigger conditions for almost too early and / or almost too late handovers event based on the Successful Handover Report received from UE with SHR-cause equal to “t304-cause” and / or “t310 / 312-cause” is met which is followed with HO to wrong cell as defined in 3GPP TS 38.300, clause 15.5.2.2.2. The counter may be triggered in source NR cell CU and reported per source and target NR cell CU pair. The network / NG RAN node of the source NR cell CU identifies the SHR and RLF report sent within the HO report are from the same UE and related to the same mobility event based on the same target C-RNTI reported and timesinceSHR and timesinceFailure in the SHR and RLF report, respectively are pointing to some point in time when the mobility event happened with some tolerance configured by vendor.

[0107] c) Each measurement is an integer value and are indicated as follows: HO. IntraSys. AlmostTooEarly; HO. IntraSys. AlmostTooLate; HO. IntraSys. NearFailureRLF

[0108] d) Valid for packet switched traffic.

[0109] e) One usage of this measurement is to support MRO (see 3GPP TS 28.313).

[0110] Handover near failures related to MRO for inter-system mobility are described as follows.

[0111] a) This measurement provides the number of handover failure events delated to MRO detected during the successful inter-system mobility between NG-RAN and E-UTRAN, limited to the scenarios defined in 3GPP TS 38.300 clause 15.5.2.2.3. The measurement includes separate counters for various handover failure types, classified as "Inter-system almost too early handover" (inter-system mobility from E-UTRAN to NG-RAN) and "Inter-system almost too late handover" (inter-system mobility from NG-RAN to E-UTRAN) and “Near failure event followed with RLF report”.

[0112] b) The measurements of almost too early inter-system handover events may be obtained by accumulating the number of near failure events detected during the successful inter-system mobility from E-UTRAN to NG-RAN. The counter for almost too early handovers event may be triggered based on the Successful Handover Report received from UE with SHR- cause equal to “t304-cause”, see 3GPP TS 38.331 clause 6.2.2. The counter is triggered in target NR cell CU and reported per source E-UTRAN and target NR cell CU pair. The measurementsof almost too late inter-system handover events may be obtained by accumulating the number of near failure events detected during the successful inter-system mobility from NG-RAN to E- UTRAN. The counter for almost too late handovers event may be triggered based on the Successful Handover Report received from UE with SHR-cause equal to “t310 / 312-cause”, see 3GPP TS 38.331 clause 6.2.2. The counter may be triggered in source NR cell CU and reported per source NR and target E-UTRAN cell CU pair.

[0113] As the UE stores the SHR until the SHR is fetched by the network or for 48 hours after the SHR is recorded, the network identifies the point in time successful handover to which the SHR is related with backward compatibility based on timeSinceSHR IE reported within the SHR, see TS 38.331

[0020] clause 6.2.2.

[0114] The measurement of “Near failure event followed with RLF report” is obtained by accumulating the number of near failure events detected by gNB during the intersystem mobility from NG-RAN to E-UTRAN which are followed shortly after successful handover with RLF detected by UE in the target E-UTRAN cell CU. The counter for “Near failure event followed with RLF report” is triggered when trigger conditions for almost too late handovers event based on the Successful Handover Report received from UE with SHR-cause equal to “t310 / 312-cause” is met which is followed with HO to wrong cell as defined in TS 38.300, clause 15.5.2.2.2. The counter is triggered in source NR cell CU and reported per source NR and target E-UTRAN cell CU pair. The network / NG RAN node of the source NR cell CU identifies the SHR and RLF report are from the same UE and related to the same mobility event based on the same target C-RNTI reported and timesinceSHR and timesinceFailure in the SHR and HO report (which contains target C-RNTI and timesinceFailure extracted from RLF report in LTE format) (see 3GPP TS 38.423), respectively are pointing to some point in time when the mobility event happened with some tolerance configured by vendor.

[0115] c) Each measurement is an integer value, and may be indicated as follow: HO. InterSys. AlmostTooEarly; HO. InterSys. AlmostTooLate; HO. InterSys. NearFailureRLF

[0116] d) These are valid for packet switched traffic.

[0117] e) One usage of this measurement is to support MRO (see TS 28.313

[0030] ).

[0118] Turning to FIG. 9, this figure shows a block diagram of one possible and nonlimiting example of a cellular network 1 that is connected to a user equipment (UE) 10. Anumber of network elements are shown in the cellular network of FIG. 9: multiple gNBs 70; and a core network 90.

[0119] In FIG. 9, a user equipment (UE) 10 is in wireless communication via radio link 11-1 with the gNB 70-1 and via radio link 11-2 with the gNB (or ng-eNB) 70-2 of the cellular network 1. A UE 10 is a wireless communication device, such as a mobile device, that is configured to access a cellular network. The UE 10 is illustrated with one or more antennas 28. The ellipses 2 indicate there could be multiple UEs 10 in wireless communication via radio links with the base station 70. The UE 10 includes one or more processors 13, one or more memories 15, and other circuitry 16. The other circuitry 16 includes one or more receivers (Rx(s)) 17 and one or more transmitters (Tx(s)) 18. A program 12 is used to cause the UE 10 to perform the operations described herein. For a UE 10, the other circuitry 16 could include circuitry such as for user interface elements (not shown) like a display. The program 12 may be implemented via instructions stored in memory / memories 15 and executed by processor(s) 13, or by circuitry such being implemented as part of the processor(s) or other circuitry elements, or both.

[0120] The gNBs 70-1 and 70-2, as network elements of the cellular network 1, provide the UE 10 access to cellular network 1 and to the data network 91 via the core network 90 (e.g., via a user plane function (UPF) of the core network 90). As such, a gNB (or ng-eNB) 70 may be considered to be an access node, which provides access by UE(s) 10 to the cellular network 1. This example describes circuitry in the gNB 70-1, and it is assumed circuitry in the other gNBs or ng-eNBs would be similar. Only one gNB or ng-eNB 770-2 is shown, but there could be multiple such base stations.

[0121] The gNB 70-1 is illustrated as having one or more antennas 58. In general, the gNB 70-1 may be referred to as RAN node 70, although many will make reference to this as a gNB (gNode B, a base station for NR, new radio) instead, and also there are ng-eNB variants too. There are, however, many other examples of RAN nodes including the ng-eNB (evolved Node B) as illustrated herein or a TRP (Transmission-Reception Point). The gNB 70-1 includes one or more processors 73, one or more memories 75, and other circuitry 76. The other circuitry 76 includes one or more receivers (Rx(s)) 77 and one or more transmitters (Tx(s)) 78. A program 72 is used to cause the gNB 70-1 to perform the operations described herein. The program 72 may be implemented via instructions stored in memory / memories 75 and executed byprocessor(s) 73, or by circuitry such being implemented as part of the processor(s) or other circuitry elements, or both.

[0122] It is noted that the gNB 70-1 may instead be implemented via other wireless technologies, such as Wi-Fi (a wireless networking protocol that devices use to communicate without direct cable connections). In the case of Wi-Fi, the link(s) 11 could be characterized as a wireless link.

[0123] Two or more gNBs 70 communicate using, e.g., link(s) 79. The link(s) 79 may be wired or wireless or both and may implement, e.g., an Xn interface for 5G (fifth generation), an X2 interface for LTE (Long Term Evolution), or other suitable interface for other standards.

[0124] The cellular network 1 may include a core network 90, as a second network element or elements, that may include core network functionality, and which provide connectivity via a link or links 81 with a data network 91, such as a telephone network and / or a data communications network (e.g., the Internet). The core network 90 includes one or more processors 93, one or more memories 95, and other circuitry 96. The other circuitry 96 includes one or more receivers (Rx(s)) 97 and one or more transmitters (Tx(s)) 98. A program 92 is used to cause the core network 90 to perform the operations described herein. The program 92 may be implemented via instructions stored in memory / memories 95 and executed by processor(s) 93, or by circuitry such being implemented as part of the processor(s) or other circuitry elements, or both.

[0125] The core network 90 could be a 5GC (5G core network). The core network 90 can implement or comprise multiple network functions (NF(s)) 99, and the program 92 may comprise one or more of the NFs 99. A 5G core network may use circuitry such as memory and processors, which may implement a virtualization layer. It could be a single standalone computing system, a distributed computing system, or a cloud computing system. The NFs 99, as network elements, of the core network could be containers or virtual machines running on the circuitry of the computing system(s) making up the core network 90.

[0126] Core network functionality for 5G may include access and mobility management functionality that is provided by a network function 99 such as an access and mobility management function (AMF), session management functionality that is provided by a network function such as a session management function (SMF). Core network functionality foraccess and mobility management in an LTE (Long Term Evolution) network may be provided by an MME (Mobility Management Entity) and / or SGW (Serving Gateway) functionality, which routes data to the data network. Many others are possible, as illustrated by the examples in FIG. 9: AMF; SMF; MME; SGW; GMLC (Gateway Mobile Location Center); LMF (Location Management Function); UDM (Unified Data Management) / UDR (Unified Data Repository); NRF (Network Repository Function); and / or E-SMLC (Evolved Serving Mobile Location Center). These are merely exemplary core network functionality that may be provided by the core network 90, and note that both 5G and LTE core network functionality might be provided by the core network 90. The gNBs 70 are coupled via a backhaul link 31 to the core network 90. The gNBs 70 and the core network 90 may include an NG (Next Generation) interface for 5G, or an SI interface for LTE, or other suitable interface for other radio access technologies for communicating via the backhaul link 31.

[0127] In the data network 91, there are instructions 94 stored in a computer-readable storage medium 4-1, which could be circuitry such as long-term memory such as a hard drive or a solid-state drive, a short-term memory such as dynamic random-access memory, or a combination of both (e.g., reading from long-term memory for temporary placement into shortterm memory and subsequent downloading). The computer-readable medium 4-1 contains instructions 94 that, when downloaded and installed into the programs 12, 72, and 92 and / or memories 15, 75, or 95 of the corresponding UE 10, gNB (or ng-eNB) 70, and / or core network element(s) 90, and executed by processor(s) 13, 73, or 93, cause the respective device to perform corresponding actions described herein. The computer-readable storage medium 4 may be implemented in other forms, such as via instructions 94 on a compact disc (as a computer- readable storage medium 4-2) or a memory stick.

[0128] The programs 12, 72, and 92 contain instructions (as part of a corresponding program 12, 72, and 92) stored by corresponding one or more memories 15, 75, or 95. These instructions, when executed by the corresponding one or more processors 13, 73, or 93, cause the corresponding apparatus 10, 70, or 90, to perform the operations described herein. The computer readable memories 15, 75, or 95 are circuitry and may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, flash memory, firmware, magnetic memory devicesand systems, optical memory devices and systems, fixed memory and removable memory. The processors 13, 73, and 93, are circuitry and may be of any type suitable to the local technical environment. For example, these processors may include one or more of general-purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), processors based on a multi-core processor architecture, and may also include specialized circuits such as field-programmable gate arrays (FPGAs), application specific circuits (ASICs), signal processing devices and other devices, or combinations of these devices, as non-limiting examples. The processors 13, 73, and 93 are circuitry that can be programmed to perform functions via software, firmware or the like (including microcode), but are not solely software.

[0129] The receivers 17, 77, and 97, and the transmitters 18, 78, and 98 may implement wired or wireless interfaces. The receivers and transmitters may be grouped together as transceivers.

[0130] The cellular network 1 may implement network virtualization, which is the process of combining circuitry and software network resources and network functionality into a single, software-based administrative entity, a virtual network. Network virtualization involves platform virtualization, often combined with resource virtualization. Network virtualization is categorized as either external, combining many networks, or parts of networks, into a virtual unit, or internal, providing network-like functionality to software containers on a single system. Note that the virtualized entities (such as network functions 99) that result from the network virtualization are still implemented, at some level, using circuitry such as processors 73 and / or 93 and memories 75 and / or 95, and also such virtualized entities create technical effects.

[0131] It is noted that a common way to view “cells” in a cellular system is as a 360- degree oval. However, antennas typically do not radiate over 360 degrees, and therefore a common technique is to have the 360 degrees subdivided into multiple sections. That is, there can be multiple cells per base station. For instance, there could be three cells for a single carrier frequency and associated bandwidth, each cell covering one-third of a 360-degree area so that the single base station’s coverage area covers an approximate oval. Furthermore, each cell can correspond to a single carrier and a base station may use multiple carriers. So, if there are three 120-degree cells per carrier and two carriers, then the base station has a total of six cells. Whilethe description herein may indicate that “cells” perform functions, it should be apparent that the base station that forms the cell will perform the functions.

[0132] In general, the various embodiments of the user equipment 10 can include, but are not limited to, devices implementing cellular technologies (such as smart phones, mobile phones, cellular phones, voice over Internet Protocol (IP) (VoIP) phones, and / or wireless local loop phones), tablets, portable computers, vehicles or vehicle-mounted devices for, e.g., wireless V2X (vehicle-to-everything) communication, image capture devices such as digital cameras, gaming devices, music storage and playback appliances, Internet appliances (including Internet of Things, loT, devices), loT devices with sensors and / or actuators for, e.g., automation applications, as well as portable units or terminals that incorporate combinations of such functions, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), Universal Serial Bus (USB) dongles, smart devices, wireless customer-premises equipment (CPE), an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. That is, the UE 10 could be any end device that may be capable of wireless communication. By way of example rather than limitation, the UE may also be referred to as a communication device, terminal device (MT), a Subscriber Station (SS), a Portable Subscriber Station, a Mobile Station (MS), or an Access Terminal (AT).

[0133] Additional examples are as follows.

[0134] Example 1. A method, comprising: receiving, at a first cell, information indicating that a user equipment has had a handover from the first cell to a second cell that was successful and including a cause indicating a near failure event associated with the handover; determining, by the first cell based at least on the cause, a measurement to accumulate; and accumulating by the first cell a number of near failure events for the cause by incrementing the determined measurement.

[0135] Example 2. The method according to example 1, wherein the cause comprises a cause related to timer T304 and the near failure event comprises an "almost too early handover".

[0136] Example 3. The method according to example 1 or 2, wherein the cause related to timer T304 comprises that the user equipment shall generate a successful handover report upon successfully completing the handover but, while accessing to the target cell, the time T304 was running and the elapsed time of the timer T304 reached a value greater than a threshold.

[0137] Example 4. The method according to example 3, wherein the threshold for timer T304 is a threshold configured by an operator.

[0138] Example 5. The method according to example 1, wherein the cause comprises a cause related to timer T310 or timer T312 and the near failure event comprises an "almost too late handover".

[0139] Example 6. The method according to example 1 or 3, wherein the cause related to timer T310 or timer T312 comprises that the user equipment shall generate a successful handover report upon successfully completing the handover to the target cell while, during the execution of the handover, the T310 or T312 was running in the source cell and the elapsed time of the timer T310 or T312 reached a value greater than a threshold.

[0140] Example 7. The method according to example 6, wherein the threshold for timer T310 or timer T312 is a threshold configured by operator.

[0141] Example 8. The method according to example 1, wherein the cause comprises a cause related to timer T304 or timer T312 or timer T310, the user equipment declared a radio link failure within a certain time period after the handover, the handover was an intra-system handover, and the near failure event comprises a "near failure event followed with RLF report".

[0142] Example 9. The method according to example 1, wherein the cause comprises a cause related to timer T312 or timer T310, the user equipment declared a radio link failure within a certain time period after the handover, the handover was an inter-system handover, and the near failure event comprises a "near failure event followed with RLF report".

[0143] Example 10. The method according to example 8 or 9, wherein the certain time period is defined by a T_UE Context store timer.

[0144] Example 11. The method according to any of examples 1 to 8 or 10, wherein there are multiple measurements to accumulate and wherein the multiple measurements are for intra-system handovers.

[0145] Example 12. The method according to example 11, wherein there are three causes for the intra-system handovers and a corresponding three measurements to accumulate, and determining the measurement to accumulate comprises determining, by the first cell based at least on the cause, the measurement that corresponds to one of the three causes for the intra- system handovers to accumulate.

[0146] Example 13. The method according to any of examples 1 to 7, 9, or 10, wherein there are multiple measurements to accumulate and wherein the multiple measurements are for inter-system handovers.

[0147] Example 14. The method according to example 13, wherein there are three causes for the inter-system handovers and a corresponding three measurements to accumulate, and determining the measurement to accumulate comprises determining, by the first cell based at least on the cause, the measurement that corresponds to one of the three causes for the intersystem handovers to accumulate.

[0148] Example 15. The method according to any of examples 1 to 14, wherein the receiving, determining, and accumulating are performed for multiple pairs of cells, and at least one or both of the first cell or second cell are different between the multiple pairs of cells.

[0149] Example 16. An apparatus, comprising means for: receiving, at a first cell, information indicating that a user equipment has had a handover from the first cell to a second cell that was successful and including a cause indicating a near failure event associated with the handover; determining, by the first cell based at least on the cause, a measurement to accumulate; and accumulating by the first cell a number of near failure events for the cause by incrementing the determined measurement.

[0150] Example 17. The apparatus according to example 16, wherein the cause comprises a cause related to timer T304 and the near failure event comprises an "almost too early handover"

[0151] Example 18. The apparatus according to example 16 or 17, wherein the cause related to timer T304 comprises that the user equipment shall generate a successful handoverreport upon successfully completing the handover but, while accessing to the target cell, the time T304 was running and the elapsed time of the timer T304 reached a value greater than a threshold.

[0152] Example 19. The apparatus according to example 18, wherein the threshold for timer T304 is a threshold configured by an operator.

[0153] Example 20. The apparatus according to example 16, wherein the cause comprises a cause related to timer T310 or timer T312 and the near failure event comprises an "almost too late handover".

[0154] Example 21. The apparatus according to example 16 or 18, wherein the cause related to timer T310 or timer T312 comprises that the user equipment shall generate a successful handover report upon successfully completing the handover to the target cell while, during the execution of the handover, the T310 or T312 was running in the source cell and the elapsed time of the timer T310 or T312 reached a value greater than a threshold.

[0155] Example 22. The apparatus according to example 21, wherein the threshold for timer T310 or timer T312 is a threshold configured by operator.

[0156] Example 23. The apparatus according to example 16, wherein the cause comprises a cause related to timer T304 or timer T312 or timer T310, the user equipment declared a radio link failure within a certain time period after the handover, the handover was an intra-system handover, and the near failure event comprises a "near failure event followed with RLF report".

[0157] Example 24. The apparatus according to example 16, wherein the cause comprises a cause related to timer T312 or timer T310, the user equipment declared a radio link failure within a certain time period after the handover, the handover was an inter-system handover, and the near failure event comprises a "near failure event followed with RLF report".

[0158] Example 25. The apparatus according to example 23 or 24, wherein the certain time period is defined by a T_UE Context store timer.

[0159] Example 26. The apparatus according to any of examples 16 to 23 or 25, wherein there are multiple measurements to accumulate and wherein the multiple measurements are for intra-system handovers.

[0160] Example 27. The apparatus according to example 26, wherein there are three causes for the intra-system handovers and a corresponding three measurements to accumulate, and determining the measurement to accumulate comprises determining, by the first cell based at least on the cause, the measurement that corresponds to one of the three causes for the intra- system handovers to accumulate.

[0161] Example 28. The apparatus according to any of examples 16 to 22, 24, or 25, wherein there are multiple measurements to accumulate and wherein the multiple measurements are for inter-system handovers.

[0162] Example 29. The apparatus according to example 28, wherein there are three causes for the inter-system handovers and a corresponding three measurements to accumulate, and determining the measurement to accumulate comprises determining, by the first cell based at least on the cause, the measurement that corresponds to one of the three causes for the intersystem handovers to accumulate.

[0163] Example 30. The apparatus according to any of examples 16 to 29, wherein the receiving, determining, and accumulating are performed for multiple pairs of cells, and at least one or both of the first cell or second cell are different between the multiple pairs of cells.

[0164] Example 31. An apparatus, comprising: one or more processors; and one or more memories storing instructions that, when executed by the one or more processors, cause the apparatus at least to perform: receiving, at a first cell, information indicating that a user equipment has had a handover from the first cell to a second cell that was successful and including a cause indicating a near failure event associated with the handover; determining, by the first cell based at least on the cause, a measurement to accumulate; and accumulating by the first cell a number of near failure events for the cause by incrementing the determined measurement.

[0165] Example 32. The apparatus according to example 31, wherein the cause comprises a cause related to timer T304 and the near failure event comprises an "almost too early handover"

[0166] Example 33. The apparatus according to example 31 or 32, wherein the cause related to timer T304 comprises that the user equipment shall generate a successful handover report upon successfully completing the handover but, while accessing to the target cell, the timeT304 was running and the elapsed time of the timer T304 reached a value greater than a threshold.

[0167] Example 34. The apparatus according to example 33, wherein the threshold for timer T304 is a threshold configured by an operator.

[0168] Example 35. The apparatus according to example 31, wherein the cause comprises a cause related to timer T310 or timer T312 and the near failure event comprises an "almost too late handover".

[0169] Example 36. The apparatus according to example 31 or 33, wherein the cause related to timer T310 or timer T312 comprises that the user equipment shall generate a successful handover report upon successfully completing the handover to the target cell while, during the execution of the handover, the T310 or T312 was running in the source cell and the elapsed time of the timer T310 or T312 reached a value greater than a threshold.

[0170] Example 37. The apparatus according to example 36, wherein the threshold for timer T310 or timer T312 is a threshold configured by operator.

[0171] Example 38. The apparatus according to example 31, wherein the cause comprises a cause related to timer T304 or timer T312 or timer T310, the user equipment declared a radio link failure within a certain time period after the handover, the handover was an intra-system handover, and the near failure event comprises a "near failure event followed with RLF report".

[0172] Example 39. The apparatus according to example 31, wherein the cause comprises a cause related to timer T312 or timer T310, the user equipment declared a radio link failure within a certain time period after the handover, the handover was an inter-system handover, and the near failure event comprises a "near failure event followed with RLF report".

[0173] Example 40. The apparatus according to example 38 or 39, wherein the certain time period is defined by a T_UE Context store timer.

[0174] Example 41. The apparatus according to any of examples 31 to 38 or 40, wherein there are multiple measurements to accumulate and wherein the multiple measurements are for intra-system handovers.

[0175] Example 42. The apparatus according to example 11, wherein there are three causes for the intra-system handovers and a corresponding three measurements to accumulate,and determining the measurement to accumulate comprises determining, by the first cell based at least on the cause, the measurement that corresponds to one of the three causes for the intrasystem handovers to accumulate.

[0176] Example 43. The apparatus according to any of examples 31 to 37, 39, or 40, wherein there are multiple measurements to accumulate and wherein the multiple measurements are for inter-system handovers.

[0177] Example 44. The apparatus according to example 43, wherein there are three causes for the inter-system handovers and a corresponding three measurements to accumulate, and determining the measurement to accumulate comprises determining, by the first cell based at least on the cause, the measurement that corresponds to one of the three causes for the intersystem handovers to accumulate.

[0178] Example 45. The apparatus according to any of examples 31 to 44, wherein the receiving, determining, and accumulating are performed for multiple pairs of cells, and at least one or both of the first cell or second cell are different between the multiple pairs of cells.

[0179] Example 46. A computer program, comprising instructions which, when the program is executed by an apparatus, cause the apparatus to carry out the methods of any of examples 1 to 15.

[0180] Example 47. The computer program according to example 46, wherein the computer program is a computer program product comprising a computer-readable medium bearing the instructions embodied therein for use with the apparatus.

[0181] Example 48. The computer program according to example 46, wherein the computer program is directly loadable into an internal memory of the apparatus.

[0182] As used in this application, the term “circuitry” may refer to one or more or all of the following:

[0183] (a) hardware-only circuit implementations (such as implementations in analog, digital, and / or quantum circuitry) and

[0184] (b) combinations of hardware circuits and software such as (as applicable): (i) a combination of analog, digital, and / or quantum hardware circuit(s) with software / firmware and (ii) any or all portions of hardware processor(s) (including digital and / or quantum processor(s))with software, and memory(ies) that work together to cause an apparatus, such as a mobile device, computing device, or server, to perform various functions) and

[0185] (c) any or all portions of hardware circuit(s), such as microprocessor(s), processor(s) and / or quantum processors, that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

[0186] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0187] In an example embodiment, software (e.g., application logic, an instruction set) as used herein is maintained on any one of various conventional computer-readable media. In the context of this document, a “computer-readable medium” may be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer, with one example of a computer described and depicted, e.g., in FIG. 9. A computer-readable medium may comprise a computer-readable storage medium (e.g., memories 15, 75, and 95 or other device) that may be any media or means that can contain, store, and / or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer. A computer-readable storage medium does not comprise propagating signals, and therefore may be considered to be non-transitory. The term “non-transitory”, as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM, random access memory, versus ROM, readonly memory).

[0188] If desired, the different functions discussed herein may be performed in a different order and / or concurrently with each other. Furthermore, if desired, one or more of the above-described functions may be optional or may be combined.

[0189] Although various aspects of the invention are set out in the independent claims, other aspects of the invention comprise other combinations of features from the described embodiments and / or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims.

[0190] It is also noted herein that while the above describes example embodiments of the invention, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing from the scope of the present invention as defined in the appended claims.

[0191] The following abbreviations that may be found in the specification and / or the drawing figures are defined as follows:

[0192] 3GPP third generation partnership project

[0193] 4G fourth generation

[0194] 5G fifth generation

[0195] AMF access and mobility management function

[0196] C-RNTI Cell-Radio Network Temporary Identifier

[0197] DAPS Dual Active Protocol Stack

[0198] eNodeB evolved Node B

[0199] E-SMLC evolved serving mobile location center

[0200] E-UTRA Evolved Universal Terrestrial Radio Access

[0201] eNB (or eNodeB) evolved Node B (e.g., an LTE base station)

[0202] GMLC Gateway Mobile Location Center

[0203] gNB (or gNodeB) base station for 5G / NR

[0204] gNB-CU-CP gNB-Central unit-control plane

[0205] I / F interface

[0206] LMF Location Management Function

[0207] LIE long term evolution

[0208] MME mobility management entity

[0209] MRO Mobility Robustness Optimization

[0210] NF network function

[0211] ng or NG next generation

[0212] NR new radio

[0213] NRF Network Repository Function

[0214] N / W or NW network

[0215] PCell primary cell

[0216] RACH random access channel

[0217] RAN radio access network

[0218] RAT radio access technology

[0219] RLF radio link failure

[0220] RRC radio resource control

[0221] Rx receiver

[0222] SGW serving gateway

[0223] SHR Successful handover report

[0224] SMF session management function

[0225] synch synchronization

[0226] TAI tracking area identity

[0227] TRP transmission-reception point

[0228] Tx transmitter

[0229] UDM unified data management

[0230] UDR unified data repository

[0231] UE user equipment (e.g., a wireless, typically mobile device)

[0232] UPF user plane function

Claims

What is claimed is:

1. A method, comprising: receiving, at a first cell, information indicating that a user equipment has had a handover from the first cell to a second cell that was successful and including a cause indicating a near failure event associated with the handover; determining, by the first cell based at least on the cause, a measurement to accumulate; and accumulating by the first cell a number of near failure events for the cause by incrementing the determined measurement.

2. The method according to claim 1, wherein the cause comprises a cause related to timer T304 and the near failure event comprises an "almost too early handover".

3. The method according to claim 1, wherein the cause comprises a cause related to timer T310 or timer T312 and the near failure event comprises an "almost too late handover".

4. The method according to claim 1, wherein the cause comprises a cause related to timer T304 or timer T312 or timer T310, the user equipment declared a radio link failure within a certain time period after the handover, the handover was an intra-system handover, and the near failure event comprises a “near failure event followed with RLF report”.

5. The method according to claim 1, wherein the cause comprises a cause related to timer T312 or timer T310, the user equipment declared a radio link failure within a certain time period after the handover, the handover was an inter-system handover, and the near failure event comprises a “near failure event followed with RLF report”.Page 33 of 376. An apparatus, comprising means for: receiving, at a first cell, information indicating that a user equipment has had a handover from the first cell to a second cell that was successful and including a cause indicating a near failure event associated with the handover; determining, by the first cell based at least on the cause, a measurement to accumulate; and accumulating by the first cell a number of near failure events for the cause by incrementing the determined measurement.

7. The apparatus according to claim 6, wherein the cause comprises a cause related to timer T304 and the near failure event comprises an "almost too early handover"8. The apparatus according to claim 6 or 7, wherein the cause related to timer T304 comprises that the user equipment shall generate a successful handover report upon successfully completing the handover but, while accessing to the target cell, the time T304 was running and the elapsed time of the timer T304 reached a value greater than a threshold.

9. The apparatus according to claim 8, wherein the threshold for timer T304 is a threshold configured by an operator.

10. The apparatus according to claim 6, wherein the cause comprises a cause related to timer T310 or timer T312 and the near failure event comprises an "almost too late handover" .

11. The apparatus according to claim 6 or 8, wherein the cause related to timer T310 or timer T312 comprises that the user equipment shall generate a successful handover report upon successfully completing the handover to the target cell while, during the execution of the handover, the T310 or T312 was running in the source cell and the elapsed time of the timer T310 or T312 reached a value greater than a threshold.Page 34 of 3712. The apparatus according to claim 11 , wherein the threshold for timer T310 or timer T312 is a threshold configured by operator.

13. The apparatus according to claim 6, wherein the cause comprises a cause related to timer T304 or timer T312 or timer T310, the user equipment declared a radio link failure within a certain time period after the handover, the handover was an intra-system handover, and the near failure event comprises a “near failure event followed with RLF report”.

14. The apparatus according to claim 6, wherein the cause comprises a cause related to timer T312 or timer T310, the user equipment declared a radio link failure within a certain time period after the handover, the handover was an inter-system handover, and the near failure event comprises a “near failure event followed with RLF report”.

15. The apparatus according to claim 13 or 14, wherein the certain time period is defined by a T_UE Context store timer.

16. The apparatus according to any of claims 6 to 13 or 15, wherein there are multiple measurements to accumulate and wherein the multiple measurements are for intra-system handovers.

17. The apparatus according to claim 16, wherein there are three causes for the intra-system handovers and a corresponding three measurements to accumulate, and determining the measurement to accumulate comprises determining, by the first cell based at least on the cause, the measurement that corresponds to one of the three causes for the intra-system handovers to accumulate.

18. The apparatus according to any of claims 6 to 12, 14, or 15, wherein there are multiple measurements to accumulate and wherein the multiple measurements are for inter-system handovers.Page 35 of 3719. The apparatus according to claim 18, wherein there are three causes for the inter-system handovers and a corresponding three measurements to accumulate, and determining the measurement to accumulate comprises determining, by the first cell based at least on the cause, the measurement that corresponds to one of the three causes for the inter-system handovers to accumulate.

20. The apparatus according to any of claims 6 to 19, wherein the receiving, determining, and accumulating are performed for multiple pairs of cells, and at least one or both of the first cell or second cell are different between the multiple pairs of cells.Page 36 of 37

Images