Terminal device, network device, and method

Abstract

To provide a method and apparatus for supporting handover success reporting.SOLUTION: In a mobile communication system, a terminal device receives an instruction 215 from a first network device for providing a first cell, the instruction 215 executing a handover of the terminal device from the first cell to a second cell of a second network device, and determines 230 trigger information regarding handover success reporting of the handover based on a set of trigger conditions. The trigger information indicates whether or not handover success reporting is triggered for the handover. In this way, since handover success reporting can be arbitrarily triggered based on the set of trigger conditions, the terminal device is restricted to report handover success reporting only when necessary, thereby saving processing resources and communication resources for unnecessary handover success reporting.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] Embodiments of the present disclosure relate generally to the field of communications, and more specifically, to solutions for supporting handover success reports.

Background Art

[0002] 5G New Radio (NR) is a worldwide standard for a unified and higher-performance 5G radio air interface. 5G realizes a new type of network designed to connect almost all people and everything together, such as machines, things, devices, etc. In the 3rd Generation Partnership Project (3GPP (registered trademark): 3rd Generation Partnership Project) Release 17 (Rel-17) Work Item Description (WID: Work Item Description), Enhancement of data collection for Self-Optimizing Networks (SON) / Minimization of drive tests (MDT) in NR, the goals of the SON function are to support data collection for SON functions including Coverage and Capacity Optimization (CCO), inter-system radio access technology (RAT) energy saving, inter-system load balancing, two-step random access channel (RACH) optimization, mobility enhancement optimization, and the remaining parts of the Rel-16 SON / MDT Work Item (WI: Work Item) (such as successful handovers reports).

[0003] Regarding handover success reporting, the Mobility Robustness Optimization (MRO) feature in NR can be enhanced to provide more robust mobility by reporting failure events observed during a successful handover. A solution to this problem is to configure the user equipment (UE) to create a report associated with the success of the handover, including a set of measurements collected during the handover phase, such as measurements at the handover trigger, measurements at the end of the handover execution, or measurements after the handover execution. However, generating such a report every time a handover is successful would lead to unnecessary waste of resources. [Overview of the project] [Problems that the invention aims to solve]

[0004] Overall, embodiments of this disclosure provide solutions for supporting handover success reporting. [Means for solving the problem]

[0005] In a first embodiment, a method of communication is provided. This method includes a terminal device receiving an instruction from a first network device providing a first cell to perform a handover of the terminal device from the first cell to a second cell of a second network device. This method further includes determining trigger information relating to a handover success report for the handover based on a set of trigger conditions. The trigger information indicates whether the handover success report is triggered for the handover.

[0006] In a second embodiment, a communication method is provided. This method includes a network device transmitting configuration information to a terminal device indicating whether or not handover success reporting is supported for an inter-RAT handover of the terminal device from a first cell to a second cell. The first cell is provided by the network device based on a first RAT, and the second cell is based on a second RAT different from the first RAT.

[0007] In a third embodiment, a terminal device is provided, comprising a processor configured to perform the method according to the first embodiment.

[0008] In a fourth embodiment, a network device is provided, comprising a processor configured to perform the method according to the second embodiment.

[0009] In a fifth embodiment, a computer-readable medium having stored instructions is provided. When the instructions are executed on at least one processor of the device, the device is caused to perform the method according to the first embodiment.

[0010] In a sixth embodiment, a computer-readable medium having stored instructions is provided. When the instructions are executed on at least one processor of the device, the device is caused to perform the method according to the second embodiment.

[0011] It should be understood that the summary portion of the invention is not intended to identify any important or fundamental features of the embodiments of this disclosure, nor to limit the scope of this disclosure. Other features of this disclosure will be readily apparent from the following description. [Brief explanation of the drawing]

[0012] The drawings further illustrate some embodiments of this disclosure in more detail, thereby further clarifying the aforementioned and other objectives, features, and advantages of this disclosure.

[0013] [Figure 1A] It is a schematic diagram of a communication environment in which some embodiments of the present disclosure can be implemented.

[0014] [Figure 1B] It is a schematic diagram of another communication environment in which some embodiments of the present disclosure can be implemented.

[0015] [Figure 2] It is a diagram showing an exemplary communication process between a network device and a terminal device according to some embodiments of the present disclosure.

[0016] [Figure 3] It is a schematic diagram of yet another communication environment in which some embodiments of the present disclosure can be implemented.

[0017] [Figure 4] It is a schematic diagram showing some points in time and durations related to handover of a terminal device according to some embodiments of the present disclosure.

[0018] [Figure 5] It is a diagram showing another exemplary communication process between a network device and a terminal device according to some embodiments of the present disclosure.

[0019] [Figure 6] It is a diagram showing yet another exemplary communication process between a network device and a terminal device according to some embodiments of the present disclosure.

[0020] [Figure 7] It is a flowchart of an exemplary communication method according to some embodiments of the present disclosure.

[0021] [Figure 8] It is a flowchart of another exemplary communication method according to some embodiments of the present disclosure.

[0022] [Figure 9]Schematic block diagram of a device suitable for implementing some embodiments of the present disclosure.

[0023] In the figure, the same or similar reference numerals represent the same or similar elements.

Embodiments for Carrying Out the Invention

[0024] Here, the principles of the present disclosure will be described with reference to some embodiments. It should be understood that these embodiments are described for illustrative purposes only and are intended to assist those skilled in the art in understanding and implementing the present disclosure, and do not imply any limitation on the scope of the present disclosure. The disclosure described herein can be implemented in various ways different from the methods described below.

[0025] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0026] As used herein, the term "network device" or "base station" (BS) means a device capable of providing or hosting a cell or coverage in which a terminal device can perform communication. Examples of network devices include, but are not limited to, Node B (NodeB or NB), Evolved Node B (eNodeB or eNB), next generation Node B (gNB), infrastructure devices for V2X (Vehicle-to-Everything) communication, Transmission / Reception Point (TRP), Remote Radio Unit (RRU), Radio Head (RH), Remote Radio Head (RRH), femto nodes, pico nodes, and other low-power nodes.

[0027] As used herein, the term “terminal device” means any device having wireless or wired communication capabilities. Examples of terminal devices include, but are not limited to, user equipment (UE), personal computers, desktop computers, mobile phones, cellular phones, smartphones, personal digital assistants (PDAs), portable computers, tablets, wearable devices, Internet of Things (IoT) devices, Internet of Everything (IoE) devices, machine-type communication (MTC) devices, and in-vehicle devices for V2X communication, where the “X” in V2X represents pedestrians, vehicles or infrastructure / networks, or image acquisition devices such as digital cameras, game devices, music storage and playback devices, or internet-connected home appliances that enable wireless or wired internet access and browsing. For illustrative purposes, several embodiments will be described below with reference to UE as an example of a terminal device, and the terms “terminal device” and “user equipment” (UE) may be used interchangeably in the context of this disclosure.

[0028] In some embodiments, the terminal device may be connected to a first network device and a second network device. One of the first and second network devices may be a master node and the other a secondary node. The first and second network devices may use different radio access technologies (RATs). In some embodiments, the first network device may be a first RAT device, and the second network device may be a second RAT device. In some embodiments, the first RAT device is an eNB, and the second RAT device is a gNB. Information regarding the different RATs may be transmitted to the terminal device from at least one of the first and second network devices. In some embodiments, the first information may be transmitted from the first network device to the terminal device, and the second information may be transmitted from the second network device directly or via the first network device to the terminal device. In some embodiments, information regarding the configuration of the terminal device configured by the second network device may be transmitted from the second network device via the first network device. Information regarding the reconfiguration of a terminal device set by the second network device may be transmitted from the second network device directly to the terminal device or via the first network device.

[0029] As used herein, the term “circuit” may mean hardware circuitry and / or combinations of hardware circuitry and software. For example, a circuit may be a combination of analog and / or digital hardware circuitry and software / firmware. In yet another example, a circuit may be any part of a hardware processor having a digital signal processor, software and one or more memories, which work together to cause a device such as a terminal or network device to perform various functions. In yet another example, a circuit may be a hardware circuit and / or a processor such as a microprocessor or a part thereof that requires software / firmware for operation, but the software may not be present if it is not required for operation. As used herein, the term “circuit” may include hardware circuitry or one or more processors alone, or a part of hardware circuitry or one or more processors, and the implementation of its (or their) accompanying software and / or firmware.

[0030] As used herein, the terms “transmit / receive point,” “transmit / receive point,” or “transmit and receive point” may generally refer to a station communicating with user equipment. However, a transmit / receive point may be referred to by different terms, such as base station (BS), cell, node B, evolved node B (eNB), next-generation node B (gNB), transmit / receive point (TRP), sector, site, base transceiver system (BTS), access point (AP), relay node (RN), remote radio head (RRH), radio unit (RU), antenna, etc.

[0031] In other words, in the context of this disclosure, a transmit / receive point, base station (BS), or cell may be interpreted as a comprehensive concept indicating a portion of the area or function covered by a base station controller (BSC) in code division multiple access (CDMA), a Node-B in WCDMA®, an eNB or sector (site) in LTE, a gNB or TRP in NR, etc. Therefore, the concepts of transmit / receive point, base station (BS), and / or cell may include various coverage areas such as megacells, macrocells, microcells, picocells, and femtocells. Furthermore, this concept may include the communication range of a relay node (RN), remote radio head (RRH), or radio unit (RU).

[0032] In the context of this disclosure, user equipment and transmit / receive point may be two transmit / receive entities with a comprehensive meaning to embody the technologies and technical concepts disclosed herein, and may not be limited to specific terms or words. Furthermore, user equipment and transmit / receive point may be uplink or downlink transmit / receive entities with a comprehensive meaning to embody the technologies and technical concepts disclosed in connection with this disclosure, and may not be limited to specific terms or words. As used herein, uplink (UL) transmit / receive is a method of transmitting data from user equipment to a base station. Alternatively, downlink (DL) transmit / receive is a method of transmitting data from a base station to user equipment.

[0033] As used herein, the terms “resource,” “transmit resource,” “resource block,” “physical resource block,” “uplink resource,” or “downlink resource” may refer to any resource for performing communication, such as communication between a terminal device and a network device, including resources in the time domain, resources in the frequency domain, resources in the spatial domain, resources in the code domain, or any other resources that enable communication. Hereinafter, resources in both the frequency domain and the time domain are used as examples of transmit resources to illustrate some embodiments of the present disclosure. It should be noted that embodiments of the present disclosure are similarly applicable to other resources in other domains.

[0034] As used herein, the singular "one" and "the foregoing" also include the plural unless explicitly indicated in the context. The term "including" and its variations should be understood as an open term meaning "including, but not limited to." The term "based on" should be understood as "at least partially based on." The terms "one embodiment" and "embodiment" should be understood as "at least one embodiment." The term "another embodiment" should be understood as "at least one other embodiment." Terms such as "first," "second," etc., may refer to different or identical subjects. The following may include other explicit and implicit definitions.

[0035] In some examples, values, procedures, or devices are referred to as “best,” “worst,” “highest,” “minimum,” “maximum,” etc. Such descriptions are intended to show that a choice can be made from among many used functional alternatives, and it should be understood that such a choice does not need to be better, smaller, higher, or otherwise more desirable than other choices.

[0036] As mentioned above, in the 3GPP Rel-17 WID extension for data acquisition for SON / MDT in NR, one of the purposes of the SON function is to report successful handovers. A successful handover report, as a whole, is a report of a successful handover of a terminal device from a source cell to a target cell. Specifically, a successful handover report is generated by the terminal device that performed the successful handover, sent by the terminal device to the target network device in the target cell or to a subsequent network device serving the terminal device (if the target network device does not receive a successful handover report), and finally, can be retrieved by the source network device in the source cell from the target network device or the subsequent network device.

[0037] Based on the handover success report provided by the terminal device, the source network device and / or target network device can further optimize future handover procedures initiated at the source cell or targeting the target cell, even if a previous handover performed by the reporting terminal device was successful. This can further improve the performance of future handovers. For example, upon receiving a handover success report, the receiving network device (e.g., the source network device or target network device) can analyze whether its mobility settings require adjustment. Such adjustments may result in changes to mobility settings, such as changes to radio link monitoring (RLM) settings or changes to mobility thresholds between the source and target network devices. Additionally, the target network device can further optimize dedicated RACH beam resources based on beam measurements reported when the handover is successful.

[0038] However, conventional solutions for handover success reporting do not specify various details of handover success reporting, and these need to be clarified. For example, it may be unnecessary to generate such a handover success report every time a handover is successful. Therefore, it may be desirable to be able to optionally or selectively generate handover success reports for successful handovers that require improvement. In fact, the specific mechanisms to support handover success reporting are not clear and need to be specified. Furthermore, it is unclear how to configure handover success reporting precisely, and it should be noted that conventional solutions for handover success reporting do not take into account the new features introduced by Rel-16.

[0039] To address the aforementioned technical problems and other potential technical problems in conventional solutions, embodiments of the present disclosure provide solutions that support handover success reporting. In some embodiments, a terminal device receives instructions from a first network device providing a first cell. These instructions indicate that the terminal device will perform a handover from the first cell to a second cell of a second network device. The terminal device then determines trigger information for a handover success report of the handover based on a set of trigger conditions. The trigger information indicates whether the handover success report is triggered for the handover.

[0040] According to embodiments of the present disclosure, a terminal device can be configured with a set of trigger conditions for optionally generating a handover success report for a handover, and so a handover success report can be triggered only when one or more of the set of trigger conditions are met. This allows the terminal device to be limited to reporting relevant handover success conditions, such as potential problems detected by RLM, beam failure detection (BFD), etc., before or during a successful handover event. In other words, since a handover success report can be optionally triggered based on the set of trigger conditions, the terminal device can be limited to reporting a handover success report only when necessary, saving processing and communication resources for unnecessary handover success reports. The principles and embodiments of the present disclosure are described in detail below.

[0041] Figure 1A is a schematic diagram of a communication environment 100 in which several embodiments of the present disclosure can be implemented. As shown in Figure 1A, the communication environment 100 (which may be referred to as a communication network 100 or a communication system 100) includes a network device 110 serving terminal devices 120 located in a cell 115 provided by the network device 110. Specifically, the terminal devices 120 can communicate with the network device 110 within the cell 115 via a communication link 145. The communication link 145 may be referred to as a downlink when transmitting from the network device 110 to the terminal devices 120, and instead as an uplink when transmitting from the terminal devices 120 to the network device 110.

[0042] In the exemplary scenario shown in Figure 1A, due to the mobility of terminal device 120, terminal device 120 may leave cell 115 of network device 110 and enter cell 135 of network device 130. In this case, the quality of link 145 from terminal device 120 to cell 115 may be degraded, and as a result, the communication quality of terminal device 120 may also be degraded. To provide terminal device 120 with better communication quality, network device 110 may cause terminal device 120 to perform a handover from cell 115 to cell 135. During the handover, terminal device 120 may release link 145 to cell 115 and instead establish link 165 to cell 135. In the case of a handover from cell 115 to cell 135, cell 115 may be called the source cell, network device 110 may be called the source network device, cell 135 may be called the target cell, and network device 130 may be called the target network device.

[0043] More specifically, the handover may be performed by the terminal device 120 in connected mode, while the terminal device 120 is active. The handover may be controlled by the source network device 110 and assisted by the terminal device 120. Prior to the handover, the terminal device 120 may send one or more measurement reports to the source network device 110 indicating that the link 145 to the source cell 115 is degraded and / or that the target cell 135 is better than the source cell 115. Based on these measurement reports, the network device 110 may move the terminal device 120's connection from the source cell 115 to the target cell 135 (i.e., handover), resulting in the terminal device 120 obtaining better wireless conditions and therefore a better user experience.

[0044] During the handover of the terminal device 120 from source cell 115 to target cell 135, source network device 110 can communicate information necessary to facilitate the handover with target network device 130 via communication link 155 (e.g., the Xn interface between the two network devices). Additionally, while the handover of terminal device 120 from source cell 115 to target cell 135 is attributed to the movement of terminal device 120, embodiments of this disclosure are not limited thereto and should be understood to be applicable to handovers caused by a variety of possible causes.

[0045] In some embodiments, terminal device 120 can generate a handover success report if the handover from source cell 115 to target cell 135 is successful. The availability of the handover success report may be indicated by a message (e.g., a handover completion message such as RRCReconfigurationComplete) sent from terminal device 120 to target network device 130 via the radio resource control (RRC) layer. Target network device 130 may retrieve information in the handover success report via a UE Information Request and Response mechanism. Additionally, target network device 130 may then forward the handover success report to source network device 110 to indicate any failures experienced during the successful handover event.

[0046] Based on the handover success report provided by terminal device 120, even if a previous handover performed by the reporting terminal device 120 was successful, source network device 110 and / or target network device 130 may further improve future handover procedures initiated at source cell 115 or targeting target cell 135. For example, upon receiving a handover success report, source network device 110 and / or target network device 130 may analyze whether their mobility settings require adjustment. Such adjustments may involve changes to RLM settings, changes to mobility thresholds between source and target, etc.

[0047] In some embodiments, since the primary purpose of a handover success report is to help network devices improve future handovers related to source and target network devices, terminal devices may not need to generate a handover success report every time a handover is successful. Alternatively, it may be desirable for terminal devices to selectively or optionally generate handover success reports for handovers that may require improvement. For this purpose, as shown in Figure 1A, terminal device 120 can be configured with a set of trigger conditions 125 to trigger a handover success report. Thus, a handover success report can be triggered only when one or more of the set of conditions 125 are met. This limits terminal device 120 to reporting handover success reports only when necessary, thus saving processing and communication resources for unnecessary handover success reports.

[0048] Furthermore, the handover of terminal device 120 from cell 115 to cell 135 as described above with reference to Figure 1A can be referred to as an inter-network-device handover, where source cell 115 and target cell 135 are provided by different network devices 110 and 130. However, it should be understood that, in addition to such inter-network-device handovers, the embodiments of this disclosure are also applicable to intra-network-device handovers, where source cell 115 and target cell 135 can be provided by the same network device. An example of such an intra-network-device handover will be described below with reference to Figure 1B.

[0049] Figure 1B is a schematic diagram of another communication environment 105 in which several embodiments of the present disclosure can be implemented. Similar to the exemplary scenario in Figure 1A, the network device 110 in the exemplary scenario shown in Figure 1B also provides a cell 115, and the terminal device 120 may have a communication link 145 to the cell 115. Similar to the exemplary scenario in Figure 1A, the terminal device 120 in the exemplary scenario shown in Figure 1B may also perform a handover from cell 115 to cell 135, for example, due to the terminal device moving to cell 135. The handover may cause the terminal device 120 to release the link 145 to the source cell 115 and instead establish a link 165 to the target cell 135. Unlike the exemplary scenario in Figure 1A, the target cell 135 in the exemplary scenario shown in Figure 1B may be provided by the same network device 110 that provides the source cell 115, and therefore the handover in Figure 1B may be referred to as an intra-network device handover.

[0050] The procedure for an intra-network device handover performed by the terminal device 120 in Figure 1B may be substantially the same as the inter-network device handover described above with reference to Figure 1A, except that it does not require communication between the two network devices to facilitate the handover. Similar to the exemplary scenario in Figure 1A, the terminal device 120 may also be configured with a set of trigger conditions 125 that generate a handover success report for the intra-network device handover in Figure 1B. Thus, the handover success report can be triggered only when one or more of the set of conditions 125 are met. This limits the terminal device 120 to reporting a handover success report only when necessary, thereby saving processing and communication resources for unnecessary handover success reports. In the following description, several embodiments will be described in more detail in relation to the exemplary scenario of the inter-network device handover shown in Figure 1A. However, it should be understood that all embodiments can also be applied to intra-network device handovers such as the one shown in Figure 1B, if applicable.

[0051] It should be understood that the number of terminal devices, network devices, cells, and communication links shown in Figures 1A and 1B are for illustrative purposes only and do not imply any limitation. The communication environment 100 or 105 may include any suitable number of terminal devices, any suitable number of network devices, any suitable number of other communication devices, any suitable number of cells, and any suitable number of communication links adapted to carry out embodiments of the present disclosure.

[0052] Furthermore, it should be understood that various wireless and wired communications may exist between all the communication devices in Figures 1A and 1B, if necessary. Note that in Figures 1A and 1B, network devices 110 and 130 are schematically depicted as base stations, and terminal device 120 is schematically depicted as a mobile phone; however, these descriptions are merely examples and do not imply any limitations. In other embodiments, network devices 110 and 130 may be any other wireless network devices, and terminal device 120 may be any other wireless communication device.

[0053] Communications in communication environments 100 or 105 may comply with any appropriate standard, including but not limited to, the Global System for Mobile Communications (GSM), Extended Coverage Global System for Mobile Internet of Things (EC-GSM-IoT), Long-Term Evolution (LTE), LTE-Evolution, LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access (CDMA), and GSM Edge Radio Access Network (GERAN). Furthermore, communications may be performed in accordance with any generation of communication protocol currently known or to be developed in the future. Examples of communication protocols include, but are not limited to, first-generation (1G), second-generation (2G), 2.5G, 2.75G, third-generation (3G), fourth-generation (4G), 4.5G, and fifth-generation (5G) communication protocols.

[0054] Figure 2 shows an exemplary communication process 200 between a network device 110 and a terminal device 120 according to some embodiments of the present disclosure. For illustrative purposes, the communication process 200 will be described with reference to Figure 1A. However, it should be understood that the communication process 200 can be similarly applied to any other communication scenario in which two communication terminals communicate with each other.

[0055] As shown in Figure 2, if the network device 110 determines that it is necessary to perform a handover of terminal device 120 from cell 115 to cell 135, it sends an indication 215 to terminal device 120 (210). The indication 215 may indicate that the handover from cell 115 to cell 135 will be performed by terminal device 120. Upon receiving the indication 215 from the network device 110 (220), terminal device 120 determines trigger information based on the set of conditions 125 (230). The trigger information indicates whether or not a handover success report will be triggered for the handover.

[0056] In other words, based on the set of trigger conditions 125, the terminal device 120 can decide whether or not to generate a handover success report for the handover indicated by instruction 215. For example, if one or more of the set of trigger conditions 125 are met before or during the handover, the terminal device 120 may decide to generate a handover success report for the handover. On the other hand, if none of the set of trigger conditions 125 are met before or during the handover, the terminal device 120 may instead decide not to generate a handover success report for the handover.

[0057] Overall, the set of trigger conditions 125 may include any suitable trigger conditions that suggest a successful but incomplete handover that may require improvement. For example, the set of trigger conditions 125 may include detection of a radio problem to the source cell before the handover trigger, detection of a RACH delay during the handover procedure, reaching a quality change threshold, reaching an absolute quality threshold at the main measurement moment, initiation of a handover while timers T310 / T312 as defined in the relevant 3GPP specification are operating, and execution of RRCReconfiguration. In some embodiments, it is desirable that the set of trigger conditions 125 be more comprehensive and broad so that the source network device 110 and / or target network device 130 of the handover can obtain more useful information for improving future handovers. For example, one or more of the set of trigger conditions 125 may be designed to take into account various new features introduced by Rel-16.

[0058] As an example of such a wide range of trigger conditions, the set of trigger conditions 125 may include a first type of trigger condition related to a listen-before-talk (LBT) process performed by the terminal device 120. In unlicensed spectrum New Radio (NR-U), channel access in both downlink and uplink depends on the LBT function. For example, referring to Figure 1A, if the communication system 100 is implemented in NR-U, the network device 110 or terminal device 120 must first "sense" the communication channel to know that there is no communication on the communication channel before any transmissions on the communication channel. If the communication channel is a broadband unlicensed carrier (e.g., several hundred MHz), the "channel sensing" procedure may depend on detecting energy levels in several sub-bands of the communication channel. LBT parameters (e.g., type / duration, empty channel determination parameter, etc.) can be set by the network device 110 in the terminal device 120.

[0059] Regarding the LBT process, the relevant 3GPP specification defines LBT failure and persistent LBT failure as follows: If an LBT failure indication has already been received from a lower layer, the lbt-FailureDetectionTimer may be started or restarted and LBT_COUNTER may be incremented by 1. If LBT_COUNTER is greater than or equal to lbt-FailureInstanceMaxCount, a persistent LBT failure is triggered for the active UL BWP in the serving cell. If the serving cell is a SpCell, and a persistent LBT failure has been triggered for all UL BWPs configured with a PRACH occasion on the same carrier in the serving cell, a persistent LBT failure may be indicated to the upper layer. If the serving cell is not a SpCell, any ongoing random access procedure in the serving cell may be stopped, and the active UL BWP may be switched to an UL BWP on the same carrier in the serving cell that is configured with a PRACH occasion and has not yet triggered a persistent LBT failure, and the random access procedure may be started. Furthermore, if a continuous LBT failure is triggered in SpCell and is not canceled, and the random access procedure in SpCell is deemed to have completed successfully, all continuous LBT failures triggered in SpCell may be canceled. Details of LBT failures and continuous LBT failures are described in the relevant 3GPP specifications.

[0060] In general, the first type of trigger condition related to the LBT process may be any suitable trigger condition indicating an LBT process that may require improvement. In some embodiments, the first type of trigger condition may be related to LBT failure-related information. In other words, LBT failure-related information can be considered a trigger condition for handover success reporting.

[0061] As an example, the first type of trigger condition may be that a continuous LBT failure during the LBT process was triggered and not canceled. A continuous LBT failure that was triggered and not canceled may suggest that the LBT failure recovery process performed by the terminal device 120 before or during the handover is not optimal and can be improved by optimizing the handover. Thus, such a trigger condition regarding a continuous LBT failure can trigger the terminal device 120 to collect information related to the handover and report the collected information to the source network device 110 via the target network device 130 or another serving network device of the terminal device 120. In this way, the source network device 110 can optimize future handover procedures based on the handover success report triggered by the trigger condition regarding the continuous LBT failure to avoid continuous LBT failures related to terminal devices in cell 115 before future handovers.

[0062] As another example, the first type of trigger condition may be that the number of LBT counters for counting the number of LBT failures during the LBT process is greater than a predetermined threshold. A number of LBT failures greater than the predetermined threshold may suggest that the handover procedure is not optimal, as one or more LBT failures occur in the LBT procedure performed by the terminal device 120 before or during the handover, and that this can be improved by optimizing the handover-related parameters. Thus, a trigger condition relating to such an LBT counter can trigger the terminal device 120 to collect information related to the handover and report the collected information to the source network device 110 via the target network device 130 or another serving network device of the terminal device 120. In this way, the source network device 110 can optimize future handover procedures based on the handover success report triggered by the trigger condition relating to the LBT counter, thereby avoiding one or more LBT failures related to the terminal devices in cell 115 before the future handover.

[0063] In some embodiments, the LBT counter may be "LBT_COUNTER" as defined in the relevant 3GPP specification. In some other embodiments, the LBT counter may be any other existing or future LBT counter defined for an LBT process performed by a terminal device. In some embodiments, the predetermined threshold may be 1, and the trigger condition may be that the LBT counter is 1 or greater, which means that there is an LBT failure in the LBT process. In some other embodiments, the predetermined threshold may be any appropriate value other than 1, and the number of LBT failures higher than the predetermined threshold may indicate a more serious LBT problem in the LBT process.

[0064] As another example of the broad range of trigger conditions described above, the set of trigger conditions 125 may include a second type of trigger condition related to high-speed master cell group (MCG) link recovery associated with terminal device 120. High-speed MCG link recovery may be performed by terminal device 120 in a dual connectivity (DC) communication scheme. In a DC, user devices (UEs) are simultaneously connected to master nodes (MNs) and secondary nodes (SNs). UEs can be configured to operate with each node and in carrier aggregation (CAs). The cells of the MN on which the UE operates in the CA are referred to as the master cell group (MCG), and the cells of the SN are referred to as the secondary cell group (SCG).

[0065] Figure 3 is a schematic diagram of yet another communication environment 300 in which some embodiments of the present disclosure can be implemented. In the communication environment 300, it is assumed that a dual connection communication scheme is configured for the terminal device 120. In this case, the network device 110 is the master network device (or master node) of the terminal device 120 and can provide an MCG including cell 115. In other words, the MCG provided by the master network device 110 consists of one or more cells including cell 115. The network device 150 is the secondary network device (or secondary node) of the terminal device 120 and may provide an SCG including cell 155. That is, the SCG provided by the secondary network device 150 consists of one or more cells including cell 155. The dual connection communication scheme allows the terminal device 120 to communicate simultaneously with the network device 150 via communication link 185, in addition to the communication link 145 between the network device 110 and the terminal device 120. The rest of the exemplary scenario shown in Figure 3 is similar to the exemplary scene shown in Figure 1A, so a detailed description of these parts is omitted.

[0066] To improve signaling robustness, in some DC options, the UE may be configured with a split signaling radio bearer (SRB) that enables the transmission of radio resource control (RRC) signaling via the MCG and / or SCG. That is, it can use the MN and / or SN radio resources to transmit NR RRC messages such as Evolved Universal Terrestrial Radio Access (E-UTRA) or RRC Reconfiguration. Additionally, in some DC options, the UE may be configured with SRB3, an SRB that terminates at the SN and is used solely for control signaling between the SN and the UE (i.e., does not require coordination with the MN).

[0067] Additionally, for several dual-connection communication schemes, the high-speed MCG link recovery function introduced in Rel-16 aims to reduce connection downtime during radio link failures (RLF). By utilizing SCG connectivity, the downtime caused by MCG RLF can be reduced from several seconds to the typical handover downtime of 30ms-70ms. For end users, this directly translates to reduced service downtime.

[0068] For example, in Multi-RAT Dual Connectivity (MR-DC), fast MCG recovery refers to an RRC procedure in which the UE sends an MCG failure information message to the MN via the SCG when a radio link failure is detected in the MCG. If a radio link failure is detected for the MCG and fast MCG link recovery is configured, the UE may trigger fast MCG link recovery. During fast MCG link recovery, the UE can suspend MCG transmission for all radio bearers and report the failure to the MN using an MCG failure information message via the SCG using the SCG SCG leg of split SRB1 or SRB3.

[0069] Upon receiving an MCG failure indication, the MN may use the SCG leg of split SRB1 or SRB3 to send an RRC reconfiguration or RRC release message to the UE via the SCG. If an RRCReconfiguration message is received in response to an MCGFailureInformation message, the MN may clear any information contained in the VarRLF-Report (if any). This means that if a fast MCG recovery via handover is successful, the network will not have MCG failure information, thereby potentially missing an opportunity to avoid another MCG RLF and improve the performance of fast MCG recovery.

[0070] To address this potential deficiency in handovers in response to high-speed MCG recovery, a second type of trigger condition may be that the terminal device 120 receives a radio resource control (RRC) reconfiguration message via the SCG provided by the network device 150. The RRC reconfiguration message may include a handover instruction 215 and corresponds to MCG failure information transmitted by the terminal device 120 to the network device 110 via the SCG. The MCG failure information may indicate an MCG radio link failure (RLF). More specifically, the trigger condition related to MCG link recovery may be receiving an RRCReconfiguration (with reconfigurationWithSync) in response to an MCGFailureInformation.

[0071] Such an RRC reset message received by terminal device 120 may indicate that the MCG for terminal device 120 is not optimal before or during the handover and can be improved by optimizing the handover. Therefore, trigger conditions related to such an RRC reset message can trigger terminal device 120 to collect information related to the handover and report the collected information to source network device 110 via target network device 130 or another serving network device of terminal device 120. In this way, source network device 110 can optimize future handover procedures based on the handover success report triggered by the trigger conditions related to the RRC reset message to avoid MCG failures related to terminal devices in cell 115 before future handovers. More specifically, if the MCG recovery due to the handover is successful, terminal device 120 can report MCG failure information, which allows the network to analyze and improve the performance of fast MCG recovery.

[0072] As another example of the broad range of trigger conditions described above, the set of trigger conditions 125 may include a third type of trigger condition in the case where the handover is a Dual Active Protocol Stack (DAPS) handover. Generally, a DAPS handover may refer to a handover procedure that maintains the source network device connection after receiving the RRC message for the handover and after successful random access to the target network device until the source cell is released. In the case of a DAPS handover, the RLF in the source cell may stop transmitting or receiving any data over the source link, release the source link, or maintain the source RRC setting.

[0073] For example, referring to Figure 1A, suppose that the handover of terminal device 120 from cell 115 to cell 135 is a DAPS handover. Upon receiving an instruction 215 (or request) to perform a DAPS handover with a reduced interruption time, terminal device 120 may continue to send and receive user data in source cell 115. Simultaneously, a new connection 165 to target cell 135 can be established, and terminal device 120 can perform synchronous and random access in target cell 135. While maintaining an active source user plane protocol stack for sending and receiving user data in source cell 115, terminal device 120 can establish a new user plane protocol stack for target cell 135, including the PHY (physical), MAC (media access control), and RLC (radio link control) layers.

[0074] Therefore, in the case of a DAPS handover from cell 115 to cell 135, if the terminal device 120 is configured with a third type of trigger condition related to the DAPS handover, the source network device 110 or target network device 130 can improve future DAPS handovers related to source cell 115 or target cell 135. For example, if a source RLF occurs during a DAPS handover, a 0ms handover interruption may mean that the DAPS handover cannot be achieved. Therefore, it may be desirable for the terminal device 120 to trigger a handover success report in response to a source RLF during a DAPS handover. For this purpose, in some embodiments, the third type of trigger condition may be that the terminal device 120 detects an RLF in source cell 115 in the case of a DAPS handover (e.g., when any DAPS bearer is configured).

[0075] A trigger condition related to the RLF on source cell 115 in such a DAPS counter can trigger terminal device 120 to collect information related to the DAPS handover and report the collected information to source network device 110 via target network device 130 or another serving network device of terminal device 120. In this way, source network device 110 and / or target network device 130 can improve future DAPS handover procedures related to source cell 115 and / or target cell 135 based on the handover success report triggered by the trigger condition related to the RLF on source cell 115.

[0076] As another example of the broad range of trigger conditions described above, the set of trigger conditions 125 may include a fourth type of trigger condition in which the handover is a conditional handover (CHO). Conditional handovers are one of the main mobility enhancements defined by 3GPP in Rel-16, which focus on reducing the number of failures that occur while terminal equipment is in motion, such as when an inter-cell handover fails or when a connection failure is triggered before a handover is triggered.

[0077] For example, referring to Figure 1A, suppose the handover of terminal device 120 from cell 115 to cell 135 is a conditional handover. In such a case, instead of preparing one target cell as in the usual case, the network device 110 may pre-prepare multiple candidate target cells, including cell 135. The network device 110 may enable sending instruction 215 (e.g., a handover command) to terminal device 120 earlier than in a normal handover, when the wireless condition is still good and the condition begins to deteriorate, as in a normal handover. Upon receiving a handover command, terminal device 120 may store the handover command rather than immediately applying it. In fact, terminal device 120 may apply a stored handover command to one of the configured candidate target cells (for example, cell 135 in the exemplary scenario of Figure 1A) only if the conditions set in terminal device 120 are met, and terminal device 120 can then perform the handover and connect to target network device 130, as in a normal handover.

[0078] Therefore, in the case of a conditional handover from cell 115 to cell 135, if terminal device 120 is configured with a fourth type of trigger condition related to the conditional handover, source network device 110 or target network device 130 can improve future conditional handovers related to source cell 115 or target cell 135. For example, the fourth type of trigger condition may be that multiple CHO candidate cells, including cell 135, have been configured. Multiple configured CHO candidate cells may mean that multiple target cells have been configured for the CHO. Therefore, a trigger condition relating to such multiple CHO candidate cells can trigger terminal device 120 to collect information related to the CHO with the multiple candidate cells and report the collected information to network device 110 via target network device 130 or another serving network device of terminal device 120. Thus, source network device 110 and / or target network device 130 can improve future CHOs with the multiple candidate cells based on the handover success report triggered by the trigger condition relating to the multiple CHO candidate cells.

[0079] As another example, a fourth type of trigger condition may be that multiple (e.g., two) execution conditions are set for the target cell 135. Multiple set execution conditions for the target cell 135 may mean that not all of the multiple execution conditions will be met for the handover of terminal device 120 to target cell 135. Therefore, a trigger condition relating to such multiple execution conditions can trigger terminal device 120 to collect information related to the conditional handover and report the collected information to network device 110 via target network device 130 or another serving network device of terminal device 120. Thus, source network device 110 and / or target network device 130 can improve future conditional handovers with multiple execution conditions based on the handover success report triggered by the trigger condition relating to the multiple execution conditions.

[0080] Returning to Figure 2, after determining trigger information based on the set of trigger conditions 125 (230), the terminal device 120 may perform different operations related to handover success reporting based on the determined trigger information. In some embodiments, the terminal device 120 may decide to trigger a handover success report for a handover from cell 115 to cell 135. For example, the terminal device 120 may detect that one or more of the set of trigger conditions 125 are met before or during the handover. This means that the terminal device 120 needs to generate a handover success report for the handover. To this end, before or during the handover from cell 115 to cell 135, the terminal device 120 can collect information to be reported in the handover success report (240). This allows the information to be collected only when a handover success report is triggered, thus avoiding the unnecessary collection of information for all successful handovers.

[0081] On the other hand, terminal device 120 may decide not to trigger a handover success report for a handover from cell 115 to cell 135. For example, terminal device 120 may confirm before or during the handover that none of the set of trigger conditions 125 are met. This means that terminal device 120 does not need to generate a handover success report for the handover. In this case, terminal device 120 may avoid collecting information for the handover success report before or during the handover from cell 115 to cell 135 (250). This eliminates the unnecessary overhead of collecting information for all successful handovers, as terminal device 120 does not need to collect information to be reported in the handover success report if the handover success report is not triggered.

[0082] Generally, the handover success report generated by the terminal device 120 may include any information that can help the source network device 110 or the target network device 130 improve the performance of future handovers. For example, the information collected by the terminal device 120 (240) and included in the handover success report may include RLM-related information, BFD-related information, and handover-related information. In some embodiments, it is desirable that the content of the handover success report be more comprehensive and extensive. This allows the source network device 110 or the target network device 130 to obtain more useful information related to various aspects of the handover after receiving an information-rich handover success report, thereby improving the performance of future handovers more effectively and efficiently.

[0083] As an example, in order to generate a handover success report, terminal device 120 can collect a first type of information related to the LBT process performed by terminal device 120. Generally, the first type of information may be any appropriate information about the LBT process that can reflect problems in the LBT process. For example, LBT failure-related information can be stored by terminal device 120 as part of the handover success report and reported to source network device 110. In this way, after receiving a handover success report containing information about the LBT processing performed by terminal device 120 before the handover, source network device 110 can improve future LBT processes performed by terminal devices related to the handover initiated in cell 115 by optimizing the handover settings.

[0084] In some embodiments, the first type of information can be stored so that if one or more trigger conditions of the first type are met before or during the handover of the terminal device 120, the terminal device 120 can report this in the handover success report. In other words, if the terminal device 120 detects that trigger conditions related to the LBT process have been met before or during the handover, the terminal device 120 may collect information related to the LBT procedure to be included in the handover success report. Thus, the information collected by the terminal device 120 for the handover success report can be more targeted and effective. In some other embodiments, the first type of information may be stored and reported by the terminal device 120 in response to any other trigger conditions that are met.

[0085] In some embodiments, the first type of information may include an indication of a persistent LBT failure. Thus, upon receiving a handover success report provided by the terminal device 120, the source network device 110 can obtain an indication of a persistent LBT failure from the handover success report. This allows the source network device 110 to optimize future handovers of terminal devices initiated in cell 115 to avoid persistent LBT failures associated with the terminal devices.

[0086] As an addition or alternative, the first type of information may include information about one or more bandwidth parts (BWPs) that trigger persistent LBT failures. Thus, upon receiving a handover success report provided by terminal device 120, network device 110 can obtain BWP information regarding persistent LBT failures from the handover success report. This allows network device 110 to optimize future handovers of terminal devices initiated in cell 115 to avoid persistent LBT failures in these BWPs.

[0087] As an addition or alternative, the first type of information may include BWPs in the order in which continuous LBT failure recovery was performed. Thus, upon receiving a handover success report provided by terminal device 120, network device 110 can obtain aligned BWP information regarding continuous LBT failure recovery from the handover success report. This allows network device 110 to optimize future handovers of terminal devices initiated in cell 115 to avoid continuous LBT failures in those BWPs.

[0088] As an addition or alternative, the first type of information may include a counter value for counting the number of LBT failures. Thus, upon receiving a handover success report provided by terminal device 120, network device 110 can determine the counter value from the handover success report. This allows network device 110 to determine the severity of the LBT failures, such as how many LBT failures occurred during the handover, and to assess the congestion of the unlicensed bandwidth. Based on this, network device 110 can optimize the use of licensed bandwidth, for example, by allocating fewer BWPs (bandwidth points) where LBT failures occur to terminal devices. In some embodiments, the counter for counting the number of LBT failures may be LBT_COUNTER as defined in the relevant 3GPP specification.

[0089] As an addition or alternative, the first type of information may include a timer value for continuous LBT failure detection. Thus, upon receiving a handover success report provided by terminal device 120, network device 110 can obtain the timer value from the handover success report. This allows network device 110 to determine the severity of the LBT failure, such as how much time has passed since the last LBT failure, when performing a handover, and to assess the congestion of the unlicensed bandwidth. Based on this, network device 110 can optimize the use of licensed bandwidth, for example, by allocating fewer BWPs (bandwidth points) where LBT failures occur to terminal devices. In some embodiments, the timer may be an lbt-FailureDetectionTimer as defined in the relevant 3GPP specification.

[0090] As another example, for handover success reporting, terminal device 120 can collect a second type of information related to MCG link recovery associated with the terminal device. Generally, the second type of information may be any appropriate information about MCG link recovery that can reflect problems in MCG link recovery. For example, terminal device 120 may store MCG RLF-related information in the handover success report. This allows terminal device 120 to report MCG failure information to the network if MCG recovery due to handover is successful, thereby enabling the network to analyze and improve the performance of high-speed MCG recovery.

[0091] In some embodiments, the second type of information can be stored so that if one or more trigger conditions of the second type are met before or during the handover of the terminal device 120, the terminal device 120 can report this in the handover success report. In other words, if the terminal device 120 detects that trigger conditions related to high-speed MCG link recovery have been met before or during the handover, the terminal device 120 may collect information related to high-speed MCG link recovery, which can then be included in the handover success report. Thus, the information collected by the terminal device 120 for the handover success report can be more targeted and effective. In some other embodiments, the second type of information may be stored and reported by the terminal device 120 in response to any other trigger conditions that are met.

[0092] In some embodiments, the second type of information may include the duration from the detection of the MCG RLF until the handover is completed, i.e., the time elapsed from the MCG connection failure until the handover is successful, which can represent the interruption time of the ongoing MCG service. Therefore, upon receiving a handover success report provided by the terminal device 120, the network device 110 can obtain the duration from the handover success report. This allows the network device 110 to analyze the performance of the high-speed MCG recovery due to the handover and determine whether optimization of the high-speed MCG recovery is necessary.

[0093] As an addition or alternative, the second type of information may include a timer value representing the duration of MCG link recovery, for example, the value of the T316 timer at the time of shutdown, which can indicate how long the recovery process will take. Thus, upon receiving a handover success report provided by the terminal device 120, the network device 110 can obtain the timer value from the handover success report. This allows the network device 110 to analyze the performance of the high-speed MCG recovery due to the handover and determine whether optimization of the high-speed MCG recovery settings is necessary.

[0094] As an addition or alternative, the second type of information may include MCG RLF instructions or MCG RLF reports. For example, terminal device 120 may store all or part of the information in the stored RLF-report variable in a handover success report variable and then clear the RLF-report variable. Thus, upon receiving a handover success report provided by terminal device 120, network device 110 can obtain MCG RLF instructions or MCG RLF reports from the handover success report. This allows network device 110 to optimize future handovers of terminal devices initiated in cell 115 to avoid MCG RLFs.

[0095] As an addition or alternative, a second type of information may be included in the MCG link recovery instructions regarding whether to use SRB3 or the split SRB1 SCG link. Thus, upon receiving a handover success report provided by terminal device 120, network device 110 can obtain this instruction from the handover success report. This allows network device 110 to optimize future handovers of terminal devices initiated in cell 115 by improving the configuration of SRB3 and split SRB1.

[0096] As another example, for handover success reporting, if the handover is a DAPS handover, terminal device 120 can collect a third type of information related to the RLF on source cell 115 during the handover. In other words, terminal device 120 can store source RLF-related information in the handover success report. This allows service interruptions during DAPS handovers to be reported to the network, enabling the network to analyze and improve the performance of DAPS handovers.

[0097] In some embodiments, a third type of information can be stored so that if one or more trigger conditions of the third type are met before or during a handover of the terminal device 120, the terminal device 120 can report this in the handover success report. In other words, if the terminal device 120 detects that trigger conditions related to a DAPS handover have been met before or during a handover, the terminal device 120 may collect information related to the DAPS handover to be included in the handover success report. Thus, the information collected by the terminal device 120 for the handover success report can be more targeted and effective. In some other embodiments, the third type of information may be stored and reported by the terminal device 120 in response to any other trigger conditions that are met.

[0098] In some embodiments, the third type of information may include the duration from the detection of an RLF on source cell 115 until the completion of the DAPS handover, i.e., the time elapsed from the source RLF until the DAPS handover is successful, which can represent a service interruption during the DAPS handover. Thus, upon receiving a handover success report provided by terminal device 120, the network device 110 can obtain the duration from the handover success report. This allows the network device 110 to optimize future DAPS handovers initiated at cell 115 in order to shorten the duration from the detection of an RLF at source cell 115 until the completion of the DAPS handover.

[0099] As another example, if the handover is a conditional handover, the terminal device 120 can collect a fourth type of information for handover success reporting. Generally, the fourth type of information may be any appropriate information about the conditional handover that can reflect problems in the conditional handover. Using the conditional handover information included in the handover success report provided by the terminal device 120, the source network device 110 can optimize the conditional handover settings. For example, the source network device 110 can avoid setting CHO candidate cells with low signal strength and / or setting execution conditions that are not triggered.

[0100] In some embodiments, the fourth type of information can be stored so that if one or more trigger conditions of the fourth type are met before or during the handover of the terminal device 120, the terminal device 120 can report this in the handover success report. In other words, if the terminal device 120 detects that trigger conditions related to a conditional handover have been met before or during the handover, the terminal device 120 may collect information related to the conditional handover, which can then be included in the handover success report. Thus, the information collected by the terminal device 120 for the handover success report can be more targeted and effective. In some other embodiments, the fourth type of information may be stored and reported by the terminal device 120 in response to any other trigger conditions that are met.

[0101] In some embodiments, the fourth type of information may include identifiers for a plurality of CHO candidate cells, including the target cell 135. Thus, upon receiving a handover success report provided by the terminal device 120, the network device 110 can obtain the identifiers for the plurality of CHO candidate cells from the handover success report. This allows the network device 110 to optimize future conditional handovers of terminal devices initiated at cell 115 and improve the CHO candidate cells.

[0102] As an addition or alternative, the fourth type of information may include measurement results for the multiple CHO candidate cells. Thus, upon receiving a handover success report provided by the terminal device 120, the network device 110 can obtain the measurement results for the multiple CHO candidate cells from the handover success report. This allows the network device 110 to optimize future conditional handovers of terminal devices initiated at cell 115 and improve the CHO candidate cells.

[0103] As an addition or alternative, the fourth type of information may include the execution conditions of the multiple CHO candidate cells. Thus, upon receiving a handover success report provided by the terminal device 120, the network device 110 can obtain the execution conditions of the multiple CHO candidate cells from the handover success report. This allows the network device 110 to optimize future conditional handovers of terminal devices initiated in cell 115 and improve the setting of the execution conditions of the multiple CHO candidate cells.

[0104] As an addition or alternative, the fourth type of information may include execution conditions to be satisfied for the target cell 135, such as measId, event ID, trigger threshold, trigger offset, hysteresis value, and timToTrigger value. Thus, upon receiving a handover success report provided by the terminal device 120, the network device 110 can obtain the satisfied execution conditions from the handover success report. This allows the network device 110 to optimize future conditional handovers of terminal devices initiated in cell 115, thereby improving the setting of execution conditions for the multiple CHO candidate cells.

[0105] As another example, for a handover success report, terminal device 120 can collect a fifth type of information related to the handover time information. The handover time information in the handover success report provided by terminal device 120 allows the network to know the time of the handover event corresponding to the handover success report, and thus obtain the handover success event time information, which can be used to improve future handover configurations.

[0106] Figure 4 is a schematic diagram showing several time points 410, 420, and 430 and durations 415, 425, and 435 related to the handover of terminal device 120 according to some embodiments of the present disclosure. Referring to Figures 1A and 4, time point 410 may represent the time when the handover of terminal device 120 from cell 115 to cell 135 begins. Time point 420 may represent the time when the handover of terminal device 120 from cell 115 to cell 135 is completed. Time point 430 may represent the time when a handover success report of the handover is sent to the target network device 130 or another network device.

[0107] Therefore, duration 415 may represent the duration for which the handover is performed, i.e., the value of timer T304 as defined in the relevant 3GPP specification. Duration 425 may represent the duration from when the handover is completed until a handover success report is sent to the target network device 130 or another network device, i.e., the time elapsed from the start of the handover until the handover success report is received. Duration 435 may represent the duration from when the handover starts until a handover success report is sent to the target network device 130 or another network device, i.e., the time elapsed from when the handover starts until the handover success report is received.

[0108] In some embodiments, the fifth type of information may include a duration 435 from the start of the handover until a handover success report is sent to the target network device 130 or another network device. Additionally or alternatively, the fifth type of information may include a duration 425 from the completion of the handover until a handover success report is sent to the target network device 130 or another network device. For example, if terminal device 120 receives a UEInformationRequest requesting a handover success report, terminal device 120 may store the time elapsed from the start of the handover or the time elapsed from the successful handover (e.g., to construct a timeline of the handover events) in the reported handover success report. Terminal device 120 may then provide the handover success report to the network via a UEInformationResponse.

[0109] In some embodiments, instead of reporting durations 415, 425, and / or 435, the terminal device 120 may store and report absolute time information about when the handover was initiated or successful. For example, the fifth type of information may include the time 410 when the handover was initiated. Additionally or alternatively, the fifth type of information may include the time 420 when the handover was completed.

[0110] As another example, for handover success reporting, terminal device 120 can collect the identifier of terminal device 120 in source cell 115. For example, the identifier may be a Cell Radio Network Temporary Identifier (C-RNTI). Thus, upon receiving a handover success report provided by terminal device 120, network device 110 can obtain the identifier of terminal device 120 from the handover success report. This allows network device 110 to optimize future handovers of terminal devices initiated in cell 115 based on the settings of terminal device 120.

[0111] The above describes several embodiments in which a terminal device can be configured with various trigger conditions for handover success reporting and various types of information to be reported within the handover success report. Below, several other embodiments that can support handover success reporting for inter-RAT handovers of terminal devices will be described.

[0112] Conventional handover success reporting could only support intra-RAT handovers. However, the inventors have discovered that supporting handover success reporting can achieve the same benefit in inter-RAT handover performance. Therefore, some embodiments of this disclosure support handover success reporting for inter-RAT handovers, such as NR to LTE handovers. Refer to Figure 1A for a more detailed explanation of handover success reporting for inter-RAT handovers.

[0113] Returning to Figure 1A, let us assume that the handover of terminal device 120 from cell 115 to cell 135 is an inter-RAT handover, where source cell 115 may be based on a first RAT, and target cell 135 may be based on a second RAT different from the first RAT. Generally, the first and second RATs may be any two different RATs from existing RATs or RATs to be developed in the future.

[0114] In some embodiments, the first RAT may be NR and the second RAT may be LTE. This allows the inter-RAT handover success report to be supported for network devices based on up to two primary RATs. In these embodiments, upon receiving a mobilityFromNRCommand, the terminal device 120 may check the set of trigger conditions 125 for the handover success report. If one or more of the set of trigger conditions 125 are met, the terminal device 120 may store the contents of the handover success report in the handover success report variable. The trigger conditions for the handover success report and the contents to be included in the handover success report may be the same as or similar to those described above. Additionally, if a handover success report is triggered for a handover, the terminal device 120 may collect cell identification information of the target cell 135 to be reported in the handover success report. Cell identification information can indicate that the handover is an inter-RAT handover and may include a cell global identifier (CGI) and an associated tracking area code (TAC). Thus, a successful inter-RAT handover report can be implicitly indicated by the cell identification information in LTE. For example, the CGI may be the E-UTRA CGI of terminal device 120.

[0115] In some embodiments, the source network device 110 can determine configuration information regarding whether or not to support inter-RAT handover success reporting. The source network device 110 may then transmit this configuration information to the terminal device 120. In this way, the network device 110 can flexibly control the configuration of inter-RAT handover success reporting in cell 115. In these embodiments, returning to Figure 2, when determining the trigger information for handover success reporting (230), if the terminal device 120 receives configuration information from the source network device 110 indicating that handover success reporting is supported for inter-RAT handover, the terminal device 120 may further determine whether or not to trigger the trigger information, i.e., the handover success reporting. For example, the configuration information may be transmitted from the source network device 110 to the terminal device 120 via the system information of the source cell 115. This makes the configuration information more accessible to terminal devices in cell 115. Alternatively or additionally, the configuration information may be transmitted via a handover command message that causes the terminal device 120 to perform a handover. Thus, configuration information can be specifically determined for a particular terminal device or a particular handover.

[0116] In some embodiments, the configuration information may be common to the set of trigger conditions 125. In other words, a single RAT handover success report may be configured based on all trigger conditions. This simplifies the configuration of trigger conditions for RAT handover success reports. Alternatively, the configuration information may be specific to one of the set of trigger conditions 125. That is, a RAT handover success report can be configured for each trigger condition. This allows for flexible and selective generation of RAT handover success reports for one or more of the set of trigger conditions 125.

[0117] Figure 5 shows another exemplary communication process 500 between a network device 110 and a terminal device 120 according to some embodiments of the present disclosure. In an example of the communication process 500, the network device 110 may first send configuration information to the terminal device 120 via system information 515 of cell 115 (510). Thus, when the terminal device 120 receives the system information 515 in the source cell 115 (520), the terminal device 120 can obtain the configuration information from the system information 515. If the configuration information indicates that a handover success report is supported for inter-RAT handover, and the network device 110 sends an inter-RAT handover instruction 535 (530), the terminal device 120 can determine the inter-RAT handover trigger information after receiving the instruction 535 (540) (550).

[0118] Furthermore, if terminal device 120 decides to trigger a handover success report for an inter-RAT handover, terminal device 120 can collect the information to be reported in the handover success report (560). Conversely, if terminal device 120 decides not to trigger a handover success report for an inter-RAT handover, terminal device 120 can avoid collecting the information to be reported in the handover success report (570). On the other hand, if the configuration information indicates that a handover success report is not supported for an inter-RAT handover, terminal device 120 can avoid generating a handover success report without further determining the trigger information.

[0119] Figure 6 shows yet another exemplary communication process 600 between a network device 110 and a terminal device 120 according to some embodiments of the present disclosure. In the exemplary communication process 600, the network device 110 may send configuration information to the terminal device 120 via a handover command message 615 (610). Thus, when the terminal device 120 receives the handover command message 615 (620), the terminal device 120 can obtain the configuration information from the handover command message 615. If the configuration information indicates that a handover success report is supported for an inter-RAT handover, the terminal device 120 can determine the trigger information for the inter-RAT handover (630).

[0120] Furthermore, if terminal device 120 decides to trigger a handover success report for an inter-RAT handover, terminal device 120 can collect the information to be reported in the handover success report (640). Conversely, if terminal device 120 decides not to trigger a handover success report for an inter-RAT handover, terminal device 120 can avoid collecting the information to be reported in the handover success report (650). On the other hand, if the configuration information indicates that a handover success report is not supported for an inter-RAT handover, terminal device 120 can avoid generating a handover success report without further determining the trigger information.

[0121] Figure 7 is a flowchart of an exemplary method 700 according to some embodiments of the present disclosure. In some embodiments, method 700 can be implemented in a terminal device, for example, terminal device 120 as shown in Figures 1A, 1B, and 3. Additionally or alternatively, method 700 may be implemented in other terminal devices not shown in Figures 1A, 1B, and 3. For illustrative purposes, method 700 will be described as being implemented by terminal device 120 with reference to Figures 1A, 1B, and 3 without loss of generality.

[0122] In block 710, the terminal device 120 receives an instruction from the first network device 110, which provides the first cell 115, to perform a handover of the terminal device 120 from the first cell 115 to the second cell 135 of the second network device 130. In block 720, the terminal device 120 determines trigger information relating to a handover success report for the handover, based on a set of trigger conditions, which indicates whether or not the handover success report is triggered for the handover.

[0123] In some embodiments, the set of trigger conditions may include at least one of a first type of trigger condition related to an LBT process performed by the terminal device 120, a second type of trigger condition related to high-speed MCG link recovery associated with the terminal device 120, a third type of trigger condition when the handover is a DAPS handover, and a fourth type of trigger condition when the handover is a CHO.

[0124] In some embodiments, the first type of trigger condition may include at least one of the following: a continuous LBT failure during the LBT process has been triggered and not canceled; or an LBT counter for counting the number of LBT failures during the LBT process is greater than a predetermined threshold.

[0125] In some embodiments, the first network device 110 is the master network device for the terminal device 120, and the third network device 150 is the secondary network device for the terminal device 120, and the second type of trigger condition may include the terminal device 120 receiving an RRC reset message containing instructions via an SCG provided by the secondary network device, the RRC reset message being a message corresponding to MCG failure information transmitted by the terminal device 120 via the SCG to the master network device providing an MCG including the first cell 115, the MCG failure information indicating an MCG RLF.

[0126] In some embodiments, a third type of trigger condition may include the detection of an RLF in the first cell 115 by the terminal device 120.

[0127] In some embodiments, the fourth type of trigger condition may include at least one of the following: a plurality of CHO candidate cells, including the second cell 135, being set; and a plurality of execution conditions being set for the second cell 135.

[0128] In some embodiments, when a handover success report is triggered for a handover, the terminal device 120 can collect information to be reported in the handover success report.

[0129] In some embodiments, if a handover success report is not triggered for a handover, the terminal device 120 can avoid collecting information for the handover success report.

[0130] In some embodiments, the information may include at least one of the following: a first type of information relating to the LBT process performed by the terminal device 120; a second type of information relating to MCG link recovery associated with the terminal device 120; a third type of information relating to the RLF on the first cell 115 during the handover if the handover is a DAPS handover; a fourth type of information if the handover is a CHO; and a fifth type of information relating to the handover time information.

[0131] In some embodiments, this information may include an identifier for the terminal device 120 in the first cell 115.

[0132] In some embodiments, the first type of information may include at least one of the following: an indication of a continuous LBT failure; information about one or more BWPs that trigger the continuous LBT failure; BWPs in the order in which continuous LBT failure recovery was performed; a counter value for counting the number of LBT failures; and a timer value for continuous LBT failure detection.

[0133] In some embodiments, the second type of information may include at least one of the following: the duration from the detection of the MCG RLF until the completion of the handover; a timer value representing the duration of the MCG link recovery; an indication of the MCG RLF; an MCG RLF report; and an indication of whether to use SRB3 or the SCG link of split SRB1 in the MCG link recovery.

[0134] In some embodiments, the third type of information may include the duration from the detection of the RLF in the first cell 115 until the completion of the DAPS handover.

[0135] In some embodiments, the fourth type of information may include at least one of the identifiers of a plurality of CHO candidate cells including the second cell, the measurement results of the plurality of CHO candidate cells, the execution conditions of the plurality of CHO candidate cells, and the execution conditions that the second cell 135 is satisfied with.

[0136] In some embodiments, the fifth type of information may include at least one of the following: the duration from when the handover begins until a handover success report is sent to the second network device 130 or another network device; the duration from when the handover is completed until a handover success report is sent to the second network device 130 or another network device; the time when the handover begins; and the time when the handover is completed.

[0137] In some embodiments, the first cell 115 may be based on a first RAT, and the second cell 135 may be based on a second RAT different from the first RAT.

[0138] In some embodiments, the second RAT may be LTE, and when a handover success report is triggered for a handover, the terminal device 120 can collect cell identification information of the second cell 135 to be reported in the handover success report. The cell identification information may include CGI and associated TAC.

[0139] In some embodiments, when determining trigger information, if the terminal device 120 receives configuration information from the first network device 110 indicating that a handover success report is supported for a handover as an inter-RAT handover, the terminal device 120 can determine the trigger information.

[0140] In some embodiments, the configuration information may be carried within the system information of the first cell 115 and / or within a handover command message that causes the terminal device 120 to perform a handover.

[0141] In some embodiments, the configuration information may be common to the set of trigger conditions. Alternatively, in some embodiments, the configuration information may be specific to one of the set of trigger conditions.

[0142] Figure 8 is a flowchart of another exemplary method 800 according to some embodiments of the present disclosure. In some embodiments, method 800 can be implemented in a network device, for example, a network device 110 as shown in Figures 1A, 1B, and 3. Additionally or alternatively, method 800 may be implemented in other terminal devices not shown in Figures 1A, 1B, and 3. For illustrative purposes, method 800 will be described as being implemented by network device 110 with reference to Figures 1A, 1B, and 3 without loss of generality.

[0143] In block 810, the network device 110 transmits configuration information to the terminal device 120 indicating whether or not a handover success report is supported for an inter-RAT handover of the terminal device 120 from the first cell 115 provided by the network device 110 based on the first RAT to the second cell 135 based on a second RAT different from the first RAT.

[0144] In some embodiments, configuration information may be carried in at least one of the system information of the first cell and a handover command message that causes a terminal device to perform an inter-RAT handover.

[0145] In some embodiments, the configuration information may be common to a set of trigger conditions for triggering a handover success report. Alternatively, in some embodiments, the configuration information may be specific to the trigger conditions for triggering a handover success report.

[0146] According to embodiments of the present disclosure, the terminal device includes a circuit which receives an instruction from a first network device providing a first cell to perform a handover of the terminal device from the first cell to a second cell of a second network device, and is configured to determine, based on a set of trigger conditions, trigger information relating to a handover success report for the handover, which indicates whether or not the handover success report is triggered for the handover.

[0147] In some embodiments, the set of trigger conditions may include at least one of a first type of trigger condition related to an LBT process performed by the terminal device 120, a second type of trigger condition related to high-speed MCG link recovery associated with the terminal device 120, a third type of trigger condition when the handover is a DAPS handover, and a fourth type of trigger condition when the handover is a CHO.

[0148] In some embodiments, the first type of trigger condition may include at least one of the following: a continuous LBT failure during the LBT process has been triggered and not canceled; or an LBT counter for counting the number of LBT failures during the LBT process is greater than a predetermined threshold.

[0149] In some embodiments, the first network device 110 is the master network device for the terminal device 120, and the third network device 150 is the secondary network device for the terminal device 120, and the second type of trigger condition may include the terminal device 120 receiving an RRC reset message containing instructions via an SCG provided by the secondary network device, the RRC reset message being a message corresponding to MCG failure information transmitted by the terminal device 120 via the SCG to the master network device providing an MCG including the first cell 115, the MCG failure information indicating an MCG RLF.

[0150] In some embodiments, a third type of trigger condition may include the detection of an RLF in the first cell 115 by the terminal device 120.

[0151] In some embodiments, the fourth type of trigger condition may include at least one of the following: a plurality of CHO candidate cells, including the second cell 135, being set; and a plurality of execution conditions being set for the second cell 135.

[0152] In some embodiments, the circuit is further configured to collect information to be reported in the handover success report when a handover success report is triggered for a handover.

[0153] In some embodiments, the circuit is further configured to avoid collecting information for a handover success report if a handover success report is not triggered for a handover.

[0154] In some embodiments, the information may include at least one of the following: a first type of information relating to the LBT process performed by the terminal device 120; a second type of information relating to MCG link recovery associated with the terminal device 120; a third type of information relating to the RLF on the first cell 115 during the handover if the handover is a DAPS handover; a fourth type of information if the handover is a CHO; and a fifth type of information relating to the handover time information.

[0155] In some embodiments, this information may include an identifier for the terminal device 120 in the first cell 115.

[0156] In some embodiments, the first type of information may include at least one of the following: an indication of a continuous LBT failure; information about one or more BWPs that trigger the continuous LBT failure; BWPs in the order in which continuous LBT failure recovery was performed; a counter value for counting the number of LBT failures; and a timer value for continuous LBT failure detection.

[0157] In some embodiments, the second type of information may include at least one of the following: the duration from the detection of the MCG RLF until the completion of the handover; a timer value representing the duration of the MCG link recovery; an indication of the MCG RLF; an MCG RLF report; and an indication of whether to use SRB3 or the SCG link of split SRB1 in the MCG link recovery.

[0158] In some embodiments, the third type of information may include the duration from the detection of the RLF in the first cell 115 until the completion of the DAPS handover.

[0159] In some embodiments, the fourth type of information may include at least one of the identifiers of a plurality of CHO candidate cells including the second cell, the measurement results of the plurality of CHO candidate cells, the execution conditions of the plurality of CHO candidate cells, and the execution conditions that the second cell 135 is satisfied with.

[0160] In some embodiments, the fifth type of information may include at least one of the following: the duration from when the handover begins until a handover success report is sent to the second network device 130 or another network device; the duration from when the handover is completed until a handover success report is sent to the second network device 130 or another network device; the time when the handover begins; and the time when the handover is completed.

[0161] In some embodiments, the first cell 115 may be based on a first RAT, and the second cell 135 may be based on a second RAT different from the first RAT.

[0162] In some embodiments, the second RAT may be an LTE, and the circuit is further configured to collect cell identification information of the second cell 135 to be reported in the handover success report when a handover success report is triggered for a handover. The cell identification information may include the CGI and associated TAC.

[0163] In some embodiments, the circuit is further configured to determine trigger information when the terminal device 120 receives configuration information from the first network device 110 indicating that handover success reporting is supported for handovers as RAT handovers.

[0164] In some embodiments, the configuration information may be carried within the system information of the first cell 115 and / or within a handover command message that causes the terminal device 120 to perform a handover.

[0165] In some embodiments, the configuration information may be common to the set of trigger conditions. Alternatively, in some embodiments, the configuration information may be specific to one of the set of trigger conditions.

[0166] According to embodiments of the present disclosure, the network device includes a circuit configured to transmit to a terminal device configuration information indicating whether or not a handover success report is supported for an inter-RAT handover of the terminal device from a first cell to a second cell. The first cell is provided by the network device based on a first RAT, and the second cell is based on a second RAT different from the first RAT.

[0167] In some embodiments, configuration information may be carried in at least one of the system information of the first cell and a handover command message that causes a terminal device to perform an inter-RAT handover.

[0168] In some embodiments, the configuration information may be common to a set of trigger conditions for triggering a handover success report. Alternatively, in some embodiments, the configuration information may be specific to the trigger conditions for triggering a handover success report.

[0169] Figure 9 is a schematic block diagram of a device 900 suitable for implementing some embodiments of the present disclosure. The device 900 is considered to be another embodiment of the network device 110 or terminal device 120 shown in Figure 1. Therefore, the device 900 can be implemented in the network device 110 and terminal device 120, or as at least a part thereof.

[0170] As illustrated, the device 900 comprises a processor 910, a memory 920 coupled to the processor 910, appropriate transmitters (TX) and receivers (RX) 940 coupled to the processor 910, and a communication interface coupled to the TX / RX 940. The memory 920 stores at least a portion of the program 930. The TX / RX 940 is used for bidirectional communication. The TX / RX 940 has at least one antenna to facilitate communication, although the access node referred to herein may actually have multiple antennas. The communication interface may represent any interface necessary for communication with other network elements, such as an X2 or Xn interface for bidirectional communication between gNBs or eNBs, an S1 interface for communication between a Mobility Management Entity (MME) / Serving Gateway (S-GW) and an eNB, an Un interface for communication between a gNB or eNB and a relay node (RN), or a Uu interface for communication between a gNB or eNB and a terminal device.

[0171] Program 930 is deemed to include program instructions that, when executed by the associated processor 910 as described herein with reference to any of Figures 1 to 8, enable the device 900 to operate according to embodiments of the present disclosure. Embodiments of the present disclosure may be implemented by computer software executable by the processor 910 of the device 900, by hardware, or by a combination of software and hardware. The processor 910 may be configured to implement various embodiments of the present disclosure. Furthermore, a combination of the processor 910 and memory 920 may form processing means 950 suitable for implementing various embodiments of the present disclosure.

[0172] Memory 920 may be of any type suitable for a local technology network and may be implemented using any suitable data storage technology, such as non-temporary computer-readable storage media, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory, as an unrestricted example. Although only one memory 920 is shown in device 900, several physically different memory modules may exist within device 900. Processor 910 may be of any type suitable for a local technology network and may include, as an unrestricted example, one or more of general-purpose computers, dedicated computers, microprocessors, digital signal processors (DSPs), and processors based on multicore processor architectures. Device 900 may have multiple processors, for example, application-specific integrated circuit chips that are temporally dependent on a clock that synchronizes the main processor.

[0173] The components included in the equipment and / or apparatus of this disclosure can be implemented in a variety of ways, including software, hardware, firmware, or any combination thereof. In some embodiments, one or more units may be implemented using software and / or firmware, such as machine-executable instructions stored on a storage medium. In addition to, or instead of, machine-executable instructions, some or all of the units in the equipment and / or apparatus may be implemented at least partially by one or more hardware logic components. Exemplary types of usable hardware logic components include, but are not limited to, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems on a chip (SOCs), and complex programmable logic devices (CPLDs).

[0174] Overall, various embodiments of the Disclosure may be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some embodiments may be implemented in hardware, while others may be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device. Various embodiments of the Disclosure are illustrated and described using block diagrams, flowcharts, or any other pictorial representation, but it should be understood that the blocks, devices, systems, techniques, or methods described herein can be implemented, in non-limiting examples, in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or any combination thereof.

[0175] This disclosure also provides at least one computer program product tangibly stored on a non-temporary computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions contained in a program module, which are executed within a device on a target real or virtual processor to perform the processes or methods described above with reference to any one of Figures 2, 5 through 8. Generally, a program module includes routines, programs, libraries, objects, classes, components, data structures, etc., that perform a specific task or implement a specific abstract data type. In various embodiments, the functions of program modules can be combined or separated among program modules as needed. The machine-executable instructions of a program module can be executed within a local or distributed device. In a distributed device, the program module may reside in both local and remote storage media.

[0176] Program code for performing the methods of this disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general-purpose computer, a dedicated computer, or other programmable data processing device, and when executed by the processor or controller, the program code may implement the functions / operations specified in the flowcharts and / or block diagrams. The program code may run entirely on a machine, partially on a machine, as an independent software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0177] The program code described above may be implemented on a machine-readable medium, which may be any tangible medium that can contain or store programs used by or associated with an instruction execution system, device, or apparatus. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or apparatus, or any suitable combination of the aforementioned media. More specific examples of machine-readable storage media may include electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable optical disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above.

[0178] While the operations have been described in a specific order, it should not be understood that, in order to obtain the desired results, these operations must be performed in the specific order shown, or in a sequential order, or that all of the described operations must be performed. In some cases, multitasking or parallel processing may be advantageous. Similarly, while details of several specific embodiments are included in the above discussion, these should not be interpreted as limitations on the scope of this disclosure, but rather as descriptions of features that may be specific to those embodiments. Some features described in the context of individual embodiments may be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may be implemented separately or in any suitable subcombination in multiple embodiments.

[0179] While this disclosure has been described in language specific to structural features and / or methodological behavior, it should be understood that the disclosure as defined in the attached claims is not necessarily limited to the specific features or behaviors described above. Rather, the specific features and behaviors described above are disclosed as exemplary forms of implementing the claims.

Claims

1. A method performed by a terminal device, The Master Cell Group (MCG) sends a failure information message. Received a Radio Resource Control (RRC) reconfiguration message including reconfigurationWithSync, Time information regarding the MCG recovery procedure is stored in the first report. method.

2. The aforementioned time information is associated with the time when timer T316 is stopped. The method according to claim 1.

3. Furthermore, a second message was received requesting a handover success report. Upon receiving the second message, the time elapsed since the successful completion of the handover is stored in the handover success report variable. The method according to claim 1.

4. A method performed by a network device, Upon receiving a Master Cell Group (MCG) failure information message, Send a Radio Resource Control (RRC) reconfiguration message including reconfigurationWithSync, Time information regarding the MCG recovery procedure is received in the first report. method.

5. The aforementioned time information is associated with the time when timer T316 is stopped. The method according to claim 4.

6. Furthermore, a second message is sent to request a handover success report. The time elapsed since the successful completion of the handover is received in the handover success report variable. The method according to claim 4.

7. A means for sending Master Cell Group (MCG) failure information messages, Means for receiving a radio resource control (RRC) reconfiguration message including reconfigurationWithSync, A means for storing time information regarding the MCG recovery procedure in the first report, A terminal device equipped with the following features.

8. The aforementioned time information is associated with the time when timer T316 is stopped. The terminal device according to claim 7.

9. A means of receiving a second message requesting a handover success report, In response to receiving the second message, means for storing the time elapsed since the successful completion of the handover in a handover success report variable, The terminal device according to claim 7, further comprising:

10. A means for receiving Master Cell Group (MCG) failure information messages, Means for transmitting a radio resource control (RRC) reconfiguration message including reconfigurationWithSync, A means for receiving time information regarding the MCG recovery procedure in the first report, A network device equipped with the following features.

11. The aforementioned time information is associated with the time when timer T316 is stopped. The network device according to claim 10.

12. A means of sending a second message to request a handover success report, A means of receiving the time elapsed since the successful completion of the handover in the handover success report variable, The network device according to claim 10, further comprising:

Images