Optimized network method for handling ltm cell handover failure

Abstract

Various methods (e.g., enhancements through network signaling) are introduced to support LTM functionality to self-optimize in terms of LTM preparation (e.g., determining / adjusting the LTM candidate cell list configured to the UE) and LTM execution (e.g., determining / adjusting which cell among the LTM candidates is the most suitable to be selected and the time at which LTM execution should be triggered). LTM related information collected by the UE for supporting SON functionality (e.g., LTM related information contained in RA reports, RLF reports, and successful handover reports) is used to analyze and optimize LTM related failures, such as LTM cell handover too early, LTM cell handover too late, or LTM cell handover to wrong cell. Methods of transferring RLF reports and failure analysis results between gNB-CU and gNB-DU are also described.

Description

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 575252, filed April 5, 2024, the entire disclosure of which is incorporated herein by reference. Background Technology

[0002] Wireless communication networks, including network nodes and wireless network devices such as mobile phones and smartphones, are widely used in many parts of the world. The capacity and complexity of these networks are constantly increasing. To accommodate more users and more types of devices that may benefit from wireless communication, the technical standards governing the operation of wireless communication networks are also continuously evolving. The fourth-generation network standard (4G, also known as Long Term Evolution or LTE) has been deployed, the fifth generation (5G, also known as New Radio or NR) is under development or in its early stages of deployment, and the sixth generation (6G) is in the planning stages. The specific technical standards defining the new network characteristics and capabilities are issued by the Third Generation Partnership Project (3GPP) in a series of numbered versions (e.g., Rel. 15, Rel. 16, etc.).

[0003] Both LTE and NR networks follow a “cellular” architecture, in which multiple typically fixed network nodes (called base stations, also known as eNBs in LTE and gNBs in NR) provide wireless communication services to fixed and mobile radio network equipment within a coverage area or “cell,” which are collectively referred to herein as User Equipment (UE). The term “cell” also refers to the single logical entity that provides wireless communication services; therefore, a base station can provide multiple cells.

[0004] Until LTE, base stations (eNB) were all standalone entities. NR introduced the concept of splitting base stations (gNB) into central units (CU) and distributed units (DU). Figure 1 This architecture is illustrated. Access and Mobility Management Functions (AMF) and / or User Plane Functions (UPF) in the core network are connected to base stations (gNBs). Each gNB is divided into one CU and multiple DUs. The split point between the CU and DU in the network protocol stack is typically implemented above the Radio Link Control (RLC) layer, where RLC, MAC, and Physical Layer (PHY) are implemented in the DU, while RRC, Packet Data Convergence Protocol (PDCP), and higher-layer functions are implemented in the CU.

[0005] Mobility is a fundamental aspect of wireless communication networks. As a UE moves within a geographical area, it moves from one cell to another. The UE periodically measures the signal strength and quality of its air interface with its current serving cell and with neighboring cells. When a neighboring cell consistently provides a higher quality channel, the network performs a "handover" process, transferring control and service to the UE from the current or "source" cell to the new or "target" cell. Therefore, this operation is also known as "cell handover." Ideally, the handover or cell handover process is transparent to the user, and the user does not experience any degradation in the quality of ongoing calls or data streams during the process.

[0006] LTM support in 3GPP Rel-18

[0007] Traditionally, handover is performed via Radio Resource Control (RRC) signaling, a higher-level signaling protocol. Therefore, handover involves significant signaling transmission over the air interface and substantial processing at the UE, consuming battery power. Version 18 introduces a cell handover triggered by the Media Access Control (MAC) layer instead of RRC. This process operates at a lower layer of the protocol stack (e.g., Layer 1 or Layer 2) and is called L1 / L2 Triggered Mobility (LTM). Compared to RRC handover, LTM enables faster cell handover with lower overhead and therefore lower power consumption.

[0008] A general description of L1 / L2 triggered mobility (LTM) operations can be found in 3GPP TS 38.300 v18.0.0 (Section 9.2.3.5). An excerpt follows:

[0009] LTM is a procedure in which the gNB receives L1 measurement reports from the UE. Based on these reports, the gNB changes the UE's serving cell via a cell handover command issued via MACCE signaling. The cell handover command indicates a candidate LTM configuration that the gNB has previously prepared and provided to the UE via RRC signaling. The UE then switches to the target configuration according to the cell handover command. Using the LTM procedure can reduce mobility latency as described in Appendix G.

[0010] The following principles apply to LTM:

[0011] • Maintain the security key during LTM cell handover;

[0012] • Supports subsequent LTM.

[0013] LTM supports intra-gNB-DU mobility and inter-gNB-DU mobility within a gNB-CU. LTM supports both intra-frequency and inter-frequency mobility, including movement to a non-serving inter-frequency cell. LTM only supports licensed spectrum. It supports the following scenarios:

[0014] • Pcell changes in non-CA and non-DC scenarios;

[0015] • Changes to PCell and Scell ​​in CA scenarios;

[0016] • Changes to PCell and MCG Scell ​​in dual-connectivity scenarios, and changes to PSCell and SCGScell ​​within the SN without MN involvement. LTM does not support simultaneous changes to PCell and PSCell.

[0017] Even though the UE has stored LTM candidate configurations, the UE can still execute any L3 handover command sent by the network.

[0018] Figure 2 Reproduced the version in TS 38.300 v18.0.0 Figure 9 Section 2.3.5.2-1, “Signaling Procedure of LTM,” illustrates the overall procedure of LTM.

[0019] TS 38.401 v18.0.0 describes in more detail intra-NR mobility when using LTM, involving split-deployment gNBs, namely intra-gNB-DU LTM (Section 8.2.1.4), inter-gNB-DU LTM (Section 8.2.1.5), and LTM accompanying gNB-CU-UP changes (Section 8.2.1.6).

[0020] Figure 3 Reproduced the version in TS 38.401 v18.0.0 Figure 8 Section 2.1.4-1 illustrates the signaling process of LTM within the gNB-DU.

[0021] Figure 4 Reproduced the version in TS 38.401 v18.0.0 Figure 8 .2.1.5-1 illustrates the signaling process of LTM between gNB-DU.

[0022] Radio Link Failure (RLF) Reporting in Self-Organizing Networks (SONs)

[0023] Radio Link Failure Report (RLF Report) was introduced as a Self-Organizing Network (SON) function to improve mobility robustness. This report is generated by the UE when a Radio Link Failure (RLF) or Handover Failure (HOF) occurs and is retrieved by the network. The network then uses its contents to analyze the problems leading to the failure and to find network optimization solutions to improve overall mobility robustness within the mobile network. For NG-RAN, it is defined in TS 38.300 v18.0.0 as follows:

[0024] To analyze connection failures, the UE enables the RLF report to indicate network availability.

[0025] The UE stores the latest RLF report (including LTE RLF report and NR RLF report) until the network obtains the RLF report, or stores it for 48 hours after a connection failure is detected.

[0026] The UE only instructs RLF report availability and provides RLF reports to the network if the current RPLMN is a PLMN existing in the UE's EPLMN list or if the RPLMN at the time of the detected connection failure is an RLFMN. If the RLF occurs in an E-UTRA cell, the UE makes LTE RLF reports available to NG-RAN nodes and eNBs; if the RLF occurs in an NR cell, the UE makes NR RLF reports available to gNBs.

[0027] If an LTE RLF report is reported to an NG-RAN node and the previous serving node is an E-UTRAN node, the NG-RAN node can trigger an uplink RAN ​​configuration transmission procedure via NG to transmit the report to the E-UTRAN node, and the E-UTRAN node can take the report into consideration as defined in TS 36.300.

[0028] RLF reports are also used to detect failure types. For in-NG-RAN mobility, these types are defined in TS 38.300v18.0.0 as follows:

[0029] One of the functions of mobile robustness optimization is to detect connection failures caused by handovers that occur too early, too late, or to the wrong cell. These problems are defined as follows:

[0030] • Late intra-system handover: The UE experiences an RLF after staying in a cell for an extended period of time; the UE attempts to rebuild the radio link connection in different cells.

[0031] • Premature intra-system handover: An RLF occurs shortly after a successful handover from the source cell to the target cell, or a handover failure occurs during the handover process; the UE attempts to rebuild the radio link connection in the source cell.

[0032] • Intra-system handover to the wrong cell: An RLF occurs shortly after a successful handover from the source cell to the target cell, or a handover failure occurs during the handover process; the UE attempts to rebuild the radio link connection in a cell other than the source cell and the target cell.

[0033] In the above definition, "successful handover" refers to the UE state, that is, the successful completion of the random access (RA) process.

[0034] In the case of Conditional Handover (CHO), the handover too late, handover too early, and handover to the wrong cell in the above definitions refer to CHO execution too late, CHO execution too early, and CHO execution to the wrong cell, respectively.

[0035] Several challenges remain. Based on published technologies, how to perform self-optimization for LTM is unclear. For example, it is unclear how to reduce potential failures in the various steps involved in LTM, such as the LTM preparation phase, in which the gNB (or more specifically, the gNB-CU) prepares LTM candidate cells; or the LTM execution phase, in which the gNB (or more specifically, the gNB-DU) decides to send a cell handover command to the UE.

[0036] The background section of this document is provided to place various aspects of this disclosure within a technical and operational context to assist those skilled in the art in understanding their scope and utility. The methods described in the background section may be employed, but are not necessarily methods previously conceived or employed. Unless expressly stated otherwise, nothing herein is to be acknowledged as prior art simply by virtue of its inclusion in the background section. Summary of the Invention

[0037] The following is a brief overview of this disclosure to enable those skilled in the art to gain a basic understanding of it. This summary is not intended to be a complete overview of the disclosure, nor is it intended to identify key / essential elements of any aspect of the disclosure or to define its scope. The sole purpose of this summary is to present certain concepts disclosed herein in a simplified form as a prelude to the more detailed description that follows.

[0038] Based on the various aspects of this disclosure described and claimed herein, a variety of methods (e.g., through network signaling enhancement) are introduced to support the self-optimization of LTM functionality, covering LTM preparation aspects (e.g., determining / adjusting the list of LTM candidate cells configured for the UE) and LTM execution aspects (e.g., determining / adjusting the most suitable cell among the LTM candidate cells and the timing for triggering LTM execution). LTM-related information collected by the UE to support SON functionality (e.g., LTM-related information contained in RA reports, RLF reports, and successful handover reports) is used to analyze and optimize LTM-related failures, such as premature LTM cell handover, late LTM cell handover, or LTM cell handover to the wrong cell.

[0039] Methods for transmitting RLF reports and failure analysis results between gNB-CU and gNB-DU are also described. These methods include: methods for determining the cause and type of failure after an RLF occurs due to LTM mobility; optimization actions that network nodes can take to optimize LTM mobility and avoid future failures (and their signaling transmission between CU and DU); and methods for transmitting RLF reports and failure analysis results between gNB-CU and gNB-DU.

[0040] One aspect relates to a method performed by a UE operating in a wireless communication network for providing information on Recurrent Function Failures (RLFs) related to an LTM cell handover process. The method involves receiving an LTM candidate cell list from a base station serving the UE, receiving an LTM cell handover command from the serving base station, attempting an LTM cell handover and experiencing an RLF in the form of an LTM failure, and preparing a Sort of Names (SON) report for LTM, which includes information related to the LTM failure, to enable the network to analyze the LTM failure and optimize the network to avoid future LTM failures.

[0041] On the other hand, a method is provided by a CU (Commission Unit) of a base station serving a UE in a wireless communication network for performing network optimization after a Recurrent Function Failure (RLF) occurs in the UE, which is related to an LTM cell handover process (LTM failure). The method includes receiving RRC (Recurrent Rectification) signaling to rebuild the UE in the wireless communication network after an LTM failure. It also involves obtaining a SON (Signaling Message for LTM) prepared by the UE, which includes information related to the LTM failure. The method further involves determining the LTM failure type, selecting one or more DUs (Dedicated Units) of the base station based on the LTM failure type, and sending at least a portion of the SON report for LTM to the selected DUs.

[0042] Another aspect involves a method executed by the current CU of the current base station for performing network optimization after a Recurrent Leak (RLF) occurs at the UE, where the current base station serves the UE in the first RAN of the wireless communication network. This RLF is related to an LTM cell handover process (LTM failure). A Sonographic Information Report (SON) prepared by the UE for LTM is obtained, including information related to the LTM failure. Based on this SON report, it is determined that prior to the LTM mobility execution, the UE was served by a previous CU of a previous base station, which is different from the current CU. The SON report for LTM obtained from the UE is then sent to the previous CU.

[0043] Another aspect involves a network node that performs network optimization after a UE experiences an RLF (Recurrent Leakage Failure) related to the LTM (LTM Failure) cell handover process. This network node includes processing circuitry and power supply circuitry. The processing circuitry is configured to execute the second method described above, and the power supply circuitry is configured to supply power to the processing circuitry.

[0044] Another aspect involves a network node that performs network optimization after a UE experiences an RLF (Recurrent Leakage Failure) related to the LTM (LTM Failure) cell handover process. This network node includes processing circuitry and power supply circuitry. The processing circuitry is configured to execute the third method described above, and the power supply circuitry is configured to supply power to the processing circuitry.

[0045] Another aspect relates to a UE that provides RLF information related to LTM cell handover procedures. The UE includes: an antenna configured to transmit and receive radio signals; and radio frequency front-end circuitry connected to the antenna and processing circuitry. The processing circuitry is configured to regulate the signals transmitted between the antenna and the processing circuitry, and is configured to perform the first method described above. The UE also includes: an input interface connected to the processing circuitry and configured to allow information to be input into the UE for processing by the processing circuitry; and an output interface connected to the processing circuitry and configured to output the information processed by the processing circuitry from the UE. The UE also includes a battery connected to the processing circuitry and configured to power the UE. Attached Figure Description

[0046] The present disclosure will now be described more fully with reference to the accompanying drawings, in which various aspects of the disclosure are illustrated. However, the disclosure should not be construed as limited to the aspects set forth herein. Rather, these aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art. Throughout the drawings, the same reference numerals refer to the same elements.

[0047] Figure 1 This is a schematic diagram showing the network and the gNB split into CUs and multiple DUs.

[0048] Figure 2 It is a signaling diagram. Figure 2 This reproduces the feature from 3GPP TS 38.401 v18.0.0. Figure 9 2.3.5.2-1: Signaling process of LTM.

[0049] Figure 3 It is a signaling diagram. Figure 3 This reproduces the feature from 3GPP TS 38.401 v18.0.0. Figure 8 2.1.4-1: gNB-DU internal LTM.

[0050] Figure 4 It is a signaling diagram. Figure 4 This reproduces the feature from 3GPP TS 38.401 v18.0.0. Figure 8 2.1.5-1: gNB-DU internal LTM.

[0051] Figure 5The signaling diagram illustrates the following: In the case of a late LTM cell handover, the UE generates an RLF report containing LTM information. The reconstructed cell is in the LTM cell handover candidate list, and the gNB-CU does not perform optimization on the LTM candidate cell list.

[0052] Figure 6 The signaling diagram illustrates the following: In the case of a late LTM cell handover, the UE generates an RLF report containing LTM information. The rebuilt cell is not in the LTM cell handover candidate list, and the gNB-CU performs optimization on the LTM candidate cell list.

[0053] Figure 7 The signaling diagram illustrates the following: In the case of "Early LTM Cell Handover," the UE generates an RLF report containing LTM information. In this case, the gNB-CU does not perform optimization on the LTM cell handover candidate list. This scenario may occur when the UE attempts to rebuild to a cell already in the LTM cell handover candidate list. The gNB-DU performs optimization on LTM cell handover triggers.

[0054] Figure 8 The signaling diagram shows the following: In the case of a handover from an LTM cell to an incorrect cell, the UE generates an RLF report containing LTM information.

[0055] Figure 9 The signaling diagram illustrates the following: the UE generates an RLF report containing LTM information, and the gNB-CU performs optimization on the LTM candidate cell list.

[0056] Figure 10 This is a flowchart of a method performed by a UE operating in a wireless communication network to provide information about the RLF related to the LTM cell handover process.

[0057] Figure 11 This is a flowchart of a method for performing network optimization after a UE experiences an RLF (Redirecting Function Failure) in a wireless communication network, which is executed by the CU (Committee Unit) of the base station serving the UE. This RLF is related to the LTM (Ltdling Time Management) cell handover process (LTM failure).

[0058] Figure 12 This is a flowchart of a method for performing network optimization after a UE experiences an RLF, executed by the current CU of the current base station. The current base station serves the UE in the first RAN of the wireless communication network. The RLF is related to an LTM cell handover process (LTM failure), in which the UE was previously connected to a different CU.

[0059] Figure 13 This is a schematic diagram of a wireless communication network.

[0060] Figure 14 Is Figure 13 A schematic diagram of a UE operating in a wireless communication network is shown.

[0061] Figure 15 yes Figure 13 The diagram shows a network node used as a base station in a wireless communication network.

[0062] Figure 16 It is connected to Figure 13 The diagram shows a virtualized environment for a wireless communication network. Detailed Implementation

[0063] For simplicity and illustrative purposes, this disclosure is described primarily with reference to exemplary aspects. Numerous specific details are set forth in the following description to provide a thorough understanding of this disclosure. However, it will be readily apparent to those skilled in the art that this disclosure can be practiced without being limited by these specific details. Well-known methods and structures are not described in detail in this description to avoid unnecessarily obscuring this disclosure.

[0064] In this disclosure, a user equipment (UE) refers to any device using a wireless network service. A network node refers to a node capable of providing services to a UE. The solution is described for L1 / L2 triggered mobility in NR, but can be extended to other radio access technologies (e.g., 6G).

[0065] This disclosure applies to all scenarios of LTM, including, for example, Pcell changes, PSCell changes, and SCell changes.

[0066] The LTM configuration provided to the UE may include one or more candidate target cells, wherein the UE (and the target gNB-DU) is prepared for a potential LTM cell handover to each of the one or more candidate target cells. In this document, such candidate target cells may be referred to as “candidate target cell,” “LTM candidate target cell,” “candidate LTM target cell,” “candidate cell,” “LTM candidate cell,” “candidate LTM cell,” “LTM handover candidate cell,” “LTM handover candidate,” or “LTM cell handover candidate.” These one or more candidate target cells may be collectively referred to as the “LTM candidate list,” “LTM candidate cell list,” or “LTM cell handover candidate list.” As used herein, “LTM failure” refers to a radio link failure (RLF) that occurs during, is caused by, immediately follows, or is otherwise related to the LTM cell handover for the UE.

[0067] In this disclosure, these methods are described with reference to NR as a reference radio technology. This should be considered non-limiting, as the methods described herein are applicable to any radio access technology that supports LTM mobility.

[0068] In this disclosure, it is assumed that the UE experienced a failure related to LTM mobility. Examples of failures and related content logged by the UE include:

[0069] LTM cell handover too late

[0070] ◦ An RLF occurs after the UE has stayed in a cell for an extended period of time; the UE attempts to rebuild the radio link connection in a different cell that is an LTM cell handover candidate.

[0071] ◦ An RLF occurs after the UE has stayed in a cell for an extended period of time; the UE attempts to rebuild the radio link connection in a different cell that is not an LTM cell handover candidate.

[0072] • Premature LTM cell handover

[0073] ◦ An RLF occurs shortly after the LTM from the source cell to the target cell is successfully executed; the UE attempts to rebuild the radio link connection in the source cell.

[0074] ◦ An LTM failure occurs during LTM execution; the UE attempts to rebuild the radio link connection in the source cell.

[0075] • LTM cell switched to the wrong cell

[0076] ◦ An RLF occurs shortly after a successful LTM execution from the source cell to the target cell; the UE attempts to rebuild the radio link connection in a cell other than the source cell and the target cell that is an LTM candidate cell.

[0077] ◦ An LTM failure occurs during LTM execution; the UE attempts to rebuild the radio link connection in a cell other than the source cell and the target cell, and which is not an LTM candidate cell.

[0078] In the case of "late LTM cell handover," if the cell to which the UE performs reconstruction is not included in the LTM candidate cell list, one possible remedy is to include that cell in the LTM candidate cell list. This action can be performed by the gNB-CU and is described in one aspect of this disclosure. Another scenario is that the cell to which the UE performs reconstruction is already included in the LTM candidate cell list, so the action required to improve the situation is not in the gNB-CU, but in the gNB-DU. For example, the gNB-DU could determine to trigger a subsequent cell handover command to the cell that the UE reported as the reconstruction cell in the RLF report after a previous failure; or trigger a subsequent similar LTM procedure earlier / more aggressively based on L1 measurement reports, for example, by using an internal decision threshold that causes the LTM procedure to be triggered earlier (e.g., the serving cell uses a higher RSRP threshold, and / or neighboring cells use a lower RSRP threshold).

[0079] In another aspect of the "late LTM cell handover" scenario, the correction action is determined by the gNB-CU and then signaled to the gNB-DU. Specifically, the gNB-CU can learn that an RLF occurred during LTM mobility and the UE re-established itself to an LTM cell handover candidate. The gNB-CU can learn of this situation, for example, by correlating the re-establishment event (and its details contained in, for example, an RRCReestablishmentRequest) with other information (e.g., receiving an F1: DU-CU CellSwitch Notification message and / or an LTM cell handover candidate list), or by receiving an RLF report from the UE that details information about the RLF report.

[0080] Once the gNB-CU obtains information about the RLF and can classify the failure as "LTM cell handover too late," the gNB-CU can send information to the gNB-DU signaling aimed at preventing such failures from occurring in the future. This information can be provided to the gNB-DU on a cell-pair basis (e.g., for a given source cell and a given target cell) or as general information independent of the source and target cells. This information may include one or more of the following:

[0081] • Instructions regarding the need to advance the LTM cell handover trigger point by a certain amount (e.g., in dB). In other words, the handover trigger point needs to be moved by the offset indicated by gNB-CU to gNB-DU.

[0082] • Regarding the source cell signal, the LTM cell handover trigger point needs to be advanced (i.e., triggered earlier) by a certain amount of indication. For example, the source cell signal should be x dBm higher than the previous source cell signal at the LTM mobility trigger point associated with failure, or at least the previous source cell signal at the previous LTM mobility trigger point.

[0083] • Regarding the requirement to advance the LTM cell handover trigger point (i.e., trigger earlier) by a certain amount for the target cell signal. For example, the target cell signal should be y dBm lower than the previous source cell signal at the LTM mobility trigger point associated with failure or the previous source cell signal at the previous LTM mobility trigger point.

[0084] • Regarding the need to advance the LTM cell handover trigger point by a certain amount (i.e., trigger earlier) for both source and target cell signals. For example, the source cell signal should be x dBm higher than the previous source cell signal at the LTM mobility trigger point, and the target cell signal should be y dBm lower than the previous source cell signal at the LTM mobility trigger point. Furthermore, a difference threshold between the source and target cell signals can be provided, indicating that handover should only be triggered if the difference between the source and target cells exceeds the indicated difference.

[0085] In the case of "premature LTM cell handover," the rebuilt cell is the same as the source cell, and therefore this cell is already one of the cells involved in the LTM process. Therefore, the action required to improve the situation is not at the gNB-CU, but at the gNB-DU. For example, in one aspect, the gNB-DU's action is to trigger subsequent similar LTM processes later / less aggressively based on L1 measurement reports, for example, by using internal decision thresholds that cause the LTM process to be triggered later (e.g., the serving cell uses a lower RSRP threshold, and / or neighboring cells use a higher RSRP threshold).

[0086] In another aspect related to the "premature LTM cell handover" scenario, the correction action is determined by the gNB-CU and then signaled to the gNB-DU. Specifically, the gNB-CU can learn that an RLF occurred during LTM mobility and the UE re-established itself to the source cell. The gNB-CU can learn of this situation, for example, by correlating the re-establishment event (and its details contained in, for example, the RRCReestablishmentRequest) with other information (e.g., information in a received F1:DU-CU Cell Switch Notification message), or by receiving an RLF report from the UE that details information about the RLF report.

[0087] Once the gNB-CU obtains information about the RLF and can classify the failure as "premature LTM cell handover," the gNB-CU can send information to the gNB-DU signaling aimed at preventing such failures from occurring in the future. This information can be provided to the gNB-DU on a cell-pair basis (e.g., for a given source cell and a given target cell) or as general information independent of the source and target cells. This information may include one or more of the following:

[0088] • Instructions regarding the need to delay the LTM cell handover trigger point (i.e., to trigger it later) by a certain amount (e.g., in dB). In other words, the handover trigger point needs to be moved by the offset indicated by gNB-CU to gNB-DU.

[0089] • Regarding the source cell signal, there is an indication that the LTM cell handover trigger point needs to be delayed (i.e., triggered later) by a certain amount. For example, the source cell signal should be x dBm lower than the previous source cell signal at the LTM mobility trigger point associated with the failure, or at least the previous source cell signal at the previous LTM mobility trigger point.

[0090] • An indication that the LTM cell handover trigger point needs to be delayed (i.e., triggered later) by a certain amount for the target cell signal. For example, the target cell signal should be y dBm higher than the previous source cell signal at the LTM mobility trigger point associated with the failure or the previous source cell signal at the previous LTM mobility trigger point.

[0091] • An indication is provided regarding the need to delay the LTM cell handover trigger point (i.e., trigger it later) by a certain amount for both the source and target cell signals. For example, the source cell signal should be x dBm lower than the previous source cell signal at the LTM mobility trigger point, and the target cell signal should be y dBm lower than the previous source cell signal at the LTM mobility trigger point. Furthermore, a threshold value indicating the difference between the source and target cell signals can be provided, indicating that handover should only be triggered if the difference between the source and target cells exceeds the indicated value.

[0092] In the case of "LTM cell handover to the wrong cell," the re-established cell may or may not be included in the LTM candidate cell list. In the latter case, one possible optimization is to add the re-established cell to the LTM candidate cell list at the gNB-CU. Conversely, if the re-established cell is already included in the LTM candidate cell list, the action required to improve the situation is not at the gNB-CU, but at the gNB-DU. For example, the gNB-DU can determine whether to send the next cell handover command to the re-established cell based on adjusting the gNB-DU's internal decision threshold for the involved LTM candidate cell.

[0093] In another aspect related to the "LTM cell handover to the wrong cell" scenario, the correction action is determined by the gNB-CU and then signaled to the gNB-DU. Specifically, the gNB-CU can learn that an RLF occurred during LTM mobility and the UE rebuilt to a cell different from the target cell. The gNB-CU can learn of this situation, for example, by correlating the rebuild event (and its details contained in, for example, the RRCReestablishmentRequest) with other information (e.g., information contained in a received F1: DU-CU CellSwitch Notification message), or by receiving an RLF report from the UE that details information about the RLF report.

[0094] Once the gNB-CU obtains information about the RLF and can classify the failure as an "LTM cell handover to wrong cell," the gNB-CU can send information to the gNB-DU signaling aimed at preventing such failures from occurring in the future. This information can be provided to the gNB-DU by source cell and by one or more potential target cells. This information may include the following:

[0095] Regarding LTM mobility from a given source cell to one or more potential target cells indicated by the gNB-CU, an indication should be made that one potential target cell should take precedence over the others. In a variation, the gNB-CU may also indicate an offset by which the handover trigger point to such a priority cell should be advanced, or a value representing the priority level of the potential target cell.

[0096] The UE records LTM-related mobility information in one or more SON reports, such as in RA reports, RLF reports, and successful handover reports. In the remainder of this disclosure, UE reports that include LTM-related information (such as RLF reports) are also referred to as SON reports for LTM (or UE reports for LTM).

[0097] NG-RAN nodes can reuse existing mechanisms to obtain SON reports for LTM, and in the case of NG-RAN nodes deployed in a split architecture, the gNB-CU obtains the SON reports for LTM.

[0098] In one aspect, the gNB-CU receives a SON report for LTM from the UE and performs preliminary analysis to determine which entity (gNB-CU, gNB-DU, or both gNB-CU and gNB-DU) can utilize the information in the SON report for LTM to optimize LTM-related configurations. This determination may, for example, include associating the received SON report for LTM with a specific LTM cell handover failure type (e.g., "LTM cell handover too late," "LTM cell handover too early," or "LTM cell handover to the wrong cell"). The gNB-CU may then forward the SON report for LTM (or at least a portion of the information contained therein) to one or more gNB-DUs, optionally also providing the gNB-DU with an indication of the LTM cell handover failure type associated with the report (or the forwarded portion of the information in the report). The gNB-CU determines the gNB-DU to contact based on information included in the SON report used for LTM, such as: the cell identifier of the cell serving the UE before attempting an LTM cell handover, the candidate cell to which the UE attempted an LTM handover, or the cell identifier of the cell to which the UE re-established or attempted to re-establish after an LTM cell handover failure.

[0099] • gNB-CU can send an indication of LTM cell handover failure type to gNB-DU.

[0100] • The gNB-CU can send multiple SON reports for LTM to the same gNB-DU through a single non-UE associated signaling message, or send partial information from each of the multiple SON reports for LTM (involving the same UE or multiple UEs).

[0101] In one aspect, the gNB-CU sends one or more SON reports (or portions thereof) for LTM and an LTM cell handover failure type to the gNB-DU, and the LTM cell handover failure type is explicitly signaled. In one possible implementation example, the signaling message used for this purpose is a new message, such as an F1AP CELL SWITCH MOBILITY REPORT message.

[0102] In some aspects, when sending the SON report for LTM to the gNB-DU, the gNB-CU does not send any indication of the LTM cell handover failure type, but instead leaves the analysis to the gNB-DU. Optionally, the gNB-CU may implicitly or explicitly indicate that it expects the gNB-DU to report the results of the gNB-DU's analysis of the SON report data for LTM. An example of an implicit request could be the presence of one or more specific IEs (without conveying an explicit request) in the message sending the SON report data for LTM to the gNB-DU, or the absence of one or more specific IEs. Another example of an implicit request could be that the standard specifies that the gNB-DU should report the results of its analysis of the SON report data for LTM received from the gNB-CU back to the gNB-CU (in which case, an explicit request for such a report need not be included in the message transmitting the SON report data for LTM from the gNB-CU to the gNB-DU).

[0103] On the other hand, gNB-CU can indicate the possible causes or types of transmission failures, for example, as guidance for gNB-DU to analyze the SON report data received from gNB-CU for LTM.

[0104] In another aspect or others, while sending the SON report data for LTM to the gNB-DU, the gNB-CU also instructs on suggested or recommended configuration adjustments to take into account the SON report data for LTM.

[0105] In another aspect or others, when sending the SON report data for LTM to gNB-DU, gNB-CU also includes additional information that is generated, determined, or identified by gNB-CU during the analysis of the SON report data for LTM. This additional information may be related to LTM-related configurations that gNB-CU applies to the LTM process or LTM configuration (and / or applies during the LTM process) and that are relevant to at least a portion of the SON report data for LTM.

[0106] In one aspect, the gNB-CU awaits feedback / notification from the gNB-DU before determining whether (and if so, executing) further actions related to LTM optimization (e.g., the gNB-CU determines whether the LTM candidate cell list needs modification and performs the update if necessary). Regarding this aspect, as another option, the gNB-CU may not analyze the SON report data used for LTM itself (except when determining which relevant gNB-DU should forward the SON report data for LTM), but instead forward the SON report data for LTM to the gNB-DU, allowing the gNB-DU to perform analysis (including preliminary analysis) and inform the gNB-CU of the analysis results and / or any appropriate actions to be taken to incorporate the SON report data for LTM, and / or may instruct the gNB-CU whether it should analyze the SON report data for LTM itself (or whether such analysis would be beneficial).

[0107] On the other hand, gNB-CU determines, based on the content of the SON report used for LTM, that the existing list of LTM candidate cells needs to be updated.

[0108] For example, this could happen if the SON report used for LTM indicates that the cell the UE is trying to reconnect to is not included in the current LTM candidate cell list.

[0109] In one aspect, the scenario described above may occur when the gNB-CU does not read / interpret the Layer 1 (L1) measurement results included in the SON report used for LTM and the gNB-CU does not wait for feedback / instructions from the gNB-DU. For example, the following situation may occur: the gNB-DU determines that the UE has reported other cells included in the LTM candidate cell list, but the gNB-DU makes the decision to send a cell handover command too late, and LTM execution fails. If there is no feedback from the gNB-DU to the gNB-CU, and the gNB-CU does not read / interpret the L1 measurement results, the gNB-CU may assume that the cell the UE reconnects to or attempts to reconnect to is a good LTM candidate and include that cell in the LTM candidate cell list for subsequent LTM configurations (optionally, only if the conditions are similar to those of the LTM procedure targeted by the SON report used for LTM, such as L1 measurement results).

[0110] On the other hand, the scenario described above may occur when the gNB-CU reads / interprets the Layer 1 (L1) measurement results included in the SON report used for LTM and compares them with the L3 measurement reports included in the UE's RLF report. For example, the gNB-CU may consider not only the L3 measurement reports to generate the candidate cell list for the LTM procedure, but also the L1 measurement reports. For instance, if the L1 measurements performed before the RLF show poor values ​​for a candidate target cell, while the L3 measurements are still satisfactory, the gNB-CU may determine to remove the cell from the candidate target cell list.

[0111] In one aspect, the L1 measurement results included in the UE's RLF report are reported according to a range of values ​​standardized in the L1 specification, such as -140 dBm to -40 dBm, with a resolution of 1 dB, just as the L1 reported values ​​included in the L1 UCI signaling, where reported value 17 indicates that SS-RSRP is greater than or equal to -156 dB and reported value 112 indicates that SS-RSRP is less than or equal to -45 dBm.

[0112] In another embodiment, the L1 measurement results included in the UE's RLF report are reported according to a standardized value range in the RRC specification, for example, a defined range of -156 dBm to -31 dBm with a resolution of 1 dB, where a reported value of 0 indicates that the SS-RSRP is greater than or equal to -156 dB, and a reported value of 126 indicates that the SS-RSRP is less than or equal to -31 dBm. According to this latter embodiment, the UE first determines the L1 measurement results at a lower layer, and when declaring the RLF / HOF, the UE converts the determined L1 measurement values ​​to equivalent values ​​standardized in the RRC specification.

[0113] In one aspect, if the gNB-CU is responsible for reading the reported L1 measurements and taking action based on these values, the UE includes the corresponding measurements standardized in the RRC specification in the RLF report; otherwise, if the gNB-DU is responsible for reading the reported L1 measurements and taking action based on these values, the UE includes the corresponding measurements standardized in the L1 specification in the RLF report.

[0114] In one aspect, the gNB-DU requests SON reports (or portions thereof) for LTM from the gNB-CU before receiving them. The advantage of this mechanism is that it allows the gNB-DU to control the inflow of LTM-optimization-related signaling from the gNB-CU. For example, the F1AP message CELL SWITCH MOBILITY REPORT REQUEST (or a similar message) can be used, in which the gNB-DU indicates to the gNB-CU that it intends (or no longer intends) to receive SON reports (or portions thereof) for LTM. Alternatively, this request can be refined to indicate different types of SON reports, for example, indicating an intention to receive certain SON reports (or portions thereof) for LTM (which is equivalent to requesting to receive these SON reports for LTM), and / or indicating an inadvertence to receive certain SON reports (or portions thereof) for LTM (which is equivalent to requesting not to receive these SON reports for LTM).

[0115] In one aspect, one of the gNB-DUs associated with the gNB-CU provides feedback to the gNB-CU (e.g., via a newly defined F1AP CELL SWITCH MOBILITY FEEDBACK message). Such messages can be used to provide the gNB-CU with indications / information that it can use to determine whether (further) LTM-related optimizations are needed. A non-limiting example of such indications could be an indication that "the LTM candidate list needs to be updated" or "the LTM candidate list does not need to be updated," and / or a suggestion / recommendation to perform an update to the LTM candidate list (e.g., a suggestion / recommendation to add one or more cells to the list and / or remove one or more cells from the list). In a dependent embodiment, the gNB-CU performs LTM-related optimizations, such as updating the LTM candidate cell list, based on the feedback received from the gNB-DU.

[0116] In the other case, the gNB-CU receives the SON report for LTM from the UE and performs preliminary analysis, determining that the UE is connected to a cell served by another RAN node (e.g., another gNB-CU) before LTM mobility is performed. The gNB-CU then sends the SON report for LTM to that other RAN node (e.g., that other gNB-CU).

[0117] Figure 5 The diagram illustrates how, based on signaling from one aspect, a UE generates an RLF report containing LTM information in the case of "LTM cell handover too late." In this scenario, the gNB-CU does not perform optimization on the LTM cell handover candidate list. This scenario may occur when a UE attempts to rebuild to a cell that is already part of the LTM cell handover candidate list after encountering an RLF in the source / serving cell.

[0118] Figure 6 The diagram illustrates how, based on signaling from one aspect, a UE generates an RLF report containing LTM information in the case of "Late LTM Cell Handover." In this scenario, the gNB-CU optimizes the LTM cell handover candidate list. This scenario can occur when a UE (after an LTM handover failure or shortly after a successful LTM handover) attempts to rebuild to a cell that is not part of the LTM cell handover candidate list, and the gNB-CU adds the rebuilding cell to the list.

[0119] Figure 7 The diagram illustrates how, based on signaling from one aspect, a UE generates an RLF report containing LTM information in the case of "Early LTM Cell Handover." In this scenario, the gNB-CU does not perform optimization on the LTM cell handover candidate list. This scenario may occur when the UE attempts to re-establish itself on a cell that is already part of the LTM cell handover candidate list. The gNB-DU performs optimization on LTM cell handover triggers.

[0120] Figure 8 The diagram illustrates how, based on signaling from one aspect, a UE generates an RLF report containing LTM information in the case of an "LTM cell handover to the wrong cell." In this scenario, the gNB-CU does not perform optimization on the LTM cell handover candidate list. This scenario may occur when the UE attempts to rebuild to a cell other than the source and target cells, and the rebuilding cell is already part of the LTM cell handover candidate list. The gNB-DU performs optimization on the LTM cell handover trigger.

[0121] Figure 9 The diagram illustrates how, based on signaling from one aspect, a UE generates an RLF report containing LTM information in the case of an "LTM cell handover to the wrong cell." In this scenario, the gNB-CU optimizes the LTM cell handover candidate list. This can occur when the UE attempts to rebuild to a cell other than the source and target cells, and the rebuilding cell is not part of the LTM cell handover candidate list. The gNB-CU then adds the rebuilding cell to the LTM cell handover candidate list.

[0122] Implementation examples in the standard

[0123] The following provides some non-restrictive implementation examples of TS 38.473 and TS 38.423.

[0124] The following is an example of how some embodiments are implemented in the standard for the F1AP interface:

[0125] 9.2.10.1 Access and Mobility Indicators

[0126] This message is sent from gNB-CU to gNB-DU to provide access and mobility information to gNB-DU.

[0127] Direction: gNB-CU gNB-DU.

[0128]

[0129]

[0130]

[0131] In the example above, the ACCESS AND MOBILITY INDICATION message already present on the F1 interface is enhanced to include information about the failure result analysis performed by the gNB-CU. Therefore, the gNB-DU receives the RRC RLF-Report-r16 IE as part of the NR UE RLF report container IE, and also receives the failure analysis results from the gNB-CU. This enables the gNB-DU to take corrective actions to prevent LTE failures.

[0132] In another example of one of the above aspects, the gNB-CU can send an RLF report and a new failure type to the gNB-DU in a new UE-associated F1AP message.

[0133] Cell handover mobility report

[0134] The message is sent from NG-RAN node 1 to NG-RAN node 2 to report an LTM cell handover failure event.

[0135] Direction: NG-RAN Node 1 NG-RAN node 2.

[0136]

[0137]

[0138] In another example of one of the aspects described above, the gNB-CU may include information in a new message sent to the gNB-DU regarding how the LTM mobility handover trigger point should be changed from one cell to another. This enhancement may be provided as a standalone enhancement or along with other information, such as the information shown in the previous example.

[0139] 9.1.3.xx LTM Mobility Adjustment Request

[0140] This message is sent from gNB-CU to gNB-DU to initiate mobility parameter adjustments.

[0141] Direction: NG-RAN Node 1 NG-RAN node 2.

[0142]

[0143] 9.2.2.yy LTM Mobility Parameter Information

[0144] The LTM mobility parameter information (IE) includes changes to the LTM mobility trigger relative to its current value. The LTM mobility trigger corresponds to the threshold used by a cell to initiate an LTM mobility procedure to a specific neighboring cell. A change to a positive value indicates a recommendation to postpone LTM mobility.

[0145]

[0146] In the example above, a new message is described from gNB-CU signaling to gNB-DU, which instructs gNB-DU how the LTM mobility trigger point between the two cells (source cell and potential target cell) should be changed.

[0147] method

[0148] Figure 10 The steps of method 100, performed by a UE operating in a wireless communication network, are illustrated for providing information about an LTM cell handover failure (RLF) related to the LTM cell handover process. The steps include: receiving an LTM candidate cell list from the base station serving the UE (box 102); receiving an LTM cell handover command from the serving base station (box 104); attempting an LTM cell handover (box 106); if no RLF is experienced (box 108), the UE hands over to a new cell (box 110); if an RLF in the form of an LTM failure is experienced (box 108), a SON report for LTM is prepared, including information related to the LTM failure, to enable the network to analyze the LTM failure and optimize the network to avoid future LTM failures (box 112). Upon reconnection to the network, the SON report can be sent to a network node.

[0149] Figure 11The steps of method 200 are illustrated, which is performed by a CU of a base station serving a UE in a wireless communication network for performing network optimization after the UE experiences an RLF (LTM Failure) related to an LTM cell handover process. The steps include: receiving RRC signaling to rebuild the UE in the wireless communication network after an LTM failure (box 202); obtaining a SON report for LTM prepared by the UE, which includes information related to the LTM failure (box 204); determining the LTM failure type (box 206); selecting one or more DUs of the base station based on the LTM failure type (box 208); and sending at least a portion of the SON report for LTM to the selected DUs (box 210).

[0150] Figure 12 The steps of method 300 are illustrated, which is performed by the current CU of the current base station serving the UE in a first RAN of the wireless communication network for performing network optimization after the UE experiences an LTM cell handover-related RLF (LTM Failure). A SON report for LTM prepared by the UE is obtained, which includes information related to the LTM failure. Based on the SON report, it is determined that prior to the LTM mobility execution, the UE was served by a previous CU of a previous base station, which is different from the current CU. The SON report for LTM obtained from the UE is sent to the previous CU.

[0151] Network and device description

[0152] Figure 13 An example of a communication system QQ100 according to some embodiments is shown.

[0153] In this example, the communication system QQ100 includes a telecommunications network QQ102, which includes an access network QQ104 (e.g., a radio access network RAN) and a core network QQ106. The core network QQ106 includes one or more core network nodes QQ108. The access network QQ104 includes one or more access network nodes, such as network nodes QQ110a and QQ110b (one or more of which may generally be referred to as network node QQ110), or any other similar 3GPP access node or non-3GPP access point. Furthermore, those skilled in the art will understand that network nodes are not necessarily limited to an implementation where the radio and baseband portions are provided by a single vendor and integrated. Therefore, it should be understood that network nodes include decomposed implementations or portions thereof. For example, in some embodiments, the telecommunications network QQ102 includes one or more Open RAN (ORAN) network nodes. An ORAN network node is a node in the QQ102 telecommunications network that supports ORAN specifications (e.g., specifications published by the O-RAN Alliance or any similar organization) and can operate alone or with other nodes to perform one or more functions of any node in the QQ102 telecommunications network (including one or more network nodes QQ110 and / or core network nodes QQ108).

[0154] Examples of ORAN network nodes include Open Radio Units (O-RUs), Open Distributed Units (O-DUs), Open Central Units (O-CUs) (including O-CU control planes (O-CU-CPs) or O-CU user planes (O-CU-UPs)), RAN intelligent controllers (near real-time or non-real-time) with managed software or software plug-ins (e.g., near real-time control applications (e.g., xApps) or non-real-time control applications (e.g., rApps)), or any combination thereof (the adjective "open" indicates support for the ORAN specification). Network nodes can support the specification, for example, by supporting interfaces defined by the ORAN specification (e.g., A1, F1, W1, E1, E2, X2, or Xn interfaces, Open Fronthaul User Plane Interfaces, or Open Fronthaul Management Plane Interfaces). Furthermore, ORAN access nodes can be logical nodes within physical nodes. Additionally, ORAN network nodes can be implemented in a virtualized environment (described further below) where one or more network functions are virtualized. For example, the virtualized environment may include an O-Cloud computing platform orchestrated by a service management and orchestration framework via the O-2 interface or similar technologies defined by the O-RAN Alliance. Network node QQ110 connects UEs QQ112a, QQ112b, QQ112c and QQ112d (one or more of which may generally be referred to as UE QQ112) to core network QQ106 via one or more wireless connections, thereby facilitating direct or indirect connections of user equipment (UE).

[0155] Exemplary wireless communication via a wireless connection includes sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information without the use of wires, cables, or other conductors. Furthermore, in various embodiments, the communication system QQ100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that can facilitate or participate in data and / or signal transmission via wired or wireless connections. The communication system QQ100 may include any type of communication, telecommunications, data, cellular, radio network, and / or other similar system, and / or interface with such systems.

[0156] UE QQ112 can be any of a wide variety of communication devices, including wireless devices that are deployed, configured, and / or operable to communicate wirelessly with network node QQ110 and other communication devices. Similarly, network node QQ110 is deployed, capable of, configured, and / or operable to communicate directly or indirectly with UE QQ112 and / or with other network nodes or devices in telecommunication network QQ102 to achieve and / or provide network access (e.g., wireless network access) and / or perform other functions (e.g., management) in telecommunication network QQ102.

[0157] In the depicted example, core network QQ106 connects network node QQ110 to one or more host computing systems, such as host QQ116. These connections can be direct or indirect via one or more intermediate networks or devices. In other examples, network nodes can be directly coupled to hosts. Core network QQ106 includes one or more core network nodes (e.g., core network node QQ108), which are composed of hardware and software components. The characteristics of these components can be substantially similar to those described with respect to UEs, network nodes, and / or hosts, such that the description is generally applicable to the corresponding components of core network node QQ108. Example core network nodes include one or more of the following functions: Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier Dehiding Function (SIDF), Unified Data Management (UDM), Security Edge Protection Agent (SEPP), Network Open Function (NEF), and / or User Plane Function (UPF).

[0158] Host QQ116 may be owned or controlled by a service provider other than the operator or provider of access network QQ104 and / or telecommunications network QQ102. Host QQ116 may host a variety of applications to provide one or more services. Examples of such applications include real-time and pre-recorded audio / video content, data collection services (e.g., retrieving and compiling data on various environmental conditions detected by multiple UEs), analytics functions, social media, functions for controlling or interacting with remote devices, functions for alarms and monitoring centers, or any other such functions performed by the server.

[0159] Overall, Figure 13 The QQ100 communication system enables connections between the UE, network nodes, and the host. In this sense, the communication system can be configured to operate according to predefined rules or procedures (e.g., specific standards), including but not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE) and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., sixth generation (6G)); Wireless Local Area Network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi); and / or any other suitable wireless communication standards, such as Global Microwave Access Interoperability (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC), ZigBee, LiFi, and / or any Low Power Wide Area Network (LPWAN) standards, such as LoRa and Sigfox.

[0160] In some examples, the QQ102 telecommunications network is a cellular network implementing 3GPP standardized features. Therefore, the QQ102 network can support network slicing to provide different logical networks to different devices connected to it. For example, the QQ102 network can provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs while providing enhanced mobile broadband (eMBB) services to other UEs, and / or massive machine-type communication (mMTC) / massive Internet of Things (IoT) services to yet another UE.

[0161] In some examples, UE QQ112 is configured to send and / or receive information without direct human interaction. For example, the UE may be designed to send information to access network QQ104 according to a predetermined schedule when triggered by internal or external events or in response to a request from access network QQ104. Furthermore, the UE may be configured to operate in single RAT, multi-RAT, or multi-standard modes. For example, the UE may operate using any or a combination of WiFi, NR (New Radio), and LTE, i.e., configured for multiple radio dual connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) NR-Dual Connectivity (EN-DC).

[0162] In this example, the central QQ114 communicates with the access network QQ104 to facilitate indirect communication between one or more UEs (e.g., UEQQ112c and / or QQ112d) and a network node (e.g., network node QQ110b). In some examples, the central QQ114 may be a controller, router, content source and analyzer, or any other communication device described herein with respect to the UE. For example, the central QQ114 may be a broadband router that enables the UE to access the core network QQ106. As another example, the central QQ114 may be a controller that sends commands or instructions to one or more actuators in the UE. Commands or instructions may be received from the UE, network node QQ110, or generated by executable code, scripts, processes, or other instructions in the central QQ114. As another example, the central QQ114 may be a data collector that acts as temporary storage for UE data, and in some embodiments, analysis or other processing may be performed on the data. As another example, the central QQ114 may be a content source. For example, for a UE in the form of a VR device, display, speaker, or other media delivery device, the central QQ114 can retrieve VR assets, videos, audio, or other media or data related to sensory information via network nodes, and then provide them directly to the UE after performing local processing and / or adding additional local content. In yet another example, the central QQ114 acts as a proxy server or orchestrator for the UE, particularly when one or more of the UEs are low-power Internet of Things (IoT) devices.

[0163] The central hub QQ114 can have a continuous / permanent or intermittent connection with the network node QQ110b. The central hub QQ114 can also allow different communication schemes and / or scheduling between the central hub QQ114 and the UE (e.g., UE QQ112c and / or QQ112d), and between the central hub QQ114 and the core network QQ106. In other examples, the central hub QQ114 is connected to the core network QQ106 and / or one or more UEs via a wired connection. Furthermore, the central hub QQ114 can be configured to connect to a machine-to-machine (M2M) service provider via the access network QQ104, and / or to another UE via a direct connection. In some scenarios, the UE can establish a wireless connection with the network node QQ110 while still being connected via the central hub QQ114 via a wired or wireless connection. In some embodiments, the central hub QQ114 can be a dedicated hub, i.e., its primary function is to route communication between the UE and the network node QQ110b. In other embodiments, the central hub QQ114 may be a non-dedicated hub—that is, a device capable of operating to route communication between the UE and the network node QQ110b, but also capable of serving as the starting and / or ending point of communication for certain data channels.

[0164] Figure 14 A UE QQ200 according to some embodiments is shown. The UE QQ200 provides... Figure 2 Further details of some embodiments of the UE QQ112 shown are provided below. As used herein, a UE refers to a device capable of, configured, positioned, and / or operable to wirelessly communicate with network nodes and / or other UEs. Examples of UEs include, but are not limited to: smartphones, mobile phones, cellular phones, VoIP phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage / playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablets, laptops, laptop embedded devices (LEEs), laptop mounted devices (LMEs), augmented reality (AR) or virtual reality (VR) devices, wireless client terminal equipment (CPEs), vehicles, in-vehicle or vehicle-mounted / integrated wireless devices, etc. Other examples include any UE identified by 3GPP, including narrowband Internet of Things (NB-IoT) UEs, machine-type communication (MTC) UEs, and / or enhanced machine-type communication (eMTC) UEs.

[0165] The UE can support device-to-device (D2D) communication, for example, by implementing 3GPP standards for sidelink communication, Dedicated Short Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, the UE may not necessarily be a user in the sense of a human user, i.e., a human user who owns and / or operates the associated device. Instead, the UE may represent a device intended to be sold to or operated by a human user, but which may not or initially may not be associated with a particular human user (e.g., a smart sprinkler controller). Alternatively, the UE may represent a device not intended to be sold to or operated by an end user, but which may be associated with or operated for the benefit of a user (e.g., a smart meter).

[0166] UE QQ200 includes processing circuitry QQ202, which is operatively coupled via bus QQ204 to input / output interface QQ206, power supply QQ208, memory QQ210, communication interface QQ212, and / or any other component, or any combination thereof. Some UEs may utilize Figure 14 All or some of the components shown. The level of integration between components may vary from UE to UE. In addition, some UEs may contain multiple instances of components, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0167] The processing circuit QQ202 is configured to process instructions and data and can be configured to implement any sequential state machine operable to execute instructions stored as a machine-readable computer program in memory QQ210. The processing circuit QQ202 can be implemented as: one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, a general-purpose processor (e.g., a microprocessor or digital signal processor (DSP)) together with appropriate software; or any combination of the foregoing. For example, the processing circuit QQ202 may include multiple central processing units (CPUs).

[0168] In this example, the input / output interface QQ206 can be configured to provide one or more interfaces to input devices, output devices, or one or more input and / or output devices. Examples of output devices include speakers, sound cards, graphics cards, displays, monitors, printers, actuators, transmitters, smart cards, other output devices, or any combination thereof. Input devices can allow users to capture information into the UE QQ200. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital camcorders, webcams, etc.), microphones, sensors, mice, trackballs, directional keyboards, touchpads, scroll wheels, smart cards, etc. Presence-sensitive displays may include capacitive or resistive touch sensors to sense input from the user. Sensors may be, for example, accelerometers, gyroscopes, tilt sensors, force sensors, magnetometers, optical sensors, proximity sensors, biometric sensors, etc., or any combination thereof. Output devices can use the same type of interface port as input devices. For example, a Universal Serial Bus (USB) port can be used to provide both input and output devices.

[0169] In some embodiments, the power supply QQ208 is configured as a battery or battery pack. Other types of power sources can be used, such as an external power source (e.g., a power outlet), a photovoltaic device, or a battery. The power supply QQ208 may also include power supply circuitry for delivering power from the power supply QQ208 itself and / or an external power source to various parts of the UEQQ200 via input circuitry or an interface (e.g., a power cable). The power delivery may be for example, to charge the power supply QQ208. The power supply circuitry may perform any formatting, conversion, or other modifications on the power from the power supply QQ208 to suit the various components of the UE QQ200 being powered.

[0170] The memory QQ210 can be, or can be configured to include, memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), disk, optical disk, hard disk, removable cassette tape, flash drive, etc. In one example, the memory QQ210 includes one or more application programs QQ214, such as an operating system, web browser application, widget, utility engine, or other application, and corresponding data QQ216. The memory QQ210 can store any of a variety of operating systems or combinations of operating systems for use by the UE QQ200.

[0171] The QQ210 memory can be configured to include multiple physical drive units, such as a Redundant Array of Independent Disks (RAID), flash memory, a USB flash drive, an external hard drive, a thumb drive, a pen drive, a key drive, a high-density digital multifunction optical disc (HD-DVD) drive, an internal hard drive, a Blu-ray disc drive, a holographic digital data storage (HDDS) disc drive, an external mini dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro DIMM SDRAM, a smart card memory, such as a tamper-proof module in the form of a Universal Integrated Circuit Card (UICC), including one or more Subscriber Identity Modules (SIMs), such as a Universal Subscriber Identity Module (USIM) and / or an IP Multimedia Service Identity Module (ISIM), other memory, or any combination thereof. The UICC can be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly referred to as a "SIM card." The QQ210 memory can allow the UE QQ200 to access instructions, applications, etc., stored on transient or non-transient storage media to unload or upload data. Articles of art (e.g., articles of art utilizing a communication system) may be tangibly embodied in or contained in memory QQ210, which may be or include a device-readable storage medium.

[0172] The processing circuitry QQ202 can be configured to communicate with an access network or other network using a communication interface QQ212. The communication interface QQ212 may include one or more communication subsystems and may include an antenna QQ222 or be communicatively coupled to the antenna QQ222. The communication interface QQ212 may include one or more transceivers for communication, such as through one or more remote transceivers communicating with another device capable of wireless communication (e.g., another UE or a network node in the access network). Each transceiver may include a transmitter QQ218 and / or a receiver QQ220 suitable for providing network communication (e.g., optical, electrical, frequency allocation, etc.). Furthermore, the transmitter QQ218 and receiver QQ220 may be coupled to one or more antennas (e.g., antenna QQ222) and may share circuit components, software, or firmware, or alternatively, be implemented separately.

[0173] In the illustrated embodiment, the communication functions of the communication interface QQ212 may include cellular communication, WiFi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication (e.g., Bluetooth), near-field communication, location-based communication (e.g., using a Global Positioning System (GPS) to determine location), other similar communication functions, or any combination thereof. Communication can be implemented according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, NR, UMTS, WiMax, Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Optical Network (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), etc.

[0174] Regardless of the sensor type, the UE can provide the output of data captured by its sensors via its communication interface QQ212, through a wireless connection with a network node. Data captured by the UE's sensors can be transmitted wirelessly to the network node via another UE. The output can be periodic (e.g., every 15 minutes if sensed temperature is reported), random (e.g., to balance the load generated by multiple sensor reports), responsive to a triggered event (e.g., sending an alarm when humidity is detected), responsive to a request (e.g., a user-initiated request), or a continuous stream (e.g., real-time video feed of a patient).

[0175] As another example, the UE includes actuators, motors, or switches associated with a communication interface configured to receive wireless input from a network node via a wireless connection. The state of the actuator, motor, or switch can change in response to the received wireless input. For example, the UE may include a motor that adjusts the control surfaces or rotors of a flying drone based on the received input, or adjusts a robotic arm performing a medical procedure.

[0176] When the UE is in the form of an Internet of Things (IoT) device, it can be a device used in one or more application areas, including but not limited to urban wearable technology, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices include devices or devices embedded in the following: connected refrigerators or freezers, televisions, connected lighting devices, electricity meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door / window sensors, flood / humidity sensors, electronic door locks, connected doorbells, air conditioning systems (such as heat pumps), autonomous vehicles, surveillance systems, weather monitoring devices, vehicle parking monitoring devices, electric vehicle charging stations, smartwatches, fitness trackers, wearable devices for haptic or sensory enhancement, sprinklers, animal or object tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any type of medical device, such as heart rate monitors or remote-controlled surgical robots. In addition to the above, IoT device forms of UEs also include... Figure 14 In addition to the other components described in the UE QQ200 shown, it also includes circuitry and / or software depending on the intended application of the IoT device.

[0177] As another concrete example, in IoT scenarios, a UE can represent a machine or other device performing monitoring and / or measurement, and sending the results of such monitoring and / or measurement to another UE and / or network node. In this case, the UE can be an M2M device, which can be referred to as an MTC device in the 3GPP context. As a specific example, the UE can implement the 3GPP NB-IoT standard. In other scenarios, the UE can represent a vehicle, such as a car, bus, truck, ship, and aircraft, or other device capable of monitoring and / or reporting its operational status or other functions related to its operation.

[0178] In practice, any number of UEs can be used together for a single use case. For example, the first UE can be a drone or integrated into a drone, providing the drone's speed information (obtained via a speed sensor) to a second UE (a remote controller operating the drone). When the user makes changes from the remote controller, the first UE can adjust the drone's throttle (e.g., by controlling the actuators) to increase or decrease the drone's speed. The first UE and / or the second UE can also include more than one of the functions described above. For example, the UE can include sensors and actuators, and handle data communication between both the speed sensor and the actuators.

[0179] Figure 15A network node QQ300 according to some embodiments is illustrated. As used herein, a network node refers to a device capable of, configured, arranged, and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or devices in a telecommunications network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., wireless base stations, NodeBs, evolved NodeBs (eNBs), and NR NodeBs (gNBs)), O-RAN nodes, or components of O-RAN nodes (e.g., O-RUs, O-DUs, O-CUs).

[0180] Base stations can be classified based on the coverage they provide (or, in other words, their transmit power level); therefore, depending on the coverage provided, a base station can be called a femtobase, picobase, microbase, or macrobase. A base station can be a relay node or a relay donor node controlling a relay. Network nodes can also include one or more (or all) portions of a distributed radio base station, such as centralized digital units, distributed units (e.g., in O-RAN access nodes), and / or remote radio units (RRUs), sometimes referred to as remote radio headends (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna-integrated radio. A portion of a distributed radio base station can also be referred to as a node in a distributed antenna system (DAS).

[0181] Other examples of network nodes include multi-transmitter point (multi-TRP) 5G access nodes, multi-standard radio (MSR) devices (e.g., MSR BS), network controllers (e.g., Radio Network Controller (RNC) or Base Station Controller (BSC)), Base Transceiver Stations (BTS), transmitter points, transmitter nodes, multi-cell / multicast coordination entities (MCE), operations and maintenance (O&M) nodes, operations support system (OSS) nodes, self-organizing network (SON) nodes, location nodes (e.g., evolved Serving Mobility Location Center (E-SMLC)), and / or minimized drive test (MDT).

[0182] Network node QQ300 includes processing circuitry QQ302, memory QQ304, communication interface QQ306, and power supply QQ308. Network node QQ300 may consist of multiple physically separate components (e.g., NodeB components and RNC components, or BTS components and BSC components, etc.), each component may have its corresponding components. In some scenarios where network node QQ300 includes multiple separate components (e.g., BTS and BSC components), one or more separate components may be shared among multiple network nodes. For example, a single RNC can control multiple NodeBs. In such scenarios, each unique NodeB and RNC pair may, in some cases, be considered a single, individual network node. In some embodiments, network node QQ300 may be configured to support multiple RATs. In such embodiments, some components may be replicated (e.g., a separate memory QQ304 for different RATs), while some components may be reused (e.g., the same antenna QQ310 may be shared by different RATs). The network node QQ300 may also include multiple sets of various components shown for different wireless technologies (such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, RFID, or Bluetooth wireless technologies). These wireless technologies may be integrated into the same or different chips or chipsets and other components within the network node QQ300.

[0183] The processing circuitry QQ302 may include one or more of the following: a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field-programmable gate array or any other suitable computing device, resource, or combination of hardware, software and / or coding logic, which is operable to provide the functionality of the network node QQ300 alone or in combination with other components of the network node QQ300 (e.g., memory QQ304).

[0184] In some embodiments, the processing circuit QQ302 includes a system-on-a-chip (SOC). In some embodiments, the processing circuit QQ302 includes one or more of a radio frequency (RF) transceiver circuit QQ312 and a baseband processing circuit QQ314. In some embodiments, the RF transceiver circuit QQ312 and the baseband processing circuit QQ314 may be on separate chips (or chipsets), boards, or units, such as radio units and digital units. In alternative embodiments, some or all of the RF transceiver circuit QQ312 and the baseband processing circuit QQ314 may be on the same chip or chipset, board, or unit.

[0185] The memory QQ304 may include any form of volatile or non-volatile computer-readable memory, including but not limited to persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, RAM, ROM, mass storage media (e.g., hard disk), removable storage media (e.g., flash drive, optical disc (CD), or digital video disc (DVD)) and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions usable by the processing circuitry QQ302. The memory QQ304 may store any suitable instructions, data, or information, including computer programs, software, applications including logic, rules, code, tables, and / or other instructions executable by the processing circuitry QQ302 and usable by the network node QQ300. The memory QQ304 may be used to store any calculations performed by the processing circuitry QQ302 and / or any data received via the communication interface QQ306. In some embodiments, the processing circuitry QQ302 and the memory QQ304 are integrated together.

[0186] Communication interface QQ306 is used for wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As shown, communication interface QQ306 includes a port / terminal QQ316 for transmitting and receiving data to and from the network, for example, via a wired connection. Communication interface QQ306 also includes radio front-end circuitry QQ318, which may be coupled to antenna QQ310, or in some embodiments, is part of antenna QQ310. Radio front-end circuitry QQ318 includes a filter QQ320 and an amplifier QQ322. Radio front-end circuitry QQ318 may be connected to antenna QQ310 and processing circuitry QQ302. Radio front-end circuitry QQ318 can be configured to modulate the signal transmitted between antenna QQ310 and processing circuitry QQ302. Radio front-end circuitry QQ318 can receive digital data to be transmitted to other network nodes or UEs via a wireless connection. Radio front-end circuitry QQ318 can use a combination of filter QQ320 and / or amplifier QQ322 to convert the digital data into a radio signal with appropriate channel and bandwidth parameters. This radio signal can then be transmitted via antenna QQ310. Similarly, when receiving data, antenna QQ310 can collect radio signals, which are then converted into digital data by radio front-end circuitry QQ318. The digital data can then be passed to processing circuitry QQ302. In other embodiments, the communication interface may include different components and / or different combinations of components.

[0187] In some alternative embodiments, network node QQ300 does not include a separate radio front-end circuit QQ318; instead, processing circuitry QQ302 includes the radio front-end circuitry and is connected to antenna QQ310. Similarly, in some embodiments, all or part of the RF transceiver circuitry QQ312 is part of communication interface QQ306. In other embodiments, communication interface QQ306 includes one or more ports or terminals QQ316, radio front-end circuitry QQ318, and RF transceiver circuitry QQ312 as part of a radio unit (not shown), and communication interface QQ306 communicates with baseband processing circuitry QQ314 as part of a digital unit (not shown).

[0188] Antenna QQ310 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals. Antenna QQ310 may be coupled to radio front-end circuitry QQ318 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna QQ310 is decoupled from network node QQ300 and may be connected to network node QQ300 via an interface or port.

[0189] Antenna QQ310, communication interface QQ306, and / or processing circuitry QQ302 can be configured to perform any receive operation and / or certain acquisition operation described herein as being performed by a network node. Any information, data, and / or signals can be received from the UE, another network node, and / or any other network device. Similarly, antenna QQ310, communication interface QQ306, and / or processing circuitry QQ302 can be configured to perform any transmit operation described herein as being performed by a network node. Any information, data, and / or signals can be transmitted to the UE, another network node, and / or any other network device.

[0190] Power supply QQ308 supplies power to the various components of network node QQ300 in a manner appropriate to each component (e.g., at the voltage and current levels required by each respective component). Power supply QQ308 may also include or be coupled to power management circuitry to supply power to the components of network node QQ300 to perform the functions described herein. For example, network node QQ300 may be connected to an external power source (e.g., mains, power outlet) via input circuitry or an interface (e.g., a cable), thereby supplying power to the power circuitry of power supply QQ308. As another example, power supply QQ308 may include a power source in the form of a battery or battery pack, which is connected to or integrated into the power circuitry. The battery can provide backup power if the external power source fails.

[0191] Implementation examples of the network node QQ300 may include Figure 15Additional components beyond those shown may be used to provide certain aspects of the network node's functionality, including any of the functions described herein and / or any functions required to support the topics described herein. For example, network node QQ300 may include a user interface device to allow information to be input into and output from network node QQ300. This allows users to perform diagnostic, maintenance, repair, and other management functions on network node QQ300. In some embodiments providing a core network node (e.g., core network node 108 of Figure QQ1), some components, such as the radio front-end circuitry QQ318 and the RF transceiver circuitry QQ312, may be omitted.

[0192] Figure 16 This is a block diagram illustrating a virtualized environment QQ400 in which some embodiments of functionality can be virtualized. In this context, virtualization means creating virtual versions of a device or equipment, which may include virtualized hardware platforms, storage devices, and network resources. Virtualization as used herein can be applied to any device or component thereof described herein, and relates to a manner in which at least a portion of its functionality is implemented as one or more virtual components. Some or all of the functionality described herein can be implemented as virtual components executed by one or more virtual machines (VMs) hosted in one or more virtual environments QQ400 on one or more hardware nodes (e.g., hardware computing devices operating as network nodes, UEs, core network nodes, or hosts). Furthermore, in embodiments where the virtual node does not require radio connectivity (e.g., a core network node or host), the node can be fully virtualized. In some embodiments, the virtualized environment QQ400 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated via an O-2 interface by a service management and orchestration framework. Virtualization can facilitate the distributed implementation of network nodes, UEs, core network nodes, or hosts.

[0193] The application QQ402 (which may also be referred to as a software instance, virtual device, network function, virtual node, virtual network function, etc.) runs in the virtualization environment QQ400 to implement some of the features, functions and / or benefits of some embodiments disclosed herein.

[0194] Hardware QQ404 includes processing circuitry, memory storing software and / or instructions executable by the hardware processing circuitry, and / or other hardware devices described herein (e.g., network interfaces, input / output interfaces, etc.). Software can be executed by the processing circuitry to instantiate one or more virtualization layers QQ406 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VM QQ408a and QQ408b (one or more of which may generally be referred to as VM QQ408), and / or perform any functionality, features, and / or benefits associated with some embodiments described herein. Virtualization layer QQ406 can present a virtual operating platform to VMQQ408 that appears to be network hardware.

[0195] VM QQ408 includes virtual processing, virtual memory, virtual network or interface, and virtual storage, and can be run by a corresponding virtualization layer QQ406. Different embodiments of instances of virtual device QQ402 can be implemented on one or more VM QQ408, and these implementations can be made in different ways. In some contexts, hardware virtualization is referred to as Network Functions Virtualization (NFV). NFV can be used to consolidate numerous network device types into industry-standard high-capacity server hardware, physical switches, and physical storage devices that can be located in data centers and customer residential facilities.

[0196] In the context of NFV, a VM QQ408 can be a software implementation of a physical machine, running as if it were on a physical, non-virtualized machine. Each VM QQ408, along with the portion of hardware QQ404 that executes that VM (whether dedicated to that VM or shared by that VM with other VMs), forms a separate virtual network element. Also in the context of NFV, virtual network functions handle specific network functions running on one or more VM QQ408s above the hardware QQ404, and correspond to application QQ402.

[0197] The hardware QQ404 can be implemented in a standalone network node with general or specific components. Some functions of the hardware QQ404 can be implemented through virtualization. Alternatively, the hardware QQ404 can be part of a larger hardware cluster (e.g., in a data center or CPE) where many hardware nodes work together and are managed by a management and orchestration QQ410, which in particular oversees the lifecycle management of the application QQ402. In some embodiments, the hardware QQ404 is coupled to one or more radio units, each radio unit including one or more transmitters and one or more receivers, which may be coupled to one or more antennas. The radio units can communicate directly with other hardware nodes via one or more suitable network interfaces and can be used in conjunction with virtual components to provide radio capabilities to virtual nodes (e.g., radio access nodes or base stations). In some embodiments, some signaling can be provided by using a control system QQ412, which can alternatively be used for communication between the hardware nodes and the radio units.

[0198] While the computing devices (e.g., UE, network node) described herein may include combinations of the hardware components shown, other embodiments may include computing devices with different combinations of components. It should be understood that these computing devices may include any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determination, calculation, acquisition, or similar operations described herein may be performed by processing circuitry that processes information in ways such as: converting acquired information into other information, comparing the acquired or converted information with information stored in the network node, and / or performing one or more operations based on the acquired or converted information, and making determinations based on the results of said processing. Furthermore, although components are depicted as single boxes located within larger boxes or nested within multiple boxes, in practice, a computing device may include multiple different physical components constituting a single illustrated component, and functionality may be partitioned between individual components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of a component may be partitioned between processing circuitry and the communication interface. In another example, the non-computationally intensive functions of any such component may be implemented in software or firmware, and the computationally intensive functions may be implemented in hardware.

[0199] In some embodiments, some or all of the functions described herein may be provided by processing circuitry that executes instructions stored in memory, which in some embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functions may be provided by the processing circuitry, for example, in a hard-wired manner, without executing instructions stored on a separate or discrete device-readable storage medium. In any of these particular embodiments, the processing circuitry may be configured to perform the described functions regardless of whether instructions stored on a non-transitory computer-readable storage medium are executed. The benefits provided by such functions are not limited to the individual processing circuitry or other components of the computing device, but are enjoyed holistically by the computing device and / or generally by the end user and wireless network.

[0200] The various aspects of this disclosure offer numerous advantages over existing technologies and can achieve one or more of the following technical effects. The methods described herein at the UE and CU allow for self-optimization of LTM functionality. This facilitates LTM cell handover, resulting in the benefit of reduced downtime compared to conventional Layer 3 mobility when using LTM.

[0201] Generally, unless a different meaning is explicitly given and / or can be inferred from the context of use, all terms used herein should be interpreted according to their common meaning in the relevant technical field. Unless otherwise expressly stated, all references to a / an / element, device, component, part, step, etc., should be openly interpreted as referring to at least one instance of that element, device, component, part, step, etc. Unless explicitly stated that a step is performed after or before another step, and / or implicitly requires that a step must be performed after or before another step, the steps of any method disclosed herein need not be performed in the exact order disclosed. Where appropriate, any feature of any aspect disclosed herein may be applied to any other aspect. Similarly, any advantage of any aspect may be applied to any other aspect, and vice versa. Other objects, features, and advantages of the appended aspects will be apparent from the specification.

[0202] The term “unit” can have the conventional meaning in the fields of electronics, electrical equipment and / or electronic equipment, and can include, for example, electrical and / or electronic circuits, devices, modules, processors, memories, logic solid-state devices and / or discrete devices, computer programs or instructions, etc., for performing corresponding tasks, processes, calculations, outputs and / or display functions, such as those described herein.

[0203] As used in this article, “configured to” means to be set up, organized, adapted, or arranged to operate in a particular manner; the term is synonymous with “designed to” or, in the case of processing circuitry, “programmed to”.

[0204] Some aspects contemplated herein have been described more fully with reference to the accompanying drawings. However, other aspects are also included within the scope of the subject matter disclosed herein. The disclosed subject matter should not be construed as limited to the aspects set forth herein; rather, these aspects are provided as examples to convey the scope of the subject matter to those skilled in the art.

[0205] Of course, this disclosure may be practiced in ways other than those specifically set forth herein without departing from its essential characteristics. All aspects of this invention should be considered illustrative rather than restrictive in all respects and are intended to cover all variations falling within the meaning and equivalents of the appended aspects.

[0206] Example

[0207] Group A Examples

[0208] 1. A method performed by a user equipment (UE) operating in a wireless communication network for providing information about radio link failures (RLFs) related to an L1 / L2 triggered mobility (LTM) cell handover process, the method comprising:

[0209] Receive the LTM candidate cell list from the Serving Distributed Element (DU) of the base station serving the UE;

[0210] Perform LTM early synchronization with at least one cell in the candidate cell list;

[0211] Receive LTM cell handover command from the serving DU;

[0212] Attempting LTM cell handover and experiencing RLF (LTM failure); and

[0213] Prepare a Self-Organizing Network (SON) report for LTM, which includes information related to LTM failures so that the network can analyze LTM failures and optimize the network to avoid future LTM failures.

[0214] 2. The method according to Embodiment 1 further includes, after LTM failure:

[0215] Rebuilding connections with wireless communication networks; and

[0216] The SON report used for LTM is sent to the central unit (CU) of the serving base station.

[0217] 3. According to the method described in Example 1, wherein the LTM cell handover RLF type is LTM cell handover too late.

[0218] 4. The method according to Example 1, wherein the LTM cell handover RLF type is LTM cell handover too early.

[0219] 5. The method according to Embodiment 1, wherein the LTM cell handover RLF type is LTM cell handover to the wrong cell.

[0220] Group B Implementation Examples

[0221] 6. A method performed by a central unit (CU) of a base station serving a user equipment (UE) in a wireless communication network for performing network optimization after a radio link failure (RLF) occurs at the UE, the RLF being related to an L1 / L2 triggered mobility (LTM) cell handover process (LTM failure), the method comprising:

[0222] Receive Radio Resource Control (RRC) signaling to rebuild the UE in the wireless communication network after the UE experiences an LTM failure;

[0223] Obtain the Adaptive Network (SON) report for LTM prepared by the UE, which includes information related to LTM failure;

[0224] Determine the LTM failure type;

[0225] Select one or more distributed units (DUs) of the base station based on LTM failure type; and

[0226] Send at least a portion of the SON report used for LTM to the selected DU.

[0227] 7. The method according to embodiment 6, wherein sending at least a portion of the SON report for LTM to the selected DU further includes: sending the LTM failure type to the selected DU.

[0228] 8. The method according to embodiment 6, wherein sending at least a portion of the SON report for LTM to the selected DU further includes: sending an explicit instruction indicating that the selected DU needs to report the results of its analysis of the data in the SON report for LTM back to the CU.

[0229] 9. The method according to embodiment 6, wherein sending at least a portion of the SON report for LTM to the selected DU further includes: sending an implicit indication by including or excluding predetermined information elements (IEs), the implicit indication indicating that the selected DU needs to report the results of its analysis of the data in the SON report for LTM back to the CU.

[0230] 10. The method according to embodiment 6, wherein sending at least a portion of the SON report for LTM to the selected DU further includes: sending the data of the SON report for LTM in the CELL SWITCH MOBILITY REPORT.

[0231] 11. The method according to embodiment 10, wherein the CELL SWITCH MOBILITY REPORT is an F1 Application Protocol (F1AP) message.

[0232] 12. The method according to embodiment 10, wherein the CELL SWITCH MOBILITY REPORT is sent in response to receiving a CELL SWITCH MOBILITY REPORT REQUEST from one or more DUs.

[0233] 13. The method according to embodiment 10 further includes: receiving a CELL SWITCH MOBILITY FEEDBACK message after sending a CELL SWITCH MOBILITY REPORT.

[0234] 14. The method according to embodiment 13 further includes: analyzing the data of the SON report for LTM only after receiving a CELL SWITCH MOBILITY FEEDBACK message from one or more selected DUs, but without determining the LTM failure type and the selected DU.

[0235] 15. The method according to embodiment 6, wherein sending at least a portion of the SON report for LTM to the selected DU further includes: sending one or more recommended configuration adjustments.

[0236] 16. The method according to embodiment 6, wherein sending at least a portion of the SON report for LTM to the selected DU further includes: sending information relating to one or more LTM-related configurations.

[0237] 17. The method according to embodiment 6 further includes: updating the existing LTM candidate cell list based on the SON report used for LTM.

[0238] 18. The method according to embodiment 6, wherein one or more selected DUs are part of another base station.

[0239] 19. The method according to embodiment 6, wherein one or more selected DUs are part of different radio access networks (RANs).

[0240] 20. The method according to Example 6, wherein the determined LTM failure type is LTM cell handover too late.

[0241] 21. The method according to embodiment 20, wherein the cell to which the UE performs reconstruction is not in the LTM candidate cell list sent to the UE before LTM failure, the method further includes:

[0242] Add the cell to which the UE performs reconstruction to the LTM candidate cell list.

[0243] 22. The method according to embodiment 20, wherein the CELL SWITCH MOBILITY REPORT includes an instruction instructing the DU to perform an LTM cell handover in advance.

[0244] 23. The method according to embodiment 22, wherein the instruction to perform LTM cell handover in advance includes the following instruction: the source cell signal measured for LTM triggering is "X" dBm higher than the previous LTM triggering point.

[0245] 24. The method according to embodiment 22, wherein the instruction to perform LTM cell handover in advance includes the following instruction: the target cell signal measured for LTM triggering is "Y" dBm lower than the previous LTM triggering point.

[0246] 25. The method according to embodiment 22, wherein the instruction to indicate early LTM cell handover includes the following instructions: the source cell signal measured for LTM triggering is "X" dBm higher than the previous LTM triggering point, and the target cell signal measured for LTM triggering is "Y" dBm lower than the previous LTM triggering point.

[0247] 26. The method according to embodiment 22, wherein the instruction to perform LTM cell handover in advance includes: LTM cell handover should only be triggered when the difference between the source cell signal and the target cell signal measured for LTM triggering is greater than a difference threshold.

[0248] 27. The method according to Embodiment 6, wherein the determined LTM failure type is premature LTM cell handover, the UE reconstruction process is performed for the original serving DU, the CELL SWITCH MOBILITY REPORT is sent to the serving DU and includes an instruction instructing the serving DU to delay the LTM cell handover.

[0249] 28. The method according to embodiment 27, wherein the instruction indicating a delay in LTM cell handover includes the following instruction: the source cell signal measured for LTM triggering is “X” dBm lower than the previous LTM trigger point.

[0250] 29. The method according to embodiment 27, wherein the instruction indicating a delay in LTM cell handover includes the following instruction: the target cell signal measured for LTM triggering is “Y” dBm higher than the previous LTM trigger point.

[0251] 30. The method according to embodiment 27, wherein the instruction indicating a delay in LTM cell handover includes the following instructions: the source cell signal measured for LTM triggering is “X” dBm lower than the previous LTM triggering point, and the target cell signal measured for LTM triggering is “Y” dBm higher than the previous LTM triggering point.

[0252] 31. The method according to embodiment 27, wherein the instruction to delay LTM cell handover includes: LTM cell handover should only be triggered when the difference between the source cell signal and the target cell signal measured for LTM triggering is greater than a difference threshold.

[0253] 32. The method according to Example 6, wherein the determined LTM failure type is LTM cell handover to the wrong cell.

[0254] 33. The method according to embodiment 32, wherein the cell to which the UE performs reconstruction is not in the LTM candidate cell list sent to the UE before LTM failure, the method further includes:

[0255] Add the cell to which the UE performs reconstruction to the LTM candidate cell list.

[0256] 34. The method according to embodiment 32, wherein the CELL SWITCH MOBILITY REPORT includes the following instruction to the DU: one potential target cell in the LTM potential target cells should be prioritized over other potential target cells.

[0257] 35. The method according to embodiment 34, wherein the instruction further indicates an offset by which the LTM trigger point should be advanced toward the priority cell.

[0258] 36. The method according to embodiment 34, wherein the instruction further indicates a value representing the priority level of the preferred target cell.

[0259] Group C Implementation Examples

[0260] 37. A user equipment that provides information on radio link failures (RLFs) related to an L1 / L2 triggered mobility (LTM) cell handover process, comprising:

[0261] The processing circuitry is configured to perform any step of any embodiment in Group A embodiments; and

[0262] The power supply circuit is configured to supply power to the processing circuit.

[0263] 38. A network node that performs network optimization after a radio link failure (RLF) occurs in a UE, the RLF being related to an L1 / L2 triggered mobility (LTM) cell handover process (LTM failure), the network node comprising:

[0264] The processing circuitry is configured to perform any step of any embodiment in any of the Group B embodiments;

[0265] The power supply circuit is configured to supply power to the processing circuit.

[0266] 39. A user equipment (UE) that provides information on radio link failures (RLFs) related to an L1 / L2 triggered mobility (LTM) cell handover process, the UE comprising:

[0267] The antenna is configured to transmit and receive wireless signals;

[0268] The radio frequency front-end circuit is connected to the antenna and the processing circuit, and is configured to regulate the signal transmitted between the antenna and the processing circuit.

[0269] The processing circuitry is configured to perform any step of any embodiment in Group A embodiments;

[0270] An input interface is connected to the processing circuitry and is configured to allow information to be input into the UE for processing by the processing circuitry.

[0271] An output interface, connected to the processing circuitry, is configured to output information already processed by the processing circuitry from the UE; and

[0272] The battery is connected to the processing circuitry and is configured to power the UE.

[0273] abbreviation

[0274] .

Claims

1. A method (100) for providing radio link failure (RLF) information performed by a user equipment (UE) operating in a wireless communication network, the RLF being related to an L1 / L2 triggered mobility LTM cell handover procedure, the method being characterized in that: Receive (102) LTM candidate cell list from the base station serving the UE; Receive (104) LTM cell handover command from the serving base station; An attempt was made to perform an (106) LTM cell handover, and a (108) LTM failure RLF was encountered; and Prepare (112) a self-organizing network SON report for LTM, the SON report for LTM including information related to the LTM failure, so that the network can analyze the LTM failure and optimize the network to avoid future LTM failures.

2. The method (100) according to claim 1, further comprising: Before receiving an LTM cell handover command from the serving base station, perform LTM early synchronization with at least one cell in the candidate cell list.

3. The method (100) according to claim 1 or 2, further comprising, after the LTM fails: Re-establish the connection with the wireless communication network; and The SON report used for LTM is sent to the serving base station.

4. The method (100) according to claim 3, wherein, The base station to which the SON report for LTM is sent is the same base station from which the UE receives the LTM cell handover command.

5. The method (100) according to claim 3, wherein, The base station to which the SON report for LTM is sent is a different base station from which the UE receives the LTM cell handover command.

6. A method (200) executed by a central unit (CU) of a base station for performing network optimization after a radio link failure (RLF) occurs in a user equipment (UE), the base station serving the UE in a wireless communication network, the RLF being related to an L1 / L2 triggered mobility LTM cell handover process, i.e., an LTM failure, the method comprising: Receive (202) Radio Resource Control (RRC) signaling to rebuild the UE in the wireless communication network after the LTM failure of the UE; Obtain (204) the self-organizing network SON report for LTM prepared by the UE, the SON report for LTM including information related to the LTM failure; Determine the (206) LTM failure type; Based on the LTM failure type, select (208) one or more distributed units (DUs) of the base station; as well as Send (210) at least a portion of the SON report for LTM to the selected DU.

7. The method (200) according to claim 6, wherein, Sending at least a portion of the SON report for LTM to the selected DU also includes sending the LTM failure type to the selected DU.

8. The method (200) according to claim 6 or 7, wherein, Sending at least a portion of the SON report for LTM to the selected DU further includes sending an explicit instruction that the selected DU needs to report the results of its analysis of the SON report for LTM back to the CU.

9. The method (200) according to any one of claims 6 to 8, wherein, Sending at least a portion of the SON report for LTM to the selected DU further includes: sending an implicit indication by including or excluding a predetermined information element IE, the implicit indication indicating that the selected DU needs to report the results of its analysis of the data in the SON report for LTM back to the CU.

10. The method (200) according to any one of claims 6 to 9, wherein, Sending at least a portion of the SON report for LTM to the selected DU also includes sending one or more recommended configuration adjustments.

11. The method (200) according to any one of claims 6 to 10, wherein, Sending at least a portion of the SON report for LTM to the selected DU also includes sending information about one or more LTM-related configurations.

12. The method (200) according to any one of claims 6 to 11, further comprising: The existing LTM candidate cell list is updated based on the SON report used for LTM.

13. The method (200) according to any one of claims 6 to 12, wherein, The identified LTM failure type is LTM cell handover too late.

14. The method (200) according to claim 13, wherein, The cell to which the UE performs reconstruction is not in the LTM candidate cell list sent to the UE before the LTM failure, and the method further includes: The cell to which the UE performs reconstruction is added to the LTM candidate cell list.

15. The method (200) according to any one of claims 6 to 12, wherein, The determined LTM failure type is LTM cell handover to the wrong cell.

16. The method (200) according to claim 15, wherein, The cell to which the UE performs reconstruction is not in the LTM candidate cell list sent to the UE before the LTM failure, and the method further includes: The cell to which the UE performs reconstruction is added to the LTM candidate cell list.

17. The method (200) according to claim 6, wherein, At least a portion of the SON report used for LTM includes instructions to the DU indicating that one of the potential target cells for LTM should be prioritized over other potential target cells.

18. The method (200) according to claim 17, wherein, The instruction also specifies the offset that the LTM trigger point should be advanced toward the priority cell.

19. A method (300) executed by a current central unit (CU) of a current base station for performing network optimization after a user equipment (UE) experiences a radio link failure (RLF), the current base station serving the UE in a first radio access network (RAN) of a wireless communication network, the RLF being related to an L1 / L2 triggered mobility LTM cell handover process, i.e., an LTM failure, the method comprising: Obtain (302) the self-organizing network SON report for LTM prepared by the UE, the SON report for LTM including information related to the LTM failure; According to the SON report (204): prior to the LTM mobility execution, the UE was served by a previous CU of a previous base station, which was different from the current CU; as well as The SON report for LTM obtained from the UE is sent (206) to the previous CU.

20. The method (300) according to claim 19, wherein, The previous base station was part of the first RAN.

21. The method (300) according to claim 19, wherein, The previous base station is part of a second RAN that is different from the first RAN.

22. A user equipment that provides information on radio link failures (RLFs) related to L1 / L2-triggered mobility LTM cell handover procedures, the user equipment comprising: The processing circuit is configured to perform any one of the steps of claims 1 to 5; as well as A power supply circuit is configured to supply power to the processing circuit.

23. A network node that performs network optimization after a user equipment (UE) experiences a radio link failure (RLF), wherein the RLF is related to an L1 / L2 triggered mobility LTM cell handover process, i.e., an LTM failure, wherein the network node comprises: The processing circuit is configured to perform any one of the steps of any one of claims 6 to 18; as well as A power supply circuit is configured to supply power to the processing circuit.

24. A network node that performs network optimization after a user equipment (UE) experiences a radio link failure (RLF), wherein the RLF is related to an L1 / L2 triggered mobility LTM cell handover process, i.e., an LTM failure, the network node comprising: The processing circuit is configured to perform any one of the steps of any one of claims 19 to 21; as well as A power supply circuit is configured to supply power to the processing circuit.

25. A user equipment (UE) that provides information on radio link failures (RLFs) related to an L1 / L2-triggered mobility LTM cell handover process, the UE comprising: The antenna is configured to transmit and receive wireless signals; A radio frequency front-end circuit is connected to the antenna and the processing circuit, and is configured to modulate the signal transmitted between the antenna and the processing circuit; The processing circuit is configured to perform any one of the steps of claims 1 to 5; An input interface is connected to the processing circuitry and configured to allow information to be input into the UE for processing by the processing circuitry. An output interface is connected to the processing circuit and configured to output information that has been processed by the processing circuit from the UE; as well as A battery is connected to the processing circuit and configured to power the UE.

Images