Communicating lower-layer triggered mobility failure information in a distributed network architecture

Abstract

Methods, systems, and techniques are disclosed for communicating lower layer triggered mobility (LTM) failure information in a distributed network architecture, such as between a central unit (CU) and a distributed unit (DU), as well as among CUs (e.g., inter-CU communication). Aspects of this disclosure for communicating LTM failure information include an example method for wireless communications by a CU of a base station. The method includes obtaining 1503 a failure indication for a connection failure event of an LTM procedure and transmitting 1505, to a DU, failure information based on the failure indication. Another example method by a DU of a base station includes receiving 2005, from a CU, failure information for a connection failure event of a LTM procedure, and performing 2006 at least one of: a cause analysis based on the failure information, or a UE verification procedure based on the failure information.

Description

COMMUNICATING LOWER-LAYER TRIGGERED MOBILITY FAILURE INFORMATION IN A DISTRIBUTED NETWORK ARCHITECTURECROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims, in accordance with Article 8 of the Patent Cooperation Treaty (PCT) , the priority and benefits to International Application No. PCT / CN2024 / 130143, entitled “COMMUNICATING LOWER-LAYER TRIGGERED MOBILITY FAILURE INFORMATION IN A DISTRIBUTED NETWORK ARCHITECTURE, ” filed on November 6, 2024, which is expressly incorporated by reference herein in its entirety.TECHNICAL FIELD

[0002] This disclosure relates generally to wireless communications and, more particularly, to lower layer triggered mobility (LTM) procedures.BACKGROUND

[0003] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent as described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, is neither expressly nor impliedly admitted as prior art against the present disclosure.

[0004] In Lower Layer Triggered Mobility (LTM) procedures, also known as LTM cell switch procedures, a network entity (e.g., a next generation Node B (gNB) ) receives layer 1 (L1) measurement reports from a user equipment (UE) and determines whether to update a serving cell for the UE based on the L1 measurement reports via signaling a medium access control (MAC) control element (CE) cell switch command. The LTM cell switch command indicates an LTM candidate configuration of the target LTM cell that the gNB previously prepared and was transmitted to the UE via radio resource control (RRC) signaling. The LTM procedure may fail, such as due to timing, cell selection, or other configuration of the target LTM cell.

[0005] Conventionally, after a UE is configured with a LTM candidate configuration for at least one LTM candidate cell, a connection failure (e.g., radio link failure (RLF) ) or LTM execution failure (also referred to as LTM cell switch failure, LTM handover failure (LTM-HOF) , or HOF) may occur. These failures may be caused by improper LTM cell switch parameter (s) configurations by at least one network entity, e.g., a central unit (CU) , a source distributed unit (DU) , or a target DU. To avoid subsequent connection failures, a mobility robustness optimization (MRO) mechanism may be introduced into a wireless communication system. For MRO mechanism, the UE records parameter (s) of the connection failure information in a mobility procedure, generates an RLF report, and sends the RLF report to the network entity (s) responsible for the connection failure.

[0006] The RLF report, however, is not always available, especially to the CUs or DUs that participated in the failed LTM procedures. In some cases, the UE may not provide the RLF report to relevant network entities. For example, the UE performs reestablishment procedure or LTM recovery procedure with the selected cell. However, the UE does not provide the RLF report to the network entity managing the selected cell.SUMMARY

[0007] The present disclosure provides methods, systems, and techniques for communicating layer 1 (L1) or layer 2 (L2) triggered mobility (LTM) (also referred to as “L1 / L2 triggered mobility” or “lower-layer triggered mobility” ) failure information in a distributed network architecture, such as between a central unit (CU) and a distributed unit (DU) , as well as among CUs (e.g., inter-CU communication) . The present disclosure provides methods and techniques for communicating LTM failure information between CUs and DUs so that the root cause of the LTM failure may be analyzed and corrected. In particular, the present disclosure addresses what failure information is to be communicated to which relevant network entities in order to improve or optimize LTM procedures, regardless of whether radio link failure (RLF) reports are available to the network entities.

[0008] According to general aspects of this disclosure, a method for wireless communications by a CU of a base station includes obtaining a failure indication for a connection failure event of an LTM procedure and transmitting, to a DU, failure information based on the failure indication.

[0009] In aspects, the method further includes generating the failure information including at least one of: user equipment (UE) identifier information associated with the connection failure event, or reestablishment or recovery information associated with the connection failure event.

[0010] In some cases, obtaining the failure indication includes receiving the failure indication from a network entity. The method further includes: selecting a UE context matching the failure indication based on a cell radio network temporary identifier (C-RNTI) ; and verifying an identification of the UE based on a shortened version of message authentication code-integrity (shortMAC-I) calculated using the UE context.

[0011] In some cases, obtaining the failure indication includes determining a DU responsible for a connection failure event of an LTM procedure.

[0012] In aspects, the failure information includes at least one of: failure cell information; failure C-RNTI information; the shortMAC-I; UE application protocol (AP) identifier (ID) on an Fl interface between the CU and a DU; mobility type; LTM failure type; LTM related mobility information; reestablishment cell information; or reestablishment cause.

[0013] In aspects, the failure information is transmitted to a source DU.

[0014] In aspects, the failure cell information and the failure C-RNTI information are related to a target DU.

[0015] In some cases, the failure information further includes at least one of: a source C-RNTI or source cell information.

[0016] In some cases, the failure information is transmitted to a target DU.

[0017] In aspects, obtaining the failure indication includes receiving a radio link failure (RLF) report generated by the UE. And transmitting the failure information includes transmitting the RLF report to a proper DU based on a failure type of the LTM procedure.

[0018] In some cases, the proper DU includes at least one of: a failure DU when the failure type is an LTM-too-late; a source DU when the failure type is an LTM-too-early, a source DU when the failure type is an LTM to a wrong cell, or a target DU when the failure type is for an LTM-cell-switch and the RLF report includes random access information.

[0019] In aspects, obtaining the failure indication includes: receiving, from a recovery network entity, LTM recovery information. The LTM recovery information indicates at least one of:an indication that the UE has successfully accessed a current access cell; current access cell information, or a candidate target cell included in an LTM candidate cell configuration.

[0020] In some cases, the method further includes determining, based on the received LTM recovery information, a failure type of the LTM procedure, and wherein transmitting the failure information includes transmitting the failure type and the LTM recovery information to at least one of: a source DU or a target DU associated with the connection failure event of the LTM procedure.

[0021] According to general aspects of this disclosure, a method for wireless communications by a first CU of a base station includes receiving, from a second CU or a core network, a failure indication for a connection failure event of an LTM procedure, and transmitting, to a third CU or a DU, failure information based on the failure indication.

[0022] In aspects, the failure indication includes at least one of: the failure information; failure information and reestablishment information; failure information and LTM recovery cell information; or a radio link failure, RLF, report.

[0023] In aspects, the failure information includes at least one off a cause of an LTM reestablishment request; a radio link failure, RLF, report; reestablishment cell information; or an LTM recovery cell information.

[0024] According to general aspects of this disclosure, a method for wireless communications by a DU of a base station includes receiving, from a CU, failure information for a connection failure event of a LTM procedure, and performing at least one of: a cause analysis based on the failure information, or a UE verification procedure based on the failure information.

[0025] In aspects, the failure information includes at least one of: failure cell information; failure C-RNTI information; a shortened version of message authentication code-integrity, shortMAC-I; UE application protocol, AP, identifier, ID, on an F1 interface between the CU and a DU; mobility type; LTM failure type; LTM related mobility information; reestablishment cell information; or reestablishment cause.

[0026] In aspects, the DU is a source DU.

[0027] In aspects, the DU is a target DU. The failure cell information and the failure C-RNTI are related to the target DU.

[0028] According to general aspects of this disclosure, an apparatus includes one or more radio frequency (RF) modems; a processor coupled to the one or more RF modems; and at least one memory storing executable instructions. The executable instructions manipulate at least one of the processor or the one or more RF modems to perform the above methods, which are discussed in details herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Fig. 1 illustrates a diagram of a wireless communications system that includes multiple user equipments (UEs) and network entities in communication over one or more cells, according to aspects of this disclosure.

[0030] Fig. 2 illustrates an example signaling diagram of a successful lower layer triggered mobility (LTM) procedure, in accordance with aspects of this disclosure.

[0031] Fig. 3 illustrates a signaling diagram of failure information indication upon reestablishing connections (e.g., through LTM recovery, legacy reestablishment, mobility related serving cell change, or setup procedure) with radio link failure (RLF) report, in accordance with aspects of this disclosure.

[0032] Fig. 4 illustrates an example diagram of failure information delivery for connection reestablishment without RLF report, in accordance with aspects of this disclosure.

[0033] Fig. 5 illustrates an example diagram of failure information delivery from a central unit (CU) to distributed unit (DU) for connection reestablishment without RLF report, in accordance with aspects of this disclosure.

[0034] Fig. 6 illustrates an example diagram of failure information delivery from a CU to DU for connection reestablishment without RLF report, in accordance with aspects of this disclosure.

[0035] Fig. 7 illustrates an example diagram of failure information delivery from a CU to DU for connection reestablishment without RLF report, in accordance with aspects of this disclosure.

[0036] Fig. 8 illustrates an example diagram of failure information delivery from a CU to DU for connection reestablishment without RLF report, in accordance with aspects of this disclosure.

[0037] Fig. 9 illustrates an example diagram of failure information delivery from a CU to DU for connection reestablishment without RLF report, in accordance with aspects of this disclosure.

[0038] Fig. 10 illustrates an example diagram of failure information delivery from a CU to DU for connection reestablishment without RLF report, in accordance with aspects of this disclosure.

[0039] Fig. 11 illustrates an example diagram of failure information delivery from a CU to a source DU when an RLF report is available, in accordance with aspects of this disclosure.

[0040] Fig. 12 illustrates an example diagram of failure information delivery from a CU to a target DU when an RLF report is available, in accordance with aspects of this disclosure.

[0041] Fig. 13 illustrates an example diagram of failure information delivery from a CU to DU for LTM recovery without RLF report, in accordance with aspects of this disclosure.

[0042] Fig. 14 illustrates an example diagram of inter-CU failure information delivery, in accordance with aspects of this disclosure.

[0043] Fig. 15 illustrates an example flowchart of a method performed by a CU, in accordance with aspects of this disclosure.

[0044] Fig. 16 illustrates an example flowchart of a method performed by the CU on obtaining a failure indication, in accordance with aspects of this disclosure.

[0045] Fig. 17 illustrates an example flowchart of a method performed by the CU based on received failure indication, in accordance with aspects of this disclosure.

[0046] Fig. 18 illustrates an example flowchart of a method performed by the CU on determining a failure type of the LTM, in accordance with aspects of this disclosure.

[0047] Fig. 19 illustrates an example flowchart of a method performed by the CU, in accordance with aspects of this disclosure.

[0048] Fig. 20 illustrates an example flowchart of an inter CU communication method, in accordance with aspects of this disclosure.

[0049] Fig. 21 is a diagram illustrating a hardware implementation for an example UE apparatus.

[0050] Fig. 22 is a diagram illustrating a hardware implementation for one or more example network entities.DETAILED DESCRIPTION

[0051] The present disclosure provides techniques for communicating layer 1 (L1) or layer 2 (L2) triggered mobility (LTM) (also referred to as “L1 / L2 triggered mobility” or “lower-layer triggered mobility” ) failure information in a distributed network architecture, such as between a central unit (CU) and a distributed unit (DU) , as well as among CUs (e.g., inter-CU communication) . By communicating the failure information between CUs and DUs, the root cause of the LTM failure may be analyzed and corrected. In particular, the present disclosure addresses what failure information is to be communicated to which relevant network (NW) entities in order to improve or optimize LTM procedures and enable mobility robustness optimization (MRO) mechanism.

[0052] Aspects of this disclosure for communicating LTM failure information include a method for wireless communications by a CU of a base station. The method includes obtaining a failure indication for a connection failure event of an LTM procedure and transmitting, to a DU failure information based on the failure indication.

[0053] Complimentary aspects of the disclosure include an example method by a DU of a base station. The method includes receiving, from a CU, failure information for a connection failure event of a LTM procedure, and performing at least one of: a cause analysis based on the failure information, or a UE verification procedure based on the failure information.

[0054] Aspects of this disclosure for communicating LTM failure information further include a method for wireless communications by a first CU of a base station. The method includes receiving, from a second CU or a core network, a failure indication for a connection failure event of an LTM procedure, and transmitting, to a third CU or a DU, failure information based on the failure indication.

[0055] The present disclosure provides example methods for failure information delivery between CU and DU for reestablishment or LTM recovery, for cases without RLF report or with RLF report. For example, a CU may initiate a failure indication to DU after a successful LTM recovery, which is after a connection failure during a prior LTM procedure. In some embodiments, the connection reestablishment or LTM recovery is without an RLF report. For cases of the connection reestablishment or LTM recovery without an RLF report, one example scheme for CU to determine the LTM failure type includes one or more of the following: a. LTM-too-late: there is no recent handover for the UE prior to the connection failure,  e.g., the NW-side timer is absent or having a value larger than the configured threshold (e.g., Tstore_UE_cntxt) , or if LTM is configured but the LTM execution is not initiated for the UE prior to the connection failure, e.g., the UE reported timer is absent or larger than the configured threshold (e.g., Tstore_UE_cntxt) . b. LTM-too-early: there is a recent handover / LTM cell switch for the UE prior to the  connection failure, e.g., the NW-side timer having a value smaller than the configured threshold (e.g., Tstore_UE_cntxt) , and the first re-establishment attempt cell / the successful re-connect cell / the cell UE attempts LTM recovery is the cell that served the UE at the last LTM initialization. c. LTM to wrong cell: there is a recent handover / LTM cell switch for the UE prior to the  connection failure, e.g., the NW-side timer having a value smaller than the configured threshold (e.g., Tstore_UE_cntxt) , and the first re-establishment attempt cell / the cell UE attempts to re-connect / the cell UE attempts LTM recovery is neither the cell that served the UE at the last handover / LTM initialization nor the cell that served the UE where the RLF happened or the cell that the handover / LTM was initialized toward.

[0056] The "NW-side timer" above indicates the time elapsed since the last successful LTM execution or the notification of the access success information from the failure DU or the successful connection between the failure DU, or the cell switch notification message from the last serving DU (e.g., source DU in case of LTM was initialized) and UE until the reestablishment procedure, or the reception of the reestablishment request message, or the access information from the reestablishment DU, or until the reception of LTM recovery information (e.g., reception of RRCReconfigurationComplete message) , or the access success information from the LTM recovery DU.

[0057] In some cases, the LTM failure may be caused by a source DU having not configured an LTM cell switch command to a UE in time (referred to as LTM-too-late) . To analyze the failure root cause, the CU transmits failure information to the source DU (also referred to as the failure DU) . The failure information may include at least one of: the failure C-RNTI reported in reestablishment procedure, e.g., set to source C-RNTI; failure cell information (e.g., physical cell identifier (PCI) , PCI and frequency, and / or cell global identifier (CGI) , etc. ) reported / derived in reestablishment procedure (e.g., set to source cell information) ; shortMAC-I reported in reestablishment procedure; UE F1AP ID between the CU and the source DU; mobility type (e.g., LTM or cell switch types) ; LTM failure type, e.g., LTM-too-late; LTM related mobility information. The CU also transmits reestablishment information to the source DU (e.g., along with the failure information) . The reestablishment information includes at least one off reestablishment cell information derived / based reestablishment procedure, or reestablishment cause.

[0058] In some cases, an RLF occurs shortly after a successful LTM from a source LTM cell to a target cell, the UE attempts to re-establish the radio link connection in the source cell (referred to as LTM-too-early) or the UE attempts to re-establish the radio link connection in a cell other than the source cell (referred to as LTM to wrong cells) . In such cases, the CU transmits failure information and reestablishment information to the source DU. The failure information to the source DU includes at least one of: the source C-RNTI, source cell information (e.g., a physical cell identifier (PCI) , a PCI and a range of frequency, or a cell global identifier (CGI) ) , failure cell information reported in reestablishment procedure (e.g., set to target cell information) , failure C-RNTI reported in reestablishment procedure (e.g., set to target C-RNTI) , UE F1AP ID between the CU and the source DU, mobility type (LTM) , LTM failure type (e.g., LTM-too-early or LTM to wrong cell) , or LTM related mobility information. The CU also transmits failure information and reestablishment information to the target DU. The failure information to the target DU includes at least one of: failure cell information reported in reestablishment procedure (e.g., set to target cell information) ; failure C-RNTI reported in reestablishment procedure (e.g., set to target C-RNTI) ; or shortMAC-I reported in reestablishment procedure.

[0059] In some cases, instead of RLF, an LTM cell switch failure, or LTM handover failure (LTM-HOF) occurs shortly after a successful LTM from a source LTM cell to a target cell, the UE attempts to re-establish the radio link connection in the source cell (LTM-too-early) or the UE attempts to re-establish the radio link connection in a cell other than the source cell (LTM to wrong cells) . In such cases, the CU transmits failure information and reestablishment information to the source DU. The failure information includes at least one of: the failure C-RNTI reported in reestablishment procedure (e.g., set to source C-RNTI) , failure cell information (e.g., PCI, PCI and frequency, and / or CGI) reported / derived in reestablishment procedure (e.g., set to source cell information) , shortMAC-I reported in reestablishment procedure, UE F1AP ID between the CU and the source DU, mobility type, LTM failure type (e.g., LTM-too-early or LTM to wrong cell) , or LTM related mobility information.

[0060] In some cases, the UE performs LTM recovery (e.g., the UE attempts to reestablish connection with one of the LTM candidate cells) without providing an RLF report. In such cases, the CU transmits failure information and LTM recovery cell information to the source DU. The failure information includes at least one of: LTM failure type (e.g., LTM-too-late, LTM-too-early, or LTM to wrong cell) , connection failure type (e.g., HOF or RLF) , source cell information, target cell information, source C-RNTI, UE F1 AP ID between CU and the source DU, or LTM related mobility information. When the UE provides RLF report, the CU may transmit failure information including at least one of: the source C-RNTI in the source cell, the target C-RNTI in the target cell, LTM failure type information, mobility type, or LTM related mobility information. In some cases, the CU transmits information that clarifies the CU behavior (e.g., the condition or scenario for the CU to provide the assistance information) . For example, the CU provides to the source DU the source C-RNTI in the source cell in case of RLF for LTM-too-early / LTM to wrong cell. The CU provides the target DU the target C-RTNI in the target ell in case of HOF for LTM-too-early / LTM to wrong cell. The RLF report may provide random access channel (RACH) information to be included in the CU's transmission to DU.

[0061] In some cases, multiple radio access network (RAN) devices may communicate the failure notification information or failure report information, such as among CUs (e.g., inter-CU) or other RAN devices and core network (CN) devices.

[0062] The present disclosure communicates failure information and reestablishment information among CUs and DUs, thus enabling timely change requests on F1, Xn, and / or NG interfaces during cell switching. Such communication improves and enables mobility robustness optimization (MRO) for LTM.

[0063] Fig. 1 illustrates a diagram 100 of a wireless communications system associated with multiple cells 190. The wireless communications system includes user equipments (UEs) 102 and base stations / network entities 104. Some base stations may include an aggregated base station architecture and other base stations may include a disaggregated base station architecture. The aggregated base station architecture utilizes a radio protocol stack that is physically or logically integrated within a single radio access network (RAN) node. A disaggregated base station architecture utilizes a protocol stack that is physically or logically distributed among two or more units (e.g., radio unit (RU) 106, distributed unit (DU) 108, central unit (CU) 110) . For example, a CU 110 is implemented within a RAN node, and one or more DUs 108 may be co-located with the CU 110, or alternatively, may be geographically or virtually distributed throughout one or multiple other RAN nodes. The DUs 108 may be implemented to communicate with one or more RUs 106. Any of the RU 106, the DU 108 and the CU 110 may be implemented as virtual units, such as a virtual radio unit (VRU) , a virtual distributed unit (VDU) , or a virtual central unit (VCU) . The base station / network entity 104 (e.g., an aggregated base station or disaggregated units of the base station, such as the RU 106 or the DU 108) , may be referred to as a transmission reception point (TRP) . The network entity 104 can be a RAN entity or core network (CN) entity in this application. For example, the network entity 104 can be the location management function (LMF) entity (e.g., for positioning use cases) . The descriptions of network entity is just for illustration and does not show any limitation on the implementation. In some cases, the network entity includes a high-level entity including CN and / or RAN entities.

[0064] Operations of the base station (BS) 104 and / or network designs may be based on aggregation characteristics of base station functionality. For example, disaggregated base station architectures are utilized in an integrated access backhaul (IAB) network, an open-radio access network (O-RAN) network, or a virtualized radio access network (vRAN) , which may also be referred to a cloud radio access network (C-RAN) . Disaggregation may include distributing functionality across the two or more units at various physical locations, as well as distributing functionality for at least one unit virtually, which may enable flexibility in network designs. The various units of the disaggregated base station architecture, or the disaggregated RAN architecture, may be configured for wired or wireless communication with at least one other unit. For example, the base stations (BSs) 104d, 104e and / or the RUs 106a, 106b, 106c, 106d may communicate with the UEs 102a, 102b, 102c, 102d, and / or 102s via one or more radio frequency (RF) access links based on a Uu interface. In examples, multiple RUs 106 and / or BSs 104 may simultaneously serve the UEs 102, such as by intra-cell and / or inter-cell access links between the UEs 102 and the RUs 106 / BSs 104.

[0065] The RU 106, the DU 108, and the CU 110 may include (or may be coupled to) one or more interfaces configured to transmit or receive information / signals via a wired or wireless transmission medium. For example, a wired interface may be configured to transmit or receive the information / signals over a wired transmission medium, such as via the fronthaul link 160 between the RU 106d and the baseband unit (BBU) 112 of the BS 104d associated with the cell 190d. The BBU 112 includes a DU 108 and a CU 110, which may also have a wired interface (e.g., midhaul link 162) configured between the DU 108 and the CU 110 to transmit or receive the information / signals between the DU 108 and the CU 110. In further examples, a wireless interface, which may include a receiver, a transmitter, or a transceiver, such as an RF transceiver, configured to transmit and / or receive the information / signals via the wireless transmission medium, such as for information communicated between the RU 106a of the cell 190a and the BS 104e of the cell 190e via cross-cell communication beams 136-138 of the RU 106a and the BS 104e.

[0066] The RUs 106 may be configured to implement lower layer functionality. For example, the RU 106 is controlled by the DU 108 and may correspond to a logical node that hosts RF processing functions, or lower layer PHY functionality, such as execution of fast Fourier transform (FFT) , inverse FFT (iFFT) , digital beamforming, physical random access channel (PRACH) extraction and filtering, etc. The functionality of the RU 106 may be based on the functional split, such as a functional split of lower layers.

[0067] The RUs 106 may transmit or receive over-the-air (OTA) communication with one or more UEs 102. For example, the RU 106b of the cell 190b communicates with the UE 102b of the cell 190b via a first set of communication beams 132 of the RU 106b and a second set of communication beams 134b of the UE 102b, which may correspond to inter-cell communication beams or, in some examples, cross-cell communication beams. For instance, the UE 102b of the cell 190b may communicate with the RU 106a of the cell 190a via a third set of communication beams 134a of the UE 102b and a fourth set of communication beams 136 of the RU 106a. DUs 108 may control both real-time and non-real-time features of control plane and user plane communications of the RUs 106.

[0068] Any combination of the RU 106, the DU 108, and the CU 110, or reference thereto individually, may correspond to a BS 104. Thus, the BS 104 may include at least one of the RU 106, the DU 108, or the CU 110. The BSs 104 provide the UEs 102 with access to a core network (CN) . The BSs 104 may relay communications between the UEs 102 and the core network (not shown) . The BSs 104 may be associated with macrocells for higher-power cellular base stations and / or small cells for lower-power cellular base stations. For example, the cell 190e may correspond to a macrocell, whereas the cells 190a-190d may correspond to small cells. Small cells include femtocells, picocells, microcells, etc. A network that includes at least one macrocell and at least one small cell may be referred to as a “heterogeneous network. ”

[0069] Transmissions from a UE 102 to a BS 104 / RU 106 are referred to as uplink (UL) transmissions, whereas transmissions from the BS 104 / RU 106 to the UE 102 are referred to as downlink (DL) transmissions. Uplink transmissions may also be referred to as reverse link transmissions and downlink transmissions may also be referred to as forward link transmissions. For example, the RU 106d utilizes antennas of the BS 104d of cell 190d to transmit a downlink / forward link communication to the UE 102d or receive an uplink / reverse link communication from the UE 102d based on the Uu interface associated with the access link between the UE 102d and the BS 104d / RU 106d.

[0070] Communication links between the UEs 102 and the BSs 104 / RUs 106 may be based on multiple-input and multiple-output (MIMO) antenna technology, including spatial multiplexing, beamforming, and / or transmit diversity. The communication links may be associated with one or more carriers. The UEs 102 and the BSs 104 / RUs 106 may utilize a spectrum bandwidth of Y MHz (e.g., 5, 10, 15, 20, 100, 400, 800, 1600, 2000, etc. MHz) per carrier allocated in a carrier aggregation of up to a total of Yx MHz, where x component carriers (CCs) are used for communication in each of the uplink and downlink directions. The carriers may or may not be adjacent to each other along a frequency spectrum. In examples, uplink and downlink carriers may be allocated in an asymmetric manner, with more or fewer carriers allocated to either the uplink or the downlink. A primary component carrier and one or more secondary component carriers may be included in the component carriers. The primary component carrier may be associated with a primary cell (Pcell) and a secondary component carrier may be associated with a secondary cell (Scell) .

[0071] Some UEs 102, such as the UEs 102a and 102s, may perform device-to-device (D2D) communications over sidelink. For example, a sidelink communication / D2D link utilizes a spectrum for a wireless wide area network (WWAN) associated with uplink and downlink communications. Such sidelink / D2D communication may be performed through various wireless communications systems, such as wireless fidelity (Wi-Fi) systems, Bluetooth systems, Long Term Evolution (LTE) systems, New Radio (NR) systems, etc.

[0072] The UEs 102 and the BSs 104 / RUs 106 may each include multiple antennas. The multiple antennas may correspond to antenna elements, antenna panels, and / or antenna arrays that may facilitate beamforming operations. For example, the RU 106b transmits a downlink beamformed signal based on a first set of communication beams 132 to the UE 102b in one or more transmit directions of the RU 106b. The UE 102b may receive the downlink beamformed signal based on a second set of communication beams 134b from the RU 106b in one or more receive directions of the UE 102b. In a further example, the UE 102b may also transmit an uplink beamformed signal (e.g., sounding reference signal (SRS) ) to the RU 106b based on the second set of communication beams 134b in one or more transmit directions of the UE 102b. The RU 106b may receive the uplink beamformed signal from the UE 102b in one or more receive directions of the RU 106b. The UE 102b may perform beam training to determine the best receive and transmit directions for the beamformed signals. The transmit and receive directions for the UEs 102 and the BSs 104 / RUs 106 may or may not be the same.

[0073] In further examples, beamformed signals may be communicated between a first base station / RU 106a and a second BS 104e. For instance, the BS 104e of the cell 190e may transmit a beamformed signal to the RU 106a based on the communication beams 138 in one or more transmit directions of the BS 104e. The RU 106a may receive the beamformed signal from the BS 104e of the cell 190e based on the RU communication beams 136 in one or more receive directions of the RU 106a. In further examples, the B S 104e transmits a downlink beamformed signal to the UE 102e based on the communication beams 138 in one or more transmit directions of the BS 104e. The UE 102e receives the downlink beamformed signal from the BS 104e based on UE communication beams 130 in one or more receive directions of the UE 102e. The UE 102e may also transmit an uplink beamformed signal to the BS 104e based on the UE communication beams 130 in one or more transmit directions of the UE 102e, such that the BS 104e may receive the uplink beamformed signal from the UE 102e in one or more receive directions of the BS 104e.

[0074] The BS 104 may include and / or be referred to as a network entity. That is, “network entity” may refer to the BS 104 or at least one unit of the BS 104, such as the RU 106, the DU 108, and / or the CU 110. The BS 104 may also include and / or be referred to as a next generation evolved Node B (ng-eNB) , a next generation NB (gNB) , an evolved NB (eNB) , an access point, a base transceiver station, a radio base station, a radio transceiver, a transceiver function, a basic service set (BSS) , an extended service set (ESS) , a TRP, a network node, network equipment, or other related terminology. The BS 104 or an entity at the BS 104 may be implemented as an IAB node, a relay node, a sidelink node, an aggregated (monolithic) base station, or a disaggregated base station including one or more RUs 106, DUs 108, and / or CUs 110. A set of aggregated or disaggregated base stations may be referred to as a next generation-radio access network (NG-RAN) . In some examples, the UE 102a operates in dual connectivity (DC) with the BS 104e and the base station / RU 106a. In such cases, the BS 104e may be a master node and the base station / RU 106a may be a secondary node.

[0075] Uplink / downlink signaling may also be communicated via a satellite positioning system (SPS) 114. In an example, the SPS 114 associated with the cell 190c may be in communication with one or more UEs 102, such as the UE 102c, and one or more BSs 104 / RUs 106, such as the RU 106c. The SPS 114 may correspond to one or more of a Global Navigation Satellite System (GNSS) , a global position system (GPS) , a non-terrestrial network (NTN) , or other satellite position / location system. The SPS 114 may be associated with LTE signals, NR signals (e.g., based on round trip time (RTT) and / or multi-RTT) , wireless local area network (WLAN) signals, a terrestrial beacon system (TBS) , sensor-based information, NR enhanced cell identifier (ID) (NR E-CID) techniques, downlink angle-of-departure (DL-AoD) , downlink time difference of arrival (DL-TDOA) , uplink time difference of arrival (UL-TDOA) , uplink angle-of-arrival (UL-AoA) , and / or other systems, signals, or sensors.

[0076] In Fig. 1, any of the UEs 102 may include a LTM failure report component 140 configured to report RLF or LTM HOF to the network entity 104 (e.g., to the CU 110) . The LTM failure report component 140 may detect an RLF or LTM HOF and generate an RLF report. The LTM failure report component 140 may send 410 reestablishment requests, RLF reports, or LTM recovery requests according to examples below in Figs. 3-13.

[0077] The BS 104 includes a failure information component 150 configured to perform operations regarding LTM failures, with or without RLF report from the LTM failure report component 140 of the UE 104. For example, the failure information component 150 is configured to obtain (e.g., by the CU 110) a failure indication for a connection failure event of an LTM procedure and transmit, to a DU 108, failure information based on the failure indication. The failure information component 150 may also receive, by the DU 108 of the BS 104, from the CU 110, failure information for a connection failure event of a LTM procedure. The failure information component 150 may enable the DU 108 to perform at least one of: a cause analysis based on the failure information, or a UE verification procedure based on the failure information.

[0078] Accordingly, Fig. 1 describes a wireless communication system that may be implemented in connection with aspects of one or more other figures described herein. Further, although the following description may be focused on 5G NR, the concepts described herein may be applicable to other similar areas, such as 5G-Advanced and future versions, LTE, LTE-advanced (LTE-A) , and other wireless technologies, such as 6G.

[0079] Fig. 2 illustrates an example signaling diagram of a successful lower-layer (Layer 1 or Layer 2) triggered mobility (LTM) procedure, in accordance with aspects of this disclosure. As shown, Fig. 2 illustrates the operations among the UE 102, the source DU 108a, the candidate DU 108b, and the CU 110. The operations begin with the UE 102 transmitting (operation 1) a MeasurementReport message, containing Layer 3 (L3) measurement results of neighboring cells, to the source gNB-DU 108a. The source gNB-DU 108a then sends an UL RRC MESSAGE TRANSFER message, carrying the received MeasurementReport, to the gNB-CU 110.

[0080] The gNB-CU 110 decides (operation 2) to start the LTM configuration. The gNB-CU 110 sends (operation 3) a UE 102 CONTEXT SETUP REQUEST message to each candidate gNB-DU 108b for each candidate cell. This message includes a candidate cell ID, channel state information (CSI) resource configuration for the upcoming LTM, and may include an LTM configuration ID mapping list. The gNB-CU 110 may also request PRACH resources, ask for the lower layer configuration needed for generating a reference configuration, or provide the lower layer part of the reference configuration to candidate gNB-DUs 108b.

[0081] Ifthe candidate gNB-DU 108b accepts the LTM configuration request, the candidate gNB-DU 108b replies (operation 4) with a UE 102 CONTEXT SETUP RESPONSE message containing the lower layer RRC configurations generated for the designated target candidate cell. In some cases, the operations 3 and 4 can also apply for preparing candidate cells in the source gNB-DU 108a through the CU-initiated UE 102 Context Modification procedure.

[0082] The gNB-CU 110 sends (operation 5) a UE 102 CONTEXT MODIFICATION REQUEST to the source gNB-DU 108a, which includes information on early synchronization and the LTM configuration ID mapping list for the accepted target candidate cells. The modification request message may also include an updated CSI resource configuration.

[0083] The source gNB-DU 108a responds (operation 6) with a UE 102 CONTEXT MODIFICATION RESPONSE, including an updated lower layer configuration, such as the new CSI report configuration for the source cell.

[0084] The gNB-CU 110 may send (operation 7) a UE 102 CONTEXT MODIFICATION REQUEST to the candidate gNB-DU 108bs, providing information for the next LTM or updating candidate cell configurations. The lower layer part of the reference configuration may also be included. Each candidate gNB-DU 108b responds (operation 8) with a UE 102 CONTEXT MODIFICATION RESPONSE, including the updated lower layer configuration, such as the updated CSI report configuration. In some cases, the operation 7 may also be triggered after operations 19 or 22 in Fig. 2, depending on implementation for subsequent LTM.

[0085] The gNB-CU 110 sends (operation 9) a DL RRC MESSAGE TRANSFER to the source gNB-DU 108a. The message contains an RRCReconfiguration message with the LTM configuration. The source gNB-DU 108a forwards (operation 10) the RRCReconfiguration message to the UE 102.

[0086] The UE 102 responds (operation 11) with an RRCReconfigurationComplete message to the source gNB-DU 108a. The source gNB-DU 108a forwards (operation 12) the RRCReconfigurationComplete message to the gNB-CU 110 via an UL RRC MESSAGE TRANSFER. The source gNB-DU 108a optionally acquires (operation 13) timing advance (TA) from the UE 102. Early synchronization to the candidate cells may be performed.

[0087] The candidate gNB-DU 108b sends (operation 14) a DU-CU TA INFORMATION TRANSFER message to the gNB-CU 110, including TA values and related PRACH resource information. The gNB-CU 110 forwards (operation 15) this information to the source gNB-DU 108a in a CU-DU TA INFORMATION TRANSFER message.

[0088] The UE 102 sends (operation 16) Layer 1 measurement results to the source gNB-DU 108a. The source gNB-DU 108a decides (operation 17) to initiate LTM to a target cell. The source gNB-DU 108a sends (operation 18) a Cell Switch Command to the UE 102.

[0089] The source gNB-DU 108a notifies (operation 19) the gNB-CU 110 of the cell switch initiation by sending a DU-CU CELL SWITCH NOTIFICATION message, which includes the target cell ID, TCI state ID (s) , and optional TA value information for the next LTM. The gNB-CU 110 forwards (operation 20) the CU-DU CELL SWITCH NOTIFICATION to the target gNB-DU 108b, relaying the target cell ID, TCI state ID (s) , and TA values.

[0090] The target gNB-DU 108b detects (operation 21) the UE 102's access. The target gNB-DU 108b sends (operation 22) an ACCESS SUCCESS message to the gNB-CU 110, indicating the target cell ID.

[0091] The UE 102 sends (operation 23) an RRCReconfigurationComplete message to the target gNB-DU 108b. The target gNB-DU 108b forwards (operation 24) this message to the gNB-CU 110 via an UL RRC MESSAGE TRANSFER. The gNB-CU 110 may issue (operation 25) a UE 102 CONTEXT RELEASE COMMAND to the source gNB-DU 108a to release the resources for prepared cells. The source gNB-DU 108a completes (operation 26) the process by sending a UE 102 CONTEXT RELEASE COMPLETE message.

[0092] In some situations, after a UE 102 is configured with a LTM candidate configuration for at least one LTM candidate cell, a connection failure (e.g., radio link failure (RLF) or LTM execution failure (such as an LTM cell-switch failure, LTM handover failure (HOF) , or HOF) may occur. These failures may be caused by improper LTM cell switch parameter (s) configured by at least one of the network entities, e.g., the CU 110, the source DU 108a, and / or the target DU 108b. This disclosure categorizes the modes (or types, or cases) of failure into three types for LTM procedure.

[0093] A first type of LTM failure includes too late LTM or LTM handover (also referred to as LTM-too-late) , which takes place when an RLF occurs after the UE has stayed for a long period of time in the cell. The UE attempts to re-establish the radio link connection in a different cell. In addition, the LTM is configured but the LTM execution is not initiated for the UE prior to the connection failure.

[0094] A second type of LTM failure includes too early LTM or LTM handover (also referred to as LTM-too-early) , which takes place when an RLF occurs shortly after a successful LTM from a source LTM cell to a target cell or a handover failure (HOF) occurs during the LTM procedure. The UE attempts to re-establish the radio link connection in the source cell.

[0095] A third type of LTM failure includes LTM or LTM HOF to a wrong cell, which takes place when an RLF occurs shortly after a successful LTM from a source cell to a target cell or a handover failure occurs during the LTM procedure. The UE attempts to re-establish the radio link connection in a cell other than the source cell and the target cell.

[0096] Ifthe cell where the UE attempts to re-establish the radio link connection is one of the LTM candidate cell, the UE can perform LTM recovery procedure. For example, the UE is configured with a LTM candidate cell x. Optionally, the cell x is configured to support LTM recovery or LTM attempt. When the connection failure occurs, the UE selects the cell x as the reestablishment attempt cell. The UE can perform LTM recovery with the cell x, e.g., the UE sends RRC Reconfiguration Complete message to cell x. If the UE selects a cell which is not a LTM candidate cell or which is a LTM candidate cell without LTM recovery or LTM attempt configured, the UE performs legacy reestablishment procedure, e.g., the UE sends RRC Reestablishment Request message to cell x.

[0097] To avoid subsequent connection failures, a mobility robustness optimization (MRO) mechanism may be introduced into a wireless communication system. For MRO mechanism, the UE records parameter (s) of the connection failure information in a mobility procedure, generates an RLF report, and sends the RLF report to the network entity (s) responsible for the connection failure. The UE may report the RLF report to a third network entity which may be different from the source one or the target one. The third network entity transfers the RLF report to the network entity to which the source cell or target cell belongs. In some embodiments, when the third network entity is the same as the one to which the RLF report is transferred, the transfer of RLF report is the internal implementation at the network entity. The network entity can perform initial analysis, e.g., to determine whether the connection failure was caused by the unsuitable configuration (s) at the network side. It is understood that the terminology “RLF report” is merely exemplary and illustrative and is not intended to limit against or exclude other types of report (s) .

[0098] According to aspects of this disclosure, in a distributed network architecture, the network entity may be a CU. If the connection failure was not caused due to the sub-optimal LTM candidate configuration (s) of the CU. The CU further identifies the DU (s) responsible for the connection failure and forwards the RLF report to the DU (s) . In addition, the CU communicates failure information to DUs (e.g., source DU and / or target DU) , depending on the failure type, to facility analyzing the improper LTM parameters in order to timely implement corrections or improvement to avoid future LTM failures.

[0099] Fig. 3 illustrates a signaling diagram 300 of failure information indication upon reestablishing connections (e.g., through LTM recovery, legacy reestablishment, mobility related serving cell change, or setup procedure) with radio link failure (RLF) report, in accordance with aspects of this disclosure. As shown, in an LTM procedure, the UE 102 detects 301 a connection failure (e.g., RLF or LTM HOF, among others) associated with the source LTM cell 108a and / or the target LTM cell 108b. The UE 102 then generates 302 an RLF report regarding the connection failure.

[0100] The UE establishes 313 a connection with a third network entity (Third NE) 104c (e.g., through LTM recovery, legacy reestablishment, mobility related serving cell change, or setup procedure) via a cell of the third network entity 104c and reports the RLF report to the network entity. The third network entity forwards 304 the RLF report to the CU 110, that manages the source DU 108a and candidate DU (s) including the target DU 108b. In some cases, the CU 110 forwards 305 the RLF report to one or more DU (s) 108a or 108b responsible for the connection failure. For example, the DU (s) include the source and / or target DU. Furthermore, the CU may forward failure information to assist the DU (s) for root cause analysis of the connection failure.

[0101] The present disclosure provides various examples of the failure information to be communicated to enable to root cause analysis of the connection failure. Although an RLF report provided by the UE 102 includes relevant information, the RLF report may not be sufficient. Furthermore, there are another cases where the UE 102 does not provide the RLF report to the network entity. For example, the UE 102 performs reestablishment procedure or LTM recovery procedure with the selected cell. However, the UE 102 may not provide the RLF report to the network entity managing the selected cell. The present disclosure provides example procedures to deliver CU-DU failure information regardless whether the RLF report is available, as described in details below.

[0102] Fig. 4 illustrates an example diagram 400 of failure information delivery for connection reestablishment without RLF report, in accordance with aspects of this disclosure. As shown, when the UE 102 detects 401, in an LTM procedure, a connection failure. The connection failure can be LTM HOF or RLF. For one example, the UE detects RLF with previous serving cell after the UE has stayed for a long period and configured with LTM configuration which is not initiated before the RLF. The previous cell can be called the failure cell, where the UE was connected before the RLF. Correspondingly, the network entity managing the failure cell can be considered as failure network. In this case, the failure node is the previous one.

[0103] For a second example, the UE detects HOF during the LTM procedure. In this case, the failure cell refers to the source cell during the LTM procedure. The HOF occurs between UE and the target LTM cell. That is, the UE does not complete the connection with the target LTM cell. Generally, the failure cell refers to the cell where the UE was connected before the connection failure. Therefore, in this case, the failure cell refers to the source LTM cell. The failure network entity is the source one.

[0104] For a third example, the UE detects RLF occurs shortly after a successful LTM from a source LTM cell to a target LTM cell. In this case, the failure cell refers to the target LTM cell during the LTM procedure. The failure network entity is the target one.

[0105] The UE 102 transmits 410 a reestablishment request to the third network entity 104c. It is noted that in this application, if it is not explicitly indicated, the reestablishment procedure may refer to the one with reestablishment request message. The reestablishment request message may include reestablishment cause and the UE identify information.

[0106] The reestablishment cause indicates the failure cause that triggered the re-establishment procedure. The reestablishment cause may be set or configured to be at least one of: a reconfiguration failure (if the reestablishment procedure was initiated due to inability to comply with the configuration from the network entity) ; LTM HOF (if the reestablishment procedure was initiated due to handover failure in the mobility procedure, e.g., T304 expiry) ; RLF, or other failures (for cases different from the above ones) .

[0107] The UE identity information is used to retrieve UE context and to facilitate contention resolution by lower layers. The UE identify information includes at least one of: a failure C-RNTI, a failure cell PCI, or a shortMAC-I. The failure C-RNTI indicates the C-RNTI the UE had in the cell (cell in this disclosure may be the same as or can be directly replaced by a PCell) the UE connected to prior to the reestablishment. For example, the failure C-RNTI may be set to the C-RNTI used in the source cell for handover failure case; or the failure C-RNTI may be set to the C-RNTI used in the failure cell (e.g., the cell where RLF was detected) in which the trigger for the reestablishment occurred (other cases) .

[0108] The failure cell PCI indicates the physical cell identity of the cell the UE was connected to prior to the reestablishment. The failure cell PCI may be set to the PCI of the source cell for handover failure case; or the failure cell PCI may be set to the PCI of the failure cell in which the trigger for the reestablishment occurred (other cases) .

[0109] The UE identity information may also include shortMAC-I, which is used to identify and verify the UE at RRC connection reestablishment. The inputs to generate shortMAC-I are: the cell identity of the reestablishment cell, the above failure C-RNTI and failure PCI. For one example, if there is no recent LTM cell switch procedure and RLF occurs between UE and the serving cell, e.g., LTM-too-late, the failure C-RNTI and cell PCI are set to the ones related to the previous serving cell before the RLF. To simplify the description, for the serving cell in LTM-too-late cases, the serving cell is still referred to as the source cell herein.

[0110] In other examples, recent LTM cell switch procedure and connection failure may occur, e.g., LTM-too-early or LTM to wrong cell. For HOF case, the failure C-RNTI and cell PCI are set to the ones related to the source LTM cell. For RLF case, the failure C-RNTI and cell PCI are set to the ones related to the target LTM cell.

[0111] The third network entity 104c transmits 403 a failure indication to the failure network entity (Failure NE) 104b associated with the connection failure. For example, the third network entity 104c identifies the CU based on the failure cell PCI and forwards the failure information and reestablishment cell CGI. The failure indication includes the information of the reestablishment request and may further include the reestablishment cell CGI. The failure network entity 104b performs root cause analysis of the LTM procedure failure based on the received failure information and reestablishment cell CGI, in order to correct or improve associated LTM configurations. There is no scheme for CU to delivery any failure information to DU in the case no RLF report is provided from UE.

[0112] In addition, when the UE 102 does not provide the RLF report to the third network entity 104c (here, “third” means that the network entity may be different from the source or target network entity. In some cases, the third network entity can be the same as the source network entity or the target network entity (e.g., the CU 110, or DUs 108a or 108b) ) . The UE 102 provides the failure information to a third network entity 104c. If the third network entity 104c is different from the failure network entity 104b, the third network entity 104c forwards the failure information to the related network, e.g., a CU for LTM cases. The failure network entity 104c is the one responsible for the connection failure, at least responsible for the initial analysis of the connection failure. The failure network 104b can be the source network entity 108a and / or the target network entity 108b.

[0113] For intra-CU and inter-DU LTM cases, the CU 110 manages the source DU 108a and candidate DU (s) including target DU 108b. The existing MRO mechanism often does not support the failure information delivery from CU to DU for reestablishment case without RLF report. As a result, the DU 108a or 108b could not optimize the LTM parameter (s) for reestablishment cases without RLF report. Similar issue also exists for the LTM recovery cases without RLF report. The present disclosure overcomes the deficiency in the existing MRO mechanism and details the failure information communicated between the CU 110 and DUs 108 to improve the MRO mechanisms in various LTM failure situations. As such, the present disclosure supports MRO at the DU at least for reestablishment case without RLF report or LTM recovery case without RLF report by delivering the failure information from the CU 110 to DUs 108, as described in the various embodiments below. The foregoing examples of the detection or determination scheme at the CU side may also apply in reestablishment cases without RLF report or LTM recovery case without RLF report.

[0114] For LTM-too-late cases, a CU may deliver failure information and reestablishment information to a DU without RLF report. For example, after detecting RLF, the UE 102 may perform reestablishment without providing an RLF report. Either the CU (e.g., Fig. 5) or the DU (e.g., Fig. 6) may perform UE verification. Based on the failure information (and other information therein, such as reestablishment information) , the DU may optimize the LTM parameters to improve the robustness of the LTM procedure.

[0115] Fig. 5 illustrates an example diagram 500 of failure information delivery for connection reestablishment without RLF report, in accordance with aspects of this disclosure. As shown, the UE 102 detects 401a an RLF with the source DU 108a (the previous serving cell, where the UE is in connection with before the RLF) . The operation 401a is similar to the operation 401 of Fig. 4. In particular, the UE provides the failure C-RNTI and failure cell information related to the ones of the failure cell. The failure cell is referred to as the source cell, even though LTM cell switch command has not been received on the UE side. The UE 102 transmits 410 a reestablishment request to the third network entity 104c, similar to the operation 410 of Fig. 4.

[0116] The third network entity 104c transmits 503 the failure information and reestablishment information to the CU 110, similar to the operation 403 of Fig. 4. The failure information may include shortMAC-I, failure cell information, failure C-RNTI. The reestablishment information may include reestablishment cell information, and reestablishment causes. The cell information can include PCI, PCI and frequency information, cell identity, or cell global identity. In addition, the cell information may include the network type information, e.g., NTN, non-public network, or the like.

[0117] The CU 110 verifies 504 the UE based on the shortMAC-I in the failure indication from the third network entity 104c. When the CU 110 receives the failure information and reestablishment information, the CU 110 selects the UE context that matches the received failure cell information and C-RNTI. If the UE context is available, the CU 110 uses the shortMAC-I to confirm this identification, such as by calculating a shortMAC-I and comparing the calculated value to the received value in the failure information.

[0118] If the CU 110 determines that the DU 108a to which the source cell belongs should be responsible for the LTM RLF, the CU 110 forwards 505 failure information and reestablishment information to source DU to which the source cell belongs. The failure information includes at least one off failure cell information, failure C-RNTI, UE F1AP ID between the CU and the source DU (also referred to as the UE assistant identifier) , LTM failure type information, mobility type, LTM related mobility information, or the like.

[0119] In some embodiments, the failure cell information and C-RNTI are set to the ones related to the source cell (or the failure cell) , provided in the reestablishment procedure from the UE, or derived by the third network entity based on the UE identify information provided by the UE.

[0120] The UE F1AP ID can include at least one of the gNB-CU UE F1AP ID and gNB-DU UE F1AP ID. The gNB-CU UE F1AP ID uniquely identifies the UE association over the F1 interface within the gNB-CU. The gNB-DU UE F1AP ID uniquely identifies the UE association over the F1 interface within the gNB-DU. The LTM failure type information may include or be indicated by LTM-too-late, LTM-too-early, or LTM to wrong cell. The LTM failure type information is set to LTM-too-late in this case. The mobility type is set to LTM. The LTM related mobility information may explicitly or implicitly indicate the LTM related mobility parameter (s) , e.g., LTM candidate cell information, LTM candidate cell configuration information, LTM cell switch decision relate parameters, or the like.

[0121] In some embodiments, the DU can provide (e.g., via cell switch or reconfiguration) the LTM related mobility information to the CU during LTM procedure, e.g., during LTM preparation phase, LTM execution phase, LTM completion phase or other phase. For example, the source DU 108a can provide the LTM related mobility information to the CU 110 via the DU-CU CELL SWITCH NOTIFICATION message, the UE CONTEXT MODIFICATION RESPONSE message, or other messages. The target DU can provide LTM related mobility information to the CU via ACCESS SUCCESS message, UE CONTEXT MODIFICATION RESPONSE message or other message.

[0122] The reestablishment information includes at least one of: reestablishment cell information, reestablishment cause information, or the like.

[0123] The CU 110 transmits 505 the failure message carrying the failure information and reestablishment information from the CU 110 to the DU 108a. The failure message can be one of the following: a FAILURE INDICATION message, a HANDOVER REPORT message, an ACCESS AND MOBILITY INDICATION message, or a new message.

[0124] The source DU 108a may perform 506 root cause analysis for the LTM connection failure. For example, the root cause analysis may identify improper LTM configuration parameters to be updated or corrected. When needed, the source DU 108a may adjust the LTM related mobility parameters to improve the robustness of LTM.

[0125] Fig. 6 illustrates an example diagram 600 of failure information delivery for connection reestablishment without RLF report, in accordance with aspects of this disclosure. As shown, the UE 102 detects 401a an RLF and transmits 410 a reestablishment request to the third network entity 104c, similar to operations 401a and 410 of Fig. 5. The third network entity 104c transmits 603 a failure indication to the CU 110, similar to operation 503 of Fig. 5. If the CU 110 determines that the DU to which the source cell belongs should be responsible for the LTM RLF, the CU 110 then sends 605 a failure message to the source DU 108a, which performs 604 the UE verification based on the shortMAC-I. The source DU 108a may perform 606 root cause analysis for the LTM connection failure. For example, the root cause analysis may identify improper LTM configuration parameters to be updated or corrected. When needed, the source DU 108a may adjust the LTM related mobility parameters to improve the robustness of LTM.

[0126] In some embodiments, the CU 110 forwards, via the failure message, failure information and reestablishment information to the source DU 108a to which the source cell belongs, similar to the operation 505 of Fig. 5. For example, the failure information includes at least one off failure cell information, failure C-RNTI, shortMAC-I, UE F 1AP ID between the CU and the source DU, LTM failure type information, mobility type, LTM related mobility information, or the like.

[0127] The DU 108a verifies 604 the UE based on the shortMAC-I. For example, when the DU 108a receives the failure information and reestablishment cell information, the DU 108a selects the UE context that matches the received failure cell information and failure C-RNTI. If the UE context is available, the DU uses the shortMAC-I to confirm this identification, by calculating a shortMAC-I and comparing it to the received one.

[0128] For LTM-too-early cases or LTM to wrong cell cases, a CU may deliver failure information and reestablishment information to a DU without RLF report when the RLF occurs shortly in target cell after a successful LTM procedure. For example, after detecting RLF, the UE 102 may perform reestablishment without providing an RLF report. Either the CU (e.g., Fig. 7) or the DU (e.g., Fig. 8) may perform UE verification. Based on the failure information (and other information therein, such as reestablishment information) , the DU may optimize the LTM parameters to improve the robustness of the LTM procedure.

[0129] Fig. 7 illustrates an example diagram 700 of failure information delivery for connection reestablishment without RLF report, in accordance with aspects of this disclosure. As shown, the UE 102 detects 401a an RLF and transmits 410 a reestablishment request to the third network entity 104c, similar to operations 401a and 410 of Fig. 5. In this embodiment, the UE 102 provides the failure C-RNTI and failure cell information related to the ones of the failure cell (the target cell of the LTM procedure) .

[0130] The third network entity 104c transmits 703 a failure indication to the CU 110, similar to operation 503 of Fig. 5. Having obtained the failure indication, the CU 110 verifies 704 the UE 102 based on shortMAC-I.

[0131] If the CU 110 determines that the DU 108a to which the source cell belongs should be responsible for the LTM RLF, the CU 110 then sends 705 a failure message to the source DU 108a, similar to operation 505 of Fig. 5. In the failure message, the CU 110 optionally forwards failure information and reestablishment information to the DU 108a, to which the source cell belongs. The failure information includes at least one of: failure cell information, failure C-RNTI, UE F1AP ID between the CU and the source DU, LTM failure type information, mobility type, source cell information, source C-RNTI, or the like.

[0132] The failure cell information and C-RNTI are set to the ones related to the target cell, provided in the reestablishment procedure from the UE or derived by the third network entity based on the UE identity information provided by the UE. To assist the source DU 108a to identify the UE 102, the CU 110 may provide to the source DU 108a the source cell information, and / or source C-RNTI or UE F1AP ID between the CU 110 and the source DU 108a.

[0133] The source DU 108a may perform 706 root cause analysis for the LTM connection failure. For example, the root cause analysis may identify improper LTM configuration parameters to be updated or corrected. When needed, the source DU 108a may adjust the LTM related mobility parameters to improve the robustness of LTM.

[0134] Fig. 8 illustrates an example diagram 800 of failure information delivery for connection reestablishment without RLF report, in accordance with aspects of this disclosure. As shown, the UE 102 detects 401a an RLF and transmits 410 a reestablishment request to the third network entity 104c, similar to operations 401a and 410 of Fig. 5. The third network entity 104c transmits 803 a failure indication to the CU 110, similar to operation 503 of Fig. 5.

[0135] If the CU 110 determines that the DU 108a to which the source cell belongs should be responsible for the LTM RLF, the CU 110 then sends 805 a failure message to the target DU 108b for UE verification. The failure information includes at least one of: failure cell information, failure C-RNTI, UE F1AP ID between the CU and the target DU, shortMAC-I, or the like. The failure cell information and C-RNTI are set to the ones related to the target cell, provided in the reestablishment procedure from the UE or derived by the third network entity based on the UE identity information provided by the UE. The reestablishment information includes at least one of: reestablishment cell information, or the like.

[0136] The target DU 108b verifies 804 the UE based on shortMAC-I. The target DU 108b sends 816 the UE verification result information to the CU 110. The verification result information can be used to indicate whether the target DU 108b has successfully verified the UE 102. If the verification result information indicates that the UE is successfully verified, the CU 110 transmits 818 a failure message to the source DU 108a, similar to the operation 705 of Fig. 7. The source DU 108a may perform 806 root cause analysis based on the failure message.

[0137] For LTM cell switch failure or HOF cases (either due to LTM-too-early or LTM to wrong cell) , a CU may deliver failure information and reestablishment information to a DU without RLF report if the LTM HOF occurs during an LTM procedure. For example, after detecting 401b LTM HOF, the UE 102 may perform reestablishment without providing an RLF report. Either the CU 110 (e.g., Fig. 9) or the source DU 108a (e.g., Fig. 10) may perform UE verification. Based on the failure information (and other information therein, such as reestablishment information) , the source DU 108a may optimize the LTM parameters to improve the robustness of the LTM procedure.

[0138] Fig. 9 illustrates an example diagram 900 of failure information delivery for connection reestablishment without RLF report, in accordance with aspects of this disclosure. As shown, the UE 102 detects 401b an LTM HOF with respect to the target DU 108b. The UE 102 then transmits 410 a reestablishment request to the third network entity 104c, similar to the operation 410 of Fig. 5. In the reestablishment request, the UE 102 provides the failure C-RNTI and failure cell information related to the ones of the source cell. The third network entity 104c transmits 903 a failure indication to the CU 110, similar to operation 503 of Fig. 5. The CU 110 verifies 904 the UE based on shortMAC-I included in the failure indication, similar to operation 704 of Fig. 7.

[0139] If the CU 110 determines that the DU 108a to which the source cell belongs should be responsible for the LTM HOF, the CU 110 then sends 905 a failure message to the source DU 108a (or the DU to which the source cell belongs) , similar to the operation 505 of Fig. 5. The failure information includes at least one of: failure cell information, failure C-RNTI, target cell information, target C-RNTI, UE F1AP ID between the CU and the source DU, LTM failure type information, mobility type, LTM related mobility information, or the like.

[0140] The DU 108a may use target cell information to perform 906 the root cause analysis and identify improvement or correction measures of the LTM decision to the target cell 108b.

[0141] Fig. 10 illustrates an example diagram 1000 of failure information delivery for connection reestablishment without RLF report, in accordance with aspects of this disclosure. As shown, the UE 102 detects 401b an LTM HOF with respect to the target DU 108b. The UE 102 then transmits 410 a reestablishment request to the third network entity 104c, similar to the operation 410 of Fig. 5. In the reestablishment request, the UE 102 provides the failure C-RNTI and failure cell information related to the ones of the source cell. The third network entity 104c transmits 1003 a failure indication to the CU 110, similar to operation 503 of Fig. 5.

[0142] If the CU 110 determines that the DU 108a to which the source cell belongs should be responsible for the LTM HOF, the CU 110 then sends 1005 a failure message to the source DU 108a (or the DU to which the source cell belongs) , similar to the operation 505 of Fig. 5. The failure information includes at least one of: failure cell information, failure C-RNTI, shortMAC-I, target cell information, target C-RNTI, UE F1AP ID between the CU and the source DU, LTM failure type information, mobility type, LTM related mobility information, or the like.

[0143] The source DU 108a may optionally verify 1004 the UE based on the shortMAC-I in the failure message. The DU 108a may perform 1006 the root cause analysis and identify improvement or correction measures of the LTM decision to the target DU 108b.

[0144] For cases when RLF report is available, a CU may also deliver failure information and / or reestablishment information to a DU. For example, after detecting RLF, the UE 102 may provide an RLF report. The CU may provide different failure information to DUs (e.g., the source C-RNTI in Fig. 11, compared to the target C-RNTI in Fig. 12) . The content of failure information and / or reestablishment information from the CU 110 CU to the DU 108a or 108b may be for failure cause analysis. The DU 108a or 108b may thus optimize the sub-optimal LTM parameters and / or improve the robustness of the LTM procedure.

[0145] Fig. 11 illustrates an example diagram 1100 of failure information delivery from a CU 110 to a source DU 108a when an RLF report is available, in accordance with aspects of this disclosure. As shown, the UE 102 detects 301 a connection failure (e.g., RLF) during an LTM procedure. The UE 102 then generates 302 an RLF report. The UE 102 transmits 1103 the RLF report to the CU 110. In some cases, the CU 110 may retrieve the RLF report from the UE 102, from the third network 104c (as shown in Fig. 3 but not in Fig. 11) , or from the core network (CN) (not shown) .

[0146] The CU 110 determines 1114 what type of failure the RLF report is for (e.g., whether the RLF report is for RLF of LTM-too-early or LTM to wrong cell) . For example, based on the retrieved RLF report, or the retrieved RLF report and failure information from the third network 104c or from the core network (CN) , the CU 110 may determine the LTM failure type and connection failure type. For example, the CU can determine whether the RLF report is for the RLF in LTM-too-early or LTM to wrong cell cases.

[0147] If the CU 110 determines that the RLF report is for the RLF in LTM-too-early or LTM to wrong cell cases, the CU 110 transmits 1105 the RLF report with other failure information to the source DU 108a. The other failure information includes at least a source C-RNTI. The source C-RNTI may be used for the source DU to retrieve the stored UE context at source DU. Consequently, the source DU can identify the failure cause and optimize the related LTM parameters if needed. In some embodiments, the CU 110 may provide to the DU 108a at least one of the following: the LTM failure type information, mobility type, LTM related mobility information, or the like.

[0148] Fig. 12 illustrates an example diagram 1200 of failure information delivery from a CU 110 to a source DU 108a when an RLF report is available, in accordance with aspects of this disclosure. As shown, the UE 102 detects 301 a connection failure (e.g., RLF) during an LTM procedure. The UE 102 then generates 302 an RLF report. The UE 102 transmits 1203 the RLF report to the CU 110. In some cases, the CU 110 may retrieve the RLF report from the UE 102, from the third network 104c (as shown in Fig. 3 but not in Fig. 12) , or from the core network (CN) (not shown) .

[0149] The CU 110 determines 1214 whether the RLF report should be delivered to the target DU 108b. For example, based on the retrieved RLF report, or the retrieved RLF report and failure information from the third network 104c or from the core network (CN) , the CU can determine the LTM failure type, connection failure type and the presence / absence of the random access information in the RLF report. For example, the CU can determine whether there is random access information in RLF report, and / or whether the RLF report is for the HOF in LTM-too-early or LTM to wrong cell cases.

[0150] If the CU 110 determines 1214 that there is random access information in the RLF report and / or the RLF report is for the LTM HOF in LTM-too-early or LTM to wrong cell cases, the CU transmits 1215 the RLF report with other failure information to the target DU 108b. The other failure information includes at least the target C-RNTI. The target C-RNTI may be used for the target DU 108b to retrieve the stored UE context at the target DU 108b. Consequently, the target DU 108b can identify suboptimal random access related configuration and optimize the related random access configuration parameters if needed.

[0151] The operations in Fig. 12 may be implemented separately or combined with part or all operations in other figure (s) . For example, the operations in Fig. 12 can be implemented together with the step (s) of failure message from CU 110 to the source DU 108a illustrated in other figure (s) , such as in Fig. 11. In this implementation, there is no limitation on the order of the step from the CU 110 to the target DU 108b and / or the operations from the CU 110 to the source DU 108a.

[0152] For cases the UE performs successful LTM recovery procedure without RLF report, a CU may deliver failure information and recovery information to a DU. The recovery information may include LTM recovery cell information. For example, when the CU 110 decides that a DU 108 should be responsible for the LTM connection failure during LTM procedure, the CU 110 may transmit failure information and recovery information to the DU 108 (similar to operations illustrated in Figs. 5-10) . Figs. 13 illustrates an intra-CU LTM case for example. For intra-CU LTM, all the LTM candidate cells are controlled or managed by the same CU. When connection failure occurs during LTM procedure, the UE performs LTM recovery with the selected LTM candidate cell which is managed by the CU. Other network architecture may also use the illustrated failure information delivery. For cases where the UE performs successful LTM recovery procedure without RLF report, the failure information may further include connection failure type, e.g., HOF or RLF. The connection failure type can be determined at CU side which manages the source DU and / or target DU. The detection or determination of the LTM failure type at CU side may refer to the examples described above for the reestablishment case without RLF report.

[0153] Fig. 13 illustrates an example diagram 1300 of failure information and recovery information delivery for LTM recovery without RLF report, in accordance with aspects of this disclosure. As shown, the UE 102 detects 301 a connection failure with respect to an LTM recovery cell 104d. The UE 102 then performs 1330 LTM recovery with the LTM recovery cell 104d. For example, the network entity configures the indicator associated with the selected LTM candidate cell. The indicator is used to indicate whether the LTM recovery or LTM attempt procedure can be applied for the associated LTM candidate cell. When the UE 102 selects this kind of LTM candidate cell (e.g., cell 104d) , the UE performs LTM recovery procedure. In some cases, the UE 102 may send the RRC Reconfiguration Complete message to the network entity as the implementation of LTM recovery procedure.

[0154] In this example, the source cell may be referred to as cell 1 (belonging to DU 108a) , the target cell as cell 2 (belonging to DU 108b) and LTM recovery cell as cell 3 (belonging to cell / DU 104d) . The DU 108a, DU 108b, and the cell 104d may be different cells or the same cell.

[0155] The LTM recovery cell 104d (e.g., a DU that manages the LTM recovery cell, also referred to as a recovery DU) transmits 1303 LTM recovery information to the CU 110. The LTM recovery information is used to indicate that the UE has successfully accessed through the current access cell (e.g., cell 104d) . The LTM recovery information may also indicate the current access cell information where the UE has successfully accessed, or indicate the candidate cell for LTM included in LTM candidate cell configuration that the UE selected for LTM based recovery while T311 is running. In addition, the LTM recovery information may include the UE F1AP ID between the CU and the recovery DU. The LTM recovery information may be included in ACCESS SUCCESS message or other F1 messages.

[0156] When the CU 110 receives the LTM recovery information, the CU 110 determines the LTM failure type. The CU 110 transmits failure information and recovery information to the source DU 108a or the target DU 108b. The CU 110 may determine the LTM failure type according to the following examples.

[0157] If the source DU (e.g., DU 108a) does not provide the target cell information to CU 110 before the reception of the LTM recovery information from the recovery DU (e.g., the recovery cell 104d) , the CU determines 1304 that the source DU has not provided LTM cell switch command before the RLF (e.g., when the connection failure type is RLF) ; and if the CU 110 determines that the UE stayed in the source DU 108a for a long time or there is no recent LTM procedure to the source DU 108a, e.g., the NW-side timer is absent or having a value larger than the configured threshold (e.g., Tstore_UE_cntxt) , the CU 110 determines 1304 the LTM failure type as LTM-too-late. The description of the NW-side timer can refer to the previous examples. The details are not provided herein.

[0158] If the source DU (e.g., DU 108a) provides the target cell information to the CU 110 and the CU 110 has not received the UE access information from the target cell (e.g., DU 108b) before the reception of the LTM recovery information from the recovery DU (e.g., recovery cell 104d) , the CU determines that LTM HOF occurred. That is, the connection failure type is RLF. The UE access information is used to inform the CU 110 of which cell the UE has successfully accessed during LTM. If the LTM recovery cell is the same as the source one, the failure type (e.g., including LTM failure type and connection failure type) is LTM-too-early with HOF (e.g., LTM failure type is LTM-too-early, connection failure type is HOF) . If the LTM recovery cell is different from the source one, the failure type is LTM to wrong cell with HOF.

[0159] If the source DU (e.g., DU 108a) provides the target cell information to the CU 110 and the CU 110 receives the UE access information from the target cell (e.g., DU 108b) before the reception of the LTM recovery information from the recovery DU (e.g., the recovery cell 104d) , the CU 110 determines that RLF occurred in target cell. That is, the connection failure type is RLF. If the stay time at the target cell is short, e.g., the NW-side timer has a value smaller than the configured threshold (e.g., Tstore_UE_cntxt) , and if the LTM recovery cell is the same as the source one, the failure type is LTM-too-early with RLF. If the stay time at the target cell is short, e.g., the NW-side timer having a value smaller than the configured threshold (e.g., Tstore_UE_cntxt) , and if the LTM recovery cell is different from the source one, the failure type is LTM to wrong cell with RLF. The description of the NW-side timer can refer to the previous examples. The details are not provided herein.

[0160] If the CU 110 determines that the DU 108 should be responsible for the LTM connection failure, the CU 110 sends failure information and recovery cell information to the DU 108. The failure information may further include connection failure type, e.g., HOF or RLF. Here, the DU can be the source DU 108a and / or the target DU 108b. The interaction between the CU 110 and the DU 108 refer to the operations in Figs. 5-10. Similarly, the failure information to be included in the communication may also refer to the discussion in Figs. 5-10. The CU 110 also transmits 1305 recovery cell information to the DU 108 to indicate the recovery cell 104d.

[0161] For cases on inter-CU failure information delivery, a CU may send failure report information as LTM MRO.

[0162] Fig. 14 illustrates an example diagram 1400 of inter-CU failure information delivery, in accordance with aspects of this disclosure. As shown, a reception CU 110a transmits 1403 a failure notification to the failure CU 110b. The reception CU 110a refers to the CU that manages the reestablishment cell, LTM recovery cell, or the one retrieves RLF report from the UE. The failure CU 110b refers to the one that manages the failure cell. The failure cell refers to the one where RLF was detected during LTM procedure, or the source cell if LTM HOF was detected during LTM procedure. The failure notification information from the reception CU 110a to the failure CU 110b can include at least one of the following: the failure information, failure information and reestablishment information, failure information and recovery cell information, or an RLF report. If the reception CU 110a is the one that manages LTM recovery cell, the reception CU may additionally include the UE Xn AP ID between the reception CU and failure CU.

[0163] The failure CU 110b transmits 1405 failure report information to the responsible CU 110c. If the failure CU 110b determines that the failure CU 110b is not the one responsible for the LTM connection failure, the failure CU 110b may send or forward 1302 the failure report information to the CU 110c responsible for the LTM connection failure. The CU 110c responsible for the LTM connection failure is the CU that manages the responsible DU for the LTM connection failure. The failure report information can include at least one of the following: the LTM cause, failure information, RLF report, reestablishment cell information or LTM recovery cell information, or the like. The descriptions of the information are discussed in the previous embodiments of Figs. 5-12.

[0164] Fig. 14 illustrates the interaction (s) between CUs 110a-110c are over the Xn interface (one illustration of the interface between RAN network entities) . In another embodiments, the interaction (s) can be over interface between a RAN network entity and a core network (CN) network entity, e.g., NG / S1 interface, if there is no direct Xn connectivity between the related CUs 110a-c. For example, the reception CU can send the failure notification information to the CN network entity 1, e.g., via Uplink RAN configuration transfer procedure. The CN network entity 1 is the one managing the reception CU. The CN network entity 2 transfers the failure notification information to the failure CU, e.g., via Downlink RAN configuration transfer procedure. The CN network entity 2 is the one managing the failure CU. If the CN network entity 2 is different from the CN network entity 1, there is additional interaction from CN network entity 1 to CN network entity 2 to deliver the failure notification information. Similar procedures can also be introduced for the delivery of failure report information if there is no direct Xn connectivity between failure CU and responsible CU. It is understood that the interface names are merely exemplary and illustrative but not limited for other implementation (s) .

[0165] In some cases, there may be interaction (s) between the failure CU 110b and the responsible DU 108 within the failure CU 110b, or between the responsible CU 110c and the responsible DU 108 within the responsible CU 110c.

[0166] Referring to Figs. 5-14 collectively, example content for the failure message in the operations 505, 605, 705, 805, 905, 1005, 1105, 1205, 1305, and 1405 may include the partial example information listed in Table 1 below. Table 1: illustration of the contents in the failure message from gNB-CU to gNB-DU

[0167] Fig. 15 illustrates an example flowchart of a method 1500 performed by a central unit (CU) , in accordance with aspects of this disclosure. With reference to Figs. 1, 3-14, and 22, the method 1500 may be performed by the CU 110 of the network entity 104, which may correspond to a base station or a unit of the base station, such as the RU 106, the DU 108, the CU 110, an RU processor 2206, a DU processor 2226, a CU processor 2246, etc. The one or more network entities 104 may include memory 2206’ / 2226’ / 2246’, which may correspond to an entirety of the one or more network entities 104, or a component of the one or more network entities 104, such as the RU processor 2206, the DU processor 2226, or the CU processor 2246.

[0168] As shown in Fig. 15, the CU of the network entity obtains 1503 a failure indication for a connection failure event of an LTM procedure (similar to operation 503 of Fig. 5, operation 603 of Fig. 6, operation 703 of Fig. 7, etc. ) . In one example, obtaining the failure indication may include receiving the failure indication from a network entity (e.g., the third network entity 104c in Figs. 5-10) . In another example, obtaining the failure indication may include the CU determining a DU responsible for a connection failure event of an LTM procedure.

[0169] The CU of the network entity transmits 1505, to a DU, failure information based on the failure indication (similar to operation 505 of Fig. 5, operation 605 of Fig. 6, operation 705 of Fig. 7, etc. ) . For example, the failure information may include at least one of: UE identifier information associated with the connection failure event, or reestablishment or recovery information associated with the connection failure event.

[0170] Fig. 16 illustrates an example flowchart of a method 1600 performed by the CU on obtaining a failure indication, in accordance with aspects of this disclosure. As shown, the CU may receive 1603a, from a recovery network entity, LTM recovery information indicating at least one of: an indication that the UE has successfully accessed a current access cell; current access cell information, or a candidate target cell included in an LTM candidate cell configuration.

[0171] The CU may receive 1603b an RLF report generated by the UE (similar to operations 1103 of Fig. 11, 1203 of Fig. 12, etc. ) . For example, the RLF report may include at least one of: LTM failure cause, timestamp and location, serving cell and target cell information, measurement reports, timing advance values, cell switch configuration parameters, reestablishment attempts, L1 and L2 failure details, or mobility history.

[0172] Fig. 17 illustrates an example flowchart of a method 1700 performed by the CU based on received failure indication, in accordance with aspects of this disclosure. As shown, the CU may select 1721 a UE context matching the failure indication based on a C-RNTI. The CU verifies 1704 an identification of the UE based on a shortMAC-I calculated using the UE context. The CU generates 1722 the failure information including at least one of: identifier information (e.g., C-RNTI, shortMAC-I, etc. ) associated with the connection failure event, or reestablishment or recovery information associated with the connection failure event.

[0173] Fig. 18 illustrates an example flowchart of a method 1800 performed by the CU on determining a failure type of the LTM, in accordance with aspects of this disclosure. As shown, the CU determines 1814, based on the received LTM recovery information, a failure type of the LTM procedure (similar to operations 1114 of Fig. 11, 1214 of Fig. 12, 1314 of Fig. 13, etc. ) .

[0174] The CU transmits 1805 the failure type and the LTM recovery information to at least one off a source DU or a target DU associated with the connection failure event of the LTM procedure (similar to operations 1105 of Fig. 11, 1205 of Fig. 12, 1305 of Fig. 13, etc. ) .

[0175] Fig. 19 illustrates an example flowchart of a method 1900 performed by the CU in an inter-CU situation, in accordance with aspects of this disclosure. As shown, the CU receives 1903, from a second CU or a core network, a failure indication for a connection failure event of an LTM procedure (similar to operation 1403 of Fig. 14) .

[0176] The CU transmits 1905, to a third CU or a DU, failure information based on the failure indication (similar to operation 1405 of Fig. 14) .

[0177] Collectively referring to Figs. 15-19, in aspects, the failure information includes at least one of: failure cell information; failure C-RNTI information; the shortMAC-I; UE application protocol (AP) identifier (ID) on an Fl interface between the CU and a target DU; mobility type; LTM failure type; LTM related mobility information; reestablishment cell information; or reestablishment cause.

[0178] In aspects, the failure information is transmitted to a source DU (similar to the operation 505 of Fig. 5 or the operation 605 of Fig. 6) .

[0179] In aspects, the failure cell information and the failure C-RNTI information are related to a target DU.

[0180] In some cases, the failure information further includes at least one of: a source C-RNTI or source cell information (similar to the operation 1105 of Fig. 11) .

[0181] In some cases, the failure information is transmitted to a target DU (similar to the operation 805 of Fig. 8) .

[0182] In aspects, transmitting the failure information includes transmitting the RLF report to a proper DU based on a failure type of the LTM procedure. In some cases, the proper DU includes at least one of: a failure DU when the failure type is an LTM-too-late; a source DU when the failure type is an LTM-too-early, a source DU when the failure type is an LTM to a wrong cell, or a target DU when the failure type is for an LTM-cell-switch and the RLF report includes random access information.

[0183] In some embodiments, the CU forwards the RLF report to the correct DU based on LTM failure type. The LTM failure type may include: the failure DU in case of too late LTM (or LTM-too-late) , the source DU in case of too early LTM (or LTM-too-early) , or LTM to wrong cell. The target DU ifrandom access information exists in RLF report for LTM HOF cases. The receiving DU can then perform a root cause analysis based on the RLF report and the LTM failure type. By addressing the issues, the DU can optimize LTM trigger parameters and enhance the robustness of LTM.

[0184] In some embodiments, a DU performs root cause analysis to optimize the LTM trigger related parameters.

[0185] In some embodiments, the CU forwards the source C-RNTI to the source DU, ifthe connection Failure type IE in RLF report is set to “RLF; ” and ifRLF Report Failure Type IE is set to value “too early LTM” or “LTM to wrong cell. ” For example, the CU will forward the RLF report to target DU in case of random access information existing for LTM HOF cases. The UE may provide the source C-RNTI in RLF report for LTM HOF cases.

[0186] To assist the target DU to identify the UE and retrieve UE context at target DU, it is beneficial for CU to provide target C-RNTI alongside RLF report to the target DU.

[0187] In some embodiments, The CU forwards the target C-RNTI to the target DU if there is random access information for HOF in RLF report.

[0188] In some embodiments, for reestablishment without RLF report, the CU should forward additional information to source DU if the failure is not due to wrong selection of prepared LTM cell. For reestablishment case without RLF report in existing MRO scheme, the node receiving the reestablishment request may initiate a failure indication to the failure node where the connection failure was detected. Correspondingly, the failure node performs UE verification and perform a thorough analysis of the failure.

[0189] In some embodiments, for reestablishment without RLF report, the CU forwards to the source DU at least one of the following additional information: source cell information; source C-RNTI; target cell information in case of too early LTM or LTM to wrong cell; reestablishment cell information; or LTM failure type.

[0190] Fig. 20 illustrates an example flowchart of communication method 2000 by a DU, in accordance with aspects of this disclosure. As shown, a DU receives 2005 from a CU, failure information for a connection failure event of an LTM procedure (similar to respective operations 505-1005 of Figs. 5-10) . The DU performs 2006 at least one of: a cause analysis based on the failure information, or a user equipment, UE, verification procedure based on the failure information (similar to respective operations 506-1006 of Figs. 5-10) .

[0191] Fig. 21 is a diagram 2100 illustrating an example of a hardware implementation for a UE apparatus 2102. The UE apparatus 2102 may be the UE 102, a component of the UE 102, or may implement UE functionality. The UE apparatus 2102 may include an application processor 2106, which may have on-chip memory 2106’. In examples, the application processor 2106 may be coupled to a secure digital card 2108 and / or a display 2110. The application processor 2106 may also be coupled to a sensor (s) module 2112, a power supply 2114, an additional module of memory 2116, a camera 2118, and / or other related components. For example, the sensor (s) module 2112 may control a barometric pressure sensor / altimeter, a motion sensor such as an inertial management unit (IMU) , a gyroscope, accelerometer (s) , a light detection and ranging (LIDAR) device, a radio-assisted detection and ranging (RADAR) device, a sound navigation and ranging (SONAR) device, a magnetometer, an audio device, and / or other technologies used for positioning.

[0192] The UE apparatus 2102 may further include a wireless baseband processor 2126, which may be referred to as a modem. The wireless baseband processor 2126 may have on-chip memory 2126′. Along with, and similar to, the application processor 2106, the wireless baseband processor 2126 may also be coupled to the sensor (s) module 2112, the power supply 2114, the additional module of memory 2116, the camera 2118, and / or other related components. The wireless baseband processor 2126 may be additionally coupled to one or more subscriber identity module (SIM) card (s) 2120 and / or one or more transceivers 2130 (e.g., wireless RF transceivers) .

[0193] Within the one or more transceivers 2130, the UE apparatus 2102 may include a Bluetooth module 2132, a WLAN module 2134, an SPS module 2136 (e.g., GNSS module) , and / or a cellular module 2138. The Bluetooth module 2132, the WLAN module 2134, the SPS module 2136, and the cellular module 2138 may each include an on-chip transceiver (TRX) , or in some cases, just a transmitter (TX) or just a receiver (RX) . The Bluetooth module 2132, the WLAN module 2134, the SPS module 2136, and the cellular module 2138 may each include dedicated antennas and / or utilize antennas 2140 for communication with one or more other nodes. For example, the UE apparatus 2102 may communicate through the transceiver (s) 2130 via the antennas 2140 with another UE 102 (e.g., sidelink communication) and / or with a network entity 104 (e.g., uplink / downlink communication) , where the network entity 104 may correspond to a base station or a unit of the base station, such as the RU 106, the DU 108, or the CU 110.

[0194] The wireless baseband processor 2126 and the application processor 2106 may each include a computer-readable medium / memory 2126′, 2106′, respectively. The additional module of memory 2116 may also be considered a computer-readable medium / memory. Each computer-readable medium / memory 2126′, 2106′, 2116 may be non-transitory. The wireless baseband processor 2126 and the application processor 2106 may each be responsible for general processing, including execution of software stored on the computer-readable medium / memory 2126′, 2106′, 2116. The software, when executed by the wireless baseband processor 2126 / application processor 2106, causes the wireless baseband processor 2126 / application processor 2106 to perform the various functions described herein. The computer-readable medium  / memory may also be used for storing data that is manipulated by the wireless baseband processor 2126 / application processor 2106 when executing the software. The wireless baseband processor 2126 / application processor 2106 may be a component of the UE 102. The UE apparatus 2102 may be a processor chip (e.g., modem and / or application) and include just the wireless baseband processor 2126 and / or the application processor 2106. In other examples, the UE apparatus 2102 may be the entire UE 102 and include the additional modules of the apparatus 2102.

[0195] As discussed in Fig. 1 and implemented with respect to Figs. 3 through 13, the LTM failure report component 140 of the UE 102 reports RLF or LTM HOF to the network entity 104 (e.g., to the CU 110) . The LTM failure report component 140 may detect an RLF or LTM HOF, and generate an RLF report. The LTM failure report component 140 may send 410 reestablishment requests, RLF reports, or LTM recovery requests according to the corresponding operations in Figs. 3-13.

[0196] The LTM failure report component 140 may be within the application processor 2106 (e.g., at 140a) , the wireless baseband processor 2126 (e.g., at 140b) , or both the application processor 2106 and the wireless baseband processor 2126. The LTM failure report component 140a-140b may be one or more hardware components specifically configured to carry out the stated processes / algorithm, implemented by one or more processors configured to perform the stated processes / algorithm, stored within a computer-readable medium for implementation by the one or more processors, or a combination thereof.

[0197] Fig. 22 is a diagram 2200 illustrating an example of a hardware implementation for one or more network entities 104. The one or more network entities 104 may be a base station, a component of a base station, or may implement base station functionality. The one or more network entities 104 may include, or may correspond to, at least one of the RU 106, the DU 108, or the CU 110. The CU 110 may include a CU processor 2246, which may have on-chip memory 2246′. In some aspects, the CU 110 may further include an additional module of memory 2256 and / or a communications interface 2248, both of which may be coupled to the CU processor 2246. The CU 110 may communicate with the DU 108 through a midhaul link 162, such as an Fl interface between the communications interface 2248 of the CU 110 and a communications interface 2228 of the DU 108.

[0198] The DU 108 may include a DU processor 2226, which may have on-chip memory 2226′. In some aspects, the DU 108 may further include an additional module of memory 2236 and / or the communications interface 2228, both of which may be coupled to the DU processor 2226. The DU 108 may communicate with the RU 106 through a fronthaul link 160 between the communications interface 2228 of the DU 108 and a communications interface 2208 of the RU 106.

[0199] The RU 106 may include an RU processor 2206, which may have on-chip memory 2206′. In some aspects, the RU 106 may further include an additional module of memory 2216, the communications interface 2208, and one or more transceivers 2230, all of which may be coupled to the RU processor 2206. The RU 106 may further include antennas 2240, which may be coupled to the one or more transceivers 2230, such that the RU 106 may communicate through the one or more transceivers 2230 via the antennas 2240 with the UE 102.

[0200] The on-chip memory 2206′, 2226′, 2246′and the additional modules of memory 2216, 2236, 2256 may each be considered a computer-readable medium / memory. Each computer-readable medium / memory may be non-transitory. Each of the processors 2206, 2226, 2246 is responsible for general processing, including execution of software stored on the computer-readable medium / memory. The software, when executed by the corresponding processor (s) 2206, 2226, 2246 causes the processor (s) 2206, 2226, 2246 to perform the various functions described herein. The computer-readable medium  / memory may also be used for storing data that is manipulated by the processor (s) 2206, 2226, 2246 when executing the software. In examples, the failure information component 150 may sit at any of the one or more network entities 104, such as at the CU 110; both the CU 110 and the DU 108; each of the CU 110, the DU 108, and the RU 106; the DU 108; both the DU 108 and the RU 106; or the RU 106.

[0201] The failure information component 150 may perform various operations and signaling (such as the operations in Figs. 3-14) according to the examples provided herein and be within one or more processors of the one or more network entities 104, such as the RU processor 2206 (e.g., at 150a) , the DU processor 2226 (e.g., at 150b) , and / or the CU processor 2246 (e.g., at 150c) . As discussed in Fig. 1 and implemented with respect to Figs. 3 through 14, the failure information component 150 is configured to perform operations regarding LTM failures, with or without RLF report from the LTM failure report component 140 of the UE 104. For example, the failure information component 150 is configured to obtain (e.g., by the CU 110) a failure indication for a connection failure event of an LTM procedure and transmit, to a DU 108, failure information based on the failure indication. The failure information component 150 may also receive, by the DU 108 of the BS 104, from the CU 110, failure information for a connection failure event of a LTM procedure. The failure information component 150 may enable the DU 108 to perform at least one of: a cause analysis based on the failure information, or a UE verification procedure based on the failure information.

[0202] The failure information component 150a-150c may be one or more hardware components specifically configured to carry out the stated processes / algorithm, implemented by one or more processors 2206, 2226, 2246 configured to perform the stated processes / algorithm, stored within a computer-readable medium for implementation by the one or more processors 2206, 2226, 2246, or a combination thereof.

[0203] The specific order or hierarchy of blocks in the processes and flowcharts disclosed herein are an illustration of example approaches. Hence, the specific order or hierarchy of blocks in the processes and flowcharts may be rearranged. Some blocks may also be combined or deleted. Dashed lines may indicate example / optional elements of the diagrams. The accompanying method claims present elements of the various blocks in an example order, and are not limited to the specific order or hierarchy presented in the claims, processes, and flowcharts.

[0204] The detailed description set forth herein describes various configurations in connection with the drawings and does not represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough explanation of various concepts. However, these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

[0205] Aspects of wireless communication systems, such as telecommunication systems, are presented with reference to various apparatuses and methods. These apparatuses and methods are described in the following detailed description and are illustrated in the accompanying drawings by various blocks, components, circuits, processes, call flows, systems, algorithms, etc. (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, or combinations thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

[0206] An element, or any portion of an element, or any combination of elements may be implemented as a “processing system” that includes one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs) , central processing units, application processors, digital signal processors (DSPs) , reduced instruction set computing (RISC) processors, systems-on-chip (SoC) , baseband processors, field programmable gate arrays (FPGAs) , programmable logic devices (PLDs) , state machines, gated logic, discrete hardware circuits, and other similar hardware configured to perform the various functionality described throughout this disclosure. One or more processors in the processing system may execute software, which may be referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Software may be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, or any combination thereof.

[0207] If the functionality described herein is implemented in software, the functions may be stored on, or encoded as, one or more instructions or code on a computer-readable medium, such as a non-transitory computer-readable storage medium. Computer-readable media includes computer storage media and may include a random-access memory (RAM) , a read-only memory (ROM) , an electrically erasable programmable ROM (EEPROM) , optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of these types of computer-readable media, or any other medium that may be used to store computer executable code in the form of instructions or data structures that may be accessed by a computer. Storage media may be any available media that may be accessed by a computer.

[0208] Aspects, implementations, and / or use cases described herein may be implemented across many differing platform types, devices, systems, shapes, sizes, and packaging arrangements. For example, the aspects, implementations, and / or use cases may come about via integrated chip implementations and other non-module-component based devices, such as end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail / purchasing devices, medical devices, artificial intelligence (AI) -enabled devices, machine learning (ML) -enabled devices, etc. The aspects, implementations, and / or use cases may range from chip-level or modular components to non-modular or non-chip-level implementations, and further to aggregate, distributed, or original equipment manufacturer (OEM) devices or systems incorporating one or more techniques described herein.

[0209] Devices incorporating the aspects and features described herein may also include additional components and features for the implementation and practice of the claimed and described aspects and features. For example, transmission and reception of wireless signals necessarily includes a number of components for analog and digital purposes, such as hardware components, antennas, RF-chains, power amplifiers, modulators, buffers, processor (s) , interleavers, adders / summers, etc. Techniques described herein may be practiced in a wide variety of devices, chip-level components, systems, distributed arrangements, aggregated or disaggregated components, end-user devices, etc., of varying configurations.

[0210] The description herein is provided to enable a person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not limited to the aspects described herein, but are to be interpreted in view of the full scope of the present disclosure consistent with the language of the claims.

[0211] Reference to an element in the singular does not mean “one and only one” unless specifically stated, but rather “one or more. ” Terms such as “if, ” “when, ” and “while” do not imply an immediate temporal relationship or reaction. That is, these phrases, e.g., “when, ” do not imply an immediate action in response to or during the occurrence of an action, but simply imply that if a condition is met then an action will occur, but without requiring a specific or immediate time constraint for the action to occur. The terms “may, ” “might, ” and “may, ” as used in this disclosure, often carry certain connotations. For example, “may” refers to a permissible feature that may or may not occur, “might” refers to a feature that probably occurs, and “may” refers to a capability (e.g., capable of) . The phrase “For example” often carries a similar connotation to “may” and, therefore, “may” is sometimes excluded from sentences that include “for example” or other similar phrases.

[0212] Unless specifically stated otherwise, the term “some” refers to one or more. Combinations such as “at least one of A, B, or C” or “one or more of A, B, or C” include any combination of A, B, and / or C, such as A and B, A and C, B and C, or A and B and C, and may include multiples of A, multiples of B, and / or multiples of C, or may include A only, B only, or C only. Sets may be interpreted as a set of elements where the elements number one or more.

[0213] Unless otherwise specifically indicated, ordinal terms such as “first” and “second” do not necessarily imply an order in time, sequence, numerical value, etc., but are used to distinguish between different instances of a term or phrase that follows each ordinal term. Reference numbers, as used in the specification and figures, are sometimes cross-referenced among drawings to denote same or similar features. A feature that is exactly the same in multiple drawings may be labeled with the same reference number in the multiple drawings. A feature that is similar among the multiple drawings, but not exactly the same, may be labeled with reference numbers that have different leading numbers, but have one or more of the same trailing numbers (e.g., 206, 306, 406, etc., may refer to similar features in the drawings) . Sometimes an “X” is used to universally denote multiple variations of a feature. For instance, “X06” may universally refer to all reference numbers that end in “06” (e.g., 206, 306, 406, etc. ) .

[0214] It is noted that throughout this disclosure, an expression of “X / Y” may include meaning of “X or Y” . It is noted that throughout this disclosure, an expression of “X / Y” may include meaning of “X and Y” . It is noted that throughout this disclosure, an expression of “X / Y” may include meaning of “X and / or Y” . It is noted that throughout this disclosure, an expression of “ (A) B” or “B (A) ” may include concept of “only B” . It is noted that throughout this disclosure, an expression of “ (A) B” or “B (A) ” may include concept of “A+B” or “B+A” .

[0215] It is noted that some or all of the foregoing or the following embodiments may be jointly combined or formed to be a new or another one embodiment.

[0216] It is noted that the foregoing or the following embodiments may be used to solve at least (but not limited to) the issue (s) or scenario (s) mentioned in this disclosure.

[0217] The following additional considerations may apply to the foregoing and the following discussions.

[0218] It is noted that any two or more than two of the foregoing or the following paragraphs, (sub) -bullets, points, actions, or claims described in each method / embodiment / implementation may be combined logically, reasonably, and properly to form a specific method.

[0219] It is noted that any sentence, paragraph, (sub) -bullet, point, action, or claim described in each of the foregoing or the following embodiment (s)  / implementations / concept (s) may be implemented independently and separately to form a specific method. Dependency, e.g., “based on, ” “more specifically, ” “where” or etc., in embodiment (s)  / implementations / concept (s) mentioned in this disclosure is just one example embodiment which would not restrict the specific method.

[0220] A user device in which the techniques of this disclosure may be implemented (e.g., the UE 102) may be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media-streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS) . Still further, the user device may operate as an interuet-of-things (IoT) device or a mobile-interuet device (MID) . Depending on the type, the user device may include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0221] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may be software modules (e.g., code stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC) ) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0222] When implemented in software, the techniques may be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software may be executed by one or more general-purpose processors or one or more special-purpose processors.

[0223] Structural and functional equivalents to elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are encompassed by the claims. The words “module, ” “mechanism, ” “element, ” “device, ” and the like may not be a substitute for the word “means. ” As such, no claim element is to be construed as a means plus function unless the element is expressly recited using the phrase “means for. ” As used herein, the phrase “based on” may not be construed as a reference to a closed set of information, one or more conditions, one or more factors, or the like. In other words, the phrase “based on A, ” where “A” may be information, a condition, a factor, or the like, may be construed as “based at least on A” unless specifically recited differently. Example Aspects

[0224] Example 1 is a method of wireless communications by a central unit, CU, of a base station, the method comprising: determining, a distributed unit, DU, responsible for a connection failure event of a lower-layer triggered mobility, LTM, procedure; and transmitting (1505 or 505-1405) , to a distributed unit, DU, failure information based on the failure indication.

[0225] Example 2 is a method of example 1, further comprising: obtaining at least one off user equipment, UE, identifier information associated with the connection failure event, reestablishment or recovery information associated with the connection failure event, failure information, or a radio link failure, RLF, report.

[0226] Example 3 is a method of example 2, further comprising: selecting a UE context matching the failure indication based on a cell radio network temporary identifier, C-RNTI; and verifying (404 or 505) an identification of the UE based on a shortened version of message authentication code-integrity, shortMAC-I, calculated using the UE context.

[0227] Example 4 is a method of any of examples 1-3, wherein the failure information comprises at least one of: failure cell information; failure C-RNTI information; source or target cell information; source or target C-RNTI information; the shortMAC-I; UE application protocol, AP, identifier, ID, on an Fl interface between the CU and a DU; mobility type; LTM failure type; LTM related mobility information. The reestablishment information comprises at least one of: reestablishment cell information; or reestablishment cause. The recovery information comprises recovery cell information. The RLF report comprises the information associated with the connection failure event generated at UE side.

[0228] Example 5 is a method of example 4, further comprising: receiving the LTM related mobility information from a DU.

[0229] Example 6 is a method of any of examples 1-5, wherein the failure information, or the failure information and reestablishment or recovery information, or failure information and RLF report is transmitted (505-705, 818, 905-1505) to a source DU or transmitted (805, 1005, 1205, 1305, 1505) to a target DU.

[0230] Example 7 is a method of example 1-6, further comprising: transmitting (1105) , the failure information and RLF report to a source DU, wherein when the RLF report is for the RLF in case of too early LTM or LTM to wrong cell, the failure information comprises at least a source C-RNTI.

[0231] Example 8 is a method of example 1-6, further comprising: transmitting (1205) , the failure information and RLF report to a target DU, wherein when there is random access information in the RLF report, and / or the RLF report is for the HOF in case of too early LTM or LTM to wrong cell, the failure information comprises at least a target C-RNTI.

[0232] Example 9 is a method of examples 1-8, wherein obtaining the UE identifier information and reestablishment information comprises at least one of: receiving (1103-1203) a reestablishment request from the UE; obtaining the recovery information and / or the RLF report from the UE; or obtaining from a third entity at least one of: the reestablishment or recovery information; the failure information; or a RLF report.

[0233] Example 10 is a method of any of examples 1-6, further comprises: receiving (1303) , from a recovery network entity, LTM recovery information indicating at least one off an indication that the UE has successfully accessed a current access cell; current access cell information, or a candidate target cell included in an LTM candidate cell configuration.

[0234] Example 11 is a method of any of examples 1-5, further comprising: receiving the UE access information from the target cell.

[0235] Example 12 is a method of examples 10 andl 1, further comprising: determining (1314) , based on the received LTM recovery information, a failure type of the LTM procedure. The failure type is determined based on a timer value of the network entity and a configured threshold for the timer value.

[0236] Example 13 is a method of example 12, further comprising at least one off determining (1314) the failure type of the LTM procedure as too late LTM if the CU did not receive the target cell information from the source cell before the reception of the LTM recovery information from the recovery DU and / or if the UE stayed in the source cell for a long time or there is no recent LTM procedure to the source cell before connection failure; determining (1314) the failure type of the LTM procedure as too early LTM with HOF if the CU received the target cell information from the source cell but not received the UE access information from the target cell, and if LTM recovery cell is the same as the source one; determining (1314) the failure type of the LTM procedure as LTM to wrong cell with HOF if the CU received the target cell information from the source cell but not received the UE access information from the target cell, and if LTM recovery cell is different from the source one; determining (1314) the failure type of the LTM procedure as too early LTM with RLF if the CU received the target cell information from the source cell and the UE access information from the target cell, and if LTM recovery cell is the same as the source one; or determining (1314) the failure type of the LTM procedure as LTM to wrong cell with RLF if the CU received the target cell information from the source cell and the UE access information from the target cell, and if LTM recovery cell is different from the source one.

[0237] Example 14 is a method of wireless communications by a central unit, CU, of a base station, the method comprising: obtaining (1503 or 503-1403) a failure indication for a connection failure event of a lower-layer triggered mobility, LTM, procedure; and transmitting (1505 or 505-1405) , to a distributed unit, DU, failure information based on the failure indication.

[0238] Example 15 is a method of example 14, further comprising: generating the failure information including at least one of: user equipment, UE, identifier information associated with the connection failure event, or reestablishment or recovery information associated with the connection failure event.

[0239] Example 16 is a method of example 15, wherein obtaining the failure indication comprises receiving (503-803) the failure indication from a network entity, and the method further comprising: selecting a UE context matching the failure indication based on a cell radio network temporary identifier, C-RNTI; and verifying (504, 704, 904) an identification of the UE based on a shortened version of message authentication code-integrity, shortMAC-I, calculated using the UE context.

[0240] Example 17 is a method of any of examples 14-16, wherein the failure information comprises at least one of: failure cell information; failure C-RNTI information; the shortMAC-I; UE application protocol, AP, identifier, ID, on an F 1 interface between the CU and a target DU; mobility type; LTM failure type; LTM related mobility information; reestablishment cell information; or reestablishment cause.

[0241] Example 18 is a method of any of examples 14-17, wherein the failure information is transmitted to a source DU.

[0242] Example 19 is a method of example 14-17, wherein the failure cell information and the failure C-RNTI information are related to a target DU.

[0243] Example 20 is a method of example 19, wherein the failure information further comprises at least one of: a source C-RNTI; or source cell information.

[0244] Example 21 is a method of example 19, wherein the failure information is transmitted to a DU.

[0245] Example 22 is a method of example 14, wherein obtaining the failure indication comprises: receiving (1103-1203) a radio link failure, RLF, report generated by the UE; and wherein transmitting the failure information comprises transmitting the RLF report to a proper DU based on a failure type of the LTM procedure.

[0246] Example 23 is a method of example 22, wherein the proper DU includes at least one of: a failure DU when the failure type is an LTM-too-late; a source DU when the failure type is an LTM-too-early, a source DU when the failure type is an LTM to a wrong cell, or a target DU when the failure type is for an LTM-cell-switch and the RLF report includes random access information.

[0247] Example 24 is a method of example 14 or 15, wherein obtaining the failure indication comprises: receiving (1303) , from a recovery network entity, LTM recovery information indicating at least one of: an indication that the UE has successfully accessed a current access cell; current access cell information, or a candidate target cell included in an LTM candidate cell configuration.

[0248] Example 25 is a method of example 24, further comprising: determining (1314) , based on the received LTM recovery information, a failure type of the LTM procedure, and wherein transmitting the failure information comprises transmitting (1305) the failure type and the LTM recovery information to at least one of: a source DU or a target DU associated with the connection failure event of the LTM procedure.

[0249] Example 26 is a method of any one of examples 14-25, further comprising: determining (1114) , by the CU, that the failure information is to be transmitted to the DU based on the RLF report and related causes of failure therein, the related causes of failure including at least one of: an LTM failure type, a connection failure type, or a presence of random access information.

[0250] Example 27 is a method of any one of examples 14-26, wherein the failure type of the connection failure event comprises at least one of: a source DU failing to provide an LTM cell switch command before the connection failure event; the first network entity failing to receive UE access information from a target cell before receiving the LTM recovery information from the recovery network entity; or the first network entity receiving the UE access information from the target cell before receiving the LTM recovery information from the recovery network entity and (a) the LTM recovery network entity is the same as the source DU or (b) a stay time at the target cell is below a threshold.

[0251] Example 28 is a method of wireless communication at a first central unit (CU) of a base station, the method comprising: receiving (1403) ) , from a second CU or a core network, a failure indication for a connection failure event of a lower-layer triggered mobility (LTM) procedure; and transmitting (1405) , to a third CU or a DU, failure information based on the failure indication.

[0252] Example 29 is a method of example 28, wherein the failure indication comprises at least one of: the failure information; failure information and reestablishment information; failure information and LTM recovery cell information; or a radio link failure, RLF, report.

[0253] Example 30 is a method of example 28, wherein the failure information comprises at least one of: a cause of an LTM reestablishment request; a radio link failure, RLF, report; reestablishment cell information; or an LTM recovery cell information.

[0254] Example 31 is a method of wireless communications by a distributed unit, DU, of a base station the method comprising: receiving (505-1405) , from a central unit, CU, failure information for a connection failure event of a lower-layer triggered mobility, LTM, procedure; and performing (506-1006) at least one of: a cause analysis based on the failure information, or a user equipment, UE, verification procedure based on the failure information.

[0255] Example 32 is a method of example 30, wherein the failure information comprises at least one off failure cell information; failure C-RNTI information; a shortened version of message authentication code-integrity, shortMAC-I; UE application protocol, AP, identifier, ID, on an Fl interface between the CU and a target DU; mobility type; LTM failure type; LTM related mobility information; reestablishment cell information; or reestablishment cause.

[0256] Example 33 is a method of example 31 or 32, wherein the DU is a source DU.

[0257] Example 34 is a method of example 31 or 32, wherein the DU is a target DU and wherein the failure cell information and the failure C-RNTI are related to the target DU.

[0258] Example 35 is an apparatus comprising: one or more radio frequency (RF) modems; a processor coupled to the one or more RF modems; and at least one memory storing executable instructions, the executable instructions to manipulate at least one of the processor or the one or more RF modems to perform the method of any of examples 1 to 34.

[0259] Example 36 is an apparatus for wireless communication for implementing a method as in any of Examples 1 to 34.

[0260] Example 37 is an apparatus for wireless communication including means for implementing a method as in any of Examples 1 to 34.

[0261] Example 38 is a non-transitory computer-readable medium storing computer executable code, the code when executed by a processor causes the processor to implement a method as in any of Examples 1 to 34.

[0262] Example 39 is a computer program product for implementing a method as in any of Examples 1 to 34.

Claims

1.A method of wireless communications by a central unit, CU (110) , of a base station (104) , the method comprising:obtaining (503) a failure indication for a connection failure event of a lower-layer triggered mobility, LTM, procedure; andtransmitting (505) , to a distributed unit, DU (108) , failure information based on the failure indication.2.The method of claim 1, further comprising:generating the failure information including at least one of:user equipment, UE (102) , identifier information associated with the connection failure event, orreestablishment or recovery information associated with the connection failure event.3.The method of claim 2, wherein obtaining the failure indication comprises receiving the failure indication from a network entity, and the method further comprising:selecting a UE context matching the failure indication based on a cell radio network temporary identifier, C-RNTI; andverifying (504) an identification of the UE based on a shortened version of message authentication code-integrity, shortMAC-I, calculated using the UE context.4.The method of any of claims 1-3, wherein the failure information comprises at least one of:failure cell information;failure C-RNTI information;the shortMAC-I;UE application protocol, AP, identifier, ID, on an F1 interface between the CU and a DU;mobility type;LTM failure type;LTM related mobility information;reestablishment cell information;reestablishment cause; orconnection failure type.5.The method of any of claims 1-4, wherein the failure information is transmitted to a source DU (108a) .6.The method of claim 1-4, wherein the failure cell information and the failure C-RNTI information are related to a target DU (108b) .7.The method of claim 6, wherein the failure information further comprises at least one of:a source C-RNTI; orsource cell information.8.The method of claim 6, wherein the failure information is transmitted to a target DU (108b) .9.The method of claim 1, wherein obtaining the failure indication comprises:receiving (1103) a radio link failure, RLF, report generated by the UE (102) , ordetermining the DU being responsible for the connection failure event; andwherein transmitting the failure information comprises transmitting (1105, 1205) the RLF report to a proper DU based on a failure type of the LTM procedure.10.The method of claim 9, wherein the proper DU includes at least one of:a failure DU when the failure type is an LTM-too-late;a source DU when the failure type is an LTM-too-early,a source DU when the failure type is an LTM to a wrong cell, ora target DU when the failure type is for an LTM-cell-switch and the RLF report includes random access information.11.The method of any of claims 1-2, wherein obtaining the failure indication comprises:receiving (1303) , from a recovery network entity, LTM recovery information indicating at least one offan indication that the UE has successfully accessed a current access cell;current access cell information, ora candidate target cell included in an LTM candidate cell configuration.12.The method of claim 11, further comprising:determining (1314) , based on the received LTM recovery information, a failure type of the LTM procedure, and wherein transmitting the failure information comprises transmitting (1305) the failure type and the LTM recovery information to at least one off a source DU (108a) or a target DU (108b) associated with the connection failure event of the LTM procedure.13.A method of wireless communications by a distributed unit, DU, (108) of a base station (104) the method comprising:receiving (505) , from a central unit, CU, (110) failure information for a connection failure event of a lower-layer triggered mobility, LTM, procedure; andperforming at least one of:a cause analysis (506) based on the failure information, ora user equipment, UE, verification procedure (604) based on the failure information.14.The method of claim 13, wherein the failure information comprises at least one of:failure cell information;failure cell radio network temporary identifier, C-RNTI, information;a shortened version of message authentication code-integrity, shortMAC-I;UE application protocol, AP, identifier, ID, on an F1 interface between the CU and a DU;mobility type;LTM failure type;LTM related mobility information;reestablishment cell information;reestablishment cause; orconnection failure type.15.An apparatus for wireless communication comprising a transceiver, a memory, and a processor coupled to the memory and the transceiver, the apparatus being configured to implement a method as in any of claims 1-14.

Images