Optimizing network methods for handling LTM cell switch failures

Abstract

Methods are introduced (e.g., via network signaling enhancements) to support self- optimization of LTM function in the aspects of LTM preparation (e.g., determining / adjusting the list of LTM candidate cells with which a UE is configured) and LTM execution (e.g., determining / adjusting which cells of the LTM candidate is the most appropriate to choose and the time when LTM execution is to be triggered). LTM related information collected by the UE(s) to support SON functions (e.g., LTM related information comprised in RA reports, RLF reports, Successful Handover Reports), is used to analyze and optimize LTM associated failures, such as too early LTM cell switch, or a too late LTM cell switch, or LTM cell switch to wrong cell. Methods to transfer the RLF Report and the result of the failure analysis between gNB-CU and gNB-DU are also described.

Description

[0001] SELF-OPTIMIZING NETWORK METHODS FOR HANDLING LTM CELL SWITCH FAILURES

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

[0003] BACKGROUND

[0004] Wireless communication networks, including network nodes and radio network devices such as cellphones and smartphones, are ubiquitous in many parts of the world. These networks continue to grow in capacity and sophistication. To accommodate both more users and a wider range of types of devices that may benefit from wireless communications, the technical standards governing the operation of wireless communication networks continue to evolve. The fourth generation of network standards (4G, also known as Long Term Evolution, or LTE) has been deployed, the fifth generation (5G, also known as New Radio, or NR) is in development or the early stages of deployment, and the sixth generation (6G) is being planned. Specific technical standards defining new network features and capabilities are promulgated by the Third Generation Partnership Project (3 GPP) as a series of numbered Releases, e.g., Rel. 15, Rel. 16, etc.

[0005] Both LTE and NR networks follow a “cellular” architecture, wherein a plurality of generally fixed network nodes, known as base stations (also called eNB in LTE and gNB in NR) provide wireless communication services to both fixed and mobile radio network devices, referred to generally herein as User Equipment (UE), within a coverage area, or “cell.” The term “cell” also refers to a unique logical entity providing wireless communication service; hence one base station may provide a plurality of cells.

[0006] Up through LTE, the base station (eNB) was monolithic entity. NR introduced the concept of splitting the base station (gNB) between a Central Unit (CU) and Distributed Units (DU). Figure 1 shows this architecture. Access and Mobility Management Function (AMF) and / or User Plane Function (UPF) in the core network connect to base stations (gNB). Each gNB is divided into a CU and a plurality of DUs. A break between the CU and DU in the network protocol stack is commonly implemented above the Radio Link Control (RLC), with RLC, MAC, and the Physical layer (PHY) implemented in the DU, while RRC, Packet Data Convergence Protocol (PDCP) and higher layer functions are implemented in the CU.

[0007] Mobility is a fundamental aspect of wireless communication networks. As a UE moves throughout a geographic region, it will move from one cell to another. The UE periodically performs measurements of the signal strength and quality of the air interface between it and a current serving cell, as well as neighboring cells. When a neighbor cell provides a consistently higher quality channel, the network performs a “handover” procedure, passing control and servicing of the UE from the current, or “source” cell to the new, or “target” cell. Accordingly, the operation is also referred to as a “cell switch.” Ideally, a handover or cell switch procedure is performed transparently to the user, who experiences no degradation in quality of any ongoing call or data stream as the procedure is executed.

[0008] LTM support in 3 GPP rel-18

[0009] Handover has conventionally been performed by Radio Resource Control (RRC) signaling, which is a high-level signaling protocol. As such, it involves extensive signaling across the air interface, and extensive processing at the UE, which consumes battery power. Release 18 introduced a cell switch triggered by the Media Access Control (MAC) layer rather than RRC. This procedure operates at lower levels of the protocol stack (e.g., Level 1 or Level 2), and is referred to as L1 / L2 Triggered Mobility (LTM). LTM can achieve faster cell switching, with lower overhead and hence power consumption, than RRC handover.

[0010] A high level description of Ll / L2-Triggered Mobility (LTM) operation can be found in 3GPP TS 38.300 vl8.0.0 (section 9.2.3.5). An excerpt is provided below:

[0011] LTM is a procedure in which a gNB receives LI measurement report(s) from a UE, and on their basis the gNB changes UE serving cell by a cell switch command signalled via a MAC CE. The cell switch command indicates an LTM candidate configuration that the gNB previously prepared and provided to the UE through RRC signalling. Then the UE switches to the target configuration according to the cell switch command. The LTM procedure can be used to reduce the mobility latency as described in Annex G.

[0012] The following principles apply to LTM:

[0013] • Security key is maintained upon an LTM cell switch;

[0014] • Subsequent LTM is supported.

[0015] LTM supports both intra-gNB-DU and intra-gNB-CU inter-gNB-DU mobility. LTM supports both intra-frequency and inter-frequency mobility, including mobility to interfrequency cell that is not a current serving cell. LTM is supported only for licensed spectrum. The following scenarios are supported:

[0016] • PCell change in non-CA scenario and non-DC scenario;

[0017] • PCell and SCell(s) change in CA scenario; • Dual connectivity scenario, PCell and MCG SCell(s) change and intra-SN PSCell and SCG SCell(s) change without MN involvement. LTM for simultaneous PCell and PSCell change is not supported.

[0018] While the UE has stored LTM candidate configurations the UE can also execute any L3 handover command sent by the network.

[0019] FIG. 2, recreating Figure 9.2.3.5.2-1, “Signalling procedure for LTM” in TS 38.300 vl 8.0.0, shows a high level procedure for LTM.

[0020] The TS 38.401 vl8.0.0 describes the intra-NR mobility when LTM is used with more details concerning a gNB in split deployment, z.e., intra-gNB DU LTM (section 8.2.1.4), inter-gNB-DU LTM (section 8.2.1.5) and LTM with gNB-CU-UP change (section 8.2.1.6).

[0021] FIG. 3, recreating Figure 8.2.1.4-1 of TS 38.401 vl8.0.0, shows the signaling procedure for intra-gNB-DU LTM.

[0022] FIG. 4, recreating Figure 8.2.1.5-1 of TS 38.401 vl8.0.0, shows the signaling procedure for inter-gNB-DU LTM.

[0023] Radio Link Failure (RLF) Report in Self-Organized Network (SON)

[0024] The Radio Link Failure Report (RLF Report) was introduced as a Self-Organized Network (SON) function, to improve Mobility Robustness. This report is generated by the UE in case of Radio Link Failure (RLF) or Handover Failure (HOF), and fetched by the network. Its content is then used by the network to analyze issue(s) that lead to the failure, and find network optimization to improve overall mobility robustness within the mobile network. For NG-RAN, it is defined as follows, in TS 38.300 vl8.0.0:

[0025] For analysis of connection failures, the UE makes the RLF Report available to the network.

[0026] The UE stores the latest RLF Report, including both LTE and NR RLF report until the RLF report is fetched by the network or for 48 hours after the connection failure is detected.

[0027] The UE only indicates RLF report availability and only provides the RLF report to the network if the current RPLMN is a PLMN that was present in the UE's EPLMN List or was the RPLMN at the time the connection failure was detected. In case RLF happens in an E- UTRA cell, the UE makes the LTE RLF Report available to NG-RAN nodes and eNB(s), and in case RLF happens in an NR cell the UE makes the NR RLF Report available to gNB(s).

[0028] If the LTE RLF Report is reported to a NG-RAN node, and the last serving node is an E-UTRAN node, the NG-RAN node may transfer it to the E-UTRAN node by triggering the Uplink RAN configuration transfer procedure over NG and the E-UTRAN node can take this into account as defined in TS 36.300.

[0029] The RLF Report is also used to detect the failure type. For intra-NG-RAN mobility, these are defined as follows, in TS 38.300 vl8.0.0:

[0030] One of the functions of Mobility Robustness Optimization is to detect connection failures that occur due to Too Early or Too Late Handovers, or Handover to Wrong Cell. These problems are defined as follows:

[0031] • Intra-system Too Late Handover: an RLF occurs after the UE has stayed for a long period of time in the cell; the UE attempts to re-establish the radio link connection in a different cell.

[0032] • Intra-system Too Early Handover: an RLF occurs shortly after a successful handover from a source cell to a target cell or a handover failure occurs during the handover procedure; the UE attempts to re-establish the radio link connection in the source cell.

[0033] • Intra-system Handover to Wrong Cell: an RLF occurs shortly after a successful handover from a source cell to a target cell or a handover failure occurs during the handover procedure; the UE attempts to re-establish the radio link connection in a cell other than the source cell and the target cell.

[0034] In the definition above, the "successful handover" refers to the UE state, namely the successful completion of the Random Access (RA) procedure.

[0035] In case of Conditional Handover (CHO), the Too Late Handover, Too Early Handover and Handover to Wrong Cell in the definition above means Too Late CHO Execution, Too Early CHO Execution and CHO Execution to Wrong Cell.

[0036] There currently exist certain challenge(s). According to published technology, it is not clear how to perform self-optimization for LTM. For example, it is not clear how to reduce the failures which may occur in the various steps involved in the LTM, for example during the LTM preparation phase, where a gNB (or more specifically a gNB-CU) prepares the LTM candidate cells, or during the LTM execution phase, where the gNB (or more specifically a gNB-DU) takes the decision to send a cell switch command to the UE.

[0037] The Background section of this document is provided to place aspects of the present disclosure in technological and operational context, to assist those of skill in the art in understanding their scope and utility. Approaches described in the Background section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Unless explicitly identified as such, no statement herein is admitted to be prior art merely by its inclusion in the Background section.

[0038] SUMMARY

[0039] The following presents a simplified summary of the disclosure in order to provide a basic understanding to those of skill in the art. This summary is not an extensive overview of the disclosure and is not intended to identify key / critical elements of aspects of the disclosure or to delineate the scope of the disclosure. The sole purpose of this summary is to present some concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.

[0040] According to aspects of the present disclosure described and claimed herein, methods are introduced (e.g., via network signaling enhancements) to support self-optimization of LTM function in the aspects of LTM preparation (e.g., determining / adjusting the list of LTM candidate cells with which a UE is configured) and LTM execution (e.g., determining / adjusting which cells of the LTM candidate is the most appropriate to choose and the time when LTM execution is to be triggered). LTM related information collected by the UE(s) to support SON functions (e.g., LTM related information comprised in RA reports, RLF reports, Successful Handover Reports), is used to analyze and optimize LTM associated failures, such as too early LTM cell switch, or a too late LTM cell switch, or LTM cell switch to wrong cell.

[0041] Methods to transfer the RLF Report and the result of the failure analysis between gNB- CU and gNB-DU are also described. These include methods to determine the failure causes and types after an RLF due to LTM mobility; optimization actions (and its signaling between CU and DU) that can be taken by the network nodes to optimize LTM mobility and avoid future failures; and methods to transfer the RLF Report and the result of the failure analysis between gNB-CU and gNB-D.

[0042] One aspect relates to a method, performed by a UE operative in a wireless communication network, of providing information about an RLF related to an LTM cell switch procedure. An LTM candidate cell list is received from a base station serving the UE. An LTM cell switch command is received from the serving base station. The LTM cell switch is attempted, and an RLF in the form of an LTM failure is experienced, an 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. Another aspect relates to a method, performed by a CU of a base station serving a UE in a wireless communication network, for performing network optimization after an RLF by the UE, the RLF related to an LTM cell switch procedure (LTM failure). RRC signaling is received, re-establishing the UE in the wireless communication network after the LTM failure by the UE. An SON report for LTM prepared by the UE is obtained, which includes information related to the LTM failure. An LTM failure type is determined. One or more DUs of the base station are selected based on the LTM failure type. At least part of the SON report for LTM is sent to the selected DU(s).

[0043] Yet another aspect relates to a method, performed by a current CU of a current base station in a first RAN of a wireless communication network serving a UE, for performing network optimization after an RLF by the UE, the RLF related to an LTM cell switch procedure (LTM failure). An SON report for LTM prepared by the UE is obtained, which includes information related to the LTM failure. It is determined from the SON report that, prior to an LTM mobility execution, the UE was served by a prior CU of a prior base station, the prior CU being different from the current CU. The SON report for LTM obtained from the UE is sent to the prior CU.

[0044] Still another aspect relates to a network node for performing network optimization after an RLF by a UE, the RLF related to an LTM cell switch procedure (LTM failure). The network node includes processing circuitry configured to perform the second method described above, and power supply circuitry configured to supply power to the processing circuitry.

[0045] Still another aspect relates to a network node for performing network optimization after an RLF by a UE the RLF related to an LTM cell switch procedure (LTM failure). The network node includes processing circuitry configured to perform the third method described above, and power supply circuitry configured to supply power to the processing circuitry.

[0046] Still another aspect relates to a UE for providing information about an RLF related to an LTM cell switch procedure. The UE includes an antenna configured to send and receive wireless signals, and radio front-end circuitry connected to the antenna and to processing circuitry. The processing circuitry is configured to condition signals communicated 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 input of information into the UE to be processed by the processing circuitry, and an output interface connected to the processing circuitry and configured to output information from the UE that has been processed by the processing circuitry. The UE further includes a battery connected to the processing circuitry and configured to supply power to the UE.

[0047] BRIEF DESCRIPTION OF THE DRAWINGS

[0048] The present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which aspects of the disclosure are shown. However, this 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. Like numbers refer to like elements throughout.

[0049] FIG. l is a diagram showing a network and a gNB split between CU and DUs.

[0050] FIG. 2 is a signaling diagram. It is a reproduction of 3GPP TS 38.401 vl8.0.0 FIG. 9.2.3.5.2-1 : Signalling procedure for LTM.

[0051] FIG. 3 is a signaling diagram. It is a reproduction of 3GPP TS 38.401 vl8.0.0 FIG.

[0052] 8.2.1.4-1 : Intra-gNB-DU LTM.

[0053] FIG. 4 is a signaling diagram. It is a reproduction of 3GPP TS 38.401 vl8.0.0 FIG.

[0054] 8.2.1.5-1 : Intra-gNB-DU LTM.

[0055] FIG. 5 is a signaling diagram showing an aspect wherein the UE generates an RLF report with LTM information, in the case of Too Late LTM Cell Switch. The reestablishment cell was in the LTM cell switch candidate list and the gNB-CU does not perform optimization of the LTM candidate cell list.

[0056] FIG. 6 is a signaling diagram showing an aspect wherein the UE generates an RLF report with LTM information, in case of Too Late LTM Cell Switch. The re-establishment cell was not part of the LTM cell switch candidate list, and the gNB-CU performs optimization of the LTM candidate cell list.

[0057] FIG. 7 is a signaling diagram showing an aspect wherein the UE generates an RLF report with LTM information, for the case of “Too early LTM Cell switch”. In this case, the gNB-CU does not perform an optimization of the LTM cell switch candidate list. This scenario can occur when the UE attempts to re-establish to a cell which was already part of the LTM cell switch candidate list. The gNB-DU performs optimization of the LTM cell switch triggers.

[0058] FIG. 8 is a signaling diagram showing an aspect wherein the UE generates an RLF report with LTM information, in case of LTM Cell Switch to Wrong cell. FIG. 9 is a signaling diagram showing an aspect wherein the UE generates an RLF report with LTM information, and the gNB-CU performs optimization of LTM candidate cell list.

[0059] FIG. 10 is a flow diagram of a method, performed by a UE operative in a wireless communication network, of providing information about an RLF related to an LTM cell switch procedure.

[0060] FIG. 11 is a flow diagram of a method, performed by a CU of a base station serving a UE in a wireless communication network, for performing network optimization after an RLF by the UE, the RLF related to an LTM cell switch procedure (LTM failure).

[0061] FIG. 12 is a flow diagram of a method, performed by a current CU of a current base station in a first RAN of a wireless communication network serving a UE, for performing network optimization after an RLF by the UE, the RLF related to an LTM cell switch procedure (LTM failure) wherein the UE was previously connected to a different CU.

[0062] FIG. 13 is a diagram of a wireless communication network.

[0063] FIG. 14 is a diagram of a UE operative in the wireless communication network of FIG. 13.

[0064] FIG. 15 is a diagram of a network node in the wireless communication network of FIG. 13 and functioning as a base station.

[0065] FIG. 16 is a diagram of a virtualization environment connected to the wireless communication network of FIG. 13.

[0066] DETAILED DESCRIPTION

[0067] For simplicity and illustrative purposes, the present disclosure is described by referring mainly to an exemplary aspect thereof. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. However, it will be readily apparent to one of ordinary skill in the art that the present disclosure may be practiced without limitation to these specific details. In this description, well known methods and structures have not been described in detail so as not to unnecessarily obscure the present disclosure.

[0068] In this disclosure, a user equipment is referred to as any device using the service of a wireless network. A network node is referred to as 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., to 6G). The disclosure is applicable to all scenarios of LTM, including e.g. PCell change PSCell change and SCell change.

[0069] The LTM configuration provided to a UE may include one or more candidate target cell(s), wherein the UE (and the target gNB-DU) is prepared for a potential LTM cell switch to each of the one or more candidate target cell(s). Herein, such a candidate target cell may be referred to as a “candidate target cell”, “LTM candidate target cell”, “candidate LTM target cell”, “candidate cell”, “LTM candidate cell”, “candidate LTM cell”, “LTM switch candidate cell”, “LTM switch candidate” or “LTM cell switch candidate”. Collectively, the one or more candidate target cell(s) may also be referred to as “LTM candidate list”, “LTM candidate cell list” or “LTM cell switch candidate list”. As used herein the term “LTM failure” refers to a Radio Link Failure (RLF) of a UE that is during, caused by, immediately after, or otherwise related to, an LTM cell switch.

[0070] In this disclosure, methods are described with respect to NR as the radio technology of reference. This should be considered as non-limiting as the methods herein apply to any radio access technology where LTM mobility is supported.

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

[0072] • Too late LTM cell switch o an RLF occurs after the UE has stayed for a long period of time in the cell; the UE attempts to re-establish the radio link connection in a different cell, which is an LTM cell switch candidate. o an RLF occurs after the UE has stayed for a long period of time in the cell; the UE attempts to re-establish the radio link connection in a different cell, which is NOT an LTM cell switch candidate.

[0073] • Too early LTM cell switch o an RLF occurs shortly after a successful LTM execution from a source cell to a target cell; the UE attempts to re-establish the radio link connection in the source cell o an LTM failure occurs during LTM execution procedure; the UE attempts to re-establish the radio link connection in the source cell.

[0074] • LTM cell switch to wrong cell o an RLF occurs shortly after a successful LTM execution from a source cell to a target cell; the UE attempts to re-establish the radio link connection in a cell other than source or target cell that is an LTM candidate cell o an LTM failure occurs during the LTM execution procedure; the UE attempts to re-establish the radio link connection in a cell other than source or target cell which is NOT an LTM candidate cell.

[0075] In case of “Too late LTM cell switch”, if the cell to which the UE performed the reestablishment was not included in the configuration of the LTM candidate cell list, a potential remedy action is to include such cell in the LTM candidate cell list. This is something the gNB-CU can do, and this action is described in one of the aspects of the present disclosure. Another scenario is that the cell to which the UE performed the re-establishment cell was already included in the configuration of the LTM candidate cell list, therefore the action needed to improve the situation is not at the gNB-CU, but at the gNB-DU. For instance, the gNB-DU can determine to trigger the next Cell Switch Command(s) towards the cell that the UE reported as re-establishment cell in the RLF-Report after a previous failure, or trigger subsequent similar LTM procedures earlier / more aggressively, based on the LI measurement reports, e.g. using internal decision thresholds that leads to an earlier trigger of the LTM procedure (e.g. a higher RSRP threshold for the serving cell and / or lower RSRP threshold(s) for the neighbor cells).

[0076] In another aspect directed the “Too late LTM cell switch” case, the corrective action is determined by the gNB-CU and then signaled to the gNB-DU. Namely, the gNB-CU may become aware that an RLF occurred during LTM mobility and that the UE re-established to an LTM cell switch candidate. The gNB-CU may become aware of this either by, for example, correlating re-establishment events (and their details contained e.g. in the RRCReestablishmentRequest) with other information such as the reception of a Fl : DU-CU Cell Switch Notification message and / or the list of LTM cell switch candidates, or by receiving an RLF report from the UE detailing information about the RLF report.

[0077] Once the gNB-CU knows the information about the RLF and it is able to classify that the failure is a “Too late LTM cell switch”, the gNB-CU may signal to the gNB-DU information aimed at preventing such failure in the future. Such information may be provided to the gNB-DU on a per cell pair (e.g. for a given source cell and a given target cell) or as general information independent of source and target cells. The information may include one or more of the following: • An indication that the LTM cell switch trigger point needs to be anticipated (i.e. it needs to be triggered earlier) by a certain amount, e.g. in dB. Namely, the handover trigger point needs to be moved by an offset that is indicated by the gNB-CU to the gNB-DU.

[0078] • An indication that the LTM cell switch trigger point needs to be anticipated (i.e. it needs to be triggered earlier) by a certain amount in terms of source cell signal. For example, source cell signal needs to be x dBm higher with respect to the last source cell signal at the LTM mobility triggering point associated to the failure or at the last LTM mobility trigger point.

[0079] • An indication that the LTM cell switch trigger point needs to be anticipated (i.e. it needs to be triggered earlier) by a certain amount in terms of target cell signal. For example, target cell signal needs to be y dBm lower with respect to the last source cell signal at the LTM mobility triggering point associated to the failure or at the last LTM mobility trigger point.

[0080] • An indication that the LTM cell switch trigger point needs to be anticipated (i.e. it needs to be triggered earlier) by a certain amount in terms of source cell signal and target cell signal. For example, source cell signal needs to be x dBm higher with respect to the last source cell signal at the LTM mobility triggering point and target cell signal needs to be y dBm lower with respect to the last source cell signal at the LTM mobility triggering point. Additionally, a delta threshold between source and target cell signals may be provided, indicating that the handover should be triggered only if the delta between source and target is higher than the delta indicated.

[0081] In case of “Too Early LTM cell switch”, the re-establishment cell is the same as the source cell, hence it was already it is one of the cells that were involved in the LTM procedure. Therefore, the action needed to improve the situation is not at the gNB-CU, but at the gNB-DU. For instance, in one aspect the gNB-DU action is to trigger subsequent similar LTM procedures late / less aggressively, based on the LI measurement reports, e.g. using internal decision thresholds that leads to a later trigger of the LTM procedure (e.g. a lower RSRP threshold for the serving cell and / or higher RSRP threshold(s) for the neighbor cells).

[0082] In another aspect related to the “Too Early LTM cell switch” case, the corrective action is determined by the gNB-CU and then signalled to the gNB-DU. Namely, the gNB-CU may become aware that an RLF occurred during LTM mobility and that the UE re-established to the source cell. The gNB-CU may become aware of this by, for example, correlating re- establishment events (and their details contained e.g. in the RRCReestablishmentRequest) with other information such as the information in the received Fl : DU-CU Cell Switch Notification message, or by receiving an RLF report from the UE detailing information about the RLF report.

[0083] Once the gNB-CU knows the information about the RLF and it is able to classify that the failure is a “Too Early LTM cell switch”, the gNB-CU may signal to the gNB-DU information aimed at preventing such failure in the future. Such information may be provided to the gNB-DU on a per cell pair (e.g. for a given source cell and a given target cell) or as general information independent of source and target cells. The information may include one or more of the following:

[0084] • An indication that the LTM cell switch trigger point needs to be delayed (i.e. it needs to be triggered later) by a certain amount, e.g. in dB. Namely, the handover trigger point needs to be moved by an offset that is indicated by the gNB-CU to the gNB-DU.

[0085] • An indication that the LTM cell switch trigger point needs to be delayed (i.e. it needs to be triggered later) by a certain amount in terms of source cell signal. For example, source cell signal needs to be x dBm lower with respect to the last source cell signal at the LTM mobility triggering point associated to the failure or at the last LTM mobility trigger point.

[0086] • An indication that the LTM cell switch trigger point needs to be delayed (i.e. it needs to be triggered later) by a certain amount in terms of target cell signal. For example, target cell signal needs to be y dBm higher with respect to the last source cell signal at the LTM mobility triggering point associated to the failure or at the last LTM mobility trigger point.

[0087] • An indication that the LTM cell switch trigger point needs to be delayed (i.e. it needs to be triggered later) by a certain amount in terms of source cell signal and target cell signal. For example, source cell signal needs to be x dBm lower with respect to the last source cell signal at the LTM mobility triggering point and target cell signal needs to be y dBm lower with respect to the last source cell signal at the LTM mobility triggering point. Additionally, a delta threshold between source and target cell signals may be provided, indicating that the handover should be triggered only if the delta between source and target is higher than the delta indicated.

[0088] In case of “LTM cell switch to Wrong Cell”, the re-establishment cell may have already been included or not included in the LTM candidate cell list. In the latter case, one of the possible optimization actions is at the gNB-CU, to add the re-establishment cell in the LTM candidate cell list. Instead, if the re-establishment cell was already included in the LTM candidate cell list, the action needed to improve the situation is not at the gNB-CU, but at the gNB-DU. For instance, the gNB-DU can determine to send next Cell Switch Command(s) to the re-establishment cell, e.g. based on adaptation of the gNB-DU’ s internal decision thresholds for the involved LTM candidate cells.

[0089] In another aspect related to the “LTM cell switch to Wrong Cell” case, the corrective action is determined by the gNB-CU and then signaled to the gNB-DU. Namely, the gNB-CU may become aware that an RLF occurred during LTM mobility and that the UE reestablished to a cell different from the target cell. The gNB-CU may become aware of this by, for example, correlating re-establishment events (and their details contained e.g. in the RRCReestablishmentRequest) with other information such as information contained in the received Fl : DU-CU Cell Switch Notification message, or by receiving an RLF report from the UE detailing information about the RLF report.

[0090] Once the gNB-CU knows the information about the RLF and it is able to classify that the failure is a “LTM cell switch to Wrong Cell”, the gNB-CU may signal to the gNB-DU information aimed at preventing such failure in the future. Such information may be provided to the gNB-DU on a per source and per one or more potential target cell. The information may include the following:

[0091] • An indication that, for LTM mobility from a given source cell to one or more potential target cell indicated by the gNB-CU, one of the LTM mobility potential target cell should be prioritized over the other potential target cells. In one variant, the gNB-CU may also indicate an offset by which the handover trigger point towards such prioritized cell shall be anticipated or a value representing the level of prioritization of such potential target cell.

[0092] A UE logs information related to LTM mobility in one or more SON reports, e.g., in RA reports, RLF reports, Successful Handover Reports. A UE report (e.g., an RLF report) comprising LTM related information is also called in the remainder of this disclosure as a SON report for LTM (or UE report for LTM).

[0093] SON reports for LTM can be fetched by an NG-RAN node reusing existing mechanisms, and in case of an NG-RAN node deployed in split architecture, the SON reports for LTM are fetched by the gNB-CU.

[0094] In one aspect, the gNB-CU receives from a UE, a SON report for LTM and performs an initial analysis to determine which entity (the gNB-CU, a gNB-DU or both the gNB-CU and a gNB-DU) that can make use of the information in the SON report for LTM to optimize LTM related configuration(s), wherein this determination e.g. may comprise associating said received SON report for LTM with a certain LTM cell switch failure type (e.g., a “too late LTM cell switch”, “too early LTM cell switch”, “LTM cell switch to wrong cell”). The gNB- CU may then forward the SON report for LTM (or at least part of the information comprised in it) to one or more gNB-DUs, optionally also providing to the gNB-DU(s) an indication of an LTM cell switch failure type with which the report (or the forwarded part of the information in the report) is associated. The gNB-CU determines the gNB-DU(s) to be contacted based on information included in the SON report for LTM, such as the cell identity of the cell serving the UE before an LTM cell switch was attempted, the candidate cell to which the LMT switch was attempted, or the cell identity of the cell towards which the UE re-established, or attempted to re-establish, after a failure in LTM cell switch.

[0095] • The gNB-CU may send to the gNB-DU(s) an indication of the LTM cell switch failure type.

[0096] • The gNB-CU may send to the gNB-DU(s) multiple SON reports for LTM, or parts of the information in each of multiple SON reports for LTM (concerning the same UE, or more than one UE) to the same gNB-DU via a single non-UE associated signaling message.

[0097] In one aspect, the gNB-CU sends to the gNB-DU(s) one or more SON reports for LTM (or parts thereof) together with an LTM cell switch failure type, and the LTM cell switch failure type is explicitly signaled. In a possible example of implementation, the signaling message used for this purpose is a new message, e.g., an F1AP CELL SWITCH MOBILITY REPORT message.

[0098] In some aspects, the gNB-CU does not send any indication of LTM cell switch failure type together with the SON report(s) for LTM sent to the gNB-DU(s), but instead leaves this analysis to be done by the gNB-DU(s). Optionally, the gNB-CU may implicitly or explicitly indicate that it wants the gNB-DU to report the result of its analysis of the SON report(s) for LTM data to the gNB-CU. An example of an implicit request could be the presence of one or more certain IE(s) (not conveying an explicit request), or absence of one or more certain IE(s), in the message sending the SON report(s) for LTM data to the gNB-DU. Another example of an implicit request could be that it is specified in a standard that the gNB-DU shall report back to the gNB-CU the result of the gNB-DU’ s analysis of SON report(s) for LTM data received from the gNB-CU (in which case no explicit request for such a report is needed in the message conveying the SON report(s) for LTM data from the gNB-CU to the gNB-DU.

[0099] In another aspect, the gNB-CU sends an indication of the possible cause, or type, of the failure, e.g. as a guide to the gNB-DU’ s / gNB-DUs' analysis of the SON report for LTM data received from the gNB-CU.

[0100] In another aspect, or in some other aspects, the gNB-CU indicates, together with the SON report(s) for LTM data sent from the gNB-CU to the gNB-DU, suggested, or recommended, configuration adaptations to take into account the SON report(s) for LTM data.

[0101] In another aspect, or in some other aspects, the gNB-CU includes, together with the SON report(s) for LTM data sent from the gNB-CU to the gNB-DU, additional information generated or determined or identified during the gNB-CU’ s analysis of the SON report(s) for LTM data, e.g. information about LTM related configuration(s) that the gNB-CU applied to the LTM procedure or LTM configuration (and / or applied at the time of the LTM procedure) that at least part of the SON report(s) for LTM data is related to.

[0102] In one aspect, the gNB-CU waits for feedback(s) / notification(s) from the gNB-DU(s) before determining whether (and if it determines to do so, it executes) further actions related to LMT optimization, e.g., determining if the LTM candidate cell list needs to be modified, and if so, execute such update. With this aspect, and as a further option, the gNB-CU may refrain from its own analysis of the SON report(s) for LTM data (other than determining the relevant gNB-DU(s) to forward the SON report(s) for LTM data to), and instead forward the SON report(s) for LTM data to the gNB-DU(s) to let the gNB-DU(s) perform the analysis (including the initial analysis) and inform the gNB-CU of the analysis result and / or any suitable action to take the SON report(s) for LTM data into account, and / or possibly indicate to the gNB-CU whether it should perform (or may benefit from performing) its own analysis of the SON report(s) for LTM data.

[0103] In another aspect, the gNB-CU, based on the content of SON reports for LTM, determines that an existing LTM candidate cell list needs to be updated.

[0104] This can happen, e.g., if the SON report for LTM indicates that the cell which the UE attempted to reconnect to is not included in the current LTM candidate cell list.

[0105] • In one aspect, the scenario above may occur when the gNB-CU does not read / interpret Layer 1 (LI) measurements included in the SON report for LTM, and the gNB-CU does not wait for feedback / indication from the gNB-DU. It may happen, for example, that the gNB-DU determines that other cells, included in the LTM candidate cell list were reported by the UE, but the decision of the gNB-DU to send the Cell Switch Command was taken too late, and the LTM execution failed. If there is no feedback from gNB-DU to gNB-CU and the gNB-CU does not read / interpret LI measurements, then the gNB-CU may assume that the cell the UE reconnected to, or attempted to reconnect to, is a good candidate for LTM and include that cell in the LTM candidate cell list of subsequent LTM configurations (optionally only if the conditions are similar as for the LTM procedure subject to the SON report(s) for LTM, e.g. in terms of LI measurement results.

[0106] • In another aspect, the scenario above may occur when the gNB-CU reads / interprets Layer 1 (LI) measurements included in the SON report for LTM, and compares them with the L3 measurement reports included by the UE in the RLF -Report. For example, rather than only considering the L3 measurement reports to generate the candidate cell list for the LTM procedure, the gNB-CU may consider also the LI measurement reports. For example, if for a candidate target cell, the LI measurements taken before the RLF shows poor values while the L3 measurements are still satisfactory, the gNB-CU may determine to remove this cell from the list of candidate target cells.

[0107] In one aspect, the LI measurement results included by the UE in the RLF -Report are reported according to a value range standardized in LI -specification, .e.g. in the range -140 dBm to -40 dBm with IdB resolution, as it is in the LI reported value included in the LI UCI signaling, and wherein reported value of 17 means SS-RSRP is greater or equal to -156dB, and reported value of 112 means SS-RSRP is less than or equal -45 dBm.

[0108] In another aspect, the LI measurement results included by the UE in the RLF -Report are reported according to a value range standardized in RRC specification, e.g., in a range defined from -156 dBm to -31 dBm with 1 dB resolution, wherein reported value of 0 means SS-RSRP is greater or equal to -156dB and reported value of 126 means SS-RSRP is less than or equal -31 dBm. According this this latter embodiment, the UE first determines the LI measurements at lower layers, and upon declaring a RLF / HOF, the UE converts the determined LI measurements values into the equivalent values standardized in RRC specification.

[0109] In one aspect, if the gNB-CU is in charge or reading and acting upon the reported LI measurements values, the UE includes in the RLF -Report the corresponding measurement value as standardized in the RRC specification, otherwise if the gNB-DU is in charge or reading and acting upon the reported LI measurements values, the UE includes in the RLF- Report the corresponding measurement values as standardized in the LI- specification.

[0110] In one aspect, before the gNB-DU receives SON reports for LTM (or parts thereof) it requests the gNB-CU for them. This mechanism offers the advantage to allow the gNB-DU to control the inflow of the signaling from the gNB-CU related to LTM optimization. For example, an F1AP message CELL SWITCH MOBILITY REPORT REQUEST (or similar) can be used, where the gNB-DU indicates to the gNB-CU that it is interested (or no longer interested) to receive SON reports for LTM (or parts thereof). Optionally, the request may be refined to indicate different types of SON reports, e.g. indicating interest in receiving certain SON reports for LTM (or parts thereof) (which is equivalent to requesting to receive such SON reports for LTM) and / or indicating lack of interest in receiving certain SON reports for LTM (or parts thereof) (which is equivalent to requesting not to receive such SON reports for LTM).

[0111] In one aspect, one of the gNB-DU contacted by the gNB-CU provides feedback to the gNB-CU (e.g., via a newly defined F1AP CELL SWITCH MOBILITY FEEDBACK message). Such a message can be used to provide indications / information the gNB-CU can use for determining whether (further) LTM related optimization is needed or not. A nonlimiting example of such an indication can be to indicate that “LTM candidate list update needed” or “LTM candidate list update not needed”, and / or to suggest / recommend a certain update of the LTM candidate list (e.g. suggestion / recommendation of one or more cell(s) to add to the list and / or one or more cell(s) to remove from the list). In a dependent embodiment, the gNB-CU performs LTM related optimization based on the received feedback from the gNB-DU, e.g., it updates the LTM cell candidate list.

[0112] In another aspect, the gNB-CU receives from a UE, a SON report for LTM and performs an initial analysis, and determines that before the LTM mobility execution, the UE was connected to a cell served by another RAN node, e.g. another gNB-CU. The gNB-CU sends the SON report for LTM to the other RAN node (e.g. the other gNB-CU).

[0113] FIG. 5 shows signaling according to one aspect, for a UE generating an RLF report with LTM information, for the case of “Too late LTM Cell switch”. In this case, the gNB-CU does not perform an optimization of the LTM cell switch candidate list. This scenario can occur when the UE attempts to re-establish to a cell which is already part of the LTM cell switch candidate list after suffering RLF in the source / serving cell. FIG. 6 shows signaling according to one aspect, for a UE generating an RLF report with LTM information, for the case of “Too late LTM Cell switch”. In this case, the gNB-CU performs an optimization of the LTM cell switch candidate list. This scenario can occur when the UE (after a failed LTM switch or shortly after a successful LTM switch) attempts to reestablish to a cell which was not part of the LTM cell switch candidate list, and the gNB-CU adds the re-establishment cell to the list.

[0114] FIG. 7 shows signaling according to one aspect, for a UE generating an RLF report with LTM information, for the case of “Too early LTM Cell switch”. In this case, the gNB- CU does not perform an optimization of the LTM cell switch candidate list. This scenario can occur when the UE attempts to re-establish to a cell which was already part of the LTM cell switch candidate list. The gNB-DU performs optimization of the LTM cell switch triggers.

[0115] FIG. 8 shows signaling according to one aspect, for a UE generating an RLF report with LTM information, for the case of “LTM Cell switch to Wrong cell”. In this case, the gNB-CU does not perform an optimization of the LTM cell switch candidate list. This scenario can occur when the UE attempts to re-establish to a cell, other than the source or target cell, and the re-establishment cell was already part of the LTM cell switch candidate list. The gNB-DU performs optimization of the LTM cell switch triggers.

[0116] FIG. 9 shows signaling according to one aspect, for a UE generating an RLF report with LTM information, for the case of “LTM Cell switch to Wrong cell”. In this case, the gNB-CU does perform an optimization of the LTM cell switch candidate list. This scenario can occur when the UE attempts to re-establish to a cell, other than the source or target cell, and the re-establishment cell was not part of the LTM cell switch candidate list. The gNB-CU adds the re-establishment cell to the LTM cell switch candidate list.

[0117] Examples of Implementation in Standards

[0118] In the following, some non-limiting examples of implementation for TS 38.473 and TS 38.423 are provided.

[0119] One example of how some of the embodiments can be implemented in the standard is shown below for the Fl AP interface:

[0120] 9.2.10.1 ACCESS AND MOBILITY INDICATION

[0121] This message is sent by gNB-CU to gNB-DU to provide access and mobility information to the gNB-DU.

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

[0123] In the example above the ACCESS AND MOBILITY INDICATION message already existing over the Fl interface has been enhanced with information concerning the failure result analysis that the gNB-CU carries out. The gNB-DU receives therefore the RRC RLF- Report-rl6 IE as part of the NR UE RLF Report Container IE and it also receives the failure analysis result from the gNB-CU. This allows the gNB-DU to take corrective actions to prevent LTE failures.

[0124] In another example of one of the aspects described above, the gNB-CU may send the RLF Report and the new failure type in a new UE-associated F1AP message towards the gNB-DU.

[0125] CELL SWITCH MOBILITY REPORT

[0126] This message is sent by NG-RAN nodei to NG-RAN node? to report an LTM Cell Switch failure event. Direction: NG-RAN node i NG-RAN node 2.

[0127] In another example of one of the aspects described above, the gNB-CU may include in a new message towards the gNB-DU, information concerning how the handover trigger point for LTM mobility from one cell to another cell should be changed. Such enhancement could be provided as a standalone enhancement or together with other information such as those shown in the previous example.

[0128] 9.1.3 xx LTM MOBILITY ADAPTATION REQUEST

[0129] This message is sent by the gNB-CU to the gNB-DU to initiate adaptation of mobility parameters.

[0130] Direction: NG-RAN nodei NG-RAN node?.

[0131] 9.2.2.yy LTM Mobility Parameters Information

[0132] The LTM Mobility Parameters Information IE contains the change of the LTM Mobility Trigger as compared to its current value. The LTM Mobility Trigger corresponds to the threshold at which a cell initializes the LTM mobility procedure towards a specific neighbor cell. Positive value of the change means the LTM mobility is proposed to take place later.

[0133] In the example above, a new message is described, signaled from the gNB-CU to the gNB-DU and indicating to the gNB-DU how the LTM mobility trigger point between two cells, a source and a potential target, should be changed. Methods

[0134] FIG. 10 depicts the steps in a method 100, performed by a UE operative in a wireless communication network, of providing information about an RLF related to an LTM cell switch procedure. An LTM candidate cell list is received from a base station serving the UE (block 102). An LTM cell switch command is received from the serving base station (block 104). The LTM cell switch is attempted (block 106. If no RLF is experienced (block 108), the UE switches to the new cell (block 110). If an RLF in the form of an LTM failure is experienced (block 108), then an 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 (block 112). Upon reconnection to the network, the SON report may be sent to a network node.

[0135] FIG. 11 depicts the steps in a method 200, performed by a CU of a base station serving a UE in a wireless communication network, for performing network optimization after an RLF by the UE, the RLF related to an LTM cell switch procedure (LTM failure). RRC signaling is received, re-establishing the UE in the wireless communication network after the LTM failure by the UE (block 202). An SON report for LTM prepared by the UE is obtained, which includes information related to the LTM failure (block 204). An LTM failure type is determined (block 206). One or more DUs of the base station are selected based on the LTM failure type (block 208). At least part of the SON report for LTM is sent to the selected DU(s) (block 210).

[0136] FIG. 12 depicts the steps in a method 300, performed by a current CU of a current base station in a first RAN of a wireless communication network serving a UE, for performing network optimization after an RLF by the UE, the RLF related to an LTM cell switch procedure (LTM failure). An SON report for LTM prepared by the UE is obtained, which includes information related to the LTM failure. It is determined from the SON report that, prior to an LTM mobility execution, the UE was served by a prior CU of a prior base station, the prior CU being different from the current CU. The SON report for LTM obtained from the UE is sent to the prior CU.

[0137] Network and Apparatus Descriptions

[0138] FIG. 13 shows an example of a communication system QQ100 in accordance with some embodiments. In the example, the communication system QQ1OO includes a telecommunication network QQ102 that includes an access network QQ104, such as a radio access network (RAN), and a core network QQ106, which 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 be generally referred to as network nodes QQ110), or any other similar 3rdGeneration Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network QQ102 includes one or more Open- RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network QQ102 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network QQ102, including one or more network nodes QQ110 and / or core network nodes QQ108.

[0139] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O- CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the O- RAN Alliance or comparable technologies. The network nodes QQ110 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs QQ112a, QQ112b, QQ1 12c, and QQ112d (one or more of which may be generally referred to as UEs QQ112) to the core network QQ106 over one or more wireless connections.

[0140] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different 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 may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system QQ100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0141] The UEs QQ112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes QQ110 and other communication devices. Similarly, the network nodes QQ1 10 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs QQ112 and / or with other network nodes or equipment in the telecommunication network QQ102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network QQ102.

[0142] In the depicted example, the core network QQ106 connects the network nodes QQ110 to one or more host computing systems, such as host QQ116. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network QQ106 includes one more core network nodes (e.g., core network node QQ108) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node QQ108. Example core network nodes include functions of one or more of a 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 De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF). The host QQ116 may be under the ownership or control of a service provider other than an operator or provider of the access network QQ104 and / or the telecommunication network QQ102. The host QQ116 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0143] As a whole, the communication system QQ100 of FIG. 13 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are 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., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (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.

[0144] In some examples, the telecommunication network QQ102 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network QQ102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network QQ102. For example, the telecommunications network QQ102 may 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 loT services to yet further UEs.

[0145] In some examples, the UEs QQ112 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network QQ104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network QQ104. Additionally, a UE may be configured for operating in single- or multi-RAT or multistandard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi -radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0146] In the example, the hub QQ114 communicates with the access network QQ104 to facilitate indirect communication between one or more UEs (e.g., UE QQ112c and / or QQ112d) and network nodes (e.g., network node QQ110b). In some examples, the hub QQ114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub QQ114 may be a broadband router enabling access to the core network QQ106 for the UEs. As another example, the hub QQ114 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes QQ110, or by executable code, script, process, or other instructions in the hub QQ114. As another example, the hub QQ114 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub QQ114 may be a content source. For example, for a UE that is a VR device, display, loudspeaker, or other media delivery device, the hub QQ114 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub QQ114 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub QQ114 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0147] The hub QQ114 may have a constant / persistent or intermittent connection to the network node QQ110b. The hub QQ114 may also allow for a different communication scheme and / or schedule between the hub QQ114 and UEs (e.g., UE QQ112c and / or QQ112d), and between the hub QQ114 and the core network QQ106. In other examples, the hub QQ114 is connected to the core network QQ106 and / or one or more UEs via a wired connection. Moreover, the hub QQ114 may be configured to connect to an M2M service provider over the access network QQ104 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes QQ110 while still connected via the hub QQ114 via a wired or wireless connection. In some embodiments, the hub QQ114 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node QQ110b. In other embodiments, the hub QQ114 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node QQ110b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0148] FIG. 14 shows a UE QQ200 in accordance with some embodiments. The UE QQ200 presents additional details of some embodiments of the UE QQ112 of Figure 2. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage / playback device, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), an Augmented Reality (AR) or Virtual Reality (VR) device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB- loT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0149] A UE may support device-to-device (D2D) communication, for example by implementing a 3 GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0150] The UE QQ200 includes processing circuitry QQ202 that is operatively coupled via a bus QQ204 to an input / output interface QQ206, a power source QQ208, a memory QQ210, a communication interface QQ212, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in FIG. 14. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0151] The processing circuitry QQ202 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory QQ210. The processing circuitry QQ202 may 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, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry QQ202 may include multiple central processing units (CPUs).

[0152] In the example, the input / output interface QQ206 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE QQ200. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0153] In some embodiments, the power source QQ208 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source QQ208 may further include power circuitry for delivering power from the power source QQ208 itself, and / or an external power source, to the various parts of the UE QQ200 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source QQ208. Power circuitry may perform any formatting, converting, or other modification to the power from the power source QQ208 to make the power suitable for the respective components of the UE QQ200 to which power is supplied.

[0154] The memory QQ210 may be or 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), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory QQ210 includes one or more application programs QQ214, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data QQ216. The memory QQ210 may store, for use by the UE QQ200, any of a variety of various operating systems or combinations of operating systems.

[0155] The memory QQ210 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory QQ210 may allow the UE QQ200 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory QQ210, which may be or comprise a device-readable storage medium.

[0156] The processing circuitry QQ202 may be configured to communicate with an access network or other network using the communication interface QQ212. The communication interface QQ212 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna QQ222. The communication interface QQ212 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter QQ218 and / or a receiver QQ220 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, 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. In the illustrated embodiment, communication functions of the communication interface QQ212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0157] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface QQ212, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0158] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0159] A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and / or software in dependence of the intended application of the loT device in addition to other components as described in relation to the UE QQ200 shown in FIG. 14.

[0160] As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0161] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0162] FIG. 15 shows a network node QQ300 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g, radio access points), base stations (BSs) (e.g, radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), O-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O-CU).

[0163] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0164] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi -standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0165] The network node QQ300 includes a processing circuitry QQ302, a memory QQ304, a communication interface QQ306, and a power source QQ308. The network node QQ300 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node QQ300 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node QQ300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory QQ304 for different RATs) and some components may be reused (e.g., a same antenna QQ310 may be shared by different RATs). The network node QQ300 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node QQ300, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node QQ300.

[0166] The processing circuitry QQ302 may comprise a combination of one or more of 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 encoded logic operable to provide, either alone or in conjunction with other network node QQ300 components, such as the memory QQ304, to provide network node QQ300 functionality.

[0167] In some embodiments, the processing circuitry QQ302 includes a system on a chip (SOC). In some embodiments, the processing circuitry QQ302 includes one or more of radio frequency (RF) transceiver circuitry QQ312 and baseband processing circuitry QQ314. In some embodiments, the radio frequency (RF) transceiver circuitry QQ312 and the baseband processing circuitry QQ314 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry QQ312 and baseband processing circuitry QQ314 may be on the same chip or set of chips, boards, or units.

[0168] The memory QQ304 may comprise any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computerexecutable memory devices that store information, data, and / or instructions that may be used by the processing circuitry QQ302. The memory QQ304 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry QQ302 and utilized by the network node QQ300. The memory QQ304 may be used to store any calculations made by the processing circuitry QQ302 and / or any data received via the communication interface QQ306. In some embodiments, the processing circuitry QQ302 and memory QQ304 is integrated.

[0169] The communication interface QQ306 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface QQ306 comprises port(s) / terminal(s) QQ316 to send and receive data, for example to and from a network over a wired connection. The communication interface QQ306 also includes radio front-end circuitry QQ318 that may be coupled to, or in certain embodiments a part of, the antenna QQ310. Radio front-end circuitry QQ318 comprises filters QQ320 and amplifiers QQ322. The radio front-end circuitry QQ318 may be connected to an antenna QQ310 and processing circuitry QQ302. The radio front-end circuitry may be configured to condition signals communicated between antenna QQ310 and processing circuitry QQ302. The radio front-end circuitry QQ318 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry QQ318 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters QQ320 and / or amplifiers QQ322. The radio signal may then be transmitted via the antenna QQ310. Similarly, when receiving data, the antenna QQ310 may collect radio signals which are then converted into digital data by the radio front-end circuitry QQ318. The digital data may be passed to the processing circuitry QQ302. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

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

[0171] The antenna QQ310 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna QQ310 may be coupled to the radio front-end circuitry QQ318 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna QQ310 is separate from the network node QQ300 and connectable to the network node QQ300 through an interface or port.

[0172] The antenna QQ310, communication interface QQ306, and / or the processing circuitry QQ302 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna QQ310, the communication interface QQ306, and / or the processing circuitry QQ302 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment. The power source QQ308 provides power to the various components of network node QQ300 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source QQ308 may further comprise, or be coupled to, power management circuitry to supply the components of the network node QQ300 with power for performing the functionality described herein. For example, the network node QQ300 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source QQ308. As a further example, the power source QQ308 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0173] Embodiments of the network node QQ300 may include additional components beyond those shown in FIG. 15 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node QQ300 may include user interface equipment to allow input of information into the network node QQ300 and to allow output of information from the network node QQ300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node QQ300. In some embodiments providing a core network node, such as core network node 108 of FIG. QQ1, some components, such as the radio front-end circuitry QQ318 and the RF transceiver circuitry QQ312 may be omitted.

[0174] FIG. 16 is a block diagram illustrating a virtualization environment QQ400 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments QQ400 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment QQ400 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an 0-2 interface. Virtualization may facilitate distributed implementations of a network node, UE, core network node, or host.

[0175] Applications QQ402 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0176] Hardware QQ404 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may 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 VMs QQ408a and QQ408b (one or more of which may be generally referred to as VMs QQ408), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer QQ406 may present a virtual operating platform that appears like networking hardware to the VMs QQ408.

[0177] The VMs QQ408 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer QQ406. Different embodiments of the instance of a virtual appliance QQ402 may be implemented on one or more of VMs QQ408, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0178] In the context of NFV, a VM QQ408 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs QQ408, and that part of hardware QQ404 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs QQ408 on top of the hardware QQ404 and corresponds to the application QQ402.

[0179] Hardware QQ404 may be implemented in a standalone network node with generic or specific components. Hardware QQ404 may implement some functions via virtualization. Alternatively, hardware QQ404 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration QQ410, which, among others, oversees lifecycle management of applications QQ402. In some embodiments, hardware QQ404 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system QQ412 which may alternatively be used for communication between hardware nodes and radio units.

[0180] Although the computing devices described herein (e.g., UEs, network nodes) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0181] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain 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 functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0182] Aspects of the present disclosure present numerous advantages over the prior art, and may achieve one or more of the following technical effects. Methods described herein at both the UE and CU(s) allow self-optimization of LTM functionality. This facilitates the use of LTM cell switching, which brings the benefit of exploiting the reduced interruption times in case of mobility that can be achieved when using LTM compared to traditional Layer 3 mobility.

[0183] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc., are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the aspects disclosed herein may be applied to any other aspect, wherever appropriate. Likewise, any advantage of any of the aspects may apply to any other aspects, and vice versa. Other objectives, features and advantages of the enclosed aspects will be apparent from the description.

[0184] The term “unit” may have conventional meaning in the field of electronics, electrical devices and / or electronic devices and may include, for example, electrical and / or electronic circuitry, devices, modules, processors, memories, logic solid state and / or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and / or displaying functions, and so on, as such as those that are described herein. As used herein, the term “configured to” means set up, organized, adapted, or arranged to operate in a particular way; the term is synonymous with “designed to,” or with respect to processing circuitry, “programmed to.”

[0185] Some of the aspects contemplated herein are described more fully with reference to the accompanying drawings. Other aspects, however, are contained within the scope of the subject matter disclosed herein. The disclosed subject matter should not be construed as limited to only the aspects set forth herein; rather, these aspects are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0186] The present disclosure may, of course, be carried out in other ways than those specifically set forth herein without departing from essential characteristics of the disclosure. The present aspects are to be considered in all respects as illustrative and not restrictive, and all changes coming within the meaning and equivalency range of the appended aspects are intended to be embraced therein.

[0187] EMBODIMENTS

[0188] Group A Embodiments

[0189] 1. A method, performed by a user equipment (UE) operative in a wireless communication network, of providing information about a Radio Link Failure (RLF) related to an L1 / L2 Triggered Mobility (LTM) cell switch procedure, the method comprising: receiving, from a serving Distributed Unit (DU) of a base station serving the UE, an LTM candidate cell list; performing LTM early synchronization to at least one cell in the candidate cell list; receiving an LTM cell switch command from the serving DU; attempting the LTM cell switch and experiencing an RLF (LTM failure); and preparing a Self-Organizing Network (SON) report for LTM 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.

[0190] 2. The method of embodiment 1 further comprising, after the LTM failure: re-establishing connectivity to the wireless communication network; and sending the SON report for LTM to a Central Unit (CU) of the serving base station.

[0191] 3. The method of embodiment 1 wherein the LTM cell switch RLF type is Too Late LTM Cell Switch.

[0192] 4. The method of embodiment 1 wherein the LTM cell switch RLF type is Too Early LTM Cell Switch.

[0193] 5. The method of embodiment 1 wherein the LTM cell switch RLF type is LTM Cell Switch to Wrong Cell.

[0194] Group B Embodiments

[0195] 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) by the UE, the RLF related to an L1 / L2 Triggered Mobility (LTM) cell switch procedure (LTM failure), the method comprising: receiving Radio Resource Control (RRC) signaling re-establishing the UE in the wireless communication network after the LTM failure by the UE; obtaining a Self-Organizing Network (SON) report for LTM prepared by the UE, which includes information related to the LTM failure; determining an LTM failure type; and selecting one or more Distributed Units (DU) of a base station based on the LTM failure type; and sending at least part of the SON report for LTM to the selected DU(s).

[0196] 7. The method of embodiment 6, wherein sending at least part of the SON report for LTM to the selected DU(s) comprises also sending the LTM failure type to the selected DU(s).

[0197] 8. The method of embodiment 6, wherein sending at least part of the SON report for LTM to the selected DU(s) comprises also sending an explicit indication that the selected DU(s) is to report the results of its analysis of the SON report for LTM data back to the CU.

[0198] 9. The method of embodiment 6, wherein sending at least part of the SON report for LTM to the selected DU(s) comprises also sending an implicit indication that the selected DU(s) is to report the results of its analysis of the SON report for LTM data back to the CU, by the inclusion or exclusion of a predetermined Information Element (IE).

[0199] 10. The method of embodiment 6, wherein sending at least part of the SON report for LTM to the selected DU(s) comprises sending the SON report for LTM data in a CELL SWITCH MOBILITY REPORT.

[0200] 11. The method of embodiment 10, wherein the CELL SWITCH MOBILITY REPORT is an Fl Application Protocol (F1AP) message .

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

[0202] 13. The method of embodiment 10, further comprising, after sending the CELL SWITCH MOBILITY REPORT, receiving a CELL SWITCH MOBILITY FEEDBACK message.

[0203] 14. The method of embodiment 13 further comprising analyzing the SON report for LTM data, other than to determine the LTM failure type and select DU(s), only after receiving the CELL SWITCH MOBILITY FEEDBACK message from one or more selected DUs.

[0204] 15. The method of embodiment 6, wherein sending at least part of the SON report for LTM to the selected DU(s) comprises also sending one or more recommended configuration adaptations.

[0205] 16. The method of embodiment 6, wherein sending at least part of the SON report for LTM to the selected DU(s) comprises also sending information about one ore more LTM related configurations.

[0206] 17. The method of embodiment 6, further comprising updating an existing LTM candidate cell list based on the SON report for LTM.

[0207] 18. The method of embodiment 6 wherein one or more selected DUs are part of a different base station.

[0208] 19. The method of embodiment 6 wherein one or more selected DUs are part of a different Radio Access Network (RAN).

[0209] 20. The method of embodiment 6, wherein the determined LTM failure type is Too Late LTM Cell Switch.

[0210] 21. The method of embodiment 20, wherein the cell to which the UE performed reestablishment was not on an LTM candidate cell list sent to the UE prior to the LTM failure, and further comprising: adding the cell to which the UE performed re-establishment to the LTM candidate cell list.

[0211] 22. The method of embodiment 20, wherein the CELL SWITCH MOBILITY REPORT includes a directive to the DU(s) to anticipate the LTM cell switch.

[0212] 23. The method of embodiment 22, wherein the directive to anticipate the LTM cell switch comprises a directive that the source cell signal measured for LTM triggering be “X” dBm higher with respect to the prior LTM trigger point.

[0213] 24. The method of embodiment 22, wherein the directive to anticipate the LTM cell switch comprises a directive that the target cell signal measured for LTM triggering be “Y” dBm lower with respect to the prior LTM trigger point.

[0214] 25. The method of embodiment 22, wherein the directive to anticipate the LTM cell switch comprises a directive that both the source cell signal measured for LTM triggering be “X” dBm higher with respect to the prior LTM trigger point and the target cell signal measured for LTM triggering be “Y” dBm lower with respect to the prior LTM trigger point.

[0215] 26. The method of embodiment 22, wherein the directive to anticipate the LTM cell switch comprises an LTM cell switch should only be triggered if a difference between source and target cell signals measured for LTM triggering is greater than a delta threshold value.

[0216] 27. The method of embodiment 6, wherein the determined LTM failure type is Too Early LTM Cell Switch, the UE re-establishment procedure was to the original serving DU, and wherein the CELL SWITCH MOBILITY REPORT is sent to the serving DU and includes a directive to the serving DU to delay the LTM cell switch.

[0217] 28. The method of embodiment 27, wherein the directive to delay the LTM cell switch comprises a directive that the source cell signal measured for LTM triggering be “X” dBm lower with respect to the prior LTM trigger point.

[0218] 29. The method of embodiment 27, wherein the directive to delay the LTM cell switch comprises a directive that the target cell signal measured for LTM triggering be “Y” dBm higher with respect to the prior LTM trigger point.

[0219] 30. The method of embodiment 27, wherein the directive to delay the LTM cell switch comprises a directive that both the source cell signal measured for LTM triggering be “X” dBm lower with respect to the prior LTM trigger point and the target cell signal measured for LTM triggering be “Y” dBm higher with respect to the prior LTM trigger point.

[0220] 31. The method of embodiment 27, wherein the directive to delay the LTM cell switch comprises an LTM cell switch should only be triggered if a difference between source and target cell signals measured for LTM triggering is greater than a delta threshold value.

[0221] 32. The method of embodiment 6, wherein the determined LTM failure type is LTM cell switch to Wrong Cell.

[0222] 33. The method of embodiment 32, wherein the cell to which the UE performed reestablishment was not on an LTM candidate cell list sent to the UE prior to the LTM failure, and further comprising: adding the cell to which the UE performed re-establishment to the LTM candidate cell list.

[0223] 34. The method of embodiment 32, wherein the CELL SWITCH MOBILITY REPORT includes a directive to the DU(s) that one of the LTM potential target cells should be prioritized over other potential target cells.

[0224] 35. The method of embodiment 34, wherein the directive further indicates an offset by which the LTM trigger point towards the prioritized cell shall be anticipated.

[0225] 36. The method of embodiment 34, wherein the directive further indicates a value representing a level of prioritization of the prioritized target cell.

[0226] Group C Embodiments

[0227] 37. A user equipment for providing information about a Radio Link Failure (RLF) related to an L1 / L2 Triggered Mobility (LTM) cell switch procedure, comprising: processing circuitry configured to perform any of the steps of any of the Group A embodiments; and power supply circuitry configured to supply power to the processing circuitry.

[0228] 38. A network node for performing network optimization after a Radio Link Failure (RLF) by the UE, the RLF related to an L1 / L2 Triggered Mobility (LTM) cell switch procedure (LTM failure), the network node comprising: processing circuitry configured to perform any of the steps of any of the Group B embodiments; power supply circuitry configured to supply power to the processing circuitry.

[0229] 39. A user equipment (UE) for providing information about a Radio Link Failure (RLF) related to an L1 / L2 Triggered Mobility (LTM) cell switch procedure, the UE comprising: an antenna configured to send and receive wireless signals; radio front-end circuitry connected to the antenna and to processing circuitry, and configured to condition signals communicated between the antenna and the processing circuitry; the processing circuitry being configured to perform any of the steps of any of the Group A embodiments; an input interface connected to the processing circuitry and configured to allow input of information into the UE to be processed by the processing circuitry; an output interface connected to the processing circuitry and configured to output information from the UE that has been processed by the processing circuitry; and a battery connected to the processing circuitry and configured to supply power to the UE. ABBREVIATIONS

Claims

CLAIMSWhat is claimed is:

1. A method (100), performed by a user equipment, UE, operative in a wireless communication network, of providing information about a Radio Link Failure, RLF, related to an L1 / L2 Triggered Mobility, LTM, cell switch procedure, the method characterized by: receiving (102), from a base station serving the UE, an LTM candidate cell list; receiving (104) an LTM cell switch command from the serving base station; attempting (106) the LTM cell switch and experiencing (108) an RLF in the form of an LTM failure; and preparing (112) a Self-Organizing Network, SON, report for LTM 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.

2. The method (100) of claim 1, further comprising, prior to receiving an LTM cell switch command from the serving base station, performing LTM early synchronization to at least one cell in the candidate cell list.

3. The method (100) of either of claims 1 or 2 further comprising, after the LTM failure: re-establishing connectivity to the wireless communication network; and sending the SON report for LTM to the serving base station.

4. The method (100) of claim 3 wherein the base station to which the SON report for LTM is sent is the same base station from which the UE received the LTM cell switch command.

5. The method (100) of claim 3 wherein the base station to which the SON report for LTM is sent is a different base station than the base station from which the UE received the LTM cell switch command.

6. A method (200), 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, by the UE, the RLF related to an L1 / L2 Triggered Mobility, LTM, cell switch procedure, LTM failure, the method comprising: receiving (202) Radio Resource Control, RRC, signaling re-establishing the UE in thewireless communication network after the LTM failure by the UE; obtaining (204) a Self-Organizing Network, SON, report for LTM prepared by the UE, which includes information related to the LTM failure; determining (206) an LTM failure type; and selecting (208) one or more Distributed Units, DU, of the base station based on the LTM failure type; and sending (210) at least part of the SON report for LTM to the selected DU(s).

7. The method (200) of claim 6, wherein sending at least part of the SON report for LTM to the selected DU(s) comprises also sending the LTM failure type to the selected DU(s).

8. The method (200) of either of claims 6 or 7, wherein sending at least part of the SON report for LTM to the selected DU(s) comprises also sending an explicit indication that the selected DU(s) is to report the results of its analysis of the SON report for LTM data back to the CU.

9. The method (200) of any of claims 6-8, wherein sending at least part of the SON report for LTM to the selected DU(s) comprises also sending an implicit indication that the selected DU(s) is to report the results of its analysis of the SON report for LTM data back to the CU, by the inclusion or exclusion of a predetermined Information Element (IE).

10. The method (200) of any of claims 6-9, wherein sending at least part of the SON report for LTM to the selected DU(s) comprises also sending one or more recommended configuration adaptations.

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

12. The method (200) of any of claims 6-11, further comprising updating an existing LTM candidate cell list based on the SON report for LTM.

13. The method (200) of any of claims 6-12, wherein the determined LTM failure type is Too Late LTM Cell Switch.

14. The method (200) of claim 13, wherein the cell to which the UE performed reestablishment was not an LTM candidate cell list sent to the UE prior to the LTM failure, and further comprising: adding the cell to which the UE performed re-establishment to the LTM candidate cell list.

15. The method (200) of any of claims 6-12, wherein the determined LTM failure type is LTM cell switch to Wrong Cell.

16. The method (200) of claim 15, wherein the cell to which the UE performed reestablishment was not an LTM candidate cell list sent to the UE prior to the LTM failure, and further comprising: adding the cell to which the UE performed re-establishment to the LTM candidate cell list.

17. The method (200) of claim 6, wherein the at least part of the SON report for LTM includes a directive to the DU(s) that one of the LTM potential target cells should be prioritized over other potential target cells.

18. The method (200) of claim 17, wherein the directive further indicates an offset by which the LTM trigger point towards the prioritized cell shall be anticipated.

19. A method (300), performed by a current Central Unit, CU, of a current base station in a first Radio Access Network, RAN, of a wireless communication network, serving a user equipment, UE, for performing network optimization after a Radio Link Failure, RLF, by the UE, the RLF related to an L1 / L2 Triggered Mobility, LTM, cell switch procedure, LTM failure, the method comprising: obtaining (302) a Self-Organizing Network, SON, report for LTM prepared by the UE, which includes information related to the LTM failure; determining (204) from the SON report that, prior to an LTM mobility execution, the UE was served by a prior CU of a prior base station, the prior CU being different from the current CU; and sending (206) the SON report for LTM obtained from the UE to the prior CU.

20. The method (300) of claim 19 wherein the prior base station is part of the first RAN.

21. The method (300) of claim 19 wherein the prior base station is part of a second RAN different than the first RAN.

22. A user equipment for providing information about a Radio Link Failure, RLF, related to an L1 / L2 Triggered Mobility, LTM, cell switch procedure, comprising: processing circuitry configured to perform any of the steps of any of claims 1-5; and power supply circuitry configured to supply power to the processing circuitry.

23. A network node for performing network optimization after a Radio Link Failure, RLF, by a user equipment, UE, the RLF related to an L1 / L2 Triggered Mobility, LTM, cell switch procedure, LTM failure, the network node comprising: processing circuitry configured to perform any of the steps of any of claims 6-18; and power supply circuitry configured to supply power to the processing circuitry.

24. A network node for performing network optimization after a Radio Link Failure, RLF, by a user equipment, UE, the RLF related to an L1 / L2 Triggered Mobility, LTM, cell switch procedure, LTM failure, the network node comprising: processing circuitry configured to perform any of the steps of any of claims 19-21; and power supply circuitry configured to supply power to the processing circuitry.

25. A user equipment, UE, for providing information about a Radio Link Failure, RLF, related to an L1 / L2 Triggered Mobility, LTM, cell switch procedure, the UE comprising: an antenna configured to send and receive wireless signals; radio front-end circuitry connected to the antenna and to processing circuitry, and configured to condition signals communicated between the antenna and the processing circuitry; the processing circuitry being configured to perform any of the steps of any of claims 1- 5; an input interface connected to the processing circuitry and configured to allow input of information into the UE to be processed by the processing circuitry; an output interface connected to the processing circuitry and configured to outputinformation from the UE that has been processed by the processing circuitry; and a battery connected to the processing circuitry and configured to supply power to the UE.

Images