Method to avoid beam failure shortly after mobility triggered at lower layers
Patent Information
- Application Number
- CN202610217978.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2025-02-17
- Filing Date
- 2026-02-23
- Publication Date
- 2026-08-18
Smart Images

Figure CN122602247A_ABST
Abstract
Description
Technical Field
[0001] The exemplary and non-limiting example embodiments generally relate to communication, and more specifically, to methods for avoiding beam failure shortly after mobility is triggered at a lower layer. Background Technology
[0002] Communication devices can gain access to a communication network by connecting to network nodes. Summary of the Invention
[0003] According to one aspect, an apparatus includes at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: determine, based on measurements received from a user equipment, to trigger a cell handover command for that user equipment; store measurements received from the user equipment and used for the cell handover decision; mark the stored measurements used for the cell handover decision using an identifier of the user equipment associated with a source cell; receive an indication that, after a successful handover to a target cell, the user equipment performed a beam failure recovery procedure due to beam failure of the beam used to connect to the target cell; wherein the received indication that the user equipment performed the beam failure recovery procedure after a successful handover to the target cell includes an indication of the user equipment's identifier, which is associated with the identifier used to mark the stored measurements; and perform a root cause analysis using the stored measurements marked with the identifier of the user equipment associated with the source cell to determine the root cause of the beam failure of the beam used to connect to the target cell.
[0004] According to one aspect, an apparatus includes at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: in response to determining that a user equipment has completed a successful handover to a target cell, a timer is started, the successful handover being triggered as a Layer 1 or Layer 2 mobility (LTM) cell handover; monitor whether the user equipment performed a beam failure recovery procedure due to beam failure of the beam used to connect to the target cell after a successful handover to the target cell and before the timer expires; determine that the user equipment performed a beam failure recovery procedure due to beam failure of the beam used to connect to the target cell after a successful handover to the target cell and before the timer expires; and in response to determining that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell and before the timer expires, transmit an indication that the user equipment performed a beam failure recovery procedure due to beam failure of the beam used to connect to the target cell after a successful handover to the target cell; wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes an indication of an identifier of the user equipment associated with the target cell.
[0005] According to one aspect, an apparatus includes at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: after a user equipment has successfully completed a handover from a source cell to a target cell, store a mapping between an identifier associated with the source cell and an identifier associated with the target cell for the user equipment; receive an instruction that the user equipment performed a beam failure recovery procedure due to a beam failure for connecting to the target cell after a successful handover to the target cell; wherein the received instruction packet indicating that the user equipment performed the beam failure recovery procedure after a successful handover to the target cell. The method includes: an indication of the identifier associated with the target cell of the user equipment; determining the identifier associated with the source cell of the user equipment based on the stored mapping, using the identifier associated with the target cell of the user equipment received along with an indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell; and transmitting the following indication: the user equipment performed a beam failure recovery procedure due to a beam failure after a successful handover to the target cell; wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes an indication of the identifier associated with the source cell of the user equipment determined from the stored mapping.
[0006] According to one aspect, an apparatus includes at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: receive an instruction that a user equipment performs a beam failure recovery procedure due to beam failure of a beam used to connect to a target cell after a successful handover to the target cell; wherein the received instruction that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes an indication of an identifier of the user equipment associated with the target cell; and transmit an instruction that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell; wherein the transmitted instruction that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes an indication of an identifier of the user equipment associated with the target cell. Attached Figure Description
[0007] The foregoing aspects and other features will be explained in the following description taken in conjunction with the accompanying drawings.
[0008] Figure 1 This is a block diagram of a possible and non-limiting system in which exemplary embodiments can be practiced.
[0009] Figure 2 The LTM between gNB-DUs is shown.
[0010] Figure 3This illustrates a problem scenario where BFR occurs shortly after a successful LTM HO.
[0011] Figure 4 This shows an example intra-CU scene.
[0012] Figure 5 This shows an example inter-CU scene.
[0013] Figure 6 It is an example device configured to implement the examples described herein.
[0014] Figure 7 A representation of an example of a non-volatile storage medium for storing instructions that implement the examples described herein is shown.
[0015] Figure 8 This is an example method based on the example described in this article.
[0016] Figure 9 This is an example method based on the example described in this article.
[0017] Figure 10 This is an example method based on the example described in this article.
[0018] Figure 11 This is an example method based on the example described in this article.
[0019] Figure 12 An example implementation of a scene within the CU is described.
[0020] Figure 13 An example implementation of a CU-interactive scenario is described. Detailed Implementation
[0021] Go to Figure 1 This figure illustrates a possible, non-limiting block diagram of an example in which the examples described herein can be practiced. It depicts a user equipment (UE) 110, a radio access network (RAN) node 170, and (multiple) network elements 190. Figure 1In the example, User Equipment (UE) 110 wirelessly communicates with Wireless Network 100. The UE is a wireless device that can access Wireless Network 100. UE 110 includes one or more processors 120, one or more memories 125, and one or more transceivers 130 interconnected via one or more buses 127. Each of the one or more transceivers 130 includes a receiver Rx 132 and a transmitter Tx 133. The one or more buses 127 may be address, data, or control buses and may include any interconnecting mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optic cables, or other optical communication devices. The one or more transceivers 130 are connected to one or more antennas 128. The one or more memories 125 include computer program code 123. UE 110 includes modules comprising one or both of portions 140-1 and / or 140-2, which can be implemented in various ways. The module may be implemented in hardware as module 140-1, such as being implemented as part of one or more processors 120. Module 140-1 may also be implemented as an integrated circuit or via other hardware such as a programmable gate array. In another example, module 140 may be implemented as module 140-2, which is implemented as computer program code 123 and executed by one or more processors 120. For example, one or more memories 125 and computer program code 123 may be configured to enable user equipment 110 to perform one or more operations as described herein using one or more processors 120. UE 110 communicates with RAN node 170 via radio link 111.
[0022] In this example, RAN node 170 is a base station that provides access to wireless network 100 for wireless devices such as UE 110. RAN node 170 can be a base station for, for example, 5G (also known as New Radio (NR)). In 5G, RAN node 170 can be an NG-RAN node, which is defined as a gNB or ng-eNB. A gNB is a node that provides NR user plane and control plane protocol termination to the UE and is connected to the 5GC (e.g., multiple network elements 190) via an NG interface (such as connection 131). An ng-eNB is a node that provides E-UTRA user plane and control plane protocol termination to the UE and is connected to the 5GC via an NG interface (such as connection 131). An NG-RAN node can include multiple gNBs, which can also include a central unit (CU) (gNB-CU) 196 and multiple distributed units (DUs) (gNB-DU) (where DU 195 is shown). Note that DU 195 can include or be coupled to and control a radio unit (RU). gNB-CU 196 is a logical node that hosts the Radio Resource Management (RRC), SDAP, and PDCP protocols of the gNB or the RRC and PDCP protocols of the en-gNB, controlling the operation of one or more gNB-DUs. gNB-CU 196 terminates the F1 interface connected to gNB-DU 195. The F1 interface is illustrated as reference numeral 198, but reference numeral 198 also illustrates a link between remote elements of RAN node 170 and centralized elements of RAN node 170, such as between gNB-CU and gNB-DU. gNB-DU 195 is a logical node that hosts the RLC, MAC, and PHY layers of the gNB or en-gNB, and its operation is partially controlled by gNB-CU 196. A gNB-CU supports one or more cells. A cell can be supported by one gNB-DU 196, or, in the case of RAN sharing, a cell can be supported or shared by multiple DUs. gNB-DU 195 terminates the F1 interface 198 connected to gNB-CU 196. Note that DU 195 is considered to include transceiver 160, for example as part of the RU, but some examples may allow transceiver 160 to be part of a separate RU, for example, under the control of and connected to DU 195. RAN node 170 may also be an eNB (evolved Node B) base station for LTE (Long Term Evolution), or any other suitable base station or node.
[0023] RAN node 170 includes one or more processors 152, one or more memories 155, one or more network interfaces (N / WI / F) 161, and one or more transceivers 160 interconnected via one or more buses 157. Each of the one or more transceivers 160 includes a receiver Rx 162 and a transmitter Tx 163. The one or more transceivers 160 are connected to one or more antennas 158. The one or more memories 155 include computer program code 153. CU 196 may include processor(s) 152, one or more memories 155, and network interfaces 161. Note that DU 195 may also contain its own one or more memories and processor(s) and / or other hardware, but these are not shown.
[0024] RAN node 170 includes module 150, which comprises one or both of portions 150-1 and / or portions 150-2. Module 150 can be implemented in various ways. Module 150 can be implemented in hardware as module 150-1, for example, as a portion of one or more processors 152. Module 150-1 can also be implemented as an integrated circuit or via other hardware, such as a programmable gate array. In another example, module 150 can be implemented as module 150-2, which is implemented as computer program code 153 and executed by one or more processors 152. For example, one or more memories 155 and computer program code 153 are configured to enable RAN node 170 to perform one or more operations as described herein using one or more processors 152. Note that the functionality of module 150 can be distributed, such as distributed between DU 195 and CU 196, or implemented only in DU 195.
[0025] One or more network interfaces 161 communicate over the network, such as via links 176 and 131. Two or more gNBs 170 may communicate using, for example, link 176. Link 176 may be wired or wireless or both, and may implement, for example, an Xn interface for 5G, an X2 interface for LTE, or other suitable interfaces for other standards.
[0026] One or more buses 157 may be address, data, or control buses and may include any interconnecting mechanism, such as a series of lines on a motherboard or integrated circuit, optical fiber or other optical communication equipment, wireless channels, etc. For example, one or more transceivers 160 may be implemented as a Remote Radio Header (RRH) 195 for LTE or a Distributed Unit (DU) 195 for a gNB implementation of 5G, wherein other elements of the RAN node 170 may be physically located differently from the RRH / DU 195, and one or more buses 157 may be partially implemented as, for example, fiber optic cables or other suitable network connections to connect other elements of the RAN node 170 (e.g., Central Unit (CU), gNB-CU 196) to the RRH / DU 195. Reference numeral 198 also indicates those suitable network links(s).
[0027] A RAN node / gNB may include one or more TRPs, and the methods described herein can be applied to such one or more TRPs. Figure 1 As shown, RAN node 170 includes TRP 51 and TRP 52 (attached to the TRP represented by transceiver 160). Similar to transceiver 160, TRP 51 and TRP 52 may each include a transmitter and a receiver. RAN node 170 may host or include... Figure 1 Other TRPs not shown. In another example, when describing transceiver 160, TRP 51 may correspond to transceiver 160, or TRP 52 may correspond to transceiver 160.
[0028] In NR, relay nodes are called Integrated Access and Backhaul (IAB) nodes. The mobile termination portion of the IAB node facilitates backhaul (parent link) connections. In other words, the mobile termination portion includes the functions that carry UE functionality. The distributed unit portion of the IAB node facilitates so-called access link (sub-link) connections (i.e., for access link UEs, and for backhaul to other IAB nodes in the case of multi-hop IABs). In other words, the distributed unit portion is responsible for certain base station functions. IAB scenarios can follow a so-called split architecture, where the central unit hosts higher-level protocols to the UE and terminates the control plane interface and user plane interface with the 5G core network.
[0029] Note that the description in this document indicates that a "cell" performs a function; however, it should be clear that the equipment forming a cell can perform functions. A cell constitutes part of a base station. That is, each base station can correspond to multiple cells. For example, for a single carrier frequency and associated bandwidth, there can be three cells, each covering one-third of a 360-degree area, such that the coverage area of a single base station is approximately elliptical or circular. Furthermore, each cell can correspond to a single carrier, and a base station can use multiple carriers. Therefore, if each carrier corresponds to three 120-degree cells and there are two carriers, the base station has a total of six cells.
[0030] Wireless network 100 may include one or more network elements 190, which may include core network functions and provide connectivity to other networks (e.g., telephone networks and / or data communication networks (e.g., the Internet)) via one or more links 181. Such core network functions for 5G may include location management functions (multiple LMFs) and / or multiple Access and Mobility Management Functions (AMFs) and / or multiple User Plane Functions (UPFs) and / or multiple Session Management Functions (SMFs). Such core network functions for LTE may include MME (Mobility Management Entity) / SGW (Serving Gateway) functions. Such core network functions may include SON (Self-Managed / Optimized Network) functions. These are merely example functions that can be supported by network elements 190, and note that both 5G and LTE functions can be supported. RAN node 170 is coupled to network element 190 via link 131. Link 131 may be implemented as, for example, an NG interface for 5G, or an S1 interface for LTE, or other suitable interfaces for other standards. Network element 190 includes one or more processors 175 interconnected via one or more buses 185, one or more memories 171, and one or more network interfaces (N / WI / F) 180. The one or more memories 171 include computer program code 173. The computer program code 173 may include SON and / or MRO functions 172.
[0031] Wireless network 100 can implement network virtualization, which is the process of combining hardware and software network resources and network functions into a single software-based management entity, or virtual network. Network virtualization involves platform virtualization, often combined with resource virtualization. Network virtualization is categorized as either external, combining many networks or parts of networks into virtual units, or internal, providing network-like functionality to software containers on a single system. Note that the virtualized entities created by network virtualization are still implemented at some level using hardware such as processors 152 or 175 and memories 155 and 171, and these virtualized entities also produce technical effects.
[0032] Computer-readable storage devices 125, 155, and 171 can be of any type suitable for the local technical environment and can be implemented using any suitable data storage technology, such as semiconductor-based memory devices, flash memory, magnetic storage devices and systems, optical storage devices and systems, non-transitory memory, transient memory, fixed memory, and removable memory. Computer-readable storage devices 125, 155, and 171 can be components for performing storage functions. As a non-limiting example, processors 120, 152, and 175 can be of any type suitable for the local technical environment and can include one or more of a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture. Processors 120, 152, and 175 can be components for performing functions such as controlling UE 110, RAN node 170, network element(s) 190, and other functions as described herein.
[0033] Typically, various example embodiments of user equipment 110 may include, but are not limited to, cellular phones (such as smartphones), tablet computers, personal digital assistants (PDAs) with wireless communication capabilities, portable computers with wireless communication capabilities, image capture devices (such as digital cameras with wireless communication capabilities), gaming devices with wireless communication capabilities, music storage and playback devices with wireless communication capabilities, internet devices including those that allow wireless internet access and browsing, tablet computers with wireless communication capabilities, head-mounted displays (such as those implementing virtual / augmented / mixed reality), and portable units or terminals combining such functions. UE 110 may also be a vehicle such as a car, or a UE installed in a vehicle, such as a UAV (Uniform Aerial Vehicle) like a drone, or a UE installed in a UAV. User equipment 110 may be a terminal device, such as a mobile phone, mobile device, sensor device, etc., and the terminal device may be a device used by a user or a device not used by a user.
[0034] UE 110, RAN node 170, and / or (multiple) network elements 190 (and associated memory, computer program code, and modules) can be configured to implement (e.g., partially implement) the methods described herein. Therefore, UE 110's Figure 1 The computer program code 123, module 140-1, module 140-2, and other elements / features shown herein can implement the user equipment-related aspects of the examples described herein. Similarly, RAN node 170's... Figure 1 The computer program code 153, module 150-1, module 150-2, and other elements / features shown herein can implement the gNB / TRP-related aspects of the examples described herein. (Multiple) network elements 190 Figure 1The computer program code 173 shown, along with other elements / features, can be configured to implement the network element-related aspects of the examples described herein.
[0035] Having thus introduced a suitable, but not limiting, technical context for practicing the exemplary embodiments, the exemplary embodiments will now be described in more detail.
[0036] 3GPP Rel-18 introduced the feature of L1 / L2 Triggered Mobility (LTM). The goal of LTM is to reduce latency and downtime during mobility procedures. When using LTM procedures, the gNB can change the UE's serving cell via a cell handover command sent through the MAC CE signaling, instead of using Layer 3 (RRC) signaling as in regular mobility procedures. The cell handover command indicates the LTM candidate configuration previously provided to the UE by the gNB. The UE then switches to the target configuration based on the cell handover command. Rel-18 currently only supports intra-gNB or intra-CU LTM procedures, including both intra-DU mobility scenarios and inter-DU mobility scenarios. Currently, work is underway in the Rel-19 specification to extend LTM support to inter-gNB and inter-CU LTM scenarios. Examples of intra-CU and gNB-DU LTM scenarios are presented below.
[0037] gNB-DU LTM The gNB-DU inter-LTM procedure is used when a UE moves from one gNB-DU to another within the same gNB-CU during an NR operation for LTM. Figure 2 The LTM procedure for gNB-DU within NR is illustrated, including signaling exchange between UE 110, source gNB-DU 295-1, candidate gNB-DU 295-2, and gNB-CU 296. Figure 2 The steps are as follows: 1. The UE sends a message to the source gNB-DU. Measurement Report The message (L3 measurement results) contains measurements from neighboring cells. The source gNB-DU sends a UL RRC message transfer message, which transmits the received data. Measurement Report The message is sent to gNB-CU.
[0038] 2. gNB-CU determines to initiate LTM configuration.
[0039] 3. For each candidate cell, the gNB-CU sends a UECONTEXT SETUP REQUEST message to (multiple) candidate gNB-DUs, which includes a candidate cell ID and CSI resource configuration for subsequent LTM. The gNB-CU may provide an LTM configuration ID mapping list to (multiple) candidate gNB-DUs. The gNB-CU may request PRACH resources from (multiple) candidate gNB-DUs. The gNB-CU may request (multiple) candidate gNB-DUs to provide lower-layer configuration for generating a reference configuration, or provide (multiple) candidate gNB-DUs with a lower-layer portion of the reference configuration.
[0040] 4. If the candidate gNB-DU accepts the LTM configuration request, the candidate gNB-DU responds with a UEContextSetup RESPONSE message, which includes the generated lower-layer RRC configuration for the accepted target candidate cell.
[0041] The UE Context Modification procedure initiated by the CU can be initiated to prepare candidate cells in the source gNB-DU in accordance with steps 3 and 4 of 8.2.1.4 Intra-gNB-DU LTM in 3GPP TS 38.401.
[0042] 5. The gNB-CU sends a UE CONTEXT MODIFICATIONREQUEST message to the source gNB-DU, which includes information related to early synchronization and a list of LTM configuration ID mappings for (multiple) accepted target candidate cells. The gNB-CU may send updated CSI resource configurations to the source gNB-DU. The gNB-CU may notify the source gNB-DU about L2 reset configurations within the DU.
[0043] 6. The source gNB-DU responds with a UE CONTEXT MODIFICATION RESPONSE message, which includes updated lower-layer configurations, such as updated CSI report configurations for the source cell.
[0044] 7. For each candidate cell accepted among the candidate gNB-DUs, the gNB-CU may send a UE CONTEXT MODIFICATION REQUEST message containing information for subsequent LTM or for updating the candidate cell configuration. The gNB-CU may also provide the lower-layer portion of the reference configuration to the candidate gNB-DUs. The gNB-CU may notify the candidate gNB-DUs of an L2 configuration reset within the DU.
[0045] 8. The candidate gNB-DU responds with a UE CONTEXT MODIFICATION RESPONSE message, which includes updated lower-layer configurations, such as updated CSI report configurations containing the requested candidate cell.
[0046] Step 7 can also be triggered after step 19 or after step 22, depending on the implementation method, for subsequent LTM.
[0047] 9. The gNB-CU sends a DL RRC message transfer to the source gNB-DU, which includes the generated LTM configuration. RRCReconfiguration information.
[0048] 10. The source gNB-DU will receive... RRCReconfiguration The message is forwarded to the UE.
[0049] 11. UE with RRCReconfigurationComplete Message response source gNB-DU.
[0050] 12. The source gNB-DU will be transmitted via UL RRC message (UL RRC MESSAGE TRANSFER). RRCReconfigurationComplete The message was forwarded to gNB-CU.
[0051] 13. Early TA acquisition for (multiple) candidate cells can be performed in accordance with the method specified in TS 38.300.
[0052] 14. The candidate gNB-DU sends a DU-CU TA INFORMATIONTRANSFER message to the gNB-CU, which includes the TA value and the associated PRACH resource information.
[0053] 15. In the CU-DU TA INFORMATION TRANSFER message, gNB-CU forwards the TA value and the associated PRACH resource information to the source gNB-DU.
[0054] 16. The UE sends the L1 measurement results to the source gNB-DU.
[0055] 17. The source gNB-DU decides to perform LTM to the target cell.
[0056] 18. The source gNB-DU sends a cell switch command to the UE.
[0057] 19. The source gNB-DU sends a DU-CU CELL SWITCHNOTIFICATION message to the gNB-CU to instruct the initiation of a cell handover command to the UE, which includes the target cell ID and (multiple) TCI status IDs. It may also include (multiple) TA value-related information applicable to subsequent LTMs.
[0058] 20. In the CU-DU cell switch notification message, gNB-CU forwards the target cell ID, (multiple) TCI status IDs and (multiple) TA value information received in step 19 to the target gNB-DU.
[0059] 21. The target gNB-DU detects UE access in accordance with the method specified in TS 38.300.
[0060] 22. The target gNB-DU sends an ACCESS SUCCESS message to the gNB-CU, which includes the target cell ID.
[0061] 23. The UE sends a message to the target gNB-DU. RRCReconfigurationComplete information.
[0062] 24. The target gNB-DU will transmit the message via UL RRC message. RRCReconfigurationComplete The message was forwarded to gNB-CU.
[0063] 25. The gNB-CU can send a UE context release command (UE CONTEXT RELEASECOMMAND) message to the source gNB-DU to release the resources of the prepared cell.
[0064] 26. The source gNB-DU responds with a UE CONTEXT RELEASE COMPLETE message.
[0065] Automated optimization tasks performed by SON and handover decision-making at the MAC CE cell ( Figure 2 Step 17) is related to the correct beam identification in the target cell.
[0066] To optimize the behavior of mobility processes, 3GPP defines Mobility Robustness Optimizations (MRO) features (3GPP TS 38.300). However, these features focus on cell-level mobility aspects and cover scenarios such as Too Early HO (TEH), Too Late HO (TLH), and HO to Wrong Cell (HWC). The problem scenarios addressed in the examples described in this paper are not covered by existing standardized mechanisms for MRO.
[0067] The handover issue is related to the RAN2 SON implementation. In the example, the Successful HO Report (SHR) could be enhanced so that the UE can provide an indication to the network that it experienced a BFR shortly after an LTM HO. However, this solution is not optimal. For example, the SHR report is specified to capture near-failure cases during HO. The scenario addressed in this specification is a beam failure (BF) occurring immediately after a successful handover (referred to as a cell handover in LTM), which, in a broader sense and as a near-failure case, can be compared to HWC because the issue occurs shortly after the cell handover. However, as mentioned above, in this scenario, the cell handover is successful, and the BFR occurs shortly thereafter. The solution of the UE providing an indication to the network that it experienced a BFR shortly after an LTM HO introduces additional signaling from the UE to the network, which may be undesirable. This document describes a network-based solution that avoids this signaling from the UE and detects and corrects the issue.
[0068] The issue of beam failure recovery after a successful LTM cell handover is related to RAN-3. The target DU can send beam failure detection (BFD) and beam failure recovery (BFR) information (e.g., recovery of TCI state) to the CU signaling, which the CU forwards to the source DU. However, this indication from the target cell to the source cell alone is insufficient for proper root cause analysis and corrective action at the source DU.
[0069] Figure 3 This illustrates a problem scenario where a BFR (Band Failure) occurs shortly after a successful LTM HO (Local Time HO). In an LTM HO, source cell 302 can also select which beam the UE should switch to from a neighboring cell. However, if the network does not correctly perform this beam selection for the HO, it can lead to beam failure because beam-level connectivity is more sensitive to radio conditions. The different steps involved in this problem scenario are as follows: 1. UE 110 reports at least one L3 measurement event triggered by a neighboring cell to source cell 302 (cell-1 302).
[0070] 2. The source CU decides to initiate LTM configuration. This involves obtaining candidate LTM configurations from neighboring cells. Based on information from one or more neighboring cells, the source prepares a common LTM configuration for the UE and configures the UE using RRC signaling. This configuration includes a list of LTM candidates, configurations for LTM measurement events, and a new UE identifier (C-RNTI from cell-2 304) to be used with UL authorization in cell-2 304 after a no-RACH cell handover.
[0071] 3. UE 110 begins reporting L1 beam measurements according to the LTM measurement configuration.
[0072] 4. In step 4a, the source DU decides to perform LTM for UE 110. In step 4b, the source DU sends a cell handover command to UE 110, which includes transmission-specific information required for RACH-free cell handover, referred to as TCI status (e.g., which beam, e.g., beam 2-1). The new UE-ID (C-RNTI) used in the new cell is linked to the UL authorization prepared for the UE.
[0073] 5. UE 110 is attached to the target DU (cell-2 304) via beam 2-1.
[0074] 6. Shortly thereafter, the UE experiences a beam failure and performs beam failure recovery (BFR), which is RACH-based access to another beam.
[0075] 7. BFR successful, and UE connected to beam 2-2 of cell-2 304.
[0076] As can be observed from the above steps, both the LTM HO and BFR procedures were successful, therefore the UE did not experience any radio link failure (RLF). However, the overall delay and interruption experienced by the UE during the RACH-based BFR can be considered as part of the HO, thus negatively impacting the HO because the UE had to change beams shortly after the HO. In principle, LTM is a RACH-free procedure, while BFR is a RACH-based procedure, and this, along with the sequence of the two procedures, offsets the advantages of LTM over Layer 3 (L3) handover.
[0077] Since the BFR was successful in the target DU (cell-2 304), it can be assumed that beam management in the target DU was functioning correctly. However, there may be a problem at the source (cell-1 302) causing suboptimal beam selection during the HO. The beams in the target cell to be used by UE 110 for LTM HO are indicated to UE 110 by the source DU in the cell handover command (see step 4 above). The source DU makes this decision based on the UE's measurement report (step 3), which was discarded upon successful HO. Because the BFR occurs after successful LTM HO, even if the source DU could be notified of the problem, it cannot correlate the problem with the UE's radio measurements to analyze which other beams the UE was able to measure just before performing LTM HO.
[0078] Therefore, the problem addressed in the example described herein is how to improve root cause analysis at the source DU for this scenario by integrating radio measurements from the UE during LTM execution. This root cause analysis is crucial for identifying the exact problem, such as in the cell handover decision criteria of the source DU.
[0079] As described herein, the source DU responsible for cell handover decisions is instructed to store L1 beam measurements for the cell handover decision for a dedicated configuration time. This configuration time for storing L1 measurements is related to the configuration time for classifying BFRs in the target cell controlled by the target DU as "BFRs occurring shortly after cell handover". The source DU also marks these L1 beam measurements with a unique UE identifier that can be matched with the UE identifier that follows the target DU to the source DU and indicates the message received for that issue.
[0080] The CU acts as a relay between the target DU and the source DU. In a CU-internal scenario (involving a common CU), the message flow is: the target DU notifies the CU, and then the CU notifies the source DU. In a CU-internal scenario (involving two CUs), the message flow is: target DU to target CU to source CU to source DU. The task of the (source / common) CU is to convert the target C-RNTI received from the target CU / DU into a source C-RNTI, and then forward the beam information along with the "source C-RNTI" to the source DU.
[0081] The embodiments described herein include the following: Example 1: When the source DU decides to trigger the UE's cell handover using the MAC CE cell handover command, the source DU stores L1 measurements and marks these measurements using the UE's source cell C-RNTI.
[0082] Example 2: The source CU stores the mapping between the source cell C-RNTI and the target cell C-RNTI of the departing UE. The source cell has information about the candidate target cell C-RNTI prepared from the LTM HO. Once the source cell receives notification of a successful LTM HO from a specific candidate LTM cell, the source CU stores the mapping between the target cell C-RNTI and the source cell C-RNTI for that cell.
[0083] Example 3: A timer is used in the (target) DU to correlate a successful LTM from cell-1 to cell-2 with a subsequent BFR in cell-2. UEs may also experience beam failures and require BFRs during normal operation, which are covered by the beam management process. However, for the problem scenario described herein, a BFR occurring shortly after a successful LTM is distinguished from a BFR that may occur during normal cell coverage. A timer is configured at the target DU (cell-2). This timer is started when the LTM process from the incoming UE completes successfully, and any BFRs occurring before the timer expires are considered related to that LTM.
[0084] Example 4: If the target DU (cell-2) detects the relevant LTM and BFR using a timer, the target DU notifies the source cell-1 of the problem experienced by the UE. For intra-CU LTM in Rel-18, information exchange is supported on the F1 interface. For inter-CU LTM in Rel-19, information exchange is also supported on the Xn interface. This information includes, for example, the target C-RNTI, beam 1 in which the UE performed a successful LTM HO, and beam 2 in which the UE performed a BFR. Beam information can be represented, for example, by a TCI state ID.
[0085] Example 5: When the source CU is notified of the problem by the target cell (Example 4), the target C-RNTI reported by the target cell is mapped to the source C-RNTI. For this purpose, the source CU uses its stored mapping (mentioned in Example 2). Then, the source CU notifies the source DU of the problem and forwards the beam-related information reported from the target cell, along with the source C-RNTI.
[0086] Example 6: The source DU identifies the stored UE measurements from the C-RNTI (Example 5) indicated by the source CU and performs evaluation and root cause analysis. For example, the source DU can analyze whether beam 2 (in which the UE performs BFR) reported from the target cell is also reported by the UE in the measurements. If the source DU observes that both beam 1 and beam 2 have sufficient strength and are measurable for many UEs experiencing the problem, the source DU can decide on a future LTM HO decision, preferring beam 2 over beam 1.
[0087] The following describes the implementation details of the solution presented in this article for both intra-CU and inter-CU deployments. A detailed baseline LTM process has previously been incorporated. Figure 2 Please provide an explanation.
[0088] CU in-house deployment: For CU-internal scenarios, standardized features involve the F1 interface between the CU and DU. The steps include: At 411, source DU 295-1 stores UE measurements used for LTM cell handover decisions and uses the UE's source cell C-RNTI to mark these measurements for future reference.
[0089] At 416, candidate DU 295-2 starts a timer once it observes a successful LTM HO from an incoming UE. For example, DU 295-2 starts the timer once it receives an RRC Reconfiguration Complete message (415) from UE 110.
[0090] At 418, upon successful LTM HO completion, the mapping between the source cell C-RNTI and the target cell C-RNTI of CU 296 is stored.
[0091] At 419, UE 110 experiences beam failure shortly after a successful LTM HO, while the timer at candidate DU 295-2 is still running. At 420, UE 110 attempts a beamfailure (BFR) with candidate DU 295-2. If the BFR succeeds and the UE is able to reconnect to candidate DU 295-2, DU 295-2 can associate the BFR at 421 as occurring shortly after the successful LTM HO, because DU 295-2 observes that the BFR occurred before the timer expires. DU 295-2 then sends this information to CU 296 at 422, for example, by using a DU-CU ACCESS AND MOBILITY message on the F1 interface. Figure 4As shown, the F1 interface message is enhanced with information elements, such as “BFR shortly after LTM”, beam 1, beam 2 and the UE’s target cell C-RNTI information, which are provided to CU 296 at 422.
[0092] If the UE experiences a BFR after the timer expires at the candidate DU, the DU considers the BFR to be unrelated to the LTM HO process and does not forward the "BFR shortly after LTM" information to the CU.
[0093] At 424, CU 296 maps the target cell C-RNTI received from the target cell (e.g., received from candidate DU295-2 at 422) to the stored source cell C-RNTI, and forwards the stored source cell C-RNTI to source DU 295-1 at 426. CU 296 can use the F1 interface message "Access and Mobility Indication" at 426. The message transmitted at 426 is enhanced by IE, for example, by utilizing information including "BFR shortly after LTM", beam 1, beam 2, and the source cell C-RNTI of UE 110. Here, CU 296 uses the source cell C-RNTI from this mapping.
[0094] At 428, source DU 295-1 uses information reported from CU 296 at 426 to perform root cause analysis and take corrective actions if necessary. For example, DU 295-1 may modify its "LTM Cell Handover Decision" criteria used at 409 to make LTM cell handover decisions. The criteria used by source DU 295-1 to make LTM cell handover decisions (e.g., at 409) may include one or more thresholds. Therefore, one or more thresholds may be modified based on root cause analysis or corrective actions performed according to information reported from CU 296 at 426.
[0095] Inter-CU deployment: Figure 5 An example implementation of inter-CU deployment is shown. For inter-CU deployment, the problem detection section is similar to that in the reference. Figure 4 The CU-internal deployment is explained as follows: At 518, candidate DU 295-2 starts a timer, and if UE 110 experiences a successful BFR at 520 within that timer, then at 521, DU 295-2 marks the successful BFR as a BFR shortly after LTM HO, because at 521, DU 295-2 observes the BFR occurring before the timer expires.
[0096] The difference between intra-CU deployment and inter-CU deployment is that, for inter-CU deployment, candidate DU 295-2 forwards information to source CU 296-1 via candidate CU 296-2, such as... Figure 5 As shown. Specifically, at 522, candidate DU 295-2 transmits an informational message (which may be an Access and Mobility Indicator) to candidate CU 296-2. This information includes a BFR that occurred shortly after LTM, the beam 1 that caused the failure, the beam 2 used for successful connection after the handover and after the BFR, and the target cell C-RNTI. At 523, candidate CU 296-2 transmits the information received at 522 to source CU 296-1, namely, the following information: a BFR that occurred shortly after LTM, the beam 1 that caused the failure, the beam 2 used for successful connection after the handover and after the BFR, and the target cell C-RNTI.
[0097] At point 522, candidate DU 295-2 forwards information to candidate CU 296-2 using the DU-CU Access and Mobility Indication message on the F1 interface.
[0098] At 523, candidate CU 296-2 forwards this information to source CU 296-1 via the Xn interface using an Access and Mobility Indication message. The Xn interface message transmitted at 523 is enhanced with information elements, such as IEs indicating the text and / or context related to: "BFR shortly after LTM", beam 1 that caused the failure, beam 2 used for successful connection after handover and after BFR, and the target cell C-RNTI of UE 110.
[0099] At 524, source CU 296-1 uses the stored mapping (stored at 516) to map the target cell C-RNTI to the source cell C-RNTI, and at 526 forwards the information to source DU 295-1, as in the case within a CU. At 526, the information transmitted from source CU 296-1 to source DU 295-1 includes the source cell C-RNTI. At 528, source DU 295-1 then performs root cause analysis using the stored UE measurements (stored at 510), and takes any corrective actions if necessary, such as modifying one or more thresholds used to make cell handover decisions (e.g., at 509).
[0100] The optimizations described in this article can be captured in RAN architecture specifications such as 3GPP TS 38.401. For example, MRO support for LTM can be enhanced in TS 38.401.
[0101] The terms "candidate" and "target" are used interchangeably. During LTM HO preparation, a source can prepare multiple neighboring cells for a potential HO, so these multiple neighboring cells are candidate cells. Once the UE actually executes the HO for a specific neighboring cell / DU, the specific neighboring cell / DU that the UE subsequently connects to is the target cell / DU.
[0102] MRO support for LTM The gNB-CU receives RLF reports associated with LTM mobility events from the UE or via a failure indication message on Xn. The gNB-CU performs initial analysis and, in the event of a failure due to an inappropriate cell handover trigger, may forward the RLF report to the last serving gNB-DU in the case of an excessively late LTM, or to the source gNB-DU in the case of an excessively early LTM or LTM to the wrong cell.
[0103] In the event of beam failure recovery shortly after a successful LTM cell handover, the target DU indicates the situation to the source DU via the CU using access and mobility indication messages on F1. The source DU receiving the indication performs an initial analysis based on L1 measurements related to the time point when the LTM cell handover was triggered and assesses whether its LTM mobility configuration needs adjustment.
[0104] The advantages and technical benefits of the solution described in this paper include providing assistance in better performing root cause analysis of beam failures (BFRs) shortly after an LTM homepage (HO). By utilizing corrective actions, the network can minimize such events and prevent UE beam failures shortly after an LTM homepage. This helps maintain the advantages of LTM in reducing outages and latency during mobility and improves the overall user experience.
[0105] The solution described in this article is related to the F1 and Xn interfaces.
[0106] Figure 6 This is an example device 600, which can be implemented in hardware and configured to implement the examples described herein. Device 600 includes at least one processor 602 (e.g., an FPGA and / or a CPU), and one or more memories 604 (including computer program code 605). The computer program code 605 includes instructions for performing the methods described herein, wherein at least one memory 604 and the computer program code 605 are configured to utilize at least one processor 602 to cause device 600 to implement circuits, processes, components, modules, or functions (implemented by control module 606) to implement the examples described herein. The one or more memories 604 may include non-transitory memory, transient memory, volatile memory (e.g., RAM), or non-volatile memory (e.g., ROM).
[0107] Beam failure avoidance 630 implements the examples described herein related to methods for avoiding beam failure shortly after low-level triggered mobility.
[0108] Device 600 includes a display and / or I / O interface 608, which includes user interface (UI) circuitry and components that can be used to display aspects or states of the methods described herein (e.g., during or after the execution of one of the methods), or to receive input from a user, such as through a keyboard, camera, touchscreen, touch area, microphone, biometrics, one or more sensors, etc. Device 600 includes one or more communication interfaces (I / F) 610, such as network (N / W) interfaces. Communication interface 610 can be wired and / or wireless and communicates via the Internet / other networks through one or more links 624 using any communication technology. Link 624 can be... Figure 1 Links 131 and / or 176 in the network. Figure 1 Links 131 and / or 176 can also be implemented using transceiver 616 and the corresponding wireless link 626. Communication interface 610 may include one or more transmitters or one or more receivers.
[0109] Transceiver 616 includes one or more transmitters 618 and one or more receivers 620. Transceiver 616 and / or communication interface 610 may include standard known components such as amplifiers, filters, frequency converters, (de)modulators, and encoding / decoding circuitry, as well as one or more antennas, such as antenna 614 for communication over wireless link 626.
[0110] The control module 606 of device 600 includes one or both of portions 606-1 and / or 606-2, which can be implemented in various ways. Control module 606 can be implemented in hardware as control module 606-1, for example, as part of one or more processors 602. Control module 606-1 can also be implemented as an integrated circuit or via other hardware, such as a programmable gate array. In another example, control module 606 can be implemented as control module 606-2, which is implemented as computer program code (with corresponding instructions) 605 and executed by one or more processors 602. For example, one or more memories 604 store instructions that, when executed by one or more processors 602, cause device 600 to perform one or more operations described herein. Furthermore, one or more processors 602, one or more memories 604, and example algorithms (e.g., flowcharts and / or signaling diagrams) encoded as instructions, programs, or code are means for causing the operations described herein to be performed.
[0111] The apparatus 600 that implements the function of control module 606 may be UE 110, RAN node 170 (e.g., gNB), or network element 190 (e.g., LMF 190). Therefore, processor 602 may correspond to processor 120, processor 152, and / or processor 175; memory 604 may correspond to one or more memories 125, one or more memories 155, and / or one or more memories 171; computer program code 605 may correspond to computer program code 123, computer program code 153, and / or computer program code 173; control module 606 may correspond to module 140-1, module 140-2, module 150-1, and / or module 150-2; and communication interface 610 and / or transceiver 616 may correspond to transceiver 130, antenna 128, transceiver 160, antenna 158, N / W interface 161, and / or N / W interface 180. Alternatively, device 600 and its components may not correspond to UE 110, RAN node 170 or network element 190 and their respective components, because device 600 may be part of a self-organizing / self-optimizing network (SON) node or other node, such as a node in the cloud.
[0112] Device 600 may also correspond to DU 195, CU 196, source DU 295-1 (e.g., source gNB-DU 295-1), candidate DU 295-2 (e.g., candidate gNB-DU 295-2), CU 296 (e.g., gNB-CU 296), cell 302, cell 304, source CU296-1 or candidate CU 296-2.
[0113] Device 600 can also be distributed throughout the network (e.g., 100), including within and between device 600 and any network element (e.g., network control element (NCE) 190 and / or RAN node 170 and / or UE 110).
[0114] Interface 612 enables data communication and signaling between the various components of device 600, such as... Figure 6As shown. For example, interface 612 may be one or more buses, such as an address bus, data bus, or control bus, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optic cable, or other optical communication device. Computer program code (e.g., instructions) 605 (including control module 606) may include object-oriented software configured to pass data or messages between objects in computer program code 605, or computer program code (e.g., instructions) 605 (including control module 606) may include functional, scripting, or procedural code. Device 600 need not include every feature mentioned, or may include other features. The various components of device 600 may be at least partially located within a common housing 628, or a subset of the various components of device 600 may be at least partially located in different housings, which may include housing 628.
[0115] Figure 7 The illustration shows a non-volatile storage medium 700a (e.g., a computer / optical disc (CD) or digital versatile optical disc (DVD)), 700b (e.g., a Universal Serial Bus (USB) memory stick), and 700c (e.g., cloud storage for downloading instructions and / or parameters 702 or receiving instructions and / or parameters 702 sent via email), which stores instructions and / or parameters 702 that, when executed by a processor, enable the processor to perform one or more steps of the methods described herein. Instructions and / or parameters 702 may represent a computer-readable medium.
[0116] Figure 8This is an example method 800 based on the examples described herein. At 810, the method includes: determining, based on measurements received from the user equipment, to trigger a cell handover command for that user equipment. At 820, the method includes: storing measurements received from the user equipment and used for the cell handover decision. At 830, the method includes: marking the stored measurements used for the cell handover decision using an identifier associated with the user equipment and the source cell. At 840, the method includes: receiving an indication that the user equipment performed a beam failure recovery procedure due to beam failure of the beam used to connect to the target cell after a successful handover to the target cell. At 850, the method includes: wherein the received indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes an indication of the user equipment's identifier, which is associated with an identifier used to mark the stored measurements. At 860, the method includes: performing a root cause analysis using the stored measurements marked with the identifier associated with the user equipment and the source cell to determine the root cause of the beam failure used to connect to the target cell. Method 800 can be performed using RAN node 170, DU 195, source DU295-1 (e.g., source gNB-DU 295-1), device 600, RAN node 170-1 or RAN node 170-2.
[0117] Figure 9 This is an example method 900 based on the examples described herein. At 910, the method includes: in response to determining that a user equipment has completed a successful handover to a target cell, starting a timer, the successful handover being triggered as a Layer 1 or Layer 2 triggered mobility (LTM) cell handover. At 920, the method includes: monitoring whether the user equipment performed a beam failure recovery procedure due to beam failure of the beam used to connect to the target cell after a successful handover to the target cell, before the timer expires. At 930, the method includes: determining that the user equipment performed a beam failure recovery procedure due to beam failure of the beam used to connect to the target cell after a successful handover to the target cell, before the timer expires. At 940, the method includes: in response to determining that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell, before the timer expires, transmitting an indication that the user equipment performed a beam failure recovery procedure due to beam failure of the beam used to connect to the target cell after a successful handover to the target cell. At 950, the method includes: wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after successful handover to the target cell includes: an indication of the identifier of the user equipment associated with the target cell. Method 900 can be performed using RAN node 170, DU 195, candidate DU 295-2 (e.g., candidate gNB-DU 295-2), device 600, RAN node 170-1, or RAN node 170-3.
[0118] Figure 10 This is an example method 1000 based on the examples described herein. At 1010, the method includes: after a user equipment has successfully completed a handover from a source cell to a target cell, storing a mapping between an identifier associated with the user equipment and an identifier associated with the user equipment and the target cell. At 1020, the method includes: receiving an indication that the user equipment performed a beam failure recovery procedure due to a beam failure for connecting to the target cell after a successful handover to the target cell. At 1030, the method includes: wherein the received indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes an indication of the identifier associated with the user equipment and the target cell. At 1040, the method includes: based on the stored mapping, using the identifier associated with the user equipment and the target cell received with the indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell, determining the identifier associated with the user equipment and the source cell. At 1050, the method includes: transmitting an indication that the user equipment performed a beam failure recovery procedure due to a beam failure after a successful handover to the target cell. At 1060, the method includes: wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after successful handover to the target cell includes the following indication: an identifier of the user equipment associated with the source cell, determined from a stored mapping. Method 1000 can be performed using RAN node 170, CU 196, CU 296 (e.g., gNB-CU 296), source CU 296-1, device 600, or RAN node 170-2.
[0119] Figure 11 This is an example method 1100 based on the examples described herein. At 1110, the method includes: receiving an indication that a user equipment performed a beam failure recovery procedure due to beam failure of the beam used to connect to the target cell after a successful handover to the target cell. At 1120, the method includes: wherein the received indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes: an indication of an identifier of the user equipment associated with the target cell. At 1130, the method includes: transmitting an indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell. At 1140, the method includes: wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes: an indication of an identifier of the user equipment associated with the target cell. Method 1100 can be performed using RAN node 170, CU 196, candidate CU 296-2, device 600, or RAN node 170-3.
[0120] Figure 12An example implementation of a scenario within a CU is described. RAN node 170-1 includes CU 296, source DU 295-1, and candidate DU 295-2. CU 296 communicates with source DU 295-1 on F1 interface 198-1, and candidate DU 295-2 communicates with CU 296 on F1 interface 198-2. RAN node 170-1 can be a gNB. RAN node 170-1 communicates with other RAN nodes via Xn interface 176-1.
[0121] Figure 13 An example implementation of an inter-CU scenario is described. RAN node 170-2 includes source CU 296-1 and source DU 295-1. Source CU 296-1 communicates with source DU 295-1 on F1 interface 198-3. RAN node 170-2 can be a gNB. RAN node 170-3 includes candidate CU 296-2 and candidate DU 295-2. Candidate CU 296-2 communicates with candidate DU 295-2 on F1 interface 198-4. RAN node 170-3 can be a gNB. RAN node 170-2 communicates with RAN node 170-3 via Xn interface 176-2.
[0122] This article provides and describes the following examples.
[0123] Example 1. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: determine, based on measurements received from a user equipment, to trigger a cell handover command for the user equipment; store measurements received from the user equipment and used for the cell handover decision; mark the stored measurements used for the cell handover decision using an identifier associated with the user equipment and a source cell; receive an indication that, after a successful handover to a target cell, the user equipment performed a beam failure recovery procedure due to beam failure of a beam used to connect to the target cell, wherein the received indication that the user equipment performed the beam failure recovery procedure after a successful handover to the target cell includes an indication of an identifier of the user equipment, the identifier being associated with an identifier used to mark the stored measurements; and perform a root cause analysis using the stored measurements marked with the identifier associated with the user equipment and a source cell to determine the root cause of the beam failure used to connect to the target cell.
[0124] Example 2. The apparatus of Example 1, wherein at least one memory stores instructions that, when executed by at least one processor, cause the apparatus to at least: modify at least one decision criterion for future mobility decisions or future handover decisions based on root cause analysis.
[0125] Example 3. The apparatus according to Example 2, wherein future mobility decisions or future handover decisions include cell handover triggered by Layer 1 or Layer 2.
[0126] Example 4. An apparatus according to any one of Examples 1 to 3, wherein the received indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes the following indications: the beam used by the user equipment to connect to the target cell that caused the beam failure, and the beam used by the user equipment to connect to the target cell that did not cause the beam failure.
[0127] Example 5. The apparatus according to Example 4, wherein at least one memory stores instructions that, when executed by at least one processor, cause the apparatus to at least: modify at least one decision criterion for future mobility decisions or future handover decisions based on received indications of beams that cause beam failure for user equipment to connect to the target cell and beams that do not cause beam failure for user equipment to connect to the target cell.
[0128] Example 6. An apparatus according to any one of Examples 4 to 5, wherein after a failure on a beam that causes beam failure and is used by the user equipment to connect to the target cell, a beam that does not cause beam failure and is used by the user equipment to connect to the target cell is directly used by the user equipment.
[0129] Example 7. An apparatus according to any one of Examples 1 to 6, wherein at least one memory stores instructions that, when executed by at least one processor, cause the apparatus to at least: maintain a counter for the number of beam failure recovery procedures that have occurred after a successful handover to the target cell; increment the counter in response to receiving an indication that a user equipment has performed a beam failure recovery procedure after a successful handover to the target cell, the indication including an indication of an identifier of the user equipment associated with an identifier used to mark a stored measurement; and modify at least one decision criterion for future mobility decisions or future handover decisions based on the counter for the number of beam failure recovery procedures that have occurred after a successful handover to the target cell.
[0130] Example 8. The apparatus of Example 7, wherein at least one memory stores instructions that, when executed by at least one processor, cause the apparatus to at least: monitor statistics including a counter of the number of beam failure recovery processes that have occurred after a successful handover to the target cell; and, based on the monitoring of the statistics, modify at least one decision criterion for future mobility decisions or future handover decisions, the statistics including the counter of the number of beam failure recovery processes that have occurred after a successful handover to the target cell.
[0131] Example 9. An apparatus according to Example 8, wherein at least one memory stores instructions that, when executed by at least one processor, cause the apparatus to at least: maintain another counter for the number of beam failure recovery processes that have occurred after a successful handover to another target cell; increment another counter in response to receiving another indication that a user equipment has performed a beam failure recovery process after a successful handover to another target cell, the other indication including another indication of an identifier of the user equipment, the identifier being associated with an identifier used to mark a stored measurement; and modify at least one decision criterion for future mobility decisions or future handover decisions based on the other counter for the number of beam failure recovery processes that have occurred after a successful handover to another target cell.
[0132] Example 10. The apparatus of Example 9, wherein at least one memory stores instructions that, when executed by at least one processor, cause the apparatus to at least: monitor statistics including another counter for the number of beam failure recovery processes that have occurred after a successful handover to another target cell; and, based on the monitoring of the statistics, modify at least one decision criterion for future mobility decisions or future handover decisions, the statistics including another counter for the number of beam failure recovery processes that have occurred after a successful handover to another target cell.
[0133] Example 11. An apparatus according to any one of Examples 1 to 10, wherein the received instruction that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes the following instruction: the user equipment performed a beam failure recovery procedure before a timer expired after a successful handover to the target cell.
[0134] Example 12. An apparatus according to any one of Examples 1 to 11, wherein the received indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes the following indication (e.g., indicating the following text): The user equipment performed a beam failure recovery procedure shortly after a successful handover to the target cell.
[0135] Example 13. An apparatus according to any one of Examples 1 to 12, wherein the apparatus includes a source distributed unit, or the source distributed unit includes an apparatus, or the radio access network node includes an apparatus, or the apparatus includes a radio access network node, or the gNB includes an apparatus, or the apparatus includes a gNB.
[0136] Example 14. An apparatus according to any one of Examples 1 to 13, wherein the identifier of the user equipment associated with the source cell includes a temporary identifier of the source cell radio network.
[0137] Example 15. An apparatus according to any one of Examples 1 to 14, wherein the received instruction that the user equipment has performed a beam failure recovery procedure after a successful handover to the target cell is received indirectly from the target distributed unit via the central unit.
[0138] 16. An apparatus according to any one of Examples 1 to 15, wherein the received instruction that the user equipment has performed a beam failure recovery procedure after a successful handover to the target cell is received from the central cell on the F1 interface.
[0139] Example 17. An apparatus according to any one of Examples 1 to 16, wherein a successful handover to a target cell includes a mobility (LTM) cell handover triggered by Layer 1 or Layer 2.
[0140] Example 18. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: in response to determining that a user equipment has completed a successful handover to a target cell, a timer is started, the successful handover being triggered as a Layer 1 or Layer 2 mobility (LTM) cell handover; monitor whether the user equipment performed a beam failure recovery procedure due to beam failure of the beam used to connect to the target cell before the timer expires after a successful handover to the target cell; determine that the user equipment performed a beam failure recovery procedure due to beam failure of the beam used to connect to the target cell before the timer expires after a successful handover to the target cell; and in response to determining that the user equipment performed a beam failure recovery procedure before the timer expires after a successful handover to the target cell, transmit an indication that the user equipment performed a beam failure recovery procedure due to beam failure of the beam used to connect to the target cell after a successful handover to the target cell, wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes: an indication of an identifier of the user equipment associated with the target cell.
[0141] Example 19. The apparatus according to Example 18, wherein the transmitted indication of the user equipment performing a beam failure recovery procedure after a successful handover to the target cell includes: an indication of the beam used by the user equipment to connect to the target cell that caused the beam failure, and an indication of the beam used by the user equipment to connect to the target cell that did not cause the beam failure.
[0142] Example 20. According to the apparatus of Example 19, after a failure on a beam that causes beam failure and is used by the user equipment to connect to the target cell, a beam that does not cause beam failure and is used by the user equipment to connect to the target cell is directly used by the user equipment.
[0143] Example 21. An apparatus according to any one of Examples 18 to 20, wherein the transmitted instruction that the user equipment has performed a beam failure recovery procedure after a successful handover to the target cell is transmitted to the central cell on the F1 interface.
[0144] Example 22. An apparatus according to any one of Examples 18 to 21, wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes the following indication: the user equipment performed a beam failure recovery procedure before a timer expired after a successful handover to the target cell.
[0145] Example 23. An apparatus according to any one of Examples 18 to 22, wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes the following indication (e.g., the following text indicating that the user equipment performed a beam failure recovery procedure shortly after a successful handover to the target cell).
[0146] Example 24. An apparatus according to any one of Examples 18 to 23, wherein the apparatus includes a distributed unit, or the distributed unit includes an apparatus, or the apparatus includes a gNB, or the gNB includes an apparatus, or the radio access network node includes an apparatus, or the apparatus includes a radio access network node.
[0147] Example 25. An apparatus according to any one of Examples 18 to 24, wherein the apparatus provides access to a target cell.
[0148] Example 26. An apparatus according to any one of Examples 18 to 25, wherein the identifier of the user equipment associated with the target cell includes a temporary identifier of the target cell radio network.
[0149] Example 27. An apparatus according to any one of Examples 18 to 26, wherein the transmitted instruction that the user equipment has performed a beam failure recovery procedure after a successful handover to the target cell is transmitted indirectly to the source distributed unit via the central unit.
[0150] Example 28. An apparatus comprising: at least one processor; and at least one memory storing instructions, which, when executed by the at least one processor, cause the apparatus to at least: after a user equipment has successfully completed a handover from a source cell to a target cell, store a mapping between an identifier of the user equipment associated with the source cell and an identifier of the user equipment associated with the target cell; receive an instruction that, after a successful handover to the target cell, the user equipment performed a beam failure recovery procedure due to a beam failure for connecting to the target cell, wherein the received instruction that the user equipment performed the beam failure recovery procedure after a successful handover to the target cell includes: the user equipment The system includes: an indication of an identifier associated with the target cell; determining an identifier associated with the source cell of the user equipment based on the stored mapping, using the identifier associated with the target cell of the user equipment received along with an indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell; and transmitting the following indication: the user equipment performed a beam failure recovery procedure due to a beam failure after a successful handover to the target cell, wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes the following indication: the identifier associated with the source cell of the user equipment determined from the stored mapping.
[0151] Example 29. The apparatus according to Example 28, wherein the received indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes the following indications: the beam used by the user equipment to connect to the target cell that caused the beam failure, and the beam used by the user equipment to connect to the target cell that did not cause the beam failure.
[0152] Example 30. The apparatus according to Example 29, wherein after a failure on a beam that causes beam failure and is used by the user equipment to connect to the target cell, a beam that does not cause beam failure and is used by the user equipment to connect to the target cell is directly used by the user equipment.
[0153] Example 31. An apparatus according to any one of Examples 28 to 30, wherein the received instruction that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes the following instruction: the user equipment performed a beam failure recovery procedure before a timer expired after a successful handover to the target cell.
[0154] Example 32. An apparatus according to any one of Examples 28 to 31, wherein the received indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes the following indication (e.g., indicating the following text): The user equipment performed a beam failure recovery procedure shortly after a successful handover to the target cell.
[0155] Example 33. An apparatus according to any one of Examples 28 to 32, wherein the received instruction that the user equipment has performed a beam failure recovery procedure after a successful handover to the target cell is received from the target distributed unit on the F1 interface.
[0156] Example 34. An apparatus according to any one of Examples 28 to 33, wherein the received instruction that the user equipment has performed a beam failure recovery procedure after a successful handover to the target cell is received from the target central cell on the Xn interface.
[0157] Example 35. The apparatus according to Example 34, wherein the received instruction that the user equipment has performed a beam failure recovery procedure after a successful handover to the target cell is received indirectly from the target distributed unit via the target central unit.
[0158] Example 36. An apparatus according to any one of Examples 28 to 35, wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes the following indications: the beam used by the user equipment to connect to the target cell that caused the beam failure, and the beam used by the user equipment to connect to the target cell that did not cause the beam failure.
[0159] Example 37. According to the apparatus of Example 36, after a failure on a beam that causes beam failure and is used by the user equipment to connect to the target cell, a beam that does not cause beam failure and is used by the user equipment to connect to the target cell is directly used by the user equipment.
[0160] Example 38. An apparatus according to any one of Examples 28 to 37, wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes the following indication: the user equipment performed a beam failure recovery procedure before a timer expired after a successful handover to the target cell.
[0161] Example 39. An apparatus according to any one of Examples 28 to 38, wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes the following indication (e.g., the following text indicating that the user equipment performed a beam failure recovery procedure shortly after a successful handover to the target cell).
[0162] Example 40. An apparatus according to any one of Examples 28 to 39, wherein the transmitted instruction that the user equipment has performed a beam failure recovery procedure after a successful handover to the target cell is transmitted to the distributed cell on the F1 interface.
[0163] Example 41. An apparatus according to any one of Examples 28 to 40, wherein the identifier of the user equipment associated with the source cell includes a temporary identifier of the source cell radio network.
[0164] Example 42. An apparatus according to any one of Examples 28 to 41, wherein the identifier of the user equipment associated with the target cell includes a temporary identifier of the target cell radio network.
[0165] Example 43. An apparatus according to any one of Examples 28 to 42, wherein the apparatus includes a central unit, or the central unit includes the apparatus, or the apparatus includes a gNB, or the gNB includes the apparatus, or the radio access network node includes the apparatus, or the apparatus includes a radio access network node.
[0166] Example 44. An apparatus according to any one of Examples 28 to 43, wherein a successful handover to the target cell includes a Layer 1 or Layer 2 triggered mobility (LTM) cell handover.
[0167] Example 45. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: receive an instruction that a user equipment performs a beam failure recovery procedure after a successful handover to a target cell due to a beam failure of a beam used to connect to the target cell, wherein the received instruction that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes: an indication of an identifier of the user equipment associated with the target cell; and transmit an instruction that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell, wherein the transmitted instruction that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes: an indication of an identifier of the user equipment associated with the target cell.
[0168] Example 46. According to the apparatus of Example 45, the received instruction that the user equipment has performed a beam failure recovery procedure due to beam failure after a successful handover to the target cell is received from the target distributed unit on the F1 interface.
[0169] Example 47. An apparatus according to any one of Examples 45 to 46, wherein the received indication that the user equipment has performed a beam failure recovery procedure after a successful handover to the target cell includes the following indications: the beam used by the user equipment to connect to the target cell that caused the beam failure, and the beam used by the user equipment to connect to the target cell that did not cause the beam failure.
[0170] Example 48. According to the apparatus of Example 47, after a failure on a beam that causes beam failure and is used by the user equipment to connect to the target cell, a beam that does not cause beam failure and is used by the user equipment to connect to the target cell is directly used by the user equipment.
[0171] Example 49. An apparatus according to any one of Examples 45 to 48, wherein the received instruction that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes the following instruction: the user equipment performed a beam failure recovery procedure before a timer expired after a successful handover to the target cell.
[0172] Example 50. An apparatus according to any one of Examples 45 to 49, wherein the received indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes the following indication (e.g., the following text indicating that the user equipment performed a beam failure recovery procedure shortly after a successful handover to the target cell).
[0173] Example 51. An apparatus according to any one of Examples 45 to 50, wherein the transmitted instruction that the user equipment has performed a beam failure recovery procedure after a successful handover to the target cell is transmitted to the source central cell on the Xn interface.
[0174] Example 52. An apparatus according to any one of Examples 45 to 51, wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes the following indications: the beam used by the user equipment to connect to the target cell that caused the beam failure, and the beam used by the user equipment to connect to the target cell that did not cause the beam failure.
[0175] Example 53. According to the apparatus of Example 52, after a failure on a beam that causes beam failure and is used by the user equipment to connect to the target cell, a beam that does not cause beam failure and is used by the user equipment to connect to the target cell is directly used by the user equipment.
[0176] Example 54. An apparatus according to any one of Examples 45 to 53, wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes the following indication: the user equipment performed a beam failure recovery procedure before a timer expired after a successful handover to the target cell.
[0177] Example 55. An apparatus according to any one of Examples 45 to 54, wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes the following indication (e.g., the following text indicating that the user equipment performed a beam failure recovery procedure shortly after a successful handover to the target cell).
[0178] Example 56. An apparatus according to any one of Examples 45 to 55, wherein a successful handover to the target cell includes a mobility (LTM) cell handover triggered by Layer 1 or Layer 2.
[0179] Example 57. An apparatus according to any one of Examples 45 to 56, wherein the apparatus includes a central unit, or the central unit includes the apparatus, or the apparatus includes a gNB, or the gNB includes the apparatus, or the radio access network node includes the apparatus, or the apparatus includes a radio access network node.
[0180] Example 58. An apparatus according to any one of Examples 45 to 57, wherein the identifier of the user equipment associated with the target cell includes a temporary identifier of the target cell radio network.
[0181] Example 59. A method comprising: determining, based on measurements received from a user equipment, to trigger a cell handover command for the user equipment; storing measurements received from the user equipment and used for the cell handover decision; marking the stored measurements used for the cell handover decision using an identifier associated with the user equipment and a source cell; receiving an indication that the user equipment performed a beam failure recovery procedure after a successful handover to a target cell due to beam failure of a beam used to connect to the target cell, wherein the received indication that the user equipment performed the beam failure recovery procedure after a successful handover to the target cell includes an indication of an identifier of the user equipment associated with the identifier used to mark the stored measurements; and performing a root cause analysis using the stored measurements marked with the identifier associated with the user equipment and a source cell to determine the root cause of the beam failure used to connect to the target cell.
[0182] Example 60. A method comprising: in response to determining that a user equipment has completed a successful handover to a target cell, starting a timer, wherein a successful handover is triggered as a Layer 1 or Layer 2 mobility (LTM) cell handover; monitoring whether the user equipment performed a beam failure recovery procedure due to beam failure of a beam used to connect to the target cell before the timer expires after a successful handover to the target cell; determining that the user equipment performed a beam failure recovery procedure due to beam failure of a beam used to connect to the target cell before the timer expires after a successful handover to the target cell; and in response to determining that the user equipment performed a beam failure recovery procedure before the timer expires after a successful handover to the target cell, transmitting an indication that the user equipment performed a beam failure recovery procedure due to beam failure of a beam used to connect to the target cell after a successful handover to the target cell, wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes: an indication of an identifier of the user equipment associated with the target cell.
[0183] Example 61. A method comprising: after a user equipment has successfully completed a handover from a source cell to a target cell, storing a mapping between an identifier associated with the source cell and an identifier associated with the target cell of the user equipment; receiving an indication that the user equipment performed a beam failure recovery procedure due to a beam failure for connecting to the target cell after a successful handover to the target cell, wherein the received indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes an indication of the identifier associated with the target cell of the user equipment; determining an identifier associated with the source cell of the user equipment based on the stored mapping, using the identifier associated with the target cell of the user equipment received with the indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell; and transmitting an indication that the user equipment performed a beam failure recovery procedure due to a beam failure after a successful handover to the target cell, wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes an indication of the identifier associated with the source cell of the user equipment determined from the stored mapping.
[0184] Example 62. A method comprising: receiving an indication that a user equipment performed a beam failure recovery procedure after a successful handover to a target cell due to a beam failure of a beam used to connect to the target cell, wherein the received indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes: an indication of an identifier of the user equipment associated with the target cell; and transmitting an indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell, wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes: an indication of an identifier of the user equipment associated with the target cell.
[0185] Example 63. An apparatus comprising: components for triggering a cell handover command to a user equipment based on a measurement received from a user equipment; components for storing measurements received from the user equipment and used for the cell handover decision; components for marking the stored measurements used for the cell handover decision using an identifier associated with the user equipment and the source cell; components for receiving an indication that the user equipment performed a beam failure recovery procedure after a successful handover to a target cell due to beam failure of a beam used to connect to the target cell, wherein the received indication that the user equipment performed the beam failure recovery procedure after a successful handover to the target cell includes an indication of an identifier of the user equipment associated with the identifier used to mark the stored measurements; and components for performing a root cause analysis using the stored measurements marked with the identifier associated with the user equipment and the source cell to determine the root cause of the beam failure used to connect to the target cell.
[0186] Example 64. An apparatus comprising: means for starting a timer in response to determining that a user equipment has completed a successful handover to a target cell, the successful handover being triggered as a Layer 1 or Layer 2 mobility (LTM) cell handover; means for monitoring whether the user equipment performed a beam failure recovery procedure due to beam failure of a beam used to connect to the target cell before the timer expires after a successful handover to the target cell; means for determining that the user equipment performed a beam failure recovery procedure due to beam failure of a beam used to connect to the target cell before the timer expires after a successful handover to the target cell; and means for transmitting an indication in response to determining that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell before the timer expires: the user equipment performed a beam failure recovery procedure due to beam failure of a beam used to connect to the target cell after a successful handover to the target cell, wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes: an indication of an identifier of the user equipment associated with the target cell.
[0187] Example 65. An apparatus includes: components for storing a mapping between an identifier associated with the source cell and an identifier associated with the target cell of a user equipment (UE) after a successful handover from a source cell to a target cell; components for receiving an indication that the UE performed a beam failure recovery procedure due to a beam failure for connecting to the target cell after a successful handover to the target cell, wherein the received indication that the UE performed a beam failure recovery procedure after a successful handover to the target cell includes an indication of the identifier associated with the target cell of the UE; components for determining an identifier associated with the source cell of the UE based on the stored mapping using the identifier associated with the target cell received with the indication that the UE performed a beam failure recovery procedure after a successful handover to the target cell; and components for transmitting an indication that the UE performed a beam failure recovery procedure due to a beam failure after a successful handover to the target cell, wherein the transmitted indication that the UE performed a beam failure recovery procedure after a successful handover to the target cell includes an indication of the identifier associated with the source cell of the UE determined from the stored mapping.
[0188] Example 66. An apparatus comprising: a component for receiving an indication that a user equipment performs a beam failure recovery procedure after a successful handover to a target cell due to a beam failure of a beam used to connect to the target cell, wherein the received indication that the user equipment performed the beam failure recovery procedure after a successful handover to the target cell includes: an indication of an identifier of the user equipment associated with the target cell; and a component for transmitting an indication that the user equipment performed the beam failure recovery procedure after a successful handover to the target cell, wherein the transmitted indication that the user equipment performed the beam failure recovery procedure after a successful handover to the target cell includes: an indication of an identifier of the user equipment associated with the target cell.
[0189] Example 67. A computer-readable medium including instructions stored thereon, the instructions being configured to perform at least the following: determining, based on measurements received from a user equipment, to trigger a cell handover command for the user equipment; storing measurements received from the user equipment and used for the cell handover decision; marking the stored measurements used for the cell handover decision using an identifier associated with the user equipment and the source cell; receiving an indication that, after a successful handover to a target cell, the user equipment performed a beam failure recovery procedure due to beam failure of the beam used to connect to the target cell, wherein the received indication that the user equipment performed the beam failure recovery procedure after a successful handover to the target cell includes an indication of an identifier of the user equipment, the identifier being associated with an identifier used to mark the stored measurements; and performing a root cause analysis using the stored measurements marked with the identifier associated with the user equipment and the source cell to determine the root cause of the beam failure used to connect to the target cell.
[0190] Example 68. A computer-readable medium including instructions stored thereon, the instructions being configured to perform at least the following: in response to determining that a user equipment has completed a successful handover to a target cell, starting a timer, the successful handover being triggered as a Layer 1 or Layer 2 mobility (LTM) cell handover; monitoring whether the user equipment performed a beam failure recovery procedure due to beam failure of the beam used to connect to the target cell after a successful handover to the target cell, before the timer expires; determining that the user equipment performed a beam failure recovery procedure due to beam failure of the beam used to connect to the target cell after a successful handover to the target cell, before the timer expires; and in response to determining that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell, before the timer expires, transmitting an indication that the user equipment performed a beam failure recovery procedure due to beam failure of the beam used to connect to the target cell after a successful handover to the target cell, wherein the transmitted indication that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes: an indication of an identifier of the user equipment associated with the target cell.
[0191] Example 69. A computer-readable medium includes instructions stored thereon for performing at least the following: after a user equipment (UE) has successfully completed a handover from a source cell to a target cell, storing a mapping between an identifier associated with the source cell and an identifier associated with the target cell for the UE; receiving an indication that the UE performed a beam failure recovery procedure due to a beam failure for connecting to the target cell after a successful handover to the target cell, wherein the received indication that the UE performed a beam failure recovery procedure after a successful handover to the target cell includes an indication of the identifier associated with the target cell for the UE; determining an identifier associated with the source cell for the UE based on the stored mapping, using the identifier associated with the target cell for the UE received along with the indication that the UE performed a beam failure recovery procedure after a successful handover to the target cell; and transmitting an indication that the UE performed a beam failure recovery procedure due to a beam failure after a successful handover to the target cell, wherein the transmitted indication that the UE performed a beam failure recovery procedure after a successful handover to the target cell includes an indication of the identifier associated with the source cell for the UE determined from the stored mapping.
[0192] Example 70. A computer-readable medium including instructions stored thereon, the instructions being configured to perform at least the following: receiving an instruction that a user equipment performs a beam failure recovery procedure after a successful handover to a target cell due to beam failure of a beam used to connect to the target cell, wherein the received instruction that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes: an indication of an identifier of the user equipment associated with the target cell; and transmitting an instruction that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell, wherein the transmitted instruction that the user equipment performed a beam failure recovery procedure after a successful handover to the target cell includes: an indication of an identifier of the user equipment associated with the target cell.
[0193] References to "computer," "processor," etc., should be understood to include not only computers with different architectures (such as single-processor / multi-processor architectures and sequential or parallel architectures), but also special-purpose circuits, such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), signal processing devices, and other processing circuits. References to computer programs, instructions, code, etc., should be understood to include software or firmware for programmable processors, such as the programmable content of hardware devices, whether it is instructions for the processor or configuration settings for fixed-function devices, gate arrays, or programmable logic devices.
[0194] The memory described herein can be implemented using any suitable data storage technology, such as semiconductor-based memory devices, flash memory, magnetic storage devices and systems, optical storage devices and systems, non-transitory memory, transient memory, fixed memory, and removable memory. The memory may include a database for storing data.
[0195] The term “non-transient” as used in this article refers to the limitation on the medium itself (i.e., tangible, not signaling), rather than the limitation on the persistence of data storage (e.g., RAM versus ROM).
[0196] As used herein, the term "circuit" may refer to: (a) a hardware circuit implementation, such as an implementation in analog and / or digital circuitry; and (b) a combination of circuitry and software (and / or firmware), such as (if applicable): (i) a combination of (multiple) processors or (ii) a portion of (multiple) processors / software, including (multiple) digital signal processors, software, and memory working together to enable a device to perform various functions; and (c) a circuit, such as (multiple) microprocessors or a portion of (multiple) microprocessors, which requires software or firmware to operate, even if the software or firmware is not physically present. As another example, as used herein, the term "circuit" will also cover an implementation of a processor (or multiple processors) or a portion of a processor and its (or their) accompanying software and / or firmware. For example, and if applicable to a particular element, the term "circuit" will also cover a baseband integrated circuit or application processor integrated circuit for use in a mobile phone or server, cellular network equipment, or another network device.
[0197] It should be understood that the foregoing description is illustrative only. Various alternatives and modifications can be conceived by those skilled in the art. For example, the features recited in the dependent claims can be combined with each other in any suitable combination(s). Furthermore, features in the different example embodiments described above can be selectively combined to form new example embodiments. Therefore, this description is intended to cover all such alternatives, modifications, and variations that fall within the scope of the appended claims.
[0198] The following explains the abbreviations and acronyms that may appear in the instruction manual and / or drawings (abbreviations and acronyms may be added to / combined with each other, or added to / combined with other characters by means of, for example, dashes, hyphens, forward slashes, letters or numbers, and may not be case-sensitive): 3GPP Third Generation Partnership Project 4G fourth generation 5G (Fifth Generation) 5GC 5G core network AMF access and mobility management functions ASIC (Application-Specific Integrated Circuit) BF beam failure BFD Beam Failure Detection BFR beam failure recovery CD Case / Computer Disk CE control elements CPU (Central Processing Unit) C-RNTI Radio Network Temporary Identifier CSI Channel State Information CU (Centralized Unit) DC Dual Connection DL downlink DSP Digital Signal Processor DU Distributed Unit DVD Digital Multifunction Disc eNB Evolved Node B (e.g., LTE base station) EN-DC E-UTRAN New Radio - Dual Connectivity The en-gNB provides the UE with the node for terminating NR user plane and control plane protocols, and acts as a secondary node in the EN-DC. EPC Evolution Group Core E-UTRA evolved UMTS terrestrial radio access, namely LTE radio access technology. E-UTRAN E-UTRA Network Interface between F1 CU and DU FPGA (Field Programmable Gate Array) gNB (Next Generation Node B) or generalized Node B is a base station used for 5G / NR; that is, a node that provides NR user plane and control plane protocol termination to the UE and connects to the 5GC via the NG interface. HO switch HWC switched to the wrong cell IAB Integration Access and Backhaul ID identifier IE Information Elements I / F interface I / O Input / Output L1 Floor 1 L2 Floor 2 L3 Floor 3 LMF location management function LTE Long Term Evolution (4G) LTM L1 / L2 triggered mobility MAC Media Access Control MAC CE Media Access Control Element MME (Mobility Management Entity) MRO Mobility Robustness Optimization NCE Network Control Components ng or NG, next generation ng-eNB, the next generation of eNB NG-RAN (Next Generation Radio Access Network) NR Radio N / W network PDA (Personal Digital Assistant) PDCP (Packet Data Convergence Protocol) PHY physical layer PRACH (Physical Random Access Channel) RACH Random Access Channel RAM (Random Access Memory) RAN (Radio Access Network) RAN2 Radio Layer 2 RAN-3 Radio Layer 3 Rel release RLC Radio Link Control RLF radio link failure ROM (Read-Only Memory) RRC Radio Resource Control RU radio unit Rx receiver or receiver The interface between the Mobility Management Entity (MME) in S1 EPC and the Evolved Node B in E-UTRAN SDAP Service Data Adaptation Protocol SGW Service Gateway SHR Successful Switch Report SMF Session Management Function SON (Self-Organizing Network or Self-Optimizing Network) TA scheduled in advance TCI Transmission Configuration Instructions Premature TEH switchover TLH switching too late TRP Transmitter / Receiver Point TS Technical Specifications Tx transmission, or transmitter UAV (Unmanned Aerial Vehicle) UE (User Equipment) (e.g., wireless, typically mobile devices) UI (User Interface) UL uplink UMTS (Universal Mobile Telecommunications System) UPF User Plane Functions USB Universal Serial Bus UTRAN (Universal Terrestrial Radio Access Network) Network interfaces between X2 RAN nodes and between the RAN and the core network Network interface between Xn NG RAN nodes
Claims
1. A device for communication, comprising: At least one processor; as well as At least one memory storing instructions that, when executed by the at least one processor, cause the device to at least: Based on measurements received from the user equipment, a cell handover command for the user equipment is triggered. The measurements received from the user equipment and used for cell handover decisions are stored; The stored measurements used for the cell handover decision are marked using the identifier associated with the source cell of the user equipment; The user equipment received the following instruction: After a successful handover to the target cell, it performed a beam failure recovery procedure due to beam failure of the beam used to connect to the target cell. The received indication that the user equipment performed the beam failure recovery procedure after the successful handover to the target cell includes an indication of the user equipment's identifier, which is associated with an identifier used to mark the stored measurement; as well as Root cause analysis is performed using the stored measurements used for cell handover decisions, which are marked with the identifier associated with the source cell by the user equipment, to determine the root cause of the beam failure for connecting to the target cell.
2. The apparatus of claim 1, wherein the at least one memory stores instructions that, when executed by the at least one processor, cause the apparatus to at least: Based on the aforementioned root cause analysis, at least one decision criterion used for future mobility decisions or future handover decisions is modified.
3. The apparatus of claim 2, wherein the future mobility decision or future handover decision includes a layer 1 or layer 2 triggered cell handover.
4. The apparatus according to any one of claims 1 to 3, wherein the received indication that the user equipment performed the beam failure recovery procedure after the successful handover to the target cell includes the following indications: the beam used by the user equipment to connect to the target cell that caused the beam failure, and the beam used by the user equipment to connect to the target cell that did not cause the beam failure.
5. The apparatus of claim 4, wherein the at least one memory stores instructions that, when executed by the at least one processor, cause the apparatus to at least: Based on the received indications of the beam that causes the beam to fail and the beam that does not cause the beam to fail, used by the user equipment to connect to the target cell, at least one decision criterion for future mobility decisions or future handover decisions is modified.
6. The apparatus of claim 4, wherein after a failure on the beam used by the user equipment to connect to the target cell that caused the beam failure, the beam used by the user equipment to connect to the target cell that did not cause the beam failure is directly used by the user equipment.
7. The apparatus according to any one of claims 1 to 3, wherein the at least one memory stores instructions, the instructions causing the apparatus to at least: Maintain a counter for the number of beam failure recovery processes that have occurred after a successful handover to the target cell; In response to receiving an indication that the user equipment performed the beam failure recovery procedure after the successful handover to the target cell, the counter is incremented, the indication including the indication of the user equipment's identifier, the identifier being associated with an identifier used to mark the stored measurement; and Based on the counter of the number of beam failure recovery processes that have occurred after a successful handover to the target cell, at least one decision criterion used for future mobility decisions or future handover decisions is modified.
8. The apparatus of claim 7, wherein the at least one memory stores instructions that, when executed by the at least one processor, cause the apparatus to at least: Monitoring statistics, including a counter representing the number of beam failure recovery processes that have occurred following a successful handover to the target cell; and Based on the monitoring of the statistical information, the at least one decision criterion used for the future mobility decision or the future handover decision is modified, the statistical information including a counter of the number of beam failure recovery processes that have occurred after a successful handover to the target cell.
9. The apparatus of claim 8, wherein the at least one memory stores instructions that, when executed by the at least one processor, cause the apparatus to at least: Maintain another counter for the number of beam failure recovery processes that have occurred after a successful handover to another target cell; In response to receiving another indication that the user equipment performed a beam failure recovery procedure after a successful handover to the other target cell, the other counter is incremented, the other indication including another indication of the user equipment's identifier, the identifier being associated with the identifier used to mark the stored measurement; and Based on the other counter, which represents the number of beam failure recovery processes that have occurred after a successful handover to the other target cell, the at least one decision criterion used for future mobility decisions or future handover decisions is modified.
10. The apparatus of claim 9, wherein the at least one memory stores instructions that, when executed by the at least one processor, cause the apparatus to at least: The statistics monitor the statistical information, which includes another counter representing the number of beam failure recovery processes that have occurred following a successful handover to the other target cell; and Based on the monitoring of the statistical information, the at least one decision criterion used for the future mobility decision or the future handover decision is modified, the statistical information including another counter for the number of beam failure recovery processes that have occurred after a successful handover to the other target cell.