EP4616637A1

EP4616637A1 - Managing a lower layer triggerred mobility at a user equipment

Info

Publication number: EP4616637A1
Application number: EP23847695.6A
Authority: EP
Inventors: Chih-Hsiang Wu; Ming-Hung Tao
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2022-12-16
Filing date: 2023-12-15
Publication date: 2025-09-17
Also published as: WO2024130053A1; CN120345298A

Abstract

A user equipment (UE) can implement a method for managing lower layer mobility protocol procedure(s). The method includes: receiving, from a radio access network (RAN) at the UE via a serving cell, a lower layer mobility configuration and a cell identifier; receiving, from the RAN at the UE via the serving cell, a lower layer mobility command activating the lower layer mobility configuration; in a first instance, performing a reestablishment procedure based on the cell identifier; and in a second instance, refraining from performing the reestablishment procedure based on the cell identifier.

Description

MANAGING A LOWER LAYER TRIGGERED MOBILITY AT A USER EQUIPMENT

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to and the benefit of the filing date of provisional U.S. Patent Application No. 63/387,931 entitled “MANAGING A LOWER LAYER TRIGGERED MOBILITY AT A USER EQUIPMENT,” filed on December 16, 2022. The entire contents of the provisional application are hereby expressly incorporated herein by reference.

FIELD OF THE DISCLOSURE

[0002] This disclosure relates to wireless communications and, more particularly, to enabling a fast serving cell change for a user equipment (UE) using a control signaling of a protocol layer lower than a radio resource control (RRC) protocol layer.

BACKGROUND

[0003] 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.

[0004] 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 technical specification (TS) 36.323) and New Radio (NR) (see 3GPP 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 signaling radio bearers (SRBs) and data radio bearers (DRBs) to the Radio Resource Control (RRC) sublayer. Generally speaking, in some scenarios, the UE and a base station use SRBs to exchange RRC messages as well as non-access stratum (NAS) messages. In further scenarios, the UE and base station use DRBs to transport data on a user plane. [0005] Depending on the scenario, UEs use several types of SRBs and DRBs. When operating in dual connectivity (DC), the cells associated with the base station operating 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). 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 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 using the lower-layer resources of only the MN can be referred as MCG DRBs, DRBs using the lower-layer resources of only the SN can be referred as SCG DRBs, and DRBs using the lower-layer resources of both the MCG and the SCG can be referred to as split DRBs.

[0006] The UE, in some scenarios, concurrently utilizes resources of multiple radio access network (RAN) nodes (e.g., base stations or components of a distributed base station), interconnected by a backhaul. When such 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 a master node (MN) that covers a primary cell (PCell), and the other base station operates as a secondary node (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 determine that the UE should establish a radio connection with another base station. For example, one base station determines to hand the UE over to the second base station and initiates a handover procedure.

[0007] When the UE moves from coverage area of one cell to another cell in a RAN, at some point a serving cell change will be performed for the UE. To perform the serving cell change, the RAN configures the UE to transmit Layer 3 (L3) measurement results. Based on L3 measurement results received from the UE, the RAN transmits an RRC reconfiguration message configuring Reconfiguration with Synchronization (e.g., the RRC reconfiguration message includes a ReconfigurationWithSync IE) for change of the serving cell (e.g., PCell or PSCell). In cases where the UE operates in carrier aggregation (CA) of at least one secondary cell (SCell) with the PCell or PSCell, the RAN has to release the at least one SCell due to the change of the PCell or PSCell. The serving cell change involves complete L2 (and LI) resets, leading to longer latency, larger overhead, and longer interruption time. Thus, it is desirable to develop new mobility techniques to reduce latency and overhead for fast serving cell change. However, it is not clear how to perform a serving cell using a lower layer signaling functionality (e.g., a lower layer mobility (LTM) functionality) at the UE and a disaggregated base station.

SUMMARY

[0008] An example embodiment of the techniques of this disclosure is a method implemented in a user equipment (UE), the method comprising: receiving, from a radio access network (RAN) at the UE via a serving cell, a lower layer mobility configuration and a cell identifier; receiving, from the RAN at the UE via the serving cell, a lower layer mobility command activating the lower layer mobility configuration; in a first instance, performing a reestablishment procedure based on the cell identifier; and in a second instance, refraining from performing the reestablishment procedure based on the cell identifier.

[0009] Another example embodiment of these techniques is a UE comprising processing hardware and configured to implement the method above.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Fig. 1A is a block diagram of an example system in which a radio access network (RAN) and a user device can implement the techniques of this disclosure for managing conditional procedures related to a secondary node (SN);

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

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

[0013] Fig. 2B is a block diagram of an example protocol stack according to which the UE of Fig. 1A communicates with a CU and a DU;

[0014] Fig. 3 is a messaging diagram of an example scenario where a base station configures a UE to perform a lower layer procedure for lower layer triggered mobility; [0015] Fig. 4 is a messaging diagram of an example scenario where a base station configures a UE to perform a lower layer procedure for inter-DU lower layer triggered mobility;

[0016] Fig. 5A is a messaging diagram of an example scenario where an MN operates in DC with an SN to perform a lower layer procedure for lower layer triggered mobility;

[0017] Fig. 5B is a messaging diagram of an example scenario similar to that of Fig. 5A, but in which the MN configures the UE directly;

[0018] Fig. 6A is a messaging diagram of an example scenario similar to that of Fig. 5A, but in which the lower layer procedure is an inter-DU lower layer procedure;

[0019] Fig. 6B is a messaging diagram of an example scenario similar to that of Fig. 5B, but in which the lower layer procedure is an inter-DU lower layer procedure;

[0020] Fig. 7A is a messaging diagram of an example scenario similar to that of Fig. 5A, but in which the base station operates as the MN (e.g., an M-DU) and the SN (e.g., an S-DU) to perform the lower layer procedure;

[0021] Fig. 7B is a messaging diagram of an example scenario similar to that of Fig. 7A, but in which the MN configures the UE directly;

[0022] Fig. 8A is a messaging diagram of an example scenario similar to that of Fig. 7A, but in which the cell change operation is an inter-DU cell change operation;

[0023] Fig. 8B is a messaging diagram of an example scenario similar to that of Fig. 7B, but in which the cell change operation is an inter-DU cell change operation;

[0024] Fig. 9A is a flow diagram depicting an example method, implemented in a UE, in which the UE receives a message including an indication of whether candidate cells are associated with a serving cell and then performs or refrains from performing a protocol procedure;

[0025] Fig. 9B is a flow diagram depicting an example method similar to that of Fig. 9A, but in which the UE receives a message either including an indication that the candidate cells are associated with the serving cell or excluding the indication;

[0026] Fig. 9C is a flow diagram depicting an example method similar to that of Fig. 9A, but in which the UE receives a message either including an indication that the candidate cells are not associated with the serving cell or excluding the indication; [0027] Fig. 10 is a flow diagram depicting an example method, implemented in a UE, in which the UE determines whether to perform or refrain from performing the protocol procedure based on whether the candidate cells are associated with the serving cell;

[0028] Fig. 11 A is a flow diagram depicting an example method, implemented in a UE, in which the UE receives a message including a first or second cell group identifier and then performs or refrains from performing a protocol procedure;

[0029] Fig. 1 IB is a flow diagram depicting an example method similar to that of Fig. 11 A, but in which the UE receives a first or second DU identifier;

[0030] Fig. 12A is a flow diagram depicting an example method, implemented in a UE, in which the UE determines whether to perform or refrain from performing the protocol procedure based on whether the candidate cells and the serving cell belong to the same cell group;

[0031] Fig. 12B is a flow diagram depicting an example method similar to that of Fig. 12A, but in which the UE determines whether to perform or refrain from performing the protocol procedure based on whether the candidate cells and the serving cell are operated by the same DU;

[0032] Fig. 13A is a flow diagram depicting an example method, implemented in a UE, in which the UE receives a message including a first or second container indicating whether candidate cells are associated with a serving cell and then performs or refrains from performing a protocol procedure;

[0033] Fig. 13B is a flow diagram depicting an example method similar to that of Fig. 13 A, but in which the UE the first or second container indicate whether the candidate cells and the serving cell belong to the same cell group; and

[0034] Fig. 13C is a flow diagram depicting an example method similar to that of Fig. 13 A, but in which the UE the first or second container indicate whether the candidate cells and the serving cell are operated by the same DU.

DETAILED DESCRIPTION OF THE DRAWINGS

[0035] Fig. 1A depicts an example wireless communication system 100 in which communication devices can implement these techniques. The wireless communication system 100 includes a UE 102, a base station (BS) 104, a base station 106 and a core network (CN) 110. The UE 102 initially connects to the base station 104. In some scenarios, the base station 104 can perform an SN addition to configure the UE 102 to operate in dual connectivity (DC) with the base station 104 and the base station 106. The base stations 104 and 106 operate as an MN and an SN for the UE 102, respectively.

[0036] In various configurations of the wireless communication system 100, the base station 104 can be implemented as a master eNB (MeNB) or a master gNB (MgNB), and the base station 106 can be implemented as a secondary gNB (SgNB). The UE 102 can communicate with the base station 104 and the base station 106 via the same RAT such as EUTRA or NR, or different RATs. When the base station 104 is an MeNB and the base station 106 is a SgNB, the UE 102 can be in EUTRA-NR DC (EN-DC) with the MeNB and the SgNB.

[0037] In some cases, an MeNB or an SeNB is implemented as an ng-eNB rather than an eNB. When the base station 104 is a Master ng-eNB (Mng-eNB) and the base station 106 is a SgNB, the UE 102 can be in next generation (NG) EUTRA-NR DC (NGEN-DC) with the Mng-eNB and the SgNB. When the base station 104 is an MgNB and the base station 106 is an SgNB, the UE 102 may be in NR-NR DC (NR-DC) with the MgNB and the SgNB. When the base station 104 is an MgNB and the base station 106 is a Secondary ng-eNB (Sng-eNB), the UE 102 may be in NR-EUTRA DC (NE-DC) with the MgNB and the Sng-eNB.

[0038] In the scenarios where the UE 102 hands over from the base station 104 to the base station 106, the base stations 104 and 106 operate as the source base station (S-BS) and a target base station (T-BS), respectively. The UE 102 can operate in DC with the base station 104 and an additional base station (not shown in Fig. 1A) for example prior to the handover. The UE 102 can continue to operate in DC with the base station 106 and the additional base station or operate in single connectivity (SC) with the base station 106, after completing the handover. The base stations 104 and 106 in this case operate as a source MN (S-MN) and a target MN (T-MN), respectively.

[0039] A core network (CN) 110 can be an evolved packet core (EPC) 111 or a fifthgeneration 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 a gNB that supports an NR radio interface as well as an NG interface for communicating with the 5GC 160. To directly exchange messages with each other during the scenarios discussed below, the base stations 104 and 106 can support an X2 or Xn interface. Among other components, the EPC 111 can include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. The SGW 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 PGW 116 provides connectivity from the UE to one or more external packet data networks, e.g., an Internet network and/or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. 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.

[0040] As illustrated in Fig. 1A, the base station 104 supports cell 124A, and the base station 106 supports a cell 126. The cells 124A and 126 can partially overlap, so that the UE 102 can communicate in DC with the base station 104 and the base station 106, where one of the base stations 104 and 106 is an MN and the other is an SN. The base station 104 can support additional cell(s) such as cells 124B and 124C, and the base station 106 can support additional cell(s) (not shown in Fig. 1A). The cells 124A, 124B and 124C can partially overlap, so that the UE 102 can communicate in carrier aggregation (CA) with the base station 104. The base station 104 can operate the cells 124A, 124B and 124C via one or more transmit and receive points (TRPs). More particularly, when the UE 102 is in DC with the base station 104 and the base station 106, one of the base stations 104 and 106 operates as an MeNB, an Mng-eNB or an MgNB, and the other operates as an SgNB or an Sng-eNB.

[0041] In general, the wireless communication system 100 can include any suitable number of base stations supporting NR cells and/or EUTRA cells. 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 also can 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.

[0042] With continued reference to Fig. 1A, the base station 104 is equipped with processing hardware 130 that can include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable memory storing instructions that the one or more general-purpose processors execute. Additionally or alternatively, the processing hardware 130 can include special-purpose processing units. The processing hardware 130 can include a PHY controller 132 configured to transmit data and control signal on physical downlink (DL) channels and DL reference signals with one or more user devices (e.g. UE 102) via one or more cells (e.g., the cell(s) 124A, 124B and/or 124C) and/or one or more TRPs. The PHY controller 132 is also configured to receive data and control signal on physical uplink (UL) channels and/or UL reference signals with the one or more user devices via one or more cells (e.g., the cell(s) 124A, 124B and/or 124C) and/or one or more TRPs. The processing hardware 130 in an example implementation includes a MAC controller 134 configured to perform MAC functions with one or more user devices. The MAC functions includes a random access (RA) procedure, managing UL timing advance for the one or more user devices, and/or communicating UL/DL MAC PDUs with the one or more user devices. The processing hardware 130 can further include an RRC controller 136 to implement procedures and messaging at the RRC sublayer of the protocol communication stack. For example, the RRC controller 136 may be configured to support RRC messaging associated with handover procedures, and/or to support the necessary operations when the base station 104 operates as an MN relative to an SN or as an SN relative to an MN. The base station 106 can include processing hardware 140 that is similar to processing hardware 130. In particular, components 142, 144, and 146 can be similar to the components 132, 134, and 136, respectively.

[0043] The UE 102 is equipped with processing hardware 150 that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and/or special-purpose processing units. The PHY controller 152 is also configured to receive data and control signal on physical DL channels and/or DL reference signals with the base station 104 or 106 via one or more cells (e.g., the cell(s) 124A, 124B, 124C and/or 126) and/or one or more TRPs. The PHY controller 152 is also configured to transmit data and control signal on physical UL channels and/or UL reference signals with the base station 104 or 106 via one or more cells (e.g., the cell(s) 124A, 124B, 124C and/or 126) and/or one or more TRPs. The processing hardware 150 in an example implementation includes a MAC controller 154 configured to perform MAC functions with base station 104 or 106. For example, the MAC functions includes a random access procedure, managing UL timing advance for the one or more user devices, and communicating UL/DL MAC PDUs with the base station 104 or 106. The processing hardware 150 can further include an RRC controller 156 to implement procedures and messaging at the RRC sublayer of the protocol communication stack.

[0044] In operation, the UE 102 in DC can use a radio bearer (e.g., a DRB or an SRB) that at different times terminates at the base station 104 (e.g., functioning as an MN) or the base station 106 (e.g., functioning as an SN). The UE 102 can apply one or more security keys when communicating on the radio bearer, in the uplink (UL) (from the UE 102 to a base station) and/or downlink (from a base station to the UE 102) direction.

[0045] Fig. IB depicts an example distributed implementation of a base station such as the base station 104 or 106. The base station in this implementation can include a centralized unit (CU) 172 and one or more distributed units (DUs) 174. The CU 172 is equipped with processing hardware that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and/or special-purpose processing units. In one example, the CU 172 is equipped with the processing hardware 130. In another example, the CU 172 is equipped with the processing hardware 140. The processing hardware 140 in an example implementation includes an SN RRC controller 142 configured to manage or control one or more RRC configurations and/or RRC procedures when the base station 106 operates as an SN. The DU 174 is also equipped with processing hardware that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and/or special-purpose processing units. In some examples, the processing hardware in an example implementation includes 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 106 operates as an MN or an SN. The process hardware may include further a physical layer controller configured to manage or control one or more physical layer operations or procedures. [0046] Fig. 2A illustrates, in a simplified manner, an example protocol stack 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, 106).

[0047] 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 an EUTRA PDCP sublayer 208 and, in some cases, to an 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 data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 in turn can provide data transfer services to Service Data Adaptation Protocol (SDAP) 212 or a radio resource control (RRC) sublayer (not shown in Fig. 2A). The UE 102, in some implementations, supports both the EUTRA and the NR stack as shown in Fig. 2A, to support handover between EUTRA and NR base stations and/or to support DC over EUTRA and NR interfaces. Further, as illustrated in Fig. 2A, the UE 102 can support layering of NR PDCP 210 over EUTRA RLC 206 A, and SDAP sublayer 212 over the NR PDCP sublayer 210.

[0048] 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.”

[0049] On a control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide signaling radio bearers (SRBs) or RRC sublayer (not shown in Fig. 2A) to exchange RRC messages or non-access-stratum (NAS) messages, for example. On a user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide Data Radio Bearers (DRBs) to support data exchange. Data exchanged on the NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets or Ethernet packets.

[0050] Fig. 2B illustrates, in a simplified manner, an example protocol stack 250, which the UE 102 can communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). The radio protocol stack 200 is functionally split as shown by the radio protocol stack 250 in Fig. 2B. The CU at any of the base stations 104 or 106 can hold all the control and upper layer functionalities (e.g., RRC 214, SDAP 212, NR PDCP 210), while the lower layer operations (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support connection to a 5GC, NR PDCP 210 provides SRBs to RRC 214, and NR PDCP 210 provides DRBs to SDAP 212 and SRBs to RRC 214.

[0051] Next, several example scenarios in which the base station operating in the system of Fig. 1A transmits a configuration to the UE 102 and later activates a configuration for communication between the UE 102 and base station. Generally speaking, events in Figs. 3- 7B that are similar are labeled with similar reference numbers (e.g., event 316 is similar to event 416 of Figs 4A and 4B, event 516 of Fig. 5A, event 517 of Fig. 5B, event 616 of Fig. 6A, event 617 of Fig. 6B, event 716 of Fig. 7A, and event 717 of Fig. 7B), with differences discussed below where appropriate. With the exception of the differences shown in the figures and discussed below, any of the alternative implementations discussed with respect to a particular event (e.g., for messaging and processing) may apply to events labeled with similar reference numbers in other figures.

[0052] Referring first to Fig. 3, in a scenario 300, the base station 104 includes a CU 172 and a DU 174, and the DU 174 operates the cell 124A. The UE 102 initially communicates 302 with the base station 104 on the cell 124A (e.g., using a first configuration). In some implementations, the UE 102 in carrier aggregation (CA) communicates with the DU 174 on the cell 124A and other cell(s) (e.g., cell 124D not shown in Fig. 1A) using the first configuration. The DU 174 operates the other cell(s). In other implementations, the UE 102 communicates with the DU 174 on the cell 124A only. In some implementations, the UE 102 communicates with the DU 174 on the cell 124A and/or other cell(s) via one or multiple TRPs. In some implementations, the cell 124A is a PCell. In such cases, the other cell(s) include SCell(s) and/or additional cell(s) associated with the PCell or an SCell. In other implementations, the cell 124A is an SCell, and one of the other cell(s) is a PCell. In such cases, the rest includes SCell(s) and/or additional cell(s) associated with the PCell or an SCell. In the following description, depending on the implementation, the base station 104 is the DU 174, the CU 172, or the DU 174 and CU 172.

[0053] In the event 302, the UE 102 can transmit UE PDUs and/or UE control signals to the base station 104 on the cell 124A and/or other cell(s) via one or multiple TRPs. In some implementations, the UE 102 communicates UE PDUs and/or DL PDUs with the base station 104 via radio bearers, which, depending on the implementation, include SRBs and/or DRB(s). In some implementations, the base station 104 configures the radio bearers for the UE 102. In some implementations, UL control signals include UL control information, channel state information, hybrid automatic repeat request (HARQ) acknowledgements (ACKs), HARQ negative ACKs, scheduling request(s), and/or sounding reference signal(s). Similarly, in some implementations, the UE 102 receives DL PDUs and/or DL control signals from the base station 104 on the cell 124A and/or other cell(s) via one or multiple TRPs. In some implementations, the DL control signals include downlink control information (DCIs) and reference signals (e.g., synchronization signal block, channel state information reference signal(s) (CSI-RS(s)), and/or tracking reference signal(s)). In some implementations, the base station 104 transmits the DCIs on physical downlink control channel(s) (PDCCH(s)), monitored by the UE 102, on the cell 124A and/or other cell(s) via one or multiple TRPs.

[0054] In some implementations, the first configuration includes physical layer configuration parameters, MAC configuration parameters, RLC configuration parameters, PDCP configuration parameters, measurement configuration parameters, and/or radio bearer configuration parameters. In some implementations, the first configuration includes a DU configuration. For example, the first configuration or the DU configuration is a CellGroupConfig IE (e.g., defined in 3GPP TS 38.331). In other implementations, the first configuration includes configuration parameters in the CellGroupConfig IE. In some implementations, the first configuration includes a CSl-MeasConfig IE, a MeasConfig IE, and/or a RadioBearerConfig IE (e.g., defined in 3GPP TS 38.331) or includes configuration parameters in the CSl-MeasConfig IE, MeasConfig IE, and/or RadioBearerConfig IE. In some implementations, the UE 102 receives the configuration parameters from the base station 104. In other implementations, the UE 102 receives a portion of the configuration parameters from a base station other than the base station 104 and the remaining portion of the configuration parameters from the base station 104.

[0055] While communicating with the base station 104, the UE 102 transmits 304 at least one measurement report to the DU 174. In some implementations, the at least one measurement report includes Layer 1 (LI) measurement report(s) and/or Layer 3 (L3) measurement report(s) for at least one serving cell of the UE 102 and/or at least one nonserving cell. For each of the L3 measurement report(s), the DU 174 transmits 306 a DU-to- CU message, including the L3 measurement report, to the CU 172. In some implementations, the DU-to-CU message(s) of the event 306 are Fl application protocol (F1AP) message(s) (e.g., UL RRC Message Transfer message(s)). In some implementations, the DU 174 does not transmit or refrains from transmitting the LI measurement report(s) to the CU 172. The at least one serving cell includes the cell 124A and/or other cell(s), and the at least one nonserving cell includes the cell 124B and/or cell 124C. In some implementations, the first configuration includes at least one measurement configuration. In some implementations, the UE 102 receives one or more RRC messages (e.g., RRCReconfiguration message(s)), including the at least one measurement configuration, from the CU 172 via the DU 174 in the event 302. In accordance with the at least one measurement configuration, the UE 102 performs measurements and transmits 304 the at least one measurement report to the DU 174. In some implementations, the at least one measurement configuration includes L3 measurement configuration(s) (e.g., MeasConfig IE(s)) and/or LI measurement configuration(s). In some implementations, the LI measurement configuration(s) (e.g., CS1- MeasConfig IE(s)) include LI measurement resource configuration(s) and/or LI measurement reporting configuration(s). In further implementation, the LI measurement resource configuration(s) configure resources of reference signal(s) (e.g., CSLRS(s)) for the UE 102 to measure and obtain LI measurement results. Lor example, the LI measurement resource configuration(s) are CSl-ResourceConfig IE(s). In another example, the LI measurement reporting configuration(s) configures way(s) the UE 102 uses to transmit LI measurement results/reports. Lor example, the LI measurement report configuration(s) are CSl-ReportConfig IE(s). As another example, the UE 102 transmits the L3 measurement report(s) to the CU 172 via the DU 174 in accordance with the L3 measurement configuration(s). The UE 102 transmits the LI measurement report(s) to the DU 174 in accordance with the LI measurement configuration(s) or LI measurement reporting configuration(s). In some implementations, the DU 174 does not transmit the LI measurement report(s) to the CU 172.

[0056] In some implementations, the LI measurement configuration(s) are new RRC IE(s) (e.g., defined in 3GPP TS 38.331) for a lower layer triggered mobility (LTM). In some implementations, the LI measurement resource configuration(s) are new RRC IE(s) (e.g., defined in 3GPP TS 38.331) for the LTM. In some implementations, the LI measurement reporting configuration(s) are new RRC IE(s) (e.g., defined in 3GPP TS 38.331) for the LTM. In some implementations, each of the LI measurement reporting configuration(s) includes a trigger event configuration configuring a trigger event to trigger the UE 102 to transmit a LI measurement report. If the UE 102 detects the trigger event, the UE 102 transmits a LI measurement report to the DU 174.

[0057] In some implementations, at least some of the LI measurement report(s) include at least one LI measurement result. In some implementations, the at least one LI measurement result includes at least one LI -reference signal received power (Ll-RSRP) value and/or at least one Ll-Signal to Interference Noise Ratio (Ll-SINR) value. Lor each of the LI measurement report(s), the UE 102 transmits a PUCCH transmission including the LI measurement report to the DU 174, in some implementations. That is, the UE 102 transmits each of the LI measurement report(s) on a PUCCH to the DU 174. In other implementations, for each of the LI measurement report(s), the UE 102 transmits a PUSCH transmission including the LI measurement report to the DU 174. That is, the UE 102 transmits each of the LI measurement report(s) on a PUSCH to the DU 174. In yet other implementations, the UE 102 transmits a portion of the LI measurement report(s) on PUCCH(s) and the rest of the LI measurement report(s) on physical UL shared channel(s) (PUSCH(s)) to the DU 174.

That is, for each of the portion of the LI measurement report(s), the UE 102 transmits a PUCCH transmission including the LI measurement report to the DU 174, and for each of the rest of the LI measurement report(s), the UE 102 transmits a PUSCH transmission including the LI measurement report to the DU 174. In some implementations, each of the LI measurement report(s) is a part of channel state information (CSI) (i.e., a CSI component) or the CSI. In some implementations, the UE 102 includes other CSI component(s) in at least some of the PUCCH transmission(s) and/or PUSCH transmission(s) described above. In some implementations, the other CSI component(s) include components such as a channel quality indicator (CQI), a Precoding Matrix Indicator (PMI), a CSI- RS Resource Indicator (CRI), a Synchronization Signal (SS)/Physical Broadcast Channel (PBCH) Resource Block Indicator (SSBRI), a Layer Indicator (LI), and/or a Rank Indicator (RI). In some implementations, the UE 102 does not transmit the LI measurement report(s) in the format for RRC message(s) to the DU 174.

[0058] In some implementations, each of the L3 measurement report(s) includes at least one L3 measurement result. In some implementations, the at least one L3 measurement result includes at least one RSRP (value) and/or at least one SINR (value). In some implementations, the UE 102 transmits each of the L3 measurement report(s) on a PUSCH to the CU 172 via the DU 174. In some implementations, each of the L3 measurement report(s) is an RRC message (e.g., MeasurementReport message). In some implementations, each of the L3 measurement configuration(s) includes a particular measurement identity (e.g., measld), and each of the L3 measurement report(s) includes a particular measurement identity in a particular L3 measurement configuration. In some implementations, when the CU 172 receives an L3 measurement report including a measurement identity and an L3 measurement result from the UE 102 via the DU 174, the CU 172 determines that the L3 measurement report is associated with an L3 measurement configuration identified by the measurement identity.

[0059] In some alternative implementations, for each of the at least one measurement report (e.g., LI measurement report(s)), the UE 102 transmits a MAC control element (CE), including the measurement report, to the DU 174 in the event 304. To transmit the MAC CE(s), the UE 102 generates one or more MAC PDUs, each including one or more of the MAC CE(s), for the DU 174 in the event 304.

[0060] It will be understood that “lower layer mobility,” “lower layer triggered mobility,” and “LTM” may be used interchangeably to refer to a procedure as described above. In particular LTM is a procedure in which a gNB receives LI measurement reports from UEs, and on the basis of such, the gNB changes serving cell(s) for UEs through, for example, MAC CE. The gNB prepares one or multiple candidate cells and provides the candidate cell configurations to the UE through RRC message. Then an LTM cell switch is triggered by selecting one of the candidate configurations as a target configuration for LTM by the gNB. The candidate cell configurations can be added, modified and released by network via RRC signaling. The following principles apply to LTM.

[0061] Candidate cell configuration can be provided as delta configurations on top of a reference configuration, which form a complete candidate cell configuration. The reference configuration is managed separately, and a UE stores the reference configuration as a separate configuration. The reference configuration can be empty. The complete candidate configuration is applied when the UE receives the candidate cell configuration before reception of the LTM cell switch command. However, UE implementation can postpone that step to the reception of the LTM cell switch command. In some implementations, the candidate configuration (e.g., which is complete) is applied and replaces the current UE configuration (e.g., at the time of reconfiguration execution/cell switch), by an RRC reconfiguration procedure that makes replacements of configuration but, depending on the implementation, does or does not reset RLC or PDCP. In alternative implementations, the candidate configuration (e.g., which can be a delta configuration) is applied to the current UE configuration (e.g., at the time of reconfiguration execution/cell switch), by legacy RRC reconfiguration procedure.

[0062] The complete candidate cell configuration is applied and replaces the current UE configuration at the time of reconfiguration execution. Although the reconfiguration procedure makes a replacement, it doesn’t necessarily reset MAC, RLC or PDCP layer. User plane is continued whenever possible (e.g. intra-DU), without reset, with the target to avoid data loss and the additional delay of data recovery. In some implementations, security is not updated in LTM. Subsequent LTM between candidates (i.e., UE does not release other candidate cell configurations after LTM is triggered) can be performed without RRC reconfiguration.

[0063] In some implementations, the UE 102 performs measurements on one or more reference signals in accordance with the at least one measurement configuration. In some implementations, the one or more reference signals include one or more Synchronization Signal (SS)/Physical Broadcast Channel (PBCH) Resource Blocks (SSBs) and/or one or more CSI-RSs. The UE 102 obtains the at least one LI measurement result and/or at least one L3 measurement result from the measurements. The DU 174 transmits the one or more reference signals on the cell 124A and other cell(s) (e.g., the cell 124B, the cell 124C, and/or other cell(s) not shown in Fig. 1A).

[0064] After (e.g., in response to) receiving one or some of the at least one measurement report from the UE 102, the base station 104 (i.e., the CU 172 or DU 174) determines to prepare a first cell (e.g., the cell 124B) for LTM for the UE 102. In some implementations, the base station 104 determines to prepare the first cell for the UE 102 because the at least one measurement report indicates that the first cell could be used by the base station 104 to communicate with the UE 102. In some implementations, the base station 104 determines to prepare the first cell for the UE 102 because the at least one measurement report indicates that the first cell qualifies to be a candidate cell that could be used for communication with the UE 102. In some implementations, if the L3 measurement report(s) indicates that signal strength and/or quality of the first cell is above a first predetermined threshold, is better than a strength and/or quality of the cell 124A, and/or is better than a strength and/or quality of the cell 124A by a first predetermined threshold, the CU 172 determines to prepare the first cell for the UE 102. In other implementations, if the LI measurement report(s) indicate that a signal strength and/or quality of the first cell is above a first predetermined threshold, is better than a signal strength and/or quality of the cell 124 A, and/or is better than a signal strength and/or quality of the cell 124A by a first predetermined threshold, the DU 174 determines to prepare the first cell for the UE 102. Alternatively, the base station 104 determines to prepare the first cell for the UE 102 regardless of whether a measurement report is received from the UE 102 or not.

[0065] In cases where the CU 172 determines to prepare the first cell, the CU 172 transmits 308 a first CU-to-DU message to the DU 174 to prepare the first cell for the UE 102. In some implementations, the CU 172 includes a cell identity (ID) of the first cell in the first CU-to-DU message to request the DU 174 to prepare the first cell for LTM for the UE 102. For example, the cell ID is a cell global identity (CGI). In another example, the cell ID is a portion of the CGI. In yet another example, the cell ID is a physical cell ID (PCI). In response to the first CU-to-DU message, the DU 174 generates a first DU configuration (referred to herein as DU configuration 1) for the UE 102, which configures the first cell for LTM. The DU 174 then transmits 310 a first DU-to-CU message, including the DU configuration 1, to the CU 172 in response to the first CU-to-DU message. In cases where the DU 174 determines to prepare the first cell, the DU 174 initiates transmission of the first DU-to-CU message to the CU 172 instead of in response to a CU-to-DU message received from the CU 172.

[0066] In some implementations, the DU 174 includes, in the first DU-to-CU message, the cell ID of the first cell associated with the DU configuration 1 to indicate that the DU configuration 1 is configured for or associated with the first cell. The CU 172 identifies that the DU configuration 1 is configured for or associated with the first cell. In some scenarios and implementations, the CU 172 includes additional cell ID(s) (e.g., cell ID(s) 2, ..., N) in the first CU-to-DU message to prepare additional cell(s) (e.g., cell(s) 2, ..., N) for LTM for the UE 102, and the DU 174 includes additional DU configuration(s) (e.g., DU configuration(s) 2, ..., N), each configuring a particular cell of the additional cell(s), as described below. In such cases, the DU 174 includes, in the first DU-to-CU message, the additional cell ID(s) respectively associated with the additional DU configuration(s) to indicate which DU configuration is associated with which cell (ID). The cell(s) 1 and/or 2, ..., N are candidate cell(s). [0067] After receiving the first DU-to-CU message, the CU 172 generates an RRC reconfiguration message (e.g., an RRCReconfiguration message), including the DU configuration 1, and transmits 316 a second CU-to-DU message including the RRC reconfiguration message, to the DU 174. In turn, the DU 174 transmits 318 the RRC reconfiguration message to the UE 102. In response, the UE 102 transmits 320 an RRC reconfiguration complete message (e.g., an RRCReconfigurationComplete message) to the DU 174, which in turn transmits 322 a second DU-to-CU message, including the RRC reconfiguration complete message, to the CU 172. In some implementations, the CU 172 performs security protection (e.g., integrity protection and/or encryption) on the RRC reconfiguration message. For example, the CU 172 generates a message authentication code for integrity (MAC-I) for the RRC reconfiguration message, encrypts the RRC reconfiguration message and the MAC-I to obtain an encrypted RRC reconfiguration message and an encrypted MAC-I, and transmits a PDCP PDU, including the encrypted RRC reconfiguration message and encrypted MAC-I, to the UE 102 via the DU 174 in the events 316 and 318. When the UE 102 receives the PDCP PDU from the CU 172 via the DU 174 (i.e., events 316 and 318), the UE 102 decrypts the encrypted RRC reconfiguration and encrypted MAC-I to obtain the RRC reconfiguration message and MAC-I and verifies whether the MAC-I is valid. If the UE 102 verifies that the MAC-I is invalid, the UE 102 discards or ignores the RRC reconfiguration message. In some implementations, the UE 102 performs an RRC connection reestablishment procedure in response to the invalid MAC-I. Otherwise, in some such implementations, if the UE 102 verifies the MAC-I is valid, the UE 102 processes the RRC reconfiguration. The UE 102 refrains from applying (i.e., executing) the DU configuration 1 until receiving a configuration activation command activating the DU configuration 1 (e.g., the event 330).

[0068] The events 316, 318, 320, 322 are collectively referred to in Fig. 3 as an LTM configuration delivery procedure 394.

[0069] In some implementations, the first CU-to-DU message is a UE Context Modification Request message, and the first DU-to-CU message is a UE Context Modification Response message or UE Context Modification Required message. In some cases where the first DU-to-CU message is a UE Context Modification Required message, the CU 172 transmits a UE Context Modification Confirm message to the DU 174 in response to UE Context Modification Required message. In some implementations, the second CU-to- DU message is a DE RRC Message Transfer message. In other implementations, the second CU-to-DU message is a UE Context Modification Request message, and the DU 174 transmits a second DU-to-CU message (e.g., UE Context Modification Response message) to the CU 172 in response to the second CU-to-DU message.

[0070] The events 308 (optional) and 310 are collectively referred to in Fig. 3 as an LTM preparation procedure 390.

[0071] In some implementations, the CU 172 includes the DU configuration 1 in a first container (e.g., a field/IE) and includes the first container in the RRC reconfiguration message of the events 316 and 318. In such cases, the CU 172 generates the first container. The first container is to indicate to the UE 102 not to apply the DU configuration 1 immediately. For example, the UE 102 receives an RRC reconfiguration message (e.g., the RRC reconfiguration message of the event 318) including a configuration (e.g., the DU configuration 1). If the configuration is included in the container, the UE 102 refrains from immediately applying the configuration. Otherwise, in some such implementations, if the configuration is not included in the container, the UE 102 applies the configuration immediately. In some implementations, the first container is a first addition or modification list (e.g., Itm-ConfigToAddModList field, ETM-ConfigToAddModEist IE, Itm- CandidateConfigToAddModList field, or LTM-CandidateConfigToAddModList IE). The CU 172 includes the DU configuration 1 in a first element (referred to herein as element 1) of the first addition or modification list. For example, the element 1 is an addition or modification IE (Itm-ConfigToAddMod field, LTM-ConfigToAddMod IE, Itm-CandidateConfigToAddMod field, or ETM-CandidateConfigToAddMod IE). When the UE 102 receives the first addition or modification list, the UE 102 can store the first addition or modification list, e.g., in a variable in its random access memory (RAM). In other alternative implementations, the DU 174 generates the first container and includes the first container in the first DU-to-CU message. In yet other alternative implementations, the DU 174 generates the element 1 and includes the element 1 in the first DU-to-CU message.

[0072] In some implementations, the CU 172 assigns an ID for the DU configuration 1. In some such implementations, the CU 172 includes, in the RRC reconfiguration message, a first LTM ID (referred to herein after as ID 1) for identifying the DU configuration 1 or the element 1. In some implementations, the CU 172 includes the ID 1 in the first container or element 1. In some implementations, the CU 172 assigns the ID 1. In other implementations, the CU 172 receives the ID 1 from the DU 174 in the first DU-to-CU message, as described below.

[0073] In some cases where the CU 172 assigns or generates the ID 1, the CU 172 transmits the ID 1 to the DU 174, and the DU 174 associates the ID 1 with the DU configuration 1. In some implementations, in the first CU-to-DU message, the CU 172 includes the ID 1 and indicates that the ID 1 is associated with the DU configuration 1. In other implementations, after receiving the first DU-to-CU message, the CU 172 transmits 312 a third CU-to-DU message including the ID 1 to the DU 174 instead of including the ID 1 in the first CU-to-DU message. In some implementations, in the third CU-to-DU message, the CU 172 includes the DU configuration 1 and the ID 1 and indicates the association between the ID 1 and DU configuration 1. Thus, in some such implementations, the DU 174 directly associates the ID 1 with the DU configuration 1. In other implementations, in the third CU- to-DU message, the CU 172 includes the cell ID 1 and the ID 1 (i.e., the first LTM ID) and indicates the association between the cell ID 1 and the ID 1. Thus, in some such implementations, the DU 174 associates the ID 1 with the DU configuration 1, based on the association between the cell ID 1 and the ID 1 as well as the association between the cell ID 1 and the DU configuration 1. In yet other implementations, in the third CU-to-DU message, the CU 172 includes the DU configuration 1, the cell ID 1, and the ID 1, and indicates the association between the ID 1, DU configuration 1, and the cell ID 1. In some implementations, the DU 174 transmits 314 a third DU-to-CU message to the CU 172 in response to the third CU-to-DU message. The events 312 (optional) and 314 (optional) are collectively referred to in Fig. 3 as an LTM ID assignment procedure 392. In some implementations, the third CU-to-DU message and third DU-to-CU message are a UE Context Modification Request message and a UE Context Modification Response message. In other implementations, the CU 172 includes the ID 1, the cell ID 1, and/or the DU configuration 1 in the second CU-to-DU message, as described above. Thus, in some such implementations, the third CU-to-DU message is omitted.

[0074] In some cases where the CU 172 includes the ID 1 in the first CU-to-DU message, the DU 174 includes the ID 1 in the DU configuration 1, first container, or element 1. Alternatively, the DU 174 does not include the ID 1 in the DU configuration 1, first container, and/or element 1. [0075] In some alternative implementations, the DU 174 assigns an ID for the DU configuration 1. For example, the DU 174 assigns the ID 1 identifying the DU configuration 1. In some implementations, the DU 174 includes the ID 1 in the first DU-to-CU message. In some such implementations, the CU 172 includes the ID 1 in the RRC reconfiguration message as described above. In other implementations, the DU 174 includes the ID 1 in the DU configuration 1, first container, or element 1. Thus, the CU 172 does not include an ID identifying the DU configuration 1 in the RRC reconfiguration message, first container, and/or element 1.

[0076] In some implementations, the DU configuration 1 includes a plurality of configurations for the UE 102 to communicate with the DU 174 on the first cell. In some implementations, the plurality of configurations includes physical layer configuration parameters (e.g., PhysicalCellGroupConfig IE), MAC layer configuration parameters (e.g., MAC-CellGroupConfig IE), and/or RLC configuration parameters (e.g., RLC-BearerConfig IE(s)). In some further implementations, the plurality of configurations includes a special cell configuration (e.g., SpCellConfig IE) and/or one or more SCell configurations (e.g., SCellConfig IE(s)).

[0077] In some implementations, the DU 174 includes a random access configuration in the DU configuration 1. In other implementations, the DU 174 does not include a random access configuration in the DU configuration 1. In some implementations, if the cell 124A and first cell are not synchronized, the DU 174 determines to include the random access configuration in the DU configuration 1. Otherwise, if the cell 124A and first cell are synchronized, the DU 174 determines to not include the random access configuration in the DU configuration 1. In other implementations, if the DU 174 determines that the UE 102 has not synchronized in UL with the first cell, the DU 174 determines to include the random access configuration in the DU configuration 1. Otherwise, if the DU 174 determines that the UE 102 has synchronized in UL with the first cell, the DU 174 determines to not include the random access configuration in the DU configuration 1. If the DU configuration 1 includes the random access configuration, the UE 102 performs the random access procedure in the event 332 in accordance with the random access configuration, as described below.

Otherwise, if the DU configuration 1 does not include the random access configuration, the UE 102 skips or refrains from performing the random access procedure of the event 332 in response to the DU configuration 1 excluding the random access configuration. [0078] In some implementations, the DU 174 includes a random access configuration in the DU configuration 1 regardless of whether the cell 124A and first cell are synchronized or not. The UE 102 performs the random access procedure in the event 332 in accordance with the random access configuration, as described below.

[0079] In some implementations, if the cell 124A and first cell are synchronized, the DU 174 determines to include, in the DU configuration 1, a first indication configuring the UE 102 not to perform a random access procedure on the first cell. Otherwise, if the cell 124A and first cell are not synchronized, the DU 174 determines to not include the first indication in the DU configuration 1. In other implementations, if the DU 174 determines that the UE 102 has synchronized in UL with the first cell, the DU 174 determines to include the first indication in the DU configuration 1. Otherwise, if the DU 174 determines that the UE 102 has not synchronized in UL with the first cell, the DU 174 determines to not include the first indication in the DU configuration 1. If the DU configuration 1 includes the first indication, the UE 102 skips or refrains from performing the random access procedure of the event 332 in accordance with or in response to the first indication. Otherwise, if the DU configuration 1 does not include the first indication, the UE 102 performs the random access procedure in accordance with the random access configuration in the event 332, in response to the DU configuration 1 excluding the first indication, as described below.

[0080] In some implementations, the DU 174 includes a reconfiguration with sync configuration (e.g., ReconfigurationWithSync IE) in the DU configuration 1 or special cell configuration. In other implementations, the DU 174 does not include a reconfiguration with sync configuration (e.g., ReconfigurationWithSync IE) in the DU configuration 1 or special cell configuration. In some implementations, if the cell 124A and first cell are not synchronized, the DU 174 determines to include the reconfiguration with sync configuration in the DU configuration 1. Otherwise, if the cell 124A and first cell are synchronized, the DU 174 determines to not include the reconfiguration with sync configuration in the DU configuration 1. In other implementations, if the DU 174 determines that the UE 102 has not synchronized in UL with the first cell, the DU 174 determines to include the reconfiguration with sync configuration in the DU configuration 1. Otherwise, if the DU 174 determines that the UE 102 has synchronized in UL with the first cell, the DU 174 determines to not include the reconfiguration with sync configuration in the DU configuration 1. In some implementations, if the DU configuration 1 includes the reconfiguration with sync configuration, the UE 102 performs the random access procedure in the event 332, as described below, in response to or in accordance with the reconfiguration with sync configuration. Otherwise, if the DU configuration 1 does not include the reconfiguration with sync configuration, the UE 102 skips or refrains from performing the random access procedure of the event 332. In some implementations, the DU 174 includes a cell ID (i.e., cell ID 1) of cell 1 (i.e., the first cell) in the DU configuration 1. In some implementations, the cell ID 1 is a PCI. In further implementations, the cell ID 1 is a CGI. In some further implementations, the DU configuration 1 includes a cell index 1 (e.g., a serving cell index or LTM cell index) indexing the cell ID 1 or the first cell. The cell index 1 is not a cell ID.

[0081] In some implementations, after (e.g., in response to) receiving one or some of the at least one measurement report of the event 304, the base station 104 (i.e., the CU 172 or DU 174) determines to prepare additional cell(s) (i.e., cell(s) 2, ..., N) of the base station 104 for LTM for the UE 102. In some implementations, the base station 104 determines to prepare the additional cell(s) for LTM for the UE 102 because the at least one measurement report indicates that the additional cell(s) could be used by the base station 104 to communicate with the UE 102. In some implementations, the additional cell(s) include the cell 124C and/or cell(s) other than the cells 124A, 124B, and 124C. In some implementations, if the L3 measurement report(s) indicate that signal strength and/or quality of a particular cell of the additional cell(s) is above a respective predetermined threshold and/or is better than the cell 124A, the CU 172 determines to prepare the particular cell for LTM for the UE 102. In other implementations, if the LI measurement report(s) indicates that signal strength and/or quality of a particular cell of the additional cell(s) is above a first predetermined threshold and/or is better than the cell 124A, the DU 174 determines to prepare the particular cell for LTM for the UE 102. In some implementations, the respective predetermined threshold(s) for the additional cells are different from the first predetermined threshold. In further implementations, the respective predetermined threshold(s) for the additional cell(s) are the same as the first predetermined threshold. Depending on the implementation, the respective predetermined thresholds for the additional cells are the same or different. Alternatively, the base station 104 determines to prepare the additional cell(s) for the UE 102 regardless of whether a measurement report is received from the UE 102 or not.

[0082] In cases where the CU 172 determines to prepare the additional cell(s), the CU 172 initiates and performs at least one additional LTM preparation procedure with the DU 174 to prepare the additional cell(s) for LTM, where each of the LTM preparation procedure(s) is similar to the procedure 390. In some cases where the DU 174 determines to prepare the additional cell(s), the DU 174 initiates and performs at least one additional LTM preparation procedure with the CU 172 to prepare the additional cell(s) for LTM, where each of the LTM preparation procedure(s) is similar to the procedure 390.

[0083] In some implementations, the CU 172 and DU 174 perform LTM preparation procedure(s) 2, ..., N to prepare the cell(s) 2, ..., N, respectively, similar to the procedure 390. In some implementations, the CU 172 includes the cell ID(s) 2, ..., N in CU-to-DU message(s) 2, ..., N in the LTM preparation procedure(s) 2, ..., N, respectively, similar to the first CU-to-DU message. In the LTM preparation procedure(s) 2, ..., N, the DU 174 generates DU configuration(s) 2, ..., N configuring the cell(s) 2, ..., N and includes the DU configuration(s) 2, ..., N in DU-to-CU message(s) 2, .., N, respectively, as described for the DU configuration 1. In cases where the DU 174 receives the CU-to-DU message(s) 2, ..., N, the DU-to-CU message(s) 2, ..., N responds to the CU-to-DU message(s) 2, ..., N, respectively. “N” is an integer and larger than one. For example, “N” is 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13 14, 15, 16, etc. In another example, the maximum number of “N” is 4, 8, 16, or 32. Examples and implementations of the DU configuration 1 can apply to the DU configuration(s) 2, ..., N.

[0084] In other implementations, the CU 172 and DU 174 perform a single LTM preparation procedure (i.e., the LTM preparation procedure 390) to prepare the cell(s) 1, 2, ..., N. In such cases, the DU 174 includes the DU configuration(s) 1, 2, ..., N for the cell(s) 1, 2, ..., N, respectively in the first DU-to-CU message. In some implementations, in the first DU-to-CU message, the DU 174 includes the cell ID(s) 1, 2, ..., N, respectively associated with the DU configuration(s) 1, 2, ..., N to indicate that the DU configuration(s) 1, 2, ..., N are configured for the cell ID(s) 1, 2, ..., N, respectively. In cases where the CU 172 determines to perform the LTM preparation procedure 390, the CU 172 includes the cell ID(s) 1, 2, ..., N in the first CU-to-DU message to request the DU 174 to prepare the cell(s) 1, 2, ..., N, respectively, for LTM.

[0085] In some implementations, after receiving the DU configuration(s) 2, ..., N from the DU 174, the CU 172 includes the DU configuration(s) 2, ..., N in the first container. In some implementations, the CU 172 includes the DU configuration(s) 2, ..., N in element(s) 2, ..., N, respectively, and includes the element(s) 2, ... , N in the first container. In some implementations, the CU 172 includes, in the RRC reconfiguration message, LTD ID(s) (i.e., ID(s) 2, ..., N) for identifying the DU configuration(s) 2, ..., N, respectively. In some implementations, the CU 172 includes the ID(s) 2, .. N in the first container. For example, the CU 172 includes the ID(s) 2, ..., N and DU configuration(s) 2, ..., N in the element(s) 2, ... , N in the first addition or modification list.

[0086] In some implementations, the CU 172 assigns the ID(s) 2, ..., N for the DU configuration(s) 2, ..., N, respectively. In other implementations, the CU 172 receives the ID(s) 2, ..., N from the DU 174 in the first DU-to-CU message of the procedure 390. In yet other implementations, the CU 172 receives from the DU 174 the ID(s) 2, ..., N in the DU- to-CU message(s) 2, ..., N of the LTM preparation procedure(s) 2, ..., N, respectively.

[0087] In some implementations, the CU 172 performs an LTM ID assignment procedure with the DU 174 for each of the DU configuration(s) 2, ..., N, similar to the procedure 392.

In other implementations, the CU 172 includes the ID(s) 2, ..., N and the DU configuration(s) 2, ..., N in the third CU-to-DU message and indicates the association between the ID(s) 2, ..., N and the DU configuration(s) 2, ..., N, respectively. Thus, in some such implementation, the DU 174 associates the DU configuration(s) 2, ..., N with the ID(s) 2, ..., N, respectively. In yet other implementations, the CU 172 includes the cell ID(s) 2, ..., N and the ID(s) 2, ..., N in the third CU-to-DU message and indicates the association between the cell ID(s) 2, ..., N and the ID(s) 2, ..., N, respectively. Thus, in some such implementations, the DU 174 associates the DU configuration(s) 2, ..., N with the ID(s) 2, ..., N, respectively, based on the association between the cell ID(s) 2, ..., N and the ID(s) 2, ..., N and the association between the cell ID(s) 2, ..., N and the DU configuration(s) 2, ..., N, respectively. In other implementations, the CU 172 includes the ID(s) 2, ..., N, the cell ID(s) 2, ..., N, and/or the DU configuration(s) 2, ..., N in the second CU-to-DU message, as described above. Thus, in some such implementations, the third CU-to-DU message can be omitted. In yet other implementations, the CU 172 includes the ID(s) 2, ..., N in the first CU-to-DU message and indicates that the ID(s) 2, ..., N are respectively associated with the cell ID(s) 2, ..., N. In some implementations, the DU 174 includes the ID(s) 2, ..., N in the DU configuration(s) 2, ..., N. Thus, the CU 172 does not include the ID(s) 2, ..., N in the RRC reconfiguration message, first container, and/or element(s) 2, ..., N.

[0088] In some alternative implementations, the DU 174 assigns the ID(s) 2, ..., N. In some implementations, the DU 174 includes the ID(s) 2, ..., N in the first DU-to-CU message of the procedure 390. In yet other implementations, the DU 174 includes the ID(s) 2, ..., N in the DU-to-CU message(s) 2, ..., N of the LTM preparation procedure(s) 2, .. ,,N. In further implementations, the CU 172 includes the ID(s) 2, .. N in the RRC reconfiguration message. In other implementations, the DU 174 includes the ID(s) 2, ..., N in the DU configuration(s) 2, ..., N. Thus, the CU 172 does not include an ID (e.g., LTM ID) identifying each of DU configuration(s) 2, ..., N in the RRC reconfiguration message, first container, and/or element 1.

[0089] In some alternative implementations, the CU 172 generates a second container including the DU configuration(s) 2, ..., N or element(s) 2, ..., N instead of using the first container. The CU 172 then transmits an additional RRC reconfiguration message, including the second container, to the UE 102 via the DU 174, similar to the events 316 and 318. In response, the UE 102 transmits an additional RRC reconfiguration complete message to the CU 172 via the DU 174, similar to the events 320 and 322. In some implementations, the second container is a second addition or modification list (e.g., Itm-ConfigToAddModList field, LTM-ConfigToAddModList IE, Itm-CandidateConfigToAddModList field, or LTM- CandidateConfigToAddModList IE), and each of the element(s) 2, ..., N is an addition or modification IE (e.g., Itm-ConfigToAddMod field, LTM-ConfigToAddMod l , Itm- CandidateConfigToAddMod field, or LTM-CandidateConfigToAddMod IE). In further implementations, when the UE 102 receives the second addition or modification list, the UE 102 stores the second addition or modification list together with the first addition or modification list (e.g., in a variable in the random access memory (RAM)).

[0090] In some implementations, the DU 174 includes cell ID(s) 2, ..., N in the DU configuration(s) 2, ..., N to identify the cell(s) 2, ..., N, respectively. In some implementations, each of the cell ID(s) 2, ..., N is a PCI. In some further implementations, the DU configuration(s) 2, ..., N includes cell indexes (e.g., serving cell indexes) 2 , ..., N indexing the cell ID(s) 2, ... , N or the cell(s) 2, ... , N, respectively. In some implementations, the cell ID(s) 1, ..., N in the DU configuration(s) 1, ..., N are different from the cell ID(s) 1, ..., N in the CU-to-DU message(s) described above.

[0091] In some implementations, each of the DU configuration(s) 1, ..., N includes physical configuration parameters, MAC configuration parameters, RLC configuration parameters, and/or LI measurement configuration(s). In some implementations, each of the DU configuration(s) 1, ..., N is a CellGroupConfig IE (e.g., as defined in 3GPP TS 38.331). In other implementations, each of the DU configuration(s) 1, ..., N include configuration parameters included in a CellGroupConfig IE (e.g., as defined in 3GPP TS 38.331). [0092] In some implementations, the CU 172 includes one or more additional configurations in at least one of the element(s) 1, .. N, the first container, or the second container. The one or more additional configurations include a measurement configuration (e.g., MeasConfig IE) and/or a radio bearer configuration (e.g., RadioBearerConfig IE).

[0093] In some implementations, the CU 172 determines to release the DU configuration M of the DU configuration(s) 1, ..., N (or the element M of the element(s) 1, ..., M), where 1 < M < N. In response to the determination, the CU 172 transmits an RRC reconfiguration message to the UE 102 via the DU 174 to indicate to the UE 102 to release the DU configuration M or element M. In some implementations, the CU 172 generates a release list including the ID (i.e., LTM ID) M for releasing the DU configuration M or element M and includes the release list in the RRC reconfiguration message. In response to the RRC reconfiguration message, the UE 102 releases the DU configuration M or element M and transmits an RRC reconfiguration complete message to the CU 172 via the DU 174. In response to the determination, the CU 172 transmits a CU-to-DU message to the DU 174 to indicate the DU 174 to release the DU configuration M. In some implementations, to indicate to the DU 174 to release the DU configuration M, the CU 172 includes the cell ID M or the ID (i.e., LTM ID) M in a release indication (e.g., a field or IE) in the CU-to-DU message. In response, the DU 174 releases the DU configuration M and transmits a DU-to- CU message to the CU 172. In some implementations, the CU-to-DU message and DU-to- CU message are a UE Context Modification Request message and a UE Context Modification Response message, respectively.

[0094] In other implementations, the DU 174 determines to release the DU configuration K. In response to the determination, the DU 174 transmits a DU-to-CU message to the CU 172 to release the DU configuration K. In some implementations, to indicate that the DU configuration K is released, the DU 174 includes the cell ID K or the ID (i.e., LTM ID) K in a release indication (e.g., a field or IE) in the DU-to-CU message, where 1 < K < N. After (e.g., in response to) receiving the DU-to-CU message, the CU 172 generates a release list, including the ID (i.e., LTM ID) K, to release the DU configuration K or element K and transmits an RRC reconfiguration message, including the release list, to the UE 102 via the DU 174. In response, the UE 102 releases the DU configuration K or element K and transmits an RRC reconfiguration complete message to the UE 102 via the DU 174. In some implementations, the CU 172 transmits a CU-to-DU message to the DU 174 in response to the DU-to-CU message. In some implementations, the DU-to-CU message and CU-to-DU message are a UE Context Modification Required message and a UE Context Modification Confirm message, respectively.

[0095] After receiving the RRC reconfiguration in the event 318 or transmitting the RRC reconfiguration complete message in the event 320, the UE 102 transmits 324 at least one measurement report to the DU 174, similar to the event 304. In some implementations, the DU 174 transmits 326 a DU-to-CU message, including the at least one measurement report, to the CU 172, similar to the event 306. In other implementations, the DU 174 does not transmit the at least one measurement report to the CU 172. In some implementations, the at least one measurement report of the event 324 includes LI measurement report(s) or L3 measurement repot(s), as described for the event 304. In some implementations, the UE 102 transmits 324 the at least one measurement report on PUCCH(s) and/or PUSCH(s) to the DU 174, similar to the event 304. In other implementations, the UE 102 transmits 324 at least one MAC CE, including the at least one measurement report, to the DU 174, similar to the event 304. In some implementations, the UE 102 does not transmit the LI measurement report(s) in the format for RRC message(s) to the DU 174.

[0096] In some implementations, the UE 102 transmits 324 the at least one measurement report to the DU 174 in accordance with at least one measurement configuration. The at least one measurement configuration configures the UE 102 to perform measurements and report measurement results. The CU 172 transmits the at least one measurement configuration to the UE 102 via the DU 174. For example, the CU 172 transmits one or more RRC messages (e.g., RRCReconfiguration message(s)) including the at least one measurement configuration to the UE 102 via the DU 174 in the event 302, in the event 316, and/or after the event 306 or 316. Depending on the implementation, the one or more RRC messages includes or does not include the RRC reconfiguration message of the event 316. In accordance with the at least one measurement configuration, the UE 102 performs measurements on one or more reference signals. In some implementations, the one or more reference signals include one or more SSBs and/or one or more CSI-RSs. The UE 102 obtains the at least one LI measurement result and/or at least one L3 measurement result from the measurements, and the UE 102 includes the at least one LI measurement result and/or at least one L3 measurement result in the at least measurement report of the event 324. The DU 174 transmits the one or more reference signals on the cell 124A, the cell 1, and/or the cell(s) 2, ..., N. Depending on the implementation, the one or more reference signals are CSI-RS(s) or SSB(s). [0097] In some implementations, the at least one measurement configuration includes L3 measurement configuration(s) (e.g., MeasConfig IE(s)), as described for the event 304. In other implementations, the at least one measurement configuration includes LI measurement configuration(s), as described for the event 304. For example, the LI measurement configuration(s) are CSI-MeasConfig IE(s) (e.g., defined in 3GPP TS 38.331). In some implementations, the LI measurement configuration(s) include measurement report configuration(s). The UE 102 transmits the LI measurement report(s) on PUCCH(s) or MAC CE(s) to the DU 174 in accordance with the measurement report configuration(s). The DU 174 receives the LI measurement report(s) on PUCCH(s) or MAC CE(s) in accordance with the measurement report configuration(s). In some implementations, the measurement report configuration(s) are CSl-ReportConfig IE(s). In other implementations, each of the measurement report configuration(s) is a new RRC IE. In some implementations, the measurement report configuration(s) configures periodically reporting and/or event-triggered reporting of the LI measurement result(s).

[0098] In yet other implementations, the at least one measurement configuration includes new-type measurement configuration(s) (e.g., LTM measurement configuration(s)). In some implementations, the new-type measurement configuration are newly defined (e.g., in a 3GPP specification). In some implementations, the new-type measurement configuration(s) include reference signal resource configuration(s) configuring resources where the DU 174 transmits reference signal(s). For example, the reference signal resource configuration(s) include CSI- RS(s) and/or SSB(s). In some implementations, the reference signal resource configuration(s) are CSl-ResourceConfig IE(s). In further implementations, the new-type measurement configuration(s) include measurement report configuration(s), as described above. The UE 102 transmits the measurement report(s) on PUCCH(s) or MAC CE(s) to the DU 174 in accordance with the measurement report configuration(s). The DU 174 receives the measurement report(s) on PUCCH(s) or MAC CE(s) in accordance with the measurement report configuration(s). In some such cases, the measurement report(s) are LI measurement report(s) or new-type measurement report(s) (e.g., LTM measurement report(s)). In some implementations, the new-type measurement configuration includes configuration parameters newly defined (e.g., in a 3GPP specification).

[0099] After (e.g., in response to) receiving the at least one measurement report in the event 324, the DU 174 generates a first LTM command to activate the DU configuration 1 (i.e., the first LTM command commands the UE 102 to apply the DU configuration 1 or to perform a serving cell change to the cell 1). The DU 174 then transmits 330 the first LTM command to the UE 102. In some implementations, the DU 174 transmits the first LTM command on the cell 124A to the UE 102. In other implementations, the DU 174 transmits the first LTM command on the cell 124D to the UE 102. In some implementations, the DU 174 includes the ID 1 in the first LTM command to indicate the DU configuration 1, and the UE 102 determines (e.g., identifies) the DU configuration 1 in accordance with the ID 1. In other implementations, the DU 174 includes the cell index 1 indexing the cell ID 1 in the first LTM command. The UE 102 determines (e.g., identifies) the DU configuration 1 based on the cell index 1. After determining the DU configuration 1, the UE 102 then applies the DU configuration 1 in response to receiving the first LTM command.

[0100] In yet other implementations, the DU 174 includes a bit map in the first LTM command to activate the DU configuration 1, instead of the ID 1 or cell index 1. The number of bits in the bit map is larger than or equal to “N”. In some implementations, bit 1 , ... , N corresponds to the DU configuration(s) 1, ..., N, respectively, and the DU 174 sets a corresponding bit (e.g., bit 1) in the bit map to a first value to indicate the ID 1 or the DU configuration 1. Thus, in some such implementations, the UE 102 determines the ID 1 or DU configuration 1 in accordance with the bit 1 set to the first value in the bit map. In further implementations, bit 0, ..., N-l corresponds to the DU configuration(s) 1, ..., N, respectively, and the DU 174 sets a corresponding bit (e.g., bit 0) in the bit map to a first value to indicate the ID 1 or the DU configuration 1. Thus, in some such implementations, the UE 102 determines the ID 1 or DU configuration 1 in accordance with the bit 0 set to the first value in the bit map. In such implementations, the DU 174 sets the remaining bits in the bit map to a second value to indicate that the reset of the DU configuration(s) 1, ..., N are not activated. In some implementations, the first value is one and the second value is zero. In other implementations, the first value is zero and the second value is one. Generally, in some implementations, if the DU 174 determines to activate the DU configuration L, the DU 174 sets the corresponding bit (e.g., bit L or bit L-7) in the bit map to the first value and set the remaining bits to the second value, where 1 <L <N.

[0101] In some implementations, the at least one measurement report (e.g., LI measurement report(s) or new-type measurement report(s)) of the event 324 includes at least one measurement result for the first cell, TRP(s) of the first cell or reference signal(s) transmitted on the first cell. In some implementations, the reference signal(s) are CSI-RS(s) or SSB(s). The DU 174 determines to activate the DU configuration 1 or transmit the first LTM command, based on the at least one measurement result. In some implementations, the DU 174 determines to activate the DU configuration 1 because, when or if the at least one measurement result is above a second predetermined threshold. In some implementations, the at least one measurement result includes Ll-RSRP value(s), Ll-RSRQ value(s) and/or Ll-SINR value(s). In other implementations, the at least one measurement result includes RSRP value(s), RSRQ value(s), and/or SINR value(s) for the new-type measurement report(s). In some implementations, the second predetermined threshold is different from the first predetermined threshold. In some implementations, the second predetermined threshold is larger than the first predetermined threshold. In such cases, the at least one measurement result indicates that the first cell is suitable for communication with the UE 102. In further implementations, the second predetermined threshold is equal to the first predetermined threshold. In such cases, the at least one measurement result indicates that the first cell has been continuously above the second predetermined threshold or the first predetermined threshold. This indicates that the first cell is suitable for communication with the UE 102. Thus, the DU 174 determines to activate the DU configuration 1 in response to determining that signal strength or quality of the first cell is above the second predetermined threshold for the UE 102.

[0102] In some implementations, the at least one measurement report (e.g., L3 measurement report(s)) of the events 324 and 326 includes at least one measurement result for the first cell. The CU 172 determines to activate the DU configuration 1 or transmit the first LTM command, because the at least one measurement result indicates that signal strength or quality of the first cell is above a second predetermined threshold. The second predetermined threshold is different from the first predetermined threshold. In some implementations, the second predetermined threshold is larger than the first predetermined threshold. In such implementations, the at least one measurement report of the event 326 indicates that signal strength or quality of the first cell is suitable for communication with the UE 102. In further implementations, the second predetermined threshold is equal to the first predetermined threshold. In such implementations, the at least one measurement report of the event 326 indicates that signal strength or quality of the first cell has been continuously above the second predetermined threshold or the first predetermined threshold. This also indicates that the first cell is suitable for communication with the UE 102. Thus, the CU 172 determines to activate the DU configuration 1 in response to that signal strength or quality of the first cell is above the second predetermined threshold. In response to the determination, the CU 172 transmits 328 a fourth CU-to-DU message to the DU 174 to activate the DU configuration 1. In response to the fourth CU-to-DU message, the DU 174 transmits 330 the first LTM command to the UE 102 and optionally transmits a fourth DU-to-CU message to the CU 172. In some implementations, the CU 172 includes the cell index 1 in the fourth CU-to-DU message. Thus, in some such implementations, the DU 174 determines to activate the DU configuration 1 in accordance with the cell index 1. In other implementations, the CU 172 includes the cell ID 1 in the fourth CU-to-DU message. Thus, the DU 174 determines to activate the DU configuration 1 in accordance with the cell ID 1. In yet other implementations, the CU 172 includes the ID 1 in the fourth CU-to-DU message. Thus, in some such implementations, the DU 174 determines to activate the DU configuration 1 in accordance with the ID 1. In some implementations, the fourth CU-to-DU message and fourth DU-to-CU message are a UE Context Modification Request message and a UE Context Modification Response message, respectively. In other implementations, the fourth CU-to- DU message and/or fourth DU-to-CU message are new interface messages (e.g., Fl application protocol (F1AP) messages (e.g., defined in 3GPP TS 38.473).

[0103] In some implementations, when or in response to determining to activate the DU configuration 1 or transmit the first LTM command, the DU 174 transmits 329, to the CU 172, a DU-to-CU message indicating an LTM being executed. In some implementations, the DU 174 includes the cell ID 1 or the ID 1 (i.e., LTM ID) in the DU-to-CU message 329 to indicate that the DU 174 is to activate the DU configuration 1. In some implementations, the DU transmits the DU-to-CU message 329 to the CU 172 before or after transmitting 330 the LTM command.

[0104] In some implementations, the first LTM command is a MAC CE included in a MAC PDU that the UE 102 receives from the DU 174 in the event 330. In further implementations, the MAC CE is a new MAC CE (e.g., defined in 3GPP TS 38.321). In some implementations, the DU 174 includes a subheader identifying the new MAC CE in the MAC PDU, and the UE 102 identifies the new MAC CE in the MAC PDU in accordance with the subheader. Depending on the implementation, the subheader includes a logical channel ID or extended logical channel ID (e.g., defined in a 3GPP specification) to identify the new MAC CE. For example, the logical channel ID or extended logical channel ID are newly defined (e.g., in 3GPP TS 38.321). In other implementations, the first LTM command is a DCI that the UE 102 receives on a PDCCH from the DU 174 in the event 330. The DU 174 generates a CRC for the DCI, scrambles the CRC with a first C-RNTI of the UE 102, and transmits the DCI and scrambled CRC on the PDCCH in the event 330. In some implementations, a format of the DCI is an existing DCI format (e.g., defined in a 3GPP specification (e.g., 3GPP TS 38.212)). In further implementations, the format of the DCI can be a new DCI format (e.g., defined in a 3GPP specification (e.g., 3GPP TS 38.212)).

[0105] In some implementations, the DU 174 does not perform security protection (e.g., integrity protection and/or encryption) on the first LTM command. This speeds up processing the first LTM command in the UE 102 because the UE 102 does not perform security check (e.g., decryption and/or integrity check) on the first LTM command.

[0106] In some implementations, after receiving the first LTM command, the UE 102 transmits 331 an acknowledgement to the DU 174 on the cell 124A or cell 124D to indicate that the UE 102 receives the first LTM command. In some implementations, the acknowledgement is a HARQ ACK. In other implementations, the acknowledgement is a MAC CE. For example, the MAC CE is an existing MAC CE (e.g., defined in 3GPP TS 38.321). In another example, the MAC CE is a new MAC CE (e.g., defined in 3GPP TS 38.321). In yet other implementations, the acknowledgement is a PUCCH transmission.

[0107] In some implementations, the CU 172 transmits 316 the RRC reconfiguration message in response to the L3 measurement report 306 for the first cell. In some implementations, to configure the UE 102 to transmit the L3 measurement report 306, the CU 172 transmits a first RRC reconfiguration message including the L3 measurement configuration (e.g., a MeasConfig IE) to the UE 102 before the event 306. In some implementations, the DU 174 transmits 330 the first LTM command in response to the LI measurement report(s) 324 for the first cell. In some implementations, to configure the UE 102 to transmit the LI or new-type measurement report(s) 324, the CU 172 transmits a second RRC reconfiguration message, including the LI or new-type measurement configuration(s), to the UE 102. In some implementations, the first and second RRC reconfiguration messages are the same message (i.e., the same instance). In other implementations, the first and second RRC reconfiguration messages are different messages. In some implementations, the second RRC reconfiguration message is the RRC reconfiguration message of the event 316. In other implementations, the second RRC reconfiguration message is different from the RRC reconfiguration message of the event 316.

[0108] After (e.g., in response to) receiving the first LTM command, the UE 102 identifies the DU configuration 1 in accordance with the ID 1 and applies the DU configuration 1. In some implementations, the UE 102 performs a random access procedure 332 on the first cell with the DU 174 in response to applying the DU configuration 1 or receiving the first LTM command. In some implementations, the UE 102 disconnects from the cell 124A after (e.g., in response to) receiving the first LTM command or after transmitting the acknowledgement. In other words, the UE 102 stops communicating on the cell 124A (e.g., in response to) receiving 330 the first configuration activation command or transmitting 331 the acknowledgement. In such cases, the UE 102 performs 332 the random access procedure after disconnecting from the cell 124A. In some implementations, the UE 102 determines whether to perform the random access procedure in accordance with the DU configuration 1. In some implementations, if the DU configuration 1 configures the UE 102 to perform a random access procedure, the UE 102 performs the random access procedure in the event 332. For example, the DU configuration 1 includes a reconfiguration with sync configuration (e.g., ReconfigurationWithSync IE) to configure the UE 102 to perform a random access procedure. Otherwise, if the DU configuration 1 does not configure the UE 102 to perform a random access procedure or configures the UE 102 to skip a random access procedure, the UE 102 refrains from performing a random access procedure with the DU 174 upon receiving the first LTM command. In such cases, the UE 102 skips the event 316. For example, if the DU configuration 1 excludes a reconfiguration with sync configuration, the DU configuration 1 configures the UE 102 not to perform a random access procedure. In some implementations, the random access procedure is a four-step random access procedure. In other implementations, the random access procedure is a two-step random access procedure. In some implementations, the random access procedure is a contention-free random access procedure. In other implementations, the random access procedure is a contention-based random access procedure.

[0109] In cases where the UE 102 performs 332 the random access procedure, the UE 102 communicates 336 with the DU 174 on cell 124B using the DU configuration 1 and communicates with the CU 172 via the DU 174, after successfully completing the random access procedure. For example, the UE 102 communicates UL PDUs, DL PDUs, and/or physical layer signals (e.g., PUCCH transmissions and PDCCH transmissions) with the base station 104 in the event 336. In such cases, the UE 102 successfully completes the random access procedure when the UE 102 receives a contention resolution from the DU 174. In cases where the random access procedure is a four-step random access procedure, the UE 102 transmits a Message 3 including a UE identity to the DU 174 via the first cell in the random access procedure. In cases where the random access procedure is a two-step random access procedure, the UE 102 transmits a Message A including the UE identity to the DU 174 via the first cell in the random access procedure. In some implementations, if the DU configuration 1 includes a second C-RNTI, the UE identity is the second C-RNTI of the UE 102. Otherwise, if the DU configuration 1 does not include a C-RNTI, the UE identity is the first C-RNTI. In cases where the random access procedure is a contention free random access procedure, the UE 102 transmits the dedicated random access preamble to the DU 174 via the first cell. In such cases, the DU configuration 1 includes the dedicated random access preamble.

[0110] The DU 174 identifies or determines that the UE 102 connects to the first cell upon receiving the UE identity or the dedicated preamble from the UE 102 in the random access procedure 332.

[0111] In the case that the UE 102 skips the random access procedure, the UE 102 directly communicates 336 with the base station 104 on the first cell in accordance with the DU configuration 1 after (e.g., in response to) receiving the first LTM command. For example, the UE 102 directly communicates UL PDUs, DL PDUs, and/or physical layer signals (e.g., PUCCH transmissions and PDCCH transmissions) with the base station 104 in the event 336. In some implementations, the DU 174 includes, in the DU configuration 1, configuration parameters configuring resources for the UE 102 to transmit the at least one PUCCH or PUSCH transmission, and the UE 102 transmits the at least one PUCCH or PUSCH transmission on the resources, using the configuration parameters, to indicate that the UE 102 connects to the first cell. In other implementations, the DU 174 transmits, to the UE 102, at least one DCI on a PDCCH on the first cell to command the UE 102 to transmit the at least one PUCCH or PUSCH transmission, after transmitting the first LTM command. The at least one DCI configures resources for the UE 102 to transmit the at least one PUCCH or PUSCH transmission, and the UE 102 transmits the at least one PUCCH or PUSCH transmission on the resources. The DU 174 identifies or determines that the UE 102 connects to the first cell upon receiving the PUCCH or PUSCH transmission. The DU 174 identifies or determines that the UE 102 connects to the first cell upon receiving the PUCCH or PUSCH transmission on the resources configured in the DU configuration 1 or the at least one DCI.

[0112] In some implementations, the UE 102 transmits an RRC message (e.g., RRC reconfiguration complete message) to the CU 172 via the DU 174 and the first cell to indicate that the UE 102 applies the DU configuration 1. In some cases where the UE 102 performs the random access procedure 332, the UE 102 includes the RRC message in the Message 3 or Message A. Alternatively, the UE 102 transmits the RRC message after completing the random access procedure. In cases where the UE 102 skip the random access procedure 332, the UE 102 includes the RRC message in a PUSCH transmission of the at least one PUSCH transmission. In some implementations, if the UE 102 maintains communication on the cell 124A with the base station 104 (i.e., the UE 102 does not disconnect from the cell 124A), the UE 102 transmits the RRC message to the base station 104 via the cell 124A. When the DU 174 receives the RRC message, the DU 174 transmits the RRC message to the CU 172.

[0113] In other implementations, the UE 102 refrains from transmitting the RRC message to the base station 104 in response to applying the DU configuration 1 or receiving the first LTM command. In some such cases, the UE 102 includes or transmits data in the Message 3, Message A or PUSCH transmission as described above. In further implementations, the UE 102 generates a MAC PDU and/or a RLC PDU including the data, and the UE 102 transmits or includes the MAC PDU and/or RLC PDU in the PUSCH transmission. For example, the data is a PDCP PDU, a SDAP PDU, a LTE Positioning Protocol (LPP) PDU, an RRC PDU, and/or a NAS PDU. The RRC PDU includes a UL-DCCH-Message excluding an RRC reconfiguration complete message. The NAS PDU includes a Mobility Management (MM) message or a Session Management (SM) message. In some implementations, the MM message is a 5G MM message or a 6G MM message, and the SM message is a 5G SM message or a 6G SM message. When the DU 174 receives the data, the DU 174 transmits the data to the CU 172.

[0114] When the DU 174 determines that the UE 102 successfully connects to the first cell in the event 332 or 336, the DU 174 transmits 334 a DU-to-CU message (e.g., Access Success message) to the CU 172 (e.g., a CP of the CU 172). In some implementations, the DU 174 includes the cell ID 1 of the first cell in the DU-to-CU message of the event 334. The cell ID is a PCI or a CGI. Thus, the CU 172 determines that the UE 102 connects to the first cell upon receiving the DU-to-CU message of the event 334. In some implementations, when the DU 174 determines that the UE 102 successfully connect to the first cell in the event 332 or 336, the DU 174 transmits a DL Data Delivery Status message or frame to the CU 172 (e.g., a UP of the CU 172). [0115] In some implementations, when determining that the UE 102 connects to the first cell, transmitting 330 the first LTM command, or receiving 331 the acknowledgement, the DU 174 stops communicating with the UE 102 on the cell 124A and/or releases resources of the cell 124 A configured for the UE 102.

[0116] In some implementations, the DU 174 generates the DU configuration 1 and/or DU configuration(s) 2, ..., N as full configuration(s) to replace the first configuration or a particular configuration (e.g., a DU configuration) in the first configuration. If the DU configuration 1 is a full configuration, the UE 102 and DU 174 communicate 336 with each other in accordance with the DU configuration 1 instead of the first configuration or the particular configuration. In some implementations, the DU 174 includes an indication that the DU configuration l is a full configuration in the DU configuration 1. In some implementations, in each of the DU configuration(s) 2, ..., N, the DU 174 includes an indication that the corresponding DU configuration is a full configuration. In some implementations, each of the indication(s) in the DU configuration(s) 1, ..., N is a field or IE (i.e., the same field or IE). In other implementations, the CU 172 includes, in the RRC reconfiguration message of the events 316, 318, a single indication indicating that the DU configuration(s) 1 and/or 2, ..., N are full configuration(s). In some cases with the second container, the CU 172 includes, in the additional RRC reconfiguration message, a single indication indicating that the DU configuration(s) 2, ..., N are full configuration(s). In yet other implementations, the CU 172 includes, in the first container, a single indication indicating that the DU configuration(s) 1 and/or 2, ..., N are full configuration(s). In yet other implementations, for each of the DU configuration(s) 2, ..., N, the CU 172 includes, in the first container, a particular indication indicating the corresponding DU configuration is a full configuration. In some cases with the second container, the CU 172 includes, in the second container, a single indication indicating that the DU configuration(s) 2, ..., N are full configuration(s). In yet other implementations, the CU 172 includes, in the element 1, an indication that the DU configuration 1 is a full configuration. In some implementations, in each of the element(s) 2, ..., N, the CU 172 includes an indication that the corresponding DU configuration is a full configuration. In further implementations, the UE 102 determines that the DU configuration 1 and/or DU configuration(s) 2, ..., N are full configuration(s) based on the indication(s) above. In some implementations, each of the indication(s) above is different from fullConfig field (e.g., defined in the current 3GPP specification). In some implementations, each of the indication(s) above is a fullConfig field (e.g., defined in the current 3GPP specification).

[0117] In other implementations, the DU 174 generates the DU configuration 1 and/or DU configuration(s) 2, ..., N as delta configuration(s) that augment (a portion of) the first configuration. For example, the portion of the first configuration includes the DU configuration in the first configuration or configuration parameters in the first configuration or the DU configuration in the first configuration. In other words, the DU 174 generates the DU configuration(s) 1, ..., N based on the first configuration or the DU configuration in the first configuration. For example, if the DU configuration 1 is a delta configuration, the UE 102 and DU 174 augment at least the portion of the first configuration with the DU configuration 1. Thus, the UE 102 and base station 104 communicate 336 with each other in accordance with the DU configuration 1 and unaugmented portion of the first configuration. In some implementations, the DU configuration(s) 1 and/or 2, ..., N, first container, second container, or element(s) 1, ..., N exclude indication(s) that the DU configuration(s) 1 and/or 2, ..., N are full configuration(s) to indicate that the DU configuration(s) 1 and/or 2, ..., N are delta configuration(s). In some implementations, the UE 102 determines that each of the DU configuration(s) 1 and/or 2, ..., N is a delta configuration based on that the indication is excluded in the DU configuration(s) 1 and/or 2, .. ,,N, first container, second container, or element(s) 1 and/or 2, ..., N.

[0118] In some implementations, the UE 102 uses a UE MAC entity (e.g., MAC 204B) to communicate with a DU MAC entity (e.g., MAC 204B) of the DU 174 (e.g., the events 302, 304, 318, 320, 324, 330 and/or 331). In some implementations, the UE 102 resets the UE MAC entity, after or in response to receiving the first LTM command and before performing the random access procedure 332 or communicating 336 with the DU 174 via the first cell. In some implementations, the DU 174 resets the DU MAC entity after (e.g., in response to) transmitting the first LTM command, receiving 331 the acknowledgement or determining that the UE 102 connects to the first cell.

[0119] In some implementations, when the UE 102 resets the UE MAC entity, the UE 102 performs at least one of the following actions for the UE MAC entity (i.e., UE MAC reset or full UE MAC reset): (i) initialize Bj for configured logical channel(s) to zero; (ii) stop one or more timers; (iii) consider timeAlignmentTimer(g) as expired if the UE 102 is configured to perform the random access procedure (e.g., the event 332) in the configuration (e.g., the configuration 1); (iv) set new data indicator(s) (NDI(s)) for UL HARQ process(es) to value 0; (v) set NDI(s) for HARQ process ID(s) to value 0 for monitoring PDCCH in Sidelink resource allocation mode 1; (vi) flush Msg3 buffer; (vii) flush MSGA buffer; (viii) cancel, if any, triggered Scheduling Request procedure; (ix) cancel, if any, triggered Buffer Status Reporting procedure; (x) cancel, if any, triggered Power Headroom Reporting procedure; (xi) cancel, if any, triggered consistent LBT failure; (xii) cancel, if any, triggered BFR; (xiii) cancel, if any, triggered Sidelink Buffer Status Reporting procedure; (xiv) cancel, if any, triggered Pre-emptive Buffer Status Reporting procedure; (xv) cancel, if any, triggered Timing Advance Reporting procedure; (xvi) cancel, if any, triggered Recommended bit rate query procedure; (xvii) cancel, if any, triggered configured uplink grant confirmation; (xviii) cancel, if any, triggered configured sidelink grant confirmation; (xix) cancel, if any, triggered Desired Guard Symbol query; (xx) cancel, if any, triggered Positioning Measurement Gap Activation/Deactivation Request procedure; (xxi) flush soft buffers for DL HARQ process(es); (xxii) for each of the DL HARQ process(es), consider the next received transmission for a TB as the very first transmission; (xxiii) release, if any, Temporary C- RNTI; and/or (xxiv) reset one or more counters (e.g., BFI_COUNTERs and/or LBT_COUNTERs).

[0120] In some implementations, when the DU 174 resets the DU MAC entity, the DU 174 performs at least one of the following actions for the DU MAC entity (i.e., DU MAC reset or full DU MAC reset): (i) stop one or more timers; (ii) consider limeAlignmenlTimer( ) that the DU 174 starts and/or maintains for the UE 102 as expired if the UE 102 is configured to perform the random access procedure (e.g., the event 332) in the configuration (e.g., the configuration 1); (iii) set NDI(s) for DL HARQ process(es) to value 0; (iv) flush soft buffers for UL HARQ process(es); (v) for each of the UL HARQ process(es), consider the next received transmission for a TB as the very first transmission; and/or (vi) reset one or more counters (e.g., BFI_COUNTERs and/or LBT_COUNTERs).

[0121] Depending on implementation, the UE 102 determines to partially or fully reset the UE MAC entity. In some implementations, when the UE 102 resets the UE MAC entity as described above, the UE 102 fully resets the UE MAC entity (i.e., a full UE MAC reset). In the full UE MAC reset, the UE 102 performs some or all of the actions described above. In other implementations, when the UE 102 resets the UE MAC entity as described above, the UE 102 partially resets the UE MAC entity (i.e., a partial UE MAC reset). In the partial UE MAC reset, the UE 102 performs a subset or portion of the some or all of the actions in the full UE MAC reset.

[0122] In some implementations, the partial UE MAC reset includes at least one of the following actions: (i) consider limeAlignmenlTimer( ) of the UE 102 as expired if the UE 102 is configured to perform the random access procedure (e.g., the event 332) in the configuration (e.g., the configuration 1); (ii) flush Msg3 buffer; (iii) flush MSGA buffer; (iv) release, if any, Temporary C-RNTI; and/or (v) reset one or more counters (e.g., BFI_COUNTERs and/or LBT_COUNTERs).

[0123] In some implementations, the partial UE MAC reset further includes at least one of the following actions: (i) cancel, if any, triggered Scheduling Request procedure; (ii) cancel, if any, triggered Buffer Status Reporting procedure; (iii) cancel, if any, triggered Power Headroom Reporting procedure; (iv) cancel, if any, triggered consistent LBT failure; (v) cancel, if any, triggered BFR; (vi) cancel, if any, triggered Sidelink Buffer Status Reporting procedure; (vii) cancel, if any, triggered Pre-emptive Buffer Status Reporting procedure;

(viii) cancel, if any, triggered Timing Advance Reporting procedure; (ix) cancel, if any, triggered Recommended bit rate query procedure; (x) cancel, if any, triggered configured uplink grant confirmation; (xi) cancel, if any, triggered configured sidelink grant confirmation; (xii) cancel, if any, triggered Desired Guard Symbol query; and/or (xiii) cancel, if any, triggered Positioning Measurement Gap Activation/Deactivation Request procedure.

[0124] In some implementations, the partial UE MAC reset further includes at least one of the following actions: (i) stop a first portion of the one or more timers and retain the rest of the one or more timers; (ii) set new data indicator(s) (NDI(s)) for UL HARQ process(es) to value 0; (iii) set NDI(s) for HARQ process ID(s) to value 0 for monitoring PDCCH in Sidelink resource allocation mode 1; (iv) flush soft buffers for DL HARQ process(es); and/or (v) for each of the DL HARQ process(es), consider the next received transmission for a TB as the very first transmission.

[0125] Depending on implementation, the DU 174 determines to partially or fully reset the DU MAC entity. In some implementations, when the DU 174 resets the DU MAC entity as described above, the DU 174 fully resets the DU MAC entity (i.e., a full DU MAC reset). In the full DU MAC reset, the DU 174 performs some or all of the actions described above. In other implementations, when the DU 174 resets the DU MAC entity as described above, the DU 174 partially resets the DU MAC entity (i.e., a partial DU MAC reset). In the partial DU MAC reset, the DU 174 performs a subset or portion of the some or all of the actions in the full DU MAC reset.

[0126] In some implementations, the partial DU MAC reset includes at least one of the following actions in the partial MAC reset: (i) consider limeAlignmenlTimer( ) that the DU 174 starts and/or maintains for the UE 102 as expired if the UE 102 is configured to perform the random access procedure (e.g., the event 332) in the configuration (e.g., the configuration 1); and/or (ii) reset one or more counters (e.g., BFI_COUNTERs and/or LBT_COUNTERs).

[0127] In some implementations, the partial DU MAC reset includes at least one of the following actions for the MAC entity (i.e., DU MAC reset): (i) stop a first portion of the one or more timers and retain the rest of the one or more timers; (ii) set NDI(s) for DL HARQ process(es) to value 0; (iii) flush soft buffers for UL HARQ process(es); (iv) for each of the UL HARQ process(es), consider the next received transmission for a TB as the very first transmission; and/or (v) reset one or more counters (e.g., BFI_COUNTERs and/or LBT_COUNTERs).

[0128] In other implementations, the UE 102 refrains from resetting the UE MAC entity in response to receiving the first LTM command. Similarly, the DU 174 refrains from resetting the DU MAC entity after (e.g., in response to) transmitting the first LTM command, receiving 331 the acknowledgement or determining that the UE 102 connects to the first cell. In other words, the UE 102 communicates with the DU 174 on the first cell using the UE MAC entity (not reset). Similarly, the DU 174 communicates with the UE 102 using the DU MAC entity (not reset) on the first cell during or after the random access procedure 332 or after determining that the UE 102 connects to the first cell.

[0129] In some implementations, the UE 102 uses at least one UE RLC entity (e.g., RLC 206B) to communicate RLC PDUs with at least one DU RLC entity (e.g., RLC 206B) of the DU 174 (e.g., the events 302, 304, 318, 320, 324, 330, and/or 331). In some implementations, the UE 102 reestablishes some or all of the at least one UE RLC entity, after or in response to receiving the first LTM command and before performing the random access procedure 332 or communicating 336 with the DU 174 via the first cell. In some implementations, the DU 174 reestablishes some or all of the at least one DU RLC entity after (e.g., in response to) transmitting the first LTM command, receiving 331 the acknowledgement or determining that the UE 102 connects to the first cell. [0130] In some implementations, the DU configuration 1 includes or does not include one or more RLC reestablishment indications (e.g., reestablishRLC field(s)) configuring the UE 102 to reestablish some or all of the at least one UE RLC entity. If the DU configuration 1 includes the RLC reestablishment indication configuring the UE 102 to reestablish a first UE RLC entity of the at least one UE RLC entity that the UE 102 uses to communicate RLC PDU(s) with the DU 174, the UE 102 reestablishes the first UE RLC entity in response to the RLC reestablishment indication and the first LTM command. In some implementations, the UE 102 reestablishes the first UE RLC entity before performing the random access procedure 332 or communicating 336 with the DU 174 via the first cell. In other implementations, the UE 102 reestablishes the first UE RLC entity while or after performing the random access procedure 332. Otherwise, if the DU configuration 1 does not include the RLC reestablishment indication, the UE 102 refrains from reestablishing the first UE RLC entity in response to the first LTM command.

[0131] In some implementations, when the UE 102 reestablishes the first UE RLC entity, the UE 102 performs at least one of the following actions for the first UE RLC entity: (i) discard RLC SDU(s), RLC SDU segment(s), and RLC PDU(s), if any; (ii) stop and reset timer(s), if running; and/or (iii) reset state variables to initial values. In some implementations, the state variables and timer(s) are already defined state variables and timer(s) (e.g., defined in 3GPP TS 38.322).

[0132] Otherwise, if the DU configuration 1 does not include the RLC reestablishment indication for the first UE RLC entity, the UE 102 refrains from reestablishing the first UE RLC entity upon or when receiving the first LTM command. In other words, the UE 102 refrains from preforming the actions for reestablishing the first UE RLC entity of the UE 102 upon or when receiving the first LTM command. In some implementations, if the DU configuration 1 or element 1 does not include the RLC reestablishment indication and includes an indication that the configuration 1 is a full configuration, the UE 102 reestablishes the first UE RLC entity of the UE 102 upon or when receiving the first LTM command. Otherwise, if the DU configuration 1 or element 1 does not include the RLC reestablishment indication and the indication that the configuration 1 is a full configuration, the UE 102 refrains from reestablishing the first UE RLC entity upon or when receiving the first LTM command. [0133] Similarly, the DU 174 reestablishes some or all of at least one DU RLC entity (e.g., NR RLC 206B) that the DU 174 uses to communicate with the at least one UE RLC entity of the UE 102 (e.g., the events 302, 304, 318, 320, 324, 330, and/or 331) in response to the RLC reestablishment indication. In some implementations, the DU 174 reestablishes a first DU RLC entity of the at least one DU RLC entity after transmitting the first LTM command, receiving an acknowledgement for the first LTM command from the UE 102, or determining that the UE 102 connects to the first cell. In some implementations, the acknowledgement is a HARQ ACK. In other implementations, the acknowledgement is a MAC CE. In yet other implementations, the acknowledgement is a PUCCH transmission. In some implementations, when the base station 104 reestablishes the first DU RLC entity, the DU 174 performs at least one of the following actions for the first DU RLC entity: (i) discard RLC SDU(s), RLC SDU segment(s), and RLC PDU(s), if any; (ii) stop and reset timer(s), if running; and/or (iii) reset state variables to initial values. In some implementations, the state variables and timer(s) are already defined state variables and timer(s) (e.g., defined in 3GPP TS 38.322).

[0134] In other implementations, the UE 102 refrains from reestablishing some or all of the at least one UE RLC entity in response to receiving the first LTM command. Similarly, the DU 174 refrains from reestablishing some or more of the at least one DU RLC entity after (e.g., in response to) transmitting the first LTM command, receiving 331 the acknowledgement, or determining that the UE 102 connects to the first cell. In other words, the UE 102 communicates with the DU 174 on the first cell using some or all of the at least one UE RLC entity (not reestablished). Lor example, the some or all of the at least one UE RLC entity includes the first UE RLC entity and/or a second UE RLC entity. Similarly, the DU 174 communicates with the UE 102 using the some or all of the at least one DU RLC entity (not reestablished) on the first cell during or after the random access procedure 332 or after determining that the UE 102 connects to the first cell. Lor example, the some or all of the at least one DU RLC entity includes the first DU RLC entity and/or a second DU RLC entity.

[0135] In some implementations, the UE 102 uses at least one UE PDCP entity (e.g., PDCP 210) to communicate UL PDCP PDUs and/or DL PDCP PDUs with at least one CU PDCP entity (e.g., PDCP 210) of the CU 172 in the event 302. In some implementations, the UE 102 performs a PDCP recovery procedure for some or all of the at least one UE PDCP entity after or in response to receiving the first LTM command. Lor example, the UE 102 performs a PDCP recovery procedure for a first UE PDCP entity of the at least one UE PDCP entity after or in response to receiving the first LTM command. In some implementations, in the PDCP recovery procedure, the UE 102 reestablishes or does not reestablish the first UE PDCP entity. In further implementations, after or in response to performing the PDCP recovery procedure, the UE 102 retransmits at least a portion of the UL PDCP PDUs to the CU 172 via the DU 174 and the first cell in the event 336. Similarly, the CU 172 performs a PDCP recovery procedure for some or all of the at least one CU PDCP entity after or in response to transmitting the first LTM command. For example, the CU 172 performs a PDCP recovery procedure for a first CU PDCP entity of the at least one CU PDCP entity after or in response to transmitting the first LTM command. In some implementations, the CU 172 performs the PDCP recovery procedure for the first CU PDCP entity in response to receiving the DU-to-CU message 329 or 334. In other implementations, the CU 172 performs the PDCP recovery procedure for the first CU PDCP entity in response to receiving the DL Data Delivery Status message. In some implementations, in the PDCP recovery procedure, the CU 172 reestablishes or does not reestablish the first CU PDCP entity. In further implementations, after or in response to performing the PDCP recovery procedure, the CU 172 retransmits at least a portion of the DL PDCP PDUs to the UE 102 via the DU 174 and the first cell in the event 336.

[0136] In other implementations, the UE 102 refrains from reestablishing some or all of the at least one UE PDCP entity in response to receiving the first LTM command. For example, the some or all of the at least one UE PDCP entity includes the first UE PDCP entity and/or a second UE PDCP entity. Similarly, the CU 172 refrains from reestablishing some or more of the at least one CU PDCP entity, after (e.g., in response to) receiving the DU-to-CU message 329 or 340 or after (e.g., in response to) receiving the DL Data Delivery Status message. In other words, the UE 102 communicates with the CU 172 via the DU 174 and the first cell using the some or all of the at least one UE PDCP entity (not reestablished). For example, the some or all of the at least one UE PDCP entity includes the first UE PDCP entity and/or a second UE PDCP entity. Similarly, the CU 172 communicates with the UE 102 using the some or all of the at least one CU PDCP entity (not reestablished) via the DU 174 and the first cell. For example, the some or all of the at least one CU PDCP entity includes the first CU PDCP entity and/or a second CU PDCP entity.

[0137] In some implementations, after determining that the UE 102 connects to the first cell, the CU 172 transmits 338 a CU-to-DU message (e.g., a UE Context Modification

Request message) to the DU 174 to indicate to the DU 174 to stop communicating with the UE 102 and/or to release or suspend resources of the cell 124A configured for the UE 102. In further implementations, in response, the DU 174 stops communicating on the cell 124A with the UE 102 and/or releases or suspends resources, of the cell 124A, configured for the UE 102, and transmits 340 a DU-to-CU message (e.g., a UE Context Modification Response message) to the CU-172. The events 338 (optional) and 340 (optional) are collectively referred to in Fig. 3 as a resource release procedure 396.

[0138] In some implementations, after or while communicating with the DU 174 on the first cell, events 344, 346, 348, 350, 351, 352, 354, and/or 356 occur, similar to the events 324, 326, 328, 330, 331, 332, 334, and/or 336, respectively. The UE 102 transmits 344 at least one measurement report to the DU 174. The at least one measurement report includes at least one measurement result for a second cell (i.e., the cell 2). The at least one measurement result indicates that the second cell is suitable for communication with UE 102 and/or the first cell is not suitable for communication with the UE 102. After (e.g., in response to) receiving the at least one measurement report, the DU 174 determines to activate the DU configuration 2 and generates a second LTM command to activate the DU configuration 2 (i.e., the second LTM command commands the UE 102 to apply the DU configuration 2).

The DU 174 then transmits 350 the second LTM command to the UE on the first cell to the UE 102.

[0139] In some implementations, when or in response to determining to activate the DU configuration 2 or transmit the second LTM command, the DU 174 transmits 349, to the CU 172, a DU-to-CU message indicating LTM being executed. In some implementations, the DU 174 includes the cell ID 2 or the ID 2 (i.e., LTM ID) in the DU-to-CU message 349 to indicate that the DU 174 is to activate the DU configuration 2. Depending on the implementation, the DU transmits the DU-to-CU message 349 to the CU 172 before or after transmitting 350 the LTM command.

[0140] The descriptions for the events 324, 326, 328, 330, 331, 332, 334, and/or 336 can be applied to the events 344, 346, 348, 350, 351, 352, 354, and/or 356 with simple changes. For example, “ cell 124A”, “first LTM command”, “first cell”, “ID 1”, and/or “DU configuration 1” are replaced with “first cell”, “second LTM command”, “second cell”, “ID 2”, and/or “DU configuration 2”, respectively.

[0141] The events 344, 346, 348, 350, 351, 352, 354 are collectively referred to in Fig. 3 as an LTM execution procedure 398. The events 304, 306, 390, 392, 394, 324, 326, 328, 330, 331, 332, 334, 336, 396, 398 are collectively referred to in Fig. 3 as an LTM configuration and/or activation procedure 380.

[0142] Referring next to Fig. 4, in a scenario 400, the base station 104 includes a CU 172, a source DU (S-DU) 174A, and a target DU (T-DU) 174B. The S-DU 174A operates the cell 124A and optionally additional cell(s), while the T-DU 174B operates a first cell (e.g., cell 124C). The scenario 400 is similar to the scenario 300. Thus, the descriptions for the scenario 300 can generally apply to the scenario 400. The differences between the scenarios 300 and 400 are described below.

[0143] In some implementations, the resource release procedure 496 is similar to the procedure 396. Alternatively, in the resource release procedure 496, the CU 172 transmits a CU-to-DU message (e.g., a UE Context Release Command message) to the S-DU 174A to release a UE context of the UE 102. In response, the S-DU 174A releases a UE context of the UE 102 and transmits 440 a DU-to-CU message (e.g., a UE Context Release Complete message) to the CU-172.

[0144] In some implementations, the CU 172 performs the procedure 492 with the T-DU 174B to provide the ID(s) 1 and/or 2, ..., N to the T-DU 174B, similar to the procedure 392. In other implementations, the CU 172 performs 490 one or more LTM preparation procedures with the T-DU 174B and receives the ID(s) 1 and/or 2, ..., N from the DU 174 in DU-to-CU message(s) of the procedure(s) 490, similar to the procedure 390. In some implementations, the CU 172 performs 493 one or more LTM ID assignment procedures with the S-DU 174A to provide the ID(s) 1, 2 and/or N to the S-DU 174A, similar to the procedure 392.

[0145] Referring next to Fig. 5A, in a scenario 500A, the base station 106 operates as an MN, and the base station 104 operates as an SN. The base station 104 includes a CU 172 and a DU 174. Scenario 500A is similar to scenario 300, except that scenario 500A is a DC scenario and scenario 300 is a single connectivity (SC) scenario. In some implementations, the MN 106 includes a CU and a DU similar to the base station 104 of Fig. 3.

[0146] Initially, the UE 102 in DC communicates with the MN 106 and with SN 104. In the event 502, the UE 102 communicates with the DU 174 on cell 124A and communicates with the CU 172 via the DU 174 using a first configuration, similar to the event 302. In some implementations, the UE 102 in DC communicates 502 UL PDUs and/or DL PDUs with the MN 106 and/or SN 104 via radio bearers which can include SRBs and/or DRB(s). In further implementations, the MN 106 and/or the SN 104 configure the radio bearers for the UE 102. The UE 102 in DC communicates 502 UL PDUs and/or DL PDUs with the SN 104 on an SCG (i.e., SCG radio resources) that the SN 104 configures for communication with the UE 102. The UE 102 in DC communicates UL PDUs and/or DL PDUs with the MN 106 on an MCG (i.e., MCG radio resources) in accordance with an MN configuration (i.e., MCG configuration). In some implementations, the first configuration is an SN configuration (i.e., SCG configuration). In the MN configuration, the MN 106 configures the MCG which includes at least one serving cell (e.g., the cell 126 and/or other cell(s)) operated by the MN 106. In the first configuration, the SN 106 A configures the SCG which includes at least one serving cell (e.g., the cell 124A and/or other cell(s)) operated by the SN 104. In some implementations, the MN configuration includes multiple configuration parameters, and the UE 102 receives the configuration parameters in one or more RRC messages from the MN 106. In other implementations, the first configuration includes multiple configuration parameters, and the UE 102 receives the configuration parameters in one or more RRC messages from the SN 104 (e.g., via the MN 106 or on an SRB (e.g., SRB3) that the MN 106 or SN 104 configures to exchange RRC messages between the UE 102 and the SN 104).

[0147] In some implementations, while the UE 102 communicates in DC with the MN 106 and SN 104, the MN 106 performs 580 an LTM configuration and/or activation procedure with the UE 102, similar to the procedures 380 and/or 480. In some implementations, while communicating in DC with the MN 106 and SN 104, the UE 102 transmits the at least one measurement report to the CU 172 via the DU 174 and cell 124A in the events 504 and 506, similar to the events 304 and 306, respectively. In other implementations, while communicating in DC with the MN 106 and SN 104, the UE 102 transmits 505 at least one measurement report to the MN 106 via the cell 126. The MN 106 in turn transmits 507 the at least one measurement report to the CU 172. In some implementations, the MN 106 generates at least one SN message, including the at least one measurement report, and transmits the at least one SN message to the CU 172 in the event 507. In some implementations, the at least one SN message include RRC Transfer message(s) and/or SN Modification Request message(s).

[0148] After (e.g., in response to) receiving the at least one measurement report or while the SN 104 communicates with the UE 102, the SN 104 determines to prepare the first cell for the UE 102, as described for Fig. 3. The events 590, 592, 594, 524, 526, 528, 530, 531, 532, 534, 536, 596, 598, and 556 are similar to the events 390, 392, 394, 324, 326, 328, 330, 331, 332, 334, 336, 396, 398, and 356, respectively. After receiving 530 the first LTM command, transmitting 531 the acknowledgement, or determining that the UE 102 successfully connects 532 or 536 to the first cell, the UE 102 operating in DC with the MN 106 and SN 104 communicates 536 with the DU 174 on the first cell in accordance with the DU configuration 1 and communicates 536 with the CU 172 via the DU 174, similar to the event 336. In further implementations, later in time, the DU 174 and/or CU 172 performs the LTM execution procedure 598 with the UE 102 to command the UE 102 to perform a cell change from the first cell to the second cell, similar to the procedure 398. As a result of the procedure 598, the UE 102 operating in DC with the MN 106 and SN 104 communicates 556 with the DU 174 on the second cell in accordance with the DU configuration 2 and communicates 556 with the CU 172 via the DU 174, similar to the event 356.

[0149] The events 504, 506, 505, 507, 590, 592, 594, 594, 524, 526, 528, 530, 531, 532, 534, 536, 596, 598 are collectively referred to in Fig. 5A as an LTM configuration and/or activation procedure 581.

[0150] Referring next to Fig. 5B, a scenario 500B is generally similar to the scenario 500A, except that the SN 104 transmits 517, 519 the RRC reconfiguration message to the UE 102 via the MN 106 and receives 521, 523 the RRC reconfiguration complete message from the UE 102 via the MN 106. In some implementations, the SN 104 generates a first SN message (e.g., SN Modification Required message, SN Modification Required message, or RRC Transfer message), including the RRC reconfiguration message, and transmits the first SN message to the MN 106 in the event 517. In some implementations, the MN 106 generates a second SN message (e.g., SN Reconfiguration Complete message or RRC Transfer message), including the RRC reconfiguration complete message, and transmits the second SN message to the SN 104 in the event 523.

[0151] The events 504, 506, 505, 507, 590, 592, 594, 517, 519, 521, 523, 524, 526, 528, 530, 531, 532, 534, 536, 596, 598 are collectively referred to in Fig. 5B as an LTM configuration and/or activation procedure 582.

[0152] Referring next to Fig. 6A, in a scenario 600A, the base station 106 operates as an MN, and the base station 104 operates as an SN, similar to the scenarios 300-500B. The SN 104 includes a CU 172, an S-DU 174A, and a T-DU 174B, similar to the base station 104 in the scenario 400. In some implementations, while the UE 102 communicates in DC with the MN 106 and SN 104, the MN 106 performs 680 an LTM configuration and/or activation procedure with the UE 102, similar to the procedures 380 and/or 480. In further implementations, while the UE 102 communicates in DC with the M-DU 174A and S-DU 174B, the CU 172 performs 681 an LTM configuration and/or activation procedure with the UE 102 via the M-DU 174A or S-DU 174B, similar to the procedure 581 or 582.

[0153] Referring next to Fig. 6B, a scenario 600B is similar to the scenarios 300-500B and 600A, except that that the SN 104 transmits 617, 619 the RRC reconfiguration message to the UE 102 via the MN 106 and receives 621, 623 the RRC reconfiguration complete message from the UE 102 via the MN 106.

[0154] Referring next to Fig. 7A, in a scenario 700A, the base station 104 operates as an MN and an SN, similar to the scenarios 300-600B. The base station 104 includes a CU 172, a master DU (M-DU) 174A, and a secondary DU (S-DU) 174B. The CU 172 operates with the M-DU 174A as an MN, similar to the base station 104 in the Fig. 3 or the MN 106 in Figs. 5A-6B, and the CU 172 operates with the S-DU 174B as an SN, similar to the SN 104 in Figs. 5A-6B.

[0155] In the scenario 700A, the UE 102 initially communicates 702 in DC with the M-DU 174A and S-DU 174B and communicates 702 with the CU 172 via the M-DU 174A and S- DU 174B. In the event 702, the UE 102 communicates with the S-DU 174B on cell 124A and communicates with the CU 172 via the S-DU 174B (e.g., using a first configuration). Events 704 and 706 are similar to the events 304 and 306. In some implementations, the UE 102 transmits 705 at least one measurement report to the M-DU 174A, similar to the event 304. The M-DU 174A in turn transmits 707 at least one DU-to-CU message, including the at least one measurement report, to the CU 172, similar to the event 306. In some implementations, while the UE 102 communicates in DC with the M-DU 174A and S-DU 174B, the CU 172 performs 780 an LTM configuration and/or activation procedure with the UE 102 via the M-DU 174A, similar to the procedure 380.

[0156] Referring next to Fig. 7B, a scenario 700B is similar to the scenarios 300-600B and 700A, except that that the CU 172 transmits 717, 719 the RRC reconfiguration message to the UE 102 via the M-DU 174A and receives 721, 723 the RRC reconfiguration complete message from the UE 102 via the M-DU 174A.

[0157] Referring next to Fig. 8A, in a scenario 800A, the base station 104 operates as an MN and an SN, similar to the scenarios 300-700B. The base station 104 includes a CU 172, a master DU (M-DU) 174A, a secondary DU (S-DU) 174B, and a target secondary DU (T- DU) 174C. The CU 172 operates with the M-DU 174A as an MN and operates with the S- DU 174B as an SN. In some implementations, while the UE 102 communicates in DC with the M-DU 174A and S-DU 174B, the CU 172 performs 880 an LTM configuration and/or activation procedure with the UE 102 via the M-DU 174A, similar to the procedure 380. In further implementations, while the UE 102 communicates in DC with the M-DU 174A and S- DU 174B, the CU 172 performs 881 an LTM configuration and/or activation procedure with the UE 102 via the S-DU 174A, similar to the procedure 581 or 582.

[0158] Referring next to Fig. 8B, a scenario 800B is similar to the scenarios 300-700B and 800A, except that that the CU 172 transmits 817, 819 the RRC reconfiguration message to the UE 102 via the M-DU 174A and receives 821, 823 the RRC reconfiguration complete message from the UE 102 via the M-DU 174A.

[0159] Next, several example methods, that can be implemented in a UE to support configuring a configuration for LTM and activating the configuration later, are discussed with reference to Figs. 9A-13C. Examples and implementations described for Figs. 3-8B can apply to Figs. 9A-13C.

[0160] Fig. 9A illustrates a method 900A, which can be implemented by a UE (e.g., the UE 102), for communicating with a RAN (e.g., the RAN 105, base station 104/106, or DU 174).

[0161] The method 900A begins at block 902, where the UE communicates with the RAN via a serving cell (e.g., a first cell) using at least one first protocol entity (e.g., events 302, 380, 402, 480, 502, 580, 602, 680, 702, 780, 802, 880). The flow proceeds to block 904 and/or block 912. At block 904, the UE receives, from the RAN, first message(s) including first LTM configuration(s) and a first indication, where each of the first LTM configuration(s) configures a candidate cell and the first indication indicates that the candidate cell(s) are associated with the serving cell (e.g., events 316, 318, 394, 380, 594, 517, 519, 580, 581, 582, 794, 717, 719, 780). At block 906, the UE receives, from the RAN, an LTM command (e.g., a first LTM command) activating an LTM configuration (e.g., a first LTM configuration), of the first LTM configuration(s), configuring a candidate cell (e.g., a second cell) (e.g., events 330, 350, 398, 380, 530, 598, 580, 730, 798, 780). At block 908, the UE connects to the candidate cell (i.e., the second cell) and refrains from performing at least one first procedure for the at least one first protocol entity, in response to receiving the LTM command (e.g., events 332, 336, 352, 356, 398, 380, 598, 556, 580, 798, 756, 780). After the UE successfully connects to the candidate cell (i.e., the second cell), the candidate cell (i.e., the second cell) becomes a (new) serving cell. In some implementations, the UE disconnects from the first cell in response to the LTM command. At block 910, the UE communicates with the RAN via the candidate cell using the at least one first protocol entity and the LTM configuration (e.g., events 336, 356, 380, 536, 556, 580, 736, 756, 780).

[0162] At block 912, the UE receives, from the RAN, second message(s) including second LTM configuration(s) and a second indication, where each of the second LTM configuration(s) configures a candidate cell, and the second indication indicates that the candidate cell(s) are not associated with the serving cell (e.g., events 494, 480, 694, 617, 619, 680, 681, 894, 880, 881, 817, 819). At block 914, the UE receives, from the RAN, an LTM command (i.e., a second LTM command) activating an LTM configuration (e.g., a second LTM configuration), of the second LTM configuration(s), configuring a candidate cell (e.g., events 430, 498, 630, 698, 830, 898). At block 916, the UE connects to the candidate cell (i.e., becoming a (new) serving cell) and performs the at least one first procedure for the at least one first protocol entity in response to receiving the LTM command (e.g., events 432, 436, 498, 456, 632, 636, 698, 656, 832, 836, 898, 856). After the UE successfully connects to the candidate cell, the candidate cell becomes a serving cell (e.g., a new serving cell). In some implementations, the UE disconnects from the first cell in response to the LTM command. At block 918, the UE communicates with the RAN via the candidate cell using the at least one first protocol entity and the LTM configuration (e.g., events 436, 456, 636, 656, 836, 856).

[0163] In some implementations, when the UE receives an LTM command (i.e., the first or second LTM command), the UE determines whether to perform the at least one first procedure depending on whether a candidate cell configured in an LTM configuration activated by the LTM command is not associated with the serving cell. If the UE determines that the candidate cell is not associated with the serving cell, the UE performs the at least one first procedure. If the UE determines that the candidate cell is associated with the serving cell, the UE refrains from performing the at least one first procedure. In some such cases, the UE performs at least one second procedure.

[0164] In some implementations, the first LTM configuration(s) are the element(s) 1 and/or 2, ..., N as described for Figs. 3, 5A-5B, and 7A-7B, and each of the first LTM configuration(s) includes the first indication. In further implementations, the second LTM configuration(s) are the element(s) 1 and/or 2, N as described for Figs. 4, 6A-6B, and 8A- 8B, and each of the second LTM configuration(s) includes the second indication.

[0165] In some implementations, the first LTM configuration(s) are the DU configuration(s) 1 and/or 2, ..., N as described for Figs. 3, 5A-5B, and 7A-7B. Each of the first LTM configuration(s) is included in a particular element (e.g., the element(s) 1 and/or 2, ..., N described for Figs. 3, 5A-5B, and 7A-7B), and each of the element(s) includes the first indication. In further implementations, the second LTM configuration(s) are the DU configuration(s) 1 and/or 2, ..., N as described for Eigs. 4, 6A-6B, and 8A-8B. Each of the second LTM configuration(s) is included in a particular element (e.g., the element(s) 1 and/or 2, ..., N described for Figs. 4, 6A-6B, and 8A-8B), and each of the element(s) includes the second indication.

[0166] In some implementations, the first message(s) and second message(s) include the same message(s) (e.g.., same instance(s) of RRC reconfiguration message(s)). In other implementations, the first message(s) and second message(s) are different messages (e.g., RRC reconfiguration messages).

[0167] In some implementations, the at least one protocol entity includes at least one UE MAC entity, and performing the at least one first procedure includes resetting the at least one UE MAC entity. Alternatively, performing the at least one first procedure includes performing a full MAC reset on the at least one UE MAC entity and in this case, the performing at least one second procedure includes performing a partial MAC reset on the at least one UE MAC entity. For example, the UE communicates with the RAN using a first UE MAC entity at block 902. In cases regarding receiving the first LTM command, the UE performs a partial MAC reset on the first UE MAC entity in response to the first LTM command. After the partial MAC reset, the UE communicates with the RAN using the first UE MAC entity at block 910. In cases regarding receiving the second LTM command, the UE performs a full MAC reset on the first UE MAC entity in response to receiving the second LTM command. After the full MAC reset, the UE communicates with the RAN using the first UE MAC entity at block 910. In some implementations, the UE communicates with the RAN using a second UE MAC entity in addition to the first UE MAC entity at block 902. In some implementations, the UE releases the second UE MAC entity in response to the LTM command (i.e., the first LTM command or second LTM command). In further implementations, the UE refrains from resetting the second UE MAC entity in response to the LTM command (i.e., the first LTM command or second LTM command). In some implementations, the UE continues to use the second UE MAC entity to communicate with the RAN at block 910. In yet further implementations, the UE performs a full MAC reset on the second UE MAC entity in response to the LTM command (i.e., the first LTM command or second LTM command). In some implementations, after performing the full MAC reset on the second UE MAC entity, the UE communicates with the RAN using the second UE MAC entity at block 910. Alternatively, after performing the full MAC reset on the second MAC entity, the UE stops using the second MAC entity to communicate with the RAN.

[0168] In some implementations, the at least one protocol entity includes at least one UE RLC entity, and performing the at least one first procedure includes reestablishing the at least one UE RLC entity. For example, the UE communicates with the RAN using a first UE RLC entity at block 902. In cases regarding receiving the first LTM command, the UE refrains from reestablishing the first UE RLC entity in response to the first LTM command. Thus, the UE continues using the first UE RLC entity (not reestablished) to communicate with the RAN at block 910. In cases regarding receiving the second LTM command, the UE reestablishes the first UE RLC entity in response to the second LTM command. In some implementations, the UE communicates with the RAN using a second UE RLC entity in addition to the first UE RLC entity at block 902. In some implementations, the UE refrains from reestablishing the second UE RLC entity in response to the LTM command (i.e., the first LTM command or second LTM command). The UE continues using the second UE RLC entity (not reestablished) to communicate with the RAN at block 910. In further implementations, the UE reestablishes the second UE RLC entity in response to the LTM command (i.e., the first LTM command or second LTM command). After reestablishing the second UE RLC entity, the UE communicates with the RAN using the second UE RLC entity at block 910.

[0169] In some implementations, the at least one protocol entity includes at least one UE PDCP entity, and the at least one first procedure includes at least one PDCP recovery procedure. For example, the UE communicates with the RAN using a first UE PDCP entity at block 902. In cases regarding receiving the first LTM command, the UE refrains from performing a PDCP recovery procedure for the first UE PDCP entity in response to the first LTM command. The UE communicates with the RAN using the first UE PDCP entity at block 910. In cases regarding receiving the second LTM command, the UE performs the PDCP recovery procedure for the first PDCP RLC entity in response to the second LTM command. In some implementations, the UE retransmits UL PDCP PDUs using the first UE PDCP entity to the RAN at block 910 in response to performing the PDCP recovery procedure. In some implementations, the UE communicates with the RAN using a second UE PDCP entity in addition to the first UE PDCP entity at block 902. In some implementations, the UE refrains from performing the PDCP recovery procedure for the second UE PDCP entity in response to the LTM command (i.e., the first LTM command or second LTM command). The UE communicates with the RAN using the second UE PDCP entity at block 910. In further implementations, the UE performs the PDCP recovery procedure for the second UE PDCP entity in response to the LTM command (i.e., the first LTM command or second LTM command). In some implementations, the UE retransmits UL PDCP PDUs using the second UE PDCP entity to the RAN at block 910 in response to performing the PDCP recovery procedure.

[0170] While the UE communicates with the RAN at block 918, the UE receives, from the RAN, an LTM command (i.e., a third LTM command) activating an LTM configuration (e.g., a third LTM configuration) of the second LTM configuration(s), configuring a candidate cell (e.g., a third cell or the third cell). The UE connects to the candidate cell and refrains from performing at least one first protocol procedure for the at least one first protocol entity in response to receiving the third LTM command, similar to block 908. In response to receiving the third LTM command, the UE communicates with the RAN via the candidate cell using the at least one first protocol entity and the third LTM configuration, similar to block 910.

[0171] Fig. 9B is a flow diagram of an example method 900B similar to the method 900A, except that method 900B includes block 913 instead of block 912. At block 913, the UE receives, from the RAN, second message(s) including second LTM configuration(s) and excluding indication(s) that candidate cell(s) in the second LTM configuration(s) are associated with the serving cell (e.g., events 494, 480, 694, 617, 619, 680, 681, 894, 880, 881, 817, 819). Excluding the indication(s) from the second message(s) indicates that the candidate cell(s) in the second LTM configuration(s) are not associated with the serving cell. When the UE receives the second LTE configuration(s) without associated indication(s) that the candidate cell(s) in the second LTM configuration(s) are associated with the serving cell, the UE determines that the candidate cell(s) are not associated with the serving cell.

[0172] Fig. 9C is a flow diagram of an example method 900C similar to the method 900A, except that method 900C includes block 905 instead of block 904. At block 905, the UE receives, from the RAN, first message(s) including first LTM configuration(s) and excluding indication(s) that candidate cell(s) in the first LTM configuration(s) are associated with the serving cell (e.g., events 316, 318, 394, 380, 594, 517, 519, 580, 581, 582, 794, 717, 719, 780). Excluding the indication(s) from the first message(s) indicates that the candidate cell(s) in the first LTM configuration(s) are associated with the serving cell. When the UE receives the first LTE configuration(s) without associated indication(s) that the candidate cell(s) in the first LTM configuration(s) are not associated with the serving cell, the UE determines that the candidate cell(s) are associated with the serving cell.

[0173] Eig. 10 illustrates a method 1000, which can be implemented by a UE (e.g., the UE 102), for communicating with a RAN (e.g., the RAN 105, base station 104/106, or DU 174), similar to Figs. 9A-9C. Examples and implementations described for Figs. 9A-9C can apply to Fig. 10.

[0174] The method 1000 begins at block 1002, where the UE communicates with the RAN via a serving cell (e.g., a first cell) using at least one first protocol entity (e.g., events 302, 380, 402, 480, 502, 580, 602, 680, 702, 780, 802, 880). At block 1004, the UE receives, from the RAN, LTM configuration(s) each configuring a candidate cell (e.g., events 316, 318, 394, 380, 594, 517, 519, 580, 581, 582, 794, 717, 719, 780, 494, 480, 694, 617, 619, 680, 681, 894, 880, 881, 817, 819). At block 1006, the UE receives, from the RAN, an LTM command activating an LTM configuration, of the LTM configuration(s), configuring a candidate cell (e.g., events 330, 350, 398, 380, 530, 598, 580, 730, 798, 780, 430, 498, 630, 698, 830, 898).

[0175] At block 1008, the UE determines whether the candidate cell (configured in the LTM configuration) is associated with the serving cell. If the UE determines that the candidate cell is associated with the serving cell at block 1008, the flow proceeds to block 1010 which includes blocks 908 and 910 of Figs. 9A-9C. If the UE determines that the candidate cell is not associated with the serving cell at block 1008, the flow proceeds to block 1012 which includes blocks 916 and 918 of Figs. 9A-9C.

[0176] Fig. 11 A is a flow diagram of an example method 1100A similar to the method 900A. Blocks 1102, 1106, 1108, 1110, 1114, 1116 and 1118 are the same as blocks 902, 906, 908, 910, 914, 916 and 918, respectively. Blocks 1104 and 1112 are similar to blocks 904 and 912, respectively, with the differences described below.

[0177] At block 1104, the UE receives, from the RAN, first message(s) including first

LTM configuration(s) and a first cell group ID, where each of the first LTM configuration(s) configures a candidate cell, and the first cell group ID indicates that the candidate cell(s) belongs to a first cell group identified by the first cell group ID (e.g., events 316, 318, 394, 380, 594, 517, 519, 580, 581, 582, 794, 717, 719, 780). At block 1112, the UE receives, from the RAN, second message(s) including second LTM configuration(s) and a second cell group ID, where each of the second LTM configuration(s) configures a candidate cell, and the second cell group ID indicates that the candidate cell(s) belong to a second cell group identified by the second cell group ID (e.g., events 494, 480, 694, 617, 619, 680, 681, 894, 880, 881, 817, 819).

[0178] In some implementations, the first LTM configuration(s) are the DU configuration(s) 1 and/or 2, ..., N as described for Eigs. 3, 5A-5B, and 7A-7B. Each of the first LTM configuration(s) is included in a particular element (e.g., the element(s) 1 and/or 2, ..., N described for Figs. 3, 5A-5B, and 7A-7B), and each of the element(s) includes the first cell group ID. In further implementations, the second LTM configuration(s) are the DU configuration(s) 1 and/or 2, ..., N as described for Figs. 4, 6A-6B, and 8A-8B. Each of the second LTM configuration(s) is included in a particular element (e.g., the element(s) 1 and/or 2, ..., N described for Figs. 4, 6A-6B, and 8A-8B), and each of the element(s) includes the second cell group ID.

[0179] In some implementations, the first cell belongs to the first cell group. For example, the UE receives a message (e.g., RRC reconfiguration message) indicating that the first cell belongs to the first cell group while the UE communicates with the RAN at block 1102. In some implementations, the message includes the first cell group ID to indicate that the first cell belongs to the first cell group. In some implementations, the message is one of the first message(s) or second message(s). In other implementations, the message is neither included in the first message(s) nor the second message(s). Thus, in some such implementations, the UE determines whether a candidate cell configured in the LTM configuration and the serving cell belong to the same cell group or different cell groups, based on the associated cell group ID (e.g., the first or second cell group ID) and a cell group ID (e.g., the first cell group ID) of the serving cell (i.e., the first cell is the serving cell).

[0180] In some implementations, when the UE receives an LTM command (i.e., the first or second LTM command), the UE determines whether to perform the at least one first procedure, depending on whether a candidate cell configured in an LTM configuration (e.g., belonging to the first LTM configuration(s) or second LTM configuration(s)) activated by the LTM command belongs to the second cell group or first cell group. If the UE determines that the candidate cell belongs to the second cell group, the UE performs the at least one first procedure. If the UE determines that the candidate cell belongs to the first cell group, the UE refrains from performing the at least one first procedure. In some such cases, the UE performs at least one second procedure.

[0181] In some implementations, the UE receives, from the RAN, third message(s) including third LTM configuration(s) and a third cell group ID, where each of the third LTM configuration(s) configures a candidate cell and the third cell group ID indicates that the candidate cell(s) belong to a third cell group identified by the third cell group ID. In further implementations, the UE receives the third LTM configuration(s) and third cell group ID while communicating with the RAN at or after block 1102, 1110, or 1118. In some cases regarding transmitting the third message(s) at block 1110, the third message(s) and first message(s) are or are not the same message(s). In some cases regarding transmitting the third message(s) at block 1118, the third message(s) and second message(s) are or are not the same message(s).

[0182] In some implementations, “cell group ID” can be replaced by “cell group index”.

[0183] Fig. 1 IB is a flow diagram of an example method 1100B similar to the method 1100A, except that method 1100B includes blocks 1105 and 1113 instead of blocks 1104 and 1112. At block 1105, the UE receives, from the RAN, first message(s) including first LTM configuration(s) and a first DU ID, where each of the first LTM configuration(s) configures a candidate cell, and the first DU ID indicates that the candidate cell(s) are operated by a first DU identified by the first DU ID (e.g., events 316, 318, 394, 380, 594, 517, 519, 580, 581, 582, 794, 717, 719, 780). At block 1113, the UE receives, from the RAN, second message(s) including second LTM configuration(s) and a second DU ID, where each of the second LTM configuration(s) configures a candidate cell, and the second DU ID indicates that the candidate cell(s) are operated by a second DU identified by the second DU ID (e.g., events 494, 480, 694, 617, 619, 680, 681, 894, 880, 881, 817, 819).

[0184] In some implementations, the first LTM configuration(s) are the DU configuration(s) 1 and/or 2, ..., N as described for Figs. 3, 5A-5B, and 7A-7B. Each of the first LTM configuration(s) is included in a particular element (e.g., the element(s) 1 and/or 2, ..., N described for Figs. 3, 5A-5B, and 7A-7B), and each of the element(s) includes the first DU ID. In further implementations, the second LTM configuration(s) are the DU configuration(s) 1 and/or 2, N as described for Figs. 4, 6A-6B, and 8A-8B. Each of the second LTM configuration(s) is included in a particular element (e.g., the element(s) 1 and/or 2, .. N described for Figs. 4, 6A-6B, and 8A-8B), and each of the element(s) includes the second DU ID.

[0185] In some implementations, the first cell belongs to the first DU. For example, the UE receives a message (e.g., RRC reconfiguration message) indicating that the first cell belongs to the first DU while the UE communicates with the RAN at block 1102. In some implementations, the message includes the first DU ID to indicate that the first cell belongs to the first DU. In some implementations, the message is one of the first message(s) or second message(s). In other implementations, the message is neither included in the first message(s) nor the second message(s). Thus, in some such implementations, the UE determines whether a candidate cell configured in the LTM configuration and the serving cell belong to the same DU or different DUs, based on the associated DU ID (e.g., the first or second DU ID) and a DU ID (e.g., the first DU ID) for the serving cell (i.e., the first cell is the serving cell).

[0186] In some implementations, when the UE receives an LTM command (i.e., the first or second LTM command), the UE determines whether to perform the at least one first procedure, depending on whether a candidate cell configured in an LTM configuration (e.g., belonging to the first LTM configuration(s) or second LTM configuration(s)) and activated by the LTM command belongs to the second DU or first DU. If the UE determines that the candidate cell belongs to the second DU, the UE performs the at least one first procedure. If the UE determines that the candidate cell belongs to the first DU, the UE refrains from performing the at least one first procedure. In some such cases, the UE performs at least one second procedure.

[0187] In some implementations, the UE receives, from the RAN, third message(s) including third LTM configuration(s) and a third DU ID, where each of the third LTM configuration(s) configures a candidate cell, and the third cell group ID indicates that the candidate cell(s) belong to a third cell group identified by the third DU ID. In further implementations, the UE receives the third LTM configuration(s) and third DU ID while communicating with the RAN at or after block 1102, 1110, or 1118. In some cases regarding transmitting the third message(s) at block 1110, the third message(s) and first message(s) are or are not the same message(s). In some cases regarding transmitting the third message(s) at block 1118, the third message(s) and second message(s) are or are not the same message(s). [0188] In some implementations, using a DU ID potentially introduces security concerns compared to Fig. 11 A, because a DU ID represents an ID of a DU similar to a base station ID (e.g., gNB ID). Exposure of a base station ID can cause leakage of a network topology. To address the security concerns, the “DU ID” described above and below can be replaced by a virtual DU ID rather than a real DU ID. In other implementations, the “DU ID” is replaced by “DU index”. Different DU indices index different DUs and does not reveal IDs of the DUs.

[0189] Fig. 12A is a flow diagram of an example method 1200A similar to the methods 1000 and 1100A. Blocks 1202, 1204, and 1206 are the same as blocks 1002, 1004, and 1006, respectively. The differences between Figs. 12A and 10 are described below.

[0190] At block 1208, the UE determines whether the candidate cell (e.g., configured in the LTM configuration activated by the LTM command) and the serving cell belong to the same cell group. If the UE determines that the candidate cell and the serving cell belong to the same cell group at block 1208, the flow proceeds to block 1210, which includes blocks 1108 and 1110 of Fig. 11 A. If the UE determines that the candidate cell and the serving cell belong to different cell groups, the flow proceeds to block 1212, which includes blocks 1116 and 1118 of Fig. 11 A.

[0191] Fig. 12B is a flow diagram of an example method 1200B similar to the methods 1000, 1100A, 1100B, and 1200A. The differences between Figs. 12B and Figs. 10, 11 A,

I IB, and 12A are described below.

[0192] At block 1209, the UE determines whether the candidate cell (e.g., configured in the LTM configuration activated by the LTM command) and the serving cell belong to the same DU. If the UE determines that the candidate cell and the serving cell belong to the same DU at block 1209, the flow proceeds to block 1210, which includes blocks 1108 and 1110 of Fig. 11 A. If the UE determines that the candidate cell and the serving cell belong to different DUs, the flow proceeds to block 1212, which includes blocks 1116 and 1118 of Fig.

I I A.

[0193] Example and implementations described for Fig. 9A-1 IB can apply to Figs. 12A- 12B.

[0194] Fig. 13A is a flow diagram of an example method 1300A similar to the methods 900A-900C. Blocks 1302, 1306, 1308, 1310, 1314, 1316, and 1318 are the same as blocks 902, 906, 908, 910, 914, 916, and 918, respectively. Blocks 1304 and 1312 are similar to blocks 904 and 912, respectively, with the differences described below.

[0195] At block 1304, the UE receives, from the RAN, first message(s), each including a first container, where the first container(s) includes first LTM configuration(s), each configuring a candidate cell, and indicates that the candidate cell(s) are associated with the first cell (e.g., events 316, 318, 394, 380, 594, 517, 519, 580, 581, 582, 794, 717, 719, 780). At block 1312, the UE receives, from the RAN, second message(s), each including a second container, where the second container(s) includes second LTM configuration(s), each configuring a candidate cell, and indicates that the candidate cell(s) are not associated with the first cell (e.g., events 494, 480, 694, 617, 619, 680, 681, 894, 880, 881, 817, 819).

[0196] In the implementations of Fig. 13 A, the first container(s) indicate that the candidate cell(s) are associated with the first cell, and the second container(s) indicate that the candidate cell(s) are not associated with the first cell. The first container(s) do not include indication(s) that the included candidate cell(s) are associated with the first cell, and the second container(s) do not include indication(s) that the included candidate cell(s) are not associated with the first cell.

[0197] In some alternative implementations, the first container(s) at block 1304 indicate that the candidate cell(s) and the first cell belong to the same cell group, and the second container(s) at block 1312 indicate that the candidate cell(s) and the first cell belong to different cell groups. In other alternative implementations, the first container(s) at block 1304 indicate that the candidate cell(s) and the first cell are operated by the same DU, and the second container(s) at block 1312 indicate that the candidate cell(s) and the first cell are operated by different DUs. Such implementations are described in further detail below with regard to Figs. 13B and 13C, describing (i) blocks 1305 and 1313 as well as (ii) blocks 1303 and 1311, respectively.

[0198] Fig. 13B is a flow diagram of an example method 1300B similar to the methods 1300A and 1100A, except that method 1300B includes blocks 1305 and 1313 instead of blocks 1304 and 1312.

[0199] At block 1305, the UE receives, from the RAN, first message(s), each including a first container, where the first container(s) includes first LTM configuration(s), each configuring a candidate cell, and indicates that the candidate cell(s) belongs to a first cell group (e.g., events 316, 318, 394, 380, 594, 517, 519, 580, 581, 582, 794, 717, 719, 780). At block 1313, the UE receives, from the RAN, second message(s), each including a second container, where the second container(s) includes second LTM configuration(s), each configuring a candidate cell, and indicates that the candidate cell(s) belongs to a second cell group (e.g., events 494, 480, 694, 617, 619, 680, 681, 894, 880, 881, 817, 819).

[0200] Fig. 13C is a flow diagram of an example method 1300C similar to the methods 1300A and 1100A, except that method 1300B includes blocks 1303 and 1311 instead of blocks 1304 and 1312.

[0201] At block 1303, the UE receives, from the RAN, first message(s), each including a first container, where the first container(s) includes first LTM configuration(s), each configuring a candidate cell, and indicates that the candidate cell(s) belongs to a first DU (e.g., events 316, 318, 394, 380, 594, 517, 519, 580, 581, 582, 794, 717, 719, 780). At block 1311, the UE receives, from the RAN, second message(s), each including a second container, where the second container(s) includes second LTM configuration(s), each configuring a candidate cell, and indicates that the candidate cell(s) belongs to a second DU (e.g., events 494, 480, 694, 617, 619, 680, 681, 894, 880, 881, 817, 819).

[0202] Example and implementations described for Figs. 9A-9C can apply to Figs. 11 A- 1 IB and Figs. 13A-13C. Example and implementations described for Figs. 11A-11C can apply to Figs. 13A-13C.

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

[0204] Generally speaking, description for one of the above figures can apply to another of the above figures. Examples, implementations and methods described above can be combined, if there is no conflict. An event or block described above can be optional or omitted. For example, an event or block with dashed lines in the figures can be optional.

The figures described above depict different methods using the constituent blocks or events. For example, methods can include only events or blocks with solid (e.g., not dashed) lines, all events or blocks, a mixture of events or blocks with solid lines and events or blocks with dashed lines, etc.

[0205] In some implementations, “message” is used and can be replaced by “information element (IE)”, and vice versa. In some implementations, “IE” is used and can be replaced by “field”, and vice versa. In some implementations, “configuration” can be replaced by

“configurations” or “configuration parameters”, and vice versa. In some implementations, the “LTM command” can be replaced by “serving cell change command”, “Layer 1/Layer 2 switching command”, “lower layer switching command” or “ lower layer serving cell change command”. In some implementations, “some” means “one or more”. In some implementations, “at least one” means “one or more”.

[0206] As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

[0207] In addition, use of the “a” or “an” are employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the description. This description, and the claims that follow, should be read to include one or at least one and the singular also may include the plural unless it is obvious that it is meant otherwise.

[0208] 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 intemet-of-things (loT) 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.

[0209] 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.

[0210] 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.

[0211] 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.

Claims

What is claimed is:

1. A method implemented in a user equipment (UE), the method comprising: receiving, from a radio access network (RAN) via a serving cell, a lower layer mobility configuration and a cell identifier; receiving, from the RAN via the serving cell, a lower layer mobility command activating the lower layer mobility configuration; in a first instance, performing a reestablishment procedure based on the cell identifier; and in a second instance, refraining from performing the reestablishment procedure based on the cell identifier.

2. The method of claim 1, wherein: the performing of the reestablishment procedure occurs when the cell identifier does not match a serving cell identifier associated with the serving cell.

3. The method of claim 2, wherein: the cell identifier is a cell group identifier of a cell group to which one or more candidate cells associated with the cell identifier belong.

4. The method of claim 2, wherein: the cell identifier is a node identifier of a node operating one or more candidate cells associated with the cell identifier.

5. The method of claim 3 or 4, wherein: the refraining from performing the reestablishment procedure based occurs when the cell identifier matches the serving cell identifier.

6. The method of claim 5, wherein: the serving cell identifier is a serving cell group identifier of a cell group to which the serving cell belongs.

7. The method of claim 5, wherein: the serving cell identifier is a serving cell node identifier of a node operating the serving cell.

8. The method of claim 4 or 7, wherein the node is a distributed unit (DU) of a RAN node.

9. The method of claim 6, wherein: the cell identifier matches the serving cell identifier when the one or more candidate cells belong to a same cell group as the serving cell; and the cell identifier does not match the serving cell identifier when the one or more candidate cells and the serving cell belong to different cell groups.

10. The method of claim 7, wherein: the cell identifier matches the serving cell identifier when the one or more candidate cells and the serving cell are operated by a same node; and the cell identifier does not match the serving cell identifier when the one or more candidate cells and the serving cell are operated by different nodes.

11. The method of any one of the preceding claims, wherein the reestablishment procedure is a radio resource control (RRC) reestablishment procedure.

12. The method of any one of claims 1-10, wherein the reestablishment procedure is a radio link control (RLC) reestablishment procedure.

13. The method of any one of the preceding claims, wherein: receiving the lower layer mobility configuration includes: receiving the lower layer mobility configuration using a protocol entity; receiving the lower layer mobility command includes: receiving the lower layer mobility command using the protocol entity; and the reestablishment procedure is a reestablishment procedure for the protocol entity.

14. The method of claim 13, wherein the protocol entity includes at least one radio link control (RLC) entity for the UE.

15. A user equipment (UE) comprising processing hardware and configured to implement a method according to any one of the preceding claims.