WO2021202216A1

WO2021202216A1 - Dual active protocol stack operation and full configuration

Info

Publication number: WO2021202216A1
Application number: PCT/US2021/024030
Authority: WO
Inventors: Chih-Hsiang Wu
Original assignee: Google Llc
Priority date: 2020-04-02
Filing date: 2021-03-25
Publication date: 2021-10-07

Abstract

A radio access network (RAN) capable of providing a full configuration related to a radio connection to a user device (UE) and a delta configuration which the UE can apply to a previously received configuration determines, while the UE is operating in a cell using the previously received configuration, to provide the full configuration to the UE for a dual active protocol stack (DAPS) procedure (1202). In some implementations, the RAN identifies at least a target cell for the full configuration (1204). In some implementations, the RAN transmits the full configuration to the UE, to cause the UE to execute the DAPS procedure to communicate via the target cell using the full configuration (1206).

Description

DUAL ACTIVE PROTOCOL STACK OPERATION AND FULL CONFIGURATION

FIELD OF THE DISCLOSURE

[0001] This disclosure relates generally to wireless communications and, more particularly, to dual active protocol stack (DAPS) operations related to handover and primary secondary cell (PSCell) change procedures, as well as full configuration.

BACKGROUND

[0002] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may 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] In telecommunication systems, 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 specification TS 36.323) and New Radio (NR) (see 3GPP specification TS 38.323) provides sequencing of protocol data units (PDUs) in the uplink direction (from a user device, also known as a user equipment (UE), to a base station) as well as in the downlink direction (from the base station to the UE). Further, the PDCP sublayer provides services for signaling radio bearers (SRBs) to the Radio Resource Control (RRC) sublayer. The PDCP sublayer also provides services for data radio bearers (DRBs) to a Service Data Adaptation Protocol (SDAP) sublayer or a protocol layer such as an Internet Protocol (IP) layer, an Ethernet protocol layer, and an Internet Control Message Protocol (ICMP) layer. Generally speaking, the UE and a base station can use SRBs to exchange RRC messages as well as non-access stratum (NAS) messages, and can use DRBs to transport data on a user plane.

[0004] UEs can use several types of SRBs and DRBs. When operating in dual connectivity (DC), the cells associated with the base station operating as the master node (MN) define a master cell group (MCG), and the cells associated with the base station operating as the secondary node (SN) define the secondary cell group (SCG). So-called SRB1 resources carry RRC messages, which in some cases include NAS messages over the dedicated control channel (DCCH), and SRB2 resources support RRC messages that include logged measurement information or NAS messages, also over the DCCH but with lower priority than SRB1 resources. More generally, SRB1 and SRB2 resources allow the UE and the MN to exchange RRC messages related to the MN and embed RRC messages related to the SN, and also can be referred to as MCG SRBs. SRB3 resources allow the UE and the SN to exchange RRC messages related to the SN, and can be referred to as SCG SRBs. Split SRBs allow the UE to exchange RRC messages directly with the MN via lower layer resources of the MN and the SN. Further, DRBs terminated at the MN and using the lower- layer resources of only the MN can be referred as MCG DRBs, DRBs terminated at the SN and using the lower-layer resources of only the SN can be referred as SCG DRBs, and DRBs terminated at the MCG but using the lower-layer resources of the MN, the SN, or both the MN and the SN can be referred to as split DRBs.

[0005] The UE in some scenarios can concurrently utilize resources of multiple nodes ( e.g ., base stations or components of a distributed base station) of a radio access network (RAN), interconnected by a backhaul. When these network nodes support different radio access technologies (RATs), this type of connectivity is referred to as Multi-Radio Dual Connectivity (MR-DC). When a UE operates in MR-DC, one base station operates as the MN that covers a primary cell (PCell), and the other base station operates as the SN that covers a primary secondary cell (PSCell). The UE communicates with the MN (via the PCell) and the SN (via the PSCell). In other scenarios, the UE utilizes resources of one base station at a time. One base station and/or the UE determines that the UE should establish a radio connection with another base station. For example, one base station can determine to hand the UE over to the second base station, and initiate a handover procedure. The UE in other scenarios can concurrently utilize resources of a RAN node (e.g., a single base station or a component of a distributed base station), interconnected by a backhaul.

[0006] 3GPP TS 36.300 vl6.0.0 and 38.300 vl6.0.0 describe legacy procedures for handover (or called reconfiguration with sync) scenarios. These procedures involve messaging (e.g., RRC signaling and preparation) among RAN nodes and the UE. UEs can perform handover procedures to switch from one cell to another, whether in single connectivity (SC) or DC operation. The UE may handover from a cell of a serving base station to a target cell of a target base station, or from a cell of a first distributed unit (DU) of a serving base station to a target cell of a second DU of the same base station, depending on the scenario. [0007] 3GPP TS 37.340 nΐό.0.0 describes legacy procedures for a UE to change PSCells in DC scenarios. These procedures involve messaging ( e.g ., RRC signaling and preparation) among RAN nodes and the UE. The UE may perform PSCell change from a PSCell of a serving SN to a target PSCell of a target SN, or from a PSCell of a source distributed unit (DU) of a base station to a PSCell of a target DU of the same base station, depending on the scenario.

[0008] More recently, 3GPP has been discussing dual active protocol stack (DAPS) handover and DAPS PSCell change procedures for achieving 0ms user data interruption during handover and PSCell change. Generally, the length of interruption experienced at the UE depends on a time difference between the time when a radio link connection at a source cell is released and the time when a radio link connection at a target cell is established. If the release time is no earlier than the established time, achieving 0ms user data interruption is possible. Using a DAPS, the UE can simultaneously communicate with the source cell while establishing a radio link connection at the target cell, and subsequently stop communicating with the source cell after establishing a radio link connection at the target cell, when performing DAPS handover and PSCell change.

[0009] In some cases, a source base station can send a DAPS request to a target base station so that the target base station may provide a configuration for the UE to perform DAPS handover or DAPS PSCell change. Currently, the target base station is unable to indicate whether the configuration is a delta configuration or a full configuration. 3GPP supports delta configuration for the UE, but not full configuration, to minimize data interruption and continue PDCP PDU sequence numbering during DAPS handover.

However, when the source base station sends a source base station configuration along with the DAPS request to the target base station, the target base station must expend processing resources to parse the source base station configuration to generate the delta configuration for the UE. Moreover, if the target base station is not DAPS compatible, the target base station may not recognize, and therefore reject, the DAPS request, which may prevent the target base station from otherwise providing a configuration for the UE to perform a legacy handover or PSCell change. Further, 3GPP currently does not support transferring robust header compression (ROHC) context from the source base station to the target base station during DAPS handover. Therefore, in some scenarios, if the UE is configured with ROHC capabilities, such that the UE can compress or decompress headers of data packets transmitted or received on a DRB, the RAN may not properly handle DAPS handover for the UE.

SUMMARY

[0010] Generally speaking, a UE and one or more base stations operating in a RAN implement the techniques of this disclosure to prepare the UE to perform DAPS procedures (i.e., DAPS handover, DAPS PSCell change), or legacy non-DAPS procedures (7. e. , non- DAPS handover, non-DAPS PSCell change). Using these techniques, for example, the RAN can provide a configuration, such as a full configuration, to the UE 102 to perform DAPS handover or DAPS PSCell change. In some implementations, the RAN can also provide an indicator to the UE that the configuration is a full configuration.

[0011] In some implementations, the RAN may prepare the UE to perform DAPS procedures as long as both the UE and the RAN are compatible with the DAPS procedures. In some implementations, the RAN may prepare the UE to perform DAPS procedures with a source base station and a target base station of the RAN, as long as the source base station and a target base station are operated by the same vendor. In some implementations, the RAN may prepare the UE to perform legacy non-DAPS procedures if at least two base stations of the RAN would be required to perform the DAPS procedures. If the RAN determines that the UE is configured with ROHC capabilities, the RAN may proceed to prepare the UE to perform legacy non-DAPS procedures.

[0012] One example implementation of these techniques is a method in a RAN. The method includes determining, by processing hardware and while the UE is operating in a cell using a previously received configuration, to provide a full configuration to the UE for a DAPS procedure. The method also includes identifying, by the processing hardware, at least a target cell for the full configuration. The method also includes transmitting, by the processing hardware and to the UE, the full configuration, to cause the UE to execute the DAPS procedure to communicate via the target cell using the full configuration.

[0013] Another example implementation of these techniques is another method in a RAN. The method includes determining, by processing hardware, that the UE is to switch from a first cell of a source base station to a second cell of a target base station. The method also includes determining, by the processing hardware, whether the UE is to execute the DAPS procedure or the non-DAPS procedure for switching to the second cell. The method also includes, in response to the determining that the UE is to execute the non-DAPS procedure, transmitting, by the processing hardware and to the UE, a configuration to execute the non- DAPS procedure.

[0014] Another example implementation of these techniques is a method in a user device. The method includes receiving, by processing hardware and from the RAN, a full configuration to execute a DAPS procedure. The method also includes executing, by the processing hardware, the DAPS procedure in response to receiving the full configuration.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Fig. 1A is a block diagram of an example system in which a radio access network (RAN) and a UE can implement the techniques of this disclosure for managing dual active protocol stack (DAPS) procedures, including DAPS handover and DAPS PSCell change;

[0016] Fig. IB is a block diagram of an example base station in which a centralized unit (CU) and a distributed unit (DU) can operate in the system of Fig. 1 A;

[0017] Fig. 2 is a block diagram of an example protocol stack, according to which the UE of Fig. 1A can communicate with base stations of Fig. 1A;

[0018] Fig. 3A is a messaging diagram of an example scenario in which a RAN prepares a DAPS handover procedure for a UE from a source base station to a target base station by sending a full configuration to the UE;

[0019] Fig. 3B is a messaging diagram of an example scenario in which a RAN prepares a DAPS handover procedure for a UE from a source DU of a distributed base station to a target DU of the distributed base station by sending a full configuration to the UE;

[0020] Fig. 4 A is a messaging diagram of an example scenario in which an MN of the

RAN initiates a DAPS PSCell change procedure for a UE, from a source SN to a target SN, by sending a full configuration to the UE;

[0021] Fig. 4B is a messaging diagram of an example scenario in which an MN of the RAN initiates a DAPS PSCell change procedure for a UE, from a source SN to a target SN, and the target SN subsequently initiates a non-DAPS PSCell change procedure;

[0022] Fig. 5A is a messaging diagram of an example scenario in which a source SN of the RAN initiates a DAPS PSCell change procedure for a UE, from the source SN to a target SN, and an MN sends a full configuration to the UE; [0023] Fig. 5B is a messaging diagram of an example scenario in which a source SN of the RAN initiates a DAPS PSCell change procedure for a UE, from a source SN to a target SN, and an MN subsequently initiates a non-DAPS PSCell change procedure;

[0024] Fig. 6 is a messaging diagram of an example scenario in which a RAN prepares a DAPS PSCell change procedure for a UE from a source DU of a distributed base station to a target DU of the distributed base station by sending a full configuration to the UE;

[0025] Fig. 7 is a flow diagram depicting an example method for configuring a UE with a full configuration, to prepare the UE to perform a DAPS procedure;

[0026] Fig. 8 is a flow diagram depicting an example method for preparing a DAPS procedure or a non-DAPS procedure for a UE from a source base station to a target base station according to whether the UE and/or target base station supports the DAPS procedure;

[0027] Fig. 9 is a flow diagram depicting an example method for preparing a DAPS procedure or a non-DAPS procedure for a UE from a source base station to a target base station according to whether the same vendor operates the source base station and the target base station;

[0028] Fig. 10 is a flow diagram depicting an example method for preparing a DAPS procedure or a non-DAPS procedure for a UE according to whether the DAPS procedure involves handover between two base stations;

[0029] Fig. 11 is a flow diagram depicting an example method for preparing a DAPS procedure or a non-DAPS procedure for a UE according to whether the UE is configured to perform ROHC;

[0030] Fig. 12 is a flow diagram depicting an example method in a RAN for configuring a UE with a full configuration, to prepare the UE to perform a DAPS procedure;

[0031] Fig. 13 is a flow diagram depicting an example method in a UE for receiving a full configuration from a RAN to perform a DAPS procedure; and

[0032] Fig. 14 is a flow diagram depicting an example method in a RAN for preparing a DAPS procedure or a non-DAPS procedure for a UE according to whether a condition for executing the non-DAPS procedure is satisfied. DETAILED DESCRIPTION OF THE DRAWINGS

[0033] Fig. 1A depicts an example wireless communication system 100 that can implement dual active protocol stack (DAPS) operation techniques of this disclosure. The wireless communication system 100 includes a UE 102, as well as base stations 104, 106A, 106B that are connected to a core network (CN) 110. The base stations 104, 106A, 106B can be any suitable type, or types, of base stations, such as an evolved node B (eNB), a next-generation eNB (ng-eNB), or a 5G Node B (gNB), for example. As a more specific example, the base station 104 can be an eNB or a gNB, and the base stations 106 A and 106B can be gNBs.

[0034] The base station 104 supports a cell 124, the base station 106A supports a cell 126A, and the base station 106B supports a cell 126B. The cell 124 partially overlaps with both of cells 126 A and 126B, such that the UE 102 can be in range to communicate with base station 104 while simultaneously being in range to communicate with base station 106A or 106B (or in range to detect or measure the signal from both base stations 106 A or 106B, etc.). The overlap can make it possible for the UE 102 to switch between cells ( e.g ., from cell 124 to cell 126 A or 126B) or base stations (e.g., from base station 104 to base station 106 A or base station 106B) before the UE 102 experiences radio link failure, for example. Moreover, the overlap allows the various dual connectivity (DC) scenarios discussed below. For example, the UE 102 can communicate in DC with the base station 104 (operating as an MN) and the base station 106A (operating as an SN) and, upon completing a handover, can communicate with the base station 106B (operating as an MN). As another example, the UE 102 can communicate in DC with the base station 104 (operating as an MN) and the base station 106A (operating as an SN) and, upon completing an SN change, can communicate with the base station 104 (operating as an MN) and the base station 106B (operating as an SN).

[0035] More particularly, when the UE 102 is in DC with the base station 104 and the base station 106 A, the base station 104 operates as a master eNB (MeNB), a master ng-eNB (Mng-eNB), or a master gNB (MgNB), and the base station 106A operates as a secondary gNB (SgNB) or a secondary ng-eNB (Sng-eNB). In implementations and scenarios where the UE 102 is in SC with the base station 104 but is capable of operating in DC, the base station 104 operates as an MeNB, an Mng-eNB or an MgNB, and the base station 106 A operates as a candidate SgNB (C-SgNB) or a candidate Sng-eNB (C-Sng-eNB). Although various scenarios are described below in which the base station 104 operates as an MN and the base station 106A (or 106B) operates as an SN, source SN (S-SN), or target SN (T-SN), any of the base stations 104, 106A, 106B generally can operate as an MN, an SN, an S-SN, or a T-SN in different scenarios. Thus, in some implementations, the base station 104, the base station 106A, and the base station 106B can implement similar sets of functions and each support MN, SN, S-SN, and T-SN operations.

[0036] In operation, the UE 102 can use a radio bearer ( e.g ., a DRB or an SRB) that at different times terminates at an MN (e.g., the base stationl04) or an SN (e.g., the base station 106A). For example, after handover to the base station 106B, the UE 102 can use a radio bearer (e.g., a DRB or an SRB) that at different times terminates at the base station 106B.

The UE 102 can apply one or more security keys when communicating on the radio bearer, in the uplink (from the UE 102 to a base station) and/or downlink (from a base station to the UE 102) direction.

[0037] The base station 104 includes processing hardware 130, which can include one or more general-purpose processors (e.g., central processing units (CPUs) and a computer- readable memory storing machine-readable instructions executable on the one or more general-purpose processor(s), and/or special-purpose processing units. The processing hardware 130 in the example implementation in Fig. 1A includes a base station RRC controller 132 that is configured to manage or control RRC configurations and RRC procedures. For example, the base station RRC controller 132 can be configured to support RRC messaging associated with DAPS handover and DAPS PSCell change procedures, and/or to support the necessary operations when the base station 104 operates as an MN, as discussed below.

[0038] The base station 106A includes processing hardware 140, which can include one or more general-purpose processors (e.g., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general-purpose processor(s), and/or special- purpose processing units. The processing hardware 140 in the example implementation of Fig. 1A includes a base station RRC controller 142 that is configured to manage or control RRC configurations and RRC procedures. For example, the base station RRC controller 142 can be configured to support RRC messaging associated with DAPS handover and DAPS PSCell change procedures, and/or to support the necessary operations when the base station 106A operates as an SN, S-SN, or T-SN, as discussed below. While not shown in Fig. 1A, the base station 106B can include processing hardware similar to the processing hardware 140 of the base station 106A.

[0039] The UE 102 includes processing hardware 150, which can include one or more general-purpose processors ( e.g ., CPUs) and a computer-readable memory storing machine- readable instructions executable on the general-purpose processor(s), and/or special-purpose processing units. The processing hardware 150 in the example implementation of Fig. 1A includes a UE RRC controller 152 that is configured to manage or control RRC configurations RRC procedures. For example, the UE RRC controller 152 can be configured to support RRC messaging associated with DAPS handover and DAPS PSCell change procedures in accordance with any of the implementations discussed below.

[0040] The CN 110 can be an evolved packet core (EPC) 111 or a fifth-generation core (5GC) 160, both of which are depicted in Fig. 1A. The base station 104 can be an eNB supporting an SI interface for communicating with the EPC 111, an ng-eNB supporting an NG interface for communicating with the 5GC 160, or as a gNB that supports the NR radio interface as well as an NG interface for communicating with the 5GC 160. The base station 106A can be an EN-DC gNB (en-gNB) with an S 1 interface to the EPC 111, an en-gNB that does not connect to the EPC 111, a gNB that supports the NR radio interface and an NG interface to the 5GC 160, or a ng-eNB that supports an EUTRA radio interface and an NG interface to the 5GC 160. To directly exchange messages with each other during the scenarios discussed below, the base stations 104, 106A, and 106B can support an X2 or Xn interface.

[0041] Among other components, the EPC 111 can include 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 and an Access and Mobility Management (AMF) 164, and/or Session Management Function (SMF) 166. The UPF 162 is generally 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.

[0042] Generally, the wireless communication network 100 can include any suitable number of base stations supporting NR cells and/or EUTRA cells. For example, base station 104 and base station 106A can also support cells 122 and 123, respectively. More particularly, the EPC 111 or the 5GC 160 can be connected to any suitable number of base stations supporting NR cells and/or EUTRA cells. Although the examples below refer specifically to specific CN types (EPC, 5GC) and RAT types (5G NR and EUTRA), in general the techniques of this disclosure can also apply to other suitable radio access and/or core network technologies such as sixth generation (6G) radio access and/or 6G core network or 5G NR-6G DC, for example.

[0043] As indicated above, the wireless communication system 100 can support various procedures ( e.g ., DAPS handover, DAPS PSCell change, etc.) and modes of operation (e.g., SC or DC). Example operation of various procedures that can be implemented in the wireless communication system 100 will now be described.

[0044] In some implementations, the wireless communication system 100 supports a legacy handover preparation procedure (i.e., a non-DAPS handover preparation procedure).

In one scenario, for example, the base station 104 can perform a non-DAPS handover preparation procedure to configure the UE 102 to handover from a cell 124 of the base station 104 to a cell 126A of the base station 106A. In this scenario, the base station 104 and the base station 106A operate as a source base station (S-BS) or a source MN (S-MN), and a target base station (T-BS) or a target MN (T-MN), respectively. In the non-DAPS handover preparation procedure, the base station 104 sends a Handover Request message to the base station 106A. In response to the Handover Request message, the base station 106A includes configuration parameters configuring radio resources for the UE 102 in a handover command message, includes the handover command message in a Handover Request Acknowledge message, and sends the Handover Request Acknowledge message to the base station 104. In turn, the base station 104 transmits the handover command message to the UE 102 and subsequently discontinues (or stops) transmitting data to or receiving data from the UE 102.

[0045] Upon receiving the handover command message, the UE 102 hands over to the base station 106A via cell 126A and communicates with the base station 106A by using the configuration parameters in the handover command message. Particularly, in response to the handover command message, the UE 102 disconnects from the cell 124 (or the base station 104), performs a random access procedure with the base station 106A via the cell 126A, and transmits a handover complete message to the base station 106A via the cell 126A. [0046] In some implementations, the wireless communication system 100 supports a DAPS handover preparation procedure. In one scenario for example, the base station 104 can perform a DAPS handover preparation procedure to configure the UE 102 to switch from a cell 124 of the base station 104 to a cell 126B of the base station 106B. In this scenario, the base station 104 and the base station 106B operate as an S-BS or an S-MN, and a T-BS or a T-MN, respectively. In the DAPS handover preparation procedure, the base station 104 sends a Handover Request message to the base station 106B. In some implementations, the base station 104 can explicitly request DAPS handover in the Handover Request message, e.g., by including a DAPS indicator in the Handover Request message. In response to the Handover Request message, and to accept the request for DAPS handover, the base station 106B includes configuration parameters configuring radio resources for the UE 102 in a handover command, includes the handover command message in a Handover Request Acknowledge message, and sends the Handover Request Acknowledge message to the base station 104. In some implementations, the base station 106B can indicate DAPS handover in the handover command message, e.g., by including a DAPS handover configuration or a DAPS handover indicator in the handover command message, or can include an indicator in the Handover Request Acknowledge message. In turn, the base station 104 transmits the handover command message to the UE 102.

[0047] Upon receiving the handover command message, the UE 102 hands over to the base station 106B via cell 126B and communicates with the base station 106B by using the configuration parameters in the handover command message. Particularly, in response to the handover command message, whereas in the non-DAPS handover preparation procedure the UE 102 disconnects from the cell 124 (or the base station 104), the UE 102 in the DAPS handover preparation procedure maintains the connection to the base station 104 via cell 124, performs a random access procedure with the base station 106B via cell 126B, and transmits a handover complete message to the base station 106B via cell 126B.

[0048] In maintaining the connection to the base station 104 via cell 124 in the DAPS handover preparation procedure, the UE 102 effectively has two links, i.e., a source MCG link with the base station 104 and a target MCG link with the base station 106B. The UE 102 can continue receiving data {i.e., downlink data) from the base station 104 until the UE 102 receives an indication from the base station 106B to release the source MCG link with the base station 104. The UE 102 can continue transmitting data (e.g., new uplink data transmission or retransmission of PDCP SDUs) to the base station 104 until the UE 102 either successfully completes the random access procedure with the base station 106B or receives the indication from the base station 106B to release the MCG link with the base station 104.

[0049] In some implementations, in the handover preparation procedure scenarios above, the wireless communication system 100 supports DC operation. In one scenario, for example, after the UE 102 connects to the base station 104, the base station 104 can perform an SN addition procedure to add the base station 106A as an SN, thereby configuring the UE 102 to operate in DC with the base stations 104 and 106A. At this point, the base stations 104 and 106A operate as an MN and an SN, respectively. Later on, the MN 104 can initiate the non-DAPS or DAPS handover preparation procedures to handover the UE 102 to the T- MN 106B.

[0050] In some implementations, the wireless communication system 100 supports a legacy PSCell change preparation procedure (i.e., a non-DAPS PSCell change preparation procedure). In one scenario, for example, the UE 102 is initially in DC with the MN 104 (. e.g ., via PCell 124) and the SN 106A (via a PSCell 123). The SN 106A can provide a configuration for the target PSCell (T-PSCell) 126A, for the UE 102. The UE 102 stops communicating with the SN 106A via PSCell 123 and attempts to connect to the T-PSCell 126A after receiving the configuration for the T-PSCell 126A. In another scenario, for example, while the UE 102 is in DC with the MN 104 and the SN 106A, the MN 104 determines to change the SN of the UE 102 from the base station 106A (which may be referred to as the source SN or S-SN) to the base station 106B (which may be referred to as the target SN or T-SN) as part of the non-DAPS PSCell change procedure. The UE 102 stops communicating with the S-SN 106A via PSCell 123 and attempts to connect to the T-SN 106B via T-PSCell 126B after receiving the configuration for the T-PSCell 126B.

[0051] In some implementations, the wireless communication system 100 supports DAPS PSCell change. In one scenario, for example, the UE 102 is initially in DC with the MN 104 (e.g., via PCell 124) and the SN 106A (via a PSCell 123). The SN 106A can provide a configuration for the T-PSCell 126A, for the UE 102. The UE 102 continues communicating with the SN 106A via PSCell 123 while attempting to connect to the T-PSCell 126A after receiving the configuration for the T-PSCell 126A. After the T-PSCell 126A begins to operate as the PSCell 126A for the UE 102, the UE 102 stops communicating with the SN 106A via PSCell 123. In another scenario, for example, while the UE 102 is in DC with the MN 104 and the SN 106A, the MN 104 determines to change the SN of the UE 102 from the base station 106A (which may be referred to as the source SN or S-SN) to the base station 106B (which may be referred to as the target SN or T-SN) as part of the DAPS PSCell change procedure. The UE 102 continues communicating with the S-SN 106A via PSCell 123 while attempting to connect to the T-SN 106B via T-PSCell 126B after receiving the configuration for the T-PSCell 126B. After the T-PSCell 126B begins to operate as the PSCell 126B for the UE 102, the UE 102 stops communicating with the S-SN 106A via PSCell 123.

[0052] In different configurations or scenarios of the wireless communication system 100, the base station 104 can operate as an MeNB, an Mng-eNB, or an MgNB, the base station 106B can operate as an MeNB, an Mng-eNB, an MgNB, an SgNB, or an Sng-eNB, and the base station 106A can operate as an SgNB or an Sng-eNB. The UE 102 can communicate with the base station 104 and the base station 106A or 106B via the same radio access technology (RAT), such as EUTRA or NR, or via different RATs.

[0053] When the base station 104 is an MeNB and the base station 106A is an SgNB, the UE 102 can be in EUTRA-NR DC (EN-DC) with the MeNB 104 and the SgNB 106A. When the base station 104 is an Mng-eNB and the base station 106A is an SgNB, the UE 102 can be in next generation (NG) EUTRA-NR DC (NGEN-DC) with the Mng-eNB 104 and the SgNB 106A. When the base station 104 is an MgNB and the base station 106A is an SgNB, the UE 102 can be in NR-NR DC (NR-DC) with the MgNB 104 and the SgNB 106A. When the base station 104 is an MgNB and the base station 106A is an Sng-eNB, the UE 102 can be in NR-EUTRA DC (NE-DC) with the MgNB 104 and the Sng-eNB 106A.

[0054] Fig. IB depicts an example, distributed implementation of any one or more of the base stations 104, 106A, 106B. In this implementation, the base station 104, 106A, or 106B includes a centralized unit (CU) 172 and one or more distributed units (DUs) 174. The CU 172 includes processing hardware, such as one or more general-purpose processors ( e.g ., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general-purpose processor(s), and/or special-purpose processing units. For example, the CU 172 can include the processing hardware 130 or 140 of Fig. 1A. The processing hardware can include a base station RRC controller (e.g., RRC controller 142) configured to manage or control one or more RRC configurations and/or RRC procedures when the base station (e.g., base station 106A) operates as an SN. The processing hardware can also include a packet data convergence (PDCP) controller configured to manage or control one or more PDCP operations or procedures.

[0055] Each of the DUs 174 also includes processing hardware that can include one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and/or special-purpose processing units. For example, the processing hardware can include a medium access control (MAC) controller configured to manage or control one or more MAC operations or procedures (e.g., a random access procedure), and a radio link control (RLC) controller configured to manage or control one or more RLC operations or procedures when the base station (e.g., base station 106A) operates as a MN or an SN. The process hardware can also include a physical layer controller configured to manage or control one or more physical layer operations or procedures.

[0056] Fig. 2 illustrates, in a simplified manner, an example dual active protocol stack (DAPS) 200 according to which the UE 102 can communicate with an eNB/ng-eNB or a gNB (e.g., one or more of the base stations 104, 106A, 106B).

[0057] In the example stack 200, a physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to the EUTRA PDCP sublayer 208 and, in some cases, to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides RLC channels to the NR PDCP sublayer 210. The UE 102, in some implementations, supports both the EUTRA and the NR stack as shown in Fig. 2, to support handover between EUTRA and NR base stations and/or to support DC over EUTRA and NR interfaces. Further, as illustrated in Fig. 2, the UE 102 can support layering of NR PDCP 210 over EUTRA RLC 206A.

[0058] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets (e.g., from an Internet Protocol (IP) layer, layered directly or indirectly over the PDCP layer 208 or 210) that can be referred to as service data units (SDUs), and output packets (e.g., to the RLC layer 206A or 206B) that can be referred to as protocol data units (PDUs). Except where the difference between SDUs and PDUs is relevant, this disclosure for simplicity refers to both SDUs and PDUs as “packets.” [0059] On a control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide SRBs to exchange RRC messages, for example. On a user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide DRBs to support data exchange.

[0060] In scenarios where the UE 102 operates in EUTRA/NR DC (EN-DC), with the base station 104 operating as an MeNB and the base station 106A operating as an SgNB, the wireless communication system 100 can provide the UE 102 with an MN-terminated bearer that uses EUTRA PDCP sublayer 208, or an MN-terminated bearer that uses NR PDCP sublayer 210. The wireless communication system 100 in various scenarios can also provide the UE 102 with an SN-terminated bearer, which uses only the NR PDCP sublayer 210. The MN-terminated bearer can be an MCG bearer or a split bearer. The SN-terminated bearer can be an SCG bearer or a split bearer. The MN-terminated bearer can be an SRB (e.g., SRB 1 or SRB2) or a DRB. The SN-terminated bearer can be an SRB or a DRB.

[0061] Figs. 3 (i.e., 3A and 3B) through 6 illustrate message sequences between the UE 102 and various base stations of the RAN (including base stations 104, 106A and/or 106B), for a number of scenarios and implementations relating to DAPS handover and DAPS PSCell change procedures.

[0062] In particular, Figs. 3A and 3B correspond to DAPS handover scenarios in which a base station initiates a DAPS handover procedure for a UE. Figs. 4 (i.e., 4A and 4B) through Fig. 6 correspond to a DAPS PSCell change scenario in which a base station initiates a DAPS PSCell change procedure for a UE.

[0063] Referring first to Fig. 3A, in a DAPS handover scenario 300A, the base station 104 operates as a source base station (S-BS) for the UE 102, and the base station 106B operates as a target base station (T-BS) for the UE 102. The T-BS 104B includes a target CU (T-CU)

172 and a target DU (T-DU) 174.

[0064] Initially, the UE 102 communicates 302A data (e.g., uplink (UL) data PDUs and/or downlink (DL) data PDUs) with the S-BS 104 via cell 124 by using an S-BS configuration.

In some scenarios, the UE 102 communicates 302A data in SC with the S-BS 104, or communicates 302A data in DC with the S-BS 104 operating as an MN and an SN (e.g., the base station 106A) not shown in Fig. 3A.

[0065] Later in time, the S-BS 104 determines 304A to initiate DAPS handover for the T-

BS 106B and the UE 102 to communicate, e.g., blindly or in response to detecting a suitable event. For example, the determination 304A can occur in response to the S-BS 104 receiving one or more measurement results from the UE 102 that are above (or below) one or more predetermined thresholds, or calculating a filtered result (from the measurement result(s)) that is above (or below) a predetermined threshold. In another example, the suitable event can be that the UE 102 is moving toward the T-BS 106B. In yet another example, the suitable event can be one or more measurement results, generated or obtained by the S-BS 104 based on measurements of signals received from the UE 102, exceeding one or more predetermined thresholds.

[0066] After determining 304A to initiate DAPS handover, the S-BS 104 sends 306A a Handover Request message to the T-CU 172. The Handover Request message includes a DAPS request indicator and the S-BS configuration. In some implementations, the S-BS 104 may include the DAPS request indicator for a DRB that the UE 102 uses to communicate with the S-BS 104.

[0067] In response to the Handover Request message, the T-CU 172 sends 308A a UE Context Setup Request message to the T-DU 174. In response, the T-DU 174 sends 310A a UE Context Setup Response message including a full T-DU configuration to the T-CU 172.

In some implementations, the T-CU 172 can include the S-BS configuration or a portion of the S-BS configuration in the UE Context Setup Request message. In response to receiving the UE Context Setup Request message, the T-DU 174 can discard or ignore 309A the S-BS configuration or the portion of the S-BS configuration, and proceed to generate the full T-DU configuration without referring to the S-BS configuration or the portion of the S-BS configuration. Alternatively, the T-DU 174 can detect that the S-BS configuration or the portion of the S-BS configuration includes a configuration information element (IE), and proceed to generate the full T-DU configuration. The T-DU 174 can include a configuration IE in the full T-DU configuration. The configuration IE in the full T-DU configuration and the configuration IE in the S-BS configuration may have the same value or different values.

In other implementations, the T-CU 172, in determining that the T-DU 174 is not configured to generate a delta T-DU configuration, may not include the S-BS configuration or a portion of the S-BS configuration in the UE Context Setup Request message. Instead, the T-CU 172 can generate 307A a full configuration request indicator to request the T-DU 174 to generate a full T-DU configuration, and subsequently include the full configuration request indicator in the UE Context Setup Request message. [0068] In response to receiving the UE Context Setup Response message, the T-CU 172 generates 312A a handover command message that includes the full T-DU configuration and a DAPS handover configuration or an indication for the DAPS handover configuration in a field or an IE (e.g., a dapsConfig field, a dapsHO-Config field, a daps-HO field or a daps- HO-Config field). Effectively, by including the full T-DU configuration in the handover command message in response to receiving the S-BS configuration in event 306A, the T-CU 172 need not expend processing resources to parse the S-BS configuration and generate a delta configuration for the UE 102.

[0069] The T-CU 172 can optionally include a full DU configuration indicator (e.g., an IE or field) in the handover command message to indicate that the full T-DU configuration is a full configuration, i.e., a complete and self-contained configuration. In some implementations, the T-CU 172 associates the DAPS handover configuration to the DRB with which the DAPS request indicator is associated. In one such implementation, the T-CU 172 can include a radio bearer (RB) configuration (e.g., RadioBearerConfig IE, DRB- ToAddModList IE or DRB-ToAddMod IE) configuring the DRB in the handover command message, and include the DAPS handover configuration in the RB configuration. In another such implementation, the T-CU 172 can include a DRB identity of the DRB in the DAPS handover configuration, and keep the DAPS handover configuration and the RB configuration separate.

[0070] In some implementations, if the S-BS 104 determines to initiate a non-DAPS handover with the T-BS 106B instead of a DAPS handover in event 304A, the S-BS 104 can send a Handover Request message to request the T-BS 106B to prepare a non-DAPS handover procedure. In response, instead of generating the handover command message that includes the DAPS handover configuration (or an indication for the DAPS handover configuration) in event 312A, the T-BS 106B generates a handover command message that excludes the DAPS handover configuration (or excludes the indication for the DAPS handover configuration).

[0071] After generating 312A the handover command message, the T-CU 172 includes the handover command message in a Handover Request Acknowledge message, and sends 314A the Handover Request Acknowledge message to the S-BS 104. In turn, the S-BS 104 transmits 316A the handover command message to the UE 102. The handover command message also includes one or more random access configurations needed by the UE 102 to handover to the T-DU 174, and in some implementations, includes additional fields, such as a mobility field (e.g., mobility Controllnfo field or a reconfigurationWithSync field), which can include some or all of the random access configurations. The one or more random access configurations may be included in the full T-DU configuration, in some implementations.

[0072] Upon receiving the handover command message including the DAPS handover configuration from the S-BS 104, the DAPS handover configuration enables the UE 102 to use a DAPS (e.g., DAPS 200) for the DRB to communicate with the S-BS 104 using the S- BS configuration, as well as with the T-DU 174 using the full T-DU configuration, during and after a successful DAPS handover. As such, in response to the handover command message, the UE 102 and the S-BS 104 continue 320A communicating with each other via cell 124 by using the S-BS configuration, while the UE 102 attempts to handover to cell 126 belonging to the T-DU 174 in accordance with the full T-DU configuration. In attempting to perform the DAPS handover, the UE 102 initiates 322A a random access procedure with the T-DU 174, e.g., by using one or more random access configurations included in the handover command message (e.g., by using one or more random access configurations included in the full T-DU configuration). After gaining access to a channel, the UE 102 transmits 323A a handover complete message to the T-DU 174 during or after successfully completing the random access procedure, which in turn sends 324A the handover complete message to the T- CU 172. The T-DU 174 identifies the UE 102 during the random access procedure. In some implementations, the T-DU 174 identifies the UE 102 if the T-DU 174 receives a UE identifier (e.g., a cell radio network temporary identifier (C-RNTI)) or a random access preamble from the UE 102 during the random access procedure. The UE identifier or random access preamble can be assigned by the T-DU 174 in the full T-DU configuration in event 310A, in some implementations. In some implementations, the T-DU 174 can send a first Downlink Data Delivery Status message to the T-CU 172 in response to identifying the UE 102.

[0073] After the T-DU 174 identifies the UE 102 during the random access procedure (e.g., the UE 102 succeeds the contention resolution), the UE 102 communicates 326A control signals and data with the T-CU 172 via the T-DU 174 by using the full T-DU configuration included in the handover command message. Given that the full T-DU configuration is a complete and self-contained configuration, the UE 102 does not use any configuration in the S-BS configuration to communicate with the T-DU 174. However, if the handover command message includes other configurations (e.g., radio bearer configuration, etc.) generated by the T-CU 172 besides the DAPS handover configuration, the UE 102 can use such configurations to communicate 326A with the T-CU 172 via the T-DU 174. Otherwise, the UE 102 can use a portion of the S-BS configuration ( e.g ., radio bearer configuration, etc.) to communicate 326A with the T-CU 172 via the T-DU 174.

[0074] In some implementations, the UE 102 can transmit UL data PDUs by using a UL PDCP state variable (e.g., TX_NEXT) associated to the DRB and receive DL data PDUs by using a DL PDCP state variable (e.g., RX_NEXT) associated to the DRB before receiving the handover command message. The UE 102 retains the UL and DL PDCP state variables and does not reset the UL and DL PDCP state variables associated to the DRB in response to the full DU configuration indicator. At event 320A, the UE 102 can use the UL PDCP state variable to transmit UL data PDUs to the S-BS 104 and use the DL PDCP state variable to receive DL data PDUs from the S-BS 104. At event 326A, the UE 102 can use the UL PDCP state variable to transmit UL data PDUs to T-CU 172 via the T-DU 174 and use the DL PDCP state variable to receive DL data PDUs from the T-CU 172 via the T-DU 174.

[0075] In some implementations, after receiving 324A the handover complete message or receiving the first Downlink Data Delivery Status message, the T-CU 172 sends 331 A an RRC reconfiguration message including a DAPS release indicator (e.g., a daps- SourceRelease field or IE) to the T-DU 174, which in turn transmits 332A the RRC reconfiguration message to the UE 102. In other implementations, the T-CU 172 can send 331 A an LI application protocol message (L1AP) message (e.g., a DLRRC Message Transfer message or a UE Context Modification Request message) including the RRC reconfiguration message to the T-DU 174. In some implementations, in response to receiving the L1AP message (e.g., a UE Context Modification Request message), the T-DU 174 can send a message (e.g., a UE Context Modification Response message) to the T-CU 172.

[0076] In some implementations, in response to receiving the RRC reconfiguration message, the UE 102 can transmit 333A an RRC reconfiguration complete message to the T- DU 174 and stop 336A communicating with the S-BS 104. In response to the RRC reconfiguration message, the UE 102 can also release the S-BS configuration or a portion of the S-BS configuration, in some implementations. In response to receiving the RRC reconfiguration complete message, the T-DU 174 can send 334A the RRC reconfiguration complete message to the T-CU 172. [0077] After receiving 324A the handover complete message or receiving the first Downlink Data Delivery Status message, the T-CU 172 sends 328A a UE Context Release message to the S-BS 104. In response, the S-BS 104 stops 330A communicating with the UE 102, and does not transmit any more data to the UE 102. In some implementations, T-CU 172 can send 328A the UE Context Release message after sending 331 A the RRC reconfiguration message or the F1AP message to the T-DU 174.

[0078] In some implementations, in response to receiving 334A the RRC reconfiguration complete message, the T-CU 172 performs a path switch procedure with the CN 110 by sending a Path Switch Request message to the CN 110. The CN 110 switches a data path from the S-BS 104 to the T-CU 172, and sends a Path Switch Request Acknowledge message to the T-CU 172 in response to the Path Switch Request message. In some implementations, the T-CU 172 can send 328A the UE Context Release message after receiving the Path Switch Request Acknowledge message from the CN 110. In other implementations, the T-CU 172 can send 328A the UE Context Release message before receiving the Path Switch Request Acknowledge message from the CN 110. In some implementations, the T-CU 172 can send 331 A the RRC reconfiguration message or the F1AP message before or after transmitting the Path Switch Request message to the CN 110 or receiving the Path Switch Request Acknowledge message from the CN 110.

[0079] In some implementations, the S-BS 104 can send one or more Sequence Number (SN) Status Transfer messages to the T-CU 172 after receiving 314A the Handover Request Acknowledge message and before receiving 328A the UE Context Release message. In other implementations, the T-CU 172 can send a Handover Success message to the S-BS 104 before sending 328A the UE Context Release message to the S-BS 104, and the S-BS 104 can send a SN Status Transfer message to the T-CU 172 in response to the Handover Success message. The T-CU 172 can update a PDCP state variable ( e.g ., TX_NEXT) associated to the DRB configured at the UE 102 according to a hyper frame number (HFN) and a PDCP sequence number (SN) included in the SN Status Transfer message received from the S-BS 104. Then, the T-CU 172 can transmit PDCP data PDUs to the UE 102 by using the updated PDCP state variable.

[0080] In some implementations, in response to receiving 328A the UE Context Release message from the T-CU 172, the S-BS 104 can transmit the RRC reconfiguration message including a DAPS release indicator to the UE102, which in turn can transmit the RRC reconfiguration complete message to the S-BS 104, instead of events 332A and 333A.

[0081] In some implementations, after successfully completing the random access procedure, the UE 102 can start transmitting new UL data PDUs to the T-CU 172 via the T- DU 174 and stop transmitting new UL data PDUs to the S-BS 104. The UE 102 can retransmit the UL data PDUs to the S-BS 104, which may be negatively acknowledged by the S-BS 104, until event 336A occurs. The UE 102 can continue transmitting UL control signals to the S-BS 104, until event 336A occurs. In other implementations, the UE 102 stops transmitting and retransmitting UL data PDUs and/or control signals on the Physical Uplink Control Channel(s) (PUCCH(s)) to the S-BS 104 after successfully completing the random access procedure. In such implementations, the UE 102 can continue DL communication (i.e., receiving control signals, reference signals, DL PDUs, etc.) with the S- BS 104 and/or transmit control signals (e.g., HARQ acknowledgement, HARQ negative acknowledgement and/or channel state information) on PUCCH(s) to the S-BS 104 until event 332A occurs or a DAPS release timer at the UE 102 expires. In one implementation, the T-BS 106B configures a timer value for the DAPS release timer in the handover command message in event 312A or the RRC reconfiguration message in event 332A. Upon receiving 316A the handover command message or receiving 332A the RRC reconfiguration message, the UE 102 starts the DAPS release timer. When the DAPS release timer expires, the UE 102 stops 336A communicating with the S-BS 104. In response to expiry of the DAPS release timer, the UE 102 can also release the S-BS configuration or a portion of the S- BS configuration. In other implementations, the UE 102 uses a predetermined timer value if the T-BS 106B does not include the timer value in the handover command message or the RRC reconfiguration message. The T-BS 106B can include a timer value in the Handover Success message, which can be the same timer value in the RRC reconfiguration message in event 332A, or greater than the timer value in the handover command message in event 312A, for example. Thus, the S-BS 104 can start a DAPS release timer with the timer value, and stops 330A communicating with the UE 102 when the DAPS release timer expires.

[0082] In some implementations, the full T-DU configuration can be a CellGroupConfig IE. In other implementations, the full T-DU configuration can include multiple configurations such as physical layer configurations, a MAC configuration, an RLC configuration, and/or the one or more random access configurations needed by the UE 102 to perform 322A the random access procedure with the T-DU 174. The UE 102 can use the full T-DU configuration to communicate with the T-DU 174 without referring to any configuration(s) in the S-BS configuration.

[0083] In some implementations, the UE 102 can use a CU configuration (e.g., a radio bearer configuration) to communicate with the T-CU 172, and cannot use the CU configuration to communicate with the T-DU 174. The T-CU 172 may receive the CU configuration from the S-BS 104 in the Handover Request message, in one of such implementations. In another such implementation, the T-CU 172 generates the CU configuration and includes the CU configuration in the handover command message in event 312A.

[0084] In some implementations, the S-BS configuration can be an RRCReconfiguration message, RRCReconfiguration-IEs, a CellGroupConfig IE conforming to 3GPP TS 38.331, an RRCConnectionReconfiguration message, or RRCConnectionReconfiguration-IEs conforming to 3 GPP TS 36.331. In other implementations, the S-BS configuration can include configurations in the CellGroupConfig IE, RRCReconfiguration-IEs or RRCConnectionReconfiguration-IEs.

[0085] In some implementations, the S-BS 104 consists of a source CU (S-CU) 172 and one or more source DUs (S-DUs) 174 as shown in Fig. IB. The S-DU(s) 174 can generate the S-BS configuration or at least a portion of the S-BS configuration, and send the S-BS configuration (or portion) to the S-CU 172. The S-CU 172 can generate the remainder of the S-BS configuration if the S-DU 174 only generated a portion of the S-BS configuration. The S-DU(s) 174 can communicate with the UE 102 via the portion of the S-BS configuration, and the S-CU 172 can communicate with the UE 102 via the remainder of the S-BS configuration, in one implementation. For example, the S-BS configuration (or portion) generated by the S-DU 174 can include a physical downlink control channel (PDCCH) configuration, physical uplink control channel (PUCCH) configuration, etc. The remainder of the S-BS configuration generated by the S-CU 172 can include an SRB configuration, a DRB configuration, a security configuration, and/or a measurement configuration. In other implementations, the S-DU 174 can include a cell group configuration (e.g., CellGroupConfig IE) in the S-BS configuration, and the S-CU 172 can include a radio bearer configuration ( RadioBearerConfig IE) in the S-BS configuration. In some implementations, the S-CU 172 can send a UE Context Release Command message to the S-DU 174 to release the S-DU 174 from communicating with the UE 102 in response to receiving the Handover Success message or the UE Context Release message from the T-CU 172. The S-DU 174 can send a UE Context Release Complete message to the S-CU 172 in response to the UE Context Release Command message. The S-DU 174 can also send a second Downlink Data Delivery Status message to the S-CU 172 in response to the UE Context Release Command message, and the S-CU 172 in turn can generate the SN Status Transfer message in response to the second Downlink Data Delivery Status message. The S-CU 172 may use information in the second Downlink Data Delivery Status message to obtain the HFN and the PDCP SN included in the SN Status Transfer message. The information may indicate a status of PDCP PDU(s) which the S-CU 172 requests to transmit. The status can indicate that some PDCP PDU(s) are not received by the UE 102 and/or other PDCP PDU(s) are received by the UE 102, so that the S-CU 172 can determine the HFN and the PDCP SN included in the SN Status Transfer message according to the status.

[0086] In some implementations, if the S-BS 104 is a gNB, the handover command message can be an RRCReconfiguration message, the S-BS configuration can be an RRCReconfiguration-IEs as defined in 3GPP TS 38.331, the handover complete message can be an RRCReconfigurationComplete message, and the RRC reconfiguration message and the RRC reconfiguration complete message can be an RRCReconfiguration message and an RRCReconfigurationComplete message, respectively.

[0087] In some implementations, if the S-BS 104 is an eNB or an ng-eNB, the handover command message can be an RRCConnectionReconfiguration message, the S-BS configuration can be an RRCConnectionReconfiguration-r8-IEs as defined in 3GPP TS 36.331, the handover complete message can be an RRCConnectionReconfigurationComplete message, and the RRC reconfiguration message and the RRC reconfiguration complete message can be an RRCConnectionReconfiguration message and an RRCConnectionReconfigurationComplete message, respectively.

[0088] Although the S-BS 104 and the T-CU 172 are interconnected via an X2 or Xn interface in the example systems of Figs. 1 A and IB, in other scenarios the S-BS 104 and the T-CU 172 may not have an interface (i.e., an X2 or Xn interface). In these cases, the S-BS 104 can transmit a Handover Required message including the DAPS request indicator to the CN 110 ( e.g ., MME 114 or AMF 164) instead of transmitting 306A the Handover Request message to the T-CU 172. The S-BS 104 can include the S-BS configuration in the Handover Required message, similar to the manner in which the S-BS configuration can be included in the Handover Request message. In response to receiving the Handover Required message, the CN 110 generates a Handover Request message that includes the S-BS configuration and the DAPS request indicator, similar to the manner in which the S-BS 104 generates the Handover Request message in event 306A. In some implementations, if the CN 110 determines that the T-BS 106B cannot perform the DAPS handover, the CN 110 may not include the DAPS request indicator in the Handover Request message generated by the CN 110. In other implementations, the CN 110 includes the DAPS request indicator in the Handover Request message generated by the CN 110 irrespective of whether the T-BS 106B can perform the DAPS handover. The CN 110 sends the Handover Request message to the T-CU 172. That is, the Handover Required message and the CN generated Handover Request message can be used instead of the Handover Request in event 306A. In response, the T-CU 172 generates a Handover Request Acknowledge message, which includes the handover command message including the full T-DU configuration and the DAPS handover configuration described above, and sends the Handover Request Acknowledge message to the CN 110. In turn, the CN 110 sends a Handover Confirm message including the handover command message to the S-BS 104 in response to the Handover Required message. That is, the Handover Request Acknowledge message and the Handover Confirm message generated by the CN 110 can be used instead of the Handover Request Acknowledge message in event 314A.

[0089] In some implementations, the T-BS 106B (or the T-DU 174 of the T-BS 106B) can determine to configure a delta T-DU configuration instead of a full T-DU configuration, in event 310A. For example, in response to receiving 306A the S-BS configuration in the Handover Request message 306A, the T-CU 172 can send 308A the S-BS configuration or a portion of the S-BS configuration in the UE Context Setup Request message to the T-DU 174. In turn, the T-DU 174 can generate a delta T-DU configuration including one or more configurations that augment some configurations in the S-BS configuration. The T-DU 174 can include the delta T-DU configuration in the UE Context Setup Response message instead of the full T-DU configuration, as discussed in event 310A, and transmit the UE Context Setup Response message to the T-CU 172. Then the T-CU 172 can include the delta T-DU configuration and the DAPS handover configuration in a handover command message, and send the handover command message in a Handover Request Acknowledge message to the S- BS 104, in a similar manner as discussed in event 314A. In turn, the S-BS 104 can transmit the handover command message to the UE 102, causing the UE 102 to initiate a random access procedure with the T-DU 174, e.g., by using one or more random access configurations in the delta T-DU configuration, in a similar manner as discussed in event 322A. As a result, the UE 102 can communicate with the T-DU 174 by using the S-BS configuration (or a portion of the S-BS configuration) and the delta T-DU configuration.

[0090] Referring now to Fig. 3B, in a DAPS handover scenario 300B, the base station 104 serves the UE 102. The base station 104 includes a CU 172, a source DU (S-DU) 174A, and a T-DU 174B. Whereas in Fig. 3A the DAPS handover scenario 300A occurs between two base stations (e.g., the base stations 104, 106B) with respect to the UE 102, in Fig. 3B the DAPS handover scenario 300B occurs within a single base station (e.g., the base station 104). Generally, the CU 172 and T-DU 174B can perform similar actions as T-CU 172 and T-DU 174 in Fig. 3A, respectively.

[0091] Initially, the UE 102 communicates 302B data with CU 172 and S-DU 174A via cell 122 by using a CU configuration and an S-DU configuration, respectively. The CU configuration can include a radio bearer configuration (e.g., RadioBearerConfig IE or DRB- ToAddModList IE). The radio bearer configuration can include SRB configuration(s) to configure SRB(s), and a DRB configuration to configure a DRB. The UE 102 communicates 302B RRC messages on the SRB(s) and data on the DRB with the CU 172 via the S-DU 174A. The S-DU 174A can generate the S-DU configuration and send the S-DU configuration to the CU 172.

[0092] Later in time, the CU 172 determines 304B to initiate DAPS handover for the T- DU 174B and the UE 102 to communicate via cell 124, e.g., blindly or in response to detecting a suitable event, similar to those described with respect to Fig. 3A. For example, the CU 172 initiates DAPS handover in response to measurement result(s) obtained by the CU 172 from measurements on signals received from the UE 102 via S-DU 174A.

[0093] After determining 304B to initiate DAPS handover, the CU 172 sends 308B a UE Context Setup Request message to the T-DU 174B. In response, the T-DU 174B sends 310B a UE Context Setup Response message including a full T-DU configuration to the CU 172.

In some implementations, the CU 172 can include the S-DU configuration or a portion of the S-DU configuration in the UE Context Setup Request message. In response to receiving the UE Context Setup Request message, the T-DU 174B can discard or ignore 309B the S-DU configuration or the portion of the S-DU configuration, and proceed to generate the full T- DU configuration without referring to any portion of the S-DU configuration. Alternatively, the T-DU 174B can detect that the S-DU configuration or the portion of the S-DU configuration includes a configuration IE, and proceed to generate the full T-DU configuration by including a configuration IE in the full T-DU configuration. The configuration IE in the full T-DU configuration and the configuration IE in the S-DU configuration may have the same value or different values. In other implementations, the CU 172, in determining that the T-DU 174B is not configured to generate a delta T-DU configuration, may not include the S-DU configuration or a portion of the S-DU configuration in the UE Context Setup Request message. Instead, the CU 172 can generate 307B a full configuration request indicator to request the T-DU 174B to generate a full T-DU configuration, and subsequently include the full configuration request indicator in the UE Context Setup Request message.

[0094] In response to receiving the UE Context Setup Response message, the CU 172 generates 312B a handover command message that includes the full T-DU configuration and a DAPS handover configuration or an indication for the DAPS handover configuration in a field or an IE, similar to the manner in which the T-CU 172 generates the handover command message in event 312A. After generating 312B the handover command message, the CU 172 sends 314B the handover command message to the S-DU 174A, which in turn transmits 316B the handover command message to the UE 102.

[0095] Upon receiving the handover command message including the DAPS handover configuration from the S-DU 174 A, the DAPS handover configuration enables the UE 102 to use a DAPS ( e.g ., DAPS 200) to communicate with the S-DU 174A using the S-DU configuration, as well as with the T-DU 174B using the full T-DU configuration, during and after a successful DAPS handover. As such, in response to the handover command message, the UE 102 and the base station 104 continue 320B communicating with each other via cell 122 by using the S-DU configuration and the CU configuration, while the UE 102 attempts to handover to cell 124 belonging to the T-DU 174B in accordance with the full T-DU configuration.

[0096] The CU 172 can instruct the S-DU 174A to continue 320B communicating with the UE 102 in various ways. In some implementations, the CU 172 in event 314B can send a UE Context Modification Request message including the handover command message to the S- DU 174A. In this UE Context Modification Request message, the CU 172 can indicate to the S-DU 174A not to stop transmitting data to the UE 102, in one such implementation. For example, the CU 172 may omit a “Transmission Action Indicator” IE, or include a “Transmission Action Indicator” IE set to “restart” in the UE Context Modification Request message. In another such implementation, the CU 172 can include an IE indicating DAPS handover in the UE Context Modification Request message to indicate to the S-DU 174A to continue communicating with the UE 102. In response to receiving the UE Context Modification Request message, the S-DU 174A can send a UE Context Modification Response message to the CU 172. In other implementations, the CU 172 in event 314B can send a DL RRC Message Transfer message (instead of the UE Context Modification Request message) including the handover command message to the S-DU 174A to indicate to the S- DU 174 A not to stop transmitting data to the UE 102.

[0097] In attempting to perform the DAPS handover, the UE 102 initiates 322B a random access procedure with the T-DU 174B, e.g., by using one or more random access configurations included in the handover command message (e.g., by using one or more random access configurations included in the full T-DU configuration). After gaining access to a channel, the UE 102 transmits 323B a handover complete message to the T-DU 174B during or after successfully completing the random access procedure, which in turn sends 324B the handover complete message to the CU 172. The T-DU 174B, similar to the T-DU 174 described with respect to Fig. 3A, can identify the UE 102 during the random access procedure and send a first Downlink Data Delivery Status message to the CU 172.

[0098] After the T-DU 174B identifies the UE 102 during the random access procedure, the UE 102 communicates 326B control signals and data with the CU 172 via the T-DU 174B by using the full T-DU configuration included in the handover command message. Given that the full T-DU configuration is a complete and self-contained configuration, the UE 102 does not use any configuration in the S-DU configuration to communicate with the T-DU 174. However, if the handover command message includes other configurations (e.g., radio bearer configuration, etc.) generated by the CU 172 besides the DAPS handover configuration, the UE 102 can use such configurations to communicate 326B with the CU 172 via the T-DU 174B.

[0099] After receiving 324B the handover complete message or receiving the first Downlink Data Delivery Status message, the CU 172 stops 330B communicating with the UE 102 via the S-DU 174A. The CU 172 can then send 33 IB an RRC reconfiguration message that includes a DAPS release indicator (e.g., a daps-SourceRelease field or IE) to the T-DU 174B, which in turn can send 332B the RRC reconfiguration message to the UE 102. In some implementations, the CU 172 stops 330B communicating with the UE 102 before or after transmitting the RRC reconfiguration message to the T-DU 174B. In some implementations, in response to receiving the RRC reconfiguration message, the UE 102 can transmit 333B an RRC reconfiguration complete message to the T-DU 174B and stop 336B communicating with the S-DU 174A. In response to the RRC reconfiguration message, the UE 102 can also release the S-DU configuration, in some implementations. In response to receiving the RRC reconfiguration complete message, the T-DU 174B can send 334B the RRC reconfiguration complete message to the CU 172.

[0100] Because the UE 102 no longer needs to use the DAPS to continue communicating with the S-DU 174A, the CU 172 can perform 340B a UE Context Release procedure with the S-DU 174A in response to receiving the RRC reconfiguration complete message. Particularly, the CU 172 sends a UE Context Release Command message to the S-DU 174A, which in turn sends a UE Context Release Complete message to the CU 172 and stops communicating with the UE 102. By performing the UE Context Release procedure in response to receiving the RRC reconfiguration complete message, the CU 172 maintains the UE context longer relative to a non-DAPS handover procedure when performing a DAPS handover procedure. In some implementations, the S-DU 174A can also send a second Downlink Data Delivery Status message to the CU 172 in response to receiving the UE Context Release Command message. The CU 172 can update a PDCP state variable (e.g., TX_NEXT) associated to the DRB configured at the UE 102 according to the second Downlink Data Delivery Status message. For example, the second Downlink Data Delivery Status message can include information which indicates a status of PDCP PDU(s) which the CU 172 requests to transmit. The status can indicate that some PDCP PDU(s) are not received by the UE 102 and/or other PDCP PDU(s) are received by the UE 102, so that the CU 172 can update the PDCP state variable according to the status and use the updated PDCP state variable to transmit PDCP data PDUs to the UE 102.

[0101] In some implementations, after successfully completing the random access procedure, the UE 102 can start transmitting new UL data PDUs to the CU 172 via the T-DU 174B and stop transmitting new UL data PDUs to the S-DU 174A. The UE 102 can retransmit the UL data PDUs to the S-DU 174 A, which may be negatively acknowledged by the S-DU 174 A, until event 336B occurs. The UE 102 can continue transmitting UL control signals to the S-DU 174A, until event 336B occurs. In other implementations, the UE 102 stops transmitting and retransmitting UL data PDUs and/or control signals on PUCCH(s) to the S-DU 174A after successfully completing the random access procedure. In such implementations, the UE 102 can continue DL communication (i.e., receiving control signals, reference signals, DL PDUs, etc.) with the S-DU 174A and/or transmit control signals ( e.g ., HARQ acknowledgement, HARQ negative acknowledgement and/or channel state information) on PUCCH(s) to the S-DU 174A until event 332B occurs or a DAPS release timer at the UE 102 expires. In one implementation, the CU 172 configures a timer value for the DAPS release timer in the handover command message in event 312B or the RRC reconfiguration message in event 332B. Upon receiving 316B the handover command message or receiving 332B the RRC reconfiguration message, the UE 102 starts the DAPS release timer. When the DAPS release timer expires, the UE 102 stops 336B communicating with the S-DU 174A. In response to expiry of the DAPS release timer, the UE 102 can also release the S-DU configuration. In other implementations, the UE 102 uses a predetermined timer value if the CU 172 does not include the timer value in the handover command message or the RRC reconfiguration message.

[0102] In some implementations, the S-DU configuration can be a CellGroupConfig IE. In other implementations, the S-DU configuration can include multiple configurations such as physical layer configurations, a MAC configuration, and/or an RLC configuration.

[0103] In some implementations, the T-DU 174B can determine to configure a delta T-DU configuration instead of a full T-DU configuration, in event 310B. For example, in response to receiving 308B the S-DU configuration in the UE Context Setup Request message, the T- DU 174B can generate a delta T-DU configuration including one or more configurations that augment some configurations in the S-DU configuration. The T-DU 174B can include the delta T-DU configuration in the UE Context Setup Response message instead of the full T- DU configuration, as discussed in event 310B, and transmit the UE Context Setup Response message to the CU 172. Then the CU 172 can include the delta T-DU configuration and the DAPS handover configuration in a handover command message, and send the handover command message in a Handover Request Acknowledge message 314B to the S-DU 174A, in a similar manner as discussed in event 314B. In turn, the S-DU 174A can transmit the handover command message to the UE 102, causing the UE 102 to initiate a random access procedure with the T-DU 174B, e.g., by using one or more random access configurations in the delta T-DU configuration, in a similar manner as discussed in event 322B. As a result, the UE 102 can communicate with the T-DU 174B by using the S-DU configuration (or a portion of the S-DU configuration) and the delta T-DU configuration.

[0104] Figs. 4 (i.e., 4A and 4B) through Figs. 6 (i.e., 6A and 6B) correspond to DAPS PSCell change scenarios in which a base station initiates a DAPS PSCell change procedure for a UE in SC or in DC. Particularly, Figs. 4 and 5 correspond to DAPS PSCell change scenarios involving an SN change, and Fig. 6 corresponds to a DAPS PSCell change scenario maintaining the same SN.

[0105] Referring first to Fig. 4A, in a DAPS PSCell change scenario 400A, the base station 104 operates as an MN for the UE 102, the base station 106A operates as an S-SN for the UE 102, and the base station 106B operates as a T-SN for the UE 102.

[0106] Initially, the UE 102 in DC communicates 402 A data with the MN 104 via PCell 124 by using an MN configuration, and with the S-SN 106A via PSCell 126A by using an S- SN configuration. In some implementations, the UE 102 in DC also uses a radio bearer configuration (e.g., RadioBearerConfig IE or DRB-ToAddModList IE) to communicate 402A data with the S-SN 106A via PSCell 126A in addition to the S-SN configuration.

[0107] Later in time, the MN 104 determines 404A to initiate DAPS PSCell change involving an SN change (i.e., MN-initiated DAPS SN addition or change procedure) for the T-SN 106B and the UE 102 to communicate via a T-PSCell 126B, e.g., blindly or in response to detecting a suitable event, similar to those described with respect to Fig. 3A.

[0108] In response to the determination 404 A, the MN 104 sends 410A an SN Addition Request message including a DAPS request indicator to the T-SN 106B. In some implementations, the MN 104 may include the DAPS request indicator for a DRB that the UE 102 uses to communicate with the S-SN 106A. In some implementations, the MN 104 may include the S-SN configuration in the SN Addition Request message. In response, the T-SN 106B generates 412A a full T-SN configuration and a DAPS PSCell change configuration (or a DAPS SN change indicator), and sends 414A the full T-SN configuration and the DAPS PSCell change configuration (or a DAPS SN change indicator) in an SN Addition Request Acknowledge message to the MN 104. Effectively, by including the full T-SN configuration in the SN Addition Request Acknowledge message in response to receiving the S-SN configuration in event 410A, the T-SN 106B need not expend processing resources to parse the S-SN configuration and generate a delta configuration for the UE 102. [0109] In some implementations, the T-SN 106B associates the DAPS PSCell change configuration to the DRB with which the DAPS request indicator is associated. In one such implementation, the T-SN 106B can include an RB configuration ( e.g ., RadioBearerConfig IE, DRB-ToAddModList IE or DRB-ToAddMod IE) configuring the DRB in the SN Addition Request Acknowledge message and include the DAPS PSCell change configuration in the RB configuration. In another such implementation, the T-SN 106B can include a DRB identity of the DRB in the DAPS PSCell change configuration, and keep the DAPS PSCell change configuration and the RB configuration separate.

[0110] In some implementations, if the MN 104 determines to initiate a non-DAPS PSCell change with the T-SN 106B instead of a DAPS PSCell change in event 404A, the MN 104 can send an SN Addition Request message in an RRC reconfiguration message to request the T-SN 106B to prepare a non-DAPS PSCell change procedure. In response, instead of sending the SN Addition Request Acknowledge message that includes the DAPS PSCell change configuration (or an indication for the DAPS PSCell change configuration) in event 414A, the T-SN 106B sends an SN Addition Request Acknowledge message that excludes the DAPS PSCell change configuration (or excludes the indication for the DAPS PSCell change configuration) to the MN 104.

[0111] In some implementations, in response to the determination 404A, the MN 104 sends 415A an SN Release Request message (or alternatively, an SN Modification Request message) to the S-SN 106A, to request the S-SN 106A to perform DAPS PSCell change or to continue communicating with the UE 102. The MN 104 can include a DAPS release request indicator (or a continue communication request indicator) in the SN Release Request message (or alternatively, in the SN Modification Request message). In other implementations, the MN 104 may not send an SN Release Request message (or alternatively, an SN Modification Request message) to the S-SN 106A, causing the S-SN 106A to continue communicating with the UE 102 as the S-SN 106A is unaware of the DAPS PSCell change and therefore behaves as usual.

[0112] In response to receiving 415A the SN Release Request message (or the SN Modification Request message), the S-SN 106A continues communicating with the UE 102, and subsequently sends 416A an SN Release Request Acknowledge message (or an SN Modification Request Acknowledge message) to the MN 104, respectively. In the SN Release Request Acknowledge message (or the SN Modification Request Acknowledge message), the S-SN 106A can include a DAPS indication to acknowledge that the S-SN 106A accepted the DAPS release request indicator, and that the S-SN 106 A will continue 420A communicating with the UE 102 in response to the DAPS release request indicator. In some implementations, events 410A, 414A, and 412A occur before, after, or simultaneously with events 415A, 416A.

[0113] In response to receiving 414A the SN Addition Request Acknowledge message from the T-SN 106B, the MN 104 includes the full T-SN configuration and the DAPS PSCell change configuration in an RRC container message, and transmits 417A the RRC container message to the UE 102. In some implementations, the MN 104 may include a full T-SN configuration indicator in the RRC container message to indicate to the UE 102 that the full T-SN configuration is a full configuration (i.e., a complete and self-contained configuration), and that the UE 102 should not immediately release the full T-SN configuration. In one implementation, the full T-SN configuration indicator can be a release and addition indicator (e.g., endc -Release AndAdd field or mrdc-ReleaseAndAdd field). In some implementations, the RRC container message can include one or more random access configurations needed by the UE 102 to connect to the T-SN 106B, and in some implementations, includes additional fields, such as a mobility field (e.g., mobilityControlInfoSCG field or a reconfigurationWithSync field), which can include some or all of the random access configurations. The one or more random access configurations may be included in the full T- SN configuration, in some implementations.

[0114] In some implementations, rather than the T-SN 106B generating the DAPS PSCell change configuration in event 412A and sending the DAPS PSCell change configuration to the MN 104 in event 414A, the MN 104 can instead generate 413A the DAPS PSCell change configuration. In one such implementation, the MN 104 associates the DAPS PSCell change configuration to the DRB with which the DAPS request indicator is associated, similar to the manner in which the T-CU 172 associates the DAPS handover configuration to the DRB.

The MN 104 can include the full T-SN configuration and the DAPS PSCell change configuration received in event 414A in the RRC container message. If the MN 104 does not receive the DAPS indication in event 416A, the MN 104 may not include the DAPS PSCell change configuration in the RRC container message 417A, and instead decide to perform a non-DAPS PSCell change procedure. [0115] In response to receiving 417A the RRC container message, the UE 102 transmits 418A an RRC container response message including an RRC reconfiguration complete message to the MN 104. In some implementations, the MN 104 can send 419A an SN message (e.g., SN Reconfiguration Complete message or SN Confirm message) to the T-SN 106B in response to the RRC container response- message. The events 404A, 410A, 412A, 413A, 414A, 415A, 416A, 417A, 418A, 419A are collectively referred to in Fig. 4A as the DAPS PSCell change preparation procedure 460A.

[0116] The DAPS PSCell change configuration enables the UE 102 to use a DAPS (e.g., DAPS 200) to communicate with the S-SN 106A via PSCell 126A and T-SN 106B via T- PSCell 126B (during and after a successful DAPS PSCell change). As such, in response to receiving 417A the RRC container message, the UE 102 and the S-SN 106A continue 420A communicating with each other (i.e., the UE remains in DC with the MN 104) while the UE 102 attempts to perform DAPS PSCell change to the T-SN 106B via T-PSCell 126B in accordance with the full T-SN configuration included in the RRC container message. In attempting to perform the DAPS PSCell change, the UE 102 initiates 422A a random access procedure with the T-SN 106B via T-PSCell 126B, e.g., by using one or more random access configurations in the full T-SN configuration. After the T-SN 106B identifies the UE 102 during the random access procedure (e.g., the UE 102 succeeds the contention resolution), the UE 102 communicates 426A in DC with MN 104 and the T-SN 106B via T-PSCell 126B by using configurations in the full T-SN configuration included in the RRC container message, while continuing to communicate with the S-SN 106A. In some implementations, the T-SN 106B identifies the UE 102 if the T-SN 106B receives a UE identifier (e.g., a C-RNTI) or a random access preamble from the UE 102 during the random access procedure. The UE identifier or random access preamble can be assigned by the T-SN 106B, in some implementations .

[0117] After the T-SN 106B identifies the UE 102 during the random access procedure, the T-SN 106B can send 432A an RRC reconfiguration message including a DAPS release indicator (e.g., a daps-SourceRelease field or IE) to the UE 102 via the T-PSCell 126B. In some implementations, the T-SN 106B can send 432A the RRC reconfiguration message to the UE 102 via the MN 104. In one such implementation, the T-SN 106B can send 432A an SN Modification Required message including the RRC reconfiguration message to the MN 104, which in turn can transmit 432A an RRC container message including the RRC reconfiguration message to the UE 102. [0118] In response to receiving the RRC reconfiguration message, the UE 102 can transmit 434A an RRC reconfiguration complete message to the T-SN 106B via T-PSCell 126B. In some implementations, the UE 102 can send 434A the RRC reconfiguration complete message to the T-SN 106B via the MN 104. In one such implementation, the UE 102 can send 434A an RRC container response message including the RRC reconfiguration complete message to the MN 104, which in turn can transmit 434A an SN message ( e.g ., SN Modification Confirm message or SN Reconfiguration Complete message) including the RRC reconfiguration complete message to the T-SN 106B. In some implementations, the T-SN 106B can send 427A an SN message (e.g., SN Modification Required message, SN Release Required message or a newly defined X2 or Xn message, such as an SN Change Success message) to the MN 104, which causes the MN 104 to release a UE context in the S-SN 106A. In turn, the MN 104 can send 428A a UE Context Release message to the S-SN 106A. In other implementations, the MN 104 can send 428A a UE Context Release message to the S-SN 106A in response to receiving 418A the RRC container response message (or a predetermined time period after receiving 418A the RRC container response message), receiving 432A the SN Modification Required message, or receiving 434A the RRC container response message.

[0119] After sending 418A the RRC reconfiguration complete message, the UE 102 stops 436A communicating with the S-SN 106A. In response to receiving 432A the RRC reconfiguration message, the UE 102 can also release the S-SN configuration. In some implementations, the UE 102 stops 436A communicating with the S-SN 106A in response to receiving 432A the DAPS release indicator in the RRC reconfiguration message. In some implementations, in response to receiving 432A the DAPS release indicator, a RF chip, receiver, or a transceiver of the UE 102 used to communicate with the S-SN 106A during the DAPS PSCell change can enter into low power consumption mode, sleep mode, or be turned off entirely. In other implementations, the UE 102 can start a DAPS release timer in response to receiving 417A the RRC container message or receiving 432A the RRC reconfiguration message. When the DAPS release timer expires, the UE 102 stops 436A communicating with the S-SN 106A. In one implementation, the MN 104 can configure a timer value for the DAPS release timer and include the timer value in the RRC container message in event 417A. In another implementation, the T-SN 106B can configure the timer value for the DAPS release timer and include the timer value in the full T-SN configuration or the DAPS PSCell change configuration. In yet another implementation, neither the MN 104 nor the T-SN 106B configures a timer value for the DAPS release timer, and instead the UE 102 uses a predetermined timer value for the DAPS release timer.

[0120] After successfully completing the random access procedure, the UE 102 can start transmitting UL data PDUs to the T-SN 106B via the cell 126B, stop transmitting and retransmitting UL data PDUs to the S-SN 106A, stop transmitting control signals on PUCCH(s) to the S-SN 106A, stop transmitting new UL data PDUs to the S-SN 106A while continuing to retransmit UL data PDU(s) to the S-SN 106A, continue DL communication with the S-SN 106A, and/or keep transmitting control signals to the S-SN 106A until event 432A occurs or the DAPS release timer at the UE 102 expires.

[0121] In some implementations, the S-SN 106A stops 430A communicating with the UE 102, e.g., immediately or in a predetermined time period, after receiving the UE Context Release message. In other implementations, the S-SN 106A stops 430A communicating with the UE 102 if the S-SN 106A does not receive DL data packets from the CN 110 (e.g., S-GW 112 or UPF 162) for a predetermined time period. The events 422A, 426A, 427A, 428A, 430A, 432A, 434A are collectively referred to in Fig. 4A as the DAPS PSCell change and DAPS release procedure 450A. In yet other implementations, the MN 104 can include a timer value in the SN Release Request message at event 415A or a UE Context Release message at event 428A, which can be the same timer value in the RRC container message in event 417A, or greater than the timer value in the RRC reconfiguration message in event 432A, for example. Thus, the S-SN 106A can start a DAPS release timer with the timer value, and stops 430A communicating with the UE 102 when the DAPS release timer expires.

[0122] In some implementations, the S-SN 106A sends a first sequence number (SN)

Status Transfer message to the MN 104 after or in response to receiving 415A the SN Release Request message or the SN Modification Request message, and in turn, the MN 104 forwards content of the first SN Status Transfer message to the T-SN 106B. The first SN Status Transfer message can convey a DL PDCP sequence number (SN) transmitter status for a DRB as a result of the DAPS PSCell change procedure. The T-SN 106B can configure the DRB using the DAPS PSCell change configuration. In one implementation, the DL PDCP SN transmitter status indicates a PDCP SN and an HFN of the first PDCP SDU that the S-SN 106A forwards to the T-SN 106B. The S-SN 106A may not stop assigning PDCP SNs to DL PDCP SDUs or delivering UL packets in UL PDCP SDUs or UL PDCP SDUs to the UPF 162 until the S-SN 106A sends a second ( e.g ., last) SN Status Transfer message or content of the second SN Status Transfer message to the T-SN 106B via the MN 104. The S-SN 106A can send the second SN Status Transfer message to the MN 104 after the T-SN 106B receives 419A the SN message, during event 420A, or in response to the S-SN 106A stopping 430A communication with the UE 102. In turn, the MN 104 can forward the second SN Status Transfer message (or the content of the second SN Status Transfer message) to the S-SN 106A.

[0123] In some implementations, the MN 104 performs a Path Update procedure involving the CN 110 (e.g., MME 114/S-GW 112 or AMF 164/UPF 162) to update the data path between the S-SN 106A and the CN 110 to an updated data path between the T-SN 106B and the CN 110 in response to or after transmitting 419A the SN message or receiving an SN Status Transfer message from the S-SN 106A. After updating the data path, the CN 110 sends DL data packets to the T-SN 106B instead of the S-SN 106A. In the Path Update procedure, the MN 104 (e.g., MeNB) in one implementation sends an E-RAB Modification Indication message to the MME 114, which in turn performs a Bearer Modification procedure with the S-GW 112 upon receiving the E-RAB Modification Indication message.

As a result, the S-GW 112 updates the data path to the T-SN 106B. In another implementation, the MN 104 (e.g., Mng-eNB or MgNB) sends a PDU Session Resource Modify Indication message to the AMF 164, which in turn performs a Bearer Modification procedure with the UPF 162 upon receiving the PDU Session Resource Modify Indication message. As a result, the UPF 162 updates the data path to the T-SN 106B.

[0124] In some implementations, the MN 104 sends 428A the UE Context Release message to the S-SN 106A after forwarding the second SN Status Transfer message or its content to the S-SN 106A, or after completing the Path Update procedure.

[0125] In some implementations, the T-SN 106B includes multiple configuration parameters in the full T-SN configuration to configure radio resources for the UE 102 to communicate with the T-SN 106B via the PSCell 126B. The multiple configuration parameters can configure physical layer, medium access control (MAC) layer and radio link control bearers. The DAPS PSCell change configuration can be associated or specific to a radio bearer (e.g., DRB). For example, the T-SN 106B can include the DAPS PSCell change configuration in an RB configuration (e.g., RadioBearerConfig IE, DRB-ToAddModList IE or DRB-ToAddMod IE) in the SN Addition Request Acknowledge message in event 414A. The MN 104 can include the RB configuration in the RRC container message in event 417A. The S-SN 106A can also configure the particular DRB and transmit an RB configuration configuring the particular DRB to the UE 102. In some implementations, the T-SN 106B can configure SCell(s) of the T-SN 106B in the multiple configuration parameters. In other implementations, the T-SN 106B may not configure an SCell to the UE 102 in the full T-SN configuration, and later transmit RRC reconfiguration message(s) to the UE 102 to configure SCell(s) of the T-SN 106B. In response, the UE 102 can transmit an RRC reconfiguration complete message to the T-SN 106B via the PSCell 126B or a configured SCell for each of the RRC reconfiguration message(s).

[0126] If the S-SN 106A is a gNB, the full T-SN configuration and the RRC reconfiguration message can be RRCReconfiguration messages and the RRC reconfiguration complete message can be an RRCReconfigurationComplete message as defined in 3GPP TS 38.331. If the S-SN 106A is an ng-eNB, the full T-SN configuration and the RRC reconfiguration message can be RRCConnectionReconfiguration messages and the RRC reconfiguration complete message can be an RRCConnectionReconfigurationComplete message as defined in 3GPP TS 36.331.

[0127] Referring now to Fig. 4B, in a DAPS PSCell change scenario 400B, the base station 104 again operates as an MN for the UE 102, the base station 106A again operates as an S- SN for the UE 102, and the base station 106B again operates as a T-SN for the UE 102, similar to scenario 400A of Fig. 4A. Whereas the T-SN 106B in Fig. 4A proceeds to perform a DAPS PSCell change procedure in response to receiving a DAPS request indicator from the MN 104, the T-SN 106B in Fig. 4B proceeds to perform a non-DAPS PSCell change procedure despite receiving a DAPS request indicator. Thus, the RAN (i.e., MN 104, S-SN 106A, and T-SN 106B) can support a legacy PSCell change preparation procedure (i.e., a non-DAPS PSCell change preparation procedure).

[0128] Initially, the UE 102 in DC communicates 402B data with the MN 104 via PCell 124 by using an MN configuration, and with the S-SN 106A via PSCell 126A by using an S- SN configuration, similar to event 402A.

[0129] Later in time, the MN 104 determines 404B to initiate DAPS PSCell change involving an SN change (i.e., MN-initiated DAPS SN addition or change procedure) for the T-SN 106B and the UE 102 to communicate via a T-PSCell 126B, similar to event 404A. In response to the determination 404B, the MN 104 sends 41 OB an SN Addition Request message including a DAPS request indicator to the T-SN 106B, similar to event 410A.

[0130] In some implementations, despite receiving the DAPS request indicator, the T-SN 106B may determine 413B to not perform a DAPS PSCell change procedure if the T-SN 106B detects a certain condition, and subsequently generates a T-SN configuration only (i.e., the T-SN 106B does not also generate a DAPS PSCell change configuration or a DAPS SN change indicator). For example, the T-SN 106B may be aware that the UE 102 is not capable of a DAPS PSCell change procedure with the S-SN configuration. In another example, the T-SN 106B may be preconfigured to be aware that the S-SN 106A is manufactured by or is otherwise associated with a different vendor, or is operating with a different software or firmware version. In yet another example, the T-SN 106B may be informed by a network node ( e.g ., an operation and maintenance (O&M) node) that S-SN 106A and the T-SN 106B are manufactured by or are otherwise associated with different vendors, or are operating with different software or firmware versions. In yet another example, the T-SN 106B may be informed by a network node (e.g., O&M node) that the S-SN 106A cannot perform a DAPS PSCell change procedure with the T-SN 106B. Thus, the RAN (i.e., MN 104, S-SN 106A, and T-SN 106B) can support a legacy PSCell change preparation procedure (i.e., a non- DAPS PSCell change preparation procedure). After generating the T-SN configuration, the T-SN 106B sends 414B the T-SN configuration in an SN Addition Request Acknowledge message to the MN 104.

[0131] In some implementations, in response to receiving the SN Addition Request Acknowledge message, the MN 104 sends 415B an SN Release Request message (or alternatively, an SN Modification Request message) to the S-SN 106A, to request the S-SN 106 A to stop communicating with the UE 102. In response to receiving 415B the SN Release Request message (or the SN Modification Request message), the S-SN 106A stops communicating with the UE 102, and subsequently sends 416B an SN Release Request Acknowledge message (or an SN Modification Request Acknowledge message) to the MN 104, respectively.

[0132] In response to receiving 414B the SN Addition Request Acknowledge message from the T-SN 106B, the MN 104 includes the T-SN configuration in an RRC container message, and transmits 417B the RRC container message to the UE 102. In some implementations, the MN 104 may include a T-SN configuration indicator in the RRC container message to indicate to the UE 102 that the T-SN configuration is a full configuration, and that the UE 102 should immediately release the S-SN configuration. In some implementations, the RRC container message can include one or more random access configurations needed by the UE 102 to connect to the T-SN 106B, and in some implementations, includes additional fields, such as a mobility field (e.g., mobilityControlInfoSCG field or a reconfigurationWithSync field), which can include some or all of the random access configurations. The one or more random access configurations may be included in the T-SN configuration, in some implementations .

[0133] In response to receiving 417B the RRC container message, the UE 102 transmits 418B an RRC container response message including an RRC reconfiguration complete message to the MN 104. In some implementations, the MN 104 can send 419A an SN message (e.g., SN Reconfiguration Complete message or SN Confirm message) to the T-SN 106B in response to the RRC container response, message. The events 414B, 415B, 416B, 417B, 418B, 419B are collectively referred to in Fig. 4B as the non-DAPS PSCell change preparation procedure 460B.

[0134] In response to receiving 417B the RRC container message, the UE 102 and the S- SN 106A stop 420B communicating with each other (i.e., the UE 102 remains in DC with the MN 104), while the UE 102 attempts to perform non-DAPS PSCell change to the T-SN 106B via T-PSCell 126B in accordance with the T-SN configuration included in the RRC container message. In attempting to perform the non-DAPS PSCell change, the UE 102 initiates 422B a random access procedure with the T-SN 106B via T-PSCell 126B, e.g., by using one or more random access configurations in the T-SN configuration. After the T-SN 106B identifies the UE 102 during the random access procedure, the UE 102 communicates 426B in DC with MN 104 and the T-SN 106B via T-PSCell 126B by using configurations in the T- SN configuration included in the RRC container message. In some implementations, the T- SN 106B identifies the UE 102 if the T-SN 106B receives a UE identifier (e.g., a C-RNTI) or a random access preamble from the UE 102 during the random access procedure. The UE identifier or random access preamble can be assigned by the T-SN 106B, in some implementations .

[0135] In some implementations, the MN 104 can send 428B a UE Context Release message to the S-SN 106A after receiving 418B the RRC container response message. The S-SN 106A stops communicating with the UE 102 in response to or after receiving the UE Context Release message. The events 422B, 426B, 428B are collectively referred to in Fig. 4B as the non-DAPS PSCell change and release procedure 450B.

[0136] Referring now to Fig. 5A, in a DAPS PSCell change scenario 500A, the base station 104 again operates as an MN for the UE 102, the base station 106A again operates as an S-SN for the UE 102, and the base station 106B again operates as a T-SN for the UE 102, similar to scenario 400A of Fig. 4A. Whereas the MN 104 in Fig. 4A determines to initiate a DAPS PSCell change procedure, the S-SN 106A in Fig. 5A instead determines to initiate the DAPS PSCell change procedure.

[0137] Initially, the UE 102 in DC communicates 502A data with the MN 104 via PCell 124 by using an MN configuration, and with the S-SN 106A via PSCell 126A by using an S- SN configuration, similar to event 402A.

[0138] Later in time, the S-SN 106A determines 504A to initiate DAPS PSCell change involving an SN change (i.e., SN-initiated DAPS SN addition or change procedure) for the T- SN 106B and the UE 102 to communicate via a T-PSCell 126B, e.g., blindly or in response to detecting a suitable event. For example, the determination 504A can occur in response to the S-SN 106A receiving one or more measurement results from the UE 102 that are above (or below) one or more predetermined thresholds, or calculating a filtered result (from the measurement result(s)) that is above (or below) a predetermined threshold. In another example, the suitable event can be that the UE 102 is moving toward the T-SN 106B. In yet another example, the suitable event can be one or more measurement results, generated or obtained by the S-SN 106A based on measurements of signals received from the UE 102, being above (or below) one or more predetermined thresholds.

[0139] In response to the determination 504A, the S-SN 106A sends 505A an SN Change Required message, which includes a DAPS request indicator, to the MN 104. In response, the MN 104, in coordination with the S-SN 106A, T-SN 106B, and UE 102, performs 560A a DAPS PSCell change preparation procedure, similar to the DAPS PSCell change preparation procedure 460A. As a result, the UE 102 and the S-SN 106A continue 520A communicating with each other (i.e., the UE 102 remains in DC with the MN 104), similar to event 420A, while the UE 102 attempts to perform DAPS PSCell change to the T-SN 106B via T-PSCell 126B.

[0140] The UE 102, in coordination with the MN 104, S-SN 106A, T-SN 106B, performs 550A a DAPS PSCell change and DAPS release procedure, similar to the DAPS PSCell change and DAPS release procedure 450A. As a result, the UE 102 stops 536A communicating with the S-SN 106A, similar to event 436A, and optionally releases the S-SN configuration.

[0141] Referring now to Fig. 5B, in a DAPS PSCell change scenario 500B, the base station 104 again operates as an MN for the UE 102, the base station 106A again operates as an S- SN for the UE 102, and the base station 106B again operates as a T-SN for the UE 102, similar to scenario 500A of Fig. 5A. Whereas the MN 104 in Fig. 5A proceeds to perform 560A a DAPS PSCell change procedure in response to receiving a DAPS request indicator from the S-SN 106A, the MN 104 in Fig. 5B proceeds to perform a non-DAPS PSCell change procedure despite receiving the DAPS request indicator.

[0142] Initially, the UE 102 in DC communicates 502B data with the MN 104 via PCell 124 by using an MN configuration, and with the S-SN 106A via PSCell 126A by using an S- SN configuration, similar to event 502A.

[0143] Later in time, the S-SN 106A determines 504B to initiate DAPS PSCell change involving an SN change for the T-SN 106B and the UE 102 to communicate via a T-PSCell 126B, similar to event 504A.

[0144] In response to the determination 504B, the S-SN 106A sends 505B an SN Change Required message, which includes a DAPS request indicator, to the MN 104, similar to event 505A. In some implementations, despite receiving the DAPS request indicator, the MN 104 may determine 507B to not perform a DAPS PSCell change procedure if the MN 104 detects a certain condition. For example, the MN 104 may be aware that the S-SN 106A does not support DAPS PSCell change. In another example, the MN 104 may be aware that the S-SN 106A and T-SN 106B are manufactured by or are otherwise associated with different vendors, or are operating with different software or firmware versions. The MN 104 may be preconfigured to not perform a DAPS PSCell change procedure because of these differences. In response to the determination 507B, the MN 104 sends 510B an SN Addition Request message excluding the DAPS request indicator to the T-SN 106B, unlike event 410A in which the SN Addition Request message includes the DAPS request indicator. Thus, the RAN (i.e., MN 104, S-SN 106A, and T-SN 106B) can support a legacy PSCell change preparation procedure (i.e., a non-DAPS PSCell change preparation procedure).

[0145] In response, the T-SN 106B generates 514B a T-SN configuration (i.e., the T-SN 106B does not also generate a DAPS PSCell change configuration or a DAPS SN change indicator). As such, the T-SN 106B, in coordination with the MN 104, S-SN 106A, and UE 102, performs 560A a non-DAPS PSCell change preparation procedure, similar to the non- DAPS PSCell change preparation procedure 460B.

[0146] As a result, the UE 102 and the S-SN 106A stop 520B communicating with each other (i.e., the UE 102 remains in DC with the MN 104), similar to event 420B, while the UE 102 attempts to perform non-DAPS PSCell change to the T-SN 106B via T-PSCell 126B.

[0147] The UE 102, in coordination with the MN 104, S-SN 106A, T-SN 106B, then performs 550B a non-DAPS PSCell change and release procedure, similar to the non-DAPS PSCell change and release procedure 450B.

[0148] In Fig. 6, in a DAPS PSCell change scenario 600, the base station 104 operates as an MN for the UE 102, and the base station 106A operates as an SN for the UE 102. The SN 106A includes a CU 172 for the UE 102, and two DUs 174 that operate as a source secondary DU (SS-DU) 174A for the UE 102 and a target secondary DU (TS-DU) 174B for the UE 102, respectively. Alternatively, although not illustrated in Fig. 6, a single base station serves the UE 102, and includes the CU 172, SS-DU 174A, TS-DU 174B, and an additional master DU (M-DU).

[0149] Initially, the UE 102 in DC communicates 602 data with the MN 104 via cell 122 and the SN 106A (which includes the CU 172 and SS-DU 174A) via PSCell 123 by using a CU configuration and an SS-DU configuration. Alternatively, if a single base station serves the UE 102, the UE 102 in DC communicates 602 data with the M-DU via a cell (not shown in Fig. 1A) and both the CU 172 and SS-DU 174A via PSCell 123.

[0150] Later in time, the CU 172 determines 604 to initiate DAPS PSCell change for the TS-DU 174B and the UE 102 to communicate via PSCell 126A, e.g., blindly or in response to detecting a suitable event, similar to those described with respect to Fig. 3A. For example, the CU 172 initiates DAPS PSCell change in response to measurement result(s) obtained by the CU 172 from measurements on signals received from the UE 102 via SS-DU 174A.

[0151] In response to the determination 604, the CU 172 sends 606 a UE Context Setup Request message to the TS-DU 174B. In response, the TS-DU 174B sends 608 a UE Context Setup Response message including a full TS-DU configuration to the CU 172. In turn, the CU 172 generates 614 an RRC reconfiguration message which includes the full TS-DU configuration and a DAPS PSCell change configuration or an indication for the DAPS PSCell change configuration in a field or an IE. Then the CU 172 sends 616 the RRC reconfiguration message to the SS-DU 174A, which in turn transmits 618 the RRC reconfiguration message to the UE 102.

[0152] The DAPS PSCell change configuration enables the UE 102 to use a DAPS to communicate with the SS-DU 174A via PSCell 123 as well as TS-DU 174B via T-PSCell 126A using the full TS-DU configuration during and after a successful DAPS PSCell change. As such, in response to the RRC reconfiguration message, the UE 102 and the SN 106A continue 620 communicating with each other via the SS-DU 174A by using the SS-DU configuration, while the UE 102 attempts to perform DAPS PSCell change to the TS-DU 174B via T-PSCell 126A in accordance with the full TS-DU configuration included in the RRC reconfiguration message. In attempting to perform the DAPS PSCell change, the UE 102 initiates 622 a random access procedure with the TS-DU 174B, e.g., by using one or more random access configurations in the full TS-DU configuration. After gaining access to a channel, the UE 102 transmits 623 an RRC reconfiguration complete message to the TS-DU 174B during or after successfully completing the random access procedure, which in turn sends 624 the RRC reconfiguration complete message to the CU 172. After the TS-DU 174B identifies the UE 102 during the random access configuration, the UE 102 communicates 626 control signals and data with the CU 172 via the TS-DU 174B by using the full TS-DU configuration included in the RRC reconfiguration message. If the RRC reconfiguration message includes configurations (e.g., DAPS PSCell change configuration) generated by the CU 172, the UE 102 communicates 626 with the CU 172 via the TS-DU 174B by using the configurations generated by the CU 172.

[0153] After receiving 624 the RRC reconfiguration complete message, the CU 172 stops 630 communicating with the UE 102 via the SS-DU 174A. The CU 172 can then send 631 an RRC reconfiguration message that includes a DAPS release indicator to the TS-DU 174B, which in turn can send 632 the RRC reconfiguration message to the UE 102. In some implementations, the CU 172 stops 630 communicating with the UE 102 after transmitting the RRC reconfiguration message to the TS-DU 174B. In response to the RRC reconfiguration message, the UE 102 can transmit 633 an RRC reconfiguration complete message to the TS-DU and stop 636 communicating with the SS-DU 174A. In turn, the TS- DU 174B can send 634 the RRC reconfiguration complete message to the CU 172.

[0154] As the UE 102 no longer needs to use the DAPS to continue communicating with the SS-DU 174 A, the CU 172 can perform 640 a UE Context Release procedure with the SS- DU 174A in response to the RRC reconfiguration complete message. Particularly, the CU 172 sends a UE Context Release Command message to the SS-DU 174A, which in turn sends a UE Context Release Complete message to the CU 172 and stops communicating with the UE 102. By performing the UE Context Release procedure in response to the RRC reconfiguration complete message, the CU 172 maintains the UE context longer relative to a non-DAPS PS Cell change procedure when performing a DAPS PS Cell change procedure.

The events 622, 623, 624, 626, 630, 631, 632, 633, 634, 640 are collectively referred to in Fig. 6 as the DAPS PSCell change and DAPS release procedure 650.

[0155] In some implementations, the CU 172 in event 616 can send a UE Context Modification Request message including the RRC reconfiguration message to the SS-DU 174A. The SS-DU 174A in turn can send a UE Context Modification Response message to the CU 172. In some implementations, the CU 172 can indicate not to stop data transmission to the UE 102 in the Context Modification Request message in response to the determination 604, so that the SS-DU 174A continues communicating with the UE 102. For example, the CU 172 may not include a “Transmission Action Indicator” IE in the Context Modification Request message, or include a “Transmission Action Indicator” IE set to “restart” in the Context Modification Request message to indicate not to stop data transmission to the UE 102. In other implementations, the CU 172 can include an IE indicating DAPS PSCell change in the Context Modification Request message so that the SS-DU 174A continues communicating with the UE 102. In yet other implementations, the CU 172 in event 616 can send a DL RRC Message Transfer message (instead of the UE Context Modification Request message) including the RRC reconfiguration message to the SS-DU 174A.

[0156] Fig. 7 is a flow diagram depicting an example method 700, implemented in a RAN ( e.g ., base station 104, base station 106A, base station 106B), for preparing a user device (. e.g ., UE 102) to perform a DAPS procedure (i.e., DAPS handover or DAPS PSCell change).

[0157] At block 702, the RAN determines to initiate a DAPS procedure (e.g., in any one of events 304A, 304B, 404A, 504A, 604).

[0158] At block 704, the RAN transmits, to the user device, a full configuration and a DAPS configuration in response to the determination at block 702 (e.g., in any one of events 316A, 316B, 417A, 560A, 618). In some implementations, the full configuration can be a full T-DU configuration, a full TS-DU configuration, or a full T-SN configuration. [0159] Fig. 8 is a flow diagram depicting an example method 800, implemented in a base station ( e.g ., S-BS 104, MN 104), for preparing a user device ( e.g ., UE 102) to perform a DAPS procedure (i.e., DAPS handover or DAPS PSCell change) or a non-DAPS procedure (i.e., non-DAPS handover or non-DAPS PSCell change).

[0160] At block 802, the base station determines to initiate a DAPS procedure (e.g., in any one of events 304A, 404A).

[0161] At block 804, the base station determines whether the user device supports the DAPS procedure. The user device can indicate support of the DAPS procedure with a DAPS capability field. Separate DAPS capability indicators can be used for indicating support of DAPS handover and DAPS PSCell change. If the user device supports DAPS handover, the user device can indicate support of DAPS handover in a DAPS capability indicator for DAPS handover. If the user device supports DAPS PSCell change, the user device can indicate support of DAPS PSCell change in a DAPS capability indicator for DAPS PSCell change. The base station can receive the DAPS capability indicator(s) from the user device, another base station or a core network, to determine whether the user device supports the corresponding DAPS procedure. In some implementations, the user device can include the DAPS capability indicator(s) in a UE-EUTRA-Capability IE or a UE-NR-Capability IE, which the user device can transmit in a UECapabilitylnformation message to the base station. In other implementations, the base station can receive the UE-EUTRA-Capability IE or UE- NR-Capability IE from another base station or a core network.

[0162] If the base station determines that the user device does not support the DAPS procedure (e.g., the base station does not receive the DAPS capability indicator of the user device), the base station at block 806 generates an interface request message to request a non- DAPS procedure, and at block 810 proceeds to send the interface request message to a target base station (e.g., T-BS 106B, T-SN 106B).

[0163] Otherwise, if the base station determines that the user device supports the DAPS procedure (e.g., the base station receives the DAPS capability indicator of the user device), the base station at block 808 further determines whether the target base station supports the DAPS procedure. In some implementations, the base station may be preconfigured to be aware whether the target base station supports the DAPS procedure. In other implementations, the base station can be informed by a network node (e.g., an O&M node) whether the target base station supports the DAPS procedure. If the base station determines that the target base station does not support the DAPS procedure, the base station proceeds to generate the interface request message to request the non-DAPS procedure and send the interface request message to the target base station, at blocks 806 and 810, respectively. In this way, rather than generating an interface request message to request a DAPS procedure to the target base station that is unable to handle a DAPS procedure, the base station provides an interface request message to request a non-DAPS procedure so that target base station may provide a configuration for the user device to perform the non-DAPS procedure.

[0164] Otherwise, if the base station determines that the target base station either supports the DAPS procedure or is unaware whether the target base station supports the DAPS procedure, the base station at block 809 generates an interface request message to request the DAPS procedure, and at block 810 proceeds to send the interface request message to the target base station ( e.g ., in any one of events 306A, 410A). The interface request message can be a Handover Request message that includes a DAPS request indicator, or an SN Addition Request message including a DAPS request indicator.

[0165] Fig. 9 is a flow diagram depicting an example method 900, implemented in a base station (e.g., S-BS 104, MN 104), for preparing a user device (e.g., UE 102) to perform a DAPS procedure (i.e., DAPS handover or DAPS PSCell change) or a non-DAPS procedure (i.e., non-DAPS handover or non-DAPS PSCell change).

[0166] At block 902, the base station determines to initiate a DAPS procedure (e.g., in any one of events 304A, 404A), similar to block 802.

[0167] At block 904, the base station determines whether a target base station (e.g., T-BS 106B, T-SN 106B) belongs to the same vendor as the base station. Typically, different vendors generate RRC configurations (e.g., DAPS handover configuration, DAPS PSCell change configuration) in different manners, and therefore base stations operated by different vendors may not be compatible to properly handle RRC configurations exchanges. For example, the base station may be preconfigured to be aware that the target base station is manufactured by or otherwise associated with a different vendor. In another example, the base station can be informed by a network node (e.g., an O&M node) that the base station and target base station are manufactured by or otherwise associated with different vendors. If the base station determines that the target base station does not belong to the same vendor, the base station at block 906 generates an interface request message to request a non-DAPS procedure, and at block 910 proceeds to send the interface request message to the target base station, similar to blocks 806 and 810, respectively.

[0168] Otherwise, if the base station determines that the target base station belongs to the same vendor, the base station at block 908 further determines whether the target base station supports the DAPS procedure, similar to block 808. If the base station determines that the target base station does not support the DAPS procedure, the base station proceeds to block 906.

[0169] Otherwise, if the base station determines that the target base station either supports the DAPS procedure or is unaware whether the target base station supports the DAPS procedure, the base station at block 909 generates an interface request message to request the DAPS procedure, and at block 910 proceeds to send the interface request message to the target base station (e.g., in any one of events 306A, 410A), similar to blocks 809 and 810, respectively.

[0170] Fig. 10 is a flow diagram depicting an example method 1000, implemented in a RAN (e.g., CU 172 or base station 104), for preparing a user device (e.g., UE 102) to perform a DAPS procedure (i.e., DAPS handover or DAPS PSCell change) or a non-DAPS procedure (i.e., non-DAPS handover or non-DAPS PSCell change).

[0171] At block 1002, the RAN determines whether to initiate a DAPS procedure. To make such a determination, the RAN at block 1004 determines whether the DAPS procedure would require coordination between two base stations.

[0172] If the RAN determines that the DAPS procedure would involve a second base station, such that a DAPS -supported user device stops communicating with the currently serving base station after communicating with the second base station, the RAN at block 1006 determines to initiate a non-DAPS procedure. In this way, even if 3GPP does not support ROHC context transfer from a base station currently serving the user device to the second base station, the RAN avoids initiating a DAPS procedure that may cause the user device to experience communication issues with the second base station due to the lack of ROHC context continuity.

[0173] If the base station determines that the DAPS procedure would not involve a second base station, the RAN at block 1008 determines to initiate a DAPS procedure (e.g., in event 304B, 604). In some implementations, the CU 172 may determine that a target DU (e.g., T-

DU 174B) or a target cell of the target DU belongs to the CU 172 (i.e., not the second base station) based on measurement result(s) of the target DU or target cell received from the UE 102. For example, if the CU 172 is preconfigured with a list of DU identities (or cell identities) that belong to the CU 172, or is otherwise aware of the DU identities (or cell identities), the CU 172 can compare the identity of target DU or target cell contained in the measurement result(s) with the list. If the target DU or target cell is on the list, the CU 172 can determine that the target DU or target cell belongs to the CU 172.

[0174] Fig. 11 is a flow diagram depicting an example method 1100, implemented in a source base station ( e.g ., S-BS 104), for preparing a user device (e.g., UE 102) to perform a DAPS procedure (i.e., DAPS handover or DAPS PSCell change) or a non-DAPS procedure (i.e., non-DAPS handover or non-DAPS PSCell change).

[0175] At block 1102, the source base station determines whether to initiate a DAPS procedure. To make such a determination, the source base station at block 1104 determines whether the source base station configured the user device to perform ROHC such that the user device compresses or decompresses headers of data packets transmitted or received on a

DRB.

[0176] If the source base station determines that the user device is configured to perform ROHC, the source base station at block 1106 generates an interface request message to request a non-DAPS procedure. The interface request message may be a SN Addition Request message that excludes a DAPS request indicator, for example. The source base station can send the interface request message to a target base station (e.g., T-BS 106B, T-SN 106B, T-CU 172). In response, the target base station and source base station can prepare the user device for the non-DAPS procedure.

[0177] If the source base station determines that the user device is not configured to perform ROHC, but is otherwise configured with DAPS, the source base station at block 1008 generates an interface request message to request a DAPS procedure (e.g., in any one of events 306A, 410A). The interface request message may be a Handover Request message that includes a DAPS request indicator, for example. The source base station can send the interface request message to the target base station. In response, the target base station and source base station can prepare the user device for the DAPS procedure.

[0178] Fig. 12 is a flow diagram depicting an example method 1200, implemented in a RAN (e.g., a RAN including base station 104, base station 106A, base station 106B), for configuring a user device (e.g., the UE 102), with a full configuration, to prepare the user device to perform a DAPS procedure (i.e., DAPS handover or DAPS PSCell change).

[0179] In the method 1200, at block 1202, the RAN determines, while the user device is operating in a cell (e.g., cell 124) using a previously received configuration (e.g., S-BS configuration), to provide the full configuration to the user device for a DAPS procedure (e.g., in any one of events 312A, 312B, 412A, 560A, 618).

[0180] At block 1204, the RAN identifies at least a target cell (e.g., cell 126) for the full configuration (e.g., in any one of events 312A, 312B, 412A, 560A, 618).

[0181] At block 1206, the RAN transmits the full configuration to the user device, to cause the user device to execute the DAPS procedure to communicate via the target cell using the full configuration (e.g., in any one of events 316A, 316B, 417A, 560A, 618).

[0182] Fig. 13 is a flow diagram depicting an example method 1300, implemented in a user device (e.g., the UE 102), for receiving a full configuration from a RAN (e.g., a RAN including base station 104, base station 106A, base station 106B) to perform a DAPS procedure (i.e., DAPS handover or DAPS PSCell change).

[0183] In the method 1300, at block 1302, the user device receives, from the RAN, the full configuration to execute a DAPS procedure (e.g., in any one of events 316A, 316B, 417 A, 560A, 618).

[0184] At block 1304, the user device executes the DAPS procedure in response to receiving the full configuration (e.g., in any one of events 322A, 322B, 422A, 550A, 650).

[0185] Fig. 14 is a flow diagram depicting an example method 1400, implemented in a RAN (e.g., a RAN including base station 104, base station 106B), for preparing a DAPS procedure or a non-DAPS procedure for a user device (e.g., the UE 102) to switch from a source base station (e.g., S-BS 104, MN 104) to a target base station (e.g., T-BS 106B, T-SN 106B) according to whether a condition for executing the non-DAPS procedure is satisfied.

[0186] In the method 1400, at block 1402, the RAN determines that the user device is to switch from a first cell of a source base station to a second cell of a target base station (e.g., in any one of events 802, 902, 1002, 1102).

[0187] At block 1404, the RAN determines whether the UE is to execute a DAPS procedure or a non-DAPS procedure for switching to the second cell (e.g., in any one of events 804, 806, 904, 1004, 1104). For example, the RAN can determine whether the UE is to execute a DAPS procedure or a non-DAPS procedure for switching to the second cell by determining that the user device does not support the DAPS procedure, and/or is configured to compress or decompress headers of data packets transmitted or received on a DRB. As another example, the RAN can determine whether the UE is to execute a DAPS procedure or a non-DAPS procedure for switching to the second cell by determining that the target base station does not support the DAPS procedure, or that the source base station and the target base station belong to different vendors.

[0188] In response to the determining that the UE is to execute the non-DAPS procedure, the RAN at block 1406 transmits, to the user device, a configuration to execute the non- DAPS procedure ( e.g ., in any one of events 806, 810, 906, 910, 1006, 1106). Otherwise, the RAN at block 1408 determines to execute the non-DAPS procedure, and proceeds to any one of events 702, 802, 902, 1002, or 1102.

[0189] The following description may be applied to the description above.

[0190] A user device in which the techniques of this disclosure can be implemented (e.g., the UE 102) can be any suitable device capable of wireless communications 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, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an internet-of-things (IoT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0191] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may 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 may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., 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.) to perform certain operations. A hardware module may also comprise programmable logic or circuitry ( e.g ., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0192] When implemented in software, the techniques can be provided as part of the 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.

[0193] Upon reading this disclosure, those of skill in the art will appreciate still additional and alternative structural and functional designs for handling mobility between base stations through the principles disclosed herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those of ordinary skill in the art, may be made in the arrangement, operation and details of the method and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.

[0194] Example 1. A method in a radio access network (RAN) capable of providing a full configuration related to a radio connection to a user device (UE) and a delta configuration which the UE can apply to a previously received configuration, the method comprising: determining, by processing hardware and while the UE is operating in a cell using the previously received configuration, to provide the full configuration to the UE for a dual active protocol stack (DAPS) procedure; identifying, by the processing hardware, at least a target cell for the full configuration; and transmitting, by the processing hardware and to the UE, the full configuration, to cause the UE to execute the DAPS procedure to communicate via the target cell using the full configuration.

[0195] Example 2. The method of example 1, wherein the DAPS procedure is a DAPS handover procedure.

[0196] Example 3. The method of example 2, further comprising: sending, by a source master node (MN) of the RAN and to a target MN of the RAN, a request specifying the DAPS procedure for configuring the target cell, to cause the target MN to generate the full configuration.

[0197] Example 4. The method of example 3, further comprising: receiving, by the source MN and from the target MN, the full configuration.

[0198] Example 5. The method of example 4, further comprising: transmitting, by the source MN and to the UE, the full configuration via a handover command message, to cause the UE to handover to the target MN and communicate with the target MN using the full configuration.

[0199] Example 6. The method of example 2, further comprising: receiving, by a centralized unit (CU) of the RAN and from a target distributed unit (DU) of the RAN, the full configuration, to cause the CU to generate a handover command message including the full configuration.

[0200] Example 7. The method of example 6, further comprising: sending, by the CU and to a source DU of the RAN, the handover command message.

[0201] Example 8. The method of example 7, further comprising: transmitting, by the source DU and to the UE, the handover command message, to cause the UE to handover to the target DU and communicate with the target DU using the full configuration.

[0202] Example 9. The method of example 1, wherein the DAPS procedure is a DAPS primary secondary cell (PSCell) change procedure.

[0203] Example 10. The method of example 9, further comprising: sending, by a master node (MN) of the RAN and to a target secondary node (SN) of the RAN, a request specifying the DAPS procedure for configuring the target cell, to cause the target SN to generate the full configuration.

[0204] Example 11. The method of example 9, further comprising: determining, by the source SN, that the UE is to execute the DAPS procedure.

[0205] Example 12. The method of examples 10 or 11, further comprising: receiving, by the MN and from the target SN, the full configuration.

[0206] Example 13. The method of example 12, further comprising: transmitting, by the MN and to the UE, the full configuration via a reconfiguration message, to cause the UE to handover to the target SN and communicate with the target SN using the full configuration. [0207] Example 14. The method of example 12, further comprising: sending, by the MN and to the source SN, an SN request message, to cause the source SN to continue communicating with the UE while the UE is executing the DAPS procedure.

[0208] Example 15. The method of example 14, further comprising: receiving, by the MN and from the source SN, an SN request acknowledgement message indicating that the source SN accepted the SN request message.

[0209] Example 16. The method of any one of examples 12 through 15, wherein transmitting, by the MN and to the UE, the full configuration comprises transmitting an indication of the full configuration.

[0210] Example 17. The method of example 9, further comprising: receiving, by a CU of the RAN and from a target DU of the RAN, the full configuration, to cause the CU to generate a reconfiguration message including the full configuration.

[0211] Example 18. The method of example 17, further comprising: sending, by the CU and to a source DU of the RAN, the reconfiguration message.

[0212] Example 19. The method of example 18, further comprising: transmitting, by the source DU and to the UE, the reconfiguration message, to cause the UE to handover to the target DU and communicate with the target DU using the full configuration.

[0213] Example 20. A method in a RAN capable of enabling execution of a DAPS procedure and a non-DAPS procedure at a UE, the method comprising: determining, by processing hardware, that the UE is to switch from a first cell of a source base station to a second cell of a target base station; determining, by the processing hardware, whether the UE is to execute the DAPS procedure or the non-DAPS procedure for switching to the second cell; in response to the determining that the UE is to execute the non-DAPS procedure, transmitting, by the processing hardware and to the UE, a configuration to execute the non- DAPS procedure.

[0214] Example 21. The method of example 20, wherein determining that the UE is to execute the non-DAPS procedure includes at least one of: (i) determining that the UE does not support the DAPS procedure; (ii) determining that the target base station does not support the DAPS procedure; (iii) determining that source base station and the target base station belong to different vendors; (iv) determining that execution of the non-DAPS procedure at the UE requires the UE to switch from the source base station to the target base station; or (v) determining that the UE is configured to compress or decompress headers of data packets transmitted or received on a data radio bearer (DRB).

[0215] Example 22. The method of examples 20 or 21, wherein the source base station sends an interface request message to the target base station to initiate the non-DAPS procedure.

[0216] Example 23. The method of any one of examples 20 through 22, wherein the DAPS procedure is a DAPS PSCell change procedure.

[0217] Example 24. The method of example 23, wherein determining that the UE is to execute the non-DAPS procedure is performed by the target base station.

[0218] Example 25. The method of example 23, wherein determining that the UE is to execute the non-DAPS procedure is performed by an MN.

[0219] Example 26. One or more base stations comprising processing hardware and configured to implement a method of any of the preceding examples.

[0220] Example 27. A method in a UE capable of receiving a full configuration related to a radio connection to a RAN and a delta configuration which the UE can apply to a previously received configuration from the RAN, the method comprising: receiving, by processing hardware and from the RAN, the full configuration to execute a DAPS procedure; and executing, by the processing hardware, the DAPS procedure in response to receiving the full configuration.

[0221] Example 28. The method of example 27, wherein receiving the full configuration comprises receiving the full configuration in a handover command message.

[0222] Example 29. The method of examples 27 or 28, wherein the DAPS procedure is a DAPS handover procedure.

[0223] Example 30. The method of example 29, wherein the DAPS handover procedure causes the UE to switch between: (i) a first MN and a second MN when the UE operates in single connectivity (SC); or (ii) a first DU of a distributed base station and a second DU of the distributed base station.

[0224] Example 31. The method of example 27, wherein receiving the full configuration comprise receiving an indication of the full configuration. [0225] Example 32. The method of example 27, wherein receiving the full configuration comprises receiving the full configuration in a reconfiguration message.

[0226] Example 33. The method of any one of examples 27, 31 or 32, wherein the DAPS procedure is a DAPS PSCell change procedure.

[0227] Example 34. The method of example 33, wherein the DAPS PSCell change procedure causes the UE to switch between: (i) a first SN and a second SN; or (ii) a first DU of a distributed base station and a second DU of the distributed base station.

[0228] Example 35. A UE comprising processing hardware and configured to implement a method of any one of examples 27 through 34.

Claims

What is claimed is:

1. A method in a radio access network (RAN) capable of providing a full configuration related to a radio connection to a user device (UE) and a delta configuration which the UE can apply to a previously received configuration, the method comprising: determining, by processing hardware and while the UE is operating in a cell using the previously received configuration, to provide the full configuration to the UE for a dual active protocol stack (DAPS) procedure; identifying, by the processing hardware, at least a target cell for the full configuration; and transmitting, by the processing hardware and to the UE, the full configuration, to cause the UE to execute the DAPS procedure to communicate via the target cell using the full configuration.

2. The method of claim 1, wherein the DAPS procedure is a DAPS handover procedure.

3. The method of claim 2, further comprising: sending, by a source master node (MN) of the RAN and to a target MN of the RAN, a request specifying the DAPS procedure for configuring the target cell, to cause the target MN to generate the full configuration; receiving, by the source MN and from the target MN, the full configuration; and transmitting, by the source MN and to the UE, the full configuration via a handover command message, to cause the UE to handover to the target MN and communicate with the target MN using the full configuration.

4. The method of claim 2, further comprising: receiving, by a centralized unit (CU) of the RAN and from a target distributed unit (DU) of the RAN, the full configuration, to cause the CU to generate a handover command message including the full configuration; sending, by the CU and to a source DU of the RAN, the handover command message; and transmitting, by the source DU and to the UE, the handover command message, to cause the UE to handover to the target DU and communicate with the target DU using the full configuration.

5. The method of claim 1, wherein the DAPS procedure is a DAPS primary secondary cell (PSCell) change procedure.

6. The method of claim 5, further comprising: sending, by a master node (MN) of the RAN and to a target secondary node (SN) of the RAN, a request specifying the DAPS procedure for configuring the target cell, to cause the target SN to generate the full configuration; determining, by the source SN, that the UE is to execute the DAPS procedure; receiving, by the MN and from the target SN, the full configuration; and transmitting, by the MN and to the UE, the full configuration or an indication of the full configuration via a reconfiguration message, to cause the UE to handover to the target SN and communicate with the target SN using the full configuration.

7. The method of claim 5, further comprising: receiving, by a CU of the RAN and from a target DU of the RAN, the full configuration, to cause the CU to generate a reconfiguration message including the full configuration; sending, by the CU and to a source DU of the RAN, the reconfiguration message; and transmitting, by the source DU and to the UE, the reconfiguration message, to cause the UE to handover to the target DU and communicate with the target DU using the full configuration.

8. A method in a RAN capable of enabling execution of a DAPS procedure and a non-DAPS procedure at a UE, the method comprising: determining, by processing hardware, that the UE is to switch from a first cell of a source base station to a second cell of a target base station; determining, by the processing hardware, whether the UE is to execute the DAPS procedure or the non-DAPS procedure for switching to the second cell; in response to the determining that the UE is to execute the non-DAPS procedure, transmitting, by the processing hardware and to the UE, a configuration to execute the non- DAPS procedure.

9. The method of claim 8, wherein determining that the UE is to execute the non- DAPS procedure includes at least one of:

(i) determining that the UE does not support the DAPS procedure;

(ii) determining that the target base station does not support the DAPS procedure;

(iii) determining that source base station and the target base station belong to different vendors;

(iv) determining that execution of the non-DAPS procedure at the UE requires the UE to switch from the source base station to the target base station; or

(v) determining that the UE is configured to compress or decompress headers of data packets transmitted or received on a data radio bearer (DRB).

10. The method of claims 8 or 9, wherein the DAPS procedure is a DAPS PSCell change procedure.

11. One or more base stations comprising processing hardware and configured to implement a method of any of the preceding claims.

12. A method in a UE capable of receiving a full configuration related to a radio connection to a RAN and a delta configuration which the UE can apply to a previously received configuration from the RAN, the method comprising: receiving, by processing hardware and from the RAN, the full configuration to execute a DAPS procedure; and executing, by the processing hardware, the DAPS procedure in response to receiving the full configuration.

13. The method of claim 12, wherein receiving the full configuration comprises one of: receiving the full configuration in a handover command message; receiving an indication of the full configuration; or receiving the full configuration in a reconfiguration message.

14. The method of claims 12 or 13, wherein the DAPS procedure is one of a DAPS handover procedure or a DAPS PSCell change procedure.

15. A UE comprising processing hardware and configured to implement a method of any one of claims 12 through 14.