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] TECHNICAL FIELD Embodiments of the present disclosure relate generally to the field of communications, and more specifically, to solutions for supporting handover success reporting. [Background technology]

[0002] 5G New Radio (NR) is the global standard for a unified, higher-performance 5G wireless air interface. 5G enables a new kind of network designed to connect nearly everyone and everything – machines, things and devices. In the 3rd Generation Partnership Project (3GPP) Release 17 (Rel-17) Work Item Description (WID), Enhancement of data collection for Self-Optimizing Networks (SON) / Minimization of drive tests (MDT) in NR, the goal of the SON function is 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 remainder of the Rel-16 SON / MDT Work Items (WIs), such as successful handovers reports.

[0003] Regarding handover success reporting, the Mobility Robustness Optimization (MRO) function in NR can be enhanced to provide more robust mobility by reporting failure events observed during successful handover. A solution to this problem is to configure the User Equipment (UE) to create a report associated with handover success that includes a set of measurements collected during the handover phase, such as measurements at handover trigger time, measurements at the end of handover execution, or measurements after handover execution. However, generating such a report after every successful handover would result in unnecessary resource waste. Summary of the Invention [Problem to be solved by the invention]

[0004] Overall, the embodiments of the present disclosure provide a solution for supporting handover success reporting. [Means for solving the problem]

[0005] In a first aspect, a method of communication is provided. The method includes receiving, in a terminal device, 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. The method further includes determining trigger information regarding 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.

[0006] In a second aspect, a communication method is provided, the method including: transmitting, in a network device, configuration information to a terminal device, indicating whether 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 being provided by the network device based on a first RAT, and the second cell being based on a second RAT different from the first RAT.

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

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

[0009] In a fifth aspect, there is provided a computer readable medium having instructions stored thereon which, when executed on at least one processor of an apparatus, cause the apparatus to perform a method according to the first aspect.

[0010] In a sixth aspect, there is provided a computer readable medium having instructions stored thereon which, when executed on at least one processor of an apparatus, cause the apparatus to perform a method according to the second aspect.

[0011] It should be understood that this summary is not intended to identify key or essential features of the embodiments of the present disclosure, nor to limit the scope of the present disclosure. Other features of the present disclosure will be readily understood from the following description. [Brief description of the drawings]

[0012] The above and other objects, features and advantages of the present disclosure will become more apparent from the following detailed description of several embodiments of the present disclosure in the drawings.

[0013] [Figure 1A] FIG. 1 illustrates a schematic diagram of a communication environment in which some embodiments of the present disclosure may be implemented.

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

[0015] [Diagram 2] FIG. 2 illustrates an example communication process between a network device and a terminal device in accordance with some embodiments of the present disclosure.

[0016] [Diagram 3] FIG. 2 is a schematic diagram of yet another communication environment in which some embodiments of the present disclosure may be implemented.

[0017] [Figure 4] 1 is a schematic diagram illustrating several time points and durations associated with a handover of a terminal device in accordance with some embodiments of the present disclosure.

[0018] [Diagram 5] FIG. 2 illustrates another exemplary communication process between a network device and a terminal device in accordance with some embodiments of the present disclosure.

[0019] [Figure 6] FIG. 2 illustrates yet another exemplary communication process between a network device and a terminal device in accordance with some embodiments of the present disclosure.

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

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

[0022] [Figure 9]FIG. 1 is a schematic block diagram of an apparatus suitable for implementing some embodiments of the present disclosure.

[0023] In the drawings, the same or similar reference numbers represent the same or similar elements. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0025] In the following description and claims, unless defined otherwise, 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) refers to a device capable of providing or hosting a cell or coverage within which terminal devices can communicate. Examples of network devices include, but are not limited to, a Node B (NodeB or NB), an evolved Node B (eNodeB or eNB), a next generation Node B (gNB), infrastructure devices for vehicle-to-everything (V2X) communications, a Transmission / Reception Point (TRP), a Remote Radio Unit (RRU), a Radio Head (RH), a Remote Radio Head (RRH), a femto node, a pico node, or other low power node.

[0027] As used herein, the term "terminal device" refers to 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, in-vehicle devices for V2X communication, etc., where the "X" in V2X represents a pedestrian, vehicle, or infrastructure / network, or an image capture device such as a digital camera, a gaming device, a music storage and playback device, or an Internet appliance that allows wireless or wired Internet access and browsing. For purposes of explanation, some embodiments will be described below with reference to a 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 network device and the second network device may be a master node and the other may be a secondary node. The first network device and the second network device 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 from at least one of the first network device and the second network device to the terminal device. 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 the 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] The term "circuitry" as used herein may refer to a hardware circuit and / or a combination of a hardware circuit and software. For example, a circuit may be a combination of analog and / or digital hardware circuitry and software / firmware. As yet another example, a circuit may be any portion of a hardware processor having software, including a digital signal processor, software, and one or more memories, that cooperate to cause a device, such as a terminal device or a 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 portion thereof, that requires software / firmware for operation, but the software may not be present if not required for operation. As used herein, the term "circuitry" also includes implementations of only a hardware circuit or one or more processors, or a portion of a hardware circuit or one or more processors, and its (or their) associated software and / or firmware.

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

[0031] That is, in the context of the present disclosure, a transmission / reception point, a base station (BS) or a cell may be interpreted as a generic concept indicating a part of an area or function covered by a base station controller (BSC) in code division multiple access (CDMA), a Node-B in WCDMA, an eNB or a sector (site) in LTE, a gNB or a TRP in NR, etc. Thus, the concept of a transmission / reception point, a base station (BS) and / or a cell may include various coverage areas such as a mega cell, a macro cell, a micro cell, a pico cell, a femto cell, etc. Furthermore, this concept may include the communication range of a relay node (RN), a remote radio head (RRH), or a radio unit (RU).

[0032] In the context of this disclosure, the user equipment and the transmission / reception point may be two transmission / reception entities having a generic meaning for embodying the techniques and technical concepts disclosed herein, and may not be limited to a specific term or word. Furthermore, the user equipment and the transmission / reception point may be an uplink or downlink transmission / reception entity having a generic meaning for embodying the techniques and technical concepts disclosed in connection with this disclosure, and may not be limited to a specific term or word. As used herein, uplink (UL) transmission / reception is the manner in which data is transmitted from the user equipment to the base station. Alternatively, downlink (DL) transmission / reception is the manner in which data is transmitted from the base station to the user equipment.

[0033] As used herein, the terms "resource", "transmission 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, such as a resource in the time domain, a resource in the frequency domain, a resource in the spatial domain, a resource in the code domain, or any other resource enabling communication. In the following, resources in both the frequency domain and the time domain are used as examples of transmission resources to explain some embodiments of the present disclosure. It should be noted that the embodiments of the present disclosure may be applied to other resources in other domains as well.

[0034] As used herein, the singular forms "a," "an," and "said" include the plural forms unless the context clearly indicates otherwise. The term "comprises" and variations thereof should be understood as open terms meaning "including, but not limited to." The term "based on" should be understood as "based at least in part 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," and the like may refer to different or the same object. The following may include other explicit and implicit definitions.

[0035] In some instances, values, procedures, or devices are referred to as "best," "lowest," "highest," "minimum," "maximum," etc. Such descriptions are intended to illustrate that selections can be made from among many functional alternatives used, and it should be understood that such selections are not necessarily better, smaller, higher, or otherwise more preferred than other selections.

[0036] As mentioned above, in the 3GPP Rel-17 WID extension of data collection for SON / MDT in NR, one of the purposes of the SON function is handover success reporting. The handover success report is, in general, a report of a successful handover of a terminal device from a source cell to a target cell. Specifically, the handover success report can be generated by a terminal device that has performed a successful handover, sent by the terminal device to a target network device of the target cell or a subsequent network device serving the terminal device (if the target network device has not obtained the handover success report), and finally obtained from the target network device or the subsequent network device by a source network device of the source cell.

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

[0038] However, in conventional handover success reporting solutions, various details of handover success reporting are not specified and 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 generate handover success reports arbitrarily or selectively for successful handovers that need improvement. Indeed, the specific mechanism to support handover success reporting is not clear and needs to be specified. Furthermore, it is unclear how exactly to configure handover success reporting, and it is noted that conventional solutions for handover success reporting do not take into account the new features introduced by Rel-16.

[0039] To solve the above-mentioned technical problems in the conventional solutions and other potential technical problems, the embodiments of the present disclosure provide a solution supporting handover success reporting. In some embodiments, a terminal device receives an indication from a first network device providing a first cell. The indication indicates to perform a handover of the terminal device from the first cell to a second cell of a second network device. The terminal device then determines trigger information for a handover success reporting of the handover based on a set of trigger conditions. The trigger information indicates whether the handover success reporting is triggered for the handover.

[0040] According to an embodiment of the present disclosure, the terminal device can be configured with the set of trigger conditions for making a handover success report of a handover arbitrarily, and thus the handover success report can be triggered only if one or more of the set of trigger conditions are met. This allows the terminal device to be restricted to report relevant handover success circumstances, such as potential problems detected by RLM, beam failure detection (BFD), etc., before or during a successful handover event. That is, since the handover success report can be arbitrarily triggered based on the set of trigger conditions, the terminal device can be restricted to report the handover success report only when necessary, and can save processing and communication resources for unnecessary handover success reports. The principles and embodiments of the present disclosure are described in detail below.

[0041] 1A is a schematic diagram of a communication environment 100 in which some embodiments of the present disclosure may be implemented. As shown in FIG. 1A, the communication environment 100 (which may also be referred to as a communication network 100 or a communication system 100) includes a network device 110 serving a terminal device 120 located in a cell 115 provided by the network device 110. Specifically, the terminal device 120 may 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 in the case of transmission from the network device 110 to the terminal device 120, and may alternatively be referred to as an uplink in the case of transmission from the terminal device 120 to the network device 110.

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

[0043] More specifically, the handover may be performed by the terminal device 120 in a connected mode in which the terminal device 120 is active. The handover may be controlled by the source network device 110 and assisted by the terminal device 120. Before 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 has deteriorated and / or that the target cell 135 has become better than the source cell 115. Based on these measurement reports, the network device 110 may move (i.e., handover) the connection of the terminal device 120 from the source cell 115 to the target cell 135, so that the terminal device 120 may obtain better radio conditions and therefore a better user experience.

[0044] During handover of the terminal device 120 from the source cell 115 to the target cell 135, the source network device 110 may communicate necessary information to facilitate the handover with the target network device 130 via a communication link 155 (e.g., an Xn interface between the two network devices). Additionally, although the handover of the terminal device 120 from the source cell 115 to the target cell 135 is described above as being due to movement of the terminal device 120, it should be understood that embodiments of the present disclosure are not limited thereto and are applicable to handovers due to a variety of possible causes.

[0045] In some embodiments, the terminal device 120 may generate a handover success report if the handover from the source cell 115 to the 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 the terminal device 120 to the target network device 130 via the radio resource control (RRC) layer. The target network device 130 may obtain the information in the handover success report via a UE Information Request and Response mechanism. Additionally, the target network device 130 may then forward the handover success report to the source network device 110 to indicate failures experienced during the successful handover event.

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

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

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

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

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

[0051] It should be understood that the numbers of terminal devices, network devices, cells, and communication links as shown in Figures 1A and 1B are for illustrative purposes only and do not imply any limitations. 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 implement embodiments of the present disclosure.

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

[0053] Communications in the communication environment 100 or 105 may conform to any suitable standard, including, but not limited to, 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), GSM EDGE Radio Access Network (GERAN), and the like. Furthermore, communications may be performed according to any generation of communication protocols now known or 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] 2 illustrates an example communication process 200 between a network device 110 and a terminal device 120, in accordance with some embodiments of the present disclosure. For purposes of explanation, the communication process 200 is described with reference to FIG. 1A. However, it should be understood that the communication process 200 is equally applicable to any other communication scenario in which two communication terminals communicate with each other.

[0055] 2, when the network device 110 determines that a handover of the terminal device 120 needs to be performed from the cell 115 to the cell 135, the network device 110 sends an indication 215 to the terminal device 120 (210). The indication 215 may indicate that a handover from the cell 115 to the cell 135 is performed by the terminal device 120. On the terminal device 120 side, upon receiving the indication 215 from the network device 110 (220), the terminal device 120 determines trigger information based on the set of conditions 125 (230). The trigger information is related to a handover success report of the handover, and indicates whether a handover success report is triggered for the handover.

[0056] In other words, based on the set of trigger conditions 125, the terminal device 120 can decide whether to generate a handover success report for the handover indicated by the instruction 215. For example, if one or more of the set of trigger conditions 125 are met before or during the execution of 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 execution of 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 indicate a successful but incomplete handover that may require improvement. For example, the set of trigger conditions 125 may include detection of radio problems to the source cell prior to handover trigger, detection of RACH delay during handover procedure, reaching a quality change threshold, reaching an absolute quality threshold at the main measurement instant, initiating handover while timer T310 / T312 defined in the relevant 3GPP specifications is running, performing RRCReconfiguration, etc. In some embodiments, it is desirable for the set of trigger conditions 125 to be more comprehensive and broad-ranging so that the handover source network device 110 and / or target network device 130 can obtain more useful information to improve future handovers. For example, one or more of the set of trigger conditions 125 may be designed taking 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 New Radio in Unlicensed Spectrum (NR-U), channel access in both downlink and uplink depends on LBT function. For example, referring to FIG. 1A, if the communication system 100 is implemented in NR-U, the network device 110 or the terminal device 120 must first "sense" the communication channel before any transmission on the communication channel to know that there is no communication on the communication channel. If the communication channel is a wide bandwidth unlicensed carrier (e.g., hundreds of MHz), the "channel sensing" procedure may rely on detecting energy levels in multiple sub-bands of the communication channel. LBT parameters (e.g., type / duration, clear channel judgment parameters, etc.) can be set by the network device 110 in the terminal device 120.

[0059] Regarding the LBT process, the relevant 3GPP specifications define LBT failure and persistent LBT failure as follows: If an LBT failure indication has already been received from lower layers, the lbt-FailureDetectionTimer may be started or restarted and the LBT_COUNTER may be incremented by one. If the LBT_COUNTER is greater than or equal to the lbt-FailureInstanceMaxCount, a persistent LBT failure is triggered for active UL BWPs in the serving cell. If the serving cell is an SpCell and persistent LBT failures are triggered for all UL BWPs configured with a PRACH occasion on the same carrier in the serving cell, persistent LBT failure may be indicated to higher layers. If the serving cell is not an SpCell, any ongoing random access procedure in the serving cell may be stopped, the active UL BWP may be switched to a UL BWP on the same carrier in the serving cell that is configured with a PRACH occasion and for which a persistent LBT failure has not yet been triggered, and a random access procedure may be initiated. Also, if a persistent LBT failure is triggered in the SpCell and is not canceled, and if the random access procedure is deemed to have been completed successfully in the SpCell, all persistent LBT failures triggered in the SpCell may be canceled. Details of LBT failure and persistent LBT failure 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, the LBT failure related information may be considered to be a trigger condition for a handover success report.

[0061] As an example, the first type of trigger condition may be that a persistent LBT failure during an LBT process is triggered and not cancelled. The persistent LBT failure triggered and not cancelled may suggest that the LBT failure recovery process performed by the terminal device 120 before or during handover is not optimal and can be improved by optimizing the handover. Therefore, such a trigger condition regarding persistent LBT failure may 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 may optimize future handover procedures based on the handover success report triggered by the trigger condition regarding persistent LBT failure to avoid persistent LBT failure related to the terminal device in the cell 115 before the future handover.

[0062] As another example, the first type of triggering condition may be that an LBT counter for counting the number of LBT failures during an LBT process is greater than a predetermined threshold. A number of LBT failures higher than the predetermined threshold may suggest that the handover procedure is not optimal and can be improved by optimizing handover-related parameters because one or more LBT failures occur in the LBT procedure performed by the terminal device 120 before or during handover. Thus, such a triggering condition on the 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 a future handover procedure based on the handover success report triggered by the triggering condition on the LBT counter to avoid one or more of the LBT failures related to the terminal device in the cell 115 before the future handover.

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

[0064] As another example of the broad range of trigger conditions mentioned above, the set of trigger conditions 125 may include a second type of trigger condition related to a fast master cell group (MCG) link recovery associated with the terminal device 120. The fast MCG link recovery may be performed by the terminal device 120 in a dual connectivity (DC) communication mode. In DC, a user equipment (UE) is simultaneously connected to a master node (MN) and a secondary node (SN). The UE may be configured to operate in carrier aggregation (CA) with each node. The cell of the MN in which the UE operates in CA is called the master cell group (MCG), and the cell of the SN is called the secondary cell group (SCG).

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

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

[0067] Additionally, for some dual connectivity communication methods, the fast MCG link recovery feature introduced in Rel-16 aims to reduce the connection interruption time during radio link failure (RLF). By utilizing SCG connectivity, the MCG RLF interruption time can be reduced from a few seconds to a typical handover interruption time of 30ms-70ms. For end users, this translates directly into shorter service interruptions.

[0068] For example, fast MCG recovery in Multi-RAT Dual Connectivity (MR-DC) 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 may suspend MCG transmission for all radio bearers and report the failure to the MN using an MCG failure information message via the SCG using a split SRB1 or SRB3 SCG leg.

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

[0070] To address this potential deficiency in handover in response to fast MCG recovery, a second type of trigger condition may be that the terminal device 120 receives a radio resource control (RRC) reconfiguration message via an SCG provided by the network device 150. The RRC reconfiguration message may include a handover indication 215 and is in response to MCG failure information sent 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, a trigger condition related to MCG link recovery may be receiving an RRCReconfiguration (comprising reconfigurationWithSync) in response to an MCG FailureInformation.

[0071] Such an RRC reconfiguration message received by the terminal device 120 may mean that the MCG for the terminal device 120 before or during the handover is not optimal and can be improved by optimizing the handover. Therefore, a trigger condition for such an RRC reconfiguration message 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 for the RRC reconfiguration message to avoid MCG failure related to the terminal device in the cell 115 before the future handover. More specifically, if the MCG recovery by handover is successful, the MCG failure information can be reported by the terminal device 120, 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 mentioned above, the set of trigger conditions 125 may include a third type of trigger condition when the handover is a dual active protocol stack (DAPS) handover. In general, a DAPS handover may refer to a handover procedure that maintains a source network device connection after receiving an RRC message for handover and until the source cell is released after successful random access to the target network device. In the case of a DAPS handover, for the RLF in the source cell, any data transmission or reception over the source link may be stopped, and the source link may be released but the source RRC configuration may be maintained.

[0073] For example, referring to FIG. 1A, assume that the handover of the terminal device 120 from the cell 115 to the cell 135 is a DAPS handover. Upon receiving an instruction 215 (or request) to perform a DAPS handover with a reduced interruption time, the terminal device 120 may continue to transmit and receive user data in the source cell 115. At the same time, a new connection 165 to the target cell 135 can be established, and the terminal device 120 can perform synchronization and random access in the target cell 135. The terminal device 120 can establish a new user plane protocol stack including PHY (physical), MAC (medium access control) and RLC (radio link control) layers for the target cell 135 while actively maintaining the source user plane protocol stack for transmitting and receiving user data in the source cell 115.

[0074] Thus, in case of a DAPS handover from cell 115 to cell 135, if terminal device 120 is configured with a third type of trigger condition related to DAPS handover, 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 source RLF occurs during DAPS handover, it may mean that a 0 ms handover interruption cannot be realized by DAPS handover. Therefore, it may be desirable for terminal device 120 to trigger a handover success report in response to source RLF during DAPS handover. To this end, in some embodiments, the third type of trigger condition may be that RLF is detected in source cell 115 by terminal device 120 in case of DAPS handover (e.g., any DAPS bearer is set up).

[0075] Such a trigger condition for RLF on the source cell 115 in the DAPS counters may trigger the terminal device 120 to collect information related to the DAPS 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 and / or the target network device 130 may improve future DAPS handover procedures related to the source cell 115 and / or the target cell 135 based on the handover success report triggered by the trigger condition for RLF on the source cell 115.

[0076] As another example of the broad range of trigger conditions mentioned above, the set of trigger conditions 125 may include a fourth type of trigger condition when the handover is a conditional handover (CHO), which is one of the main mobility enhancements defined by 3GPP in Rel-16 that focuses on reducing the number of failures that occur while the terminal device is moving, such as when a handover between cells fails or when a connection failure is triggered before a handover is triggered.

[0077] For example, referring to FIG. 1A, assume that the handover of the terminal device 120 from the cell 115 to the cell 135 is a conditional handover. In such a case, instead of preparing one target cell in the normal case, multiple candidate target cells including the cell 135 may be prepared in advance in the network device 110. The network device 110 may enable sending an instruction 215 (e.g., a handover command) to the terminal device 120 when the radio conditions are still good and earlier than when the conditions start to deteriorate as in the normal handover. When receiving the handover command, the terminal device 120 may store the handover command instead of immediately applying the handover command. In fact, the terminal device 120 may apply the stored handover command only if the conditions set in the terminal device 120 are met for one of the set candidate target cells (e.g., cell 135 in the exemplary scenario of FIG. 1A), and the terminal device 120 can then perform the handover and connect to the target network device 130 as in a normal handover.

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

[0079] As another example, the fourth type of trigger condition may be that multiple (e.g., two) execution conditions are set for the target cell 135. The multiple set execution conditions for the target cell 135 may mean that not all of the multiple execution conditions are satisfied for the handover of the terminal device 120 to the target cell 135. Thus, such trigger conditions for multiple execution conditions may trigger the terminal device 120 to collect information related to the conditional handover and report the collected information to the 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 and / or the target network device 130 can improve future conditional handovers with the multiple execution conditions based on the handover success report triggered by the trigger conditions for multiple execution conditions.

[0080] Returning to FIG. 2, after determining the trigger information based on the set of trigger conditions 125 (230), the terminal device 120 may perform different operations related to the handover success report based on the determined trigger information. In some embodiments, the terminal device 120 may determine to trigger a handover success report for a handover from the cell 115 to the 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. For this purpose, the terminal device 120 may collect information to be reported in the handover success report (240) before or during the handover from the cell 115 to the cell 135. This allows the information to be collected in the handover success report only when the handover success report is triggered, thereby avoiding unnecessary collection of information for all successful handovers.

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

[0082] In general, 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 (240) by the terminal device 120 and included in the handover success report may include RLM-related information, BFD-related information, handover-related information, etc. In some embodiments, it is desirable for the content of the handover success report to be more comprehensive and comprehensive. Thus, after receiving the informative handover success report, the source network device 110 or the target network device 130 can obtain more useful information related to various aspects of the handover, and can improve the performance of future handovers more effectively and efficiently.

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

[0084] In some embodiments, the first type of information may be stored and reported by the terminal device 120 in a handover success report if one or more first type trigger conditions are met before or during handover of the terminal device 120. In other words, if the terminal device 120 detects that a trigger condition related to an LBT process is met before or during handover, the terminal device 120 may collect information related to the LBT procedure to be included in the handover success report. In this way, the information collected by the terminal device 120 for the handover success report may 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 met trigger conditions.

[0085] In some embodiments, the first type of information may include an indication of a persistent LBT failure. Thus, upon receiving the handover success report provided by the terminal device 120, the source network device 110 may 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 the terminal device initiated in the cell 115 to avoid persistent LBT failures associated with the terminal device.

[0086] Additionally or alternatively, the first type of information may include information about one or more bandwidth parts (BWPs) at which persistent LBT failures are triggered. Thus, upon receiving a handover success report provided by the terminal device 120, the network device 110 can obtain BWP information about persistent LBT failures from the handover success report. This allows the network device 110 to optimize future handovers of the terminal device initiated in the cell 115 to avoid persistent LBT failures in these BWPs.

[0087] Additionally or alternatively, the first type of information may include the BWPs in the order in which the successive LBT failure recovery is performed. Thus, upon receiving the handover success report provided by the terminal device 120, the network device 110 can obtain the aligned BWP information for the successive LBT failure recovery from the handover success report. This allows the network device 110 to optimize future handovers of the terminal device initiated in the cell 115 to avoid the successive LBT failures in these BWPs.

[0088] Additionally or alternatively, the first type of information may include a value of a counter for counting the number of LBT failures. Thus, upon receiving the handover success report provided by the terminal device 120, the network device 110 may determine the value of the counter from the handover success report. This allows the network device 110 to determine the severity of the LBT failure, such as how many times the LBT failed when performing a handover, and to evaluate the congestion of the unlicensed spectrum. Based on this, the network device 110 may optimize the use of the licensed spectrum, for example, to allocate fewer BWPs to terminal devices where LBT failures occur. In some embodiments, the counter for counting the number of LBT failures may be LBT_COUNTER, as defined in the relevant 3GPP specifications.

[0089] Additionally or alternatively, the first type of information may include a value of a timer for continuous LBT failure detection. Thus, upon receiving a handover success report provided by the terminal device 120, the network device 110 may obtain the value of the timer from the handover success report. This allows the network device 110 to determine the severity of the LBT failure, such as how long it has been since the last LBT failure, when performing a handover, and to evaluate the congestion level of the unlicensed spectrum. Based on this, the network device 110 may optimize the use of the licensed spectrum, for example, allocating fewer BWPs to terminal devices where LBT failures occur. In some embodiments, the timer may be the lbt-FailureDetectionTimer defined in the relevant 3GPP specifications.

[0090] As another example, for the handover success report, the terminal device 120 may collect a second type of information related to the MCG link recovery associated with the terminal device. In general, the second type of information may be any suitable information of the MCG link recovery that can reflect a problem in the MCG link recovery. For example, the terminal device 120 may store the MCG RLF related information in the handover success report. Thereby, when the MCG recovery by handover is successful, the terminal device 120 can report the MCG failure information to the network, so that the network can analyze and improve the performance of the fast MCG recovery.

[0091] In some embodiments, the second type of information may be stored and reported by the terminal device 120 in a handover success report if one or more second type trigger conditions are met before or during handover of the terminal device 120. In other words, if the terminal device 120 detects that a trigger condition related to fast MCG link recovery is met before or during handover, the terminal device 120 may collect information related to fast MCG link recovery to be included in the handover success report. In this way, the information collected by the terminal device 120 for the handover success report may 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 met trigger conditions.

[0092] In some embodiments, the second type of information may include the duration from the detection of the MCG RLF to the completion of the handover, i.e., the time elapsed from the MCG connection failure to the successful handover, which may represent the interruption time of the ongoing service of the MCG. Thus, upon receiving the handover success report provided by the terminal device 120, the network device 110 may obtain the duration from the handover success report. This allows the network device 110 to analyze the performance of the fast MCG recovery by handover and determine whether optimization for the fast MCG recovery is required.

[0093] Additionally or alternatively, the second type of information may include a value of a timer representing the duration of the MCG link recovery, e.g., the value of the T316 timer at the time of stopping, which may indicate how long the recovery process takes. Thus, upon receiving a handover success report provided by the terminal device 120, the network device 110 may obtain the timer value from the handover success report. This allows the network device 110 to analyze the performance of the fast MCG recovery via handover and determine whether optimization on the fast MCG recovery settings is required.

[0094] Additionally or alternatively, the second type of information may include an indication of MCG RLF or an RLF report of the MCG. For example, the 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 the handover success report provided by the terminal device 120, the network device 110 may obtain the indication of MCG RLF or the RLF report of the MCG from the handover success report. This allows the network device 110 to optimize future handovers of the terminal device initiated in the cell 115 to avoid the MCG RLF.

[0095] Additionally or alternatively, the second type of information may include an indication in the MCG link recovery on whether to use SRB3 or a split SRB1 SCG link. Thus, upon receiving the handover success report provided by the terminal device 120, the network device 110 may obtain the indication from the handover success report. This allows the network device 110 to optimize future handovers of the terminal device initiated in the cell 115 to improve the configuration of SRB3 and split SRB1.

[0096] As another example, for the handover success report, if the handover is a DAPS handover, the terminal device 120 may collect a third type of information related to the RLF on the source cell 115 during the handover. In other words, the terminal device 120 may store the source RLF-related information in the handover success report, so that the service interruption during the DAPS handover is reported to the network, enabling the network to analyze and enhance the performance of the DAPS handover.

[0097] In some embodiments, the third type of information may be stored and reported by the terminal device 120 in a handover success report if one or more third type trigger conditions are met before or during handover of the terminal device 120. In other words, if the terminal device 120 detects that a trigger condition related to a DAPS handover is met before or during handover, the terminal device 120 may collect information related to the DAPS handover to be included in the handover success report. In this way, the information collected by the terminal device 120 for the handover success report may 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 met trigger conditions.

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

[0099] As another example, for a handover success report, if the handover is a conditional handover, the terminal device 120 may collect a fourth type of information. In general, the fourth type of information may be any suitable information of the conditional handover that can reflect a problem 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 configuration of the conditional handover. For example, the source network device 110 can avoid setting a CHO candidate cell with low signal strength and / or can avoid setting an execution condition that is not triggered.

[0100] In some embodiments, the fourth type of information may be stored and reported by the terminal device 120 in a handover success report if one or more fourth type trigger conditions are met before or during handover of the terminal device 120. In other words, if the terminal device 120 detects that a trigger condition related to a conditional handover is met before or during handover, the terminal device 120 may collect information related to the conditional handover to be included in the handover success report. In this way, 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 met trigger conditions.

[0101] In some embodiments, the fourth type of information may include identities of multiple CHO candidate cells, including the target cell 135. Thus, upon receiving the handover success report provided by the terminal device 120, the network device 110 may obtain identities of the multiple CHO candidate cells from the handover success report, thereby enabling the network device 110 to optimize future conditional handovers of the terminal device initiated in the cell 115 to improve the CHO candidate cells.

[0102] Additionally or alternatively, the fourth type of information may include measurement results of the plurality of CHO candidate cells. Thus, upon receiving the handover success report provided by the terminal device 120, the network device 110 can obtain the measurement results of the plurality of CHO candidate cells from the handover success report. This allows the network device 110 to optimize future conditional handovers of the terminal device initiated in the cell 115 to improve the CHO candidate cell.

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

[0104] Additionally or alternatively, the fourth type of information may include the fulfilled execution conditions of the target cell 135, such as, for example, measId, event ID, trigger threshold, trigger offset, hysteresis value, timToTrigger value, etc. Thus, upon receiving the handover success report provided by the terminal device 120, the network device 110 can derive the fulfilled execution conditions from the handover success report, thereby enabling the network device 110 to optimize future conditional handovers of the terminal device initiated in the cell 115 and improve the configuration of the execution conditions of the multiple CHO candidate cells.

[0105] As another example, for the handover success report, the terminal device 120 can collect a fifth type of information related to time information of the handover. The handover time information in the handover success report provided by the terminal device 120 allows the network to know the time of the handover event corresponding to the handover success report, and obtains the time information of the handover success event, so as to improve the configuration of future handovers.

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

[0107] Thus, the duration 415 may represent the duration for which the handover is performed, i.e. the value of the timer T304 defined in the relevant 3GPP specifications. The duration 425 may represent the duration from the completion of the handover until a handover success report is sent to the target network device 130 or another network device, i.e. the time elapsed from the handover success until a handover success report is obtained for the handover. The duration 435 may represent the duration from the start of the handover 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 a handover success report is obtained for the handover.

[0108] In some embodiments, the fifth type of information may include a duration 435 from when the handover is initiated until the 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 when the handover is completed until the handover success report is sent to the target network device 130 or another network device. For example, when the terminal device 120 receives a UEInformationRequest requesting a handover success report, the terminal device 120 may store the time elapsed since the handover initiation or the time elapsed since the handover success (e.g., to build a timeline of handover events) in the reported handover success report. The 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, terminal device 120 may store and report absolute time information about when handover was initiated or successful. For example, the fifth type of information may include the time when handover was initiated 410. Additionally or alternatively, the fifth type of information may include the time when handover is completed 420.

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

[0111] Above, several embodiments have been described in which the terminal device can be configured with different trigger conditions for handover success reporting and different types of information to be reported in the handover success reporting. In the following, several other embodiments are described which can support handover success reporting for inter-RAT handover of the terminal device.

[0112] Conventional handover success reporting can only be supported for intra-RAT handover. However, the inventors have discovered that by supporting handover success reporting, the performance of inter-RAT handover can also obtain the same benefits. Therefore, some embodiments of the present disclosure support handover success reporting for inter-RAT handover, e.g., NR to LTE handover. With reference to FIG. 1A, the handover success reporting for inter-RAT handover is described in more detail.

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

[0114] In some embodiments, the first RAT may be NR and the second RAT may be LTE. Thus, inter-RAT handover success reporting may be supported for network devices based on up to two primary RATs. In these embodiments, upon receiving the mobilityFromNRCommand, the terminal device 120 may check the set of trigger conditions 125 for handover success reporting. 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 a 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 or similar as 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 report in the handover success report. The cell identity may 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, the inter-RAT handover success report may be implicitly indicated by the cell identity in LTE. For example, the CGI may be the E-UTRA CGI of the terminal device 120.

[0115] In some embodiments, the source network device 110 may determine configuration information regarding whether to support inter-RAT handover success reporting. Then, the source network device 110 may transmit the configuration information to the terminal device 120. In this way, the network device 110 can flexibly control the configuration of the inter-RAT handover success reporting in the cell 115. In these embodiments, returning to FIG. 2, when determining trigger information regarding the handover success reporting (230), if the terminal device 120 receives configuration information from the source network device 110 indicating that the handover success reporting is supported for the inter-RAT handover, the terminal device 120 may further determine the trigger information, i.e., whether to trigger 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 allows the configuration information to be more available to the terminal device in the cell 115. Alternatively or additionally, the configuration information may be transmitted via a handover command message that causes the terminal device 120 to perform the handover. In this way, the configuration information can be determined specifically for a particular terminal device or for a particular handover.

[0116] In some embodiments, the configuration information may be common to the set of trigger conditions 125. In other words, one inter-RAT handover success report may be configured based on all trigger conditions. In this way, the configuration of the trigger conditions for the inter-RAT handover success report can be simplified. Alternatively, the configuration information may be information specific to one of the set of trigger conditions 125. In other words, the inter-RAT handover success report can be configured for each trigger condition. In this way, the inter-RAT handover success report can be flexibly and selectively generated for one or more of the set of trigger conditions 125.

[0117] 5 illustrates another example communication process 500 between a network device 110 and a terminal device 120, according to some embodiments of the present disclosure. In the example communication process 500, the network device 110 may first send configuration information to the terminal device 120 via system information 515 of the 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 handover success reporting is supported for inter-RAT handover and the network device 110 sends an indication 535 for inter-RAT handover (530), the terminal device 120 can determine trigger information for inter-RAT handover (550) after receiving the indication 535 (540).

[0118] Furthermore, if the terminal device 120 determines to trigger a handover success report for the inter-RAT handover, the terminal device 120 may collect information to be reported in the handover success report (560). Conversely, if the terminal device 120 determines not to trigger a handover success report for the inter-RAT handover, the terminal device 120 may avoid collecting 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 the inter-RAT handover, the terminal device 120 may avoid generating a handover success report without further determining the trigger information.

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

[0120] Furthermore, if the terminal device 120 determines to trigger a handover success report for the inter-RAT handover, the terminal device 120 may collect information to be reported in the handover success report (640). Conversely, if the terminal device 120 determines not to trigger a handover success report for the inter-RAT handover, the terminal device 120 may avoid collecting 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 the inter-RAT handover, the terminal device 120 may avoid generating a handover success report without further determining the trigger information.

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

[0122] In block 710, the terminal device 120 receives an instruction from a first network device 110 providing a first cell 115 to perform a handover of the terminal device 120 from the first cell 115 to a second cell 135 of a second network device 130. In block 720, the terminal device 120 determines trigger information for a handover success report of the handover based on a set of trigger conditions, the trigger information indicating whether 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 a fast 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: a persistent LBT fault during the LBT process is triggered and not canceled; and an LBT counter for counting the number of LBT faults during the LBT process is greater than a predetermined threshold.

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

[0126] In some embodiments, the third type of triggering condition may include 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: a plurality of CHO candidate cells including the second cell 135 are set; and a plurality of execution conditions are set for the second cell 135.

[0128] In some embodiments, if a handover success report is triggered for the handover, terminal device 120 may 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, terminal device 120 may avoid collecting information for the handover success report.

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

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

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

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

[0134] In some embodiments, the third type of information may include the duration from when an RLF is detected in the first cell 115 until the DAPS handover is completed.

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

[0136] In some embodiments, the fifth type of information may include at least one of: a duration from when the handover is initiated until a handover success report is sent to the second network device 130 or another network device; a duration from when the handover is completed until a handover success report is sent to the second network device 130 or another network device; a time when the handover is initiated; and a 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 that is different from the first RAT.

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

[0139] In some embodiments, when determining the 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 the 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 in system information of the first cell 115 and / or in a handover command message that causes the terminal device 120 to perform the 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 information specific to one of the set of trigger conditions.

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

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

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

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

[0146] According to an embodiment of the present disclosure, a terminal device comprises a circuit configured to receive 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 determine trigger information regarding a handover success report of the handover based on a set of trigger conditions, the trigger information indicating whether 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 a fast 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: a persistent LBT fault during the LBT process is triggered and not canceled; and an LBT counter for counting the number of LBT faults during the LBT process is greater than a predetermined threshold.

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

[0150] In some embodiments, the third type of triggering condition may include 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: a plurality of CHO candidate cells including the second cell 135 are set; and a plurality of execution conditions are set for the second cell 135.

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

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

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

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

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

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

[0158] In some embodiments, the third type of information may include the duration from when an RLF is detected in the first cell 115 until the DAPS handover is completed.

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

[0160] In some embodiments, the fifth type of information may include at least one of: a duration from when the handover is initiated until a handover success report is sent to the second network device 130 or another network device; a duration from when the handover is completed until a handover success report is sent to the second network device 130 or another network device; a time when the handover is initiated; and a 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 that is different from the first RAT.

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

[0163] In some embodiments, the circuitry is further configured to determine the trigger information when the terminal device 120 receives configuration information from the first network device 110 indicating that a handover success report is supported for the handover as an inter-RAT handover.

[0164] In some embodiments, the configuration information may be carried in system information of the first cell 115 and / or in a handover command message that causes the terminal device 120 to perform the 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 information specific to one of the set of trigger conditions.

[0166] According to an embodiment of the present disclosure, a network device comprises a circuit configured to send configuration information to a terminal device indicating whether 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 being provided by the network device based on a first RAT and the second cell being based on a second RAT different from the first RAT.

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

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

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

[0170] As shown, the apparatus 900 comprises a processor 910, a memory 920 coupled to the processor 910, a suitable transmitter (TX) and receiver (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 a 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 nodes referred to herein may in practice have multiple antennas. The communication interface may represent any interface required 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 an Uu interface for communication between a gNB or eNB and a terminal device.

[0171] The program 930 is deemed to include program instructions that, when executed by an associated processor 910, enable the device 900 to operate according to embodiments of the present disclosure, as described herein with reference to any of Figures 1 to 8. The embodiments herein may be realized by computer software executable by the processor 910 of the device 900, or 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, the combination of the processor 910 and the memory 920 may form a processing means 950 suitable for implementing various embodiments of the present disclosure.

[0172] The 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, by way of non-limiting example, non-transitory computer-readable storage media, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. Although only one memory 920 is shown in the device 900, there may be several physically different memory modules in the device 900. The processor 910 may be of any type suitable for a local technology network and may include, by way of non-limiting example, one or more of a general purpose computer, a special purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture. The device 900 may have multiple processors, for example application specific integrated circuit chips time-slaved to a clock that synchronizes the main processor.

[0173] The components included in the device and / or apparatus of the present disclosure can be realized in various ways, including software, hardware, firmware, or any combination thereof. In some embodiments, one or more units may be realized using software and / or firmware, such as machine-executable instructions stored on a storage medium. In addition to or in lieu of machine-executable instructions, some or all of the units in the device and / or apparatus may be implemented, at least in part, by one or more hardware logic components. By way of example and not limitation, exemplary types of hardware logic components that may be used include field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0174] Overall, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic, or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of the present disclosure have been illustrated and described using block diagrams, flow charts, or some other pictorial representations, it should be understood that the blocks, devices, systems, techniques, or methods described herein can be implemented, by way of non-limiting examples, in hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing device, or any combination thereof.

[0175] The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions included in a program module, that execute in a device on a target real or virtual processor to perform a process or method described above with reference to any one of Figures 2, 5-8. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In various embodiments, the functionality of the program modules may be combined or split between program modules as desired. The machine-executable instructions of the program modules may be executed in local or distributed devices. In a distributed device, the program modules may be located in both local and remote storage media.

[0176] Program codes for carrying out the methods of the present 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 special purpose computer, or other programmable data processing device, and when executed by the processor or controller, the program code causes the functions / acts specified in the flowcharts and / or block diagrams to be implemented. The program code may run entirely on the machine, partially on the machine, as a separate software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0177] The above program code may be implemented on a machine-readable medium, which may be any tangible medium that can contain or store a program 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, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or apparatus, or any suitable combination of the aforementioned media. More specific examples of machine-readable storage media may include an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable optical disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

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

[0179] Although the present disclosure has been described in language specific to structural features and / or methodological acts, it should be understood that the present disclosure, as defined in the appended claims, is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A method performed by a terminal device, comprising: Sending a Master Cell Group (MCG) fault information message; receiving a radio resource control (RRC) reconfiguration message including a reconfigurationWithSync; storing time information regarding the MCG recovery procedure in the first report; method.

2. The time information is associated with a time at which a timer T316 is stopped. The method of claim 1.

3. and receiving a second message for requesting a handover success report; In response to receiving the second message, storing the time that has elapsed since the successful completion of the handover in a handover success report variable. The method of claim 1.

4. 1. A method performed by a network device, comprising: Receive a master cell group (MCG) fault information message; sending a radio resource control (RRC) reconfiguration message including a reconfigurationWithSync; receiving time information regarding the MCG recovery procedure in a first report; method.

5. The time information is associated with a time at which a timer T316 is stopped. The method according to claim 4.

6. and sending a second message to request a handover success report. receiving in a handover success report variable the time that has elapsed since the successful completion of the handover; The method according to claim 4.

7. means for transmitting a master cell group (MCG) fault information message; means for receiving a radio resource control (RRC) reconfiguration message including a reconfigurationWithSync; means for storing time information relating to the MCG recovery procedure in a first report; A terminal device comprising:

8. The time information is associated with a time at which a timer T316 is stopped. The terminal device according to claim 7.

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

10. means for receiving a master cell group (MCG) fault information message; means for transmitting a radio resource control (RRC) reconfiguration message including a reconfigurationWithSync; means for receiving in a first report time information relating to an MCG recovery procedure; A network device comprising:

11. The time information is associated with a time at which a timer T316 is stopped. The network device according to claim 10.

12. means for transmitting a second message for requesting a handover success report; means for receiving in a handover success report variable a time that has elapsed since successful completion of the handover; The network device of claim 10 further comprising:

Images