Node and user equipment in wireless communication system and method performed by the same

Abstract

The present disclosure provides a node and a user equipment in a wireless communication system and methods performed by the same. A method performed by a base station in a wireless communication system, the method comprising: performing L1 / L2-triggered mobility (LTM) procedure; in case that the LTM procedure is failed, performing a cause analysis for the failed LTM procedure; and performing self-optimization based on a failure type identified based on the cause analysis, wherein the failure type includes wrong selection of candidate LTM cell and inappropriate cell switch triggering.

Description

NODE AND USER EQUIPMENT IN WIRELESS COMMUNICATION SYSTEM AND METHOD PERFORMED BY THE SAME

[0001] The present disclosure relates to a technical field of wireless communication, and more specifically, to a node and a user equipment in a wireless communication system and methods performed by the same.

[0002] In order to meet an increasing demand for wireless data communication services since a deployment of 4G communication system, efforts have been made to develop an improved 5G or pre-5G communication system. Therefore, the 5G or pre-5G communication system is also called "beyond 4G network" or "post LTE system".

[0003] Wireless communication is one of the most successful innovations in modern history. Recently, a number of subscribers of wireless communication services has exceeded 5 billion, and it continues growing rapidly. With the increasing popularity of smart phones and other mobile data devices (such as tablet computers, notebook computers, netbooks, e-book readers and machine-type devices) in consumers and enterprises, a demand for wireless data services is growing rapidly. In order to meet rapid growth of mobile data services and support new applications and deployments, it is very important to improve efficiency and coverage of wireless interfaces.

[0004] A node can collect a successful handover report from a UE for self-optimization of handover and the like.

[0005] In L1 / L2-triggered mobility (LTM), the UE transmits a random access preamble to a target node before handover, and the target node obtains a Timing Advance (TA) value and forwards it to a source node. The source node transmits the obtained TA value to the UE when transmitting a handover command, and the UE can directly access the target node based on the TA value, thereby realizing uninterrupted handover.

[0006] At present, there is no self-optimization mechanism based on LTM. In order to improve the performance, an enhanced self-optimization scheme is needed.

[0007] 5th generation (5G) or new radio (NR) mobile communications is recently gathering increased momentum with all the worldwide technical activities on the various candidate technologies from industry and academia. The candidate enablers for the 5G / NR mobile communications include massive antenna technologies, from legacy cellular frequency bands up to high frequencies, to provide beamforming gain and support increased capacity, new waveform (e.g., a new radio access technology (RAT)) to flexibly accommodate various services / applications with different requirements, new multiple access schemes to support massive connections, and so on.

[0008] 5G mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in "Sub 6GHz" bands such as 3.5GHz, but also in "Above 6GHz" bands referred to as mmWave including 28GHz and 39GHz. In addition, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in terahertz bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

[0009] At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of BWP (BandWidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

[0010] Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as V2X (Vehicle-to-everything) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, NR-U (New Radio Unlicensed) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

[0011] Moreover, there has been ongoing standardization in air interface architecture / protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, IAB (Integrated Access and Backhaul) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (2-step RACH for NR). There also has been ongoing standardization in system architecture / service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.

[0012] As 5G mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with eXtended Reality (XR) for efficiently supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) and the like, 5G performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.

[0013] A method performed by a base station in a wireless communication system, the method comprising: performing L1 / L2-triggered mobility (LTM) procedure; in case that the LTM procedure is failed, performing a cause analysis for the failed LTM procedure; and performing self-optimization based on a failure type identified based on the cause analysis, wherein the failure type includes wrong selection of candidate LTM cell and inappropriate cell switch triggering.

[0014] A base station in a wireless communication system, the base station comprising: a transceiver; and a controller coupled with the transceiver and configured to: perform L1 / L2-triggered mobility (LTM) procedure, in case that the LTM procedure is failed, perform a cause analysis for the failed LTM procedure, perform self-optimization based on a failure type identified based on the cause analysis, and wherein the failure type includes wrong selection of candidate LTM cell and inappropriate cell switch triggering.

[0015] The above and other aspects, features and advantages of certain embodiments of the present disclosure will be more apparent from the following description taken in conjunction with the accompanying drawings, in which:

[0016] FIG. 1 is an exemplary system architecture 100 of System Architecture Evolution (SAE);

[0017] FIG. 2 is an exemplary system architecture 200 according to various embodiments of the present disclosure;

[0018] FIGs. 3A-3H respectively show schematic diagrams of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure;

[0019] FIG. 4 shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure;

[0020] FIGs. 5A-5B respectively show schematic diagrams of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure;

[0021] FIGs. 6A-6K respectively show schematic diagrams of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure;

[0022] FIG. 7 shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure;

[0023] FIGs. 8A-8B respectively show schematic diagrams of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure;

[0024] FIG. 9 shows a flowchart of a method performed by a first node in a wireless communication system according to embodiments of the present disclosure;

[0025] FIG. 10 shows a flowchart of a method performed by a user equipment in a wireless communication system according to embodiments of the present disclosure;

[0026] FIG. 11 shows a flowchart of a method performed by a second node in a wireless communication system according to embodiments of the present disclosure;

[0027] FIG. 12 shows a schematic diagram of a node according to embodiments of the present disclosure; and

[0028] FIG. 13 shows a schematic diagram of a user equipment according to embodiments of the present disclosure.

[0029] Embodiments of the present disclosure provide a method performed by a first node in a wireless communication system, which includes: transmitting a third message to a user equipment (UE) or a second node, wherein the third message includes configuration information associated with L1 / L2-triggered mobility (LTM) successful handover information, wherein the configuration information associated with the LTM successful handover information includes one or more of: a Timing Advance (TA) value expires, access cannot be performed based on a first TA value, access is performed based on a random access process, and the first TA value is invalid;

[0030] receiving a sixth message from a second node, wherein the sixth message includes the LTM successful handover information; and performing corresponding configuration change based on the LTM successful handover information.

[0031] According to embodiments of the present disclosure, the LTM successful handover information includes one or more of: an identification of that access is performed based on a random access process, the first TA value, a second TA value, an identification that the first TA value is invalid, an identification of that access cannot be performed based on the first TA value, a first measurement result, a second measurement result, an LTM handover identification and LTM command information.

[0032] According to embodiments of the present disclosure, the method further includes: determining whether the first TA value is invalid based on the first TA value and a second TA value.

[0033] According to embodiments of the present disclosure, the method further includes: determining whether the first TA value is invalid based on a first measurement result and / or a second measurement result.

[0034] According to embodiments of the present disclosure, the performing corresponding configuration change based on the LTM successful handover information further comprises: when determining the first TA value to be invalid based on the LTM successful handover information, changing a valid time of the first TA value.

[0035] According to embodiments of the present disclosure, the first TA value is a TA value in an LTM command, and the second TA value is a TA value obtained based on a random access process.

[0036] According to embodiments of the present disclosure, the first measurement result is a Layer 1 measurement result and the second measurement result is a Layer 3 measurement result.

[0037] Embodiments of the present disclosure provide a method performed by a user equipment (UE) in a wireless communication system, which includes: receiving a third message from a first node or a second node, wherein the third message includes configuration information associated with L1 / L2-triggered mobility (LTM) successful handover information, wherein the configuration information associated with the LTM successful handover information includes one or more of: a Timing Advance (TA) value expires, access cannot be performed based on a first TA value, access is performed based on a random access process, and the first TA value is invalid; and transmitting a sixth message to the second node or a third node, wherein the sixth message includes the LTM successful handover information.

[0038] According to embodiments of the present disclosure, the method further includes: saving the LTM successful handover information in case that the configuration information associated with the LTM successful handover information is met in a handover process.

[0039] According to embodiments of the present disclosure, the method further includes: when the UE performs an LTM handover, including an LTM handover identification and / or LTM command information in the LTM successful handover information.

[0040] According to embodiments of the present disclosure, the method further includes: when the UE cannot perform access based on the first TA value and hands over to the third node through random access, including one or more of the following in the LTM successful handover information: an identification of that access is performed based on a random access process, the first TA value, a second TA value, an identification that the first TA value is invalid, an identification of that access cannot be performed based on the first TA value, a first measurement result, a second measurement result.

[0041] According to embodiments of the present disclosure, the method further includes: determining whether the first TA value is invalid based on the first TA value and a second TA value.

[0042] According to embodiments of the present disclosure, the method further includes: determining whether the first TA value is invalid based on a first measurement result and / or a second measurement result.

[0043] According to embodiments of the present disclosure, the first TA value is a TA value in an LTM command, and the second TA value is a TA value obtained based on a random access process.

[0044] According to embodiments of the present disclosure, the first measurement result is a Layer 1 measurement result and the second measurement result is a Layer 3 measurement result.

[0045] Embodiments of the present disclosure provide a method performed by a second node in a wireless communication system, which includes: receiving a third message from a first node, wherein the third message includes configuration information associated with L1 / L2-triggered mobility (LTM) successful handover information, wherein the configuration information associated with the LTM successful handover information includes one or more of: a Timing Advance (TA) value expires, access cannot be performed based on a first TA value, access is performed based on a random access process, and the first TA value is invalid; transmitting the configuration information to a user equipment (UE); receiving a sixth message from the UE or a third node, wherein the sixth message includes the LTM successful handover information; and transmitting the LTM successful handover information to the first node.

[0046] According to embodiments of the present disclosure, the LTM successful handover information includes one or more of: an identification of that access is performed based on a random access process, the first TA value, a second TA value, an identification that the first TA value is invalid, an identification of that access cannot be performed based on the first TA value, a first measurement result, a second measurement result, an LTM handover identification and LTM command information.

[0047] Embodiments of the present disclosure provide a first node device in a wireless communication system, including: a transceiver configured to transmit and receive signals; and a processor coupled to the transceiver and configured to perform methods performed by a first node in a wireless communication system according to embodiments of the present disclosure.

[0048] Embodiments of the present disclosure provide a second node device in a wireless communication system, including: a transceiver configured to transmit and receive signals; and a processor coupled to the transceiver and configured to perform methods performed by a second node in a wireless communication system according to embodiments of the present disclosure.

[0049] Embodiments of the present disclosure provide a user equipment (UE) in a wireless communication system, including: a transceiver configured to transmit and receive signals; and a processor coupled to the transceiver and configured to perform methods performed by a user equipment (UE) in a wireless communication system according to embodiments of the present disclosure.

[0050] Embodiments of the present disclosure provide a computer-readable medium having stored thereon computer-readable instructions which, when executed by a processor, perform methods performed by a first node and / or a second node and / or a user equipment in a wireless communication system according to embodiments of the present disclosure.

[0051] The methods performed by the first node and / or the second node and / or the user equipment in the wireless communication system provided by the present disclosure can support the nodes to perform self-optimization related to an LTM handover by exchanging LTM successful handover related information between the nodes and / or the user equipment.

[0052] Before undertaking the DETAILED DESCRIPTION below, it may be advantageous to set forth definitions of certain words and phrases used throughout this patent document. The term "couple" and its derivatives refer to any direct or indirect communication between two or more elements, whether or not those elements are in physical contact with one another. The terms "transmit," "receive," and "communicate," as well as derivatives thereof, encompass both direct and indirect communication. The terms "include" and "comprise," as well as derivatives thereof, mean inclusion without limitation. The term "or" is inclusive, meaning and / or. The phrase "associated with," as well as derivatives thereof, means to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, have a relationship to or with, or the like. The term "controller" means any device, system or part thereof that controls at least one operation. Such a controller may be implemented in hardware or a combination of hardware and software and / or firmware. The functionality associated with any particular controller may be centralized or distributed, whether locally or remotely. The phrase "at least one of," when used with a list of items, means that different combinations of one or more of the listed items may be used, and only one item in the list may be needed. For example, "at least one of: A, B, and C" includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A and B and C.

[0053] Moreover, various functions described below can be implemented or supported by one or more computer programs, each of which is formed from computer readable program code and embodied in a computer readable medium. The terms "application" and "program" refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof adapted for implementation in a suitable computer readable program code. The phrase "computer readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer readable medium" includes any type of medium capable of being accessed by a computer, such as read only memory (ROM), random access memory (RAM), a hard disk drive, a compact disc (CD), a digital video disc (DVD), or any other type of memory. A "non-transitory" computer readable medium excludes wired, wireless, optical, or other communication links that transport transitory electrical or other signals. A non-transitory computer readable medium includes media where data can be permanently stored and media where data can be stored and later overwritten, such as a rewritable optical disc or an erasable memory device.

[0054] Definitions for other certain words and phrases are provided throughout this patent document. Those of ordinary skill in the art should understand that in many if not most instances, such definitions apply to prior as well as future uses of such defined words and phrases.

[0055] The following description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of various embodiments of the present disclosure as defined by the claims and their equivalents. It includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the various embodiments described herein can be made without departing from the scope and spirit of the present disclosure. In addition, descriptions of well-known functions and constructions may be omitted for clarity and conciseness.

[0056] The terms and words used in the following description and claims are not limited to the bibliographical meanings, but, are merely used by the inventor to enable a clear and consistent understanding of the present disclosure. Accordingly, it should be apparent to those skilled in the art that the following description of various embodiments of the present disclosure is provided for illustration purpose only and not for the purpose of limiting the present disclosure as defined by the appended claims and their equivalents.

[0057] It is to be understood that the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to "a component surface" includes reference to one or more of such surfaces.

[0058] The term "include" or "may include" refers to the existence of a corresponding disclosed function, operation or component which can be used in various embodiments of the present disclosure and does not limit one or more additional functions, operations, or components. The terms such as "include" and / or "have" may be construed to denote a certain characteristic, number, step, operation, constituent element, component or a combination thereof, but may not be construed to exclude the existence of or a possibility of addition of one or more other characteristics, numbers, steps, operations, constituent elements, components or combinations thereof.

[0059] The term "or" used in various embodiments of the present disclosure includes any or all of combinations of listed words. For example, the expression "A or B" may include A, may include B, or may include both A and B.

[0060] Unless defined differently, all terms used herein, which include technical terminologies or scientific terminologies, have the same meaning as that understood by a person skilled in the art to which the present disclosure belongs. Such terms as those defined in a generally used dictionary are to be interpreted to have the meanings equal to the contextual meanings in the relevant field of art, and are not to be interpreted to have ideal or excessively formal meanings unless clearly defined in the present disclosure.

[0061] Figures discussed below and various embodiments for describing the principles of the present disclosure in this patent document are only for illustration and should not be interpreted as limiting the scope of the present disclosure in any way. Those skilled in the art will understand that the principles of the present disclosure can be implemented in any suitably arranged system or device.

[0062] FIG. 1 is an exemplary system architecture 100 of system architecture evolution (SAE). User equipment (UE) 101 is a terminal device for receiving data. An evolved universal terrestrial radio access network (E-UTRAN) 102 is a radio access network, which includes a macro base station (eNodeB / NodeB) that provides UE with interfaces to access the radio network. A mobility management entity (MME) 103 is responsible for managing mobility context, session context and security information of the UE. A serving gateway (SGW) 104 mainly provides functions of user plane, and the MME 103 and the SGW 104 may be in the same physical entity. A packet data network gateway (PGW) 105 is responsible for functions of charging, lawful interception, etc., and may be in the same physical entity as the SGW 104. A policy and charging rules function entity (PCRF) 106 provides quality of service (QoS) policies and charging criteria. A general packet radio service support node (SGSN) 108 is a network node device that provides routing for data transmission in a universal mobile telecommunications system (UMTS). A home subscriber server (HSS)109 is a home subsystem of the UE, and is responsible for protecting user information including a current location of the user equipment, an address of a serving node, user security information, and packet data context of the user equipment, etc.

[0063] FIG. 2 is an exemplary system architecture 200 according to various embodiments of the present disclosure. Other embodiments of the system architecture 200 can be used without departing from the scope of the present disclosure.

[0064] User equipment (UE) 201 is a terminal device for receiving data. A next generation radio access network (NG-RAN) 202 is a radio access network, which includes a base station (a gNB or an eNB connected to 5G core network 5GC, and the eNB connected to the 5GC is also called ng-gNB) that provides UE with interfaces to access the radio network. An access control and mobility management function entity (AMF) 203 is responsible for managing mobility context and security information of the UE. A user plane function entity (UPF) 204 mainly provides functions of user plane. A session management function entity SMF 205 is responsible for session management. A data network (DN) 206 includes, for example, services of operators, access of Internet and service of third parties.

[0065] Nodes mentioned in the present disclosure may include: gNB, gNB Central Unit (gNB-CU), gNB Distributed Unit (gNB-DU), gNB Central Unit control plane (gNB-CU-CP), gNB Central Unit user plane (gNB CU-UP), en-gNB, eNB, ng-eNB, UE, Access and Mobility Management Function (AMF), Session Management Function (SMF), Mobility Management Entity (MME) and other network entities or network logic units.

[0066] The signal strength and / or signal quality described in the present disclosure may be a Received Signal Strength Indicator (RSSI), a Reference Signal Receiving Power, RSRP), a Reference Signal Receiving Quality (RSRQ), and a Signal to Interference plus Noise Ratio (SINR), etc.

[0067] In the present disclosure, a failure type and / or problem type may also be referred to as a report type.

[0068] In the present disclosure, reports related to a Self-Optimization Network (SON) may include one or more of the following: a Connection Establishment Failure (CEF) report, or a Random Access report, or a Successful Handover report, or a Radio Link Failure (RLF) report, or a measurement report, or other reports related to wireless connection.

[0069] In the present disclosure, radio link failure may include both radio link failure and handover failure.

[0070] In the present disclosure, a user equipment (UE) may also be referred to as a user.

[0071] In the present disclosure, invalid, ineffective and the like can also be used interchangeably.

[0072] In the present disclosure, a random access process may be a contention-based random access process, or a contention-free random access process.

[0073] In the present disclosure, an LTM command may also be a Cell switch command.

[0074] In the present disclosure, a TA in an LTM command and / or a TA obtained in an LTM command may also be a TA of early synchronization (Early Sync), a TA obtained by Early Sync, or a TA obtained in advance.

[0075] In the present disclosure, the wrong LTM handover cell selection may also be called handover to a wrong cell.

[0076] In the present disclosure, handover may also be referred to as Cell switch.

[0077] Example 1

[0078] In some implementations, the present disclosure provides a method for supporting mobility self-optimization, which may include: in some implementations, a second node transmits a first message containing a request for a failure type and / or problem type (for example, associated with radio link failure and handover failure, or associated with problems present in a successful handover, or associated with problems found by the second node during communication, etc.) to a first node. After receiving the request, the first node analyzes the failure type and / or problem type, and transmits an analysis result to the second node for the second node to perform self-optimization.

[0079] In some implementations, the first message may be included in one or more of the following: a HANDOVER REPORT message or an ACCESS AND MOBILITY INDICATION message or a FAILURE INDICATION message of Xn; or an other and / or newly defined RRC and / or Xn and / or X2 and / or F1 and / or E1 and / or NG message.

[0080] In some implementations, the first message and / or the request for a failure type and / or problem type may include one or more of the following fields or related information:

[0081] · UE identification (ID): which indicates the user corresponding to the request for the failure type and / or problem type and / or report type.

[0082] · Transmitting node ID: used to identify the node transmitting the message.

[0083] · Receiving node ID: used to identify the node receiving the message.

[0084] · Analysis result feedback time: a requirement for a feedback time of an analysis result. The first node needs to feed back the analysis result to the second node within the feedback time.

[0085] In some implementations, the first node may transmit a second message containing the failure type and / or problem type to the second node based on its own situation and / or based on the first message containing the request for the failure type and / or problem type received from the second node, and the second node may perform self-optimization after receiving the message, for example, optimize its own configuration, or forward it to other nodes for the other nodes to perform self-optimization operation. In some implementations, for a split architecture, for example, in L1 / L2-triggered mobility (LTM), a cause analysis can be performed by a gNB CU or a gNB DU. When the cause analysis is performed by the gNB CU, the analyzed failure type and / or problem type can be transmitted to the gNB DU when a relevant report is transmitted. If the cause analysis is to be performed by the gNB DU, the gNB DU may perform the cause analysis after receiving a relevant report, and transmit the analyzed failure type and / or problem type to the gNB CU. In some other implementations, for example, if a downlink transmission failure and / or resource allocation problem occurs in a target node, resulting in Handover Failure and / or Radio Link Failure, etc., the target node may inform the source node of a problem type and / or failure type, and the source node can base on or refer to the received problem type and / or failure type when subsequently performing a failure cause analysis and / or performing self-optimization. If the second node indicates an analysis result feedback time in the first message, the first node needs to return the analysis result within a range of the feedback time. For example, the gNB CU transmits a first message to the gNB DU, which includes an analysis result feedback time, the gNB DU needs to return the analyzed failure type and / or problem type to the gNB CU within the analysis result feedback time. When the analysis result feedback time is exceeded, the gNB CU may release the stored SON-related report and / or user context to avoid unnecessary content storage. In some other implementations, the gNB CU may maintain a time (for example, by means of a timer), and if an analyzed failure type and / or problem type is not received from the gNB DU within this time range, the gNB CU may release the stored SON-related report and / or user context to avoid unnecessary content storage.

[0086] In some implementations, the second message may be included in one or more of the following: a HANDOVER REPORT message or an ACCESS AND MOBILITY INDICATION message or a FAILURE INDICATION message of Xn; or an other and / or newly defined RRC and / or Xn and / or X2 and / or F1 and / or E1 and / or NG message.

[0087] In some implementations, the second message may include one or more of the following fields or related information:

[0088] · UE ID: which indicates the user corresponding to the failure type and / or problem type and / or report type.

[0089] · Transmitting node ID: used to identify the node transmitting the message.

[0090] · Receiving node ID: used to identify the node receiving the message.

[0091] · Failure type: used to indicate an analyzed failure type. The failure type may include one or more of the following: too early handover, too late handover, ping-pong handover, handover to a wrong cell, wrong LTM handover cell selection, wrong LTM candidate cell selection, TA value invalidation, TA value inconsistency, wrong TA value, downlink failure, downlink failure of the target node, a problem comes from the target node, a problem comes from the transmitting node of the second message, ID of the node where a problem occurs, a resource allocation problem, a resource allocation problem occurs at the target node, and a resource allocation problem occurs at the transmitting node of the second message, etc.

[0092] · Problem type: used to indicate an analyzed problem type. The problem type may include one or more of the following: too early handover, too late handover, ping-pong handover, handover to a wrong cell, wrong LTM handover cell selection, wrong LTM candidate cell selection, TA value invalidation, TA value inconsistency, wrong TA value, downlink failure, downlink failure of the target node, a problem comes from the target node, a problem comes from the transmitting node of the second message, ID of the node where a problem occurs, a resource allocation problem, a resource allocation problem occurs at the target node, and a resource allocation problem occurs at the transmitting node of the second message, etc.

[0093] · Report type: used to indicate an analyzed report type. The report type may include one or more of the following: too early handover, too late handover, ping-pong handover, handover to a wrong cell, wrong LTM handover cell selection, wrong LTM candidate cell selection, TA value invalidation, TA value inconsistency, wrong TA value, downlink failure, downlink failure of the target node, a problem comes from the target node, a problem comes from the transmitting node of the second message, ID of the node where a problem occurs, a resource allocation problem, a resource allocation problem occurs at the target node, and a resource allocation problem occurs at the transmitting node of the second message, etc.

[0094] · Configuration of conditional handover: which may include one or more of the following: (candidate) target cell identification, execution conditions corresponding to a (candidate) target cell, slices supported by a (candidate) target cell, and situation of Protocol Data Unit (PDU) sessions (resources) accepted by a (candidate) target cell, etc. The situation of PDU sessions (resources) accepted by the (candidate) target cell may include one or more of the following: PDU session identification, the number of accepted PDU sessions (resources), etc. In an implementation, for example, if the UE is (simultaneously) configured with a conditional handover and an LTM, the configuration of conditional handover needs to be added. The configuration of conditional handover can be used for a node to perform handover optimization, for example, to optimize the configuration of conditional handover and / or LTM, so as to improve the mobility robustness.

[0095] In LTM, the gNB CU may select one or more LTM candidate cells, and the gNB DU may select one of the one or more LTM candidate cells selected by the gNB CU as the handover target cell for the UE. The wrong LTM handover cell selection means that in LTM, the gNB DU mistakenly selects a cell to which UE is handed over. The wrong LTM handover cell selection may be that a radio link failure occurs in a short time after a successful handover from the source cell or a handover failure occurs during the handover, and the UE attempts to reestablish a radio link connection on a cell that is neither the source cell nor the target cell. The wrong LTM candidate cell selection means that in LTM, the gNB CU mistakenly selects cells that can be used for LTM handover, resulting in that the gNB DU cannot handover the UE to a suitable cell. The wrong LTM candidate cell selection may be that a radio link failure occurs in a short time after a successful handover from the source cell or a handover failure occurs during the handover, and the UE attempts to reestablish a radio link connection on a cell that is not the source cell, the target cell or the LTM candidate cell.

[0096] The TA value invalidation means that a TA value used for access is not applicable and / or the TA value has been invalid and / or the TA value has expired. The TA value inconsistency means that a TA value transmitted by a node to a user is not applicable to this user, and this TA value is applicable to other users. The wrong TA value indicates that a TA value used for access is wrong.

[0097] Among the failure types and / or problem types and / or report types, in the case of LTM, failure types and / or problem types and / or report types attributed to the gNB CU may include one or more of the following: wrong LTM candidate cell selection, ping-pong handover, handover to a wrong cell, downlink failure, downlink failure of the target node, a problem comes from the target node, a problem comes from the transmitting node of the second message, ID of the node where a problem occurs, a resource allocation problem, a resource allocation problem occurs at the target node, and a resource allocation problem occurs at the transmitting node of the second message, etc. Failure types and / or problem types and / or report types attributed to the gNB CU should be self-optimized by the gNB CU. Failure types and / or problem types and / or report types attributed to the gNB DU may include one or more of the following: too early handover, too late handover, ping-pong handover, handover to a wrong cell, wrong LTM handover cell selection, TA value invalidation, TA value inconsistency, wrong TA value, downlink failure, downlink failure of the target node, a problem comes from the target node, a problem comes from the transmitting node of the second message, ID of the node where a problem occurs, a resource allocation problem, a resource allocation problem occurs at the target node, and a resource allocation problem occurs at the transmitting node of the second message, etc. Failure types and / or problem types and / or report types attributed to the gNB DU should be self-optimized by the gNB DU.

[0098] When the second node receives information that the problem occurred at the first node and / or an other node, for example, when the second node receives information about downlink failure, downlink failure of the target node, a problem comes from the target node, a problem comes from the transmitting node of the second message, ID of the node where a problem occurs, a resource allocation problem, a resource allocation problem occurs at the target node, and a resource allocation problem occurs at the transmitting node of the second message, etc., the second node needs to consider the above information when performing self-optimization. In some implementations, for example, if the second node knows that the problem comes from the first node and / or an other node, the second node does not change and / or update its own configuration to avoid unnecessary change and / or update.

[0099] Example 2

[0100] In some implementations, the present disclosure provides a method for supporting mobility self-optimization, which may include: a third node transmits a third message containing information associated with an LTM successful handover information request and / or configuration to a fourth node. After receiving the message, the fourth node may transmit the request and / or configuration to other nodes and / or the UE. The fourth node may also be a UE. The UE can record related information of LTM handover in the LTM successful handover information, and report the LTM successful handover information to a node, and the node may perform self-optimization according to the information in the LTM successful handover information. For example, the UE records related information of LTM handover in the LTM successful handover information, and the node (gNB CU and / or gNB DU) can perform optimization for LTM according to the information in the LTM successful handover information. For example, when a UE cannot perform access based on a TA value obtained in advance, the UE performs random access to obtain synchronization information to complete the access. Although this handover is successful, service is interrupted due to the UE's random access. The above-mentioned mechanism of LTM successful handover information can avoid service interruption due to the UE's random access. The LTM successful handover information may be included in a Successful Handover Report (SHR). The LTM successful handover information may also be called an LTM successful handover report.

[0101] In some implementations, the third message may be included in one or more of the following: a UE CONTEXT MODIFICATION REQUIRED message of F1; an OtherConfig message or a successHO-Config message or a RRCReconfiguration message or a RRCResume message of RRC; or it may be transmitted by means of MAC CE; or an other and / or newly defined RRC and / or Xn and / or X2 and / or F1 and / or E1 and / or NG message.

[0102] In some implementations, the third message or information associated with the L1 / L2-triggered mobility (LTM) successful handover information request and / or configuration may include one or more of the following fields or related information:

[0103] · UE ID: which indicates the user corresponding to the LTM successful handover information request and / or configuration.

[0104] · Transmitting node ID: used to identify the node transmitting the message.

[0105] · Receiving node ID: used to identify the node receiving the message.

[0106] · LTM successful handover information request indication: used to indicate a request to collect and / or report LTM successful handover information.

[0107] · Information for triggering the generation and / or reporting of LTM successful handover information: used to indicate the information for triggering the generation and / or reporting of LTM successful handover information. When the information for triggering the generation and / or reporting of LTM successful handover information is met, the UE saves and / or generates and / or reports the LTM successful handover information. In some implementations, the information for triggering the generation and / or reporting of LTM successful handover information may be included in a successful handover report configuration which, for example, may be the successHO-Config. The information for triggering the generation and / or reporting of LTM successful handover information may include one or more of the following: TA expires, access cannot be performed based on a TA obtained in advance (or a TA in an LTM command), access is performed based on a random access process, the TA obtained in advance (or the TA in the LTM command) is invalid, a threshold value of a ratio of the time elapsed by a timer, and RLF occurs in a source primary cell (PCell) in a Dual Active Protocol Stack (DAPS) handover, etc. The timer may include one or more of the following: T304, T310, T312, etc. Among them, access based on a random access process may also be: receiving a TA value and performing random access. For example, the UE receives a TA value included in an LTM command and performs access based on a random access process.

[0108] · LTM command information: used to inform the UE of information of an LTM command, which is used for the UE to include the LTM command information into LTM successful handover information when generating the LTM successful handover information subsequently. When a node receives the LTM successful handover information, the node can find the handover configuration information applied by the node to the UE according to the LTM command information, so as to analyze the problem and / or the cause of the problem and perform corresponding self-optimization operations. The LTM command information can be any information that the node can be able to understand. For example, it may be composed of one or more numbers, and when the node obtains this information, the node can find the configuration information corresponding to this handover.

[0109] In some implementations, the third message can also be used for an other SON-related report, for example, the other SON-related report can be a Connection Establishment Failure (CEF) report, or a Random Access report, or a Successful Handover report, or a Radio Link Failure (RLF) report, or a measurement report, or other reports related to wireless connection. Related contents of the third message may be exchanged between nodes, for example, between a source node and a target node, or between an originally accessing node and a newly accessing node, etc. A node can transmit the related contents of the third message to the UE for configuration of other SON-related reports, for example, through an RRCReestablishment message or an RRCReconfiguration message or an RRCResume message or an RRCSetup message; or by means of MAC CE; or through an other and / or newly defined RRC and / or Xn and / or X2 and / or F1 and / or E1 and / or NG message. In some implementations, after the node transmits the related contents of the third message to the UE, the UE can add the LTM command information to other SON-related reports. When a node receives a report from the UE and / or an other node (for example, the UE transmits the report to the other node, and the other node forwards it to the node), the node can find the handover configuration information applied by the node to the UE according to the LTM command information, and perform corresponding self-optimization. In this way, it can avoid that the node needs to store the handover configuration and / or the context of the UE for a long time, and it can also avoid that the node cannot perform self-optimization because it is releasing the context of the UE.

[0110] Example 3

[0111] In some implementations, the present disclosure provides a method for supporting mobility self-optimization, which may include: a fifth node transmits a fourth message about that LTM successful handover information is available to a sixth node, so that the sixth node knows that the fifth node has stored LTM successful handover information thereon.

[0112] In some implementations, the fourth message may be included in one or more of the following: a UE-MeasurementsAvailable message or an RRCReestablishmentComplete message or an RRCReconfigurationComplete message or an RRCResumeComplete message or an RRCSetupComplete message; or it may be transmitted by means of MAC CE; or an other and / or newly defined RRC and / or Xn and / or X2 and / or F1 and / or E1 and / or NG message.

[0113] In some implementations, the fourth message may include one or more of the following fields or related information:

[0114] · UE ID: which indicates the user corresponding to the available LTM successful handover information.

[0115] · Transmitting node ID: used to identify the node transmitting the message.

[0116] · Receiving node ID: used to identify the node receiving the message.

[0117] · LTM successful handover information available: used to indicate that LTM successful handover information is available, indicating that LTM successful handover information exists. This field may be represented by a single bit. For example, when the bit is 1, it means that the LTM successful handover information is available, and when the bit is 0, it means that the LTM successful handover information is not available; alternatively, when the bit is 0, it means that the LTM successful handover information is available, and when the bit is 1, it means that the LTM successful handover information is not available.

[0118] In some implementations, the sixth node may transmit a fifth message containing an LTM successful handover information request to the fifth node according to its own situation and / or according to the fourth message about that the LTM successful handover information is available received from the fifth node, so as to request the fifth node to report the LTM successful handover information.

[0119] In some implementations, the fifth message may be included in one or more of the following: a UEInformationRequest message of RRC; or an other and / or newly defined RRC and / or Xn and / or X2 and / or F1 and / or E1 and / or NG message.

[0120] In some implementations, the fifth message may include one or more of the following fields or related information:

[0121] · UE ID: which indicates the user corresponding to the available LTM successful handover information.

[0122] · Transmitting node ID: used to identify the node transmitting the message.

[0123] · Receiving node ID: used to identify the node receiving the message.

[0124] · LTM successful handover information request: used to indicate a request for LTM successful handover information, indicating that the LTM successful handover information is requested. This field may be represented by a single bit. For example, when the bit is 1, it means that the LTM successful handover information is requested, and when the bit is 0, it means that the LTM successful handover information is not requested; alternatively, when the bit is 0, it means that the LTM successful handover information is requested, and when the bit is 1, it means that the LTM successful handover information is not requested.

[0125] Example 4

[0126] In some implementations, the present disclosure provides a method for supporting mobility self-optimization, which may include: a seventh node transmits a sixth message containing LTM successful handover information to an eighth node, so that the eighth node can obtain related information of LTM handover. In some implementations, for example, a UE may record the related information of LTM handover in the LTM successful handover information and report the LTM successful handover information to a node, and the node may perform self-optimization according to the information in the LTM successful handover information. For example, the UE may record the LTM related information in the LTM successful handover information, and the node (gNB CU and / or gNB DU) may optimize the LTM according to the information in the LTM successful handover information. For example, when a UE cannot perform access based on a TA value obtained in advance, the UE obtains synchronization information based on a random access process to complete the access. Although this handover is successful, service is interrupted due to the UE's random access. The above-mentioned mechanism of LTM successful handover information can avoid service interruption due to the UE's random access. The LTM successful handover information may be included in a Successful Handover Report (SHR). The LTM successful handover information may also be called an LTM successful handover report.

[0127] In some implementations, the sixth message may include one or more of the following fields or related information:

[0128] · UE ID: which indicates the user corresponding to the LTM successful handover information.

[0129] · LTM handover identification: indicating whether the handover is an LTM handover. This field may be represented by a single bit. For example, when the bit is 1, it means that the handover is an LTM handover, and when the bit is 0, it means that the handover is not an LTM handover; or when the bit is 0, it means that the handover is an LTM handover, and when the bit is 1, it means that the handover is not an LTM handover. For example, if the handover is an LTM handover, this information is set and / or included in the LTM successful handover information.

[0130] · LTM command information: i.e., LTM command information associated with the LTM successful handover information, which is used for the UE to include LTM command information into LTM successful handover information when generating the LTM successful handover information. The LTM command information may come from the LTM successful handover information request and / or configuration. When a node receives the LTM successful handover information, the node can find the handover configuration information applied by the node to the UE according to the LTM command information, so as to analyze the problem and / or the cause of the problem and perform corresponding self-optimization operations. The LTM command information can be any information that the node can be able to understand. For example, it may be composed of one or more numbers, and when the node obtains this information, the node can find the configuration information corresponding to this handover.

[0131] · A TA value in an LTM command. After receiving this information, the node can perform self-optimization. For example, the node can change and / or update its maintenance of the valid time of a TA according to this information, so as to avoid service interruption and / or radio link failure due to TA invalidation. For example, if the TA value used for a successful access is inconsistent with the TA value in an LTM command and / or the difference therebetween is greater than a threshold value, it means that the TA value in the LTM command is invalid, or it may mean that the UE cannot perform access based on the TA value in the LTM command, and the node can change and / or update its maintenance of the valid time of the TA according to this information, etc. For example, if access cannot be performed based on the TA value in the LTM command, this information is set and / or included in the LTM successful handover information.

[0132] · A TA value used for a successful access. After receiving this information, the node can perform self-optimization. For example, the node can change and / or update its maintenance of the valid time of a TA according to this information, so as to avoid service interruption and / or radio link failure due to TA invalidation. For example, if the TA value used for a successful access is inconsistent with the TA value in an LTM command and / or the difference therebetween is greater than a threshold value, it means that the TA value in the LTM command is invalid, or it may mean that the UE cannot perform access based on the TA value in the LTM command, and the node can change and / or update its maintenance of the valid time of the TA according to this information, etc. For example, if access cannot be performed based on the TA value in the LTM command, this information is set and / or included in the LTM successful handover information. For example, if the LTM command does not include a TA value, this information is set and / or included in the LTM successful handover information.

[0133] · Identification of TA invalidation: used to identify the invalidation of a TA value. In some implementations, for example, it may be that a TA value obtained from the LTM command is invalid. After a node obtains this information, the node can know that the TA value obtained in advance for this handover is invalid, so that the user cannot directly access a target cell, which causes service interruption. For example, the UE needs to perform a random access process, resulting in service interruption. According to this information, the node can change and / or update its maintenance of the valid time of a TA, so as to avoid service interruption due to TA invalidation. The identification of TA invalidation may also be indicated in a Cause field. For example, if the UE cannot perform access based on the TA value in an LTM command, this information is set and / or included in the LTM successful handover information. For example, if the TA is invalid, this information is set and / or included in the LTM successful handover information.

[0134] · Identification of that access is performed based on a random access process: indicating that the UE performs access through a random access process when accessing the target node. For example, the reason for performing a random access process is that access cannot be performed based on a TA value obtained in advance. This field can inform the node that although the handover of the user was successful, but the service was interrupted due to the access based on a random access process, and the node needs to optimize this situation to avoid this situation. This field may also be an identification of receiving a TA value and performing random access. For example, the UE receives an LTM command which contains a TA value, but cannot access based on the TA value in the LTM command, and performs access based on a random access process. For example, if the target node is accessed through a random access process, this information is set and / or included in the LTM successful handover information. For example, if access cannot be performed by using the TA value in an LTM command and access is performed through a random access process, this information is set and / or included in the LTM successful handover information.

[0135] · Identification of that access cannot be performed based on a TA value in an LTM command: indicating that the UE cannot access based on a TA value in an LTM command when accessing the target node. This field can inform the node that although the handover of the user was successful, but the service was interrupted because the user cannot access based on the TA value in the LTM command and needs to perform a random access process, so the node needs to optimize this situation to avoid this situation. This field may also be an identification of access failure based on a TA value in an LTM command. For example, if the UE cannot perform access based on the TA value in an LTM command, this information is set and / or included in the LTM successful handover information.

[0136] · Layer 1 measurement result: used to record a Layer 1 measurement result before and / or during and / or after handover. In some implementations, for example, the node can determine whether a handover target node is selected correctly according to this information. In some other implementations, for example, the node can determine whether the reason why the user cannot access based on the TA value obtained in advance is that the TA value is invalid according to this information. For example, if the difference between a Layer 1 measurement result when obtaining the TA value in advance (that is, obtaining the TA value in an LTM command) and a Layer 1 measurement result when actually performing access is too large, for example, greater than and / or equal to a certain threshold value, it indicates that the reason for access failure is that the TA value is invalid.

[0137] · Layer 3 measurement result: used to record a Layer 3 measurement result before and / or during and / or after handover. In some implementations, for example, the node can determine whether a handover target node is selected correctly according to this information. In some other implementations, for example, the node can determine whether the reason why the user cannot access based on the TA value obtained in advance is that the TA value is invalid according to this information. For example, if the difference between a Layer 1 measurement result when obtaining the TA value in advance (that is, obtaining the TA value in an LTM command) and a Layer 1 measurement result when actually performing access is too large, for example, greater than and / or equal to a certain threshold value, it indicates that the reason for access failure is that the TA value in the LTM command is invalid.

[0138] · Access type: which indicates an access type of an access to a target cell. The access type may include one or more of the following: Random Access Channel (RACH)-based, RACH-less / RACH-free. The "RACH-based" may include one or more of the following: contention-based random access, contention-free random access, etc.

[0139] · Configured access type: which indicates a configured access type. The access type may include one or more of the following: RACH-based, RACH-less / RACH-free. The "RACH-based" may include one or more of the following: contention-based random access, contention-free random access, etc. For example, if the LTM command contains a TA value, the configured access type is RACH-less / RACH-free.

[0140] · Actual access type: which indicates an actual access type of an access to a target cell. The access type may include one or more of the following: RACH-based, RACH-less / RACH-free. The "RACH-based" may include one or more of the following: contention-based random access, contention-free random access, etc.

[0141] · Configuration of conditional handover: which may include one or more of the following: (candidate) target cell identification, execution conditions corresponding to a (candidate) target cell, slices supported by a (candidate) target cell, and situation of PDU sessions (resources) accepted by a (candidate) target cell, etc. The situation of PDU sessions (resources) accepted by the (candidate) target cell may include one or more of the following: PDU session identification, the number of accepted PDU sessions (resources), etc. In an implementation, for example, if the UE is (simultaneously) configured with a conditional handover and an LTM, the configuration of conditional handover needs to be included. The configuration of conditional handover can be used for a node to perform handover optimization, for example, to optimize the configuration of conditional handover and / or LTM, so as to improve the mobility robustness.

[0142] In some implementations, after receiving the LTM successful handover information request and / or configuration, if trigger information configured in the LTM successful handover information request and / or configuration is met in the handover process, the UE saves and / or generates (and / or reports) LTM successful handover information and determines the content in the LTM successful handover information. For example, the following situations may be included:

[0143] In some implementations, the handover performed by the UE is LTM, for example, the handover is triggered by an LTM command, and the UE records an LTM handover identification and / or LTM command information (for example, the LTM command information associated with the LTM command that triggered the LTM handover) in the successful handover information.

[0144] And / or, in some implementations, when the UE cannot access based on the TA value in the LTM command and hands over to the target node by performing random access, the UE records one or more of the following in the LTM successful handover information: an identification of that a random access is performed, the TA value in the LTM command, a TA value used for a successful access, an identification of TA invalidation, an identification of that a random access is performed, an identification of that access cannot be performed based on a TA value in an LTM command, a Layer 1 measurement result, a Layer 3 measurement result, etc.

[0145] And / or, in some implementations, the UE determines whether the TA value in the LTM command is invalid according to the TA value in the LTM command and the TA value for a successful access. For example, it may be determined by the difference between the TA value in the LTM command and the TA value for a successful access that whether the reason why the user cannot access based on the TA value obtained in advance is that the TA value in the LTM command is invalid. For example, if the difference between the TA value in the LTM command and the TA value for a successful access is greater than and / or equal to a certain threshold value, it means that the TA value in the LTM command is invalid. The UE records an identification of TA invalidation in the LTM successful handover information.

[0146] In some implementations, after receiving the LTM successful handover information, the node can analyze the cause of the problem and perform corresponding self-optimization according to the information therein, for example, it may include the following situations:

[0147] In some implementations, after receiving the LTM successful handover information, the node can determine whether the TA value in the LTM command is invalid according to the difference between the TA value in the LTM command and the TA value for a successful access, for example, determine whether the reason why the user cannot access based on the TA value obtained in advance is that the TA value in the LTM command is invalid. For example, if the difference between the TA value in the LTM command and the TA value for a successful access is greater than and / or equal to a certain threshold value, it means that the TA value in the LTM command is invalid. A node (e.g., the source gNB DU and / or the target gNB DU) performs self-optimization based on the received LTM successful handover information, for example, the node changes and / or updates the maintenance of the valid time of the TA value (e.g., shorten the valid time of the TA value). In a subsequent LTM, service interruption caused by the invalidation of a TA value in an LTM command can be avoided, and the robustness of LTM handover can be guaranteed.

[0148] In some other implementations, after receiving the LTM successful handover information, the node can determine whether the TA value in the LTM command is invalid according to the measurement results (for example, a Layer 1 measurement result or a Layer 3 measurement result) therein, for example, determine whether the reason why the user cannot access based on the TA value in the LTM command is that the TA value is invalid. For example, if the difference between a measurement result when obtaining the TA value in advance (that is, obtaining the TA value in an LTM command) and a measurement result when actually performing access is too large, for example, greater than and / or equal to a certain threshold value, it indicates that the reason for access failure is that the TA value in the LTM command is invalid. A node (e.g., the source gNB DU and / or the target gNB DU) performs self-optimization based on the received LTM successful handover information, for example, the node changes and / or updates the maintenance of the valid time of the TA value (e.g., shorten the valid time of the TA value). In a subsequent LTM, service interruption caused by the invalidation of a TA value in an LTM command can be avoided, and the robustness of LTM handover can be guaranteed.

[0149] In still other implementations, after receiving the LTM successful handover information, the node can know that the reason for service interruption is that the TA value is invalid (or expires) according to an identification of that the TA value is invalid (or expires) therein. A node (e.g., the source gNB DU and / or the target gNB DU) performs self-optimization based on the received LTM successful handover information, for example, the node changes and / or updates the maintenance of the valid time of the TA value (e.g., shorten the valid time of the TA value). In a subsequent LTM, service interruption caused by the invalidation of a TA value in an LTM command can be avoided, and the robustness of LTM handover can be guaranteed.

[0150] If the node finds that the TA value in the LTM command is invalid when the UE performs accessing (for example, when it is determined that the TA value in the LTM command for the UE to perform LTM handover is invalid based on the LTM successful handover information), the node performs self-optimization based on the received LTM successful handover information and / or a problem type. For example, the node changes and / or updates the maintenance of the valid time of the TA value (for example, shorten the valid time of the TA value). The LTM successful handover information may be the aforementioned sixth message, and the problem type may be the aforementioned second message.

[0151] Example 5

[0152] In some implementations, the present disclosure provides a method for supporting mobility self-optimization, which may include: a ninth node transmits a seventh message containing LTM-related and / or target side-related radio link failure information to a tenth node, so that the tenth node can obtain radio link failure information related to LTM and / or related to the target side. For example, it may be used for the tenth node to analyze the causes of LTM-related radio link failure and perform related self-optimization, or it may also be used for the tenth node to analyze whether the problem is from itself or from other nodes (for example, the target node side) and perform related self-optimization, or it may also be used for the tenth node to forward it to other nodes for the other nodes to analyze the failure reasons and perform related self-optimization.

[0153] In some implementations, the seventh message may be included in one or more of the following: a UEInformationResponse message, an SCGFailureInformation message, a MCGFailureInformation message of RRC; a FAILURE INDICATION message, a HANDOVER REPORT message, a ACCESS AND MOBILITY INDICATION message, a S-NODE MODIFICATION REQUEST message, a SgNB MODIFICATION REQUEST message, a SCG FAILURE INFORMATION REPORT message, a RRC TRANSFER message of Xn; a ACCESS AND MOBILITY INDICATION message of F1; a UPLINK RAN CONFIGURATION TRANSFER message and a DOWNLINK RAN CONFIGURATION TRANSFE message of NG; or an other and / or newly defined RRC and / or Xn and / or X2 and / or F1 and / or E1 and / or NG message. This information may be included in a report, wherein the report may be a Connection Establishment Failure (CEF) report, or a Random Access report, or a Successful Handover report, or a Radio Link Failure (RLF) report, or a measurement report, or other reports related to wireless connection.

[0154] In some implementations, the seventh message may include one or more of the following fields or related information:

[0155] · UE ID: which indicates the user corresponding to the LTM success or failure information.

[0156] · LTM handover identification: indicating whether the handover is an LTM handover. This field may be represented by a single bit. For example, when the bit is 1, it means that the handover is an LTM handover, and when the bit is 0, it means that the handover is not an LTM handover; or when the bit is 0, it means that the handover is an LTM handover, and when the bit is 1, it means that the handover is not an LTM handover.

[0157] · Identification of (simultaneous) configuration of LTM and conditional handover: which indicates that UE is (simultaneously) configured with the configuration of conditional handover and LTM. When a node receives this information, it can perform cause analysis for the conditional handover and / or LTM, and / or make corresponding self-optimization. If the UE is (simultaneously) configured with conditional handover and LTM, this information is included.

[0158] · LTM command information: used for the UE to include the LTM command information into LTM-related radio link failure information when generating the LTM-related radio link failure information. When a node receives the LTM-related radio link failure information, the node can find the handover configuration information applied by the node to the UE according to the LTM command information, so as to analyze the problem and / or the cause of the problem and perform corresponding self-optimization operations. The LTM command information can be any information that the node can be able to understand. For example, it may be composed of one or more numbers, and when the node obtains this information, the node can find the configuration information corresponding to this handover.

[0159] · A TA value in an LTM command. After receiving this information, the node can perform self-optimization. For example, the node can change and / or update its maintenance of the valid time of a TA according to this information, so as to avoid service interruption and / or radio link failure due to TA invalidation. For example, if the TA value used for a successful access is inconsistent with the TA value in an LTM command and / or the difference therebetween is greater than a threshold value, it means that the TA value in the LTM command is invalid, or it may mean that the UE cannot perform access based on the TA value in the LTM command, and the node can change and / or update its maintenance of the valid time of the TA according to this information, etc. For example, if the TA value used for a successful access is inconsistent with the TA value in an LTM command, this information is included. For example, if access is performed based on a random access process, this information is included. For example, if access cannot be performed based on the TA value in an LTM command, this information is included. For example, if access can be performed based on the TA value in an LTM command, this information is included. For example, if the LTM command contains a TA value, this information is included.

[0160] · A TA value used for a successful access. After receiving this information, the node can perform self-optimization. For example, the node can change and / or update its maintenance of the valid time of a TA according to this information, so as to avoid service interruption and / or radio link failure due to TA invalidation. For example, if the TA value used for a successful access is inconsistent with the TA value in an LTM command and / or the difference therebetween is greater than a threshold value, it means that the TA value in the LTM command is invalid, or it may mean that the UE cannot perform access based on the TA value in the LTM command, and the node can change and / or update its maintenance of the valid time of the TA according to this information, etc. For example, if the TA value used for a successful access is inconsistent with the TA value in an LTM command, this information is included. For example, if access is performed based on a random access process, this information is included.

[0161] · Identification of TA invalidation: used to identify the invalidation of a TA value. In some implementations, for example, it may be that a TA value obtained from the LTM command is invalid. After a node obtains this information, the node can know that the TA value obtained in advance for this handover is invalid, so that the user cannot directly access a target cell, which causes radio link failure and / or service interruption. According to this information, the node can change and / or update its maintenance of the valid time of a TA, so as to avoid service interruption due to TA invalidation. The identification of TA invalidation may also be indicated in a Cause field. For example, if the TA value used for a successful access is inconsistent with the TA value in an LTM command, this information is included. For example, if access is performed based on a random access process, this information is included. For example, if access cannot be performed based on the TA value in an LTM command, this information is included. For example, if the LTM command contains a TA value, this information is included. For example, if the TA value is invalid, this information is included. For example, if the TA value obtained from an LTM command is invalid, this information is included.

[0162] · Identification of that access is performed based on a random access process: indicating that the UE performs access through a random access process when accessing the target node. For example, the reason for performing a random access process is that access cannot be performed based on a TA value obtained in advance. This field may also be an identification of receiving a TA value and performing random access. For example, the UE receives an LTM command which contains a TA value, but cannot access based on the TA value in the LTM command, and tries to perform access based on a random access process. For example, if the target node is accessed through a random access process, this information is included. For example, if access cannot be performed by using the TA value in an LTM command and access is performed through a random access process, this information is included.

[0163] · Identification of that access cannot be performed based on a TA value in an LTM command: indicating that the UE cannot access based on a TA value in an LTM command when accessing the target node. In this case, radio link failure and / or service interruption may occur, and the node needs to optimize this situation to avoid this situation. This field may also be an identification of access failure based on a TA value in an LTM command. For example, if the TA value used for a successful access is inconsistent with the TA value in an LTM command, this information is included. For example, if access is performed based on a random access process, this information is included. For example, if access cannot be performed based on the TA value in an LTM command, this information is included. For example, if the TA value is invalid, this information is included. For example, if the TA value obtained from an LTM command is invalid, this information is included.

[0164] · Layer 1 measurement result: used to record a Layer 1 measurement result before and / or during and / or after handover. In some implementations, for example, the node can determine whether a handover target node is selected correctly according to this information. In some other implementations, for example, the node can determine whether the reason why the user cannot access and / or the reason of radio link failure is that the TA value is invalid according to this information. For example, if the difference between a Layer 1 measurement result when obtaining the TA value in advance (that is, obtaining the TA value in an LTM command) and a Layer 1 measurement result when actually performing access is too large, for example, greater than and / or equal to a certain threshold value, it indicates that the reason for access failure is that the TA value is invalid.

[0165] · A time from reception of an LTM command to a successful (re-) access: for example, it may be used for a node to obtain corresponding handover configuration and / or perform cause analysis and / or perform self-optimization, for example, to determine whether it is a too early handover, or a too late handover, etc.

[0166] · A time from reception of an LTM command to a failure: for example, it may be used for a node to obtain corresponding handover configuration and / or perform cause analysis and / or perform self-optimization, for example, to determine whether it is a too early handover, or a too late handover, etc.

[0167] · A time from reception of a PDCCH order to reception of an LTM command: for example, it may be used for a node to obtain corresponding handover configuration and / or perform cause analysis and / or perform self-optimization, for example, to determine whether a TA value is invalid. For example, when the time from reception of a PDCCH order to reception of an LTM command is greater than a threshold value, it means that the TA value is invalid. For example, if a PDCCH order is received, this information is included.

[0168] · A time from transmission of a preamble to reception of an LTM command: for example, it may be used for a node to obtain corresponding handover configuration and / or perform cause analysis and / or perform self-optimization, for example, to determine whether a TA value is invalid. For example, when the time from transmission of a preamble to reception of an LTM command is greater than a threshold value, it means that the TA value is invalid. For example, if a PDCCH order is received, this information is included. For example, if a preamble is transmitted, this information is included.

[0169] · Reception time of a PDCCH order: for example, it may be used for a node to obtain corresponding handover configuration and / or perform cause analysis and / or perform self-optimization. For example, if a PDCCH order is received, this information is included.

[0170] · A time from reception of a PDCCH order to the reporting and / or information reporting: it may be used for the node to find the configuration information for this handover. For example, if a PDCCH order is received, this information is included.

[0171] · Reception time of an LTM command: for example, it may be used for a node to obtain corresponding handover configuration and / or perform cause analysis and / or perform self-optimization.

[0172] · A time from reception of an LTM command to the reporting and / or information reporting: it may be used for nodes to find configuration information for this handover.

[0173] · Random Access Response (RAR) window expiration: used to indicate that the UE did not receive an RAR when the RAR window expired during a random access process. In some implementations, when a node receives this information, the node can know that the problem is that the UE cannot receive an RAR transmitted from a target node, and the node needs to consider this information when performing self-optimization. In some implementations, for example, the node knows that the problem comes from the target node, and the node does not change and / or update its own configuration, so as to avoid unnecessary change and / or update.

[0174] · Expiration of a random access contention resolution timer: used to indicate that in a random access process, the UE did not receive an MSG4 when the random access contention resolution timer expired. In some implementations, when the node receives this information, the node can know that the problem is that the UE cannot receive the MSG4 transmitted from a target node, and the node needs to consider this information when performing self-optimization. In some implementations, for example, the node knows that the problem comes from the target node, and the node does not change and / or update its own configuration, so as to avoid unnecessary change and / or update.

[0175] · Measurement result of SSB: used to indicate a measurement result of SSB. If SSB is not received, the measurement result of SSB may be set to a predefined value, for example, 0. In some implementations, when the node receives this information, the node can know that the problem is that the UE cannot receive an SSB transmitted from a target node, and the node needs to consider this information when performing self-optimization. In some implementations, for example, the node knows that the problem comes from the target node, and the node does not change and / or update its own configuration, so as to avoid unnecessary change and / or update.

[0176] · Uplink transmission failure: used to indicate a failure of uplink transmission. In some implementations, when the node receives this information, the node can know that the problem is that the UE cannot transmit uplink information at the target node side, and the node needs to consider this information when performing self-optimization. In some implementations, for example, the node knows that the problem comes from the target node, and the node does not change and / or update its own configuration, so as to avoid unnecessary change and / or update.

[0177] · Indication of transmission failure in uplink synchronization: used to indicate a failure of uplink transmission in a case of uplink synchronization. In some implementations, when the node receives this information, the node can know that the problem is that an uplink failure of the UE occurs at the target node side, and the node needs to consider this information when performing self-optimization. In some implementations, for example, the node knows that the problem comes from the target node, and the node does not change and / or update its own configuration, so as to avoid unnecessary change and / or update.

[0178] · MSG3 transmission failure: used to indicate that MSG3 transmission fails during random access. For example, it may be that the transmission of LBT fails or LBT cannot be transmitted, or it may be that a feedback of NACK is received after transmission. In some implementations, when the node receives this information, the node can know that the problem is that the UE cannot successfully transmit an MSG3 to the target node, and the node needs to consider this information when performing self-optimization. In some implementations, for example, the node knows that the problem comes from the target node, and the node does not change and / or update its own configuration, so as to avoid unnecessary change and / or update.

[0179] · Access type: which indicates an access type of an access to a target cell. The access type may include one or more of the following: RACH-based, RACH-less / RACH-free. The "RACH-based" may include one or more of the following: contention-based random access, contention-free random access, etc.

[0180] · Configured access type: which indicates a configured access type. The access type may include one or more of the following: RACH-based, RACH-less / RACH-free. The "RACH-based" may include one or more of the following: contention-based random access, contention-free random access, etc. For example, if the LTM command contains a TA value, the configured access type is RACH-less / RACH-free.

[0181] · Actual access type: which indicates an actual access type of an access to a target cell. The access type may include one or more of the following: RACH-based, RACH-less / RACH-free. The "RACH-based" may include one or more of the following: contention-based random access, contention-free random access, etc.

[0182] · Configuration of conditional handover: which may include one or more of the following: (candidate) target cell identification, execution conditions corresponding to a (candidate) target cell, slices supported by a (candidate) target cell, and situation of PDU sessions (resources) accepted by a (candidate) target cell, etc. The situation of PDU sessions (resources) accepted by the (candidate) target cell may include one or more of the following: PDU session identification, the number of accepted PDU sessions (resources), etc. In an implementation, for example, if the UE is (simultaneously) configured with a conditional handover and an LTM, the configuration of conditional handover is included. The configuration of conditional handover can be used for a node to perform handover optimization, for example, to optimize the configuration of conditional handover and / or LTM, so as to improve the mobility robustness.

[0183] · Information about whether a reconnect cell is a cell of configured LTM candidate cells: this information is used to inform the UE whether the cell reconnected after a radio link failure is a cell of the configured LTM candidate cells. If the reconnect cell is not a cell of the configured LTM candidate cells, it means that the LTM candidate cells were wrongly selected. For example, if the reconnect cell is and / or is not a cell of the configured LTM candidate cells, this information is included.

[0184] The information in the seventh message can also be used in scenarios other than radio link failure. For example, when the UE encounters a problem during random access, the information in the seventh message can be recorded in a random access report. When a node accessed by the random access obtains the report, the node can analyze it and perform corresponding self-optimization. In an implementation, for example, if a problem is found to be from downlink transmission (for example, the report contains one or more of the following: Random Access Response (RAR) window expiration, expiration of a random access contention resolution timer, the SSB measurement result is too low, etc.), the node can know that the reason why the random access attempt failed is that the UE did not receive a downlink message (for example, SSB, RAR, MSG4, etc.), and the node can perform corresponding change and / or update (such as resource allocation change and / or update, and / or transmission power change and / or update, etc.), so as to ensure the success rate of random access. In another implementation, for example, if a problem is found to be from uplink transmission (for example, the report contains one or more of the following: uplink transmission failure, indication of transmission failure in uplink synchronization, MSG3 transmission failure, etc.), the node can know that the reason why the random access attempt failed is that there is a problem in uplink transmission, and the node can perform corresponding change and / or update (such as resource allocation change and / or update, and / or transmission power configuration change and / or update, etc.), so as to ensure the success rate of random access. In the present disclosure, a TA value obtained in advance and a TA value in an LTM command may refer to each other.

[0185] The self-optimization mentioned in the present disclosure may include making and / or updating network energy-saving decisions, making and / or updating load balancing, making and / or updating coverage optimization, making and / or updating mobility optimization and / or management, making and / or updating configuration, etc., and the corresponding optimization thereof. Among them, making and / or updating configuration may include one or more of the following: changing and / or updating the maintenance of the valid time of the TA value, changing and / or updating the resource allocation strategy, changing and / or updating the transmission power configuration, changing and / or updating the transmission power, etc.

[0186] A result and a report may refer to each other in the present disclosure.

[0187] In the present disclosure, a time may be represented by one or more of the following: a timestamp, a time point, a time interval, a timer, a period of time, a time length, a time period / periodicity, a time spacing, etc. Herein, the time length may be a length of time from a certain time point, which may be the current time. A time may be a relative time or an absolute time. In some implementations, a period of time may be represented by separate fields, for example, by a combination of a start time and an end time, or by a combination of a start time and a time period.

[0188] Exemplary embodiments of the present disclosure are further described below with reference to the accompanying drawings.

[0189] The text and drawings are provided as examples only to help understand the present disclosure. They should not be construed as limiting the scope of the present disclosure in any way. Although certain embodiments and examples have been provided, based on the disclosure herein, it is apparent to those skilled in the art that changes can be made to the illustrated embodiments and examples without departing from the scope of the present disclosure.

[0190] FIG. 3A shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 3A shows a process of exchanging a failure type and / or problem type between two nodes, so that a second node can obtain an analysis result of the failure type and / or problem type, and the second node may perform self-optimization based on the result, or the second node can forward it to other nodes for the other nodes to perform self-optimization.

[0191] In some implementations, for example, the first node may be a UE, and the second node may be a gNB or a gNB-CU or a gNB-DU or a gNB CU-CP or a gNB CU-UP or an en-gNB or an eNB or a ng-eNB. In some other implementations, for example, the first node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB, and the second node may be a gNB or a gNB-CU or a gNB-DU or a gNB CU-CP or a gNB CU-UP or an en-gNB or an eNB or a ng-eNB. In yet another implementation, for example, the first node may be an AMF or an SMF or an MME, and the second node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB. In yet another implementation, for example, the first node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB, and the second node may be an AMF or an SMF or an MME.

[0192] Step 301A: the first node transmits a failure type and / or problem type to the second node. The failure type and / or problem type may be the aforementioned second message.

[0193] Step 302A: the second node may perform self-optimization based on the received failure type and / or problem type.

[0194] FIG. 3B shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 3B shows a process of exchanging LTM-related and / or target side-related radio link failure information between a UE and a gNB CU and between a gNB CU and a source gNB DU, and / or exchanging a failure type and / or problem type between a gNB CU and a source gNB DU, so that the gNB CU and / or source gNB DU can perform self-optimization based on the analyzed failure type and / or problem and the LTM-related and / or target side-related radio link failure information.

[0195] Step 301B: the UE has a radio link failure at the source gNB DU side or the UE has a handover failure when switching to the target cell.

[0196] Step 302B: the UE transmits LTM-related and / or target side-related radio link failure information to the gNB CU. The LTM-related and / or target side-related radio link failure information may be the aforementioned seventh message. The LTM-related and / or target side-related radio link failure information is carried by a radio link failure report (RLF Report).

[0197] Step 303B: the gNB CU performs cause analysis based on the collected LTM-related and / or target side-related radio link failure information. In some implementations, if the analysis result is that the gNB CU needs to perform optimization for itself, the gNB CU performs self-optimization.

[0198] Step 304B: the gNB CU transmits a failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information to the source gNB DU. The failure type and / or problem type may be the aforementioned second message. The LTM-related and / or target side-related radio link failure information may be the aforementioned seventh message. The failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information may be carried by an ACCESS AND MOBILITY INDICATION message. Herein, the LTM-related and / or target side-related radio link failure information is carried by a radio link failure report (RLF Report). In some implementations, for example, when the failure type and / or problem type contains a problem from the source gNB DU, the gNB CU transmits the failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information to the source gNB DU.

[0199] Step 305B: the source gNB DU may perform self-optimization based on the received failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information.

[0200] FIG. 3C shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 3C shows a process of exchanging LTM-related and / or target side-related radio link failure information between a UE and a gNB CU and between a gNB CU and a source gNB DU, and / or exchanging a failure type and / or problem type between a gNB CU and a source gNB DU, so that the gNB CU and / or source gNB DU can perform self-optimization based on the analyzed failure type and / or problem and the LTM-related and / or target side-related radio link failure information.

[0201] Step 301C: the UE has a radio link failure at the source gNB DU side or the UE has a handover failure when switching to the target cell.

[0202] Step 302C: the UE transmits LTM-related and / or target side-related radio link failure information to the gNB CU. The LTM-related and / or target side-related radio link failure information may be the aforementioned seventh message. The LTM-related and / or target side-related radio link failure information is carried by a radio link failure report (RLF Report).

[0203] Step 303C: the gNB CU transmits a request for a failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information to the source gNB DU. The request for a failure type and / or problem may be the aforementioned first message. The LTM-related and / or target side-related radio link failure information may be the aforementioned seventh message. The request for a failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information may be carried by an ACCESS AND MOBILITY INDICATION message. Herein, the LTM-related and / or target side-related radio link failure information is carried by a radio link failure report (RLF Report).

[0204] Step 304C: the source gNB DU performs cause analysis based on the collected LTM-related and / or target side-related radio link failure information, and if the analysis result is that the source gNB DU needs to perform optimization for itself, the source gNB DU performs self-optimization.

[0205] Step 305C: the source gNB DU transmits the analyzed failure type and / or problem type to the gNB DU. The failure type and / or problem type may be the aforementioned second message. In some implementations, only when all and / or part of the problems analyzed by the source gNB DU are from gNB CU, the gNB DU transmits the failure type and / or problems to the gNB CU. If step 303C contains a request for failure type and / or problem type, the source gNB DU needs to transmit the analyzed failure type and / or problem type to the gNB CU according to the request.

[0206] Step 306C: the gNB CU performs self-optimization based on the failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information.

[0207] FIG. 3D shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 3D shows a process of exchanging LTM-related and / or target side-related radio link failure information between a UE and a gNB CU and between a gNB CU and a source gNB DU. The gNB CU and / or source gNB DU can analyze the failure type and / or problem based on the LTM-related and / or target side-related radio link failure information and perform corresponding self-optimization.

[0208] Step 301D: the UE has a radio link failure at the source gNB DU side or the UE has a handover failure when switching to the target cell.

[0209] Step 302D: the UE transmits LTM-related and / or target side-related radio link failure information to the gNB CU. The LTM-related and / or target side-related radio link failure information may be the aforementioned seventh message. The LTM-related and / or target side-related radio link failure information is carried by a radio link failure report (RLF Report).

[0210] Step 303D: the gNB CU performs cause analysis based on the collected LTM-related and / or target side-related radio link failure information, and in some implementations, analyzes whether the problem is from itself. If the analysis result is that the gNB CU needs to perform optimization for itself, the gNB CU performs self-optimization.

[0211] Step 304D: the gNB CU transmits LTM-related and / or target side-related radio link failure information to the source gNB DU. The LTM-related and / or target side-related radio link failure information may be the aforementioned seventh message. The LTM-related and / or target side-related radio link failure information may be carried by an ACCESS AND MOBILITY INDICATION message. Herein, the LTM-related and / or target side-related radio link failure information is carried by a radio link failure report (RLF Report).

[0212] Step 305D: the source gNB DU can perform cause analysis based on LTM-related and / or target side-related radio link failure information, and if the analysis result is that the problem comes from the source gNB DU, the source gNB DU performs self-optimization.

[0213] FIG. 3E shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 3E shows a process of exchanging LTM-related and / or target side-related radio link failure information between UE and nodes and between nodes, and / or a process of exchanging failure type and / or problem type between nodes. The source gNB CU and / or the source gNB DU can perform self-optimization based on the analyzed failure types and / or problems and the LTM-related and / or target side-related radio link failure information.

[0214] Step 301E: the UE has a radio link failure at a target node (for example, including a target gNB DU, a target gNB CU, etc.).

[0215] Step 302E: the UE transmits LTM-related and / or target side-related radio link failure information to the target gNB CU. The LTM-related and / or target side-related radio link failure information may be the aforementioned seventh message. The LTM-related and / or target side-related radio link failure information is carried by a radio link failure report (RLF Report).

[0216] Step 303E: the target gNB CU performs cause analysis based on the collected LTM-related and / or target side-related radio link failure information.

[0217] Step 304E: the target gNB CU transmits the failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information to the source gNB CU. The failure type and / or problem type may be the aforementioned second message. The LTM-related and / or target side-related radio link failure information may be the aforementioned seventh message. The failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information may be carried by a HANDOVER REQUEST message. Herein, the LTM-related and / or target side-related radio link failure information is carried by a radio link failure report (RLF Report). If the result of failure type and / or problem type is that the source gNB CU needs to perform optimization for itself, the source gNB CU performs self-optimization.

[0218] Step 305E: the source gNB CU transmits a failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information to the source gNB DU. The failure type and / or problem type may be the aforementioned second message. The LTM-related and / or target side-related radio link failure information may be the aforementioned seventh message. The failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information may be carried by an ACCESS AND MOBILITY INDICATION message. Herein, the LTM-related and / or target side-related radio link failure information is carried by a radio link failure report (RLF Report). In some implementations, for example, when the failure type and / or problem type contains a problem from the source gNB DU, the source gNB CU transmits the failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information to the source gNB DU.

[0219] Step 306E: the source gNB DU may perform self-optimization based on the received failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information.

[0220] FIG. 3F shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 3F shows a process of exchanging LTM-related and / or target side-related radio link failure information between UE and nodes and between nodes, and / or a process of exchanging failure type and / or problem type between nodes. The source gNB CU and / or the source gNB DU can perform self-optimization based on the analyzed failure types and / or problems and the LTM-related and / or target side-related radio link failure information.

[0221] Step 301F: the UE has a radio link failure at a target node (for example, including a target gNB DU, a target gNB CU, etc.).

[0222] Step 302F: the UE transmits LTM-related and / or target side-related radio link failure information to the target gNB CU. The LTM-related and / or target side-related radio link failure information may be the aforementioned seventh message. The LTM-related and / or target side-related radio link failure information is carried by a radio link failure report (RLF Report).

[0223] Step 303F: the target gNB CU transmits a request for a failure type and / or problem type and / or LTM-related and / or target side-related radio link failure information to the target gNB DU. The request for a failure type and / or problem may be the aforementioned first message. The LTM-related and / or target side-related radio link failure information may be the aforementioned seventh message. The request for a failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information may be carried by an ACCESS AND MOBILITY INDICATION message. Herein, the LTM-related and / or target side-related radio link failure information is carried by a radio link failure report (RLF Report).

[0224] Step 304F: the target gNB DU performs cause analysis based on the collected LTM-related and / or target side-related radio link failure information.

[0225] Step 305F: the target gNB DU transmits the analyzed failure type and / or problem type to the target gNB DU. The failure type and / or problem type may be the aforementioned second message. If step 303F contains a request for failure type and / or problem type, the target gNB DU needs to transmit the analyzed failure type and / or problem type to the target gNB DU according to the request.

[0226] Step 306F: the target gNB CU transmits the failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information to the source gNB CU. The failure type and / or problem type may be the aforementioned second message. The LTM-related and / or target side-related radio link failure information may be the aforementioned seventh message. The failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information may be carried by a HANDOVER REQUEST message. Herein, the LTM-related and / or target side-related radio link failure information is carried by a radio link failure report (RLF Report). If the result of failure type and / or problem type is that the source gNB CU needs to perform optimization for itself, the source gNB CU performs self-optimization.

[0227] Step 307F: the source gNB CU transmits a failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information to the source gNB DU. The failure type and / or problem type may be the aforementioned second message. The LTM-related and / or target side-related radio link failure information may be the aforementioned seventh message. The failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information may be carried by an ACCESS AND MOBILITY INDICATION message. Herein, the LTM-related and / or target side-related radio link failure information is carried by a radio link failure report (RLF Report). In some implementations, for example, when the failure type and / or problem type contains a problem from the source gNB DU, the source gNB CU transmits the failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information to the source gNB DU.

[0228] Step 308F: the source gNB DU may perform self-optimization based on the received failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information.

[0229] FIG. 3G shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 3G shows a process of exchanging LTM-related and / or target side-related radio link failure information between UE and nodes and between nodes, and / or a process of exchanging failure type and / or problem type between nodes. The source gNB CU and / or the source gNB DU can perform self-optimization based on the analyzed failure types and / or problems and the LTM-related and / or target side-related radio link failure information.

[0230] Step 301G: the UE has a radio link failure at a target node (for example, including a target gNB DU, a target gNB CU, etc.).

[0231] Step 302G: the UE transmits LTM-related and / or target side-related radio link failure information to the target gNB CU. The LTM-related and / or target side-related radio link failure information may be the aforementioned seventh message. The LTM-related and / or target side-related radio link failure information is carried by a radio link failure report (RLF Report).

[0232] Step 303G: the target gNB CU performs cause analysis.

[0233] Step 304G: the target gNB CU transmits a request for a failure type and / or problem type and / or LTM-related and / or target side-related radio link failure information to the target gNB DU. The request for a failure type and / or problem may be the aforementioned first message. The LTM-related and / or target side-related radio link failure information may be the aforementioned seventh message. The request for a failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information may be carried by an ACCESS AND MOBILITY INDICATION message. Herein, the LTM-related and / or target side-related radio link failure information is carried by a radio link failure report (RLF Report).

[0234] Step 305G: the target gNB DU performs cause analysis based on the collected LTM-related and / or target side-related radio link failure information.

[0235] Step 306G: the target gNB DU transmits the analyzed failure type and / or problem type to the target gNB DU. The failure type and / or problem type may be the aforementioned second message. If step 304G contains a request for failure type and / or problem type, the target gNB DU needs to transmit the analyzed failure type and / or problem type to the target gNB DU according to the request.

[0236] Step 307G: the target gNB CU transmits the failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information to the source gNB CU. The failure type and / or problem type include an analysis result of the target gNB CU and / or an analysis result of the target gNB DU obtained from the target gNB DU. The failure type and / or problem type may be the aforementioned second message. The LTM-related and / or target side-related radio link failure information may be the aforementioned seventh message. The failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information may be carried by a HANDOVER REQUEST message. Herein, the LTM-related and / or target side-related radio link failure information is carried by a radio link failure report (RLF Report). If the result of failure type and / or problem type is that the source gNB CU needs to perform optimization for itself, the source gNB CU performs self-optimization.

[0237] Step 308G: the source gNB CU transmits a failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information to the source gNB DU. The failure type and / or problem type may be the aforementioned second message. The LTM-related and / or target side-related radio link failure information may be the aforementioned seventh message. The failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information may be carried by an ACCESS AND MOBILITY INDICATION message. Herein, the LTM-related and / or target side-related radio link failure information is carried by a radio link failure report (RLF Report). In some implementations, for example, when the failure type and / or problem type contains a problem from the source gNB DU, the source gNB CU transmits the failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information to the source gNB DU.

[0238] Step 309G: the source gNB DU may perform self-optimization based on the received failure type and / or problem type, and / or LTM-related and / or target side-related radio link failure information.

[0239] FIG. 3H shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 3H shows a process of exchanging a failure type and / or problem type between two nodes, so that a second node can obtain an analysis result of the failure type and / or problem type, and the second node may perform self-optimization based on the result, or the second node can forward it to other nodes for the other nodes to perform self-optimization.

[0240] In some implementations, for example, the first node may be a UE, and the second node may be a gNB or a gNB-CU or a gNB-DU or a gNB CU-CP or a gNB CU-UP or an en-gNB or an eNB or a ng-eNB. In some other implementations, for example, the first node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB, and the second node may be a gNB or a gNB-CU or a gNB-DU or a gNB CU-CP or a gNB CU-UP or an en-gNB or an eNB or a ng-eNB. In yet another implementation, for example, the first node may be an AMF or an SMF or an MME, and the second node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB. In yet another implementation, for example, the first node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB, and the second node may be an AMF or an SMF or an MME.

[0241] Step 301H: the second node transmits a request for a failure type and / or problem type to the first node. The request for a failure type and / or problem type may be the aforementioned first message.

[0242] Step 302H: the first node transmits the failure type and / or problem type to the second node. The failure type and / or problem type may be the aforementioned second message.

[0243] Step 303H: the second node may perform self-optimization based on the received failure type and / or problem type. The second node can also forward the received failure type and / or problem type for other nodes to perform self-optimization.

[0244] FIG. 4 shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 4 shows a process of exchanging an LTM successful handover information request and / or configuration between two nodes, for a fourth node to forward it to other nodes and / or use it to generate LTM successful handover information.

[0245] In some implementations, for example, the third node may be a gNB or a gNB-CU or a gNB-DU or a gNB CU-CP or a gNB CU-UP or an en-gNB or an eNB or a ng-eNB, and the fourth node may be a UE. In some other implementations, for example, the third node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB, and the fourth node may be a gNB or a gNB-CU or a gNB-DU or a gNB CU-CP or a gNB CU-UP or an en-gNB or an eNB or a ng-eNB. In yet another implementation, for example, the third node may be an AMF or an SMF or an MME, and the fourth node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB. In yet another implementation, for example, the third node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB, and the fourth node may be an AMF or an SMF or an MME.

[0246] Step 401A: the third node transmits an LTM successful handover information request and / or configuration to the fourth node. The LTM successful handover information request and / or configuration may be the aforementioned third message.

[0247] Step 402A: the fourth node may forward it to other nodes and / or use it to generate LTM successful handover information.

[0248] FIG. 5A shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 5A shows a process of exchanging LTM successful handover information between two nodes, for a sixth node to forward it to other nodes for other nodes to perform self-optimization, or for the sixth node to perform self-optimization.

[0249] In some implementations, for example, the fifth node may be a UE, and the sixth node may be a gNB or a gNB-CU or a gNB-DU or a gNB CU-CP or a gNB CU-UP or an en-gNB or an eNB or a ng-eNB. In some other implementations, for example, the fifth node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB, and the sixth node may be a gNB or a gNB-CU or a gNB-DU or a gNB CU-CP or a gNB CU-UP or an en-gNB or an eNB or a ng-eNB. In yet another implementation, for example, the fifth node may be an AMF or an SMF or an MME, and the sixth node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB. In yet another implementation, for example, the fifth node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB, and the sixth node may be an AMF or an SMF or an MME.

[0250] Step 501A: the fifth node transmits information about that the LTM successful handover information is available to the sixth node. The information about that the LTM successful handover information is available may be the aforementioned fourth message.

[0251] Step 502A: the sixth node transmits an LTM successful handover information request to the fifth node. The LTM successful handover information request may be the aforementioned fifth message.

[0252] Step 503A: the fifth node transmits LTM successful handover information to the sixth node. The LTM successful handover information may be the aforementioned sixth message.

[0253] Step 504A: the sixth node may forward it to other nodes for the other nodes to perform self-optimization, or the sixth node may perform self-optimization based on the collected LTM successful handover information.

[0254] FIG. 5B shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 5B shows a process of exchanging LTM successful handover information between two nodes, for a sixth node to forward it to other nodes for the other nodes to perform self-optimization, or the sixth node may perform self-optimization based on the collected LTM successful handover information.

[0255] In some implementations, for example, the fifth node may be a UE, and the sixth node may be a gNB or a gNB-CU or a gNB-DU or a gNB CU-CP or a gNB CU-UP or an en-gNB or an eNB or a ng-eNB. In some other implementations, for example, the fifth node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB, and the sixth node may be a gNB or a gNB-CU or a gNB-DU or a gNB CU-CP or a gNB CU-UP or an en-gNB or an eNB or a ng-eNB. In yet another implementation, for example, the fifth node may be an AMF or an SMF or an MME, and the sixth node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB. In yet another implementation, for example, the fifth node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB, and the sixth node may be an AMF or an SMF or an MME.

[0256] Step 501B: the sixth node transmits an LTM successful handover information request to the fifth node. The LTM successful handover information request may be the aforementioned fifth message.

[0257] Step 502B: the fifth node transmits LTM successful handover information to the sixth node. The LTM successful handover information may be the aforementioned sixth message.

[0258] Step 503B: the sixth node may forward it to other nodes for the other nodes to perform self-optimization, or the sixth node may perform self-optimization based on the collected LTM successful handover information.

[0259] FIG. 6A shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 6A shows a process of exchanging LTM successful handover information between two nodes, so that a seventh node can forward it to other nodes for the other nodes to perform self-optimization, or an eighth node can perform self-optimization based on the collected LTM successful handover information.

[0260] In some implementations, for example, the seventh node may be a UE, and the eighth node may be a gNB or a gNB-CU or a gNB-DU or a gNB CU-CP or a gNB CU-UP or an en-gNB or an eNB or a ng-eNB. In some other implementations, for example, the seventh node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB, and the eighth node may be a gNB or a gNB-CU or a gNB-DU or a gNB CU-CP or a gNB CU-UP or an en-gNB or an eNB or a ng-eNB. In yet another implementation, for example, the seventh node may be an AMF or an SMF or an MME, and the eighth node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB. In yet another implementation, for example, the seventh node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB, and the eighth node may be an AMF or an SMF or an MME.

[0261] Step 601A: the seventh node transmits LTM successful handover information to the eighth node. The LTM successful handover information may be the aforementioned sixth message.

[0262] Step 602A: the eighth node may forward it to other nodes for the other nodes to perform self-optimization, or the seventh node may perform self-optimization based on the collected LTM successful handover information.

[0263] FIG. 6B shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 6B shows a process of exchanging LTM successful handover information between nodes and UE and between nodes, so that a source gNB DU can obtain the LTM successful handover information for self-optimization.

[0264] Step 601B: the source gNB DU transmits an LTM successful handover information request and / or configuration to the gNB CU, so that the source gNB CU can configure it to the UE. The LTM successful handover information request and / or configuration may be the aforementioned third message. The LTM successful handover information request and / or configuration may be carried by a UE CONTEXT MODIFICATION REQUIRED message and / or a UE CONTEXT MODIFICATION RESPONSE message.

[0265] Step 602B: the gNB CU transmits an LTM successful handover information request and / or configuration to UE for the UE to generate LTM successful handover information. The LTM successful handover information request and / or configuration may be the aforementioned third message.

[0266] Step 603B: a process of handover of the UE to a cell of the target gNB DU. In some implementations, for example, if the trigger information configured in the LTM successful handover information request and / or configuration is met during the handover process, the UE generates LTM successful handover information.

[0267] Step 604B: the UE transmits the information that the LTM successful handover is available to the gNB CU. The information about that the LTM successful handover information is available may be the aforementioned fourth message. The LTM successful handover information may be carried by an RRC reconfiguration complete message.

[0268] Step 605B: the gNB CU transmits an LTM successful handover information request to UE. The LTM successful handover information request may be the aforementioned fifth message. The LTM successful handover information request may be carried by a UEInformationRequest message.

[0269] Step 606B: the UE transmits LTM successful handover information to the gNB CU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by a Successful Handover Report.

[0270] Step 607B: the gNB CU transmits LTM successful handover information to the source gNB DU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by an ACCESS AND MOBILITY INDICATION message. Herein, the LTM successful handover information may be carried by a Successful Handover Report.

[0271] Step 608B: the source gNB DU performs self-optimization based on the received LTM successful handover information.

[0272] FIG. 6C shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 6C shows a process of exchanging LTM successful handover information between nodes and UE and between nodes, so that a source gNB DU can obtain the LTM successful handover information for self-optimization.

[0273] Step 601C: the source gNB DU transmits an LTM successful handover information request and / or configuration to the UE for the UE to generate LTM successful handover information. The LTM successful handover information request and / or configuration may be the aforementioned third message. This information can be configured through MAC CE.

[0274] Step 602C: a process of handover of the UE to a cell of the target gNB DU. In some implementations, for example, if the trigger information configured in the LTM successful handover information request and / or configuration is met during the handover process, the UE generates LTM successful handover information.

[0275] Step 603C: the UE transmits the information that the LTM successful handover is available to the gNB CU. The information about that the LTM successful handover information is available may be the aforementioned fourth message. The LTM successful handover information may be carried by an RRC reconfiguration complete message.

[0276] Step 604C: the gNB CU transmits an LTM successful handover information request to UE. The LTM successful handover information request may be the aforementioned fifth message. The LTM successful handover information request may be carried by a UEInformationRequest message.

[0277] Step 605C: the UE transmits LTM successful handover information to the gNB CU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by a Successful Handover Report.

[0278] Step 606C: the gNB CU transmits LTM successful handover information to the source gNB DU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by an ACCESS AND MOBILITY INDICATION message. Herein, the LTM successful handover information may be carried by a Successful Handover Report.

[0279] Step 607C: the source gNB DU performs self-optimization based on the received LTM successful handover information.

[0280] FIG. 6D shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 6D shows a process of exchanging LTM successful handover information between nodes and UE and between nodes, so that a source gNB DU can obtain the LTM successful handover information for self-optimization.

[0281] Step 601D: the source gNB DU transmits an LTM successful handover information request and / or configuration to the UE for the UE to generate LTM successful handover information. The LTM successful handover information request and / or configuration may be the aforementioned third message. This information can be configured through MAC CE.

[0282] Step 602D: a process of handover of the UE to a cell of the target gNB DU. In some implementations, for example, if the trigger information configured in the LTM successful handover information request and / or configuration is met during the handover process, the UE generates LTM successful handover information.

[0283] Step 603D: the UE transmits information about that the LTM successful handover information is available to the target gNB DU. The information about that the LTM successful handover information is available may be the aforementioned fourth message. The LTM successful handover information may be carried by MAC CE.

[0284] Step 604D: the target gNB DU transmits an LTM successful handover information request to the UE. The LTM successful handover information request may be the aforementioned fifth message. The LTM successful handover information request may be carried by MAC CE.

[0285] Step 605D: the UE transmits LTM successful handover information to the target gNB DU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by MAC CE.

[0286] Step 606D: the target gNB DU transmits LTM successful handover information to the gNB CU. The LTM successful handover information may be the aforementioned sixth message.

[0287] Step 607D: the gNB CU transmits LTM successful handover information to the source gNB DU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by an ACCESS AND MOBILITY INDICATION message. Herein, the LTM successful handover information may be carried by a Successful Handover Report.

[0288] Step 608D: the source gNB DU performs self-optimization based on the received LTM successful handover information.

[0289] FIG. 6E shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 6E shows a process of exchanging LTM successful handover information between nodes and UE and between nodes, so that a source gNB DU can obtain the LTM successful handover information for self-optimization.

[0290] Step 601E: the source gNB DU transmits an LTM successful handover information request and / or configuration to the source gNB CU, so that the source gNB CU can configure it to the UE. The LTM successful handover information request and / or configuration may be the aforementioned third message. The LTM successful handover information request and / or configuration may be carried by a UE CONTEXT MODIFICATION REQUIRED message and / or a UE CONTEXT MODIFICATION RESPONSE message.

[0291] Step 602E: the source gNB CU transmits an LTM successful handover information request and / or configuration to the UE for the UE to generate LTM successful handover information. The LTM successful handover information request and / or configuration may be the aforementioned third message.

[0292] Step 603E: a process of handover of the UE to a cell of the target gNB DU. In some implementations, for example, if the trigger information configured in the LTM successful handover information request and / or configuration is met during the handover process, the UE generates LTM successful handover information.

[0293] Step 604E: the UE transmits the information about that the LTM successful handover is available to the target gNB CU. The information about that the LTM successful handover information is available may be the aforementioned fourth message. The LTM successful handover information may be carried by an RRC reconfiguration complete message.

[0294] Step 605E: the target gNB CU transmits an LTM successful handover information request to the UE. The LTM successful handover information request may be the aforementioned fifth message. The LTM successful handover information request may be carried by a UEInformationRequest message.

[0295] Step 606E: the UE transmits the LTM successful handover information to the target gNB CU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by a Successful Handover Report.

[0296] Step 607E: the target gNB CU transmits the LTM successful handover information to the source gNB CU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by a HANDOVER REPORT message, an ACCESS AND MOBILITY INDICATION message or a FAILURE INDICATION message. Herein, the LTM successful handover information may be carried by a Successful Handover Report.

[0297] Step 608E: the source gNB CU transmits the LTM successful handover information to the source gNB DU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by an ACCESS AND MOBILITY INDICATION message. Herein, the LTM successful handover information may be carried by a Successful Handover Report.

[0298] Step 609E: the source gNB DU performs self-optimization based on the received LTM successful handover information.

[0299] FIG. 6F shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 6F shows a process of exchanging LTM successful handover information between nodes and UE and between nodes, so that a source gNB DU can obtain the LTM successful handover information for self-optimization.

[0300] Step 601F: the source gNB DU transmits an LTM successful handover information request and / or configuration to the UE for the UE to generate LTM successful handover information. The LTM successful handover information request and / or configuration may be the aforementioned third message. This information can be configured through MAC CE.

[0301] Step 602F: a process of handover of the UE to a cell of the target gNB DU. In some implementations, for example, if the trigger information configured in the LTM successful handover information request and / or configuration is met during the handover process, the UE generates LTM successful handover information.

[0302] Step 603F: the UE transmits the information about that the LTM successful handover is available to the target gNB CU. The information about that the LTM successful handover information is available may be the aforementioned fourth message. The LTM successful handover information may be carried by an RRC reconfiguration complete message.

[0303] Step 604F: the target gNB CU transmits an LTM successful handover information request to the UE. The LTM successful handover information request may be the aforementioned fifth message. The LTM successful handover information request may be carried by a UEInformationRequest message.

[0304] Step 605F: the UE transmits the LTM successful handover information to the target gNB CU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by a Successful Handover Report.

[0305] Step 606F: the target gNB CU transmits the LTM successful handover information to the source gNB CU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by a HANDOVER REPORT message, an ACCESS AND MOBILITY INDICATION message or a FAILURE INDICATION message. Herein, the LTM successful handover information may be carried by a Successful Handover Report.

[0306] Step 607F: the source gNB CU transmits the LTM successful handover information to the source gNB DU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by an ACCESS AND MOBILITY INDICATION message. Herein, the LTM successful handover information may be carried by a Successful Handover Report.

[0307] Step 608F: the source gNB DU performs self-optimization based on the received LTM successful handover information.

[0308] FIG. 6G shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 6G shows a process of exchanging LTM successful handover information between nodes and UE and between nodes, so that a source gNB DU can obtain the LTM successful handover information for self-optimization.

[0309] Step 601G: the source gNB DU transmits an LTM successful handover information request and / or configuration to the UE for the UE to generate LTM successful handover information. The LTM successful handover information request and / or configuration may be the aforementioned third message. This information can be configured through MAC CE.

[0310] Step 602G: a process of handover of the UE to a cell of the target gNB DU. In some implementations, for example, if the trigger information configured in the LTM successful handover information request and / or configuration is met during the handover process, the UE generates LTM successful handover information.

[0311] Step 603G: the UE transmits information about that the LTM successful handover information is available to the target gNB DU. The information about that the LTM successful handover information is available may be the aforementioned fourth message. The LTM successful handover information may be carried by MAC CE.

[0312] Step 604G: the target gNB DU transmits an LTM successful handover information request to the UE. The LTM successful handover information request may be the aforementioned fifth message. The LTM successful handover information request may be carried by MAC CE.

[0313] Step 605G: the UE transmits LTM successful handover information to the target gNB DU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by MAC CE.

[0314] Step 606G: the target gNB DU transmits the LTM successful handover information to the target gNB CU. The LTM successful handover information may be the aforementioned sixth message. Herein, the LTM successful handover information may be carried by a Successful Handover Report.

[0315] Step 607G: the target gNB DU transmits LTM successful handover information to the target gNB CU. The LTM successful handover information may be the aforementioned sixth message.

[0316] Step 608G: the target gNB CU transmits the LTM successful handover information to the source gNB DU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by an ACCESS AND MOBILITY INDICATION message. Herein, the LTM successful handover information may be carried by a Successful Handover Report.

[0317] Step 609G: the source gNB DU performs self-optimization based on the received LTM successful handover information.

[0318] FIG. 6H shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 6H shows a process of exchanging LTM successful handover information between nodes and UE and between nodes, so that a source gNB DU can obtain the LTM successful handover information for self-optimization.

[0319] Step 601H: the source gNB CU transmits an LTM successful handover information request and / or configuration to the UE for the UE to generate LTM successful handover information. The LTM successful handover information request and / or configuration may be the aforementioned third message.

[0320] Step 602H: a process of handover of the UE to a cell of the target gNB DU. In some implementations, for example, if the trigger information configured in the LTM successful handover information request and / or configuration is met during the handover process, the UE generates LTM successful handover information.

[0321] Step 603H: the UE transmits the information about that the LTM successful handover is available to the target gNB CU. The information about that the LTM successful handover information is available may be the aforementioned fourth message. The LTM successful handover information may be carried by an RRC reconfiguration complete message.

[0322] Step 604H: the target gNB CU transmits an LTM successful handover information request to the UE. The LTM successful handover information request may be the aforementioned fifth message. The LTM successful handover information request may be carried by a UEInformationRequest message.

[0323] Step 605H: the UE transmits the LTM successful handover information to the target gNB CU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by a Successful Handover Report.

[0324] Step 606H: the target gNB CU transmits the LTM successful handover information to the source gNB CU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by a HANDOVER REPORT message, an ACCESS AND MOBILITY INDICATION message or a FAILURE INDICATION message. Herein, the LTM successful handover information may be carried by a Successful Handover Report.

[0325] Step 607H: the source gNB CU transmits the LTM successful handover information to the source gNB DU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by an ACCESS AND MOBILITY INDICATION message. Herein, the LTM successful handover information may be carried by a Successful Handover Report. In an implementation, the source gNB CU may perform cause analysis, and the source gNB CU may transmit the analyzed problem type to the source gNB DU. The problem type may be the aforementioned second message. The problem type may be carried by an ACCESS AND MOBILITY INDICATION message.

[0326] Step 608H: the source gNB DU performs self-optimization based on the received LTM successful handover information and / or problem type.

[0327] FIG. 6I shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 6I shows a process of exchanging LTM successful handover information between nodes and UE and between nodes, so that the source gNB CU can obtain the LTM successful handover information for self-optimization.

[0328] Step 601I: the source gNB CU transmits an LTM successful handover information request and / or configuration to the UE for the UE to generate LTM successful handover information. The LTM successful handover information request and / or configuration may be the aforementioned third message.

[0329] Step 602I: a process of handover of the UE to a cell of the target gNB CU. In some implementations, for example, if the trigger information configured in the LTM successful handover information request and / or configuration is met during the handover process, the UE generates LTM successful handover information.

[0330] Step 603I: the UE transmits the information about that the LTM successful handover is available to the target gNB CU. The information about that the LTM successful handover information is available may be the aforementioned fourth message. The LTM successful handover information may be carried by an RRC reconfiguration complete message.

[0331] Step 604I: the target gNB CU transmits an LTM successful handover information request to the UE. The LTM successful handover information request may be the aforementioned fifth message. The LTM successful handover information request may be carried by a UEInformationRequest message.

[0332] Step 605I: the UE transmits LTM successful handover information to the target gNB CU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by a Successful Handover Report.

[0333] Step 606I: the target gNB CU transmits the LTM successful handover information to the source gNB CU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by a HANDOVER REPORT message, an ACCESS AND MOBILITY INDICATION message or a FAILURE INDICATION message. Herein, the LTM successful handover information may be carried by a Successful Handover Report.

[0334] Step 607I: the source gNB DU performs self-optimization based on the received LTM successful handover information.

[0335] FIG. 6J shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 6J shows a process of exchanging LTM successful handover information between nodes and UE and between nodes, so that the source node can obtain the LTM successful handover information for self-optimization.

[0336] Step 601J: the source node transmits an LTM successful handover information request and / or configuration to the UE for the UE to generate LTM successful handover information. The LTM successful handover information request and / or configuration may be the aforementioned third message.

[0337] Step 602J: a process of handover of the UE to a cell of the target node. In some implementations, for example, if the trigger information configured in the LTM successful handover information request and / or configuration is met during the handover process, the UE generates LTM successful handover information.

[0338] Step 603J: the UE transmits information about that the LTM successful handover information is available to the target node. The information about that the LTM successful handover information is available may be the aforementioned fourth message. The LTM successful handover information may be carried by an RRC reconfiguration complete message.

[0339] Step 604J: the target node transmits an LTM successful handover information request to the UE. The LTM successful handover information request may be the aforementioned fifth message. The LTM successful handover information request may be carried by a UEInformationRequest message.

[0340] Step 605J: the UE transmits the LTM successful handover information to the target node. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by a Successful Handover Report.

[0341] Step 606J: the target node transmits the LTM successful handover information to the source node. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by a HANDOVER REPORT message, an ACCESS AND MOBILITY INDICATION message or a FAILURE INDICATION message. Herein, the LTM successful handover information may be carried by a Successful Handover Report.

[0342] Step 607J: the source node performs self-optimization based on the received LTM successful handover information.

[0343] FIG. 6K shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 6K shows a process of exchanging LTM successful handover information between nodes and UE and between nodes, so that a source gNB DU can obtain the LTM successful handover information for self-optimization.

[0344] Step 601K: the source gNB CU transmits an LTM successful handover information request and / or configuration to the UE for the UE to generate LTM successful handover information. The LTM successful handover information request and / or configuration may be the aforementioned third message.

[0345] Step 602K: a process of handover of the UE to a cell of the target gNB DU. In some implementations, for example, if the trigger information configured in the LTM successful handover information request and / or configuration is met during the handover process, the UE generates LTM successful handover information.

[0346] Step 603K: the UE transmits information about that the LTM successful handover information is available to the target gNB DU. The information about that the LTM successful handover information is available may be the aforementioned fourth message. The LTM successful handover information may be carried by MAC CE.

[0347] Step 604K: the target gNB DU transmits an LTM successful handover information request to the UE. The LTM successful handover information request may be the aforementioned fifth message. The LTM successful handover information request may be carried by MAC CE.

[0348] Step 605K: the UE transmits LTM successful handover information to the target gNB DU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by MAC CE.

[0349] Step 606K: the target gNB DU transmits LTM successful handover information to the gNB CU. The LTM successful handover information may be the aforementioned sixth message.

[0350] Step 607K: the gNB CU transmits LTM successful handover information to the source gNB DU. The LTM successful handover information may be the aforementioned sixth message. The LTM successful handover information may be carried by an ACCESS AND MOBILITY INDICATION message. Herein, the LTM successful handover information may be carried by a Successful Handover Report. In an implementation, the source gNB CU may perform cause analysis, and the source gNB CU may transmit the analyzed problem type to the source gNB DU. The problem type may be the aforementioned second message. The problem type may be carried by an ACCESS AND MOBILITY INDICATION message.

[0351] Step 608K: the source gNB DU performs self-optimization based on the received LTM successful handover information and / or problem type.

[0352] FIG. 7 shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 7 shows a process of exchanging LTM-related and / or target side-related radio link failure information between two nodes, for a tenth node to perform self-optimization.

[0353] In some implementations, for example, the seventh node may be a UE, and the eighth node may be a gNB or a gNB-CU or a gNB-DU or a gNB CU-CP or a gNB CU-UP or an en-gNB or an eNB or a ng-eNB. In some other implementations, for example, the seventh node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB, and the eighth node may be a gNB or a gNB-CU or a gNB-DU or a gNB CU-CP or a gNB CU-UP or an en-gNB or an eNB or a ng-eNB. In yet another implementation, for example, the seventh node may be an AMF or an SMF or an MME, and the eighth node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB. In yet another implementation, for example, the seventh node may be a gNB or a gNB-CU or a gNB CU-CP or an en-gNB or an eNB or a ng-eNB, and the eighth node may be an AMF or an SMF or an MME.

[0354] Step 701A: the ninth node transmits LTM-related and / or target side-related radio link failure information to the tenth node. The LTM-related and / or target side-related radio link failure information may be the aforementioned seventh message.

[0355] Step 702A: the ninth node performs self-optimization based on the received LTM-related and / or target side-related radio link failure information.

[0356] FIG. 8A shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 8A shows a process of exchanging handover command information between a UE, a source node and a target node, so that the source node can find relevant configuration for LTM handover based on the LTM command information after releasing the UE context, and can perform self-optimization based on a collected SON-related report.

[0357] Step 801A: the source node transmits LTM command information to the target node. The LTM command information may be the LTM command information in the aforementioned third message.

[0358] Step 802A: a handover process of handover of the UE to a cell of the target node. The source node releases the UE context information.

[0359] Step 803A: the target node collects an SON-related report from other nodes and / or the UE.

[0360] Step 804A: the target node transmits the LTM command information and / or the SON-related report to the source node. The LTM command information and / or the SON-related report may be carried by a HANDOVER REPORT message and / or an ACCESS AND MOBILITY INDICATION message and / or a FAILURE INDICATION message. The source node finds the configuration used for this LTM handover according to the LTM command information, and performs self-optimization based on the obtained SON report. The LTM command information may be the LTM command information in the aforementioned third message.

[0361] FIG. 8B shows a schematic diagram of an aspect of a method for supporting mobility self-optimization according to embodiments of the present disclosure. Specifically, FIG. 8B shows a process of exchanging handover command information between a UE, a source node and a target node, so that the source node can find relevant configuration for LTM handover based on the LTM command information after releasing the UE context, and can perform self-optimization based on a collected SON-related report.

[0362] Step 801B: the source gNB DU transmits LTM command information to the source gNB CU. The LTM command information may be the LTM command information in the aforementioned third message.

[0363] Step 802B: the source gNB CU transmits the LTM command information to the target gNB DU. The LTM command information may be the LTM command information in the aforementioned third message.

[0364] Step 803B: a handover process of handover of the UE to a cell of the target node. The source node (including the source gNB CU and / or the source gNB DU) releases the UE context information.

[0365] Step 804B: the target gNB CU collects an SON-related report from other nodes and / or UE.

[0366] Step 805B: the target gNB CU transmits the LTM command information and / or the SON-related report to the source gNB CU. The LTM command information may be the LTM command information in the aforementioned third message. The LTM command information and / or the SON-related report may be transmitted through a HANDOVER REPORT message, an ACCESS AND MOBILITY INDICATION message or a FAILURE INDICATION message.

[0367] Step 806B: the source gNB CU transmits the LTM command information and / or the SON-related report to the source gNB DU. The LTM command information may be the LTM command information in the aforementioned third message. The LTM command information and / or the SON-related report may be carried by an ACCESS AND MOBILITY INDICATION message. The source gNB DU finds the configuration used for this LTM handover according to the LTM command information, and performs self-optimization based on the obtained SON report. The source gNB CU may also perform cause analysis based on the collected SON-related report, and the source gNB CU may transmit the analyzed failure type and / or problem type to the source gNB DU in this step. The failure type and / or problem type may be the aforementioned second message. The failure type and / or problem type may be carried by an ACCESS AND MOBILITY INDICATION message.

[0368] FIG. 8B shows an example of different DUs of different CUs. If it is an example of different DUs of the same CU, the target gNB CU and the source gNB CU in FIG. 8B would be one node. In this way, 802B and 805B can be omitted.

[0369] It should be understood that, depending on the application scenario, the various example aspects, methods, steps, processes, etc. shown in combination with the drawings may be combined and implemented in any way, and are not limited herein.

[0370] Next, FIG. 9 shows a flowchart of a method 900 performed by a first node in a wireless communication system according to embodiments of the present disclosure.

[0371] As shown in FIG. 9, a method 900 performed by a first node in a wireless communication system according to embodiments of the present disclosure may include: in step S901, transmitting a third message to a user equipment (UE) or a second node, wherein the third message includes configuration information associated with L1 / L2-triggered mobility (LTM) successful handover information, wherein the configuration information associated with the LTM successful handover information includes one or more of: a Timing Advance (TA) value expires, access cannot be performed based on a first TA value, access is performed based on a random access process, and the first TA value is invalid; in step S902, receiving a sixth message from a second node, wherein the sixth message includes the LTM successful handover information; and in step S903, performing corresponding configuration change based on the LTM successful handover information.

[0372] According to embodiments of the present disclosure, the LTM successful handover information includes one or more of: an identification of that access is performed based on a random access process, the first TA value, a second TA value, an identification that the first TA value is invalid, an identification of that access cannot be performed based on the first TA value, a first measurement result, a second measurement result, an LTM handover identification and LTM command information.

[0373] According to embodiments of the present disclosure, the method further includes: determining whether the first TA value is invalid based on the first TA value and a second TA value.

[0374] According to embodiments of the present disclosure, the method further includes: determining whether the first TA value is invalid based on a first measurement result and / or a second measurement result.

[0375] According to embodiments of the present disclosure, the performing corresponding configuration change based on the LTM successful handover information further comprises: when determining the first TA value to be invalid based on the LTM successful handover information, changing a valid time of the first TA value.

[0376] According to embodiments of the present disclosure, the first TA value is a TA value in an LTM command, and the second TA value is a TA value obtained based on a random access process.

[0377] According to embodiments of the present disclosure, the first measurement result is a Layer 1 measurement result and the second measurement result is a Layer 3 measurement result.

[0378] FIG. 10 shows a flowchart of a method 1000 performed by a user equipment (UE) in a wireless communication system according to embodiments of the present disclosure.

[0379] As shown in FIG. 10, a method 1000 performed by a user equipment (UE) in a wireless communication system according to embodiments of the present disclosure may include: in step S1001, receiving a third message from a first node or a second node, wherein the third message includes configuration information associated with L1 / L2-triggered mobility (LTM) successful handover information, wherein the configuration information associated with the LTM successful handover information includes one or more of: a Timing Advance (TA) value expires, access cannot be performed based on a first TA value, access is performed based on a random access process, and the first TA value is invalid; and in step S1002, transmitting a sixth message to the second node or a third node, wherein the sixth message includes the LTM successful handover information. In some implementations, the third node may be a target node for UE handover, such as a target gNB or a target gNB CU or a target gNB DU, etc.

[0380] According to embodiments of the present disclosure, the method further includes: saving the LTM successful handover information in case that the configuration information associated with the LTM successful handover information is met in a handover process.

[0381] According to embodiments of the present disclosure, the method further includes: when the UE performs an LTM handover, including an LTM handover identification and / or LTM command information in the LTM successful handover information.

[0382] According to embodiments of the present disclosure, the method further includes: when the UE cannot perform access based on the first TA value and hands over to the third node through random access, including one or more of the following in the LTM successful handover information: an identification of that access is performed based on a random access process, the first TA value, a second TA value, an identification that the first TA value is invalid, an identification of that access cannot be performed based on the first TA value, a first measurement result, a second measurement result.

[0383] According to embodiments of the present disclosure, the method further includes: determining whether the first TA value is invalid based on the first TA value and a second TA value.

[0384] According to embodiments of the present disclosure, the method further includes: determining whether the first TA value is invalid based on a first measurement result and / or a second measurement result.

[0385] According to embodiments of the present disclosure, the first TA value is a TA value in an LTM command, and the second TA value is a TA value obtained based on a random access process.

[0386] According to embodiments of the present disclosure, the first measurement result is a Layer 1 measurement result and the second measurement result is a Layer 3 measurement result.

[0387] FIG. 11 shows a flowchart of a method 1100 performed by a second node in a wireless communication system according to embodiments of the present disclosure.

[0388] As shown in FIG. 11, a method 1100 performed by a second node in a wireless communication system according to embodiments of the present disclosure may include: in step S1101, receiving a third message from a first node, wherein the third message includes configuration information associated with L1 / L2-triggered mobility (LTM) successful handover information, wherein the configuration information associated with the LTM successful handover information includes one or more of: a Timing Advance (TA) value expires, access cannot be performed based on a first TA value, access is performed based on a random access process, and the first TA value is invalid; in step S1102, transmitting the configuration information to a user equipment (UE); in step S1103, receiving a sixth message from the UE or a third node, wherein the sixth message includes the LTM successful handover information; and in step S1104, transmitting the LTM successful handover information to the first node.

[0389] According to embodiments of the present disclosure, the LTM successful handover information includes one or more of: an identification of that access is performed based on a random access process, the first TA value, a second TA value, an identification that the first TA value is invalid, an identification of that access cannot be performed based on the first TA value, a first measurement result, a second measurement result, an LTM handover identification and LTM command information.

[0390] It should be understood that methods 900, 1000, 1100, etc. according to embodiments of the present disclosure may further include any steps described in connection with various examples, aspects, drawings, etc. of the present disclosure.

[0391] Next, FIG. 12 shows a schematic diagram of a node 1200 according to embodiments of the present disclosure.

[0392] As shown in FIG. 12, a node (or a node device, for example, a first node or a second node as described above, etc.) 1200 according to embodiments of the present disclosure may include a transceiver 1210 and a processor 1220. The transceiver 1210 may be configured to transmit and receive signals. The processor 1220 may be coupled to the transceiver 1210 and may be configured to (e.g., control the transceiver 1210 to) perform a method performed by a node (e.g., a first node and / or a second node) according to embodiments of the present disclosure.

[0393] FIG. 13 shows a schematic diagram of a user equipment 1300 according to embodiments of the present disclosure.

[0394] As shown in FIG. 13, a user equipment 1300 according to embodiments of the present disclosure may include a transceiver 1310 and a processor 1320. The transceiver 1310 may be configured to transmit and receive signals. The processor 1320 may be coupled to the transceiver 1310 and may be configured to (e.g., control the transceiver 1310 to) perform a method performed by a user equipment according to embodiments of the present disclosure. In the present disclosure, a processor may also be referred to as a controller.

[0395] Embodiments of the present disclosure also provide a computer-readable medium having stored thereon computer-readable instructions which, when executed by a processor, implement any method according to embodiments of the present disclosure.

[0396] Various embodiments of the present disclosure may be implemented as computer-readable codes embodied on a computer-readable recording medium from a specific perspective. A computer-readable recording medium is any data storage device that can store data readable by a computer system. Examples of computer-readable recording media may include read-only memory (ROM), random access memory (RAM), compact disk read-only memory (CD-ROM), magnetic tape, floppy disk, optical data storage device, carrier wave (e.g., data transmission via the Internet), etc. Computer-readable recording media can be distributed by computer systems connected via a network, and thus computer-readable codes can be stored and executed in a distributed manner. Furthermore, functional programs, codes and code segments for implementing various embodiments of the present disclosure can be easily explained by those skilled in the art to which the embodiments of the present disclosure are applied.

[0397] It will be understood that the embodiments of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software. The software may be stored as program instructions or computer-readable codes executable on a processor on a non-transitory computer-readable medium. Examples of non-transitory computer-readable recording media include magnetic storage media (such as ROM, floppy disk, hard disk, etc.) and optical recording media (such as CD-ROM, digital video disk (DVD), etc.). Non-transitory computer-readable recording media may also be distributed on computer systems coupled to a network, so that computer-readable codes are stored and executed in a distributed manner. The medium can be read by a computer, stored in a memory, and executed by a processor. Various embodiments may be implemented by a computer or a portable terminal including a controller and a memory, and the memory may be an example of a non-transitory computer-readable recording medium suitable for storing program (s) with instructions for implementing embodiments of the present disclosure. The present disclosure may be realized by a program with code for concretely implementing the apparatus and method described in the claims, which is stored in a machine (or computer)-readable storage medium. The program may be electronically carried on any medium, such as a communication signal transmitted via a wired or wireless connection, and the present disclosure suitably includes its equivalents.

[0398] What has been described above is only the specific implementation of the present disclosure, but the scope of protection of the present disclosure is not limited thereto. Anyone who is familiar with this technical field may make various changes or substitutions within the technical scope disclosed in the present disclosure, and these changes or substitutions should be covered within the scope of protection of the present disclosure. Therefore, the scope of protection of the present disclosure should be based on the scope of protection of the claims.

Claims

1.A method performed by a base station in a wireless communication system, the method comprising:performing L1 / L2-triggered mobility (LTM) procedure;in case that the LTM procedure is failed, performing a cause analysis for the failed LTM procedure; andperforming self-optimization based on a failure type identified based on the cause analysis,wherein the failure type includes wrong selection of candidate LTM cell and inappropriate cell switch triggering.2.The method of claim 1, wherein in case that the failure type identified based on the cause analysis is the wrong selection of candidate LTM cell:the cause analysis is performed by a centralized unit (CU) of the base station, andthe self-optimization is performed by the CU of the base station.3.The method of claim 2, wherein performing the self-optimization comprises:transmitting, by the CU of the base station to the DU of the base station, information including the failure type identified based on the cause analysis.4.The method of claim 1, wherein in case that the failure type identified based on the cause analysis is the inappropriate cell switch triggering:the cause analysis is performed by the CU of the base station or distributed unit (DU) of the base station, andthe self-optimization is performed by the DU of the base station.5.The method of claim 4, wherein the inappropriate cell switch triggering includes wrong cell selection at cell switch and wrong cell switch timing.6.The method of claim 1, further comprising:receiving, from a user equipment, a radio link failure (RLF) report,wherein the cause analysis is performed based on the RLF report.7.The method of claim 6, wherein the RLF report includes at least one of LTM-related radio link failure information or target side-related radio link failure information.8.The method of claim 1, further comprising:transmitting, to a UE, configuration information associated with LTM successful handover information,wherein the configuration information associated with the LTM successful handover information includes at least one of first information indicating that a Timing Advance (TA) value expires, second information indicating that access cannot be performed based on a first TA value, third information indicating that access is performed based on a random access process, or forth information indicating that the first TA value is invalid;receiving, from the UE, the LTM successful handover information; andperforming configuration change based on the LTM successful handover information.9.A base station in a wireless communication system, the base station comprising:a transceiver; anda controller coupled with the transceiver and configured to:perform L1 / L2-triggered mobility (LTM) procedure,in case that the LTM procedure is failed, perform a cause analysis for the failed LTM procedure,perform self-optimization based on a failure type identified based on the cause analysis, andwherein the failure type includes wrong selection of candidate LTM cell and inappropriate cell switch triggering.10.The base station of claim 9, wherein in case that the failure type identified based on the cause analysis is the wrong selection of candidate LTM cell:the cause analysis is performed by a centralized unit (CU) of the base station, andthe self-optimization is performed by the CU of the base station.11.The base station of claim 10, wherein the controller is further configured to for performing the self-optimization:transmit, by the CU of the base station to the DU of the base station, information including the failure type identified based on the cause analysis.12.The base station of claim 9, wherein in case that the failure type identified based on the cause analysis is the inappropriate cell switch triggering:the cause analysis is performed by the CU of the base station or distributed unit (DU) of the base station, andthe self-optimization is performed by the DU of the base station.13.The base station of claim 12, wherein the inappropriate cell switch triggering includes wrong cell selection at cell switch and wrong cell switch timing.14.The base station of claim 9, wherein the controller is further configured to:receive, from a user equipment, a radio link failure (RLF) report,wherein the cause analysis is performed based on the RLF report.15.The base station of claim 14, wherein the RLF report includes at least one of LTM-related radio link failure information or target side-related radio link failure information.

Images