Extensions to Self-Organizing Network Reporting for Wireless Link Failures after Dual-Active Protocol Stack Fallback

Abstract

A method is provided for reporting failure information in a self-organizing network (SON) implemented by a wireless device. The method includes receiving a handover command from a source cell ("cell") to attempt a handover to a target cell while connected to the cell, where a dual active protocol stack (DAPS) is configured for one or more bearers associated with the handover to the target cell. The method includes experiencing a failure while attempting the handover. The method includes storing first failure information associated with the failure. The method includes performing a DAPS fallback to the cell based at least in part on experiencing the failure. The method includes experiencing a radio link failure (RLF) while connected to the cell. The method includes storing second failure information associated with experiencing the RLF. The method includes transmitting the first or second failure information towards the SON.

Description

[Technical field]

[0001] The present disclosure relates generally to communications, and more particularly to communication methods and associated devices and nodes supporting wireless communications. [Background technology]

[0002] 3GPP wireless communication system

[0003] Consider the simplified wireless communication system shown in Figure 1, where there is a UE 102 that communicates with one or more access nodes 103-104 that are connected to a network node 106. The access nodes 103-104 are part of a wireless access network 100.

[0004] In a wireless communication system according to the 3GPP Evolved Packet System (EPS) standard specification (also called Long Term Evolution (LTE) or 4G) as specified in 3GPP TS36.300 v.16.2.0 and related specifications, the access nodes 103-104 generally correspond to Evolved Node Bs (eNBs) and the network nodes 106 generally correspond to either Mobility Management Entities (MMEs) and / or Serving Gateways (SGWs). The eNBs are part of a radio access network 100, which in this case is an E-UTRAN (Enhanced Universal Terrestrial Radio Access Network), and the MME and SGW are both part of an EPC (Evolved Packet Core Network). The eNBs are interconnected via an X2 interface and connected to the EPC via an S1 interface, more specifically to the MME via S1-C and to the SGW via S1-U.

[0005] On the other hand, in a wireless communication system conforming to the 3GPP 5G System (5GS) standard specification (also called New Radio (NR) or 5G) as specified in 3GPP TS38.300 and related specifications, the access nodes 103-104 generally correspond to 5G Node Bs (gNBs), and the network nodes 106 generally correspond to either an Access and Mobility Management Function (AMF) and / or a User Plane Function (UPF). The gNBs are part of a radio access network 100, which in this case is a Next Generation Radio Access Network (NG-RAN), and the AMF and UPF are both part of a 5G Core Network (5GC). The gNBs are interconnected via an Xn interface and connected to a 5GC via an NG interface, more specifically to the AMF via an NG-C and to the UPF via an NG-U.

[0006] To support fast mobility between NR and LTE and to avoid core network changes, LTE eNBs may also be connected to the 5G-CN via NG-U / NG-C and support the Xn interface. eNBs connected to 5GC are called next generation eNBs (ng-eNBs) and are considered part of the NG-RAN. LTE connected to 5GC is not further described herein, but it should be noted that most of the solutions / features described herein for LTE and NR also apply to LTE connected to 5GC. In this specification, the term LTE refers to LTE-EPC when used without further specification.

[0007] Mobility in RRC_CONNECTED in LTE and NR

[0008] Mobility in the RRC_CONNECTED state is also known as handover. The purpose of handover is, for example, to move a UE by mobility from a source access node using a source radio connection (also known as source cell connection) to a target access node using a target radio connection (also known as target cell connection). The source radio connection relates to a source cell controlled by the source access node. The target radio connection relates to a target cell controlled by the target access node. In other words, during handover, the UE moves from a source cell to a target cell. The source access node or source cell may be referred to as the "source" and the target access node or target cell may be referred to as the "target".

[0009] In some cases, the source and target access nodes are different nodes, such as different eNBs or gNBs. These cases are also referred to as inter-node, inter-eNB or inter-gNB handover. In other cases, the source and target access nodes are the same node, such as the same eNB and gNB. These cases are also referred to as intra-node, intra-eNB or intra-gNB handover, covering the case where the source and target cells are controlled by the same access node. In still other cases, the handover is performed within the same cell (and therefore within the same access node that controls that cell), which is also referred to as intra-cell handover.

[0010] It should therefore be understood that source access node and target access node refer to the roles served by a given access node during handover of a particular UE. For example, a given access node may act as a source access node during handover of one UE, but the access node also acts as a target access node during handover of a different UE. Also, in case of intranode or intracell handover of a given UE, the same access node acts as both source access node and target access node for that UE.

[0011] An RRC_CONNECTED UE in E-UTRAN or NG-RAN may be configured by the network to perform measurements of the serving cell and neighboring cells, and based on the measurement report sent by the UE, the network may determine to perform a handover of the UE to the neighboring cell. The network then sends a handover command message (in LTE, an RRC connection reconfiguration message with a field called mobilityControlInfo, and in NR, an RRC reconfiguration message with a reconfigurationWithSync field) to the UE.

[0012] These reconfigurations are in fact prepared by the target access node upon request from the source access node (via the X2 or S1 interface in case of EUTRA-EPC, or via the Xn or NG interface in case of NG-RAN-5GC) and take into account the existing Radio Resource Control (RRC) configuration and UE capabilities provided in the request from the source access node and its own capabilities and resource situation in the intended target cell and the target access node. The reconfiguration parameters provided by the target access node include, for example, information required by the UE to access the target access node, such as the random access configuration, a new C-RNTI (Cell Radio Network Temporary Identifier) ​​allocated by the target access node, and security parameters that enable the UE to calculate new security keys related to the target access node, so that, once the UE has accessed the target access node, it can send a handover complete message (in LTE, the RRC Connection Reconfiguration Complete message, and in NR, the RRC Reconfiguration Complete message) on SRB1 (Signaling Radio Bearer 1) encrypted and integrity protected based on the new security key.

[0013] FIG. 2 summarizes the signaling flow between a UE, a source access node (also known as a source gNB, source eNB or source cell), and a target access node (also known as a target gNB, target eNB or target cell) during a handover procedure, using LTE as an example.

[0014] In FIG. 2, in step 1, the UE sends a measurement report during an interval in which data is being transmitted to the source access node, and the source access node transmits the data to the serving gateway.

[0015] In step 2, the source access node decides that a handover should be performed. This may be based on measurement reports. In step 3, the source access node sends a handover request to the target access node. In step 5, the source access node sends an RRC Connection Reconfiguration message to the UE.

[0016] In step 6, the UE detaches from the source access node. In step 7, the source access node sends a sequence number (SN) status transfer to the target access node. The source access node forwards any data received from the UE to the target access node.

[0017] In step 8, the UE and the target access node perform a random access procedure to initiate sending user data via the target access node towards the SGW. In step 9, the UE sends an RRC connection reconfiguration complete message to the target access node. The UE then sends user data to the target access node.

[0018] In step 10, the target access node sends a path switch request to the MME. In step 11, the MME and the SGW perform path switch related signaling to change the path from the source access node to the target access node. The UE's user data can then flow between the target access node and the SGW. The SGW sends an end marker to the source access node, which forwards the end marker to the target access node. In step 12, the MME sends a path switch request acknowledgement to the target access node. In step 13, the target access node sends a UE context release message to the source access node.

[0019] User Plane Handling During Handover

[0020] Depending on the required Quality of Service (QoS), either seamless or lossless handover is performed for each user plane radio bearer accordingly, as described in the following subsections.

[0021] Seamless Handover

[0022] Seamless handover applies to user plane radio bearers mapped on Radio Link Control (RLC) Unacknowledged Mode (UM). These types of data are generally reasonably tolerant to loss but not very tolerant to delay (e.g., voice services). Therefore, seamless handover is designed to minimize complexity and delay, but may result in the loss of some Packet Data Convergence Protocol (PDCP) Service Data Units (SDUs).

[0023] At handover, for radio bearers to which seamless handover applies, PDCP entities including header compression contexts are reset and the count values ​​are set to 0. There is no security reason to maintain the count values, since new keys are generated at handover. PDCP SDUs at the UE for which transmission has not yet started will be transmitted to the target access node after handover. At the source access node, PDCP SDUs that have not yet been transmitted can be forwarded to the target access node via the X2 / Xn interface. PDCP SDUs for which transmission has already started but not successfully received will be lost. This minimizes complexity, since no context (e.g. configuration information) needs to be transferred between the source and target access nodes at handover.

[0024] Lossless Handover

[0025] Based on the SN added to the PDCP data PDUs, it is possible to guarantee in-order delivery during handover and even provide a fully lossless handover capability, performing retransmission of PDCP SDUs whose reception has not yet been acknowledged prior to the handover. This lossless handover capability is primarily used for delay-tolerant services such as file downloads, where the loss of one PDCP SDU may result in a sudden reduction in the data rate due to the Transmission Control Protocol (TCP) reaction.

[0026] Lossless handover applies for user plane radio bearers mapped on the RLC acknowledged mode (AM). When RLC AM is used, PDCP SDUs that have been transmitted but not yet acknowledged by the RLC layer are stored in a retransmission buffer in the PDCP layer.

[0027] To ensure lossless handover in the downlink (DL), the source access node forwards DL PDCP SDUs stored in a retransmission buffer, as well as fresh DL PDCP SDUs received from the gateway, to the target access node for (re)transmission. The source access node receives an indication from the core network gateway (SGW in LTE / EPC, UPF in LTE / 5GC and NR) indicating the last packet (so-called "end marker" packet) to be sent to the source access node. The source access node also forwards this indication to the target access node 104, so that the target access node knows when it can start transmitting packets received directly from the gateway.

[0028] To ensure lossless handover in the uplink (UL), the UE retransmits UL PDCP SDUs stored in the PDCP retransmission buffer at the target access node. The retransmission is triggered by the PDCP re-establishment performed upon receipt of the handover command. The source access node will forward all PDCP SDUs received out of order to the target access node after decryption and recovery. Thus, the target access node 104 can reorder the PDCP SDUs received from the source access node 103 and the retransmitted PDCP SDUs received from the UE based on the PDCP SN maintained during the handover and deliver them to the gateway in the correct order.

[0029] An additional feature of lossless handover is the so-called selective retransmission. In some cases it may happen that a PDCP SDU is successfully received but the corresponding RLC acknowledgement is not successfully received. In this case, after the handover there may be unnecessary retransmissions initiated by the UE or the target access node based on an incorrect status received from the RLC layer. To avoid these unnecessary retransmissions, PDCP status reports may be sent from the target access node to the UE and from the UE to the target access node. Whether a PDCP status report should be sent after the handover is configured independently for each radio bearer and for each direction.

[0030] Rel-16 Dual Active Protocol Stack (DAPS) Handover

[0031] To address the shortcomings of Rel-14 MBB and achieve interruption times of around 0 ms, an enhanced version of Make-Before-Break (MBB), also known as Dual Active Protocol Stack (DAPS) handover, is specified for Rel-16 for both LTE and NR.

[0032] DAPS handover is defined as a handover procedure in which the UE maintains the source gNB connection until it releases the source cell after receiving an RRC message for handover (e.g., RRC reconfiguration with reconfigurationWithSync for the Master Cell Group (MCG)) and after successful random access to the target gNB.

[0033] During DAPS handover, the UE is assumed to be capable of transmitting and receiving simultaneously from the source and target cells. In practice, this may require the UE to be equipped with dual transmit / receive (Tx / Rx) chains. Dual Tx / Rx chains also potentially allow DAPS handover to be supported in other handover scenarios, such as inter-frequency handover.

[0034] An example of DAPS inter-node handover for LTE is shown in Figure 3 below. In Figure 3, steps 401-405 are similar to steps 1-5 of Figure 2 described above. Steps 409-412 are similar to steps 10-13 of Figure 2 described above.

[0035] In step 405, upon receiving an RRC reconfiguration with "DAPS HO" indication in the handover command (set per bearer), e.g. reconfigurationWithSync for the master cell group, MCG, the UE maintains a connection to the source cell associated with the source access node while establishing a connection to the target cell associated with the target access node (for the DAPS configured bearers). That is, the UE can send and receive DL / UL user plane data via the source access node during steps 405-408 without interruption for the respective bearers. Also, after step 408, the UE has a target link available for UL / DL user plane data transmission, similar to a normal HO procedure.

[0036] The DAPS configuration for a given bearer is provided as part of the RadioBearerConfig for each Data Radio Bearer (DRB) for which DAPS is to be configured, as shown below, and the RadioBearerConfig IE is included in the RRC reconfiguration with reconfigurationWithSync for the MCG. TIFF0007654815000001.tif135170

[0037] In case of DAPS handover, the UE continues downlink user data reception from the source gNB until it releases the source cell, i.e., a daps-SourceRelease message sent by the target, and continues uplink user data transmission to the source gNB until a successful random access procedure to the target gNB. To do that, the UE should continue performing Radio Link Monitoring (RLM) with respect to the source cell for the entire duration of the handover, i.e., until an RRC Reconfiguration Complete containing HO completion information is sent. That implies, for example, that the UE should continue monitoring for possible out-of-sync indications, whether RLC retransmissions with the source exceed a threshold, etc. Obviously, if an RLF occurs in the source cell while performing DAPS, the UE releases the source connection, but the UE can continue the DAPS HO to the target.

[0038] It should be noted that, as explained before, a UE with DAPS HO configured can continue UL transmission towards the source cell until the handover is completed at the target, i.e. until an RRC Reconfiguration Complete is sent to the target. In DL, instead, the source network node (e.g. source gNode B) can continue sending DL data until the source configuration release conveyed in the daps-SourceRelease message sent by the target (after receiving the RRC Reconfiguration Complete) is received by the UE. Thus, UL data transmission towards the source cell will not be extended beyond the handover completion, although some UL transmission towards the source cell, such as HARQ ACK / NACK and other possible Layer 1 control signaling, should be performed towards the source cell after the handover completion.

[0039] The RRC triggered handover mechanism, except for DAPS handover, requires the UE to at least reset the Medium Access Control (MAC) entity and re-establish the RLC, where, upon receipt of the handover command, the UE: Create a MAC entity for the target (i.e. a different / new MAC entity), For each DRB with DAPS configured, establish an RLC entity for the target and the associated DTCH logical channel; For a DRB with DAPS configured, reconfigure separate Security and Robust Header Compression (ROHC) functions for the source and target in the PDCP entity and associate them with the RLC entities configured by the source and target, respectively; · Preserve the remainder of the source configuration until the source is released.

[0040] In RRC, the UE actions are defined as follows:

[0041] Reconfiguring with synchronization The UE shall perform the following actions to perform reconfiguration with synchronization: ... 1> If no DAPS bearer is set up, 2> Stop timer T310 for the corresponding SpCell if it is running; ... 1> If a DAPS bearer is established, 2> Create a MAC entity for the target cell group with the same configuration as the MAC entity for the source cell group, 2> For each DAPS bearer, 3> Establishing an RLC entity(ies) for the target cell group with the same configuration as for the source cell group; 3> Establish a logical channel for the target cell group with the same configuration as for the source cell group; ... 2> Apply the value of newUE-Identity as C-RNTI in the target cell group; 2> Configure the lower layers for the target SpCell according to the received spCellConfigCommon; 2> Configure lower layers for the target SpCell according to any additional fields not covered before, if included in the received reconfigurationWithSync. ...

[0042] RLC Bearer Addition / Modification

[0043] For each RLC-BearerConfig received in the rlc-BearerToAddModList IE, the UE shall do the following: 1> If the UE's current configuration includes an RLC bearer with the received logicalChannelIdentity in the same cell group, 2> If the RLC bearer is related to a DAPS bearer, 3> reconfigure the RLC entity(ies) for the target cell group according to the received rlc-Config; 3> reconfigure the logical channel for the target cell group according to the received mac-LogicalChannelConfig; 2> In other cases, ...

[0044] MAC Entity Settings

[0045] The UE shall: 1> If the SCG MAC is not part of the current UE configuration (i.e., no SCG established), 2> Create an SCG MAC entity, 1> If a DAPS bearer is established, 2> reconfigure the MAC main configuration for the target cell group according to the received mac-CellGroupConfig excluding tag-ToReleaseList and tag-ToAddModList, ...

[0046] In step 406, the source access node sends an SN Status Transfer message to the target access node indicating the UL PDCP receiver status and the SN of the first forwarded DL PDCP SDU. The uplink PDCP SN receiver status includes at least the PDCP SN of the first lost UL SDU and may include a bitmap of the reception status of any out-of-order UL SDUs that the UE needs to retransmit in the target cell. The SN Status Transfer message also includes the Hyperframe Number (HFN) of the first lost UL SDU, as well as the HFN DL status of the count storage at the target access node.

[0047] Upon successful connection setup with the target access node, i.e. after sending a handover complete message in step 408, the UE maintains two data links (except in the UL where the UE uses only the target after successful random access), one to the source access node and one to the target access node. After step 408, the UE transmits UL user plane data on the target access node in the same way as in a normal HO procedure using the target access node security key and compression context. Thus, there is no need for simultaneous UL user data transmission to both nodes, which avoids UE power splitting between the two nodes and further simplifies the UE implementation. In case of intra-frequency handover, transmitting UL user plane data to one node at a time also reduces UL interference, which increases the likelihood of successful decoding on the network side.

[0048] The UE needs to maintain the security and compression context for both the source and target access nodes until the source link is released. The UE can differentiate the security / compression context to be used for a PDCP PDU based on the cell in which the PDU is transmitted.

[0049] To avoid packet duplication, the UE may send a PDCP status report indicating the last received PDCP SN together with the handover complete message in step 408. Based on the PDCP status report, the target access node can avoid sending duplicate PDCP packets (i.e. PDCP PDUs with the same sequence number) to the UE, i.e. PDCP packets that have already been received by the UE in the source cell.

[0050] The release of the source cell in step 413 may be triggered, for example, by an explicit message from the target access node (not shown in the figure) or by some other event, such as expiration of a release timer.

[0051] As an alternative to the source access node initiating packet data forwarding after step 405 (i.e. after sending a handover command to the UE, also known as "early packet forwarding"), the target access node may indicate to the source access node when to start packet data forwarding. For example, packet data forwarding may start at a later stage, when a link to the target cell is established, e.g. after the UE performs random access in the target cell, or when the UE sends an RRC connection reconfiguration complete message to the target access node (also known as "later packet forwarding"). By initiating packet data forwarding at a later stage at the source access node, the number of duplicated PDCP SDUs received by the UE from the target cell will potentially be smaller, thereby somewhat reducing DL latency. However, initiating packet data forwarding at a later stage is also a trade-off between robustness and reduced latency, e.g. if the connection between the UE and the source access node is lost before the connection to the target access node is established. In such a case, there will be a short interruption in DL data transfer to the UE.

[0052] Figure 4 shows the protocol stacks at the UE side in a Dual Active Protocol Stack (DAPS) handover. Each user plane radio bearer has an associated PDCP entity, which has two associated RLC entities, one for the source cell and one for the target cell. The PDCP entities use different security keys and ROHC contexts for the source and target cells, but the SN allocation (for UL transmission) and reordering / duplication detection (for DL ​​reception) are common.

[0053] Note that for NR, there is an additional protocol layer above PDCP called SDAP (Service Data Application Protocol) that is responsible for mapping QoS flows to bearers. This layer is not shown in Figure 4 and will not be described in detail herein.

[0054] DAPS handover failure

[0055] In NR, a timer-based handover failure procedure is supported (i.e., the UE starts timer T304 upon receiving an RRC reconfiguration with reconfiguration with synchronization, stops the timer on success, and declares a handover failure upon expiry). To recover from a handover failure, the RRC connection re-establishment procedure is used.

[0056] However, when DAPS HO fails, the UE has the possibility to fall back to the source cell configuration without triggering RRC connection re-establishment if the source link is not released, resumes the connection with the source cell and reports DAPS HO failure via the source. Such fallback to the source cell can only occur if the RLF for the source cell has not yet been declared at the time the T304 timer expires. When the UE falls back to the source cell, it issues failure information to the source cell to indicate that the UE has failed DAPS HO towards the target cell.

[0057] Otherwise, if an RLF with respect to the source cell has already occurred at the time when the DAPS handover to the target is failed, i.e. at the time when timer T304 expires, the UE selects a third cell different from the source and target for re-establishment.

[0058] Self-Organizing Networks (SON) in 3GPP

[0059] Self-Organizing Networks (SON) is an automation technology designed to make planning, configuration, management, optimization and repair of mobile radio access networks easier and faster. SON functions and behaviors are defined and specified in accepted mobile industry recommendations produced by organizations such as 3GPP (3rd Generation Partnership Project) and NGMN (Next Generation Mobile Networks).

[0060] In 3GPP, processes within the SON area are classified into self-configuration and self-optimization processes, where a newly deployed node is configured by an automatic installation procedure to obtain the necessary basic configuration for system operation.

[0061] This process works in a pre-operational state, which is understood as the state from when the eNB is powered up and has backbone connectivity until the RF transmitter is switched on.

[0062] As shown in Figure 5, the functions handled in the pre-operational state are as follows: Basic setup, and Initial wireless settings are covered by the self-configuration process. Some of the basic setup functions are shown in A-1 to A-4 in Figure 5. Some of the initial wireless settings are shown in B-1 to B-2 in Figure 5.

[0063] The self-optimization process is defined as a process in which UE and access node measurements and performance measurements are used to automatically adjust the network.

[0064] This process works in the operating state, which is understood as the state in which the RF interface is also switched on.

[0065] As shown in Figure 5, the functions handled in the operational state are as follows: Optimization / Adaptation are covered by the self-optimization process. Some of the optimization / adaptation functions are shown in C-1 and C-2 in Figure 5.

[0066] LTE specifies support for self-configuration and self-optimization as described in 3GPP TS 36.300 Section 22.2, including features such as dynamic configuration, Automatic Neighbor Relations (ANR), mobility load balancing, mobility robustness optimization (MRO), RACH optimization and support for energy savings.

[0067] In NR, support for self-configuration and self-optimization is specified as well, starting with self-configuration features such as dynamic configuration, automatic neighbor relations (ANR) in Rel-15 as described in 3GPP TS 38.300 Section 15. In NR Rel-16, more SON features are specified, including self-optimization features such as mobility robustness optimization (MRO).

[0068] Mobility Robustness Optimization (MRO) in 3GPP

[0069] Seamless handover is a key feature of 3GPP technology. A successful handover ensures that a UE can move around in the coverage areas of different cells without causing too many interruptions in data transmission. However, there will be scenarios where the network fails to handover the UE to the "correct" neighboring cell in time, and in such scenarios the UE will declare a Radio Link Failure (RLF) or Handover Failure (HOF).

[0070] During HOF and RLF, the UE may take autonomous actions, i.e., select a cell and initiate a re-establishment procedure, to ensure that the UE is trying to return as soon as possible and therefore may be reachable again. RLF will cause poor user experience, since it is declared by the UE only when it realizes that there is no reliable communication channel (radio link) available between itself and the network. Also, re-establishing a connection requires signaling (random access procedure, RRC re-establishment request, RRC re-establishment RRC re-establishment complete, RRC reconfiguration and RRC re-configuration complete) with the newly selected cell, adding some latency, until the UE can exchange data with the network again.

[0071] According to the specifications (3GPP TS36.331), possible causes for a radio link failure can be one of the following: 1) expiry of radio link supervision related timer T310, 2) expiry of the measurement report related timer T312 (no handover command is received from the network within the duration of this timer despite having sent a measurement report when T310 was running); 3) When the maximum number of RLC retransmissions is reached, 4) Upon receiving a random access problem indication from the MAC entity.

[0072] Since RLF leads to re-establishment which degrades performance and user experience, it is for the network to understand the reason for RLF and try to optimize mobility related parameters (e.g. trigger conditions for measurement reports) to avoid slower RLF. Before the standardization of MRO related report handling in the network, only the UE was aware of some information related to what the radio quality was at the time of RLF, what the actual reason for declaring RLF was, etc. In order for the network to identify the reason for RLF, the network needs more information from both the UE and also from neighboring base stations.

[0073] As part of the MRO solution in LTE, the RLF reporting procedure was introduced in the RRC specification in the Rel-9 RAN2 work. It influenced the RRC specification (TS36.331) in that it was specified that the UE will log the relevant information at the moment of RLF and later report it to the target cell to which the UE has successfully connected (e.g. after re-establishment). It also influenced the g-NodeB interface, i.e. the X2AP specification (3GPP TS36.423), since the eNodeB receiving the RLF report can forward it to the failed eNodeB.

[0074] For RLF reports generated by the UE, the content of the RLF report has been extended with more details in subsequent releases. The measurements included in the measurement report based on the latest LTE RRC specifications are: 1) Measurement quantities (RSRP, RSRQ) of the last serving cell (PCell). 2) Measurements of neighboring cells at different frequencies of different RATs (EUTRA, UTRA, GERAN, CDMA2000). 3) Measurement quantities related to the WLAN Ap (RSSI). 4) Measurements related to Bluetooth beacons (RSSI). 5) Location information (including location coordinates and speed), if available 6) If available, the globally unique identity of the last serving cell; otherwise, the PCI and carrier frequency of the last serving cell. 7) Tracking area code of the PCell. 8) The time elapsed since the last receipt of a "Handover Command" message. 9) The C-RNTI used in the previous serving cell. 10) Whether or not a DRB with a QCI value of 1 has been configured for the UE.

[0075] After the RLF is declared, the RLF report shall be logged and included in VarRLF-Report, and once the UE has selected a cell and successfully re-established, the RLF report shall include an indication that it has an RLF report available in the RRC Re-establishment Complete message to make the target cell aware of its availability. Then, upon receiving a UEInformationRequest message with flag "rlf-ReportReq-r9", the UE shall include the RLF report (stored in the UE variable VarRLF-Report, as described above) in a UEInformationResponse message and send it to the network.

[0076] Based on the RLF report from the UE and its knowledge of which cell the UE has re-established itself with, the original source cell can infer whether the RLF was caused by a coverage hole or by handover-related parameter settings. If the RLF is deemed to be due to handover-related parameter settings, the original serving cell can further classify the handover-related failure as a premature handover, a late handover, or a handover to a wrong cell class. These handover failure classes are briefly described below. 1) Whether the handover failure was caused by a "too late handover" case a. The original serving cell may classify the handover failure as "too late handover" when the original serving cell fails to send a handover command to the UE associated with the handover towards a particular target cell and if the UE has re-established itself in this target cell after an RLF. b. An exemplary correction action from the original serving cell could be to initiate the handover procedure towards the target cell a little earlier by decreasing the CIO (Cell Individual Offset) towards this target cell, which controls when the IE sends the event triggered measurement report that leads to making the handover decision. 2) Whether the handover failure was caused by a "premature handover" instance a. The original serving cell may classify a handover failure as "premature handover" when the original serving cell successfully sends a handover command to the UE involved in the handover, but the UE has a failure to perform random access towards the target cell. b. An exemplary corrective action from the original serving cell could be to initiate the handover procedure towards the target cell a little later by increasing the CIO (Cell Individual Offset) towards this target cell, which controls when the IE sends the event triggered measurement report that leads to making the handover decision. 3) Whether the handover failure occurred due to a "handover to wrong cell" case a. The original serving cell may classify the handover failure as "handover to wrong cell" when the original serving cell intends to perform a handover for this UE towards a particular target cell, but the UE declares RLF and re-establishes itself in a third cell. b. The corrective action from the original serving cell could be to initiate a measurement reporting procedure leading to a slightly later handover towards the target cell by decreasing the CIO (Cell Individual Offset) towards the target cell, or via the UE initiating a handover towards the re-established cell a little earlier by increasing the CIO towards the re-established cell. Summary of the Invention

[0077] Currently, there exists a problem(s): the current RLF framework does not consider the scenario of RLF after fallback. In particular, according to the current RLF framework, the UE will store RLF information related to handoff from a first cell to a second cell in the VarRLF-Report. Then, when RLF is experienced in the first cell after fallback, the UE will erase (e.g., delete) the previous RLF report in the VarRLF-Report and create a new RLF report, which includes, for example, information related to the previous handover, e.g., previous PCellID, time of RLF since the latest handover, etc. At this point, since the UE has already cleared the information related to the handover from the first cell to the second cell, the network will not have the possibility to determine whether 1) such an RLF occurred immediately after the handover from the cell to the first cell, e.g., before the handover from the first cell to the second cell, in which case the network may categorize such a handover as a "too early HO" from another cell to the first cell, or 2) whether such an RLF occurred after a failed handover from the first cell to the second cell, in which case the network may categorize the handover as a "too late HO" from cell B.

[0078] Such ambiguity would therefore prevent the network from deciding whether it should be the other cell's handover configuration that needs to be optimized (e.g., to avoid "too early" HO) or the first cell's handover configuration (e.g., to avoid "too late" HO).

[0079] Thus, a method is provided to include RLF information in case of an RLF occurrence after DAPS fallback.

[0080] According to some embodiments, a method is provided for reporting failure information in a self-organizing network (SON) implemented by a wireless device. The method includes receiving a handover command from a source cell while connected to the source cell to attempt a handover from the source cell to a target cell, where a dual active protocol stack (DAPS) is configured for one or more bearers associated with the handover from the source cell to the target cell. The method includes experiencing a failure while attempting the handover from the source cell to the target cell. The method includes storing first failure information associated with the failure while attempting the handover from the source cell to the target cell. The method includes performing a DAPS fallback to the source cell based at least in part on experiencing a failure while attempting the handover from the source cell to the target cell. The method includes experiencing a radio link failure (RLF) while connected to the source cell. The method includes transmitting the first failure information or the second failure information towards the SON.

[0081] Similar wireless devices, computer programs, and computer program products are provided.

[0082] Some embodiments may provide one or more of the following technical advantage(s): Various embodiments described in this disclosure enable a UE to reflect an "RLF after DAPS fallback" scenario in an RLF-Report and also enable a network to clearly distinguish, within the same RLF-report, which parameters / information are relevant for the "RLF after DAPS fallback" case for a handover between a first cell and a second cell and which parameters are relevant for a previous handover from another cell to the first cell.

[0083] According to another embodiment, a method is provided in a self-organizing network (SON) that is implemented by a base station. The method includes receiving first failure information or second failure information from a wireless device. The method includes determining whether the wireless device experiences a radio link failure (RLF) after performing a dual active protocol stack (DAPS) fallback. The method includes optimizing one or more handover parameters based at least in part on determining that the wireless device experiences an RLF after performing the DAPS fallback.

[0084] Similar base stations, computer programs and computer program products are provided.

[0085] The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this application, illustrate several non-limiting embodiments of the inventive concepts. [Brief description of the drawings]

[0086] [Figure 1] 1 is a diagram of a simplified wireless communication system. [Diagram 2] A signaling diagram showing the signaling flow between the UE and the source and target access nodes during a handover procedure. [Diagram 3] FIG. 1 is a signaling diagram showing DAPS handover. [Figure 4] FIG. 2 is a block diagram showing an example of a dual active protocol stack (DAPS) on the UE side. [Diagram 5] FIG. 2 is a block diagram illustrating the self-configuring / self-optimizing feature. [Figure 6] FIG. 1 is a block diagram illustrating an RLF scenario after DAPS fallback, according to some embodiments. [Figure 7] FIG. 13 is a block diagram illustrating an RLF scenario after DAPS fallback, according to some other embodiments. [Figure 8] 4 is a flowchart illustrating operation of a user equipment according to some embodiments. [Figure 9] 4 is a flowchart illustrating operation of a user equipment according to some embodiments. [Figure 10] 4 is a flowchart illustrating operation of a user equipment according to some embodiments. [Figure 11] 4 is a flowchart illustrating operation of a user equipment according to some embodiments. [Figure 12] 4 is a flowchart illustrating operation of a user equipment according to some embodiments. [Figure 13] 4 is a flowchart illustrating operation of a user equipment according to some embodiments. [Figure 14] 4 is a flowchart illustrating operation of a user equipment according to some embodiments. [Figure 15] 4 is a flowchart illustrating operation of a user equipment according to some embodiments. [Figure 16] 4 is a flowchart illustrating operation of a user equipment according to some embodiments. [Figure 17] 4 is a flowchart illustrating operation of a user equipment according to some embodiments. [Figure 18] 4 is a flowchart illustrating operation of a user equipment according to some embodiments. [Figure 19] 4 is a flowchart illustrating operation of a user equipment according to some embodiments. [Figure 20] 4 is a flowchart illustrating the operation of a network node according to some embodiments. [Figure 21] 4 is a flowchart illustrating the operation of a network node according to some embodiments. [Figure 22] 4 is a flowchart illustrating the operation of a network node according to some embodiments. [Figure 23] 1 is a block diagram of a wireless network according to some embodiments. [Figure 24]FIG. 2 is a block diagram of a user equipment according to some embodiments. [Diagram 25] FIG. 1 is a block diagram of a virtualization environment, according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0087] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Examples of embodiments of the inventive concept are shown, and the embodiments are provided as examples to convey the scope of the subject matter to those skilled in the art. However, the inventive concept may be embodied in many different forms and should not be construed as being limited to the embodiments described herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. It may be implicitly assumed that an element from one embodiment is present / used in another embodiment.

[0088] Generally, all terms used herein should be interpreted according to the ordinary meaning of those terms in the relevant technical field, unless a different meaning is expressly given and / or implied from the context in which the term is used. All references to a / an / the element, apparatus, component, means, step, etc. should be openly interpreted as referring to at least one instance of that element, apparatus, component, means, step, etc., unless expressly stated otherwise. The steps of any method disclosed herein need not be performed in the exact order disclosed, unless a step is expressly described as following or preceding another step, and / or it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Similarly, any advantage of any of the embodiments may be applied to any other embodiment, and vice versa. Other objectives, features, and advantages of the enclosed embodiments will become apparent from the following description.

[0089] As previously indicated, the RLF after fallback is not considered in the current RLF framework. The RLF after fallback is illustrated in FIG.

[0090] 6, a UE (e.g., UE 2400) receives a HO command from cell A 604 in block 601, and the UE successfully performs a handover to cell B 600 via a random access procedure in block 603. Then, source cell B 600 triggers a DAPS HO for the UE in block 605, which is received by the UE. The UE triggers a random access procedure toward target cell C 602 in block 607 while keeping the MAC configuration with source cell B 600 so that the UE can continue to communicate with source cell B 600. However, in this scenario, the UE does not complete the handover toward cell C 602 due to a handover failure in block 609, e.g., T304 timer expires, and as a result, the UE performs a DAPS fallback to source cell B 600 in block 611. The UE stores the HO failure information in the VarRLF-Report, block 613, and transmits the failure information with the HO failure information to source cell B 600, block 615. Then, while still in cell B 600, the UE experiences an RLF in cell B 600, block 617, and the UE stores the RLF information in the VarRLF-Report container, step 619, which may be transmitted to the network and used for SON purposes.

[0091] The problem is that according to the current RLF framework, the "RLF after fallback" scenario shown in Figure 6 is not considered. In particular, according to the current RLF framework, the UE will store RLF information related to the HOF from cell B 600 to cell C 602 in the VarRLF-Report. Then, when an RLF is experienced in cell B 600 after fallback, the UE will erase (e.g., delete) the previous RLF report in the VarRLF-Report and create a new RLF report, which includes, for example, information related to the previous handover, such as the previous PCellID, the time of RLF since the latest handover, etc. At this point, since the UE has already cleared the information related to the HO failure from cell B 600 to cell C 602, the network will not have the possibility to determine 1) whether such an RLF occurred immediately after the handover from cell A 604 to cell B 600, e.g. before the HOF from cell B 600 to cell C 602, in which case the network may categorize such a HO as a "too early HO" from cell A 604 to cell B 600, or 2) whether such an RLF occurred after a failed HO from cell B 600 to cell C 602, in which case the network may categorize the handover as a "too late HO" from cell B 600.

[0092] Such ambiguity would therefore prevent the network from deciding whether it should be the handover configuration of cell A that needs to be optimized (e.g., to avoid a "too early" HO) or the handover configuration of cell B (e.g., to avoid a "too late" HO).

[0093] For example, after an RLF in cell B 600, the UE would, according to the current legacy specification, include timeConnFailure, e.g., the time elapsed since the last HO initialization until the connection failure. In this case, the last HO initialization occurred when cell B 600 sent a HO command to cell C 602. However, the current RLF-Report does not allow the network to determine whether such time represents the time elapsed between the RLF and the triggered (and resulting in a HOF) HO from cell B 600 to cell C 602, or the time elapsed between the RLF and the triggered (successful) HO from cell A 604 to cell B 600.

[0094] Various embodiments proposed herein enable the UE to reflect the "RLF after DAPS fallback" scenario shown in FIG. 6 in the RLF-Report and also enable the network to clearly distinguish, within the same RLF-report, which parameters / information are relevant for the "RLF after DAPS fallback" case for handover between cell B and cell C and which parameters are relevant for the previous handover from cell A to cell B.

[0095] Terminology

[0096] The term "cell A" refers to a first cell hosted by a distributed unit (DU) from which a UE performs a handover to a second cell referred to as "cell B."

[0097] The term "Cell B" refers to a second cell hosted by the DU to which the UE performs a handover from the first cell, and from which the UE performs a handover to a third cell referred to as "Cell C."

[0098] The term "cell C" refers to a third cell hosted by a DU to which a UE performs a handover from a second cell, said handover execution resulting in a handover failure (HOF).

[0099] A UE in various embodiments described herein refers to a UE 2400 (implemented using the block diagram structure of FIG. 24 described below), which will be described with reference to the flowcharts of FIGS. 8-19, according to some embodiments of the inventive concepts. For example, modules may be stored in the memory 2415 of FIG. 24, which may provide instructions such that, when the instructions of the modules are executed by the respective communications device processing circuitry 2401, the processing circuitry 2401 performs the respective operations of the flowcharts.

[0100] Returning to FIG. 6, in some aspects, the scenario illustrated in FIG. 6 includes the following actions performed by UE 2400 in some embodiments. 1. In block 601, receiving a HO command from cell A 604 to cell B 600. 2. In block 603, successfully completing the HO in cell B 600. 3. In block 605, while connected to cell B 600, receiving an RRC reconfiguration message including reconfigurationWithSync and with one or more bearers with DAPS configured for handover towards cell C 602. 4. In block 607, perform a HO to cell C 602. 5. In block 609, experiencing a HO failure, e.g., T304 expiration, while performing a HO towards cell C 602. 6. In block 611, performing a fallback to cell B 600, eg, sending a failure information message to cell B 600 indicating a DAPS failure. 7. In block 613, storing the first RLF-Report associated with the HO failure experienced in step 5. 8. In block 716, experience an RLF in cell B 600. 9. Optionally, clear the information contained in the RLF-Report variable. 10. At block 619, storing a second RLF-Report associated with the RLF experienced in step 8 (ie, block 617).

[0101] The relationship between the first and second RLF reports and the information contained therein is shown in FIG.

[0102] 7, the first RLF information 701 includes information about an HO failure to cell C 602. The second RLF information 703 includes information about an RLF failure in a connection to cell B 600.

[0103] 8-12 show various embodiments performed by a wireless device (e.g., UE 2400) to report fault information in a self-organizing network (SON). Referring to FIG. 8, in block 801, UE 2400 receives a handover command from a source cell 600 to attempt a handover from the source cell 600 to a target cell 602 while connected to the source cell 600, and a dual active protocol stack (DAPS) is configured for one or more bearers related to the handover from the source cell 600 to the target cell 602. This is similar to the operation performed in block 605 in FIG. 6 and FIG. 7.

[0104] In block 803, the UE 2400 experiences a failure during an attempt to handover from the source cell 600 to the target cell 602. This is similar to the operation performed in block 609 in Figures 6 and 7. In block 805, the UE 2400 stores first failure information related to the failure during an attempt to handover from the source cell 600 to the target cell 602. This is similar to the operation performed in block 613 in Figures 6 and 7.

[0105] In block 807, the UE 2400 performs a DAPS fallback to the source cell 600 based at least in part on experiencing a failure while attempting a handover from the source cell 600 to the target cell 602. This is similar to the operations performed in block 611 of FIGS.

[0106] In block 809, the UE 2400 experiences a radio link failure (RLF) while connected to the source cell 600. This is similar to the operations performed in block 617 of Figures 6 and 7. In various embodiments, the UE 2400 experiences an RLF while connected to the source cell 600 after DAPS fallback.

[0107] At block 811, the UE 2400 stores second failure information related to experiencing RLF.

[0108] In block 813, the UE 2400 transmits the first failure information or the second failure information towards the self-organizing network.

[0109] 10 to 19 show various embodiments for storing fault information.

[0110] The first failure information or the second failure information may be stored in a radio link failure report, which is shown in FIG.

[0111] Referring to FIG. 10, in block 1001, the UE 2400 includes storing first failure information in a radio link failure (RLF) report, or storing second failure information, and storing source failure information in the RLF report.

[0112] Various embodiments below disclose information that the UE 2400 shall store in an RLF report, included in a Var-RLF report, to represent scenarios, such as those described above and related RL failures.

[0113] Exemplary embodiments

[0114] In the first exemplary embodiment, the second RLF-Report includes information related to the phase between the time the UE experienced an HO failure for the HO from cell B 600 to cell C 602 and the time the UE experienced an RLF in cell B 600 (possibly also including information related to the time the UE was connected in cell B 600 after the HO from cell A 604), e.g., information collected in the time between steps 5 and 9.

[0115] Such a second RLF-Report may include any of the following information: timeSinceFallback: fallback, e.g. the time elapsed between the time the UE 2400 sent a failure information message including a DAPS failure indication or the time the UE 2400 declared HOF and the RLF. This is shown in block 1101 of Figure 11, where storing the second failure information includes storing time-since-fallback information indicating the time elapsed between experiencing a failure while attempting a handover from the source cell 600 to the target cell 602 and experiencing an RLF while connected to the source cell 600. · timeConnFailure (legacy timer): The time elapsed between the reception of the last RRC reconfiguration message containing reconfigurationWithSync and said RLF, regardless of whether the corresponding handover execution was successful or not. 12 and 13 show various embodiments based on timeConnFailure. In block 1201 of FIG. 12, UE 2400 stores time-conn-failure information indicating the time elapsed between receiving a handover command and experiencing a radio link failure while connected to source cell 600. In block 1301 of FIG. 13, UE 2400 stores conn-time-failure information indicating the time elapsed between initiating handover from source cell 600 to target cell 602 and experiencing a radio link failure while connected to source cell 600. fallbackFlag: a flag indicating that an RLF occurred after a fallback. The flag can be used by the network to determine whether timeConnFailure represents the time between said RLF and an unsuccessful handover execution (e.g. handover from cell B 600 to cell C 602) for which the UE 2400 then performed a fallback, or the time between said RLF and a successful handover execution (e.g. handover from cell A 604 to cell B 600). Similarly, the network will in this way determine that the included radio measurements were collected after a fallback event. This is shown in block 1401 of FIG. 14, where the UE 2400 stores fallback flag information indicating experiencing RLF after performing DAPS fallback, and the fallback flag information may be used to determine whether the time-conn-failure information or conn-time-failure represents the time elapsed between experiencing a failure during an attempt to handover from the source cell 600 to the target cell 602 based at least in part on which the wireless device performed DAPS fallback, and experiencing the RLF. timeSinceLastSuccHO: the time elapsed between the receipt of the last RRC reconfiguration message containing reconfigurationWithSync that resulted in a successful handover execution and the time that RLF was experienced. In this case, this is the time elapsed between the RRC reconfiguration message containing reconfigurationWithSync received from cell A 604 and the time that RLF was experienced in cell B 600. Thus, in this case, the second RLF report also contains information from the HO from cell A 604 related to the time that UE 2400 was connected to cell B 600. Information providing the time elapsed between receiving the handover command and experiencing a failure while attempting a handover from the source cell 600 to the target cell 602. This is shown in Figure 15, block 1501, where the UE 2400 stores timing information indicating the time elapsed between receiving the handover command and experiencing a failure while attempting a handover from the source cell 600 to the target cell 602. Information providing the time elapsed between receiving the handover command and performing the DAPS fallback. This is shown in Figure 16, block 1601, where the UE 2400 stores fallback timing information indicating the time elapsed between receiving the handover command and performing the DAPS fallback. The most recent available radio measurements of the serving, target and neighbouring cells after the fallback to cell B 600 and before the RLF in cell B 600. This is illustrated by block 1701 in Figure 17, where the UE 2400 stores radio measurement information indicating available radio measurements related to the serving, target or neighbouring cells during the duration between performing the DAPS fallback and experiencing the RLF while connected to the source cell. · Information providing the time elapsed between receipt of the HO command that caused the disconnection from the source (time of receipt of the HO command in cell A) and the time of receipt of the DAPS HO command (time of receipt of the DAPS HO command in cell B). · Information relating to the relevant cell identities (cell A and cell B) from which said HO command was received. If the UE 2400 clears the previous RLF report, the UE 2400 logs that the UE 2400 has cleared the content of the previous RLF report for the RLF report variable. This is shown in Figure 9, where the UE 2400 deletes first failure information in block 901 based at least in part on experiencing RLF while connected to the source cell 600. In block 903, the UE 2400 logs that the first failure information has been deleted.

[0116] In a second exemplary embodiment, the UE 2400 logs the time between two successive failures, e.g., the time elapsed between a first failure and a second failure, the second failure being the failure that triggered clearing / deleting the contents of the first RLF report from the VarRLF-Report.

[0117] This indication (i.e., the time between two successive failures) may be used by the network to fetch the content of the RLF report as soon as possible; otherwise, successive failures may corrupt the previous failure information, preventing the network from optimizing the DAPS HO settings to avoid such failures in the future.

[0118] In this second exemplary embodiment, the first RLF-Report includes information related to the HO failure, e.g., related to the phases during which the UE 2400 was connected to cell B 600, including the phases between the time the UE 2400 received the HO command for HO to cell C 602 and the time the HO failure was experienced or until a fallback was implemented. For example, such a first RLF report may include the following information: timeSinceLastSuccHOandNextUnsuccHO: the time elapsed between the receipt of the last RRC reconfiguration message containing reconfigurationWithSync resulting in a successful handover execution and the receipt of the last RRC reconfiguration message containing reconfigurationWithSync until the HOF or resulting in an unsuccessful handover execution. The last available radio measurements of the serving cell, the target cell and the neighbouring cells before the HO is performed, timeSinceLastUnsuccHO: the time elapsed between receipt of the last RRC reconfiguration message containing reconfigurationWithSync resulting in an unsuccessful handover execution and until a HOF was experienced, i.e. the time elapsed between receipt of a HO command for HO from cell B 600 to cell C 602 and the HOF in cell B 600. This is shown in block 1801 of Figure 18, where the UE 2400 stores time-since-last-unsuccessful-HO timing information indicating the time elapsed between receiving the handover command and experiencing a failure while attempting a handover from the source cell to the target cell. Information providing the time elapsed between initiating the handover and experiencing a failure while attempting the handover from the source cell 600 to the target cell 602. This is shown in block 1901 of Figure 19, where the UE 2400 stores time-to-last-unsuccessful-HO timing information indicating the time elapsed between initiating the handover and experiencing a failure while attempting the handover from the source cell 600 to the target cell 602. Information providing the time elapsed from receipt of the HO command that caused the disconnection from the source (time of receiving the HO command in cell A 604) to the time of receiving the DAPS HO command (time of receiving the DAPS HO command in cell B 600). · Information relating to the relevant cell identities (cell A 604 and cell B 600) from which the HO command was received.

[0119] In one method, the UE logs the first RLF information 701 in a first entry in the VarRLF-Report when it experiences an HO failure for an HO from cell B 600 to cell C 602 or upon fallback. Upon experiencing an RLF in cell B 600, the UE deletes the stored entry in the VarRLF-Report, e.g., the first RLF information, and logs the second RLF information 703 associated with the second RLF. This is shown in FIG. 9, as described above.

[0120] In a second method, upon experiencing an RLF in cell B 600, UE 2400 does not delete the stored entry representing the first RLF information 701. Rather, UE 2400 includes a second entry representing the second RLF in the VarRLF-Report. This second method may be implemented if UE 2400 experiences an RLF in the same cell to which the UE performed fallback, e.g., the cell that sent the HO command resulting in an unsuccessful HO. Otherwise, the first entry may be deleted if UE 2400 gets a third RLF in a cell different from cell B 600, or a second HO failure.

[0121] In a third method, when the UE 2400 experiences an HO failure for HO from cell B 600 to cell C 602 or a failure during fallback from cell C 602 to cell B 600, the UE 2400 stores the first RLF information 701 related to the first RLF report in a first entry in the VarRLF-Report. When the UE 2400 experiences an RLF in cell B 600, the UE 2400 appends information representing the second RLF information 703 to such first entry. This third method may be implemented when the UE 2400 experiences an RLF in the same cell to which the UE 2400 performed fallback, e.g., the cell that sent the HO command resulting in an unsuccessful HO.

[0122] In a fourth method similar to the first method, the UE 2400 logs the first RLF information 701 in the first entry in the VarRLF-Report when it experiences a HO failure for a HO from cell B 600 to cell C 602 or during fallback. When it experiences an RLF in cell B 600, the UE 2400 deletes the stored entry in the VarRLF-Report, e.g., the first RLF information 701, and logs information related to the second RLF, e.g., the second RLF information 703. Furthermore, in the second RLF report, the UE 2400 also includes information related to a previous successfully completed handover, e.g., information related to a handover from cell A to cell B. The UE includes the source cell (cell A) of such handover and the time elapsed from such handover to the time of declaring failure (the time between the HO command reception from cell A and the time of RLF in cell B 600). Upon deleting / clearing a previous stored entry in VarRLF-Report, the UE 2400 logs that it has cleared the contents of the previous RLF report for the RLF report variable. o This indication to clear can be used by the network to fetch the contents of the RLF report as soon as possible, otherwise successive failures may corrupt previous failure information, preventing the network from optimizing the DAPS HO settings to avoid such failures in the future.

[0123] Exemplary Network Implementation

[0124] 20-22 show various embodiments of operations that may be performed by base stations 2360, 2520, 2612A, 2612B, 2612C, 2720 in a SON. In the following description, base station 2360 shall be used to describe those operations.

[0125] Referring to FIG. 20, in block 2001, a base station 2360 receives first failure information or second failure information from a wireless device.

[0126] Upon receiving the information included in the above embodiments (the first failure information and / or the second failure information), the network (e.g., a base station) can optimize HO settings and related parameters for HO from cell A to cell B600, for HO from cell B600 to cell C602, and for HO from cell B600 to a fourth cell, e.g., cell D.

[0127] For example, if from the above information the network determines that an RLF occurred after the fallback, the network may categorize such failure as a "too late HO" for cell B600 that did not trigger an early enough HO to another cell. Thus, the base station 2360 determines whether the wireless device experienced a radio link failure (RLF) after performing a dual active protocol stack (DAPS) fallback in block 2003. In block 2005, the base station 2360 optimizes one or more handover parameters based at least in part on determining that the wireless device experienced an RLF after performing a DAPS fallback.

[0128] In another example, if, from the above information, the network determines that an RLF occurred before the fallback and within a time window from the last successful HO from cell A to cell B 600, the UE 2400 may categorize such failure as a "premature HO" for the HO from cell A to cell B 600. Thus, referring to FIG. 21, in block 2101, the base station 2360 determines whether the wireless device experienced an RLF before performing a DAPS fallback and within a predetermined time window from completing a handover from the first cell to the source cell. In block 2103, the base station 2360 performs optimizing handover configuration, including optimizing one or more handover parameters, based at least in part on determining that the wireless device experienced an RLF before performing a DAPS fallback and within a predetermined time window from completing a handover from the first cell to the source cell.

[0129] In yet another example, a network node (e.g., a base station or a management node) may receive the first failure information and / or the second failure information and may determine, based at least in part on the received information, an identification information of a base station associated with experiencing a failure during a handover attempt or associated with experiencing a radio link failure. In some aspects, the network node may determine, based at least in part on cell information included in the received information, an identification information of the base station. The network node may forward the received information to the determined base station. In this manner, the network node may enable the base station to determine failure information, such as, for example, (i) that an RLF occurred before a fallback and within a time window from a last successful HO from cell A to cell B 600, or (ii) that an RLF occurred after a fallback, and optimize a handover configuration, including optimizing one or more handover parameters, based at least in part on determining the failure information. This is shown in FIG. 22. 22, in block 2201, the base station 2360 determines an identity of another base station associated with experiencing a failure during a handover attempt based at least in part on the first failure information, or determines an identity of another base station associated with experiencing an RLF based at least in part on the second failure information. In block 2203, the base station 2360 forwards the first failure information or the second failure information to the other base station to enable the other base station to optimize handover settings, including optimizing one or more handover parameters.

[0130] Although the subject matter described herein may be implemented in any suitable type of system using any suitable components, the embodiments disclosed herein are described with respect to a wireless network, such as the exemplary wireless network shown in FIG. 23. For simplicity, the wireless network of FIG. 23 illustrates a network 2306, network nodes 2360 and 2360B, and wireless devices (e.g., UEs) 2310, 2310B, and 2310C. In practice, the wireless network may further include any additional elements suitable for supporting communication between wireless devices, or between a wireless device and another communication device, such as a landline, a service provider, or any other network node or end device. Of the components shown, the network node 2360 and wireless device (WD) 2310 are illustrated with additional details. The wireless network may provide communication and other types of services to one or more wireless devices to facilitate the wireless device's access to the wireless network and / or use of services provided by or via the wireless network.

[0131] The wireless network may include and / or interface with any type of communication, telecommunication, data, cellular, and / or radio network, or other similar type of system. In some embodiments, the wireless network may be configured to operate according to a particular standard or other type of predefined rules or procedures. Thus, particular embodiments of the wireless network may implement a communications standard, such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, or 5G standards, a wireless local area network (WLAN) standard, such as the IEEE 802.11 standard, and / or any other suitable wireless communication standard, such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, and / or ZigBee standards.

[0132] The network 2306 may comprise one or more backhaul networks, core networks, IP networks, public switched telephone networks (PSTN), packet data networks, optical networks, wide area networks (WANs), local area networks (LANs), wireless local area networks (WLANs), wired networks, wireless networks, metropolitan area networks, and other networks to enable communication between devices.

[0133] The network node 2360 and WD 2310 comprise various components that are described in more detail below. These components cooperate to provide network node and / or wireless device functionality, such as providing wireless connectivity in a wireless network. In different embodiments, a wireless network may comprise any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, 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.

[0134] A network node, as used herein, refers to a device capable of, set up, configured, and / or operable to communicate directly or indirectly with wireless devices and / or with other network nodes or devices in a wireless network to enable and / or provide wireless access to the wireless devices and / or perform other functions (e.g., administration) in the wireless network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., wireless access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR Node Bs (gNBs)). Base stations may be categorized based on the amount of coverage they provide (or, in other words, their transmit power levels), and may then be referred to as femto, pico, micro, or macro base stations. A base station may be a relay node or a relay donor node that controls a relay. A network node may also include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit and / or a remote radio unit (RRU), sometimes referred to as a remote radio head (RRH). Such a remote radio unit may or may not be integrated with an antenna as an antenna-integrated radio. A part of a distributed radio base station may also be referred to as a node in a distributed antenna system (DAS). Still further examples of a network node include MSR equipment such as a multi-standard radio (MSR) BS, a network controller such as a radio network controller (RNC) or a base station controller (BSC), a base transceiver station (BTS), a transmission point, a transmitting node, a multi-cell / multicast coordination entity (MCE), a core network node (e.g., MSC, MME), an O&M node, an OSS node, a SON node, a positioning node (e.g., E-SMLC), and / or an MDT. As another example, a network node may be a virtual network node, as described in more detail below.More generally, however, a network node may represent any suitable device (or group of devices) capable of, configured to, and / or operable to enable and / or provide wireless devices with access to a wireless network or to provide some service to wireless devices that have accessed the wireless network.

[0135] In FIG. 23, network node 2360 includes processing circuitry 2370, device readable medium 2380, interface 2390, auxiliary equipment 2384, power source 2386, power circuitry 2387, and antenna 2362. Although network node 2360 shown in the example wireless network of FIG. 23 may represent a device including the shown combination of hardware components, other embodiments may comprise network nodes with different combinations of components. It should be understood that a network node comprises any suitable combination of hardware and / or software required to perform the tasks, features, functions and methods disclosed herein. Moreover, while the components of network node 2360 are illustrated as a single box located within a larger box or nested within multiple boxes, in reality the network node may comprise multiple different physical components that make up a single shown component (e.g., device readable medium 2380 may comprise multiple separate hard drives as well as multiple RAM modules).

[0136] Similarly, the network node 2360 may be assembled from multiple physically separate components (e.g., a Node B component and an RNC component, or a BTS component and a BSC component, etc.), each of which may have their own respective components. In some scenarios in which the network node 2360 comprises multiple separate components (e.g., a BTS component and a BSC component), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control several Node Bs. In such scenarios, each unique Node B and RNC pair may be considered as a single separate network node in some instances. In some embodiments, the network node 2360 may be configured to support several radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate device-readable media 2380 for different RATs) and some components may be reused (e.g., the same antenna 2362 may be shared by the RATs). Network node 2360 may also include multiple sets of the various shown components for different wireless technologies, such as, for example, GSM, WCDMA, LTE, NR, WiFi, or Bluetooth wireless technologies, integrated into network node 2360. These wireless technologies may be integrated in the same or different chips or sets of chips and other components within network node 2360.

[0137] The processing circuitry 2370 is configured to perform any decision, computation, or similar operations (e.g., some acquisition operations) described herein as being provided by a network node. These operations performed by the processing circuitry 2370 may include processing information acquired by the processing circuitry 2370, for example, by transforming the acquired information into other information, comparing the acquired or transformed information to information stored in the network node, and / or performing one or more operations based on the acquired or transformed information and as a result of said processing making a decision.

[0138] The processing circuitry 2370 may comprise one or more combinations 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 coded logic operable to provide network node 2360 functionality, either alone or in conjunction with other network node 2360 components, such as device readable medium 2380. For example, the processing circuitry 2370 may execute instructions stored on the device readable medium 2380 or in memory within the processing circuitry 2370. Such functionality may include providing any of the various wireless features, functions, or benefits described herein. In some embodiments, the processing circuitry 2370 may include a system on a chip (SOC).

[0139] In some embodiments, the processing circuitry 2370 may include one or more of a radio frequency (RF) transceiver circuitry 2372 and a baseband processing circuitry 2374. In some embodiments, the radio frequency (RF) transceiver circuitry 2372 and the baseband processing circuitry 2374 may be on separate chips (or sets of chips), boards, or units, such as a radio unit and a digital unit. In alternative embodiments, some or all of the RF transceiver circuitry 2372 and the baseband processing circuitry 2374 may be on the same chip or set of chips, board, or unit.

[0140] In some embodiments, some or all of the functionality described herein as being provided by a network node, base station, eNB, or other such network device may be performed by the processing circuitry 2370 executing instructions stored in the device-readable medium 2380, or in a memory within the processing circuitry 2370. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry 2370 without executing instructions stored in a separate or distinct device-readable medium, such as in a hardwired manner. In any of those embodiments, the processing circuitry 2370 may be configured to perform the described functionality, whether or not it executes instructions stored in a device-readable storage medium. Benefits provided by such functionality are enjoyed by the processing circuitry 2370 alone, or by other components of the network node 2360, but by the network node 2360 as a whole, and / or by end users and wireless networks generally.

[0141] The device readable medium 2380 may comprise any form of volatile or non-volatile computer readable memory, including, but not limited to, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drive, compact disk (CD) or digital video disk (DVD)), and / or any other volatile or non-volatile, non-transitory device readable and / or computer executable memory device that stores information, data, and / or instructions that may be used by the processing circuit 2370. The device readable medium 2380 may store any suitable instructions, data or information, including applications including one or more of computer programs, software, logic, rules, codes, tables, etc., and / or other instructions that may be executed by the processing circuit 2370 and utilized by the network node 2360. The device readable medium 2380 may be used to store calculations performed by the processing circuit 2370 and / or data received via the interface 2390. In some embodiments, the processing circuit 2370 and the device readable medium 2380 may be considered to be integrated.

[0142] The interface 2390 is used in wired or wireless communication of signaling and / or data between the network node 2360, the network 2306, and / or the WD 2310. As shown, the interface 2390 comprises a port(s) / terminal(s) 2394 for sending and receiving data to and from the network 2306, for example over a wired connection. The interface 2390 also includes a radio front-end circuit 2392, which is coupled to the antenna 2362 or, in some embodiments, may be part of the antenna 2362. The radio front-end circuit 2392 comprises a filter 2398 and an amplifier 2396. The radio front-end circuit 2392 may be connected to the antenna 2362 and the processing circuit 2370. The radio front-end circuit may be configured to condition signals communicated between the antenna 2362 and the processing circuit 2370. The radio front-end circuit 2392 may receive digital data to be sent to other network nodes or WDs via a wireless connection. The radio front-end circuitry 2392 may convert the digital data into a radio signal having appropriate channel and bandwidth parameters using a combination of filters 2398 and / or amplifiers 2396. The radio signal may then be transmitted via the antenna 2362. Similarly, when receiving data, the antenna 2362 may collect the radio signal, which is then converted into digital data by the radio front-end circuitry 2392. The digital data may be passed to the processing circuitry 2370. In other embodiments, the interface may comprise different components and / or different combinations of components.

[0143] In some alternative embodiments, the network node 2360 may not include a separate radio front-end circuit 2392, and instead the processing circuit 2370 may comprise a radio front-end circuit and be connected to the antenna 2362 without a separate radio front-end circuit 2392. Similarly, in some embodiments, all or a portion of the RF transceiver circuit 2372 may be considered part of the interface 2390. In still other embodiments, the interface 2390 may include one or more ports or terminals 2394, the radio front-end circuit 2392, and the RF transceiver circuit 2372 as part of a radio unit (not shown), and the interface 2390 may communicate with a baseband processing circuit 2374 that is part of a digital unit (not shown).

[0144] The antenna 2362 may include one or more antennas or antenna arrays configured to send and / or receive wireless signals. The antenna 2362 may be coupled to the radio front-end circuitry 2392 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, the antenna 2362 may comprise one or more omni-directional, sector or panel antennas operable to transmit / receive wireless signals, for example, between 2 GHz and 66 GHz. An omni-directional antenna may be used to transmit / receive wireless signals in any direction, a sector antenna may be used to transmit / receive wireless signals from devices in a particular area, and a panel antenna may be a line-of-sight antenna used to transmit / receive wireless signals in a relatively straight line. In some instances, the use of more than one antenna may be referred to as MIMO. In some embodiments, the antenna 2362 may be separate from the network node 2360 and may be connectable to the network node 2360 through an interface or port.

[0145] The antenna 2362, the interface 2390, and / or the processing circuit 2370 may be configured to perform any receiving operation and / or some obtaining operation described herein as being performed by a network node. Any information, data, and / or signal may be received from a wireless device, another network node, and / or any other network equipment. Similarly, the antenna 2362, the interface 2390, and / or the processing circuit 2370 may be configured to perform any transmitting operation described herein as being performed by a network node. Any information, data, and / or signal may be transmitted to a wireless device, another network node, and / or any other network equipment.

[0146] The power circuitry 2387 may comprise or be coupled to a power management circuitry and is configured to supply power to the components of the network node 2360 for performing the functions described herein. The power circuitry 2387 may receive power from a power source 2386. The power source 2386 and / or the power circuitry 2387 may be configured to provide power to the various components of the network node 2360 in a form suitable for the respective components (e.g., at the voltage and current levels required for each respective component). The power source 2386 may either be included in the power circuitry 2387 and / or the network node 2360 or may be external to the power circuitry 2387 and / or the network node 2360. For example, the network node 2360 may be connectable to an external power source (e.g., an electrical outlet) via an input circuit or interface, such as an electrical cable, whereby the external power source supplies power to the power circuitry 2387. As a further example, power supply 2386 may include a power source in the form of a battery or battery pack connected to or integrated in power circuit 2387. The battery may provide backup power in the event that an external power source fails. Other types of power sources, such as photovoltaic devices, may also be used.

[0147] Alternative embodiments of network node 2360 may include additional components other than those shown in FIG. 23 that may be responsible for providing some aspects of the network node's functionality, including any of the functionality described herein and / or functionality necessary to support the subject matter described herein. For example, network node 2360 may include user interface devices to enable input of information into network node 2360 and output of information from network node 2360. This may enable a user to perform diagnostics, maintenance, repair, and other administrative functions for network node 2360.

[0148] A wireless device (WD) as used herein refers to a device capable of, configured to, and / or operable to communicate wirelessly with network nodes and / or other wireless devices. Unless otherwise noted, the term WD may be used interchangeably herein with user equipment (UE). Communicating wirelessly may involve transmitting and / or receiving wireless signals using electromagnetic, radio, infrared, and / or other types of signals suitable for conveying information over the air. In some embodiments, a WD may be configured to transmit and / or receive information without direct human interaction. For example, a WD may be designed to transmit information to a network on a predefined schedule, when triggered by an internal or external event, or in response to a request from the network. Examples of WDs include, but are not limited to, smartphones, mobile phones, cell phones, voice-over-IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, gaming consoles or devices, music storage devices, playback appliances, wearable terminal devices, wireless endpoints, mobile stations, tablets, laptop computers, laptop embedded equipment (LEE), laptop mounted equipment (LME), smart devices, wireless customer premises equipment (CPE), in-vehicle wireless terminal devices, etc. A WD may support device-to-device (D2D) communications, for example, by implementing 3GPP standards for sidelink communications, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-everything (V2X), in which case it may be referred to as a D2D communications device. As yet another specific example, in an Internet of Things (IoT) scenario, a WD may represent a machine or other device that performs monitoring and / or measurements and transmits results of such monitoring and / or measurements to another WD and / or network node. The WD may in this case be a machine-to-machine (M2M) device, which may be referred to as an MTC device in the 3GPP context.As one particular example, the WD may be a UE implementing the 3GPP Narrowband Internet of Things (NB-IoT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or household or personal appliances (e.g., refrigerators, televisions, etc.), personal wearables (e.g., watches, fitness trackers, etc.). In other scenarios, the WD may represent a vehicle or other equipment capable of monitoring and / or reporting on its operational status or other functions related to its operation. The WD described above may represent an endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. Additionally, the WD described above may be mobile, in which case the device may be referred to as a mobile device or mobile terminal.

[0149] As shown, wireless device 2310 includes antenna 2311, interface 2314, processing circuitry 2320, device readable medium 2330, user interface equipment 2332, auxiliary equipment 2334, power source 2336, and power circuitry 2337. WD 2310 may include multiple sets of one or more of the shown components for different wireless technologies supported by WD 2310, such as, for example, GSM, WCDMA, LTE, NR, WiFi, WiMAX, or Bluetooth wireless technologies, just to name a few. These wireless technologies may be integrated on the same or different chip or set of chips as other components in WD 2310.

[0150] The antenna 2311 may include one or more antennas or antenna arrays configured to send and / or receive wireless signals and is connected to the interface 2314. In some alternative embodiments, the antenna 2311 may be separate from the WD 2310 and connectable to the WD 2310 through an interface or port. The antenna 2311, the interface 2314, and / or the processing circuit 2320 may be configured to perform any receiving or transmitting operation described herein as being performed by a WD. Any information, data, and / or signal may be received from a network node and / or another WD. In some embodiments, the wireless front-end circuit and / or the antenna 2311 may be considered an interface.

[0151] As shown, the interface 2314 comprises a radio front-end circuit 2312 and an antenna 2311. The radio front-end circuit 2312 comprises one or more filters 2318 and an amplifier 2316. The radio front-end circuit 2312 is connected to the antenna 2311 and the processing circuit 2320 and is configured to condition signals communicated between the antenna 2311 and the processing circuit 2320. The radio front-end circuit 2312 may be coupled to the antenna 2311 or may be part of the antenna 2311. In some embodiments, the WD 2310 may not include a separate radio front-end circuit 2312, rather the processing circuit 2320 may comprise a radio front-end circuit and be connected to the antenna 2311. Similarly, in some embodiments, some or all of the RF transceiver circuit 2322 may be considered part of the interface 2314. The radio front-end circuit 2312 may receive digital data to be sent to other network nodes or WDs via a wireless connection. The radio front-end circuitry 2312 may convert the digital data into a radio signal having appropriate channel and bandwidth parameters using a combination of filters 2318 and / or amplifiers 2316. The radio signal may then be transmitted via the antenna 2311. Similarly, when receiving data, the antenna 2311 may collect the radio signal, which is then converted into digital data by the radio front-end circuitry 2312. The digital data may be passed to the processing circuitry 2320. In other embodiments, the interface may comprise different components and / or different combinations of components.

[0152] The processing circuitry 2320 may comprise one or more combinations 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, resources, or combinations of hardware, software, and / or coded logic operable to provide WD2310 functionality, either alone or in conjunction with other WD2310 components, such as the device readable medium 2330. Such functionality may include providing any of the various wireless features or benefits described herein. For example, the processing circuitry 2320 may execute instructions stored on the device readable medium 2330 or in a memory within the processing circuitry 2320 to provide the functionality disclosed herein.

[0153] As shown, the processing circuit 2320 includes one or more of the RF transceiver circuit 2322, the baseband processing circuit 2324, and the application processing circuit 2326. In other embodiments, the processing circuit may comprise different components and / or different combinations of components. In some embodiments, the processing circuit 2320 of the WD 2310 may comprise a SOC. In some embodiments, the RF transceiver circuit 2322, the baseband processing circuit 2324, and the application processing circuit 2326 may be on separate chips or sets of chips. In alternative embodiments, some or all of the baseband processing circuit 2324 and the application processing circuit 2326 may be combined into one chip or set of chips, and the RF transceiver circuit 2322 may be on a separate chip or set of chips. In yet alternative embodiments, some or all of the RF transceiver circuit 2322 and the baseband processing circuit 2324 may be on the same chip or set of chips, and the application processing circuit 2326 may be on a separate chip or set of chips. In yet other alternative embodiments, some or all of the RF transceiver circuitry 2322, the baseband processing circuitry 2324, and the application processing circuitry 2326 may be combined in the same chip or set of chips. In some embodiments, the RF transceiver circuitry 2322 may be part of the interface 2314. The RF transceiver circuitry 2322 may condition RF signals for the processing circuitry 2320.

[0154] In some embodiments, some or all of the functionality described herein as being performed by the WD may be provided by the processing circuitry 2320 executing instructions stored on a device-readable medium 2330, which in some embodiments may be a computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry 2320 without executing instructions stored on a separate or distinct device-readable storage medium, such as in a hardwired manner. In any of those particular embodiments, the processing circuitry 2320 may be configured to perform the described functionality, regardless of whether it executes instructions stored on a device-readable storage medium. Benefits provided by such functionality are enjoyed by the WD 2310 as a whole, and / or by end users and wireless networks in general, but not limited to the processing circuitry 2320 alone or other components of the WD 2310.

[0155] The processing circuitry 2320 may be configured to perform any of the decision, calculation, or similar operations (e.g., some of the acquisition operations) described herein as being performed by the WD. These operations as performed by the processing circuitry 2320 may include processing information acquired by the processing circuitry 2320, for example, by converting the acquired information to other information, comparing the acquired or converted information to information stored by the WD 2310, and / or performing one or more operations based on the acquired or converted information and as a result of the processing making a decision.

[0156] The device-readable medium 2330 may be operable to store applications including one or more of computer programs, software, logic, rules, codes, tables, etc., and / or other instructions that may be executed by the processing circuit 2320. The device-readable medium 2330 may include computer memory (e.g., random access memory (RAM) or read-only memory (ROM)), mass storage media (e.g., hard disk), removable storage media (e.g., compact disc (CD) or digital video disc (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions that may be used by the processing circuit 2320. In some embodiments, the processing circuit 2320 and the device-readable medium 2330 may be considered to be integrated.

[0157] The user interface device 2332 may provide components that allow a human user to interact with the WD 2310. Such interaction may be of many forms, such as visual, auditory, tactile, etc. The user interface device 2332 may be operable to produce output to the user and to allow the user to provide input to the WD 2310. The type of interaction may vary depending on the type of user interface device 2332 installed on the WD 2310. For example, if the WD 2310 is a smartphone, the interaction may be via a touch screen, and if the WD 2310 is a smart meter, the interaction may be through a screen that provides usage (e.g., number of gallons used) or a speaker that provides an audible alarm (e.g., if smoke is detected). The user interface device 2332 may include input interfaces, devices and circuits, as well as output interfaces, devices and circuits. The user interface device 2332 is configured to allow input of information to the WD 2310 and is connected to the processing circuit 2320 to allow the processing circuit 2320 to process the input information. The user interface device 2332 may include, for example, a microphone, proximity or other sensors, keys / buttons, a touch display, one or more cameras, a USB port, or other input circuitry. The user interface device 2332 is also configured to enable output of information from the WD 2310 and to enable the processing circuitry 2320 to output information from the WD 2310. The user interface device 2332 may include, for example, a speaker, a display, vibration circuitry, a USB port, a headphone interface, or other output circuitry. Using one or more input and output interfaces, devices, and circuits of the user interface device 2332, the WD 2310 may communicate with an end user and / or a wireless network and enable the end user and / or the wireless network to benefit from the functionality described herein.

[0158] The auxiliary device 2334 is operable to provide more specific functionality that may not generally be implemented by a WD. It may include specialized sensors for taking measurements for various purposes, interfaces for additional types of communication such as wired communication, etc. The inclusion of components of the auxiliary device 2334 and the types of components of the auxiliary device 2334 may vary depending on the embodiment and / or scenario.

[0159] The power source 2336 may be in the form of a battery or battery pack in some embodiments. Other types of power sources may also be used, such as an external power source (e.g., an electrical outlet), a photovoltaic device, or a battery. The WD 2310 may further comprise a power circuit 2337 for delivering power from the power source 2336 to various parts of the WD 2310 that require power from the power source 2336 to perform any of the functions described or indicated herein. The power circuit 2337 may comprise a power management circuit in some embodiments. The power circuit 2337 may additionally or alternatively be operable to receive power from an external power source, in which case the WD 2310 may be connectable to an external power source (such as an electrical outlet) via an input circuit or interface, such as a power cable. The power circuit 2337 may also be operable in some embodiments to deliver power from the external power source to the power source 2336. This may be for charging the power source 2336, for example. The power circuitry 2337 may perform any formatting, conversion, or other modification on the power from the power source 2336 to make the power suitable for the respective components of the WD 2310 that are being powered.

[0160] FIG. 24 illustrates an embodiment of a UE according to various aspects described herein. User equipment or UE as used herein does not necessarily have a user in the sense of a human user who owns and / or operates an associated device. Instead, a UE may represent a device (e.g., a smart sprinkler controller) that is intended for sale to or operation by a human user, but may not be associated with or may not be initially associated with a particular human user. Alternatively, a UE may represent a device (e.g., a smart power meter) that is not intended for sale to or operation by an end user, but may be associated with or operated for the benefit of a user. The UE 24200 may be any UE identified by the 3rd Generation Partnership Project (3GPP), including an NB-IoT UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE. The UE 2400 shown in FIG. 24 is an example of a WD configured for communication according to one or more communications standards promulgated by the 3rd Generation Partnership Project (3GPP), such as the 3GPP GSM, UMTS, LTE, and / or 5G standards. As mentioned above, the terms WD and UE may be used interchangeably. Thus, although FIG. 24 is a UE, the components described herein are equally applicable to a WD and vice versa.

[0161] In FIG. 24, UE 2400 includes a processing circuit 2401 operatively coupled to an input / output interface 2405, a radio frequency (RF) interface 2409, a network connection interface 2411, memory 2415 including random access memory (RAM) 2417, read only memory (ROM) 2419, storage medium 2421, etc., a communication subsystem 2431, a power source 2413, and / or any other components, or any combination thereof. Storage medium 2421 includes operating system 2423, application programs 2425, and data 2427. In other embodiments, storage medium 2421 may include other similar types of information. Some UEs may utilize all of the components shown in FIG. 24 or a subset of those components. The level of integration between components may vary from UE to UE. Additionally, some UEs may include multiple instances of components, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0162] In Fig. 24, the processing circuit 2401 may be configured to process computer instructions and data. The processing circuit 2401 may be configured to implement any sequential state machine operable to execute machine instructions stored in memory as a machine-readable computer program, such as one or more hardware-implemented state machines (e.g., in discrete logic, FPGA, ASIC, etc.), programmable logic with appropriate firmware, one or more pre-programmed, general-purpose processors, such as a microprocessor or digital signal processor (DSP) with appropriate software, or any combination of the above. For example, the processing circuit 2401 may include two central processing units (CPUs). The data may be information in a format suitable for use by a computer.

[0163] In the illustrated embodiment, the input / output interface 2405 may be configured to provide an input device, an output device, or a communication interface to an input / output device. The UE 2400 may be configured to use an output device via the input / output interface 2405. The output device may use the same type of interface port as the input device. For example, a USB port may be used to provide input to and output from the UE 2400. The output device may be a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smart card, another output device, or any combination thereof. The UE 2400 may be configured to use an input device via the input / output interface 2405 to allow a user to capture information into the UE 2400. The input device may include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a webcam, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smart card, etc. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. The sensor may be, for example, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, a light sensor, a proximity sensor, another like sensor, or any combination thereof. For example, the input device may be an accelerometer, a magnetometer, a digital camera, a microphone, and a light sensor.

[0164] In FIG. 24, the RF interface 2409 may be configured to provide a communication interface to RF components, such as a transmitter, a receiver, and an antenna. The network connection interface 2411 may be configured to provide a communication interface to a network 2443A. The network 2443A may encompass a wired and / or wireless network, such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a communication network, another similar network, or any combination thereof. For example, the network 2443A may comprise a Wi-Fi network. The network connection interface 2411 may be configured to include a receiver and a transmitter interface used to communicate with one or more other devices over a communication network according to one or more communication protocols, such as Ethernet, TCP / IP, SONET, ATM, etc. The network connection interface 2411 may implement receiver and transmitter functions suitable for a communication network link (e.g., optical, electrical, etc.). The transmitter and receiver functions may share circuit components, software or firmware, or may alternatively be implemented separately.

[0165] The RAM 2417 may be configured to interface to the processing circuit 2401 via the bus 2402 to provide storage or caching of data or computer instructions during execution of software programs, such as an operating system, application programs, and device drivers. The ROM 2419 may be configured to provide computer instructions or data to the processing circuit 2401. For example, the ROM 2419 may be configured to store unchanging low-level system code or data for basic system functions, such as basic input / output (I / O), booting, or receiving keystrokes from a keyboard, stored in non-volatile memory. The storage medium 2421 may be configured to include memory, such as RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disk, optical disk, floppy disk, hard disk, removable cartridge, or flash drive. In one example, the storage medium 2421 may be configured to include an operating system 2423, an application program 2425, such as a web browser application, a widget or gadget engine, or another application, and data files 2427. The storage medium 2421 may store any of a variety of different operating systems or combinations of operating systems for use by the UE 2400.

[0166] The storage medium 2421 may be configured to include several physical drive units, such as a redundant array of independent disks (RAID), a floppy disk drive, a flash memory, a USB flash drive, an external hard disk drive, a thumb drive, a pen drive, a key drive, a high density digital versatile disk (HD-DVD) optical disk drive, an internal hard disk drive, a Blu-Ray optical disk drive, a holographic digital data storage (HDDS) optical disk drive, an external mini dual in-line memory module (DIMM), a synchronous dynamic random access memory (SDRAM), an external micro-DIMM SDRAM, a smart card memory such as a subscriber identity module or a removable user identity (SIM / RUIM) module, other memory, or any combination thereof. The storage medium 2421 may enable the UE 2400 to access computer executable instructions, application programs, etc. stored in a temporary or non-transitory memory medium, offload data, or upload data. An article of manufacture, such as an article of manufacture utilizing a communication system, may be tangibly embodied in the storage medium 2421, which may comprise a device-readable medium.

[0167] In FIG. 24, the processing circuit 2401 may be configured to communicate with the network 2443B using the communication subsystem 2431. The network 2443A and the network 2443B may be the same network or networks or different networks or networks. The communication subsystem 2431 may be configured to include one or more transceivers used to communicate with the network 2443B. For example, the communication subsystem 2431 may be configured to include one or more transceivers used to communicate with one or more remote transceivers of another device capable of wireless communication, such as another WD, UE, or base station of a radio access network (RAN), according to one or more communication protocols, such as IEEE 802.11, CDMA, WCDMA, GSM, LTE, UTRAN, WiMax, etc. Each transceiver may include a transmitter 2433 and / or a receiver 2435 for implementing a transmitter function or a receiver function, respectively, appropriate for a RAN link (e.g., frequency allocation, etc.). Furthermore, the transmitter 2433 and receiver 2435 of each transceiver may share circuit components, software or firmware, or may alternatively be implemented separately.

[0168] In the illustrated embodiment, the communication functions of the communication subsystem 2431 may include data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication such as using a global positioning system (GPS) to determine location, another similar communication function, or any combination thereof. For example, the communication subsystem 2431 may include cellular communication, Wi-Fi communication, Bluetooth communication, and GPS communication. The network 2443b may encompass wired and / or wireless networks, such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a communication network, another similar network, or any combination thereof. For example, the network 2443B may be a cellular network, a Wi-Fi network, and / or a near-field network. The power source 2413 may be configured to provide alternating current (AC) or direct current (DC) power to the components of the UE 2400.

[0169] The features, benefits and / or functions described herein may be implemented in one of the components of the UE 2400 or distributed across multiple components of the UE 2400. Furthermore, the features, benefits and / or functions described herein may be implemented in any combination of hardware, software or firmware. In one example, the communication subsystem 2431 may be configured to include any of the components described herein. Furthermore, the processing circuit 2401 may be configured to communicate with any of such components over the bus 2402. In another example, any of such components may be represented by program instructions stored in memory that, when executed by the processing circuit 2401, perform the corresponding functions described herein. In another example, the functions of any of such components may be distributed between the processing circuit 2401 and the communication subsystem 2431. 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.

[0170] FIG. 25 is a schematic block diagram illustrating a virtualization environment 2500 in which functions implemented by some embodiments may be virtualized. In this context, virtualizing means creating a virtual version of an apparatus or device, which may include virtualizing a hardware platform, storage devices, and networking resources. Virtualization as used herein may be applied to a node (e.g., a virtualized base station or a virtualized radio access node) or to a device (e.g., a UE, a wireless device, or any other type of communication device) or a component of that device, and relates to implementations in which at least a portion of the functionality is implemented as one or more virtual components (e.g., via one or more applications, components, functions, virtual machines, or containers running on one or more physical processing nodes in one or more networks).

[0171] In some embodiments, some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines implemented in one or more virtual environments 2500 hosted by one or more of the hardware nodes 2530. Furthermore, in embodiments where the virtual nodes are not wireless access nodes or do not require wireless connectivity (e.g., core network nodes), the network nodes may be fully virtualized.

[0172] The functionality may be implemented by one or more applications 2520 (which may alternatively be referred to as software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) operable to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein. The applications 2520 are run in a virtualization environment 2500, which provides hardware 2530 comprising a processing circuit 2560 and a memory 2590. The memory 2590 includes instructions 2595 executable by the processing circuit 2560 such that the applications 2520 are operable to provide one or more of the features, benefits, and / or functions disclosed herein.

[0173] The virtualization environment 2500 includes a general-purpose or dedicated network hardware device 2530 including a set of one or more processors or processing circuitry 2560, which may be a commercial off-the-shelf (COTS) processor, a dedicated application specific integrated circuit (ASIC), or any other type of processing circuitry including digital or analog hardware components or dedicated processors. Each hardware device may include a memory 2590-1, which may be a non-persistent memory for temporarily storing instructions 2595 or software executed by the processing circuitry 2560. Each hardware device may include one or more network interface controllers (NICs) 2570, also known as network interface cards, which include physical network interfaces 2580. Each hardware device may also include a non-transitory, persistent, machine-readable storage medium 2590-2 having stored thereon software 2595 and / or instructions executable by the processing circuitry 2560. Software 2595 may include any type of software, including software for instantiating one or more virtualization layers 2550 (also called hypervisors), software for running virtual machines 2540, and software that enables it to perform the functions, features and / or benefits described in connection with some embodiments described herein.

[0174] The virtual machines 2540 may comprise virtual processing, virtual memory, virtual networking or interfaces, and virtual storage and may be run by a corresponding virtualization layer 2550 or hypervisor. Different embodiments of the virtual appliance 2520 instances may be implemented on one or more of the virtual machines 2540, and the implementations may be done in different ways.

[0175] During operation, the processing circuitry 2560 executes software 2595 to instantiate a hypervisor or virtualization layer 2550, which may sometimes be referred to as a virtual machine monitor (VMM). The virtualization layer 2550 may present to the virtual machine 2540 a virtual operating platform that looks like networking hardware.

[0176] 25, the hardware 2530 may be a standalone network node with general or specific components. The hardware 2530 may include an antenna 25225 and may implement some functions via virtualization. Alternatively, the hardware 2530 may be part of a larger cluster of hardware (e.g., as in the case of a data center or customer premises equipment (CPE)) where many hardware nodes work together and are managed via a management and orchestration (MANO) 25100 that, among other things, oversees the lifecycle management of the applications 2520.

[0177] Hardware virtualization is referred to in some contexts as network function virtualization (NFV). NFV can be used to consolidate many network equipment types onto industry-standard high-volume server hardware, physical switches, and physical storage that may be located in data centers and customer premises equipment.

[0178] In the context of NFV, virtual machine 2540 may be a software implementation of a physical machine that runs programs as if those programs were running on a physical, non-virtualized machine. Each virtual machine 2540 and the portion of hardware 2530 on which it runs, whether hardware dedicated to that virtual machine and / or hardware shared by that virtual machine with other ones of virtual machines 2540, form a separate Virtual Network Element (VNE).

[0179] Further in the context of NFV, a virtual network function (VNF) is responsible for handling a specific network function running on one or more virtual machines 2540 on top of the hardware networking infrastructure 2530 and corresponds to application 2520 in FIG. 25.

[0180] In some embodiments, one or more radio units 25200, each including one or more transmitters 25220 and one or more receivers 25210, may be coupled to one or more antennas 25225. The radio units 25200 may communicate directly with the hardware node 2530 via one or more suitable network interfaces and may be used in combination with a virtualization component to provide a virtualization node with wireless capabilities, such as a wireless access node or base station.

[0181] In some embodiments, some signaling may be accomplished using the control system 25230, which may alternatively be used for communication between the hardware node 2530 and the wireless unit 25200.

[0182] Embodiment Group A Embodiments 1. A method for reporting fault information in a self-organizing network (SON), the method comprising: - receiving, from the first cell, a first handover command for attempting a handover from the first cell to a second cell; - completing a handover from the first cell to the second cell based at least in part on the first handover command; - receiving, from the second cell, a second handover command for attempting a handover from the second cell to a third cell while connected to the second cell, where a dual active protocol stack (DAPS) is configured for one or more bearers associated with the handover from the second cell to the third cell; - experiencing a failure while attempting a handover from the second cell to a third cell; - storing first failure information related to a failure during a handover attempt from the second cell to the third cell; - performing a DAPS fallback to the second cell based at least in part on experiencing a failure during an attempt to handover from the second cell to the third cell; - experiencing a radio link failure while connected to the second cell; - storing second failure information related to experiencing a radio link failure; - transmitting the first failure information or the second failure information; A method comprising: 2. - deleting the first failure information based at least in part on experiencing a radio link failure while connected to the second cell. 2. The method of embodiment 1, further comprising: 3. - deleting the first failure information based at least in part on experiencing a radio link failure while attempting a handover to the fourth cell. 2. The method of embodiment 1, further comprising: 4. - Deleting the first failure information based at least in part on experiencing another handover failure. 2. The method of embodiment 1, further comprising: 5. The method of embodiment 1, wherein storing the second failure information includes appending the second failure information to the first failure information. 6. The method of embodiment 1, wherein storing the second failure information includes storing handover information related to completing a handover from the first cell to the second cell. 7. - Deleting the first fault information and logging information related to deleting the first fault information. 2. The method of embodiment 1, further comprising: 8. The method of any one of embodiments 1 to 7, wherein storing the first failure information includes storing the first failure information in a radio link failure (RLF) report, or storing the second failure information includes storing the second failure information in an RLF report. 9. A method as in any one of embodiments 1 to 8, wherein storing the second failure information includes storing time-since-fallback information indicating a time elapsed between experiencing a failure while attempting a handover from the second cell to the third cell and experiencing a radio link failure while connected to the second cell. 10. A method as in any one of embodiments 1 to 9, wherein storing the second failure information includes storing time-conn-failure information indicating a time elapsed between receiving the second handover command and experiencing a radio link failure while connected to the second cell. 11. The method of any one of embodiments 1 to 10, wherein storing the second failure information includes storing fallback flag information indicating experiencing a radio link failure after performing a DAPS fallback, and the fallback flag information can be used to determine whether the time-conn-failure information represents an elapsed time between experiencing a failure while attempting a handover from the second cell to a third cell and experiencing the radio link failure, based at least in part on which the wireless device performed the DAPS fallback. 12. The method of any one of embodiments 1 to 11, wherein storing the second failure information includes storing radio measurement information indicative of available radio measurements related to the serving cell, the target cell, or a neighboring cell during a duration between performing the DAPS fallback and experiencing a radio link failure while connected to the second cell. 13. The method of any one of embodiments 1 to 12, wherein storing the second failure information includes storing time-since-last-successful-HO information indicating a time elapsed between completing a handover from the first cell to the second cell and experiencing a radio link failure while connected to the second cell. 14. - logging consecutive-failure-time information indicating an elapsed time between two consecutive failures, including a first failure and a second failure, where the second failure triggers the deletion of the first failure information. 14. The method of any one of the preceding claims, further comprising: 15. The method of any one of embodiments 1 to 14, wherein storing the second failure information includes storing time-since-last-unsuccessful-HO information indicating a time elapsed between receiving the second handover command and experiencing a failure while attempting a handover from the second cell to the third cell. 16. - Providing user data and - forwarding user data to a host computer via transmission to a base station; 16. The method of any one of the preceding embodiments, further comprising: Group B Embodiments 17. A method implemented by a base station, the method comprising: - receiving first fault information or second fault information from a wireless device; - determining that the wireless device experiences a radio link failure before performing a DAPS fallback and within a predetermined time window from completing a handover from the first cell to the second cell; - optimizing the handover configuration, including optimizing one or more handover parameters based at least in part on the determination; A method comprising: 18. A method implemented by a base station, the method comprising: - receiving first fault information or second fault information from a wireless device; - determining that the wireless device experiences a radio link failure after performing a DAPS fallback; - optimizing the handover configuration, including optimizing one or more handover parameters based at least in part on the determination; A method comprising: 19. A method implemented by a base station, the method comprising: - receiving first fault information or second fault information from a wireless device; - determining an identity of another base station associated with experiencing a failure during the handover attempt based at least in part on the first failure information or determining an identity of another base station associated with experiencing a radio link failure based at least in part on the second failure information; - forwarding the first failure information or the second failure information to another base station to enable the other base station to optimize a handover configuration, including optimizing one or more handover parameters; A method comprising: 20. - Acquiring user data; - forwarding user data to a host computer or wireless device; 20. The method of any one of embodiments 17 to 19, further comprising: Group C Embodiments 21. A wireless device for reporting fault information in a self-organizing network (SON), comprising: - a processing circuit configured to perform any of the steps recited in any one of the embodiments of group A; and - a power delivery circuit configured to power a wireless device; A wireless device comprising: 22. A base station, comprising: - a processing circuit configured to perform any of the steps recited in any one of the embodiments of Group B; - a power supply circuit configured to supply power to a base station; A base station comprising: 23. A user equipment (UE) for reporting fault information in a self-organizing network (SON), comprising: - an antenna configured to transmit and receive radio signals; a radio front-end circuit coupled to an antenna and to a processing circuit and configured to condition a signal communicated between the antenna and the processing circuit, - a processing circuit configured to perform any of the steps recited in any one of the embodiments of group A; A radio front-end circuit; - an input interface connected to the processing circuitry and configured to enable input of information to the UE to be processed by the processing circuitry; - an output interface connected to the processing circuit and configured to output information from the UE that has been processed by the processing circuit; - a battery and a A user equipment (UE) comprising: 24. A communication system including a host computer, the host computer comprising: - processing circuitry configured to provide user data; - a communications interface configured to forward user data to a cellular network for transmission to a user equipment (UE); Equipped with - the cellular network comprises a base station having a radio interface and a processing circuit, the processing circuit of the base station being configured to perform any of the steps of any one of the embodiments of group B; Communication systems. 25. The communication system of embodiment 24, further comprising a base station. 26. The communication system of embodiment 24 or 25, further comprising a UE, the UE being configured to communicate with the base station. 27. - A method according to claim 1, wherein processing circuitry of a host computer is configured to execute a host application and thereby provide user data; - the UE comprises processing circuitry configured to execute a client application associated with the host application; A communication system as described in any one of embodiments 24 to 26. 28. A method implemented in a communications system including a host computer, a base station, and a user equipment (UE), the method comprising: providing user data at a host computer; initiating, at the host computer, a transmission conveying user data to the UE via a cellular network comprising a base station, the base station performing any of the steps recited in any one of the embodiments of Group B; A method comprising: 29. The method of embodiment 28, further comprising transmitting user data at the base station. 30. The method of embodiment 28 or 29, wherein the user data is provided by executing a host application at the host computer, and the method further includes executing, at the UE, a client application associated with the host application. 31. A user equipment (UE) configured to communicate with a base station, the UE comprising a radio interface and processing circuitry configured to implement any one of embodiments 28 to 30. 32. A communication system including a host computer, the host computer comprising: - processing circuitry configured to provide user data; - a communications interface configured to forward user data to a cellular network for transmission to a user equipment (UE); Equipped with a UE comprising a radio interface and a processing circuit, the components of the UE being configured to perform any of the steps described in any one of the embodiments of group A; Communication systems. 33. The communication system of embodiment 32, wherein the cellular network further includes a base station configured to communicate with the UE. 34. - A method according to claim 1, wherein processing circuitry of a host computer is configured to execute a host application and thereby provide user data; - processing circuitry of the UE configured to execute a client application associated with the host application; A communication system as described in embodiment 32 or 33. 35. A method implemented in a communications system including a host computer, a base station, and a user equipment (UE), the method comprising: providing user data at a host computer; initiating, at the host computer, a transmission conveying user data to a UE via a cellular network comprising a base station, the UE performing any of the steps recited in any one of the embodiments of group A; A method comprising: 36. The method of embodiment 35, further comprising: receiving, at the UE, user data from the base station. 37. A communication system including a host computer, the host computer comprising: - a communications interface configured to receive user data originating from a transmission from a user equipment (UE) to a base station; Equipped with a UE comprising a radio interface and a processing circuit, the processing circuit of the UE being configured to perform any of the steps of any one of the embodiments of group A; Communication systems. 38. The communication system of embodiment 37, further comprising a UE. 39. The communication system of embodiment 37 or 38, further comprising a base station, the base station having a radio interface configured to communicate with the UE and a communication interface configured to forward user data carried by a transmission from the UE to the base station to a host computer. 40. - The processing circuitry of a host computer is configured to execute a host application; - processing circuitry of the UE configured to execute a client application associated with the host application and thereby provide user data; A communication system described in any one of embodiments 37 to 39. 41. - A method according to claim 1, wherein processing circuitry of a host computer is configured to execute a host application and thereby provide requested data; - processing circuitry of the UE configured to execute a client application associated with the host application and thereby provide user data in response to the request data; A communication system described in any one of embodiments 37 to 40. 42. A method implemented in a communications system including a host computer, a base station, and a user equipment (UE), the method comprising: - receiving, at the host computer, user data transmitted from the UE to the base station, wherein the UE performs any of the steps recited in any one of the embodiments of group A. A method comprising: 43. The method of embodiment 42, further comprising, in the UE, providing user data to the base station. 44. - executing, in the UE, a client application thereby providing user data to be transmitted; - executing, at the host computer, a host application associated with the client application; 44. The method of embodiment 42 or 43, further comprising: 45. - executing, in a UE, a client application; receiving, at the UE, input data for a client application, the input data being provided by executing, at a host computer, a host application associated with the client application; Further comprising: A method according to any one of embodiments 42 to 44, wherein the user data to be transmitted is provided by a client application in response to input data. 46. ​​A communications system including a host computer, the host computer having a communications interface configured to receive user data originating from a transmission from a user equipment (UE) to a base station, the base station having a wireless interface and processing circuitry, the processing circuitry of the base station configured to perform any of the steps recited in any one of the embodiments of Group B. 47. The communication system of embodiment 46, further comprising a base station. 48. The communication system of embodiment 46 or 47, further comprising a UE, the UE being configured to communicate with the base station. 49. - The processing circuitry of a host computer is configured to execute a host application; - the UE is configured to execute a client application associated with the host application and thereby provide user data to be received by the host computer; A communication system described in any one of embodiments 46 to 48. 50. A method implemented in a communications system including a host computer, a base station, and a user equipment (UE), the method comprising: receiving, at the host computer, from a base station, user data originating from a transmission received by the base station from the UE, wherein the UE performs any of the steps recited in any one of the embodiments of group A. A method comprising: 51. The method of embodiment 50, further comprising receiving, at the base station, user data from the UE. 52. The method of embodiment 50 or 51, further comprising initiating, at the base station, transmission of the received user data to the host computer.

Claims

1. A method implemented by a wireless device (2310, 2310B, 2310C, 2400, 2520, 2691, 2692, 2730) for reporting fault information in a self-organizing network (SON), the method comprising: receiving (801) a handover command from a source cell (600) for attempting a handover from the source cell (600) to a target cell (602) while connected to the source cell (600), where a dual active protocol stack (DAPS) is configured for one or more bearers associated with the handover from the source cell (600) to the target cell (602); Experiencing (803) a failure during the handover attempt from the source cell (600) to the target cell (602); storing (805) first failure information related to the failure during the handover attempt from the source cell (600) to the target cell (602); performing a DAPS fallback (807) to the source cell (600) based at least in part on experiencing the failure during the handover attempt from the source cell (600) to the target cell (602); Experiencing a Radio Link Failure (RLF) (809) while connected to the source cell (600); storing (811) second fault information related to experiencing the RLF; Sending the first fault information or the second fault information to the SON (813); Including, Storing the second failure information storing (1101) time-since-fallback information indicative of the time elapsed between experiencing the failure while attempting the handover from the source cell (600) to the target cell (602) and experiencing the RLF while connected to the source cell (600); storing (1201) time-conn-failure information indicative of the time elapsed between receiving the handover command and experiencing the radio link failure while connected to the source cell (600); or storing (1301) conn-time-failure information indicative of the time elapsed between initiating the handover from the source cell (600) to the target cell (602) and experiencing the radio link failure while connected to the source cell (600); A method comprising:

2. 2. The method of claim 1, wherein experiencing the RLF while connected to the source cell (600) comprises experiencing the RLF while connected to the source cell (600) after the DAPS fallback.

3. Deleting (901) the first fault information based at least in part on experiencing the RLF while connected to the source cell (600). The method of claim 1 or 2, further comprising:

4. Logging that the first fault information has been deleted (903). The method of claim 3 further comprising:

5. 5. The method of claim 1, wherein storing the first failure information comprises storing the first failure information in a Radio Link Failure (RLF) report (1001), or wherein storing the second failure information comprises storing the second failure information in the RLF report.

6. 6. The method of claim 1, wherein storing the second failure information comprises storing fallback flag information (1401) indicating the experiencing of the RLF after performing the DAPS fallback, and the fallback flag information can be used to determine whether time-conn-failure information or conn-time-failure represents a time elapsed between experiencing the failure during the attempt of the handover from the source cell (600) to the target cell (602) on which the wireless device performed the DAPS fallback, at least in part, and experiencing the RLF.

7. 7. The method of claim 1, wherein storing the second failure information comprises storing (1501) timing information indicative of an elapsed time between receiving the handover command and experiencing the failure while attempting the handover from the source cell (600) to the target cell (602).

8. 8. The method of claim 1, wherein storing the second failure information comprises storing fallback timing information (1601) indicative of a time elapsed between receiving the handover command and performing the DAPS fallback.

9. 9. The method of claim 1, wherein storing the second failure information comprises storing (1701) radio measurement information indicative of available radio measurements related to a serving cell, a target cell, or a neighboring cell during a duration between performing the DAPS fallback and experiencing the RLF while connected to the source cell.

10. storing the second failure information includes storing (1801) time-since-last-unsuccessful-HO timing information indicative of an elapsed time between receiving the handover command and experiencing the failure during the handover attempt from the source cell (600) to the target cell (602); or storing the second failure information includes storing (1901) time-to-last-unsuccessful-HO timing information indicative of an elapsed time between initiating the handover and experiencing the failure while attempting the handover from the source cell (600) to the target cell (602); 10. The method according to any one of claims 1 to 9.

11. A method implemented by a base station (2360, 2520, 2612A, 2612B, 2612C, 2720) in a self-organizing network (SON), the method comprising: Receiving at least second fault information from a wireless device (2310, 2310B, 2310C, 2400, 2520, 2691, 2692, 2730) (2001); determining (2003) whether the wireless device experiences a radio link failure (RLF) after performing a dual active protocol stack (DAPS) fallback; optimizing handover settings (2005), including optimizing one or more handover parameters based at least in part on determining that the wireless device experienced the RLF after performing the DAPS fallback; Including, The second fault information is time-since-fallback information indicating the time elapsed between experiencing a failure while attempting a handover from a source cell to a target cell and experiencing the RLF while connected to the source cell; time-conn-failure information indicating the time elapsed between receiving a handover command and experiencing the radio link failure while connected to the source cell; or conn-time-failure information indicating the time elapsed between initiating the handover from the source cell to the target cell and experiencing the radio link failure while connected to the source cell; A method comprising:

12. determining (2101) whether the wireless device experienced the RLF within a predetermined time window before performing the DAPS fallback and from completing a handover from a first cell to a source cell (600); optimizing handover settings (2103), including optimizing one or more handover parameters based at least in part on determining that the wireless device experienced the RLF within the predetermined time window prior to performing the DAPS fallback and from completing the handover from the first cell to the source cell (600); The method of claim 11 further comprising:

13. determining an identity of another base station associated with experiencing a failure during a handover attempt based at least in part on first failure information, or determining an identity of another base station associated with experiencing an RLF based at least in part on the second failure information (2201); forwarding the first failure information or the second failure information to the other base station to enable the other base station to optimize handover settings, including optimizing one or more handover parameters (2203); 13. The method of claim 11 or 12, further comprising:

14. A wireless device (2310, 2310B, 2310C, 2400, 2520, 2691, 2692, 2730) configured to operate in a self-organizing network (SON), the wireless device comprising: A processing circuit (2401); and a memory (2415) coupled to the processing circuitry, the memory, when executed by the processing circuitry, providing to the wireless device: receiving (801) a source handover command from a source cell (600) for attempting a handover from the source cell (600) to a target cell (602) while connected to the source cell (600), where a dual active protocol stack (DAPS) is configured for one or more bearers associated with the handover from the source cell (600) to the target cell (602); Experiencing (803) a failure during the handover attempt from the source cell (600) to the target cell (602); storing (805) first failure information related to the failure during the handover attempt from the source cell (600) to the target cell (602); performing a DAPS fallback (807) to the source cell (600) based at least in part on experiencing the failure during the handover attempt from the source cell (600) to the target cell (602); Experiencing a radio link failure (RLF) (809) while connected to the source cell (600) after the DAPS fallback; storing (811) second failure information related to experiencing said radio link failure, Storing the second failure information includes: storing (1101) time-since-fallback information indicative of the time elapsed between experiencing the failure while attempting the handover from the source cell (600) to the target cell (602) and experiencing the RLF while connected to the source cell (600); storing (1201) time-conn-failure information indicative of the time elapsed between receiving the handover command and experiencing the radio link failure while connected to the source cell (600); or storing (1301) conn-time-failure information indicative of the time elapsed between initiating the handover from the source cell (600) to the target cell (602) and experiencing the radio link failure while connected to the source cell (600); and Sending the first fault information or the second fault information to the SON (813); A wireless device (2310, 2310B, 2310C, 2400, 2520, 2691, 2692, 2730) comprising instructions to cause the wireless device to perform operations including:

15. 15. The wireless device of claim 14, wherein the memory includes further instructions that, when executed by the processing circuitry, cause the wireless device to perform operations according to any one of claims 2 to 10.

16. A processing circuit (2370, 2560); a memory (2380, 2590) coupled to said processing circuit; wherein the memory, when executed by the processing circuitry, provides the base station with: Receiving at least second fault information from a wireless device (2001); determining (2003) whether the wireless device experiences a radio link failure (RLF) after performing a dual active protocol stack (DAPS) fallback; optimizing handover settings (2005), including optimizing one or more handover parameters based at least in part on determining that the wireless device experienced the RLF after performing the DAPS fallback; [0023] comprising instructions to perform operations including: The second fault information is time-since-fallback information indicating the time elapsed between experiencing a failure while attempting a handover from a source cell to a target cell and experiencing the RLF while connected to the source cell; time-conn-failure information indicating the time elapsed between receiving a handover command and experiencing the radio link failure while connected to the source cell; or conn-time-failure information indicating the time elapsed between initiating the handover from the source cell to the target cell and experiencing the radio link failure while connected to the source cell; A base station (2360, 2520).

17. 17. The base station (2360) of claim 16, wherein the memory includes further instructions which, when executed by the processing circuitry, cause the base station to perform the operations of claim 12 or 13.

18. A computer program comprising a non-transitory storage medium containing program code to be executed by a processing circuit of a wireless device (2310, 2310B, 2310C, 2400, 2520) configured to operate in a self-organizing network (SON), whereby execution of the program code causes the wireless device to perform a method according to any one of claims 1 to 10.

19. A computer program comprising a non-transitory storage medium containing program code to be executed by a processing circuit of a base station (2360, 2520), whereby execution of the program code causes the base station (2360, 2520) to perform a method according to any one of claims 11 to 13.

Images