Managing network optimization in handover failure scenarios

Abstract

Processing hardware in a user equipment (UE) connected to a first cell associated with a first radio access technology can implement a method for supporting handover to a second cell associated with a second RAT. The method includes attempting (2302) to connect to the second cell and detecting (2304) that applying a configuration associated with the second cell fails. The method also includes providing (2306) an indication of the configuration failure via the first cell by sending a request to reestablish a radio connection, the request including a failure cause indicating the reconfiguration failure.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to wireless communication, and more specifically, the present disclosure relates to managing network optimization and failure reporting in handover failure scenarios. BACKGROUND

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

[0003] Wireless communication has evolved to fifth generation (5G) standards and technologies that provide higher data rates and greater capacity with improved reliability and lower latency, which enhances mobile broadband service. 5G technologies also provide new categories of service for vehicles, fixed wireless broadband, and the Internet of Things (IoT). The specification of features in the 5G air interface is defined as 5G New Radio (5G NR).

[0004] To communicate wirelessly with a radio access network (RAN), a user equipment (UE) can establish a connection to the RAN via at least one network node (e.g., a base station or serving cell) that supports a fifth generation core network (5GC). In some cases, a base station (BS) can request a UE to connect to another BS using a handover procedure. During the handover procedure, the UE can transition from a source BS to a target BS or cell without losing the connection to the RAN. The source BS and target BS nodes can be associated with the same radio access technology (RAT) or different RATs.

[0005] In a telecommunications system, the packet data convergence protocol (PDCP) sublayer of the radio protocol stack provides services such as transfer of user plane data, ciphering, integrity protection, etc. For example, the PDCP layer defined for the Evolved Universal Terrestrial Radio Access (EUTRA) radio interface (see 3GPP TS 36.323) and New Radio (NR) (see TS 38.323) provides for the ordering of protocol data units (PDUs) in the uplink direction (from a user equipment (UE) to a base station) as well as in the downlink direction (from a base station to a UE). In addition, the PDCP sublayer provides signaling radio bearers (SRBs) and data radio bearers (DRBs) to the radio resource control (RRC) sublayer. Generally, UEs and base stations can use SRBs to exchange RRC messages as well as non-access stratum (NAS) messages, and use DRBs to transfer data on the user plane.

[0006] Various errors can occur in a radio link between a UE and a RAN and during a procedure performed by a UE and a RAN for handover of the UE from one base station to another. Generally, a UE reports different kinds of errors to a RAN using different error codes. However, in some cases, existing error reporting schemes do not result in the UE accurately reporting errors to the RAN.

[0007] In particular, existing techniques do not always clearly designate errors detected during handover procedures, such as dual active protocol stack (DAPS) handover and inter-radio access technology (RAT) handover. As a result of suboptimal error reporting during these scenarios, the network can perform error mitigation techniques (e.g., mobility robustness optimization (MRO)) that do not address the issues detected by the UE. SUMMARY

[0008] A UE and / or base station of the present disclosure can manage errors in scenarios involving DAPS handover or inter-RAT handover in order to support network optimization.

[0009] For example, during a dual active protocol stack (DAPS) handover, a UE connected to a base station attempts to connect to a target base station while maintaining a connection to an original base station. The UE can detect issues with both the connection to the target base station and the connection to the original base station. A UE of the present disclosure mitigates the interaction of these errors and reduces incomplete or inaccurate error reporting to the network, thereby helping the network address DAPS handover failures.

[0010] As another example, a UE connected to a cell of a first radio access technology (RAT) (e.g., a fourth generation (4G) RAT) attempts to connect to a cell of a second RAT (e.g., a fifth generation (5G) RAT) via an inter-RAT handover. If the UE is unable to complete the handover, the UE can report a handover failure. While existing techniques do not always clearly designate the cause of the handover failure, a UE of the present disclosure reports allow the RAN to correctly handle the cause of the failure (e.g., a failure to apply a configuration in a handover request).

[0011] In some scenarios, a UE of the present disclosure initially operates in conjunction with a base station and attempts to connect to a target base station during a DAPS handover. If (i) while a timer that the UE started in response to detecting a synchronization problem with the (source) base station is running or (ii) before detecting a radio failure, the UE detects a DAPS handover failure, the UE can report the DAPS handover failure by sending an RRCReestablishmentRequest to the base station that includes a failure cause corresponding to a handover failure. Alternatively, if the UE sends an RRCReestablishmentRequest that includes a failure cause corresponding to a radio link failure (RLF), a base station of the present disclosure can still determine whether the UE detected a DAPS handover failure. If the base station previously sent a DAPS handover configuration to the UE and has not received an indication of a handover success or failure, the base station can determine that the UE detected a DAPS handover failure and can perform network optimization accordingly.

[0012] In other scenarios, a UE initially operates in conjunction with a base station via a first cell and attempts to connect to a second cell associated with a different RAT. If the UE is unable to apply a configuration associated with the second cell, the UE sends an RRCReestablishmentRequest to the base station that includes a failure cause corresponding to a reconfiguration failure. Alternatively, if the UE instead sends an RRCReestablishmentRequest that includes a failure cause corresponding to a handover failure, a base station of the present disclosure can still determine whether the UE was unable to apply the configuration. If the base station later receives an indication that the handover information is not available at the UE, the base station can determine that the UE was unable to apply the configuration and can take appropriate corrective action.

[0013] An example embodiment of the techniques of the present disclosure is a method for supporting a DAPS handover in a UE connected to a first base station of a RAN. The method is implemented by processing hardware and includes attempting to connect to a second base station of the RAN during a DAPS handover. The method further includes detecting a potential failure associated with a radio connection to the first base station and detecting a failure to connect to the second base station. In addition, the method includes initiating a procedure to reestablish the radio connection, the initiating including providing an indication of a connection failure to the RAN.

[0014] Another example embodiment of the techniques is a method in a UE connected to a first cell associated with a RAT for supporting a handover to a second cell associated with a second RAT. The method is performed by processing hardware and includes attempting to connect to the second cell and detecting a failure to apply a configuration associated with the second cell. The method further includes providing an indication of a failure to apply the configuration via the first cell.

[0015] Yet another example embodiment of the technology is a UE comprising processing hardware and configured to perform the above-described methods.

[0016] Another example embodiment of the technology is a method in a first base station communicating with a UE via a radio link. The method is implemented by processing hardware and comprises transmitting a configuration according to which the UE is to connect to a second base station during a DAPS handover procedure. The method also comprises receiving an indication that the UE detected a failure of the radio link. Further, the method comprises determining that the UE detected a failure to connect to the second base station and performing a network optimization procedure based on the determination.

[0017] Another example embodiment of the technology is a method for supporting inter-RAT handover in a base station supporting a first RAT for a first cell. The method is performed by processing hardware and comprises transmitting a request to a user equipment (UE) to connect to a second cell of a second RAT. The request comprises a configuration for the UE to use to connect to the second cell. The method also comprises receiving a request to reestablish a radio connection from the UE, the request comprising a failure cause indicating a failure of the handover. Further, the method comprises transmitting a message to configure a radio connection with the UE and receiving a response to the message, the response indicating that handover failure information is not available. Further, the method comprises determining that the UE is unable to apply the configuration and performing a corrective action in response to the determination.

[0018] Yet another example embodiment of the technology is a base station comprising processing hardware and configured to perform the above-described methods. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 is a block diagram of an example system in which a radio access network (RAN) and a user equipment are capable of implementing the technology of the disclosure for managing network optimization in handover failure scenarios;

[0020] Figure 2 is a block diagram of an example protocol stack of a UE to communicate with a base station of a RAN; Figure 1

[0021] Figure 3 is a block diagram of an example scenario in which a UE transmits failure information to a base station of a RAN;

[0022] Figure 4 is a messaging diagram of an example scenario in which a UE successfully completes a handover from a base station (BS) to a target base station (T-BS) according to a dual active protocol stack (DAPS) configuration;

[0023] Figure 5 ​is a messaging diagram of an example scenario in which the UE detects a DAPS handover failure after detecting a synchronization problem in a radio link with the BS and before detecting an RLF;

[0024] Figure 6 is a messaging diagram of an example scenario in which the UE detects an RLF after detecting a DAPS handover failure;

[0025] Figure 7 is a messaging diagram of another example scenario in which the UE detects an RLF after detecting a DAPS handover failure;

[0026] Figure 8 is a messaging diagram of an example scenario in which a BS that previously sent a DAPS configuration to a UE receives an RRCReestablishmentRequest from the UE indicating a failure cause corresponding to OtherFailure;

[0027] Figure 9 is a messaging diagram of an example scenario in which a BS that previously sent a DAPS configuration to a UE receives a failure report from another BS indicating that the UE sent an RRCReestablishmentRequest indicating a failure cause corresponding to OtherFailure;

[0028] Figure 10 is a flow diagram of an example method that can be implemented in a UE of the present disclosure that includes detecting a DAPS handover failure before detecting an RLF;

[0029] Figure 11 is a flow diagram of an example method that can be implemented in a UE of the present disclosure that includes detecting a DAPS handover failure while a timer that the UE started in response to detecting a synchronization problem is running;

[0030] Figure 12 is a flow diagram of an example method that can be implemented in a UE of the present disclosure that includes initializing an RRC reestablishment procedure in response to failing to successfully send a failure information message indicating a DAPS handover failure;

[0031] Figure 13 is a flow diagram of an example method that can be implemented in a base station of the present disclosure that includes performing network optimization based on a failure cause received in a request from a UE to reestablish a radio connection;

[0032] Figure 14 is a flow diagram of an example method that can be implemented in a base station of the present disclosure that includes performing network optimization based on a failure cause received in a failure report from another base station;

[0033] Figure 15 message flow diagram for an example scenario in which a UE fails to apply an intra-RAT handover configuration;

[0034] Figure 16 message flow diagram for an example scenario in which a UE fails to apply an inter-RAT handover configuration;

[0035] Figure 17 message flow diagram for another example scenario in which a UE fails to apply an inter-RAT handover configuration;

[0036] Figure 18 is a flow diagram of an example method that can be implemented in a UE of the present disclosure, including initializing an RRC reestablishment procedure based on detecting a failure to apply an inter-RAT handover configuration;

[0037] Figure 19 is a flow diagram of another example method that can be implemented in a UE of the present disclosure, including initializing an RRC reestablishment procedure based on detecting a failure to apply an inter-RAT handover configuration;

[0038] Figure 20 is a flow diagram of an example method that can be implemented in a base station of the present disclosure, including determining a failure of a UE to detect a failure to apply an inter-RAT handover configuration;

[0039] Figure 21 is a flow diagram of an example method that can be implemented in a UE of the present disclosure for supporting DAPS handover;

[0040] Figure 22 is a flow diagram of an example method that can be implemented in a base station of the present disclosure for network optimization in scenarios involving DAPS handover;

[0041] Figure 23 is a flow diagram of an example method that can be implemented in a UE of the present disclosure for supporting inter-RAT handover; and

[0042] Figure 24 is a flow diagram of an example method that can be implemented in a base station of the present disclosure for network optimization in scenarios involving inter-RAT handover. DETAILED DESCRIPTION

[0043] Generally, the communication devices of the present disclosure implement procedures related to dual active protocol stack (DAPS) handover procedures and inter-radio access technology (RAT) handover procedures. In a DAPS handover procedure, as described below, a base station (BS) can configure a UE to handover to a target base station (T-BS) using a DAPS configuration. After the UE successfully completes the handover to the T-BS, the T-BS configures the UE to release the connection between the UE and the BS. If the UE fails to connect to the T-BS, the UE reverts to the original configuration and remains connected to the original BS. In one implementation, releasing the connection can include resetting a medium access control (MAC) protocol and releasing the MAC configuration, releasing SRB / DRB radio link control (RLC) entities and associated logical channels, reconfiguring a DRB PDCP entity to normal PDCP, releasing a SRB PDCP entity, releasing a physical channel configuration, or discarding keys (KgNB, S-KgNB, S-KeNB, KRRCenc, KRRCint, KUPint, and / or KUPenc keys). An inter-RAT handover is a handover from one radio access technology (RAT) to another radio access technology (RAT) (e.g., from a fourth generation (4G) RAT to a fifth generation (5G) RAT, or vice versa).

[0044] Figure 1 An exemplary wireless communication system 100 is depicted in which a communication device can implement the techniques of the present disclosure. The wireless communication system 100 includes a UE 102, a base station 104, a base station 106, and a core network (CN) 110. In the scenarios discussed in the present disclosure, the UE 102 is initially connected to the base station 104.

[0045] In some scenarios, the base station 104 can perform an immediate handover preparation procedure to configure the UE 102 to perform a handover from the cell 124 of the base station 104 to the cell 126 of the base station 106 (the target BS or “T-BS”). During the immediate handover, the UE 102 disconnects from the BS 104 and attempts to connect to the T-BS 106.

[0046] In other scenarios, the base station 104 can perform a DAPS handover preparation procedure to configure the UE 102 to perform a handover from the cell 124 of the base station 104 to the cell 126 of the base station 106 (the target BS or “T-BS”). In contrast to the immediate handover case discussed above, the UE 102 does not immediately disconnect from the BS 104. In this scenario, the UE 102 disconnects from the BS 104 after the UE 102 connects to the T-BS 106. More specifically, when the UE 102 receives the configuration for the T-BS 106, the UE 102 does not disconnect from the BS 104 until the UE 102 has received a disconnect configuration from the T-BS 106.

[0047] For example, the base stations 104 and 106 can be any suitable one or more types of base station, such as an evolved Node B (eNB), a next generation eNB (ng-eNB), or a 5G Node B (gNB). The UE 102 can communicate with the base station 104 and the base station 106 via the same RAT (such as EUTRA or NR) or different RATs. The base station 104 supports the cell 124 and the base station 106 supports the cell 126. The cell 124 partially overlaps with the cell 126 such that the UE 102 can be within range to communicate with the base station 104 while also being within range to communicate with the base station 106 (or to detect or measure signals from the base station 106). The overlap can enable the UE 102 to handover between cells (e.g., from the cell 124 to the cell 126) or base stations (e.g., from the base station 104 to the base station 106). As another example, the UE 102 can communicate with the base station 104 (operating as a MN) and the base station 106 (operating as a SN) in dual connectivity (DC).

[0048] The base stations 104 and 106 can be connected to the same core network (CN) 110, which can be an evolved packet core (EPC) 111 or a fifth generation core (5GC) 160. The base station 104 can be implemented as an eNB that supports the S1 interface for communication with the EPC 111, as an ng-eNB that supports the NG interface for communication with the 5GC 160, or as a gNB that supports the NR radio interface and the NG interface for communication with the 5GC 160. The base station 106 can be implemented as an eNB with an S1 interface to the EPC 111, as an ng-eNB that is not connected to the EPC 111, as a gNB that supports the NR radio interface and the NG interface to the 5GC 160, or as an ng-eNB that supports the EUTRA radio interface and the NG interface to the 5GC 160. To exchange messages directly during the scenarios discussed below, the base stations 104 and 106 can support the X2 or Xn interface.

[0049] The EPC 111 can include, among other components, a serving gateway (S-GW) 112 and a mobility management entity (MME) 114. The S-GW 112 is generally configured to transfer user plane packets related to audio calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The 5GC 160 includes a user plane function (UPF) 162, as well as an access and mobility management (AMF) 164 and / or a session management function (SMF) 166. Generally speaking, the UPF 162 is configured to transfer user plane packets related to audio calls, video calls, Internet traffic, etc., the AMF 164 is configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is configured to manage PDU sessions.

[0050] In general, the wireless communication network 100 can include any suitable number of base stations that support NR cells and / or EUTRA cells. More specifically, the EPC 111 or the 5GC 160 can be connected to any suitable number of base stations that support NR cells and / or EUTRA cells. Although the examples below specifically refer to particular CN types (EPC, 5GC) and RAT types (5G NR and EUTRA), in general, the techniques of this disclosure can also be applied to other suitable radio access and / or core network technologies, such as sixth generation (6G) radio access and / or a 6G core network or 5G NR-6G DC.

[0051] With continued reference to Figure 1 , the base station 104 is equipped with processing hardware 130 that can include one or more general-purpose processors (e.g., central processing units (CPUs)) and non-transitory computer-readable memory that stores machine-readable instructions executable on the one or more general-purpose processors and / or special purpose processing units. The processing hardware 130 in example implementations includes a base station RRC controller 132 that is configured to manage or control one or more RRC configurations or RRC procedures. For example, the base station RRC controller 132 can be configured to support RRC messaging associated with DAPS and / or inter-RAT handover, as well as to support the techniques discussed below.

[0052] The base station 106 is equipped with processing hardware 140 that can also include one or more general-purpose processors (such as CPUs) and non-transitory computer-readable memory that stores machine-readable instructions executable on the one or more general-purpose processors and / or special purpose processing units. The processing hardware 140 in example implementations includes a base station RRC controller 142 that can be similar to the base station controller 132.

[0053] Still with reference to Figure 1 , the UE 102 is equipped with processing hardware 150 that can include one or more general-purpose processors (e.g., CPUs) and non-transitory computer-readable memory that stores machine-readable instructions executable on the one or more general-purpose processors and / or special purpose processing units. The processing hardware 150 in example implementations includes a UE RRC controller 152 that is configured to manage or control one or more RRC configurations and / or RRC procedures. For example, the UE RRC controller 152 can be configured to support RRC messaging associated with DAPS and / or inter-RAT handover, as well as to support the techniques discussed below.

[0054] In operation, the UE 102 can use radio bearers (e.g., DRBs or SRBs) that terminate at the base stations 104 or 106 at different times. When communicating on a radio bearer in the uplink (from the UE 102 to the base station) and / or downlink (from the base station to the UE 102) direction, the UE 102 can apply one or more security keys.

[0055] Next, Figure 2 An example radio protocol stack 200 is shown in simplified form, according to which the UE 102 can communicate with an eNB / ng-eNB or gNB (e.g., one or more of the base stations 104 and 106). A physical layer (PHY) 202A of EUTRA provides transport channels to a MAC sublayer 204A of EUTRA, which in turn provides logical channels to a RLC sublayer 206A of EUTRA. The RLC sublayer 206A in turn provides RLC channels to a PDCP sublayer 208 of EUTRA, and in some cases to a PDCP sublayer 210 of NR. Similarly, a PHY 202B of NR provides transport channels to a MAC sublayer 204B of NR, which in turn provides logical channels to a RLC sublayer 206B of NR. The RLC sublayer 206B in turn provides RLC channels to the PDCP sublayer 210 of NR. In some implementations, the UE 102 supports both EUTRA and NR stacks in order to support handover between EUTRA and NR base stations and / or to support DC over EUTRA and NR interfaces. Further, as shown, the UE 102 can support a layering of the NR PDCP sublayer 210 over the EUTRA RLC sublayer 206A. Figure 2

[0056] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets, which can be referred to as service data units (SDUs), from an Internet Protocol (IP) layer, either directly or indirectly layered over the PDCP layer 208 or 210, and output packets, which can be referred to as protocol data units (PDUs), to the RLC layer 206A or 206B, for example. Unless the difference between SDUs and PDUs is relevant, for simplicity the present disclosure refers to both SDUs and PDUs as “packets.”

[0057] For example, on the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 provide SRBs to exchange RRC messages. On the user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 provide DRBs to support exchange of data. ​

[0058] Next, Figure 3 An example scenario 300 is shown during which a UE 102 communicates failure information to base stations 104 and 106 of a RAN according to known techniques. Base station 104 operates as a source base station, and base station 106 operates as a target base station (T-BS). Initially, the UE operates 302 in a connected mode with BS 104. Later, the UE 102 detects 304 a connection failure in a radio connection with BS 104 and decides to connect to T-BS 106.

[0059] In response to the detection, the UE 102 sends 306 a connection failure report to T-BS 106. In one example, the connection failure report is an RRCReestablishmentRequest message that includes a reestablishment cause (e.g., handoverFailure to indicate that the UE 102 detected a handover failure, or otherFailure to indicate that the UE 102 detected an RLF) that indicates a failure cause. The disclosure also refers to this reestablishment cause as a failure cause. In another example, the connection failure report is a FailureInformation message that includes a failure indication (e.g., failureType set to daps-failure).

[0060] T-BS 106 then sends 308 a connection failure indication to BS 104. In one example, the connection failure indication is an RLF INDICATION (RLF indication) message (e.g., if T-BS 106 is an eNB) or a FAILURE INDICATION (failure indication) message (e.g., if T-BS 106 is a gNB). T-BS 106 includes a failure cause (e.g., an RRC Conn Reestab indicator, a UE RLF report container, or other indication of a handover failure, radio link failure, or conditional handover failure) in the connection failure indication.

[0061] Based on the connection failure indication (e.g., based on whether the failure cause was a handover failure, a radio link failure, or other failure), the BS 104 performs Mobility Robustness Optimization (MRO). In one example, if the failure cause was a radio link failure or other failure, the BS 104 determines that the handover attempt was too late. The BS 104 can adjust the measurement configuration of the UE 102 and other UEs in response to MRO. In one implementation, the BS 104 can increase the threshold in "Event A2 (service becomes worse than threshold)." As a result of this change, the UE 102 reports this event earlier. In another implementation, the BS 104 can decrease the offset in "Event A3 (neighbor becomes better offset than SpCell)," and as a result, the UE 102 reports this event earlier.

[0062] In another example, if the failure cause was a handover failure, the BS 104 determines that the handover attempt was too early. The BS 104 can adjust the measurement configuration of the UE 102 and other UEs in response to MRO. In one implementation, the BS 104 can decrease the threshold in "Event A2 (service becomes worse than threshold)," and as a result, the UE 102 reports this event later. In another implementation, the BS 104 can increase the offset in "Event A3 (neighbor becomes better offset than SpCell)," and as a result, the UE 102 reports this event later.

[0063] In one example, the BS 104 and the T-BS 106 can be the same or different cells associated with the same base station, in which case there is no exchange of connection failure indications between the BS 104 and the T-BS 106.

[0064] Figure 4An example messaging sequence during an example scenario 400 according to known techniques is shown in which the UE 102 successfully completes a DAPS handover from the BS 104 to the T-BS 106. Initially, the UE 102 operates 402 in a connected mode with the BS 104. The BS 104 decides 404 to handover the UE 102 to the T-BS 106 using a DAPS configuration. In response to the decision, the BS 104 sends 406 an RRCReconfiguration message with the DAPS configuration (e.g., dapsConfig) to the UE 102. In response to the RRCReconfiguration message, the UE 102 starts 408 a timer T304 and attempts 410 a random access procedure with the T-BS 106 according to the DAPS configuration. During the random access procedure, the UE 102 maintains 410 a connection with the BS 104. The timer T304 is used to track how long the UE 102 attempts to connect to the T-BS 104. If the timer T304 expires before the UE 102 successfully completes the handover to the T-BS 104, the UE 102 detects a DAPS handover failure. While the present disclosure generally refers to a “DAPS handover failure,” this error is sometimes also referred to as a reconfiguration with synchronization failure. Events 402, 406, 408, and 410 are collectively referred to as a DAPS handover attempt procedure 450.

[0065] At a later time, the UE 102 successfully performs 412 the random access procedure with the T-BS 106. In response, the UE 102 stops 412 the timer T304 and sends 414 an RRCReconfigurationComplete message to the T-BS 106. The UE 102 operates 416 in a connected mode with the T-BS 106. In response to receiving the RRCReconfigurationComplete message, the T-BS 106 can send 418 a Handover Success message to the BS 104 and / or send 420 an RRCReconfiguration message including a DAPS release indication (e.g., daps-SourceRelease) to the UE 102. The UE 102 then releases 422 the connection between it and the BS 104.

[0066] Figure 5-7 An example messaging sequence corresponding to a DAPS handover failure scenario is shown in which the UE 102 is able to support network optimization using the techniques of the present disclosure.

[0067] Figure 5A scenario 500 is shown in which base station 104 operates as a source base station and base station 106 operates as a target base station (T-BS). Initially, UE 102 attempts 550 to perform a DAPS handover to the T-BS, similar to DAPS handover attempt procedure 450. Before UE 102 successfully performs a random access procedure with T-BS 106, the UE detects 509 a synchronization problem in the radio connection with BS 104 (e.g., detects PHY layer out-of-sync) and starts 509 timer T310 for BS 104. After UE 102 starts timer T310 and before T310 expires, UE 102 detects 511 that timer T304 expires. According to existing standards, after detecting that timer T304 expires, UE 102 sends a FailureInformation message to indicate that the DAPS handover failed. However, in scenario 500, UE 102 checks whether timer T310 is running before sending the FailureInformation message. In response to timer T304 expiring while timer T310 is running, UE 102 decides 513 to abort the FailureInformation message transmission. In one particular implementation, UE 102 can stop 515 timer T310 in response to T304 expiring. UE then sends 519 an RRCReestablishmentRequest to BS 104 with a handoverFailure failure cause. In response, BS 104 or T-BS 106 performs 530 MRO based on the handover failure.

[0068] Accordingly, if UE 102 detects that timer T304 expires while timer T310 is running, UE 102 initiates a connection reestablishment procedure instead of initiating FailureInformation transmission. By initiating the reestablishment procedure, UE 102 is able to set a failure cause (e.g., reestablishmentCause) to indicate a handover failure (e.g., reestablishmentCause corresponding to handoverFailure). In this way, UE 102 informs the network of the DAPS handover failure, and in response, the network is able to perform network optimization or other suitable corrective actions.

[0069] In some implementations (not shown), the UE 102 performs cell selection to perform an RRC reestablishment procedure. The UE 102 can select a cell associated with a second BS, such as the T-BS 106, instead of the BS 104. After selecting a cell associated with the second BS, the UE 102 sends an RRCReestablishmentRequest to the second BS instead of sending the RRCReestablishmentRequest to the BS 104.

[0070] Next, Figure 6 A scenario 600 is shown in which the base station 104 operates as a source base station and the base station 106 operates as a target base station (T-BS). Initially, the UE 102 attempts 650 to perform a DAPS handover to the T-BS, similar to the DAPS handover attempt procedure 450. Before the UE 102 successfully performs a random access procedure with the T-BS 106, the UE 102 detects 610 expiration of the timer T304 and decides 610 to send a FailureInformation message to the BS 104 to indicate a DAPS failure. Later, a radio link failure (RLF) 614 interrupts transmission of the FailureInformation message, and the UE 102 fails to successfully send 616 the FailureInformation message to the BS 104. For example, if the UE 102 sets the failure cause to otherFailure or radio link failure after detecting failure to send the FailureInformation message, the base station 104 can incorrectly perform MRO. In the scenario 600, the UE 102 initiates a connection reestablishment procedure by indicating a failure cause corresponding to a handover failure. More specifically, the UE 102 sends 619 an RRCReestablishmentRequest message to the BS 104 with a cause of handoverFailure. Thus, the BS 104 or the T-BS 106 performs 630 MRO based on a handover failure instead of a later occurring RLF.

[0071] Thus, if the UE 102 detects a failure to deliver a FailureInformation message indicating a DAPS failure, the UE 102 initiates a connection reestablishment procedure by, for example, sending an RRCReestablishmentRequest with a failure cause of handoverFailure. In this way, the UE 102 informs the network of a DAPS handover failure, and in response, the network is able to perform network optimization or other suitable corrective action.

[0072] The UE 102 can detect 614 an RLF in several ways. For example, the UE 102 detects an RLF due to expiration of an out-of-sync timer T310 or a link establishment timer T312 for the BS 104. In some cases, the UE 102 can detect an RLF due to receiving a random access problem indication from the MAC layer for the BS 104, or due to receiving an indication from the RLC layer that the maximum number of retransmissions has been reached for the BS 104. If the UE 102 is connected as an integrated access and backhaul (IAB) node, the UE 102 can detect an RLF upon receiving a backhaul (BH) RLF indication on a backhaul adaptive protocol (BAP) entity from the BS 104. Further, the UE 102 can detect an RLF upon receiving an indication from the MAC layer of consistent uplink listen-before-talk (LBT) failures for the BS 104.

[0073] Next, Figure 7 A scenario 700 is shown in which the base station 104 operates as a source base station and the base station 106 operates as a target base station (T-BS). Initially, the UE 102 attempts 750 to perform a DAPS handover to the T-BS, similar to the DAPS handover attempt procedure 450. Before the UE 102 successfully performs a random access procedure with the T-BS 106, the UE 102 detects 710 expiration of the timer T304 and decides 710 to send a Failurelnformation message to the BS 104 to indicate a DAPS failure. The UE 102 then stores 712 DAPS handover failure information.

[0074] In one implementation, the UE 102 stores the handover failure information in VarRLF-Report. The UE 102 can store serving cell measurement results in the measResultLastServCell field, or store neighboring cell measurement results in the measResultNeighCells field of VarRLF-Report. The UE 102 can also store the identities (e.g., C-RNTI or PCI) of the BS 104 and the T-BS 106 in VarRLF-Report. To indicate a handover failure, the UE 102 sets the connectionFailureType field to “hof”.

[0075] Later, a radio link failure (RLF) (714) interrupts transmission of the Failurelnformation message, and the UE 102 fails to successfully transmit 716 the Failurelnformation message to the BS 104. In response to the RLF during the Failurelnformation transmission (i.e., the DAPS failure indication transmission), the UE 102 decides 718 not to store the RLF information and performs an RRC reestablishment procedure with the network. In one implementation, the UE 102 stores the RLF information in VarRLF-Report after the RLF, but does not set the connectionFailureType to “rlf” (e.g., by setting the connectionFailureType to “hof” or leaving the connectionFailureType to “hof”).

[0076] The UE 102 then transmits 720 an RRCReestablishmentRequest message with a cause of otherFailure to the BS 104. In response to the RRCReestablishmentRequest, the BS 104 transmits 722 an RRCReestablishment message to the UE 102. After receiving the RRCReestablishment message, the UE 102 transmits 724 an RRCReestablishmentComplete message including an indication (e.g., rlf-InfoAvailable) that handover failure information is available to the BS 104. In one implementation, the BS 104 transmits an RRCSetup message instead of an RRCReestablishment message to the UE 102. After receiving the RRCSetup message, the UE 102 transmits 724 an RRCSetupComplete message including an indication (e.g., rlf-InfoAvailable) that handover failure information is available to the BS 104.

[0077] In response to the indication that handover failure information is available, BS 104 can send 726 a UEInformationRequest message to request handover information (e.g., by including rlf-ReportReq in the UEInformationRequest). UE 102 then sends 728 a UEInformationResponse message to BS 104 to report the handover information (e.g., by including rlf-Report in the UEInformationResponse). The rlf-Report indicates that the connection failure was due to a handover failure (e.g., because the connectionFailureType field is set to hof rather than rlf). Thus, BS 104 or T-BS 106 performs 730 mobility robustness optimization based on the failure cause corresponding to the handover failure rather than an RLF that occurs later.

[0078] Figure 8-9 An example messaging sequence is shown that corresponds to a scenario in which base station 104 can support network optimization using the techniques of this disclosure.

[0079] Figure 8 A scenario 800 is shown in which base station 104 operates as a source base station and base station 106 operates as a target base station (T-BS). Initially, BS 104 attempts 850 to perform a DAPS handover to the T-BS, similar to DAPS handover attempt procedure 450. Before BS 104 receives a DAPS failure indication (e.g., a FailureInformation message) from UE 102 or a handover success indication (e.g., a HandoverSuccess message) from T-BS 106, BS 104 receives 820 an RRCReestablishmentRequest message from UE 102. The RRCReestablishmentRequest message that BS 104 receives 820 includes a failure cause corresponding to otherFailure, which generally indicates that UE 102 has detected an RLF. However, in scenario 800, because BS 104 receives the RRCReestablishmentRequest message 820 with cause otherFailure before receiving a DAPS handover success or failure indication, BS 104 determines that UE 102 detected a handover failure. As a result, BS 104 performs 830 MRO according to a failure cause corresponding to a handover failure (e.g., handoverFailure) rather than an RLF (e.g., the traditional otherFailure).

[0080] Figure 9A scenario 900 is shown in which the base station 104 operates as a source base station and the base station 106 operates as a target base station (T-BS). Initially, the BS 104 attempts 950 to perform a DAPS handover to the T-BS, similar to the DAPS handover attempt procedure 450. The UE 102 sends 921 an RRCReestablishmentRequest message to a second base station that is different from the BS 104, including the cause otherFailure. While Figure 9 The UE 102 sends 921 the RRCReestablishmentRequest message to the T-BS 106 is shown, but in some scenarios the UE 102 can send the message to another base station of the RAN. Event 921 is similar to event 820, except that the UE 102 sends 921 the RRCRestablishmentRequest message to a second base station instead of the source BS 104. In response, the second base station (e.g., the T-BS 106 in scenario 900) sends 929 a failure report (e.g., RLF INDICATION or FAILURE INDICATION) to the BS 104 including the failure cause otherFailure.

[0081] Similar to event 830, in response to receiving the otherFailure failure cause before receiving the DAPS handover success or failure indication, the BS 104 determines that the UE 102 detected a handover failure. As a result, the BS 104 performs 930 MRO according to a failure cause corresponding to a handover failure (e.g., handoverFailure) rather than an RLF (e.g., legacy OtherFailure).

[0082] To further clarify, Figure 10-14 A device operating in the system 100 of Figure 1 Devices operating in the system 100 can implement several example methods to support network optimization.

[0083] Figure 10 is a flowchart depicting an example method 1000 implemented in a UE (e.g., the UE 102) to indicate a DAPS failure to the network. For convenience, the method 1000 is discussed below with reference to the BS 104, the T-BS 106, and the UE 102 operating in the wireless communication system 100.

[0084] At block 1002, UE 102, operating in a connected mode with BS 104, detects an RLF (e.g., event 614 or 714). At block 1004, UE 102 determines whether it detected a DAPS handover failure to T-BS 106 prior to UE 102 detecting the RLF. If UE 102 did not detect a DAPS handover failure prior to detecting the RLF, flow proceeds to block 1008. At block 1008, UE 102 initiates an RRC reestablishment procedure with the network indicating that UE 102 detected an RLF (e.g., by sending an RRCReestablishmentRequest message to the base station including a failure cause of otherFailure).

[0085] If UE 102 detected a DAPS handover failure after detecting the RLF, flow proceeds to block 1006. At block 1006, UE 102 determines whether UE 102 has already reported the DAPS handover failure to BS 104 (e.g., has successfully sent a FailureInformation message with a daps-failure indication or an RRCReestablishmentRequest message with a cause of handoverFailure). If UE 102 has reported the DAPS handover failure, flow proceeds to block 1008, where UE 102 initiates an RRC reestablishment procedure to indicate that UE 102 detected an RLF. Otherwise, flow proceeds to block 1010, where UE 102 initiates an RRC reestablishment procedure based on a failure cause corresponding to the handover failure by, for example, sending an RRCReestablishmentRequest message to the base station including a failure cause of handoverFailure (e.g., event 619).

[0086] Figure 11 is a flow diagram depicting an example method 1100 implemented in a UE (e.g., UE 102) to indicate a DAPS failure to a network. For convenience, the method 1100 is discussed below with reference to BS 104, T-BS 106, and UE 102 operating in the wireless communication system 100.

[0087] At block 1102, the UE 102 operates in a connected mode with the BS 104 and detects a DAPS handover failure (e.g., timer T304 for DAPS handover expires) (e.g., events 511, 610, or 710). At block 1104, the UE 102 determines whether it detected an RLF in the radio connection with the BS 104 prior to the UE 102 detecting the DAPS handover failure. If the UE 102 previously detected an RLF, the flow proceeds to block 1106, where the UE 102 initiates an RRC reestablishment procedure based on a failure cause corresponding to the handover failure (e.g., by sending an RRCReestablishmentRequest message to the base station including the failure cause handoverFailure). Otherwise, the flow proceeds to block 1108.

[0088] At block 1108, the UE 102 determines whether timer T310 is running. If timer T310 is not running, the flow proceeds to 1110, where the UE 102 sends a FailureInformation message to the BS 104 indicating the DAPS failure. If timer T310 is running, the flow proceeds to block 1112.

[0089] At block 1112, the UE 102 aborts the FailureInformation message transmission (e.g., event 513). Next, at block 1114, the UE 102 stops timer T310 (e.g., event 515). At block 1116, the UE 102 initiates an RRC reestablishment procedure based on a failure cause corresponding to the handover failure (e.g., event 519).

[0090] Figure 12 is a flow diagram depicting an example method 1200 implemented in a UE (e.g., UE 102) to indicate a DAPS failure to a network. For convenience, the method 1200 is discussed below with reference to the BS 104, T-BS 106, and UE 102 operating in the wireless communication system 100.

[0091] At some time prior to block 1202, the UE 102 detects a DAPS handover failure (e.g., by detecting that timer T304 expires) (e.g., events 511, 610, or 710). At block 1202, the UE 102 decides to send a FailureInformation message to the BS 104 to indicate the DAPS handover failure (e.g., events 610 or 710). The UE 102 then attempts to send the FailureInformation message to the BS 104 (e.g., events 616 or 716). At block 1204, the UE 102 checks whether the transmission is successful. If the UE 102 successfully sends the FailureInformation message to the BS 104, the flow proceeds to block 1208, where the UE 102 does not initiate an RRC reestablishment procedure. If the UE 102 does not successfully send the FailureInformation to the BS 104, the flow proceeds to block 1206. In one example, the UE 102 does not successfully send the FailureInformation to the BS 104 because the UE 102 detects an RLF in the BS 104. At block 1206, the UE 102 initiates an RRC reestablishment procedure based on a failure cause corresponding to the handover failure (e.g., by sending an RRCReestablishmentRequest message including the failure cause handoverFailure to the base station) (e.g., event 619).

[0092] Figure 13 FIG. 13 is a flowchart depicting an example method 1300 implemented in a BS (e.g., BS 104) to support network optimization. For convenience, the method 1300 will be discussed below with reference to the BS 104, the T-BS 106, and the UE 102 operating in the wireless communication system 100.

[0093] At block 1302, the BS 104 receives, from the UE 102, an RRCReestablishmentRequest message with a failure cause indicating other failure or radio link failure (e.g., event 820). The BS 104 then checks 1304 whether the BS 104 previously transmitted a DAPS handover configuration to the UE 102 (e.g., as in event 406 of the DAPS handover attempt procedure 450). If not, the flow proceeds to block 1308, where the BS 104 performs network optimization based on the received failure cause. If the BS 104 transmitted a DAPS handover configuration to the UE 102, the flow proceeds to block 1306. At block 1306, the BS 104 checks whether it received an indication of DAPS handover success or failure prior to receiving the RRCReestablishmentRequest message. If so, the flow proceeds to block 1308. If not, the flow proceeds to block 1310, where the BS 104 performs network optimization as if the received failure cause was a handover failure (e.g., event 830).

[0094] Figure 14 FIG. 14 is a flow chart that depicts an example method 1400 implemented in a BS (e.g., BS 104) to support network optimization. For convenience, the method 1400 will be discussed with reference to the BS 104, the T-BS 106, and the UE 102 operating in the wireless communication system 100.

[0095] At block 1402, the BS 104 receives, from a second BS (e.g., T-BS 106), a failure report (e.g., RLF INDICATION message or FAILURE INDICATION message) indicating that the second base station initiated an RRC reestablishment procedure with the second BS (e.g., event 929). The failure report also indicates a failure cause of “other failure” or “radio link failure.” At block 1404, the BS 104 checks whether the BS 104 previously transmitted a DAPS handover configuration to the UE 102 (e.g., as in event 406 of the DAPS handover attempt procedure 450). If not, the flow proceeds to block 1408, where the BS 104 performs network optimization based on the received failure cause. If the BS 104 transmitted a DAPS handover configuration to the UE 102, the flow proceeds to block 1406. At block 1406, the BS 104 checks whether it received an indication of DAPS handover success or failure prior to receiving the failure report. If so, the flow proceeds to block 1408. If not, the flow proceeds to block 1410, where the BS 104 performs network optimization as if the received failure cause was a handover failure (e.g., event 930).

[0096] Figure 3-14Techniques are depicted for supporting improved error reporting and network optimization in DAPS handover scenarios. Figure 15-20 Similar techniques are depicted in an inter-RAT handover scenario (i.e., handover from a first RAT to a second RAT).

[0097] For context, Figure 15 A messaging sequence during an intra-RAT handover scenario 1500 is depicted, where base station 104 operates as a source base station and base station 106 operates as a target base station (T-BS). BS 104 and T-BS 106 are cells that use the same RAT (e.g., NR or EUTRA). Initially, UE 102 operates 1502 in a connected mode with BS 104. Later, BS 104 decides 1504 to handover UE 102 to T-BS 106. In response to the decision, BS 104 sends 1506 a handover request message (e.g., an RRCReconfiguration message or an RRCConnectionReconfiguration message) to UE 102. The handover request message includes at least one configuration that UE 102 can use to connect to a cell associated with T-BS 106. While this disclosure generally refers to a “handover,” it is sometimes also referred to as a reconfiguration with synchronization.

[0098] UE 102 receives 1506 the handover request message and determines 1508 that it is unable to apply the at least one configuration from the handover request message. In one example, UE 102 determines that it is unable to apply the configuration because UE 102 is unable to comply with any part of the configuration included in the handover request message. In another example, UE 102 is unable to apply the configuration due to a protocol error in the information included in the handover request message.

[0099] In response to the determination 1508, the UE 102 sends 1510 an RRCReestablishmentRequest (or RRCConnectionReestablishmentRequest) message with a failure cause indicating reconfiguration failure (e.g., reconfigurationFailure) to the BS 104. The BS 104 decides 1512 to perform a corresponding corrective action in response to the reconfiguration failure. In one example, the BS 104 can send 1514 a UECapabilityEnquiry message to the UE 102 to request the latest UE capability information. In response to the UECapabilityEnquiry, the UE 102 sends 1516 a UECapabilitylnformation message to the BS 104 to update its capabilities (e.g., UE-NR-Capability, UE-MRDC-Capability, or UE-EUTRA-Capability).

[0100] In another example, the BS 104 can include a UE parameter update transparent container in a DL NAS TRANSPORT message and send the message to the UE 102 to request the latest UE capability. In response to the DL NAS TRANSPORT message, the UE 102 can perform a registration procedure, a routing area update procedure, or a tracking area update procedure, or can send an UL NAS TRANSPORT message with the UE parameter update transparent container to the BS 104 to update its capabilities.

[0101] Figure 16-17 An example messaging sequence is shown corresponding to an inter-RAT handover failure scenario, where the UE 102 is able to support network optimization using the techniques of the present disclosure.

[0102] Figure 16An inter-RAT handover scenario 1600 is shown in which base station 104 operates as a source base station and base station 106 operates as a target base station (T-BS). BS 104 and T-BS 106 are associated with cells of different RATs (e.g., NR or EUTRA). In some scenarios, inter-RAT handover can involve a handover from a first cell to a second cell associated with the same base station but a different RAT. Initially, UE 102 operates 1602 in a connected mode with BS 104. At a later time, BS 104 decides 1604 to handover UE 102 to T-BS 106 associated with a different RAT. In response to the decision, BS 104 sends 1606 a handover request message to UE 102 (e.g., a MobilityFromNRCommand message for handover of UE 102 from NR to another RAT, or a MobilityFromEUTRACommand message for handover of UE 102 from EUTRA to another RAT). The handover request message includes at least one configuration that UE 102 can use to connect to the second cell associated with the different RAT.

[0103] UE 102 receives 1606 the handover request message and determines 1608 that it is unable to apply the at least one configuration from the handover request message. In one example, UE 102 determines that it is unable to apply the configuration because UE 102 is unable to comply with any part of the configuration included in the handover request message. In another example, UE 102 is unable to apply the configuration due to a protocol error in the information included in the handover request message.

[0104] In response to the determination 1608, UE 102 sends 1610 an RRCReestablishmentRequest (or RRCConnectionReestablishmentRequest) message to BS 104 with a failure cause indicating a reconfiguration failure (e.g., reconfigurationFailure). For example, UE 102 does not report a handover failure, but instead reports a reconfiguration failure to the network. More specifically, if UE 102 is initiating a reestablishment procedure due to a failure to comply with a configuration in the handover request, such as a MobilityFromEUTRACommand or MobilityFromNRCommand, UE 102 sets the failure cause (e.g., reestablishmentCause) to a value indicating a reconfiguration failure (e.g., reconfigurationFailure). In this way, UE 102 informs the network of the reconfiguration failure. And in response, the network can perform network optimization or other suitable corrective action.

[0105] The BS 104 decides 1612 to perform a corresponding corrective action in response to the reconfiguration failure. In one example corrective action (not shown), the BS 104 can send a UECapabilityEnquiry message to the UE 102 to request the latest UE capabilities. In response to the UECapabilityEnquiry, the UE 102 sends a UECapabilitylnformation message to the BS 104 to update its capabilities (e.g., UE-NR-Capability, UE-MRDC-Capability, UE-EUTRA-Capability, or INTERRAT HANDOVER INFO).

[0106] In another example corrective action (not shown), the BS 104 can include a UE parameter update transparent container in a DL NAS TRANSPORT message and send the message to the UE 102 to request the latest UE capabilities. In response to the DL NAS TRANSPORT message, the UE 102 can perform a registration procedure, a routing area update procedure, or a tracking area update procedure again, or can send an UL NAS TRANSPORT message with the UE parameter update transparent container to the BS 104 to update its capabilities.

[0107] Figure 17 A scenario 1700 is shown in which the base station 104 operates as a source base station and the base station 106 operates as a target base station (T-BS). The BS 104 and the T-BS 106 are associated with cells of different RATs (e.g., NR or EUTRA). In some scenarios, an inter-RAT handover can involve a handover from a first cell to a second cell associated with the same base station but a different RAT. Initially, the UE 102 operates 1702 in a connected mode with the BS 104. Later, the BS 104 decides 1704 to handover the UE to the T-BS 106 associated with a different RAT. In response to the decision, the BS 104 sends 1706 a handover request message (e.g., a MobilityFromNRCommand message or a MobilityFromEUTRACommand message) to the UE 102.

[0108] The UE 102 receives 1706 the handover request message and determines 1708 that it is unable to apply at least one configuration from the handover request message, similar to the determination 1608. In response to the determination 1708, the UE 102 determines 1709 that the handover failure information is not stored and sends 1711 an RRCReestablishmentRequest (or RRCConnectionReestablishmentRequest) message to the BS 104 that includes a failure cause corresponding to a handover failure (e.g., handoverFailure). After receiving the RRCReestablishmentRequest message from the UE 102, the BS 104 sends 1713 an RRCReestablishment message to the UE 102. In response to the RRCReestablishment message, the UE 102 sends 1715 an RRCReestablishmentComplete message to the BS 104. The RRCReestablishmentComplete message does not include an indication that handover failure information is available because the UE 102 did not store the handover failure information at event 1709. In one example, the UE 102 does not include rlf-InfoAvailable in the RRCReestablishmentComplete message. In another example, the UE 102 includes rlf-InfoAvailable in the RRCReestablishmentComplete message but does not set connectionFailureType to “hof” (e.g., the UE 102 is able to set connectionFailureType to “rlf”).

[0109] In some implementations, the BS 104 sends an RRCSetup message instead of an RRCReestablishment message at event 1713 and an RRCSetupComplete message to the BS 104 at event 1715. The RRCSetupComplete message does not include an indication that handover failure information is available.

[0110] Because the message received 1715 by the BS 104 indicates that there is no available handover failure information, the BS 104 determines 1717 that the UE 102 detected a reconfiguration failure and decides 1717 to perform a corrective action based on the determination. For example, the BS 104 can send 1719 a UECapabilityEnquiry message to the UE 102 to request the latest UE capabilities. In response to the UECapabilityEnquiry message, the UE 102 sends 1721 a UECapabilityInformation message to the BS 104 to update its capabilities (e.g., UE-NR-Capability, UE-MRDC-Capability, UE-EUTRA-Capability, or INTER RAT HANDOVER INFO).

[0111] In another example, the BS 104 can include a UE parameter update transparent container in a DL NAS TRANSPORT message and send the message to the UE 102 to request the latest UE capabilities. In response to the DL NAS TRANSPORT message, the UE 102 can perform a registration procedure, a routing area update procedure, or a tracking area update procedure, or can send an UL NAS TRANSPORT message with the UE parameter update transparent container to the BS 104 to update its capabilities.

[0112] To further clarify, Figure 18-20 Devices operating in the system 100, shown in Figure 1 Devices operating in the system 100, shown in

[0113] Figure 18 is a flow diagram depicting an example method 1800 that can be implemented in a UE (e.g., the UE 102) to indicate a reconfiguration failure to a network. For convenience, the method 1800 will be discussed below with reference to the BS 104, the T-BS 106, and the UE 102 operating with the wireless communication system 100.

[0114] At some time prior to block 1802, the UE 102 receives a handover request including a configuration for the UE 102 to connect to a cell associated with the T-BS 106 (e.g., event 1606 or 1706). At block 1802, the UE 102 determines that it cannot complete the inter-RAT handover from the BS 104 to the T-BS 106 and decides to initiate an RRC reestablishment procedure (e.g., event 1608 or 1708). At block 1804, the UE 102 checks whether a timer T304 has expired. The UE 102 previously started the timer T304 when it attempted to connect to the T-BS 106. If the timer T304 has expired, the flow proceeds to block 1808 where the UE 102 initiates an RRC reestablishment by sending an RRCReestablishmentRequest including a failure cause handoverFailure. If the timer T304 has not expired, the flow proceeds to block 1806. At block 1806, the UE 102 determines that the failure to complete the inter-RAT handover is due to a failure to apply the configuration associated with the T-BS 106 and initiates an RRC reestablishment procedure by sending an RRCReestablishmentRequest including a failure cause reconfigurationFailure (e.g., event 1610).

[0115] Figure 19 is a flow diagram depicting an example method 1900 implemented in a UE (e.g., UE 102) to indicate a reconfiguration failure to a network. For convenience, the method 1900 is discussed below with reference to the BS 104, T-BS 106, and UE 102 operating in the wireless communication system 100.

[0116] At some time prior to block 1902, the UE 102 receives a handover request that includes a configuration for the UE 102 to use to connect to a cell associated with the T-BS 106 (e.g., event 1606 or 1706). At block 1902, the UE 102 determines that it is unable to complete the inter-RAT handover from the BS 104 to the T-BS 106 and decides to initiate an RRC reestablishment procedure (e.g., event 1608 or 1708). At block 1904, the UE 102 determines whether the UE 102 is unable to apply the configuration in the handover request. If so, the flow proceeds to block 1906, where the UE 102 initiates the RRC reestablishment procedure by sending an RRCReestablishmentRequest that includes a failure cause of reconfigurationFailure (e.g., event 1610). Otherwise, the flow proceeds to block 1908, where the UE 102 initiates the RRC reestablishment procedure by sending an RRCReestablishmentRequest that includes a failure cause of handoverFailure.

[0117] Figure 20 is a flowchart depicting an example method 2000 implemented in a BS (e.g., BS 104) to support network optimization. For convenience, the method 2000 is discussed below with reference to the BS 104, the T-BS 106, and the UE 102 operating in the wireless communication system 100.

[0118] At some time prior to block 2002, the BS 104 receives an RRCReestablishmentRequest from the UE 102 and, in response, sends an RRCReestablishment message or an RRCSetup message to the UE 102 (e.g., events 1711 and 1713). At block 2002, the BS 104 receives an RRCReestablishmentComplete or an RRCsetupComplete from the UE 102 (e.g., event 1715). Next, at block 2004, the BS 104 checks whether the RRCReestablishmentComplete message or the RRCsetupComplete message includes an indication that handover failure information is available. If so, the flow proceeds to block 2006, where the BS 104 performs network optimization based on a failure cause corresponding to a handover failure (e.g., handoverFailure). Otherwise, the flow proceeds to block 2008.

[0119] At block 2008, BS 104 checks whether the failure reason received in the previous RRCReestablishmentRequest corresponds to a handover failure. If the failure reason is not a handover failure, the process proceeds to block 2010, where BS 104 performs network optimization based on the received reason (e.g., optimizing the RLF if the reason is otherFailure or RLF). If the reason is a handover failure, the process proceeds to block 2012. At block 2012, BS 104 determines that UE 102 detected a reconfiguration failure (e.g., event 1717). In response to this determination, BS 104 is able to perform corrective actions to resolve the reconfiguration failure (e.g., event 1719).

[0120] Figure 21-24 In DAPS handover failure scenarios or RAT handover failure scenarios, Figure 1 The flowchart shows an example method for supporting network optimization that the devices operating in System 100 can implement.

[0121] Figure 21 This is a flowchart of an example method 2100 for supporting DAPS handover, which can be implemented in a UE (e.g., UE 102) of this disclosure as a set of instructions stored on a computer-readable medium and executable by processing hardware (e.g., processing hardware 150). The UE is initially connected to a first base station (e.g., BS 104) of the RAN.

[0122] At block 2102, the UE attempts to connect to a second base station (e.g., BS 106 as a T-BS operation) during a DAPS handover (e.g., events 550, 650, 750, 850, 950). At block 2104, the UE detects a potential failure associated with the radio connection to the first base station (e.g., events 509, 614, or 714). For example, the UE may detect a synchronization problem and start timer T310, or the UE may detect an RLF. At block 2106, the UE detects a failure to connect to the second base station (e.g., a DAPS handover failure or a reconfiguration with a SYNC failure) (e.g., events 511, 610, or 710). Depending on the implementation and / or scenario, blocks 2104 and 2106 may occur in different orders. At block 2108, the UE initiates a process to re-establish the radio connection, which includes providing an indication of connection failure to the RAN (e.g., to BS 104 or T-BS 106) (e.g., by initiating an RRC re-establishment process by sending an RRCReestablishmentRequest that includes the failure reason corresponding to handoverFailure) (e.g., event 519 or 619).

[0123] Figure 22is a flowchart of an example method 2200 for network optimization that can be implemented in a base station (e.g., BS 104) of the present disclosure as a set of instructions stored on a computer-readable medium and executable by processing hardware (e.g., processing hardware 130).

[0124] At block 2202, the base station transmits a configuration that the UE is to connect to a second base station (e.g., BS 106 operating as a T-BS) during a DAPS handover procedure (e.g., event 406 of DAPS handover attempt procedure 450, or any of procedures 550, 650, 750, 850, or 950) in accordance with. At block 2204, the base station receives an indication that the UE detected a failure of a radio link (e.g., event 820 or 929). At block 2206, the base station determines that the UE detected a failure of the connection to the second base station. Next, at block 2208, the base station performs a network optimization procedure (e.g., MRO) based on the determination (e.g., event 830 or 930).

[0125] Figure 23 is a flowchart of an example method 2300 for supporting inter-RAT handover that can be implemented in a UE (e.g., UE 102) of the present disclosure as a set of instructions stored on a computer-readable medium and executable by processing hardware (e.g., processing hardware 150). The UE is initially connected to a first cell associated with a first RAT (e.g., cell 124 associated with BS 104).

[0126] At block 2302, the UE attempts to connect to a second cell associated with a second RAT (e.g., cell 126 associated with BS 106) (e.g., in response to receiving a request in event 1606 or 1706). At block 2304, the UE detects a failure to apply a configuration associated with the second cell (e.g., event 1608 or 1708). At block 2306, the UE provides an indication of the failure to apply the configuration via the first cell (e.g., by sending an RRCReestablishmentRequest with a failure cause corresponding to a reconfiguration failure to initiate an RRC reestablishment procedure) (e.g., event 1610).

[0127] Figure 24 is a flowchart of an example method 2400 for supporting inter-RAT handover that can be implemented in a base station (e.g., BS 104) of the present disclosure as a set of instructions stored on a computer-readable medium and executable by processing hardware (e.g., processing hardware 130). The base station is associated with a first cell of a first RAT (e.g., cell 124).

[0128] At block 2402, the base station transmits, to a UE, a request to connect to a second cell of a second RAT, the request including a configuration that the UE is to use to connect to the second cell (e.g., event 1606 or 1706). At block 2404, the base station receives, from the UE, a request to reestablish a radio connection, the request including a failure cause indicating a handover failure (e.g., event 1711). Next, at block 2406, the base station transmits a message to configure a radio connection with the UE (e.g., event 1713). At block 2408, the base station receives a response to the message, the response indicating that handover failure information is not available (e.g., event 1715). In response, at block 2410, the base station determines that the UE is unable to apply the configuration (e.g., event 1717). At block 2412, the base station performs a corrective action in response to the determination (e.g., event 1719).

[0129] Depending on the implementation and / or scenario, a UE (e.g., UE 102) can perform a combination of the techniques disclosed above (e.g., a combination of methods 2100 and 2300). For example, while performing method 2300, the UE 102 can detect a potential failure of a radio connection associated with a first cell. Similarly, a base station (e.g., BS 104) can perform a combination of the techniques disclosed above (e.g., a combination of methods 2200 and 2400).

[0130] The following list of examples reflects various embodiments that are expressly contemplated by the present disclosure:

[0131] Example 1: A method for supporting dual active protocol stack (DAPS) handover in a user equipment (UE) connected to a first base station of a radio access network (RAN), the method comprising: attempting, by processing hardware, to connect to a second base station of the RAN during a DAPS handover; detecting, by the processing hardware, a potential failure associated with a radio connection to the first base station; detecting, by the processing hardware, a failure to connect to the second base station; and initiating, by the processing hardware, a procedure to reestablish the radio connection, the initiating including providing an indication of the connection failure to the RAN.

[0132] Example 2: The method of example 1, wherein detecting the potential failure comprises detecting the potential failure prior to detecting the failure to connect to the second base station.

[0133] Example 3: The method of example 2, wherein detecting the potential failure comprises detecting a synchronization error related to the radio connection.

[0134] Example 4: The method of any one of examples 2-3, further comprising: starting, by the processing hardware, a timer in response to detecting the potential failure; and wherein detecting the failure to connect to the second base station comprises detecting the failure to connect to the second base station while the timer is running.

[0135] Example 5: The method of example 4, further comprising: stopping, by the processing hardware, the timer in response to detecting a failure to connect to the second base station.

[0136] Example 6: The method of example 2, wherein detecting the potential failure comprises: detecting a radio link failure with the first base station prior to detecting the failure to connect to the second base station.

[0137] Example 7: The method of example 1, wherein detecting the potential failure comprises: detecting a radio link failure with the first base station after detecting the failure to connect to the second base station and prior to reporting the failure to connect to the second base station to the first base station.

[0138] Example 8: The method of example 7, wherein detecting the radio link failure comprises: detecting a failure to successfully transmit a dedicated message for reporting the connection failure.

[0139] Example 9: The method of any of examples 1-8, wherein providing the indication comprises: transmitting a request to reestablish a radio connection, the request indicating the handover failure as a failure cause.

[0140] Example 10: The method of any of examples 1-9, wherein detecting the connection failure comprises: detecting a DAPS handover failure.

[0141] Example 11: A method of network optimization in a first base station for communicating with a user equipment (UE) via a radio link, the method comprising: transmitting, by processing hardware, a configuration that the UE is to connect to a second base station during a dual active protocol stack (DAPS) handover procedure in accordance with the configuration; receiving, by the processing hardware, an indication that the UE detected a radio link failure; determining, by the processing hardware, that the UE detected a failure to connect to the second base station; and performing, by the processing hardware, a network optimization procedure based on the determination.

[0142] Example 12: The method of example 11, wherein receiving the indication comprises: receiving, from the UE, a request to reestablish a radio connection by the UE, the request including a radio link failure as a failure cause.

[0143] Example 13: The method of example 11, wherein receiving the indication comprises: receiving, from the second base station, an indication that the second base station received a request to reestablish a radio connection by the UE, the request including a radio link failure as a failure cause.

[0144] Example 14: The method of any of examples 11-13, wherein determining that the UE detected the failure to connect to the second base station comprises: receiving the indication that the UE detected the radio link failure prior to receiving an indication that the UE completed the DAPS handover or the DAPS handover failed.

[0145] Example 15: The method of any of examples 11-14, wherein performing network optimization comprises performing mobility robustness optimization (MRO).

[0146] Example 16: The method of any of examples 11-15, wherein transmitting the configuration comprises transmitting the configuration in a message that conforms to a protocol for controlling radio resources.

[0147] Example 17: A method in a user equipment (UE) connected to a first cell associated with a first radio access technology (RAT) for supporting handover to a second cell associated with a second RAT, the method comprising: attempting, by processing hardware, to connect to the second cell; detecting, by the processing hardware, that applying a configuration associated with the second cell failed; and providing, by the processing hardware, an indication of the failure to apply the configuration via the first cell.

[0148] Example 18: The method of example 17, wherein providing the indication comprises transmitting a request to reestablish a radio connection, the request including a failure cause indicating the reconfiguration failed.

[0149] Example 19: The method of any of examples 17-18, wherein detecting the failure comprises determining that the UE is unable to apply the configuration.

[0150] Example 20: The method of any of examples 17-18, wherein detecting the failure comprises starting a timer in response to attempting to connect to the second cell; and determining that the UE is unable to connect to the second cell before the timer expires.

[0151] Example 21: The method of any of examples 17-20, further comprising receiving, by the processing hardware, the configuration associated with the second cell in a handover request message.

[0152] Example 22: The method of example 21, wherein receiving the configuration comprises receiving the configuration in a MobilityFromNRCommand or a MobilityFromEUTRACommand.

[0153] Example 23: The method of any of examples 17-22, wherein the first cell and the second cell are associated with different base stations.

[0154] Example 24: The method of any of examples 17-23, further comprising detecting, by the processing hardware, a potential failure of a radio connection associated with the first cell.

[0155] Example 25: A user equipment (UE) comprising processing hardware and configured to implement a method as described in any of examples 1-10 or 17-24.

[0156] Example 26: A method for supporting inter-radio access technology (RAT) handover in a base station of a first cell supporting a first RAT, the method comprising: sending, by processing hardware and to a user equipment (UE), a request for the UE to connect to a second cell of a second RAT, the request including a configuration for the UE to use to connect to the second cell; receiving, by the processing hardware and from the UE, a request to reestablish a radio connection, the request including a failure cause indicating a handover failure; sending, by the processing hardware, a message to configure a radio connection with the UE; receiving, by the processing hardware, a response to the message, the response indicating that handover failure information is not available; determining, by the processing hardware and based on the response, that the UE is unable to apply the configuration; and performing, by the processing hardware and in response to the determination, a corrective action.

[0157] Example 27: The method of example 26, wherein performing the corrective action comprises sending, to the UE, a request for capability information associated with the UE.

[0158] Example 28: The method of any of examples 26-27, wherein sending the message to configure the radio connection comprises sending a message to reestablish the radio connection with the UE.

[0159] Example 29: The method of any of examples 26-27, wherein sending the message to configure the radio connection comprises sending a message to establish a new radio connection with the UE.

[0160] Example 30: The method of any of examples 26-29, wherein the first cell and the second cell are associated with different base stations.

[0161] Example 31: A base station comprising processing hardware and configured to implement a method as described in any of examples 11-16 or 26-30.

[0162] The following description can apply to the above description.

[0163] In some implementations, the RRCReconfiguration message can be an RRCConnectionReconfiguration message, and the RRCReconfigurationComplete can be an RRCConnectionReconfigurationComplete message.

[0164] In some implementations, the RRCReconfiguration can be generated by the BS 104 or the T-BS 106. In some implementations, the RRCReestablishmentRequest message can be an RRCConnectionReestablishmentRequest message, the RRCReestablishment message can be an RRCConnectionReestablishment message, and the RRCReestablishmentComplete can be an RRCConnectionReestablishmentComplete message.

[0165] In some implementations, one or more configurations for the UE 102 to perform a random access procedure can configure a 2-step random access. In another implementation, the random access configuration can configure a 4-step random access. In yet another implementation, the random access configuration can configure a contention-based random access or a contention-free random access. The UE 102 can send an RRCReconfigurationComplete or an RRCReestablishmentRequest message to a cell in the random access procedure or after successfully completing the random access procedure. The cell that receives the RRCReestablishmentRequest can be the same or different from the cell that the UE detected the RLF.

[0166] A user equipment (e.g., the UE 102) that can implement techniques of the present disclosure can be any suitable device capable of wireless communication, such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, in some cases, the user equipment can be embedded in an electronic system, such as a head unit of a vehicle or an advanced driver assistance system (ADAS). Further, the user equipment can operate as an Internet of Things (IoT) device or a mobile internet device (MID). Depending on the type, the user equipment can include one or more general-purpose processors, computer-readable memory, a user interface, one or more network interfaces, one or more sensors, and the like.

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

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

[0169] The present disclosure also contemplates the following additional considerations.

[0170] TS 38.331 v16.0.0 can be modified as follows:

[0171] 5.3.5.8.3 T304 expiry (reconfiguration with synch failure)

[0172] The UE shall:

[0173] 1> if T304 expires for the MCG:

[0174] 2> if configured, release the dedicated preamble provided in rach-ConfigDedicated;

[0175] 2> if configured, release the dedicated msgA PUSCH resource provided in rach-ConfigDedicated;

[0176] 2> store the following switch failure information in VarRLF-Report by setting its fields as follows:

[0177] 3> clear the information included in VarRLF-Report, if any;

[0178] 3> set plmn-IdentityList to include the list of EPLMNs stored by the UE (i.e., including the RPLMN);

[0179] 3> set measResultLastServCell to include RSRP, RSRQ and available SINR of the source PCell based on available SSB and CSI-RS measurements collected until the moment the UE detected the handover failure;

[0180] 3> set ssbRLMConfigBitmap and / or csi-rsRLMConfigBitmap in measResultLastServCell to include the radio link monitoring configuration of the source PCell;

[0181] 3> for each configured measObjectNR for which measurements are available;

[0182] 4> if SSB-based measurement quantities are available;

[0183] 5> set measResultListNR in measResultNeighCells to include all available measurement quantities of the best measured cells associated with the measObjectNR excluding the source PCell, ordered such that if SSB RSRP measurement results are available, the cell with highest SSB RSRP is listed first, else if SSB RSRQ measurement results are available, the cell with highest SSB RSRQ is listed first, else the cell with highest SSB SINR is listed first, based on available SSB-based measurements collected until the moment the UE detected the handover failure;

[0184] 6> include available optional fields for each included neighbour cell;

[0185] 4> if CSI-RS-based measurement quantities are available;

[0186] 5> set measResultListNR in measResultNeighCells to include all available measurement quantities of the best measured cells excluding the source PCell, ordered such that if CSI-RS RSRP measurement results are available, the cell with highest CSI-RS RSRP is listed first, else if CSI-RS RSRQ measurement results are available, the cell with highest CSI-RS RSRQ is listed first, else the cell with highest CSI-RS SINR is listed first, based on available CSI-RS-based measurements collected until the moment the UE detected the handover failure;

[0187] 6> include available optional fields for each included neighbour cell;

[0188] 3> for each configured EUTRA frequency for which measurements are available;

[0189] 4> based on the measurements collected until the moment the UE detected the radio link failure, set the measResultListEUTRA in measResultNeighCells to include the best measured cell, ordered such that if RSRP measurement results are available, the cell with highest RSRP is listed first, otherwise the cell with highest RSRQ is listed first;

[0190] 5> for each included neighbouring cell, include the optional fields available;

[0191] NOTE 0: When configured in the mobility measurement configuration, the measured quantities are filtered by a L3 filter. The measurements are based on the time domain measurement resource restrictions, if configured. Blacklisted cells do not need to be reported.

[0192] 3> if detailed location information is available, set the contents of Locationlnfo as follows:

[0193] 4> if available, set commonLocationlnfo to include the detailed location information;

[0194] 4> if available, set bt-Locationlnfo to include the Bluetooth measurement results in decreasing order of RSSI of the Bluetooth beacons;

[0195] 4> if available, set wlan-Locationlnfo to include the WLAN measurement results in decreasing order of RSSI of the WLAN APs;

[0196] 4> if available, set sensor-Locationlnfo to include the sensor measurement results;

[0197] 3> if available, set failedPcellld to the global cell identity and tracking area code, otherwise to the physical cell identity and carrier frequency of the target Pcell of the failed handover;

[0198] 3> in case the last RRCReconfiguration message including reconfigurationWithSync was received, include previousPCellld and set it to the global cell identity and tracking area code of the PCell;

[0199] 3> set timeConnFailure to the time elapsed since the reception of the last RRCReconfiguration message including reconfigurationWithSync;

[0200] 3> set connectionFailureType to hof;

[0201] 3> set c-RNTI to the C-RNTI used in the source PCell;

[0202] 3> set absoluteFrequencyPointA to the absolute frequency indicating the reference resource block associated with the random access resource;

[0203] 3> set locationAndBandwidth and subcarrierSpacing associated with the UL BWP of the random access resource;

[0204] 3> set msg1-FrequencyStart, msg1-FDM and msg1-SubcarrierSpacing associated with the random access resource;

[0205] 3> set perRAInfoList to indicate the random access failure information as specified in 5.3.10.3;

[0206] 2> if dapsConfig is configured for any DRB, radio link failure is not detected in the source PCell according to subclause 5.3.10.3, and T310 is not running :

[0207] 3> release the target PCell configuration;

[0208] 3> reset the target MAC and release the target MAC configuration;

[0209] 3> for each DRB with DAPS PDCP entity:

[0210] 4> release the target's RLC entity and associated logical channel;

[0211] 4> reconfigure the PDCP entity to normal PDCP as specified in TS 38.323 [5];

[0212] 3> for each SRB:

[0213] 4> if masterKeyUpdate is not received:

[0214] 5> configure the source PDCP entity with the same state variables as the target's PDCP entity;

[0215] 4> release the target's PDCP entity;

[0216] 4> release the target's RLC entity and associated logical channel;

[0217] 3> release the target's physical channel configuration;

[0218] 3> restore the SDAP configuration used in the source;

[0219] 3> discard the keys (K gNB key, S-K gNB key, S-K eNB key, K RRCenc key, K RRCint key, K UPint key, and K UPenc key), if any;

[0220] 3> resume the suspended SRB in the source;

[0221] 3> for each DRB that does not have a DAPS PDCP entity:

[0222] 4> restore the UE configuration used in the source for the DRB, including PDCP, RLC state variables, security configuration, and data stored in the transmission and reception buffers of the PDCP and RLC entities;

[0223] 3> restore the UE RRM configuration used in the source;

[0224] 3> initiate the failure information procedure as specified in sub-clause 5.7.5 to report the DAPS handover failure.

[0225] 2> else:

[0226] 3> restore the UE configuration used in the source PCell;

[0227] 3> initiate the connection re-establishment procedure as specified in sub-clause 5.3.7.

[0228] NOTE 1: In the above context, "UE configuration" includes state variables and parameters for each radio bearer.

[0229] 1> else if T304 of the secondary cell group expires:

[0230] 2> if MCG transmission is not suspended:

[0231] 3> if configured, release the dedicated preamble provided in rach-ConfigDedicated;

[0232] 3> initiate the SCG failure information procedure as specified in sub-clause 5.7.3 to report SCG reconfiguration with SYNC failure, at which point the RRC reconfiguration procedure ends;

[0233] 2> else:

[0234] 3> initiate the connection re-establishment procedure as specified in sub-clause 5.3.7;

[0235] 1> else if T304 expires when RRCReconfiguration is received via other RAT (HO to NR failure):

[0236] 2> reset MAC;

[0237] 2> perform the actions defined for this failure case as defined in the specifications applicable for the other RAT.

[0238] TS 38.331 v16.0.0 can also be modified as follows:

[0239] 5.7.5.x Failure to deliver FailureInformation message

[0240] The UE shall :

[0241] 1> if FailureInformation is initiated to provide DAPS failure information:

[0242] 2> initiate the connection re-establishment procedure as specified in 5.3.7;

[0243] 1> else:

[0244] 2> perform the radio link failure related actions specified in 5.3.10.

[0245] 5.3.7.4 Actions related to transmission of the RRCReestablishmentRequest message

[0246] The UE shall set the content of the RRCReestablishmentRequest message as follows:

[0247] …

[0248] 1> set the reestablishmentCause as follows:

[0249] 2> if the re-establishment procedure was initiated due to reconfiguration failure as specified in 5.3.5.8.2:

[0250] 3> set reestablishmentCause to the value reconfigurationFailure;

[0251] 2> else if the re-establishment procedure was initiated due to reconfiguration with sync failure as specified in 5.3.5.8.3 (Intra-NR handover failure) or 5.4.3.5 (Inter-RAT mobility from NR failure) or 5.7.5.x (Failure to deliver FailureInformation)

[0252] 3> set reestablishmentCause to the value handoverFailure;

[0253] 2> else:

[0254] 3> set reestablishmentCause to the value otherFailure;

[0255] TS 38.331 v16.0.0 can also be modified as follows:

[0256] 5.3.7.4 Actions related to transmission of RRCReestablishmentRequest message

[0257] The UE shall set the content of the RRCReestablishmentRequest message as follows:

[0258] …

[0259] 1> set reestablishmentCause as follows:

[0260] 2> if the re-establishment procedure was initiated due to reconfiguration failure as specified in 5.3.5.8.2 or 5.4.3.5:

[0261] 3> set reestablishmentCause to the value reconfigurationFailure;

[0262] 2> else if the re-establishment procedure was initiated due to reconfiguration with sync failure as specified in 5.3.5.8.3 (Intra-NR handover failure) or 5.4.3.5 (Inter-RAT mobility from NR failure):

[0263] 3> set reestablishmentCause to the value handoverFailure;

[0264] 2> else:

[0265] ​3> set the reestablishmentCause to the value otherFailure;

[0266] TS 36.331 can also be modified as follows:

[0267] 5.3.7.4 Actions related to transmission of RRCConnectionReestablishmentRequest message Except for NB-IoT, if the procedure is initiated due to radio link failure or handover failure, the UE shall:

[0268] 1> set the reestablishmentCellId in VarRLF-Report to the global cell identity of the selected cell;

[0269] Editor's note: FFS: The reestablishmentCellId is also included in the RLF report for NB-IoT.

[0270] The UE shall set the content of the RRCConnectionReestablishmentRequest message as follows:

[0271] …

[0272] 1> set the reestablishmentCause as follows:

[0273] 2> if the re-establishment procedure is initiated due to reconfiguration failure as specified in 5.3.5.5 (UE fails to comply with reconfiguration) or 5.4.3.5 (UE cannot comply with MobilityFromeUTRACommand) in 5.3.5.5 (UE fails to comply with reconfiguration)

[0274] 3> set the reestablishmentCause to the value reconfigurationFailure;

[0275] 2> else if the re-establishment procedure is initiated due to handover failure as specified in 5.3.5.6 (Intra LTE handover failure) or 5.4.3.5 (Inter RAT mobility failure from EUTRA)

[0276] in 5.4.3.5 (Inter RAT mobility failure from EUTRA)

[0277] 3> set the reestablishmentCause to the value handoverFailure;

[0278] 2> else:

[0279] 3> set the reestablishmentCause to the value otherFailure;

Claims

1. A method for supporting handover to a second cell associated with a second RAT in a user equipment (UE) connected to a first cell associated with a first radio access technology (RAT), the method comprising: The UE receives the configuration associated with the second cell in the handover request message; The UE attempts to connect to the second cell; The configuration associated with the second cell by the UE detection application failed; The UE sends a request to the first cell to re-establish the radio connection, the request including an indication of the reason for the reconfiguration failure; The UE receives a message for configuring the radio connection with the first cell; The UE sends a response to the message, the response indicating whether the handover failure information is available.

2. The method according to claim 1, wherein, Failed detections include: It was determined that the UE could not apply the configuration.

3. The method according to claim 1 or 2, wherein, Failed detections include: A timer is started in response to an attempt to connect to a second cell; and It was determined that the UE could not connect to the second cell before the timer expired.

4. The method according to any one of claims 1-3, wherein, Receiving the configuration includes receiving the configuration in MobilityFromNRCommand or MobilityFromEUTRACommand.

5. The method according to any one of claims 1-4, wherein, The first and second cells are associated with different base stations.

6. The method according to any one of claims 1-5, further comprising: The UE detects potential failures in the radio connection associated with the first cell.

7. The method according to any one of claims 1-6, wherein, Sending the request includes: Send a Radio Resource Control (RRC) Reconstruction Request message that includes the reason for the ReconfigurationFailure.

8. A user equipment (UE) including processing hardware and configured to implement the method according to any one of claims 1-7.

9. A method for supporting handover between Radio Access Technologies (RATs) in a base station, the base station supporting a first cell of a first RAT, the method comprising: The base station sends a request to the user equipment (UE) for the UE to connect to a second cell of the second RAT, the request including the configuration that the UE will use to connect to the second cell; The base station receives a request from the UE to re-establish the radio connection, the request including an indication of the reason for the handover failure; The base station sends messages to configure the radio connection with the UE; The base station receives a response to the message, and the response indicates that the handover failure information is unavailable; The base station determines that the UE cannot apply the configuration based on the response; as well as The base station performs a correction action in response to the determination.

10. The method according to claim 9, wherein, The execution of the correction action includes: Send a request to the UE for capability information associated with the UE.

11. The method according to claim 9 or 10, wherein, The transmission of messages used to configure the radio connection includes: Send a message to re-establish the radio connection with the UE.

12. The method according to any one of claims 9-11, wherein, The transmission of messages used to configure the radio connection includes: Send a message to establish a new radio connection with the UE.

13. The method according to claim 9, wherein, The first and second cells are associated with different base stations.

14. A base station, including processing hardware and configured to implement the method according to any one of claims 9-13.

Images