Method and apparatus for mobility optimization in wireless communication system

Abstract

A method and an apparatus for mobility optimization in a wireless communication system are disclosed. According to an exemplary embodiment, a method performed by a first node in a wireless communication system includes: receiving a first message including low layer triggered mobility LTM failure report information related to a user equipment (UE); and updating an LTM configuration and / or a trigger policy related to the mobility of the UE based on the LTM failure report information and the LTM configuration related to the mobility of the UE.

Description

Technical Field

[0001] The present disclosure relates to wireless communication technology, and in particular, to a method and apparatus for mobility optimization in a wireless communication system. Background Art

[0002] In order to meet the increased demand for wireless data communication services since the deployment of 4G communication systems, efforts have been made to develop improved 5G or quasi-5G communication systems. Therefore, 5G or quasi-5G communication systems are also referred to as "super 4G networks" or "post-LTE systems."

[0003] Wireless communication is one of the most successful innovations in modern history. The number of subscribers to wireless communication services recently exceeded 5 billion and continues to grow rapidly. The demand for wireless data services is growing rapidly due to the increasing popularity of smartphones and other mobile data devices (e.g., tablets, laptops, netbooks, e-book readers, and machine-type devices) among consumers and enterprises. In order to meet the high growth of mobile data services and support new applications and deployments, it is critical to improve the efficiency and coverage of the wireless interface.

[0004] In order to reduce the delay of service interruption during UE mobility, Rel-18 is currently developing specifications for L1 / L2 Triggered Mobility (LTM). The main process is based on the L1 (Layer 1) measurement report reported by the UE, and the gNB-DU determines the target cell and issues a mobility command to the UE. Compared with the previous handover process based on L3 measurement report, since the L3 measurement report is obtained based on the linear average of L1 measurement and other reprocessing, the handover based on L1 measurement report can have a faster mobility command, and the UE can receive this command faster through the L2 MAC CE of the gNB-DU. In addition, for the UE access process, a process without traditional RACH (random access channel) access (i.e., rach-less) can be applied to further reduce the delay of UE service interruption during mobility. Summary of the invention

[0005] According to one aspect of the present disclosure, a method performed by a first node in a wireless communication system includes: receiving a first message including low-layer triggered mobility LTM failure report information related to a user equipment UE; and updating an LTM configuration and / or triggering policy related to the mobility of the UE based on the LTM failure report information and the LTM configuration related to the mobility of the UE.

[0006] In an exemplary embodiment, the LTM failure report information may include at least one of the following associated with the UE: LTM failure type, cell global identifier CGI of the source cell, target cell CGI, reconstructed cell CGI, recovery cell CGI, cell radio network temporary identifier C-RNTI of the source cell, target cell C-RNTI, last serving cell C-RNTI, UE radio link failure RLF report container, TA invalid indication; or, the LTM failure report information may be associated with the failure of the secondary cell group SCG, and include at least one of the following associated with the UE: LTM failure type, source primary and secondary cell PSCell CGI, target PSCell CGI, suitable PSCell CGI, source PSCell C-RNTI, target PSCell C-RNTI, last serving PSCell C-RNTI, SCG failure report container, TA invalid indication.

[0007] In an exemplary embodiment, the first message may be an LTM failure report message, an LTM PSCell failure report message, an access and mobility indication AAMI message, or an Xn application protocol Xnap handover report message.

[0008] In an exemplary embodiment, the LTM configuration related to the mobility of the UE is included in the LTM failure report information, and the LTM configuration includes at least one of the following: LTM candidate cell list, LTM candidate cell ID, LTM source cell ID, LTM channel state information CSI resource configuration, and LTM CSI report configuration.

[0009] In an exemplary embodiment, the method performed by the first node may also include: receiving a second message related to the UE context release, the second message including an LTM configuration retention indicator; and according to the second message, releasing the LTM configuration that is not related to the mobility of the UE, and retaining the LTM configuration related to the mobility of the UE, wherein the LTM configuration related to the mobility of the UE includes at least one of the following: LTM candidate cell list, LTM candidate cell ID, LTM source cell ID, LTM CSI resource configuration, LTM CSI report configuration.

[0010] In an exemplary embodiment, the second message may be an F1 application protocol F1AP UE context release command message, a UE context modification request message, or an Xnap UE context release message.

[0011] In an exemplary embodiment, the method performed by the first node may also include: sending a message including an LTM configuration related to the mobility of the UE, the LTM configuration including at least one of the following: an LTM candidate cell list, an LTM candidate cell ID, an LTM source cell ID, an LTM CSI resource configuration, and an LTM CSI report configuration, wherein the previously sent LTM configuration is included in the received first message.

[0012] According to one aspect of the present disclosure, a method performed by a user equipment UE in a wireless communication system includes: sending a message including radio link failure RLF report information, the RLF report information being used to generate low-layer triggered mobility LTM failure report information related to the mobility of the UE; and performing an LTM process based on an LTM configuration updated using the LTM failure report information and an LTM configuration related to the mobility of the UE.

[0013] In an exemplary embodiment, the RLF report information may include at least one of an LTM configuration related to the mobility of the UE and information related to an LTM failure, wherein the LTM configuration includes at least one of the following: an LTM candidate cell list, an LTM candidate cell ID, an LTM source cell ID, an LTM channel state information CSI resource configuration, and an LTM CSI report configuration; wherein the information related to the LTM failure may include at least one of the following: source cell information, target cell information, neighboring cell information, LTM candidate cell information, LTM cell information, last switching type information, information indicating a rach-based access failure based on a random access channel or a rach-less access failure without a random access channel, and information about a rach-less access failure, or, wherein the information related to the LTM failure may be associated with a secondary cell group SCG failure and include at least one of the following: an LTM failure type, source primary and secondary cell PSCell information, target PSCell information, neighboring PSCell information, an LTM candidate PSCell list, an LTM PSCell identifier, information indicating a rach-based access failure or a rach-less access failure, and information about a rach-less access failure.

[0014] In an exemplary embodiment, the LTM configuration related to the mobility of the UE is included in the LTM failure report information, and wherein the LTM configuration may include at least one of the following: LTM candidate cell list, LTM candidate cell ID, LTM source cell ID, LTM CSI resource configuration, LTM CSI report configuration.

[0015] In an exemplary embodiment, the LTM failure report information may include at least one of the following associated with the UE: LTM failure type, cell global identifier CGI of the source cell, target cell CGI, rebuilt cell CGI, recovery cell CGI, cell radio network temporary identifier C-RNTI of the source cell, target cell C-RNTI, last serving cell C-RNTI, UE RLF report container, TA invalid indication; or the LTM failure report information may be associated with the failure of the secondary cell group SCG, and include at least one of the following associated with the UE: LTM failure type, source primary and secondary cell PSCell CGI, target PSCell CGI, suitable PSCell CGI, source PSCell C-RNTI, target PSCell C-RNTI, last serving PSCell C-RNTI, SCG Failure report container, TA invalid indication.

[0016] In an exemplary embodiment, the information about the rach-less access failure may include at least one of the following: information related to not receiving a dynamic grant, information related to not receiving an uplink scheduling of a new transmission, information related to an invalid TA value and / or an actual TA value.

[0017] In an exemplary embodiment, the method performed by the UE may further include: receiving an indication of falling back to rach-based access during the rach-less access process; and terminating the rach-less access and performing rach-based access in response to the received indication.

[0018] In an exemplary embodiment, the rach-less access failure may be determined based on a timer value configured for the rach-less access, or based on a timer value configured for the rach-based access and an offset value configured for the rach-less access.

[0019] In an exemplary embodiment, at least one of the source cell information, target cell information, neighbor cell information, LTM candidate cell information, LTM cell information, source PSCell information, target PSCell information, and neighbor PSCell information may include a cell CGI and L1 measurement result of the corresponding cell.

[0020] According to one aspect of the present disclosure, a method performed by a second node in a wireless communication system includes: generating low-layer triggered mobility LTM failure report information based on radio link failure RLF report information of a user equipment UE; and sending a first message including the LTM failure report information, wherein the LTM failure report information and the LTM configuration related to the mobility of the UE are used to update the LTM configuration and / or triggering policy related to the mobility of the UE.

[0021] In an exemplary embodiment, the LTM failure report information may include at least one of the following associated with the UE: LTM failure type, cell global identifier CGI of the source cell, target cell CGI, rebuilt cell CGI, recovery cell CGI, cell radio network temporary identifier C-RNTI of the source cell, target cell C-RNTI, last serving cell C-RNTI, UE RLF report container, TA invalid indication; or the LTM failure report information may be associated with the failure of the secondary cell group SCG, and include at least one of the following associated with the UE: LTM failure type, source primary and secondary cell PSCell CGI, target PSCell CGI, suitable PSCell CGI, source PSCell C-RNTI, target PSCell C-RNTI, last serving PSCell C-RNTI, SCG failure report container, TA invalid indication.

[0022] In an exemplary embodiment, the first message may be an LTM failure report message, an LTM PSCell failure report message, an access and mobility indication AAMI message, an Xn application protocol Xnap handover report message, or an Xnap failure indication message.

[0023] In an exemplary embodiment, the method performed by the second node may further include: receiving a message including RLF report information from the UE, the RLF report information including at least one of an LTM configuration related to the mobility of the UE and information related to an LTM failure, wherein the LTM configuration may include at least one of the following: an LTM candidate cell list, an LTM candidate cell ID, an LTM source cell ID, an LTM channel state information CSI resource configuration, and an LTM CSI report configuration, wherein the information related to the LTM failure may include at least one of the following: source cell information, target cell information, neighboring cell information, LTM candidate cell information, LTM cell information, last switching type information, information indicating a rach-based access failure based on a random access channel or a rach-less access failure without a random access channel, information about a rach-less access failure, or wherein the information related to the LTM failure may be associated with a secondary cell group SCG failure and include at least one of the following: an LTM failure type, source primary and secondary cell PSCell information, target PSCell information, neighboring PSCell information, an LTM candidate PSCell list, an LTM PSCell identifier, information indicating rach-based access failure or rach-less access failure, and information about rach-less access failure.

[0024] In an exemplary embodiment, the LTM failure report information may include an LTM configuration related to the mobility of the UE, and the LTM configuration includes at least one of the following: an LTM candidate cell list, an LTM candidate cell ID, an LTM source cell ID, an LTM CSI resource configuration, and an LTM CSI report configuration.

[0025] In an exemplary embodiment, the method performed by the second node may also include: sending a second message related to the UE context release to the first node, the second message including an LTM configuration retention indicator, wherein the LTM configuration retention indicator may be used to instruct the first node to retain the LTM configuration related to the mobility of the UE while releasing the LTM configuration that is not related to the mobility of the UE, and the LTM configuration related to the mobility of the UE may include at least one of the following: LTM candidate cell list, LTM candidate cell ID, LTM source cell ID, LTM CSI resource configuration, LTM CSI report configuration.

[0026] In an exemplary embodiment, the second message may be an F1 application protocol F1 AP UE context release command message, a UE context modification request message, or an Xnap UE context release message.

[0027] In an exemplary embodiment, the information about the rach-less access failure may include at least one of the following: information related to not receiving a dynamic grant, information related to not receiving an uplink scheduling of a new transmission, information related to an invalid TA value and / or an actual TA value.

[0028] In an exemplary embodiment, the method performed by the second node may also include: receiving and storing a message of LTM configuration related to the mobility of the UE, the LTM configuration including at least one of the following: an LTM candidate cell list, an LTM candidate cell ID, an LTM source cell ID, an LTM CSI resource configuration, and an LTM CSI report configuration, wherein the previously received and stored LTM configuration is included in the first message sent.

[0029] In an exemplary embodiment, the message for LTM configuration related to the mobility of the UE may be a sequence number SN status transfer message.

[0030] In an exemplary embodiment, the method performed by the second node may further include: determining that a rach-less access failure is about to occur to the UE; and sending an indication to the UE to fall back to rach-based access.

[0031] In an exemplary embodiment, determining that the UE is about to fail rach-less access may include determining that the UE is about to fail rach-less access based on an invalid TA value of a target cell configured for rach-less access or a timeout of a TAT timer.

[0032] According to other aspects of the present disclosure, a first node, a UE and a second node for executing the above method are also disclosed.

[0033] According to other aspects of the present disclosure, a computer-readable storage medium is also disclosed, which stores computer-executable instructions. When the computer-executable instructions are executed by a processor, the processor executes the method performed by the first node, UE or the second node.

[0034] According to the technical solution of the present invention, by updating the LTM configuration and / or triggering strategy related to the UE's mobility according to the LTM failure report information related to the UE, similar failures can be avoided in subsequent LTM processes, thereby making the LTM process have a higher switching success rate. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 is an exemplary system architecture according to the system architecture evolution of the present disclosure.

[0036] Figure 2 is an exemplary system architecture according to various embodiments of the present disclosure.

[0037] Figure 3 is a flow chart of the LTM process in the prior art.

[0038] Figure 4a and Figure 4b is a flow chart regarding LTM failure analysis and reporting in an LTM process according to an exemplary embodiment of the present disclosure.

[0039] Figure 5a , Figure 5b and Figure 5c The invention is a flowchart of a storage and transmission scheme for LTM configuration in an LTM process according to an exemplary embodiment of the present disclosure.

[0040] Figure 6a , Figure 6b and Figure 6c The invention is a flowchart of a storage and transmission scheme for LTM configuration in an LTM process according to an exemplary embodiment of the present disclosure.

[0041] Figure 7 is a schematic diagram of a rach-less access process in an LTM process according to an exemplary embodiment of the present disclosure.

[0042] Figure 8ais a flowchart of an LTM process in a dual-connection scenario according to an exemplary embodiment of the present disclosure.

[0043] Figure 8b and 8c is Figure 8a Flowchart of LTM failure analysis and reporting during LTM process in dual connection scenario.

[0044] Figure 8d , Figure 8e and Figure 8f is Figure 8a Flowchart of the LTM configuration storage and transmission solution in the LTM process in a dual-connection scenario.

[0045] Fig. 9 A method performed by a first node according to an exemplary embodiment of the present disclosure is shown.

[0046] Fig.10 A method performed by a UE according to an exemplary embodiment of the present disclosure is shown.

[0047] Fig.11 A method performed by a second node according to an exemplary embodiment of the present disclosure is shown.

[0048] Fig.12 An exemplary structure of each node applicable to the present disclosure is shown. DETAILED DESCRIPTION

[0049] The drawings discussed below and the various embodiments used to describe the principles of the present disclosure are for illustration only and should not be interpreted in any way as limiting the scope of the present disclosure. Those skilled in the art will appreciate that the principles of the present disclosure can be implemented in any suitably arranged system or device.

[0050] Figure 1It is an exemplary system architecture 1000 of System Architecture Evolution (SAE). User Equipment (UE) 1001 is a terminal device used to receive data. Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) 1002 is a wireless access network, which includes a macro base station (eNodeB / NodeB) that provides a wireless network interface for the UE to access. Mobility Management Entity (MME) 1003 is responsible for managing the mobility context, session context and security information of the UE. Services Gateway (SGW) 1004 mainly provides user plane functions, and MME 1003 and SGW 1004 may be in the same physical entity. Packet Data Network Gateway (PGW) 1005 is responsible for functions such as billing and lawful interception, and may also be in the same physical entity as SGW 1004. The Policy and Charging Rule Function (PCRF) 1006 provides Quality of Service (QoS) policies and charging criteria. The Serving GPRS Support Node (SGSN) 1008 is a network node device that provides routing for data transmission in the Universal Mobile Telecommunications System (UMTS). The Home Subscriber Server (HSS) 1009 is the home subsystem of the UE, responsible for protecting user information including the current location of the user equipment, the address of the service node, user security information, and the packet data context of the user equipment.

[0051] Figure 2It is an exemplary system architecture 2000 according to various embodiments of the present disclosure. Other embodiments of the system architecture 2000 can be used without departing from the scope of the present disclosure. UE 2001 is a terminal device for receiving data. Next Generation-Radio Access Network (NG-RAN) 2002 is a radio access network, which includes a base station (gNB or eNB connected to the fifth generation (5th Generation, 5G) core network 5GC (5G core) that provides a wireless network interface for the UE to access. The eNB connected to the 5GC is also called ng-gNB). The access control and mobility management function (Access and Mobility Management Function, AMF) 2003 is responsible for managing the mobility context and security information of the UE. The user plane function (User Plane Function, UPF) 2004 mainly provides the functions of the user plane. The session management function SMF 2005 is responsible for session management. The data network (Data Network, DN) 2006 includes services such as operators, access to the Internet and third-party services.

[0052] For the convenience of description, the following description of the embodiments of the present disclosure involves special names and explanations as follows:

[0053] 1.LTM (L1 / L2 Triggered Mobility): Layer 1 / Layer 2 Triggered Mobility

[0054] 2.CFRA (Contention Free Random Access): Non-contention random access

[0055] 3.CSI (Channel State Information): Channel State Information

[0056] 4.CGI (Cell Global ID): Cell Global ID

[0057] 5.RLF (Radio Link Failure): Radio link failure

[0058] 6.AMF (Access and Mobility Management Function): Access and mobility management function is the network element of the 5G core network, responsible for 5G base station access and mobility management. The 5G base station is connected to the AMF through the NG-C interface.

[0059] 7.NG-RAN (New Generation Radio Access Network) node: Next generation radio access network node, for example, 5G base station, including gNB or ng-eNB.

[0060] 8.gNB (next Generation Node B): next generation base station node, for example, 5G NR (New Radio) base station.

[0061] 9.gNB-DU (Distributed Unit): gNB distributed unit, gNB-DU has functions such as Radio Link Control (RLC) protocol, Medium Access Control (MAC) and Physical Layer (PHY) protocol.

[0062] 10.gNB-CU (Central Unit): gNB centralized unit. gNB-CU has functions such as Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP) and Packet Data Convergence Protocol (PDCP).

[0063] It should be understood that the message names in the present disclosure are only examples and other names may be used. The information to be transmitted between interfaces may be defined in a new message separately or by adding a new information element (IE) to an existing message in the existing corresponding interface specification.

[0064] Exemplary embodiments of the present disclosure are further described below in conjunction with the accompanying drawings.

[0065] The text and drawings of the present disclosure are provided as examples only to help understand the present disclosure. They should not be interpreted as limiting the scope of the present disclosure in any way. Although certain embodiments and examples have been provided, based on the contents disclosed herein, it is obvious to those skilled in the art that the embodiments and examples shown may be changed without departing from the scope of the present disclosure.

[0066] For the LTM process, the UE accesses the target cell from the source cell through LTM. From the perspective of technical implementation, it may not be guaranteed to be successful every time. For example, various abnormal situations may occur, resulting in LTM cell switching failure, connection failure, or radio link failure after accessing the target cell. In these cases, the UE needs to select a cell. If the selected cell is an LTM candidate cell, the UE performs a random access channel (rach-based) LTM cell switching on the selected cell to achieve rapid recovery. However, if the cell selected by the UE is not an LTM candidate cell, the UE sends an RRC re-establishment request to the selected cell. Obviously, if failures often occur during the LTM execution process, not only can the normal service of the UE not be guaranteed, but the service interruption delay will be aggravated.

[0067] Therefore, it is necessary to consider how to perform corresponding optimization after a failure occurs in the LTM mobility process, so as to avoid similar failures in subsequent LTM mobility processes and achieve a higher LTM switching success rate.

[0068] To this end, the present disclosure proposes a solution for analyzing abnormal scenarios where LTM failure occurs and optimizing the abnormal scenarios.

[0069] Figure 3 is a flow chart of an exemplary LTM process according to the present disclosure. In order to illustrate the possible failure scenarios in the LTM execution process, the normal LTM process is first introduced. Figure 3 The process shown is the scenario where the UE moves from one gNB-DU to another gNB-DU under the same gNB-CU during NR LTM. The process is as follows:

[0070] 1.L3 measurement control and reporting

[0071] In one embodiment, the UE sends a Measurement Report message (which reports the L3 measurement results) to the source gNB-DU, which contains the measurement values ​​of the neighboring cells. The source gNB-DU sends an UL RRCMESSAGE TRANSFER message to pass the received Measurement Report message to the gNB-CU.

[0072] 2. The gNB-CU decides to initiate LTM configuration.

[0073] 3. The gNB-CU sends a UE CONTEXT SETUP REQUEST message to the candidate gNB-DU, which contains a candidate cell ID, the LTM configuration ID of the candidate cell, the LTM configuration ID mapping list, and the CSI resource configuration. The gNB-CU indicates the source gNB-DU ID and requests Physical Random Access Channel (PRACH) resources from the candidate gNB-DU. The gNB-CU may request the candidate gNB-DU to provide low layer configuration to generate a reference configuration.

[0074] 4. If the candidate gNB-DU accepts the LTM Configuration Request, it shall respond with a UECONTEXT SETUP RESPONSE message including the low-layer RRC configuration (e.g., Transmission Channel Indication (TCI) state configuration and Random Access Channel (RACH) configuration) and CSI reporting configuration generated for the accepted target candidate cell.

[0075] 5. The gNB-CU sends a UE CONTEXT MODIFICATION REQUEST message to the source gNB-DU, including the CSI reporting configuration, TCI state configuration, and RACH configuration of the target candidate cells that have been accepted by other gNB-DUs.

[0076] 6. The source gNB-DU sends a UE CONTEXT MODIFICATION RESPONSE message as a response. This message may include the CSI report configuration generated for the prepared candidate cell.

[0077] 7. The gNB-CU sends a UE Context Modification Request message to the candidate gNB-DU, which contains the CSI reporting configuration, TCI state configuration, RACH configuration, and LTM configuration ID of the candidate cell in the other candidate gNB-DUs. The gNB-CU may also provide the reference configuration of the low layer part to the candidate gNB-DU. The gNB-CU may also provide the updated CSI resource configuration to the candidate gNB-DU. As a possibility, the candidate cell may be the same cell as the source cell.

[0078] 8. The candidate gNB-DU sends a UE Context Modification Response message as a response, including the updated lower layer configuration. The response sent by the candidate gNB-DU may also include the updated CSI reporting configuration.

[0079] 9. The gNB-CU sends a DL RRC MESSAGE TRANSFER message to the source gNB-DU, which contains the generated RRC Reconfiguration message with LTM configuration.

[0080] 10. The source gNB-DU forwards the received RRC Reconfiguration message to the UE.

[0081] 11. The UE sends an RRCReconfigurationComplete message to the source gNB-DU.

[0082] 12. The source gNB-DU forwards the RRC Reconfiguration Complete message to the gNB-CU via the UL RRC MESSAGE TRANSFER message.

[0083] 13. Early synchronization is performed to obtain an early timing advance (TA) value.

[0084] 14-15. The candidate gNB-DU sends the TA value information, associated CFRA resource information, candidate cell ID and source gNB-DU ID to the source gNB-DU via DU-CU TA INFORMATION TRANSFER and CU-DU TA INFORMATION TRANSFER messages. The source gNB-DU ID is omitted in the CU-DU TA INFORMATION TRANSFER message.

[0085] 16. The UE sends a Layer 1 measurement report to the source gNB-DU.

[0086] 17. The source gNB-DU decides to perform LTM cell handover to a candidate target cell.

[0087] 18. The source gNB-DU sends a Cell Switch command to the UE.

[0088] 19. The source gNB-DU sends a DU-CU CELL SWITCH NOTIFICATION message to the gNB-CU, indicating that a cell switch command has been initiated to the UE. The DU-CU CELL SWITCH NOTIFICATION message includes the target cell ID and TCI state ID.

[0089] 20. The gNB-CU sends the target cell ID and TCI state ID to the target gNB-DU through the CU-DU CELL SWITCH NOTIFICATION.

[0090] 21. The target gNB-DU detects that the UE has successfully accessed (based on rach-less or rach-based access procedure).

[0091] 22. The target gNB-DU sends an ACCESS SUCCESS message to the gNB-CU and carries the target cell ID.

[0092] 23. The UE sends an RRCReconfigurationComplete message to the target gNB-DU.

[0093] 24. The target gNB-DU forwards the RRC Reconfiguration Complete message to the gNB-CU via the UL RRC MESSAGE TRANSFER message.

[0094] 25. The gNB-CU may send a UE CONTEXT RELEASE COMMAND message to the source gNB-DU to release the prepared cell (including the source cell) resources and configuration.

[0095] 26. The source gNB-DU sends a UE CONTEXT RELEASE COMPLETE message to the gNB-CU in response.

[0096] Figure 4a and Figure 4b This is a flowchart of LTM failure analysis and reporting in the LTM process according to an exemplary embodiment of the present disclosure. This embodiment is when an LTM connection failure occurs before the execution process of intra-gNB-CU inter-gNB-DU LTM, or a failure occurs during the LTM execution process (i.e., the UE does not successfully complete the RA (random access) process, i.e., the rach-based (based on random access channel) process or the rach-less (no random access channel) process, and accesses the target cell), or a radio link failure occurs immediately after successfully accessing the target cell. See Figure 4a and Figure 4b , at step 100, an intra-system LTM failure occurs during the LTM process.

[0097] The types of switching failure are as follows, and the corresponding switching failure scenarios may include the corresponding LTM failure types during the execution of LTM:

[0098] 1. Too Late Handover, including too late execution of LTM: When RLF occurs after the UE stays in the serving cell for a long time, the UE attempts to re-establish the radio link connection in a different cell.

[0099] 2. Too Early Handover, including too early execution of LTM: RLF occurs shortly after a successful handover from a source cell to a target cell, or a handover failure occurs during the handover process, and the UE attempts to re-establish a radio link connection in the source cell.

[0100] 3. Handover to Wrong Cell, including LTM executed to the wrong cell: RLF occurs shortly after a successful handover from the source cell to the target cell, or a handover failure occurs during the handover process, and the UE attempts to re-establish the radio link connection in a cell other than the source cell and the target cell.

[0101] 4. Ping-pong Handover (Handover Ping-pong), including Ping-pong LTM execution: The UE switches from the source cell to the target cell and then switches back to the source cell within a predefined limited time, while the coverage of the source cell is sufficient to meet the service used by the UE. This event may occur more than once.

[0102] In the case of LTM, handover too late, handover too early and handover to wrong cell mean LTM execution too late (TooLate LTM Execution or LTM Too Late), LTM execution too early (Too Early LTM Execution or LTMToo Early) and LTM execution to wrong cell (LTM Execution to Wrong Cell or LTM to WrongCell).

[0103] For the first three LTM failure scenarios above, i.e. LTM is executed too late, LTM is executed too early, and LTM is executed to the wrong cell, when the UE encounters the above scenarios, the UE performs cell selection. If the cell selected by the UE is an LTM candidate cell, a rach-based (based on random access channel) LTM cell switching process is performed to quickly restore the radio link. If the selected cell is not an LTM candidate cell, the UE initiates an RRC re-establishment request to this cell, attempting to re-establish the radio link connection.

[0104] For the first three LTM failure scenarios above, no matter which failure occurs, the UE will tell the gNB-CU in step 101 through an RRC message carrying an indication IE that the UE side has available radio link failure (rlf) or handover failure (hof) information. The RRC message used is, for example, an RRCReestablishmentComplete, RRCReconfigurationComplete, or RRCSetupComplete message. The indication IE carried can be, for example, an rlf information available IE (rlf-InfoAvailable) contained in a UE-MeasurementsAvailable message. Then the gNB-CU requests the UE to report its radio link failure or handover failure information through a UE InformationRequest message in step 102. The UE InformationRequest message carries an rlf report request information element (rlf-ReportReq IE). In step 103, the UE reports the radio link failure or handover failure information to the gNB-CU via a UE Information Response message, and the UE Information Response message carries an rlf-Report IE. The RRC messages between the UE and the gNB-CU are forwarded via the gNB-DU currently serving the UE (i.e., the gNB-DU to which the cell selected by the UE for cell selection and restoration of the radio link connection after the LTM failure occurs) via F1AP (F1 Application Protocol) downlink RRC message transfer (DL RRC MESSAGE TRANSFER) and F1AP uplink RRC message transfer (UL RRC MESSAGE TRANSFER). The downlink RRC message transfer and the uplink RRC message transfer contain RRC containers carrying the UE Information Request and the UE Information Response, respectively.

[0105] According to an exemplary embodiment of the present disclosure, after the gNB-CU receives the information about the rlf report reported by the UE, the gNB-CU or gNB-DU can analyze the cause of the LTM failure. Figure 4a and Figure 4b 2 alternatives shown.

[0106] exist Figure 4a In the exemplary embodiment shown, the analysis of the cause of LTM failure is performed by the gNB-CU.

[0107] In step 104, the gNB-CU sends the LTM Failure Report information to the source gNB-DU.

[0108] Optionally, a new LTM failure report message is sent to the source gNB-DU, or the F1AP Access And Mobility Indication (AAMI) message is reused to carry the LTM failure report information, or the gNB-CU notifies the source gNB-DU of the LTM failure report information in other ways. The source gNB-DU then optimizes the LTM configuration (e.g., mobility parameters) or the LTM trigger policy. The optimization of the LTM configuration or the LTM trigger policy may, for example, be an update of the LTM configuration or the LTM trigger policy.

[0109] Optionally, step 410, gNB-CU analysis may be included before step 104.

[0110] Optionally, in step 410, the gNB-CU analyzes the cause of the LTM failure in step 410 based on the information related to the LTM failure contained in the rlf report reported by the UE, and generates LTM failure report information after the analysis is completed. Figure 4b In the exemplary embodiment shown, the analysis of the cause of LTM failure is performed by the gNB-DU (source gNB-DU or target gNB-DU). Figure 4b Steps 100 to 103 in Figure 4a Steps 100 to 103 are the same as in FIG. 1 and will not be repeated here.

[0111] Optionally, step 420 of target DU analysis may be included before step 105 .

[0112] Optionally, after the gNB-CU collects the information related to the LTM failure contained in the rlf report reported by the UE, it sends this information to the gNB-DU for analysis in step 107 to generate LTM failure report information. Depending on the LTM failure scenario, the gNB-CU sends the collected rlf report information to the source gNB-DU or the candidate (target) gNB-DU for analysis. For example, in the case where LTM is executed too late, the gNB-CU sends the rlf report information to the source gNB-DU in step 421 for analysis and optimization of the LTM configuration and / LTM trigger strategy. In the case where LTM is executed too early or LTM is executed in the wrong cell and the UE fails during the switching process, optionally, the gNB-CU sends the rlf report information to the source gNB-DU in step 421 for analysis and optimization of the LTM configuration and / LTM trigger strategy. Optionally, the gNB-CU may send the rlf report information to the gNB-DU via the F1AP AAMI message. For the case where the UE successfully accesses the target cell and the RLF occurs after the LTM is executed too early or the LTM is executed in the wrong cell, the gNB-CU optionally sends the RLF report information to the candidate gNB-DU for analysis. The candidate gNB-DU is the gNB-DU where the target cell is located. The radio link failure occurs immediately after the UE successfully accesses the target cell. Figure 4b In the embodiment of the embodiment, the gNB-CU may send the rlf report information to the candidate gNB-DU via an AAMI message in step 107. Optionally, the candidate gNB-DU analyzes the cause of the LTM failure in step 420, generates LTM failure report information after the analysis, sends the LTM failure report information to the gNB-CU in step 105, and then the gNB-CU sends the LTM failure report information to the source gNB-DU in step 104. Afterwards, the source gNB-DU optimizes the LTM configuration and / or LTM triggering strategy.

[0113] exist Figure 4a In the embodiment, the gNB-CU sends the LTM failure report information generated by the LTM failure analysis to the source gNB-DU. Optionally, the LTM failure report information can be sent from the gNB-CU to the source gNB-DU by means of a new LTM failure report message, or by reusing the F1AP AAMI message to carry the LTM failure report information, or the LTM failure report information can be notified to the source gNB-DU by other means. Then, the source gNB-DU optimizes the LTM configuration and / or the LTM triggering strategy.

[0114] exist Figure 4bIn the embodiment, the gNB-DU sends the LTM failure report information generated by the LTM failure analysis to the source gNB-DU. Optionally, the gNB-DU may send the LTM failure report to the gNB-CU by means of a new LTM failure report message or other means, and then the gNB-CU sends the LTM failure report information to the source gNB-DU by means of a new LTM failure report message or by reusing the F1AP AAMI message to carry the LTM failure report information, or notifies the source gNB-DU of the LTM failure report information by other means. Then, the source gNB-DU optimizes the LTM configuration and / or LTM triggering strategy.

[0115] In the above, whether the gNB-CU performs LTM failure analysis or the gNB-DU performs LTM failure analysis, the LTM failure report information generated after the analysis must be transmitted to the source gNB-DU, and then the source gNB-DU optimizes the LTM configuration and / or LTM triggering strategy. This is because, during the LTM preparation process, the source gNB-DU generates the corresponding CSI report configuration for the prepared candidate cell (optionally, it can be included in LTM-CSI-ReportConfig or LTM-CSI-ReportConfigToAddModList). Based on the principle that which node generates the configuration is responsible for optimizing the configuration, since the CSI report configuration of the candidate cell is generated by the source gNB-DU, the optimization of the corresponding configuration is also the responsibility of the source gNB-DU. Therefore, the corresponding LTM failure report information needs to be sent to the source gNB-DU, and then the source gNB-DU optimizes the LTM CSI report configuration (LTM-CSI-ReportConfig) parameters. In addition, the triggering of LTM is that the source gNB-DU decides which target cell to select based on the L1 measurement report reported by the UE, and then sends a cell switch command (Cell Switch Command) and carries the target cell ID to command the UE to switch. Since both the generation of the configuration of the measurement report of the candidate cell and the triggering of the LTM cell switch command are determined by the source gNB-DU, it is reasonable for the source gNB-DU to optimize the LTM configuration or mobility parameters or adjust the LTM triggering strategy. Therefore, the LTM failure report generated by the gNB-CU or gNB-DU analysis needs to be sent to the source gNB-DU in the end.

[0116] In the above process, the LTM failure report message or information generated by the gNB-CU, or the LTM failure report message or information generated by the candidate gNB-DU analysis, sent to the gNB-CU and then forwarded by the gNB-CU to the source gNB-DU, may include one or more of the following information:

[0117] -LTM report type: indicates the failure type, which is LTM executed too early, LTM executed too late, LTM executed to the wrong cell, or ping-pong LTM execution. The ping-pong LTM execution type can be determined by the gNB-CU based on the visited cell information list (VisitedCellInfoList) in the mobility history report (MobilityHistoryReport) IE reported by the UE or the source cell and target cell where the UE resides through LTM and the residence time known by the gNB-CU.

[0118] - Source Cell CGI: CGI of the source cell for the LTM procedure in the source gNB-DU.

[0119] - Target cell CGI: CGI of the target cell for the LTM procedure in the candidate gNB-DU.

[0120] -CGI of re-established cell: CGI of the non-candidate cell that the UE attempts to re-establish after a failure or the candidate cell that the UE successfully connects to after a failure. This information is included when the LTM report type is LTM executed to an erroneous cell.

[0121] -Recovery cell CGI: When the LTM report type is LTM executed to the wrong cell, the CGI of the candidate cell selected by the UE after the LTM failure to which the UE successfully reconnected.

[0122] -Source Cell C-RNTI: The cell radio network temporary identifier allocated at the source gNB-DU. The C-RNTI used in the source cell after a handover failure or radio link failure enables the source gNB-DU to query the saved UE context to match the corresponding LTM failure report.

[0123] -Target cell C-RNTI: The cell radio network temporary identifier allocated at the target gNB-DU. It is the C-RNTI used in the target cell after detecting a radio link failure or a handover failure. The gNB-DU that receives the rlf report can determine whether the radio link failure involved in the rlf report occurred on this gNB-DU through this information without decoding the content in the rlf report.

[0124] -Last serving cell C-RNTI: The cell radio network temporary identifier allocated at the last serving gNB-DU. It is the C-RNTI used in the last serving cell after detecting a radio link failure or a handover failure. The gNB-DU that receives the rlf report can determine whether the radio link failure involved in the rlf report occurred on this gNB-DU through this information without decoding the content in the rlf report.

[0125] -UE RLF report container: UE radio link failure report container, including the new radio rlf report IE (nr-RLF-Report-r16IE) in the UE information response message defined in TS 38.331.

[0126] -TA invalid indication: indicates that the rach-less access failure occurred due to TA invalidity. Optionally, the TA invalidity conclusion can be drawn by comparing the TA value received from the source gNB-DU (carried in the cell handover command) reported by the UE and the actual TA value (rach-based access is performed after rach-less failure).

[0127] The source gNB-DU optimizes the LTM configuration and / or LTM triggering strategy based on the received information.

[0128] The above characteristics of LTM failure in intra-gNB-CU inter-gNB-DU LTM process also apply to the scenario where LTM failure occurs in intra-gNB-CU intra-gNB-DU LTM process. After the gNB-CU receives the information about the RLF report reported by the UE, it can choose to Figure 4a and Figure 4b The illustrated embodiment analyzes the cause of LTM failure by the gNB-CU or gNB-DU.

[0129] In addition, for the case where an RLF occurs after a UE successfully accesses a target cell after LTM is executed in an erroneous cell, the following cases may also be considered based on the above embodiments:

[0130] - If the reestablished cell or suitable cell selected by the UE after RLF is one of the candidate cells provided by the node initiating LTM (gNB-CU), but is not one of the candidate cells selected by the (candidate) target gNB-DU, this is a wrong target cell selection at the (candidate) target gNB-DU. In this case, the gNB-CU can optionally notify the (candidate) target gNB-DU of the analyzed report for LTM configuration and / or optimization of the LTM triggering strategy. For example, this cell (suitable cell) can be considered to be added to the LTM candidate cell list configured for the UE.

[0131] - Otherwise, it is a wrong candidate cell list selection at the node initiating LTM (gNB-CU), and optimization of LTM configuration and / or LTM triggering strategy is required on the gNB-CU side, or optimization of LTM configuration and / or LTM triggering strategy is required on the source gNB-DU side.

[0132] Figure 5a , Figure 5b and Figure 5c 1 is a flowchart of storage and transmission of LTM configuration information in an LTM process according to an exemplary embodiment of the present disclosure. As described above, in the source gNB-DU, for example, according to Figure 4a and Figure 4b In the illustrated embodiment, after receiving the LTM failure report message or related information, the source gNB-DU optimizes the LTM configuration and / or LTM triggering strategy. However, in some LTM failure scenarios, the parameters related to LTM mobility may have been released together with the UE context on the source gNB-DU side, making it impossible to properly optimize the LTM configuration and / or LTM triggering strategy. Figure 5a , Figure 5b and Figure 5c An exemplary embodiment is provided to address this problem.

[0133] Referenced above Figure 3 describes the normal process for LTM. Similarly, Figure 5a , Figure 5b and Figure 5cIn an embodiment, after the LTM resource preparation is completed, the UE reports a low-layer measurement report, such as a layer 1 measurement report (L1Measurement Report) in step 200. The source gNB-DU makes an LTM cell switching decision in step 201 based on the UE's measurement report, and sends a cell switching command carrying the target cell ID to the UE in step 202. The source gNB-DU sends a DU-CU cell switch notification (DU-CU Cell Switch Notification) to the gNB-CU in step 203, and the gNB-CU forwards the CU-DU cell switch notification (CU-DU Cell Switch Notification) to the candidate gNB-DU in step 204, and the DU-CU / CU-DU cell switch notification carries the target cell ID. Optionally, after the UE successfully accesses the target cell in step 205, the corresponding candidate gNB-DU sends an access success (Access Success) message carrying the target cell ID to the gNB-CU in step 206. The UE sends an RRC Reconfiguration Complete message to the candidate gNB-DU in step 207, and the candidate gNB-DU sends an UL RRC Messaging message carrying the RRC Reconfiguration Complete message to the gNB-CU in step 208. In step 210, the gNB-CU triggers the F1 UE Context Release procedure to the source gNB-DU. Optionally, in step 209, the gNB-CU triggers the F1 UE Context Release procedure to the candidate gNB-DU.

[0134] For the scenario where LTM is executed to the wrong cell, if an RLF failure occurs in step 211 (the timer value reported by the UE is less than the pre-configured threshold) shortly after the UE successfully accesses the target cell, the UE performs cell selection to reconnect to other cells, or quickly recovers to other candidate cells, and notifies the gNB-CU that the UE side has available RLF or Hof information. The other cells and other candidate cells here are neither the source cells nor the target cells where the RLF occurs. When the gNB-CU obtains the RLF report from the UE depends on the network implementation.

[0135] For the scenario where LTM is executed to the wrong cell, if RLF occurs immediately after the UE successfully accesses the target cell, when the gNB-CU receives the access success message of the candidate gNB-DU, it can trigger a UE context release command or UE context modification request process to the source gNB-DU to release the UE's LTM configuration for the source cell. For example, in the nonsubsequent LTM configuration, the UE accesses the target cell, executes LTM once, and the resources of other candidate cells need to be released. Or, in the subsequent LTM configuration, if the source cell is not a candidate cell, the resources of the source cell need to be released. When RLF occurs, the UE performs cell selection and reestablishes the radio link connection, as shown in step 212. The other cell selected by the UE may be a candidate cell in the candidate gNB-DU or a non-candidate cell in other gNB-DUs. After the reestablishment is completed, the UE will tell the gNB-CU through an RRC message that there is available radio link failure or handover failure information on the UE side. Then, the gNB-CU requests the UE to report this information through a UE information request message (carrying an RLF report request IE) in step 213. Next, the UE reports this information to the gNB-CU through a UE information response message (carrying an rlf report IE) in step 214. In step 215, the gNB-CU or gNB-DU analyzes the cause of the LTM failure. The RRC messages of the UE and gNB-CU are forwarded by the gNB-DU currently serving the UE through the F1AP message DLRRC message transmission and the RRC container (carrying UE information request or UE information response) contained in the UL RRC message transmission. After the LTM failure occurs, the UE performs cell selection and restores the radio link connection. The gNB-DU to which the selected cell belongs is the gNB-DU currently serving the UE.

[0136] The following reference Figure 5a , Figure 5b and Figure 5c An exemplary embodiment regarding LTM configuration in the LTM process is described.

[0137] Figure 5a An embodiment of storing LTM configuration by UE is shown. Regarding LTM configuration, since gNB-CU has configured UE through RRC reconfiguration message in the LTM resource configuration preparation stage, the UE side has these configuration information. Since UE knows that radio link failure has occurred, the behavior of UE can be defined: when an rlf report is generated in the event of radio link failure, LTM configuration information is included in the rlf report IE. After gNB-CU obtains the rlf report, the gNB-CU or gNB-DU can analyze the cause of LTM failure in step 215. The specific process can be, for example, based on Figure 4a and Figure 4b Embodiment. When the gNB-CU generates an LTM failure report message or information, or receives an LTM failure report message or information generated by the candidate gNB-DU analysis, it needs to be sent to the source gNB-DU. At this time, in step 216, the rlf report IE information is carried by a new LTM failure report message or by reusing the F1AP AAMI message and sent to the source gNB-DU. In this way, although the source gNB-DU releases the UE context, it also obtains the LTM configuration when it receives the LTM failure report and rlf report IE information. Then, the source gNB-DU optimizes the LTM configuration and / LTM trigger strategy.

[0138] Figure 5b An embodiment of storing LTM configuration by gNB-CU is shown. When the gNB-CU receives the access success message of the candidate gNB-DU in step 206, it can trigger a UE context release command or a UE context modification request process to the source gNB-DU in step 210 to release the UE's LTM configuration about the source cell. For example, in a non-subsequent LTM configuration, the UE accesses the target cell, and after executing LTM once, other candidate resources need to be released. Alternatively, in a subsequent LTM configuration, if the source cell is not a candidate cell, the resources of the source cell need to be released. In order to prevent the occurrence of rlf immediately after the UE successfully accesses, and the gNB-CU has triggered the context release of the source cell at this time, the behavior of the gNB-CU can be defined: after receiving the Access Success message, the gNB-CU stores the LTM configuration related to the source cell and the mobility, and releases the LTM configuration unrelated to the mobility, and triggers the context release process of the source cell to the source gNB-DU normally. When the gNB-CU receives the rlf report, the gNB-CU or gNB-DU can analyze the cause of the failure in step 215. The specific process can be, for example, according to Figure 4a and Figure 4b Embodiment. When the gNB-CU generates LTM failure report information or message, or receives LTM failure report information or message generated by candidate gNB-DU analysis, it needs to be sent to the source gNB-DU. At this time, in step 216, the stored LTM configuration and rlf report IE information are carried and sent to the source gNB-DU by means of a new LTM failure report message, or by reusing the F1APAAMI message, and then the gNB-CU deletes the stored LTM configuration. In this way, although the source gNB-DU releases the UE context, it also obtains the LTM configuration when receiving the LTM failure report and rlf report IE information. Then, the source gNB-DU optimizes the LTM configuration and / LTM trigger strategy.

[0139] If the UE successfully accesses the target cell and no RLF occurs, there is no need to keep the LTM configuration of the UE retained by the gNB-CU. In the intra-gNB-CU inter-gNB-DU LTM scenario, since the UE is under the same gNB-CU, the gNB-CU knows whether RLF occurs after the UE accesses the target cell. If RLF occurs, the LTM configuration retained by the gNB-CU is useful. When sending an LTM failure report message or information or an RLF report IE information to the source gNB-DU, the retained LTM failure report will be carried and then deleted by itself. If no RLF occurs, the retained LTM configuration can be deleted by itself.

[0140] Figure 5c An embodiment of storing LTM configuration by the source gNB-DU is shown. When the gNB-CU receives the access success message of the candidate gNB-DU in step 206, it can trigger a UE context release command or a UE context modification request process to the source gNB-DU in step 210 to release the UE's LTM configuration about the source cell. For example, in a non-subsequent LTM configuration, the UE accesses the target cell, and after performing an LTM once, the resources of other candidate cells need to be released. Alternatively, in a subsequent LTM configuration, if the source cell is not a candidate cell, the resources of the source cell need to be released. In order to prevent the occurrence of RLF immediately after the UE accesses successfully, and at this time the gNB-CU has triggered the context release of the source cell to the source gNB-DU, an indication IE can be carried in the UE context release command or UE context modification request message sent in step 210. For example, an LTM configuration kept indicator can be carried, and optionally, a cell ID (e.g., source cell CGI) can be carried. The source gNB-DU is notified by the carried indication IE to store the LTM configuration related to the source cell and mobility in the UE context, and release the LTM configuration unrelated to mobility. After the gNB-CU receives the rlf report, the gNB-CU or gNB-DU can analyze the cause of the LTM failure in step 215. The specific process can be, for example, based on Figure 4a and Figure 4bEmbodiment. When the gNB-CU generates LTM failure report information or message, or receives LTM failure report information or message generated by the candidate gNB-DU analysis, it needs to be sent to the source gNB-DU. At this time, in step 216, the LTM failure report information and rlf report IE information are carried and sent to the source gNB-DU by means of a new LTM failure report message, or by reusing the F1AP AAMI message. When the source gNB-DU receives the LTM failure report, it associates the LTM failure report information with the stored LTM configuration. Then, the source gNB-DU optimizes the LTM configuration and / or LTM trigger strategy.

[0141] If the UE successfully accesses the target cell and no RLF occurs, there is no need to continue to save the LTM configuration about this UE that the gNB-CU notifies the source gNB-DU to retain. In the intra-gNB-CU inter-gNB-DU LTM scenario, since the UE is under the same gNB-CU, the gNB-CU knows whether RLF occurs after the UE accesses the target cell. If RLF occurs, the LTM configuration retained by the source gNB-DU is useful. When the source gNB-DU receives the LTM failure report later, it associates the retained LTM configuration with the received LTM failure report and then deletes the retained LTM configuration by itself. If no RLF occurs, the retained LTM configuration can be deleted. For example, the source gNB-DU can delete the retained LTM configuration in the following way.

[0142] Optionally, the gNB-CU may notify the source gNB-DU to release.

[0143] - If the gNB-CU has previously triggered a UE context release command to the source gNB-DU to release the UE context, there is no UE context for F1. In this case, non-UE-related signaling can be used to notify the source gNB-DU to release the retained LTM configuration.

[0144] -If the gNB-CU has previously triggered a UE context modification request to the source gNB-DU to release the UE context regarding the source cell, the UE-associated command can be triggered again to delete the retained LTM configuration. For example, there may be other candidate cells on the source gNB-DU, but if the source cell is not a candidate cell, its resources need to be released; in this case, the gNB-CU triggers a UE context modification request to the source gNB-DU to release the UE context regarding the source cell. For example, the gNB-CU can use a UE context release command or a UE context modification request to carry an indication IE to instruct the source gNB-DU to delete the retained LTM configuration. The carried indication IE can, for example, be an LTM configuration released indicator, and optionally, a cell ID (e.g., source cell CGI).

[0145] Optionally, the maximum retention time of the LTM configuration of the source gNB-DU can be within 2 hours, because the UE's rlf report has a maximum validity period of 2 hours.

[0146] exist Figure 5a In the illustrated embodiment, the above mentioned LTM configuration information related to mobility may be included by the UE in the rlf report IE. Figure 5b In the illustrated embodiment, the above-mentioned LTM configuration information related to mobility may be stored by the gNB-CU and included in the LTM failure report message or information sent to the source gNB-DU. Figure 5c In the illustrated embodiment, the process of the gNB-CU notifying the source gNB-DU to release the UE context of the source cell may carry an indication to notify the source gNB-DU to store the LTM configuration related to the source cell and mobility in the UE context, and release the LTM configuration not related to mobility, and then the source gNB-DU performs corresponding actions.

[0147] The LTM configuration information related to mobility mentioned in the above embodiments may include one or more of the following information:

[0148] -LTM Candidate Cell List: contains each candidate cell ID. The maximum number of candidate cells in the list is maxNrofCellsLTM-r18. Optionally, the LTM candidate cell list can be represented by ltm-CandidateIdList or LTM Configuration ID Mapping List.

[0149] -LTM Candidate Cell ID: It can be represented by NR Cell CGI, which contains the ID information of each LTM candidate cell; optionally, the corresponding LTM candidate cell ID can be represented by LTM-CandidateId or LTM Configuration ID, because there is a corresponding mapping relationship between the three.

[0150] -LTM Source Cell ID: It can be represented by NR Cell CGI; optionally, the corresponding LTM source cell ID can be represented by LTM-CandidateId or LTM Configuration ID, because if the source cell is also used as a candidate cell in the subsequent LTM configuration, there is a corresponding mapping relationship between the three.

[0151] -LTM CSI resource configuration (LTM-CSI-ResourceConfig), corresponding to the configuration information of one or more CSI resources for LTM measurement of one or more LTM candidate cells, is contained in the field ltm-CSI-ResourceConfigToAddModList in the LTM configuration (LTM-Config) IE defined in TS 38.331; optionally, ltm-CSI-ResourceConfigToAddModList can configure multiple LTM CSI resource configurations, and ltm-CSI-ResourceConfigToAddModList can be used to represent all LTM CSI resource configurations.

[0152] -LTM CSI report configuration (LTM-CSI-ReportConfig): Configuration information for measurement reporting corresponding to one or more CSI resources corresponding to LTM measurement (i.e., corresponding to one LTM CSI resource configuration) for one or more LTM candidate cells, contained in the field LTM-CSI-ReportConfigToAddModList in the CSI measurement configuration (CSI-MeasConfig) in the serving cell configuration (ServingCellConfig) in the cell group configuration (CellGroupConfig) IE defined in TS 38.331; Optionally, ltm-CSI-ReportConfigToAddModList can configure multiple LTM CSI report configurations, and ltm-CSI-ReportConfigToAddModList can be used to represent all LTM CSI report configurations.

[0153] For another scenario in which LTM is executed to the wrong cell, in which the UE fails to access the target cell, that is, a handover failure occurs, the above three optional solutions are still applicable. In the event of a failure in the UE access to the target cell, the UE performs cell selection in step 212 to reestablish the radio link connection. The other cell selected by the UE may be a candidate cell in the candidate gNB-DU or a non-candidate cell in other gNB-DUs. After the reconstruction is completed, the UE will tell the gNB-CU through an RRC message that there is available radio link failure or handover failure information on the UE side. Then, the gNB-CU requests the UE to report this information through a UE information request message (carrying an rlf report request IE) in step 213. Next, the UE reports this information to the gNB-CU through a UE information response message (carrying an rlf report IE) in step 214. For this scenario, Figure 5a The illustrated embodiment is applicable, and the UE may carry the LTM configuration in the rlf report. Figure 5b The embodiment shown is also applicable. When the gNB-CU does not receive an access success message carrying the target cell ID, or when the UE cell selects another LTM candidate, when it receives an access success message from another candidate gNB-DU carrying a different candidate cell ID (compared with the target cell ID in the DU-CU cell switching notification), or when the UE selects a cell other than the LTM candidate cell, it can be determined that the UE has not successfully accessed the target cell, so that it can be used Figure 5cThe embodiment shown. When the gNB-CU determines that the UE has not successfully accessed the target cell, the LTM configuration in the UE context can be stored before the UE context is released. When the gNB-CU generates LTM failure report information or message and needs to send it to the source gNB-DU, the stored LTM configuration and rlf report IE information are carried and sent to the source gNB-DU, and then the stored LTM configuration is released. Alternatively, the gNB-CU can reuse the F1APAAMI message to carry the received rlf report information and the stored LTM configuration and send it to the source gNB-DU for analysis and optimization of the LTM configuration and / or LTM trigger strategy. Figure 5c The illustrated embodiment is also applicable. When the gNB-CU determines that the UE has not successfully accessed the target cell, when the UE context is released, an indication IE may be carried in the UE context release command or the UE context modification request message to notify the source gNB-DU to store the LTM configuration related to the mobility of the source cell in the UE context, and release the LTM configuration that is not related to mobility. The carried indication IE may, for example, include an LTM configuration retention indicator, optionally, and carry the cell ID of the source cell (e.g., the source cell CGI). After the gNB-CU analyzes and generates the LTM failure report information or message, it needs to be sent to the source gNB-DU. At this time, the rlf report IE information is carried and sent to the source gNB-DU. The source gNB-DU associates the received LTM failure report information with the stored LTM configuration, and then the source gNB-DU optimizes the LTM configuration and / or LTM trigger strategy. Optionally, the gNB-CU reuses the F1AP AAMI message to carry the received rlf report information and sends it to the source gNB-DU. The source gNB-DU then associates the rlf report information with the stored LTM configuration for analysis and optimization of the LTM configuration and / or LTM triggering strategy.

[0154] The situations where LTM is executed too early include the scenario where RLF occurs immediately after the UE successfully accesses the target cell and then recovers quickly in the source cell, and the scenario where a handover failure occurs without the UE successfully accessing the target cell and then recovers quickly in the source cell. In the above situations where LTM is executed too early, whether the failure cause is analyzed by the gNB-CU, or by the candidate gNB-DU (for RLF occurring immediately after the UE successfully accesses the target cell), or by the source gNB-DU (for handover failure occurring without the UE successfully accessing the target cell), Figure 5a The embodiments shown are still applicable. Figure 5a In the illustrated embodiment, the UE may include the LTM configuration in the rlf report. Figure 5bIn the illustrated embodiment, the gNB-CU stores the LTM configuration in the UE context. When the gNB-CU generates an LTM failure report information or message that needs to be sent to the source gNB-DU, the stored LTM configuration and the rlf report IE information are carried together and sent to the source gNB-DU, and then the stored LTM configuration is released. The source gNB-DU optimizes the LTM configuration and / or LTM triggering strategy based on the received information. Optionally, for the case where the UE successfully accesses the target cell and immediately experiences an rlf, and then quickly recovers in the source cell, the gNB-CU may send the stored LTM configuration, the received LTM failure report information, and the rlf report IE information to the source gNB-DU after receiving the LTM failure report information or message generated by the candidate gNB-DU, and then release the stored LTM configuration. The source gNB-DU optimizes the LTM configuration and / or LTM triggering strategy based on the received information. Optionally, in the case where the UE sends a handover failure without successfully accessing the target cell and then quickly recovers in the source cell, the gNB-CU can reuse the F1AP AAMI message to carry the received RLF report information and the stored LTM configuration to the source gNB-DU for self-analysis and optimization.

[0155] In the case where LTM is executed too late, the UE selects an LTM candidate cell or other cells other than the LTM candidate cell in cell selection to restore the radio link connection. Figure 5a The embodiments shown are still applicable. Figure 5a In the illustrated embodiment, the UE includes the LTM configuration in the rlf report. Figure 5b In the illustrated embodiment, the gNB-CU stores the LTM configuration in the UE context. When the gNB-CU generates LTM failure report information or message that needs to be sent to the source gNB-DU, the stored LTM configuration and rlf report IE information are carried together and sent to the source gNB-DU, and then the stored LTM configuration is released. The source gNB-DU optimizes the LTM configuration and / or LTM triggering strategy based on the received information. Optionally, the gNB-CU can reuse the F1APAAMI message to carry the received rlf report information and the stored LTM configuration and send it to the source gNB-DU for self-analysis and optimization. Figure 5cThe illustrated embodiment is also applicable. When triggering the release of the UE context, the gNB-CU may carry a cell-based indication IE in the message of the UE context release command or the UE context modification request to notify the source gNB-DU to store the LTM configuration related to the mobility of the source cell in the UE context, and release the LTM configuration unrelated to mobility. The carried indication IE may be, for example, an LTM configuration retention indicator, and optionally, a cell ID (e.g., a source cell CGI). After the gNB-CU analyzes and generates the LTM failure report information or message that needs to be sent to the source gNB-DU, it carries the rlf report IE information and sends it to the source gNB-DU. The source gNB-DU associates the received LTM failure report information with the stored LTM configuration, and then the source gNB-DU optimizes the LTM configuration and / or LTM triggering strategy. Optionally, the gNB-CU may reuse the F1AP AAMI message to carry the received rlf report information and send it to the source gNB-DU. Then, the source gNB-DU associates this rlf report information with the stored LTM configuration, and performs self-analysis and optimization.

[0156] The LTM configuration information related to mobility mentioned in the above embodiments may include one or more of the following information:

[0157] -LTM Candidate Cell List: contains each candidate cell ID. The maximum number of candidate cells in the list is maxNrofCellsLTM-r18. Optionally, the LTM candidate cell list can be represented by ltm-CandidateIdList or LTM Configuration ID Mapping List.

[0158] -LTM Candidate Cell ID: It can be represented by NR Cell CGI, which contains the ID information of each LTM candidate cell; optionally, the corresponding LTM candidate cell ID can be represented by LTM-CandidateId or LTM Configuration ID, because there is a corresponding mapping relationship between the three.

[0159] -LTM Source Cell ID: It can be represented by NR Cell CGI; optionally, the corresponding LTM source cell ID can be represented by LTM-CandidateId or LTM Configuration ID, because if the source cell is also used as a candidate cell in the subsequent LTM configuration, there is a corresponding mapping relationship between the three.

[0160] -LTM CSI resource configuration (LTM-CSI-ResourceConfig), corresponding to the configuration information of one or more CSI resources for LTM measurement of one or more LTM candidate cells, is contained in the field ltm-CSI-ResourceConfigToAddModList in the LTM configuration (LTM-Config) IE defined in TS 38.331; optionally, ltm-CSI-ResourceConfigToAddModList can configure multiple LTM CSI resource configurations, and ltm-CSI-ResourceConfigToAddModList can be used to represent all LTM CSI resource configurations.

[0161] -LTM CSI report configuration (LTM-CSI-ReportConfig): Configuration information for measurement reporting corresponding to one or more CSI resources corresponding to LTM measurement (i.e., corresponding to one LTM CSI resource configuration) for one or more LTM candidate cells, contained in the field LTM-CSI-ReportConfigToAddModList in the CSI measurement configuration (CSI-MeasConfig) in the serving cell configuration (ServingCellConfig) in the cell group configuration (CellGroupConfig) IE defined in TS 38.331; Optionally, ltm-CSI-ReportConfigToAddModList can configure multiple LTM CSI report configurations, and ltm-CSI-ReportConfigToAddModList can be used to represent all LTM CSI report configurations.

[0162] The above embodiments described for the intra-gNB-CU inter-gNB-DU LTM process are also applicable to the scenario where LTM failure occurs during the intra-gNB-CU intra-gNB-DU LTM process. Figure 5a to Figure 5cThe described embodiments are still applicable for intra-gNB-CU and intra-gNB-DU LTM procedures.

[0163] against Figure 5a In the embodiment shown, the UE includes the LTM configuration in the rlf report. Figure 5b In the illustrated embodiment, the gNB-CU stores the LTM configuration in the UE context. When the gNB-CU generates LTM failure report information or message that needs to be sent to the source gNB-DU, the stored LTM configuration and rlf report IE information are carried and sent to the source gNB-DU, and then the stored LTM configuration is released. The source gNB-DU optimizes the LTM configuration and / or LTM triggering strategy based on the received information. Optionally, the gNB-CU can reuse the F1AP AAMI message to carry the received rlf report information and the stored LTM configuration and send it to the source gNB-DU for self-analysis and optimization. Figure 5c In the illustrated embodiment, when the gNB-CU triggers the UE context release, it may carry an indication IE in the message that triggers the UE context modification request to notify the source gNB-DU to store the LTM configuration related to the mobility of the source cell in the UE context, and release the LTM configuration that is not related to mobility. The indication IE carried may, for example, include an LTM configuration retention indicator, and optionally, carry the source cell ID (source cell CGI). After the gNB-CU analyzes and generates the LTM failure report information or message that needs to be sent to the source gNB-DU, it carries the rlf report IE information and sends it to the source gNB-DU. The source gNB-DU associates the received LTM failure report information with the stored LTM configuration, and optimizes the LTM configuration and / or LTM triggering strategy. Optionally, the gNB-CU may reuse the F1AP AAMI message to carry the received rlf report information and send it to the source gNB-DU. The source gNB-DU associates the received rlf report information with the stored LTM configuration, and then performs self-analysis and optimization.

[0164] Figure 6a , Figure 6b and Figure 6c This is a flowchart of a storage and transmission scheme for LTM configuration in an LTM process according to an exemplary embodiment of the present disclosure. This embodiment is for the scenario of inter NG-RAN node LTM. For the case where the NG-RAN node is a gNB-CU and gNB-DU separated architecture, inter NG-RAN node is inter-gNB-CU.

[0165] In step 300, the UE successfully accesses the target cell belonging to the candidate NG-RAN node 1. In step 301, the candidate NG-RAN node 1 sends a Handover Success message carrying the target cell ID to the source NG-RAN node. In step 302, the source NG-RAN node sends a SN Status Transfer to the candidate NG-RAN node 1. In step 303, the candidate NG-RAN node 1 performs a path handover procedure with the CN.

[0166] In the case where LTM is executed to the wrong cell, shortly after the UE successfully accesses the target cell belonging to the candidate NG-RAN node 1, a radio link failure occurs in step 304. Then, the UE performs cell selection in step 305, accesses another LTM candidate cell or other cell, and tells the currently selected NG-RAN node that there is an available radio link failure or handover failure message on the UE side through an RRC message such as RRC Reestablishment Complete, RRC Reconfiguration Complete, or RRC Establishment Complete. The carried indication IE is, for example, the rlf information available IE (rlf-InfoAvailable) contained in the UE-MeasurementsAvailable IE.

[0167] As described above, when the UE successfully accesses the target cell, the candidate NG-RAN node 1 sends a handover success message and carries the target cell ID to notify the source NG-RAN node in step 301. The source NG-RAN node transfers the SN state to the candidate NG-RAN node 1 in step 302. After executing the path switching process in step 303, the candidate NG-RAN node 1 sends a UE context release message to the source NG-RAN node in step 306. In response to receiving the UE context release message, the source NG-RAN node releases the UE's LTM configuration for the source cell. For example, in a non-subsequent LTM configuration, the UE accesses the target cell, and after performing an LTM once, the resources of other candidate cells need to be released. Or in a subsequent LTM configuration, if the source cell is not a candidate cell, the resources of the source cell need to be released. In this way, when the source NG-RAN node receives the LTM failure report information (optionally, the reused handover report (Handover Report) message carries the LTM failure report related information), the LTM configuration information may have been released on the source NG-RAN node side. Since the object that needs to be optimized at the source NG-RAN node after obtaining the LTM failure report information is about the LTM configuration, it is undesirable that the LTM configuration information is released. The above-mentioned handover success message, UE context release message and handover report message can be an Xnap message.

[0168] Figure 6a , Figure 6b and Figure 6c They are shown respectively with Figure 5a , Figure 5b and Figure 5c An exemplary embodiment similar to the embodiment of the present invention is used for an inter NG-RAN node LTM scenario.

[0169] Figure 6a An embodiment of storing LTM configuration by UE is shown. Regarding LTM configuration, since the source NG-RAN node has configured the UE through the RRC reconfiguration message during the LTM resource configuration preparation phase, the UE side has these configuration information. Since the UE knows that a radio link failure has occurred, the behavior of the UE can be defined: when an rlf report is generated in the event of a radio link failure, the LTM configuration information is included in the rlf report IE. The NG-RAN node selected by the UE (candidate NG-RAN node 2 or other NG-RAN node) requests the UE to report this information through a UE information request message (carrying an rlf report request IE) in step 307. In response to receiving the UE information request message (carrying an rlf report request IE), the UE reports this information to the NG-RAN node through a UE information response message (carrying an rlf report IE) in step 308. In step 309, the NG-RAN node sends a failure indication (Failure Indication) carrying the rlf report to the candidate NG-RAN node 1. The candidate NG-RAN node 1 can analyze the cause of the failure. If the candidate NG-RAN node 1 is a separate architecture of gNB-CU and gNB-DU, the reference Figure 4a and 4b The described embodiment analyzes the cause of LTM failure by the gNB-CU or gNB-DU. For example, if a candidate gNB-DU is required to perform analysis, the gNB-CU sends the rlf report to the candidate gNB-DU via an AAMI message. After the candidate gNB-DU analyzes, it generates LTM failure report information and sends it to the gNB-CU. The gNB-CU sends the LTM failure report message or information to the source NG-RAN node. For example, the gNB-CU can reuse the switching report message in step 340 to carry the LTM failure report information and the rlf report IE information to the source NG-RAN node. Although the source NG-RAN node releases the UE context, it also obtains the LTM configuration when receiving the LTM failure report, so that the source NG-RAN node can optimize the LTM configuration and / LTM trigger strategy.

[0170] Optimization of LTM configuration and / or LTM triggering strategy for source NG-RAN node, if the source NG-RAN node is a separate architecture of gNB-CU and gNB-DU, combined with Figure 5a , Figure 5b and Figure 5c (or Figure 6a , Figure 6b and Figure 6c ) is also applicable.

[0171] and Figure 5a (or Figure 6a ) is similar to the embodiment shown in FIG. 1 , the gNB-CU sends the LTM failure report information and the rlf report IE information to the source gNB-DU by means of a new LTM failure report message or by reusing the F1AP AAMI message. Then, the source gNB-DU optimizes the LTM configuration and / or the LTM triggering strategy.

[0172] and Figure 5b (or Figure 6b ), after receiving the handover success message from the candidate NG-RAN node 1 in step 301, the source NG-RAN node will stop sending DL data to the UE, and then perform late data forwarding to the candidate NG-RAN node 1, and notify the candidate NG-RAN node 1 of the next allocated packet data convergence protocol sequence number (PDCP SN) and other information through a sequence number status transfer message in step 302. It can be considered to enhance the sequence number status transfer to carry the LTM configuration information, and transmit the LTM configuration information from the source NG-RAN node to the candidate NG-RAN node 1. The candidate NG-RAN node saves the LTM configuration information, and carries the LTM configuration information, LTM failure report information and rlf report IE when sending a handover report message to the source NG-RAN node later. Therefore, although the source NG-RAN node releases the UE context, it also obtains the LTM configuration when receiving the LTM failure report. Then, the source NG-RAN node can optimize the LTM configuration and / LTM triggering strategy. Optionally, if the source NG-RAN node is a gNB-CU and gNB-DU separated architecture, Figure 5b (or Figure 6b) is also applicable. Specifically, the gNB-CU sends the LTM configuration information to the source gNB-DU in step 216. Optionally, the LTM configuration information can be sent from the gNB-CU to the source gNB-DU by means of a new LTM failure report message, or by reusing the F1AP AAMI message to carry the LTM configuration information, the LTM failure report information and the rlf report IE information, or the LTM configuration information can be notified to the source gNB-DU in other ways. The source gNB-DU optimizes the LTM configuration and / or LTM triggering strategy based on the received information.

[0173] and Figure 5c (or Figure 6c ), after the source NG-RAN node receives the switching success message from the candidate NG-RAN node 1 in step 301 and completes the path switching process in step 303, the candidate NG-RAN node 1 sends a UE context release message to the source NG-RAN node in step 306. In response to receiving the UE context release message, the source NG-RAN node releases the UE's LTM configuration regarding the source cell. It may be considered to enhance the UE context release message by carrying an indication IE to notify the source NG-RAN node to store the LTM configuration related to the source node in the UE context. The indication IE carried may, for example, be an LTM configuration retention indicator, and optionally, a cell ID (e.g., source cell CGI). Optionally, if the source NG-RAN node is an architecture in which the gNB-CU and gNB-DU are separated, Figure 5c (or Figure 6c ) is also applicable. When the gNB-CU triggers the release of the context of the source cell to the source gNB-DU. An indication IE can be carried in the message that triggers the UE context release command or the UE context modification request to notify the source gNB-DU to store the LTM configuration related to the source cell in the UE context. The carried indication IE can be, for example, an LTM configuration retention indicator, optionally, and a cell ID (such as the source cell CGI). When the candidate NG-RAN node 1 sends the switching report message in step 340, it carries the LTM failure report information and the rlf report IE information to the source NG-RAN node. After receiving the LTM failure report and the rlf report IE information, the source NG-RAN node associates the saved LTM configuration, and then the source NG-RAN node optimizes the LTM configuration and / or the LTM triggering strategy.

[0174] In another scenario where LTM is executed to the wrong cell, if the UE fails to access the target cell, that is, a handover failure occurs, the UE is aware of this failure, so Figure 5a (or Figure 6a) is applicable, and the UE may include the LTM configuration in the rlf report. In addition, the candidate NG-RAN node 1 is also aware of this failure because the source NG-RAN node, after making the LTM command, notifies the candidate NG-RAN node 1 through, for example, an Xnap message and carries the target cell ID. Therefore, if it is found that the UE has not successfully accessed the corresponding target cell, the candidate NG-RAN node 1 is able to know. Therefore, the source NG-RAN node may be notified through, for example, an Xnap message (e.g., UE context release) or carrying an indication IE to save the LTM configuration related to the source node. The indication IE carried may, for example, be an LTM configuration retention indicator, optionally, and carry a cell ID (e.g., source cell CGI). If the source NG-RAN node is an architecture in which the gNB-CU and gNB-DU are separated, Figure 5b and Figure 5c (or Figure 6b and Figure 6c ) are all applicable. Figure 5c (or Figure 6c ), when the gNB-CU triggers the release of the context of the source cell to the source gNB-DU, a cell-based indication IE may be carried in the message triggering the UE context release command or the UE context modification request to notify the source gNB-DU to store the LTM configuration related to the source cell in the UE context. The carried indication IE may be, for example, an LTM configuration retention indicator, and optionally, a cell ID (e.g., source cell CGI). Figure 5b (or Figure 6b ) In the embodiment shown in FIG. 1 , the LTM configuration is saved by the gNB-CU. Upon receiving a failure indication carrying rlf report information sent by the candidate NG-RAN node 2 or other NG-RAN node, the source NG-RAN node associates the saved LTM configuration. The source NG-RAN node then optimizes the LTM configuration and / or LTM trigger strategy. If the source NG-RAN node is an architecture in which the gNB-CU and gNB-DU are separated, the failure cause can be analyzed by the gNB-CU or gNB-DU. Combined with whether the LTM configuration is saved by the gNB-CU or the gNB-DU. It can be divided into the following four cases:

[0175] Case 1: The gNB-DU saves the LTM configuration and the gNB-CU analyzes the failure reason.

[0176] according to Figure 5cIn the illustrated embodiment, it is assumed that the gNB-CU analyzes the cause of failure, and the generated LTM failure report is sent by the gNB-CU to the source gNB-DU. Optionally, the gNB-CU may send the LTM failure report information to the source gNB-DU by means of a new LTM failure report message, or by reusing the F1AP AAMI message to carry the LTM failure report information and the rlf report IE information, or notify the source gNB-DU of the LTM failure report information by other means. The source gNB-DU associates the received LTM failure report information and rlf report information with the stored LTM configuration, and then the source gNB-DU optimizes the LTM configuration and / or LTM trigger strategy.

[0177] Case 2: The gNB-DU saves the LTM configuration and the gNB-DU analyzes the failure reason.

[0178] Assuming that the source gNB-DU analyzes the cause of the failure, the gNB-CU may send the rlf report IE information to the source gNB-DU. Optionally, the gNB-CU may reuse the F1AP AAMI message to carry the rlf report IE information to send the rlf report IE information to the source gNB-DU, or notify the source gNB-DU of the rlf report IE information in other ways. The source gNB-DU associates the received rlf report information with the stored LTM configuration, and then the source gNB-DU analyzes the cause of the LTM failure and optimizes the LTM configuration and / or LTM triggering strategy.

[0179] Case 3: The gNB-CU saves the LTM configuration and the gNB-CU analyzes the cause of the failure.

[0180] according to Figure 5b In the embodiment shown, it is assumed that the gNB-CU analyzes the cause of failure, and the generated LTM failure report is sent by the gNB-CU to the source gNB-DU. Optionally, the LTM failure report can be sent to the source gNB-DU by means of a new LTM failure report message, or by reusing the F1AP AAMI message to carry the LTM failure report information, the rlf report IE information, and the LTM configuration information, or the LTM failure report can be notified to the source gNB-DU by other means. The source gNB-DU then optimizes the LTM configuration and / or LTM triggering strategy.

[0181] Case 4: gNB-CU saves the LTM configuration and gNB-DU analyzes the failure reason.

[0182] Assuming that the source gNB-DU analyzes the cause of the failure, the gNB-CU can send the rlf report IE information and LTM configuration information to the source gNB-DU. Optionally, the rlf report IE information and LTM configuration information can be sent to the source gNB-DU by reusing the F1AP AAMI message to carry the rlf report IE information and LTM configuration information, or the rlf report IE information and LTM configuration information can be sent to the source gNB-DU by other means to notify the source gNB-DU. The source gNB-DU then analyzes the cause of the LTM failure and optimizes the LTM configuration and / or LTM triggering strategy.

[0183] In another embodiment, in the case where LTM is executed too early, whether it includes an RLF immediately after the UE successfully accesses the target cell and then recovers quickly in the source cell, or a handover failure occurs without the UE successfully accessing the target cell and then recovers quickly in the source cell, the source NG-RAN node knows that the UE has an RLF (radio link failure) or an Hof (handover failure), so the source NG-RAN node can store the LTM configuration itself. Optionally, if the source NG-RAN node is a separate architecture of gNB-CU and gNB-DU, Figure 5b and Figure 5c (or Figure 6b and Figure 6c ) are applicable.

[0184] In the case where an RLF occurs immediately after the UE successfully accesses the target cell and then recovers quickly in the source cell, the source NG-RAN node will collect the RLF report and send it to the candidate NG-RAN node through a failure indication. Then, the candidate NG-RAN node where the RLF occurs will analyze the cause of the LTM failure. If the candidate NG-RAN node is an architecture with separate gNB-CU and gNB-DU, the source NG-RAN node can be combined with the Figure 4a and Figure 4bThe described embodiment analyzes the cause of LTM failure by gNB-CU or gNB-DU. For example, if a candidate gNB-DU is required to perform analysis, gNB-CU sends the candidate gNB-DU with rlf report through AAMI message, and the candidate gNB-DU generates LTM failure report information after analysis, and needs to send the LTM failure report information to gNB-CU. Then gNB-CU sends the LTM failure report message or information to the source NG-RAN node. For example, the handover report message can be reused to carry LTM failure report information and rlf report IE information to the source NG-RAN node. When the source NG-RAN node receives the LTM failure report, it can be associated with the LTM configuration, and then the source NG-RAN node optimizes the LTM configuration and / LTM trigger strategy. If the source NG-RAN node is an architecture in which gNB-CU and gNB-DU are separated, the gNB-CU stores the LTM configuration, and then associates the received LTM failure report information and rlf report IE information with the LTM configuration, and sends it to the gNB-DU for LTM configuration and / LTM trigger strategy optimization. If the LTM configuration is stored by the gNB-DU, the gNB-CU sends the received LTM failure report information and rlf report IE information to the gNB-DU, and then the gNB-DU associates with the LTM configuration to optimize the LTM configuration and / or LTM triggering strategy.

[0185] In the case where the UE fails to successfully access the target cell, i.e., a handover failure occurs and then quickly recovers in the source cell, the source NG-RAN node will collect the rlf report and analyze it by itself and associate it with the LTM configuration. The source NG-RAN node will then optimize the LTM configuration and / or LTM triggering strategy. If the source NG-RAN node is an architecture where the gNB-CU and gNB-DU are separated, the failure cause can be analyzed by the gNB-CU or gNB-DU. Combined with whether the LTM configuration is saved by the gNB-CU or the gNB-DU. The four situations described above still apply.

[0186] In another embodiment, in the case where LTM is executed too late, regardless of whether the UE selects an LTM candidate cell or other cells (non-candidate cells) in the cell selection to restore the radio link connection. The source NG-RAN node knows that the UE has an RLF, so the source NG-RAN node can store the LTM configuration itself. The NG-RAN node that reestablishes the connection access sends the collected RLF report to the source NG-RAN node through a failure indication, and then the source NG-RAN node analyzes the cause of the LTM failure and associates it with the saved LTM configuration. The source NG-RAN node then optimizes the LTM configuration and / or LTM triggering strategy. If the source NG-RAN node is an architecture with separate gNB-CU and gNB-DU, the failure cause can be analyzed by the gNB-CU or gNB-DU. Combined with whether the LTM configuration is saved by the gNB-CU or the gNB-DU. The four situations described above still apply.

[0187] The LTM configuration information related to mobility mentioned in the above embodiments may include one or more of the following information:

[0188] -LTM Candidate Cell List: contains each candidate cell ID. The maximum number of candidate cells in the list is maxNrofCellsLTM-r18. Optionally, it can be represented by ltm-CandidateIdList or LTM Configuration ID Mapping List.

[0189] -LTM Candidate Cell ID: It can be represented by NR Cell CGI, which contains the ID information of each LTM candidate cell; optionally, LTM-CandidateId or LTM Configuration ID can be used to represent the corresponding LTM candidate cell ID, because there is a corresponding mapping relationship between the three.

[0190] -LTM Source Cell ID: It can be represented by NR Cell CGI; optionally, LTM-CandidateId or LTM Configuration ID can be used to represent the corresponding LTM source cell ID, because if the source cell is also used as a candidate cell in the subsequent LTM configuration, there is a corresponding mapping relationship between the three.

[0191] -LTM CSI resource configuration (LTM-CSI-ResourceConfig): Configuration information of one or more CSI resources for LTM measurement corresponding to one or more LTM candidate cells, contained in the field ltm-CSI-ResourceConfigToAddModList in the LTM configuration (LTM-Config) IE defined in TS 38.331; optionally, ltm-CSI-ResourceConfigToAddModList can configure multiple LTM-CSI-ResourceConfigs, and ltm-CSI-ResourceConfigToAddModList can be used to represent all LTM CSI resource configurations.

[0192] -LTM CSI report configuration (LTM-CSI-ReportConfig): Configuration information for measurement reporting of one or more CSI resources corresponding to LTM measurement (i.e., corresponding to one LTM-CSI-ResourceConfig) for one or more LTM candidate cells, included in the field LTM-CSI-ReportConfigToAddModList in the CSI measurement configuration (CSI-MeasConfig) in the serving cell configuration (ServingCellConfig) in the cell group configuration (CellGroupConfig) IE defined in TS 38.331. Optionally, ltm-CSI-ReportConfigToAddModList can configure multiple LTM-CSI-ReportConfigs, and ltm-CSI-ReportConfigToAddModList can be used to represent all LTM CSI report configurations.

[0193] Figure 7 The figure is a schematic diagram of a rach-less access process in an LTM process according to an exemplary embodiment of the present disclosure. When the UE receives a cell switch command (Cell Switch Command) sent by the source gNB-DU, when the cell switch command carries the TA value of the target cell, the UE is instructed to perform a rach-less access process. The rach-less access process includes the following three steps:

[0194] Step #1: Upon receiving a cell handover command, the UE monitors the physical downlink control channel (PDCCH) dynamic scheduling on the target cell.

[0195] Step #2: The target cell senses the arrival of the UE based on receiving the first UL transmission from the UE. The content of the first UL Medium Access Control (MAC) Protocol Data Unit (PDU) / transmission from the UE may be, for example, RRC reconfiguration complete to indicate the arrival of the UE. No new signaling is required to indicate the arrival of the UE.

[0196] Step #3: After the target cell receives the first UL data, the UE determines whether its first UL data is successfully received in the target cell by receiving a PDCCH scheduling addressed by the UE's C-RNTI in a new data transmission.

[0197] When the UE successfully completes the above three steps, it means that the UE has successfully accessed the target cell through the rach-less process.

[0198] The TA value of the target cell is obtained by the UE sending a preamble to the target cell after receiving the PDCCH command from the source gNB-DU. The candidate gNB-DU calculates the TA value and then sends it to the source gNB-DU through the gNB-CU. Figure 3 The validity of the TA value of the target cell is the responsibility of the source gNB-DU. When the LTM cell switching command is triggered, if the source gNB-DU determines that the TA value of the target cell is valid, the TA value is carried in the LTM cell switching command. The UE then performs a rach-less access process on the target cell based on the TA value. However, the source gNB-DU may not accurately determine the validity of the TA, or, after the UE receives the LTM cell switching command, the TA value may become invalid while the UE is monitoring the PDCCH dynamic scheduling on the target cell. In this way, the subsequent rach-less access process will fail. In this case, the UE will initiate normal rach-based access. According to an exemplary embodiment, in order to avoid the UE initiating normal rach-based access after experiencing a rach-less failure, during the rach-less process, when the target cell determines that the TA value of the target cell is invalid, in step #1, the UE can be directly instructed not to continue the rach-less process, but to directly fall back to rach-based access by means of downlink control information (DCI).

[0199] For example, when the target gNB-DU is Figure 3In step 20 of the LTM normal process shown in FIG. 1 , a CU-DU cell switching notification (CU-DU CELL SWITCH NOTIFICATION) is received, and when the TAT timer is detected to have timed out or the TA value of the target cell is invalid during the rach-less process, Figure 7 In the PDCCH dynamic scheduling of step #1 in the LTM rach-less access process shown, an indication (e.g., fallbackToRachAccess) can be carried by DCI (e.g., using 1 bit) to instruct the UE to directly fall back to rach-based access, so as to avoid falling back after the rach-less process fails, so that the UE can successfully access the target cell faster and reduce the delay of service interruption.

[0200] During the LTM switching process, the UE may access the target cell in a rach-based or rach-less access process. Therefore, the failure of the UE to access the target cell may be due to a failure in the rach-based or rach-less access process. According to an exemplary embodiment, in order to distinguish between a radio link failure or a random access (RA) process caused by a failure in a rach-based or rach-less access process, the RA-Report-r16 IE reported by the UE may be enhanced to indicate that the RA process performed by the UE is performed after a failure of the LTM in the rach-less access process. For example, the raPurpose (RA reason) may be specified in the RA-Report-r16 IE as ltmRachlessFailure (indicating that the RA process is due to a rach-less access failure in the LTM process).

[0201] In the three steps of the rach-less access process of LTM described above, from the UE side, a possible failure occurs in step 1 (dynamic grant not received) or step 3 (uplink scheduling of new transmission not received), and the entire rach-less access process fails because the UE does not receive the dynamic grant or the uplink scheduling of the new transmission. Therefore, in an exemplary embodiment, raPurpose may be newly introduced in RA-Report-r16 IE as ltmFailure (LTM failure) or ltmRachlessFailure (LTM rach-less failure) and / or TA invalid. Further, the UE may also enhance the additional detailed information about ltmRachlessFailure reported, for example, dynamic grant not received or uplink scheduling of a new transmission not received, as well as other information about TA invalid indication or TA value (invalid TA value and / or actual TA value), so as to carry out the subsequent LTM rach-less optimization process more targeted and faster.

[0202] In the case of LTM failure in UE, UE will generate rlf report information. If the UE fails in rach-less or rach-based access process, that is, handover failure occurs, when generating rlf report IE, the content of UE report can be enhanced to be for LTM failure. For example, the following one or more information related to LTM failure can also be included in rlf-Report-r16 IE:

[0203] - Source Cell info: includes the cell ID / CGI of the source cell and layer 1 measurement results;

[0204] - Target Cell info: includes the cell ID / CGI of the target cell and layer 1 measurement results;

[0205] -Neighbor Cells info: includes the cell ID / CGI of the neighboring cells and layer 1 measurement results;

[0206] -LTM Candidate Cell info: Information about LTM candidate cells configured by the gNB-CU for the UE, including cell ID / CGI and layer 1 measurement results;

[0207] -LTM Cell ID: The CGI of the LTM candidate cell selected by the UE for fast recovery after rlf or hof;

[0208] - The last handover type is LTM (last HO-Type=ltm), and optionally, it can further indicate that it is a rach-less access failure, or an invalid TA value, or a rach-based access failure;

[0209] - Information on rach-less access failure, such as failure to receive dynamic grant, failure to receive uplink scheduling for new transmission, and / or invalid TA indication or TA value (invalid TA value and / or actual TA value).

[0210] Another embodiment involves the use of the T304 timer. Currently, RAN2 has defined the reuse of the traditional T304 timer for supervising the LTM cell handover access process. It is being studied whether to add a new value to adapt to the rach-less access process. However, a timer can only be configured with one value. The UE may undergo a rach-based access process or a rach-less access process during the LTM cell handover process. The access time of the two processes is obviously different, and the rach-less access time is faster and shorter than the rach-based access time. If the timer value for the rach-less process is configured, but the TA value of the target cell selected when determining the LTM cell handover command is invalid, then the source gNB-DU will not carry the TA value of the target cell in the LTM cell handover command, so that the UE actually undergoes a rach-based access process. As a result, due to the configuration of a short timer value applicable to the rach-less process, the LTM access failure may be prematurely declared due to the expiration of the timer in the actual rach-based access process. Similarly, if a timer value applicable to the rach-based process is configured, and the UE actually accesses rach-less, then when rach-less access fails, it may be necessary to wait for a long time (i.e., timer expiration) before declaring LTM access failure, and then perform cell selection to quickly restore the wireless connection. In either case, the LTM execution process will be adversely affected. To avoid this problem, the present disclosure proposes the following optional solutions.

[0211] According to one embodiment, a new timer is configured for the UE extension, only for the UE rach-less access process. The traditional T304 still monitors the rach-based access process. Both timer values ​​are configured for the UE. The corresponding timer value is applied according to the type of access process actually occurring in the UE.

[0212] According to another embodiment, one type of timer value is configured, and a comparison relationship between a rach-less timer value and a rach-based timer value is defined. For example, a timer value for a rach-less access process is configured for the UE, and then a certain offset time (Delta time) is defined as a timer value used for the rach-based access process; or, a timer value for a rach-based access process is configured for the UE, and then a certain Delta time is defined as a timer value used for the rach-less access process. In this way, a timer applicable to another access process can be indirectly configured for the UE while only one timer value applicable to one access process is provided.

[0213] Figure 8a to Figure 8f It is a flowchart of the LTM process in the NR (New Radio) DC (Dual Connection) scenario according to an exemplary embodiment of the present disclosure. This embodiment is for the scenario of PSCell (Primary Secondary Cell, the main secondary cell in the secondary cell group, called the primary secondary cell) change in the intra SN gNB-CU inter SN gNB-DU LTM process in the NR-DC (NR-NR Dual Connection) environment. Figure 8a The flowchart of the normal LTM process in this scenario is shown. In this scenario, if signaling radio bearer #1 (SRB1) is used, the UE sends a UL information transfer multi-RAT Dual Connectivity (MRDC) message to the main node MN in step 0, and the message includes an NR RRC measurement report. In step 1, the MN sends an RRC transfer message containing a measurement report to the secondary node (SN) gNB-CU; if signaling radio bearer #3 (SRB3) is used, the UE directly sends the NR RRC measurement report to the SN, that is, the UE and the SN can directly exchange NR RRC messages without forwarding them to the SN through the main node (MN). Steps 2 to 26 of the LTM process in this scenario and Figure 3 Steps 2 to 26 in the embodiment correspond to each other and are not described here. In this scenario, if an LTM PSCell change failure occurs, mobility-related optimization is also required. The present disclosure relates to the following types of LTM PSCell change failures:

[0214] -Too Late PSCell LTM Execution. The UE received LTM configuration and a Secondary Cell Group (SCG) failure occurred before the LTM PSCell change was executed. Based on the measurement report from the UE, a suitable PSCell was found that is different from the source PSCell.

[0215] -Too Early PSCell LTM Execution. The LTM PSCell change was not successfully executed, or an SCG (Secondary Cell Group) failure occurred after a successful LTM PSCell change. Based on the measurement report from the UE, the source PSCell is still a suitable PSCell.

[0216] - LTM Execution to wrong PSCell. The LTM PSCell change was not successfully executed, or an SCG failure occurred after a successful LTM PSCell change. Based on the measurement report from the UE, the appropriate PSCell is different from the source PSCell and the target PSCell.

[0217] This situation includes two sub-situations:

[0218] - If the suitable PSCell is one of the candidate target PSCells provided by the node initiating LTM (SN gNB-CU), but is not one of the candidate PSCells selected by the candidate or target gNB-DU, this is a target PSCell selection error at the candidate or target gNB-DU;

[0219] -Otherwise, the candidate PSCell list at the node initiating LTM (SN gNB-CU) is selected incorrectly, and the gNB-CU side needs to optimize the mobility-related LTM configuration and / or LTM triggering strategy; or the source gNB-DU side needs to optimize the mobility-related LTM configuration and / or LTM triggering strategy.

[0220] In the above description, successful LTM execution refers to the UE status, that is, LTM execution is successful when the UE successfully completes the RA process.

[0221] Figure 8b and Figure 8c FIG. 4 shows a flowchart of failure analysis and reporting during the LTM PSCell change process according to an exemplary embodiment of the present disclosure. Figure 8b and Figure 8c, sending LTM PSCell change failure in step 600. In this case, the UE reports SCG failure information (SCG Failure Information) to the MN (master node) in step 601 (using SRB1), and then the MN sends a SCG Failure Information Report message carrying SCG Failure Information (SCG Failure Information) to the source SN in step 602.

[0222] For PSCell change in intra gNB-SN inter gNB-DU LTM procedure, if the suitable PSCell is one of the candidate PSCells provided by the SN gNB-CU during LTM preparation but is not one of the candidate PSCells selected by the target gNB-DU, the MN sends an SCG Failure Information Report message carrying the SCG Failure information from the UE to the source SN gNB-CU. The SN gNB-CU sends an F1AP message carrying the SCG Failure information to the SN gNB-DU to perform the analysis of the LTM PSCell change failure.

[0223] When an LTM PSCell change fails, the UE reports the SCG failure information to the MN (using SRB1), and then the MN sends an SCG failure information report message to the source SN, which carries the SCG failure information from the UE. The UE can directly send the SCG failure information to the SN (using SRB3). Optionally, the SN gNB-CU performs the cause analysis of the LTM PSCell change failure, or the source gNB-DU or the last served candidate gNB-DU performs the cause analysis of the LTM PSCell change failure. Finally, the analyzed LTM failure report information is sent to the source gNB-DU for corresponding optimization.

[0224] In order to analyze and optimize the cause of LTM failure, the SCG failure information message reported by the UE may report one or more of the following information related to the LTM PSCell change failure:

[0225] - Failure Type: It can indicate whether it is LTM failure (indicating that the UE fails to access via rach-based or rach-less), or LTM rach-less failure (indicating that the UE fails to access via rach-less), or LTMrach failure (indicating that the UE fails to access via rach-based);

[0226] - Source PSCell information: including the cell ID / CGI of the source PSCell and the layer 1 measurement result (L1 Measurement Result);

[0227] - Target PSCell information: including the cell ID / CGI of the target PSCell and layer 1 measurement results;

[0228] -Neighbor PSCells info: includes the cell ID / CGI of the neighboring PSCell and layer 1 measurement results;

[0229] -LTM Candidate PSCell List: information about the LTM candidate PSCells configured by the SN gNB-CU for the UE, including cell ID / CGI and layer 1 measurement results;

[0230] -LTM PSCell ID (ltm PSCell Id): CGI of the LTM candidate suitable PSCell selected based on measurements reported by the UE after rlf or hof;

[0231] - Information on rach-less access failure, such as failure to receive dynamic grant, failure to receive uplink scheduling for new transmission, and / or invalid TA indication or TA value (invalid TA value and / or actual TA value).

[0232] In order to analyze and optimize the causes of LTM failure, Figure 4a and Figure 4b The analysis and optimization mechanism of the LTM failure cause described in the embodiment of the present invention, as well as the enhancement of the F1 interface, are also applicable in this embodiment. When the SNgNB-CU receives the UE report through the MN (in the case of using SRB1), or directly receives the UE report (in the case of using SRB3) carrying this information about the SCG failure, the SN gNB-CU or SN gNB-DU can be selected to analyze the cause of the LTM PSCell change failure.

[0233] For example, see Figure 8bIn the illustrated embodiment, the SN gNB-CU analyzes the cause of the LTM PSCell change failure. Using the information related to the LTM PSCell change failure contained in the SCG failure information reported by the UE, the SN gNB-CU analyzes the cause of the failure and generates LTM PSCell failure report information in step 610. Then, the SN gNB-CU sends the LTM PSCell failure report information to the source gNB-DU in step 603. Optionally, a new LTM PSCell failure report message may be sent to the source gNB-DU, or the F1AP AAMI message may be reused to carry the LTM PSCell failure report information and the SCG failure information, or the gNB-CU may notify the source gNB-DU of the LTM PSCell failure report information in other ways. The source gNB-DU receives this information to optimize the LTM configuration and / or LTM trigger strategy.

[0234] For example, see Figure 8cIn the illustrated embodiment, the SN gNB-DU (source SN gNB-DU or target SN gNB-DU) analyzes the cause of the failure of the LTM PSCell change. After receiving the SCG failure information reported by the UE from the MN, the SN gNB-CU reuses the F1AP AAMI message in step 604 to carry the SCG failure information, and optionally, carries the UE assistant identifier (AssistantIdentifier) ​​information (such as gNB-DU UE F1AP ID), and sends this information to the source SN gNB-DU or the target SN gNB-DU, and the source SN gNB-DU performs failure cause analysis and optimization in step 621, or the target gNB-DU performs failure cause analysis in step 620, and generates LTM PSCell failure report information. Depending on the LTM failure scenario, the SN gNB-CU will collect the SCG failure information and send it to the source gNB-DU or the candidate gNB-DU for analysis. For example, in the case where the PSCell LTM is executed too late, the gNB-CU sends the SCG failure information to the source gNB-DU for analysis and optimizes the LTM configuration and / LTM triggering strategy. In the case where the PSCell LTM is executed too early or the LTM is executed to the wrong PSCell and the UE fails during the switching process, the gNB-CU optionally sends the SCG failure information to the source gNB-DU for analysis and optimizes the LTM configuration and / LTM triggering strategy. For example, through enhancement, the gNB-CU can send the SCG failure information to the gNB-DU through a new F1AP message or by using an existing F1AP AAMI message. In the case where the PSCell LTM is executed too early or the LTM is executed to the wrong PSCell and then the UE successfully accesses the target cell and then RLF occurs, the gNB-CU optionally sends the SCG failure information to the candidate gNB-DU for analysis. The candidate gNB-DU is the gNB-DU where the target PSCell is located. The radio link failure occurs immediately after the UE successfully accesses the target PSCell. Figure 8c In the embodiment of the present invention, the gNB-CU may send the SCG failure information to the candidate gNB-DU via an AAMI message in step 604. The candidate gNB-DU sends the LTM PSCell failure report information generated by the analysis to the gNB-CU in step 605, and then the gNB-CU sends the LTM PSCell failure report information to the source gNB-DU in step 606. The source gNB-DU optimizes the LTM configuration and / or LTM triggering strategy based on the received information.

[0235] In the above process, the LTM PSCell failure report message or information generated by the gNB-CU, or the LTM PSCell failure report message or information generated by the candidate gNB-DU analysis, sent to the gNB-CU and then forwarded by the gNB-CU to the source gNB-DU, may include one or more of the following information:

[0236] -LTM report type: indicates the failure type, which is PSCell LTM execution too early or PSCell LTM execution too late or LTM execution to the wrong PSCell or ping-pong PSCell LTM execution, where the ping-pong PSCell LTM execution type can be determined by the gNB-CU based on the VisitedCellInfoList IE in the MobilityHistoryReport IE reported by the UE, or based on the source cell and target cell where the UE resides through LTM and the residence time known by the gNB-CU.

[0237] - Source PSCell CGI: CGI of the source PSCell for the LTM procedure in the source gNB-DU.

[0238] - Target PSCell CGI: CGI of the target PSCell for the LTM process in the candidate gNB-DU.

[0239] - Suitable PSCell CGI: The CGI of a suitable LTM candidate PSCell obtained based on the measurements reported by the UE after rlf or hof. This information is included when the LTM report type is LTM to Wrong PSCell.

[0240] - Source PSCell C-RNTI: The Cell Radio Network Temporary Identity allocated at the source gNB-DU. The C-RNTI used in the source PSCell after a handover failure or radio link failure enables the source gNB-DU to query the saved UE context to match the corresponding LTM PSCell failure report.

[0241] -Target PSCell C-RNTI: The Cell Radio Network Temporary Identity allocated at the target gNB-DU, the C-RNTI used in the target cell after a radio link failure or handover failure is detected.

[0242] -Last Serving PSCell C-RNTI: The C-RNTI assigned at the last serving gNB-DU. It is the C-RNTI used in the last serving cell after detecting a radio link failure or handover failure. The gNB-DU that receives the SCG failure information can determine whether the SCG failure information occurred on this gNB-DU through this information without decoding the content of the SCG failure information.

[0243] -SCG Failure Report Container: SCG Failure Information message defined in TS 38.331.

[0244] -TA invalid indication: indicates that the rach-less access failure occurred due to TA invalidity. Optionally, the TA invalidity conclusion can be drawn by comparing the TA value received from the source gNB-DU (carried in the cell handover command) reported by the UE and the actual TA value (rach-based access is performed after rach-less failure).

[0245] After receiving this information, the source gNB-DU optimizes the LTM configuration and / or LTM triggering strategy based on the received information.

[0246] In order to analyze and optimize the cause of LTM failure, the source gNB-DU needs to optimize the LTM configuration and / or LTM triggering strategy related to LTM mobility. However, in some LTM failure scenarios, these LTM mobility-related parameter configurations may have been released along with the UE context. Figures 5a to 5c The described embodiments are also applicable. Figure 8d , Figure 8e and Figure 8f The embodiments shown are respectively Figure 5a , Figure 5b and Figure 5c The embodiments shown are similar.

[0247] Figure 8dAn embodiment of storing LTM configuration by UE is shown. Regarding LTM configuration, since the SN gNB-CU has configured the UE through the RRC reconfiguration message during the LTM resource configuration preparation phase, the UE side has these configuration information. Since the UE knows that a radio link failure has occurred, the behavior of the UE can be defined: when an LTM PSCell change failure or RLF generates SCG failure information, the LTM configuration information is included in the SCG failure information message. In step 601, the UE sends an SCG failure information message containing the LTM configuration information to the MN. In step 602, the MN that receives the SCG failure information message sends an SCG failure information report message containing the SCG failure information to the SN gNB-CU. In step 607, the SN gNB-CU or the candidate gNB-DU analyzes the cause of the LTM PSCell change failure. When the SN gNB-CU generates an LTM PSCell failure report message or information, or receives an LTM PSCell failure report message or information generated by the candidate gNB-DU analysis, the SN gNB-CU sends the LTM PSCell failure report message or information carrying the SCG failure information (carrying the LTM configuration) to the source gNB-DU in step 608. Then, the source gNB-DU optimizes the LTM configuration and / or the LTM triggering strategy.

[0248] Figure 8e An embodiment of storing LTM configuration by SN gNB-CU is shown. SN gNB-CU is aware of the RLF situation that occurs immediately after the UE successfully accesses the target PSCell, or other access failures occur during the LTM PSCell change process, or other LTM PSCell change failures, and the behavior of SN gNB-CU can be defined: when the SN gNB-CU receives the access success message of the candidate gNB-DU, the SN gNB-CU stores the LTM configuration related to mobility of the source PSCell, and releases the LTM configuration unrelated to mobility, and normally triggers the release process of the context of the source cell to the source gNB-DU. After the SNgNB-CU obtains the SCG failure information, in step 607, the gNB-CU or gNB-DU optionally analyzes the cause of the LTM failure. The specific process is based on Figure 4a and Figure 4bEmbodiment. When the SN gNB-CU generates an LTM PSCell failure report message or information, or receives an LTM PSCell failure report message or information generated by the candidate gNB-DU analysis, it needs to be sent to the source gNB-DU. At this time, the SN gNB-CU carries the stored LTM configuration information and SCG failure information and sends them to the source gNB-DU in step 608, and then the source gNB-DU optimizes the LTM configuration and / LTM trigger strategy.

[0249] Figure 8f An embodiment of storing LTM configuration by the source gNB-DU is shown. The SN gNB-CU is aware of the RLF situation that occurs immediately after the UE successfully accesses the target PSCell, or other access failures occur during the LTM PSCell change process, or other LTM PSCell change failures. When the gNB-CU receives the access success message of the candidate gNB-DU, it can trigger the UE context release command or UE context modification request process to the source gNB-DU in step 609 to release the UE's LTM configuration. In the message that triggers the UE context release command or UE context modification request, an indication IE can be carried to notify the source gNB-DU to store the LTM configuration related to the mobility of the source cell in the UE context, and release the LTM configuration that is not related to mobility. The carried indication IE can be, for example, an LTM configuration retention indicator, and optionally, a cell ID (such as the source cell CGI). After the SN gNB-CU obtains the SCG failure information, the gNB-CU or gNB-DU can optionally analyze the cause of the LTM PSCell failure. The specific process is based on Figure 4a and Figure 4b When the SN gNB-CU generates an LTM PSCell failure report message or information, or receives an LTM PSCell failure report message or information generated by the candidate gNB-DU analysis, it needs to be sent to the source gNB-DU in step 608. The source gNB-DU associates the received LTM PSCell failure report information with the stored LTM configuration, and then the source gNB-DU optimizes the LTM configuration and / or LTM triggering strategy.

[0250] The LTM configuration information related to mobility mentioned in the above embodiments and solutions may include one or more of the following information:

[0251] -LTM Candidate PSCell List: contains each candidate PSCell ID. The maximum number of candidate PSCells in the list is maxNrofPSCellsLTM; optionally, it can be represented by ltm-CandidateIdList or LTM Configuration ID Mapping List.

[0252] -LTM Candidate PSCell ID: can be represented by NR Cell CGI, including the ID information of each LTM candidate PSCell; optionally, LTM-CandidateId or LTM ConfigurationID can be used to represent the corresponding LTM candidate PSCell ID, because there is a corresponding mapping relationship between the three.

[0253] -LTM Source PSCell ID: It can be represented by NR Cell CGI; optionally, LTM-CandidateId or LTM Configuration ID can be used to represent the corresponding LTM source primary and secondary cell ID, because if the source secondary cell is also used as a candidate cell in the subsequent LTM configuration, there is a corresponding mapping relationship between the three.

[0254] -LTM CSI resource configuration (LTM-CSI-ResourceConfig): Configuration information of one or more CSI resources for LTM measurement corresponding to one or more LTM candidate PSCells, contained in the field ltm-CSI-ResourceConfigToAddModList in the LTM configuration (LTM-Config) IE defined in TS 38.331; optionally, ltm-CSI-ResourceConfigToAddModList can configure multiple LTM-CSI-ResourceConfigs, and ltm-CSI-ResourceConfigToAddModList can be used to represent all LTM CSI resource configurations.

[0255] -LTM CSI report configuration (LTM-CSI-ReportConfig): Configuration information for measurement reporting of one or more CSI resources corresponding to LTM measurement (i.e., corresponding to one LTM-CSI-ResourceConfig) for one or more LTM candidate PSCells, included in the field LTM-CSI-ReportConfigToAddModList in the CSI measurement configuration (CSI-MeasConfig) in the serving cell configuration (ServingCellConfig) in the cell group configuration (CellGroupConfig) IE defined in TS 38.331. Optionally, ltm-CSI-ReportConfigToAddModList can configure multiple LTM-CSI-ReportConfigs, and ltm-CSI-ReportConfigToAddModList can be used to represent all LTM CSI report configurations.

[0256] Fig. 9 A method 900 performed by a first node according to an exemplary embodiment of the present disclosure is shown. In step 901, the first node receives a first message including LTM failure report information related to the UE, wherein the LTM failure report information is generated based on the RLF report information of the UE. In step 902, the first node updates the LTM configuration and / or triggering policy related to the mobility of the UE based on the LTM failure report information. According to the method 900 performed by the first node, the first node may update (or optimize) the LTM configuration and / or triggering policy related to the mobility of the UE based on the LTM failure report information related to the LTM failure of the UE, thereby avoiding similar failures in subsequent LTM mobility processes.

[0257] In an exemplary embodiment, the first node may be, for example, an intra-gNB-CU inter-gNB-DU LTM scenario (e.g., Figures 4a-5c ), intra-gNB-CU intra-gNB-DU LTM scenario or intra SN gNB-CU inter SN gNB-DU LTM scenario in NR-DC environment (for example, Figures 8a-8f ) in the source gNB-DU. The LTM failure report information may include at least one of the following associated with the UE: LTM failure type, cell global identifier CGI of the source cell, target cell CGI, reestablished cell CGI, restored cell CGI, cell radio network temporary identifier C-RNTI of the source cell, target cell C-RNTI, previous serving cell C-RNTI, UE RLF report container, and TA invalid indication.

[0258] In an exemplary embodiment, the first node may be an inter NG-RAN node LTM scenario (e.g., Figure 6a-6c ) in the source NG-RAN node. The LTM failure report information may be associated with the secondary cell group SCG failure and include at least one of the following associated with the UE: LTM failure type, source primary and secondary cell PSCell CGI, target PSCell CGI, suitable PSCell CGI, source PSCell C-RNTI, target PSCell C-RNTI, previous serving PSCell C-RNTI, SCG failure report container, and TA invalid indication.

[0259] In an exemplary embodiment, according to different scenarios, the first message may be an LTM failure report message, an LTMPS Cell failure report message, an access and mobility indication AAMI message, or an Xn application protocol Xnap switching report message.

[0260] In an exemplary embodiment, the LTM failure report information may further include an LTM configuration related to the mobility of the UE, and the LTM configuration includes at least one of the following: an LTM candidate cell list, an LTM candidate cell ID, an LTM channel state information CSI resource configuration, and an LTM CSI report configuration. In this case, even if the first node has released the UE context, the LTM configuration information can be obtained when the LTM failure report information is received, thereby optimizing the LTM configuration and / or LTM triggering strategy.

[0261] In an exemplary embodiment, the method performed by the first node also includes: receiving a second message related to the UE context release, wherein the second message includes an LTM configuration retention indicator; and releasing the LTM configuration that is not related to the mobility of the UE according to the second message, and retaining the LTM configuration related to the mobility of the UE. The LTM configuration related to the mobility of the UE may, for example, include at least one of the following: an LTM candidate cell list, an LTM candidate cell ID, an LTM CSI resource configuration, and an LTM CSI report configuration. In this case, the first node retains the LTM configuration information related to the mobility of the UE when releasing the UE context, thereby enabling optimization of the LTM configuration and / or LTM triggering strategy. Depending on different scenarios, the second message may, for example, be an F1AP UE context release command message, a UE context modification request message, or an Xnap UE context release message.

[0262] In an exemplary embodiment, for the inter NG-RAN node LTM scenario, the method performed by the first node may further include: sending a message including an LTM configuration related to the mobility of the UE, wherein the first message received by the first node may include the previously sent LTM configuration. For example, the LTM configuration includes at least one of the following: an LTM candidate cell list, an LTM candidate cell ID, an LTM CSI resource configuration, and an LTM CSI report configuration.

[0263] Fig.10 A method 1000 performed by a UE according to an exemplary embodiment of the present disclosure is shown. In step 1001, the UE sends a message including RLF report information, wherein the RLF report information is used to generate LTM failure report information related to the mobility of the UE. In step 1002, an LTM process is performed based on the LTM configuration updated using the LTM failure report information.

[0264] In an exemplary embodiment, the RLF report information may include LTM configuration related to the mobility of the UE. Specifically, the LTM configuration may include at least one of the following: LTM candidate cell list, LTM candidate cell ID, LTM channel state information CSI resource configuration, LTM CSI report configuration.

[0265] In an exemplary embodiment, the RLF report information may include information related to the LTM failure. Specifically, the information related to the LTM failure may include at least one of the following: source cell information, target cell information, neighboring cell information, LTM candidate cell information, LTM cell information, last switching type information, information indicating rach-based access failure based on random access channel or rach-less access failure without random access channel, and information about rach-less access failure. Alternatively, in the intra SN gNB-CU inter SN gNB-DU LTM scenario under the NR-DC environment, the information related to the LTM failure is associated with the secondary cell group SCG failure and includes at least one of the following: LTM failure type, source primary and secondary cell PSCell information, target PSCell information, neighboring PSCell information, LTM candidate PSCell list, LTM PSCell identifier, information indicating rach-based access failure or rach-less access failure, and information about rach-less access failure. Specifically, at least one of the above-mentioned source cell information, target cell information, neighboring cell information, LTM candidate cell information, LTM cell information, source PSCell information, target PSCell information, and neighboring PSCell information may, for example, include the cell CGI and L1 measurement results of the corresponding cell.

[0266] In an exemplary embodiment, the LTM failure report information includes an LTM configuration related to the mobility of the UE, wherein the LTM configuration includes at least one of the following: an LTM candidate cell list, an LTM candidate cell ID, an LTM CSI resource configuration, and an LTM CSI report configuration.

[0267] In an exemplary embodiment, the LTM failure report information includes at least one of the following associated with the UE: LTM failure type, source cell global identifier CGI, target cell CGI, reestablished cell CGI, restored cell CGI, source cell radio network temporary identifier C-RNTI, target cell C-RNTI, last serving cell C-RNTI, UE RLF report container, TA invalid indication. Alternatively, in the intra SN gNB-CU inter SN gNB-DU LTM scenario under the NR-DC environment, the LTM failure report information is associated with the secondary cell group SCG failure, and includes at least one of the following associated with the UE: LTM failure type, source primary and secondary cell PSCell CGI, target PSCell CGI, appropriate PSCell CGI, source PSCell C-RNTI, target PSCell C-RNTI, last serving PSCell C-RNTI, SCG Failure report container, TA invalid indication.

[0268] In an exemplary embodiment, information about rach-less access failure includes at least one of the following: information related to non-receipt of dynamic authorization, information related to non-receipt of uplink scheduling of new transmission, and information related to invalid TA value and / or actual TA value. In an exemplary embodiment, the method performed by the UE also includes: during the rach-less access process, receiving an indication to fall back to rach-based access; and in response to the received indication, ending the rach-less access and performing rach-based access. Optionally, the rach-less access failure is determined based on a timer value configured for rach-less access, or based on a timer value configured for rach-based access and an offset value configured for rach-less access.

[0269] Fig.11 A method 1100 performed by a second node according to an exemplary embodiment of the present disclosure is shown. In step 1101, the second node generates LTM failure report information according to RLF report information of the UE. In step 1102, the second node sends a first message including the LTM failure report information. The LTM failure report information is used to update the LTM configuration and / or triggering policy related to the mobility of the UE.

[0270] In an exemplary embodiment, the first node may be, for example, an intra-gNB-CU inter-gNB-DU LTM scenario (e.g., Figures 4a-5c ), intra-gNB-CU intra-gNB-DU LTM scenario or intra SN gNB-CU inter SN gNB-DU LTM scenario in NR-DC environment (for example, Figures 8a-8f ) in the gNB-CU or candidate gNB-DU. The LTM failure report information may include at least one of the following associated with the UE: LTM failure type, cell global identifier CGI of the source cell, target cell CGI, reestablished cell CGI, restored cell CGI, cell radio network temporary identifier C-RNTI of the source cell, target cell C-RNTI, previous serving cell C-RNTI, UE RLF report container, TA invalid indication.

[0271] In an exemplary embodiment, the second node may be an inter NG-RAN node LTM scenario (e.g., Figure 6a-6c ) in the candidate NG-RAN node. The LTM failure report information may be associated with the secondary cell group SCG failure and include at least one of the following associated with the UE: LTM failure type, source primary and secondary cell PSCell CGI, target PSCell CGI, suitable PSCell CGI, source PSCell C-RNTI, target PSCell C-RNTI, previous serving PSCell C-RNTI, SCG failure report container, and TA invalid indication.

[0272] In an exemplary embodiment, according to different scenarios, the first message may be an LTM failure report message, an LTMPSCell failure report message, an access and mobility indication AAMI message, an Xn application protocol Xnap switching report message, or an Xnap failure indication message.

[0273] In an exemplary embodiment, a gNB-CU as a second node receives a message including RLF report information from a UE, the RLF report information including at least one of an LTM configuration related to the mobility of the UE and information related to an LTM failure. Exemplarily, the LTM configuration includes at least one of: an LTM candidate cell list, an LTM candidate cell ID, an LTM channel state information CSI resource configuration, and an LTM CSI report configuration. Exemplarily, the information related to the LTM failure includes at least one of: source cell information, target cell information, neighboring cell information, LTM candidate cell information, LTM cell information, last handover type information, information indicating a rach-based access failure based on a random access channel or a rach-less access failure without a random access channel, and information about a rach-less access failure. Alternatively, exemplarily, the information related to the LTM failure is associated with the failure of the secondary cell group SCG, and includes at least one of the following: LTM failure type, source primary and secondary cell PSCell information, target PSCell information, adjacent PSCell information, LTM candidate PSCell list, LTM PSCell identifier, information indicating rach-based access failure or rach-less access failure, information about rach-less access failure. The information about rach-less access failure may include at least one of the following: information related to non-receipt of dynamic authorization, information related to non-receipt of uplink scheduling of new transmission, and information related to invalid TA value and / or actual TA value.

[0274] In an exemplary embodiment, the LTM failure report information includes an LTM configuration related to the mobility of the UE, and the LTM configuration includes at least one of the following: an LTM candidate cell list, an LTM candidate cell ID, an LTM CSI resource configuration, and an LTM CSI report configuration.

[0275] In an exemplary embodiment, the second node may also send a second message related to the UE context release to the first node, wherein the second message includes an LTM configuration retention indicator. Exemplarily, the LTM configuration retention indicator is used to indicate that the first node retains the LTM configuration related to the mobility of the UE while releasing the LTM configuration that is not related to the mobility of the UE. The LTM configuration related to the mobility of the UE, for example, includes at least one of the following: an LTM candidate cell list, an LTM candidate cell ID, an LTM CSI resource configuration, and an LTM CSI report configuration. In an exemplary embodiment, the second message may be an F1 application protocol F1 AP UE context release command message, a UE context modification request message, or an Xnap UE context release message.

[0276] In an exemplary embodiment, the second node may also receive and store a message of LTM configuration related to the mobility of the UE, wherein the LTM configuration includes at least one of the following: an LTM candidate cell list, an LTM candidate cell ID, an LTM CSI resource configuration, an LTM CSI report configuration, and wherein the previously received and stored LTM configuration is included in the first message sent. The message of LTM configuration related to the mobility of the UE is, for example, a sequence number SN status transfer message.

[0277] In an exemplary embodiment, the candidate gNB-DU as the second node may determine that the UE is about to fail in rach-less access; and send an indication to the UE to fall back to rach-based access. For example, based on the determination that the UE is about to fail in rach-less access based on the invalid TA value of the target cell configured for rach-less access or the expiration of the TAT timer, the second node determines that the UE is about to fail in rach-less access, and sends an indication to the UE to fall back to rach-based access.

[0278] The above describes the method executed by each node according to the embodiment of the present disclosure. It should be understood that each node executing the corresponding method is also included in the scope of the present disclosure.

[0279] Fig.12 An exemplary structure of each node applicable to the present disclosure is shown. The exemplary node shown in Figure 8 includes a transceiver 1210 and a processor 1220 coupled to the transceiver 1210. The transceiver 1210 is configured to send and receive signals. The processor 1220 is configured to execute the method described in the present disclosure. The present disclosure can also be implemented as a computer storage medium. The computer storage medium stores computer executable instructions, and when the stored computer executable instructions are executed by the processor, the processor executes the method described in the present disclosure.

[0280] The various illustrative logical blocks, modules, and circuits described in the present disclosure may be implemented or executed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in an alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors cooperating with a DSP core, or any other such configuration.

[0281] The steps of the method or algorithm described in the present disclosure can be directly embodied in hardware, in a software module executed by a processor, or in a combination of the two. The software module can reside in a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor so that the processor can read and write information from / to the storage medium. In an alternative, a storage medium can be integrated into a processor. The processor and the storage medium can reside in an ASIC. The ASIC can reside in a user equipment terminal. In an alternative, the processor and the storage medium can reside in a user equipment terminal as discrete components.

[0282] In one or more exemplary designs, the functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable media include both computer storage media and communication media, the latter including any media that facilitates the transfer of a computer program from one place to another. Storage media may be any available media that can be accessed by a general or special purpose computer.

[0283] The description set forth herein, in conjunction with the accompanying drawings, describes example methods and apparatus and does not represent all examples that may be implemented or within the scope of the claims. The term "example" as used herein means "used as an example, instance, or illustration," rather than "preferred" or "superior to other examples." The detailed description includes specific details for the purpose of providing an understanding of the described techniques. However, these techniques may be practiced without these specific details. In some cases, well-known structures and devices are shown in block diagram form to avoid obscuring the concepts of the described examples.

[0284] Although this specification contains a number of specific implementation details, these should not be interpreted as limitations on any invention or the scope of the claimed protection, but rather as descriptions of specific features of specific embodiments of specific inventions. Certain features described in this specification in the context of separate embodiments may also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination. In addition, although features may be described above as working in certain combinations, and even initially claimed as such, in some cases, one or more features from the claimed combination may be deleted from the combination, and the claimed combination may be directed to a sub-combination or a variation of the sub-combination.

[0285] It should be understood that the specific order or hierarchy of steps in the method of the present disclosure is an illustration of an exemplary process. Based on design preferences, it is understood that the specific order or hierarchy of steps in the method can be rearranged to achieve the functions and effects disclosed in the present disclosure. The attached method claims present the elements of various steps in an example order, and are not meant to be limited to the specific order or hierarchy presented, unless otherwise specifically stated. In addition, although elements can be described or claimed in singular form, the plural number is also contemplated unless a limitation to the singular is explicitly stated. Therefore, the present disclosure is not limited to the examples shown, and any device for performing the functions described herein is included in the various aspects of the present disclosure.

[0286] It can be understood that “at least one of / at least one” described in the present disclosure includes any and / or all possible combinations of the listed items, the various embodiments described in the present disclosure and the various examples in the embodiments can be changed and combined in any appropriate form, and the “ / ” described in the present disclosure means “and / or”.

[0287] The text and drawings are provided as examples only to help readers understand the present disclosure. They are not intended and should not be interpreted as limiting the scope of the present disclosure in any way. Although certain embodiments and examples have been provided, it is obvious to those skilled in the art based on what is disclosed herein that the embodiments and examples shown may be changed without departing from the scope of the present disclosure.

Claims

1. A method performed by a first node in a wireless communication system, include: receiving a first message including low layer triggered mobility LTM failure report information related to a user equipment UE; as well as The LTM configuration and / or triggering policy related to the mobility of the UE is updated based on the LTM failure report information and the LTM configuration related to the mobility of the UE.

2. The method according to claim 1, in, The LTM failure report information includes at least one of the following associated with the UE: LTM failure type, cell global identifier CGI of the source cell, target cell CGI, reestablished cell CGI, restored cell CGI, cell radio network temporary identifier C-RNTI of the source cell, target cell C-RNTI, previous serving cell C-RNTI, UE radio link failure RLF report container, TA invalid indication; or The LTM failure report information is associated with the failure of the secondary cell group SCG, and includes at least one of the following associated with the UE: LTM failure type, source primary and secondary cell PSCell CGI, target PSCell CGI, suitable PSCell CGI, source PSCellC-RNTI, target PSCellC-RNTI, previous service PSCellC-RNTI, SCG failure report container, and TA invalid indication.

3. The method according to claim 1, in, The first message is an LTM failure report message, an LTM PSCell failure report message, an access and mobility indication AAMI message, or an Xn application protocol Xnap switching report message.

4. The method according to claim 1, in, The LTM configuration related to the mobility of the UE is included in the LTM failure report information, and the LTM configuration includes at least one of the following: LTM candidate cell list, LTM candidate cell ID, LTM source cell ID, LTM channel state information CSI resource configuration, and LTM CSI report configuration.

5. The method according to claim 1, further comprising: include: receiving a second message related to UE context release, the second message comprising an LTM configuration retention indicator; as well as According to the second message, releasing the LTM configuration irrelevant to the mobility of the UE, and retaining the LTM configuration related to the mobility of the UE, The LTM configuration related to the mobility of the UE includes at least one of the following: an LTM candidate cell list, an LTM candidate cell ID, an LTM source cell ID, an LTM CSI resource configuration, and an LTM CSI report configuration.

6. The method according to claim 5, in, The second message is an F1 application protocol F1AP UE context release command message, a UE context modification request message, or an Xnap UE context release message.

7. The method according to claim 1, further comprising: include: Sending a message including an LTM configuration related to the mobility of the UE, wherein the LTM configuration includes at least one of the following: an LTM candidate cell list, an LTM candidate cell ID, an LTM source cell ID, an LTM CSI resource configuration, and an LTM CSI report configuration, The received first message includes the LTM configuration sent previously.

8. A method performed by a user equipment UE in a wireless communication system, include: Sending a message including radio link failure RLF report information, where the RLF report information is used to generate low layer triggered mobility LTM failure report information related to the mobility of the UE; as well as An LTM process is performed based on an LTM configuration updated using the LTM failure report information and an LTM configuration related to the mobility of the UE.

9. The method according to claim 8, in, The RLF report information includes at least one of LTM configuration related to the mobility of the UE and information related to LTM failure, The LTM configuration includes at least one of the following: an LTM candidate cell list, an LTM candidate cell ID, an LTM source cell ID, an LTM channel state information CSI resource configuration, and an LTM CSI report configuration. The information related to the LTM failure includes at least one of the following: source cell information, target cell information, neighboring cell information, LTM candidate cell information, LTM cell information, last handover type information, information indicating a rach-based access failure or a rach-less access failure without a random access channel, information about a rach-less access failure, or Among them, the information related to LTM failure is associated with the failure of the secondary cell group SCG, and includes at least one of the following: LTM failure type, source main and secondary cell PSCell information, target PSCell information, adjacent PSCell information, LTM candidate PSCell list, LTM PSCell identifier, information indicating rach-based access failure or rach-less access failure, and information about rach-less access failure.

10. The method according to claim 8, in, LTM configuration related to the mobility of the UE is included in the LTM failure report information, and The LTM configuration includes at least one of the following: an LTM candidate cell list, an LTM candidate cell ID, an LTM source cell ID, an LTM CSI resource configuration, and an LTM CSI report configuration.

11. A method performed by a second node in a wireless communication system, include: Generate low-layer triggered mobility LTM failure report information according to radio link failure RLF report information of user equipment UE; as well as sending a first message including the LTM failure report information, The LTM failure report information and the LTM configuration related to the mobility of the UE are used to update the LTM configuration and / or triggering policy related to the mobility of the UE.

12. The method according to claim 11, further comprising: include: receiving a message including the RLF report information from the UE, the RLF report information including at least one of an LTM configuration related to mobility of the UE and information related to an LTM failure, The LTM configuration includes at least one of the following: an LTM candidate cell list, an LTM candidate cell ID, an LTM source cell ID, an LTM channel state information CSI resource configuration, and an LTM CSI report configuration. The information related to the LTM failure includes at least one of the following: source cell information, target cell information, neighboring cell information, LTM candidate cell information, LTM cell information, last handover type information, information indicating a rach-based access failure or a rach-less access failure without a random access channel, information about a rach-less access failure, or Among them, the information related to LTM failure is associated with the failure of the secondary cell group SCG, and includes at least one of the following: LTM failure type, source main and secondary cell PSCell information, target PSCell information, adjacent PSCell information, LTM candidate PSCell list, LTM PSCell identifier, information indicating rach-based access failure or rach-less access failure, and information about rach-less access failure.

13. The method according to claim 11, in, The LTM failure report information includes LTM configuration related to the mobility of the UE, and the LTM configuration includes at least one of the following: LTM candidate cell list, LTM candidate cell ID, LTM source cell ID, LTM CSI resource configuration, and LTM CSI report configuration.

14. The method according to claim 11, further comprising: include: sending a second message related to UE context release to the first node, wherein the second message includes an LTM configuration retention indicator, Among them, the LTM configuration retention indicator is used to instruct the first node to retain the LTM configuration related to the mobility of the UE while releasing the LTM configuration that is not related to the mobility of the UE, and the LTM configuration related to the mobility of the UE includes at least one of the following: LTM candidate cell list, LTM candidate cell ID, LTM source cell ID, LTM CSI resource configuration, LTM CSI report configuration.

15. The method according to claim 11, further comprising: include: Receive and store a message of LTM configuration related to the mobility of the UE, wherein the LTM configuration includes at least one of the following: an LTM candidate cell list, an LTM candidate cell ID, an LTM source cell ID, an LTM CSI resource configuration, and an LTM CSI report configuration, The first message sent includes the LTM configuration previously received and stored.

16. The method according to claim 15, in, The message of the LTM configuration related to the mobility of the UE is a sequence number SN status transfer message.

17. A first node in a wireless communication system, include: a transceiver configured to transmit and receive signals; and A processor is coupled to the transceiver and configured to execute the method according to any one of claims 1 to 7.

18. User equipment UE in a wireless communication system, include: a transceiver configured to transmit and receive signals; and A processor is coupled to the transceiver and configured to execute the method according to any one of claims 8 to 10.

19. A second node in a wireless communication system, include: a transceiver configured to transmit and receive signals; and A processor is coupled to the transceiver and configured to execute the method according to any one of claims 11 to 16.

20. A computer-readable storage medium storing computer-executable instructions, wherein when the computer-executable instructions are executed by a processor, the processor executes the method according to any one of claims 1 to 16.

Images