Managing user equipment to cell access in fast serving cell change

Abstract

A radio access network (RAN) node may implement a method for managing lower layer triggered mobility protocol procedures. The method includes transmitting a lower layer triggered mobility (LTM) configuration from a RAN node to a user equipment (UE) communicatively coupled to the RAN node via a serving cell to configure a non-serving cell for the UE; in a first instance, when a non-serving cell is synchronized with a serving cell, a first indication is sent from the RAN node to the UE to cause the UE to perform a serving cell change to the non-serving cell and avoid performing a random access procedure; and in a second instance, when the non-serving cell is not synchronized with the serving cell, sending a second indication from the RAN node to the UE to cause the UE to perform the serving cell change and perform the random access procedure.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of the filing date of Provisional U.S. Patent Application No. 63 / 445,700, entitled “MANAGING USER EQUIPMENT ACCESSTO A CELL IN A FAST SERVING CELL CHANGE,” filed on February 14, 2023. The entire contents of said provisional application are hereby expressly incorporated herein by reference. Technical Field

[0003] The present disclosure relates to wireless communications, and more particularly to managing user equipment (UE) access to cells in fast serving cell changes. Background Art

[0004] This background description is provided for the purpose of generally presenting the context of the present disclosure. The work of the presently named inventors, to the extent that it is described in this background section, and aspects of the specification that might not have been considered prior art at the time of filing are neither explicitly nor implicitly admitted to be prior art with respect to the present disclosure.

[0005] In telecommunications systems, the Packet Data Convergence Protocol (PDCP) sublayer of the radio protocol stack provides services such as delivery, encryption, integrity protection, etc. of user plane data. For example, the PDCP sublayer 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 user equipment (UE), to a base station) and in the downlink direction (from a base station to a UE). In addition, the PDCP sublayer provides signaling radio bearers (SRBs) and data radio bearers (DRBs) to the radio resource control (RRC) sublayer. Generally speaking, in some examples, the UE and the base station use SRBs to exchange RRC messages and non-access stratum (NAS) messages, and DRBs can be used to transmit data on the user plane.

[0006] Depending on the scenario, the UE uses 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 the 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 including NAS messages on the dedicated control channel (DCCH) in some cases, while SRB2 resources support RRC messages including logged measurement information or NAS messages also on the DCCH but with a lower priority than SRB1 resources. More generally, SRB1 and SRB2 resources allow the UE and MN to exchange RRC messages related to the MN and embed RRC messages related to the SN. SRB1 and SRB 2 resources can be referred to as MCG SRBs. SRB3 resources allow the UE and 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 the lower layer resources of the MN and SN. In addition, a DRB using only the lower layer resources of the MN may be referred to as an MCG DRB, a DRB using only the lower layer resources of the SN may be referred to as an SCG DRB, and a DRB using the lower layer resources of both the MCG and SCG may be referred to as a split DRB.

[0007] In some scenarios, the UE concurrently utilizes the resources of multiple radio access network (RAN) nodes (e.g., base stations, or components of distributed base stations) interconnected by backhaul. When such network nodes support different radio access technologies (RATs), this type of connection is called multi-radio dual connectivity (MR-DC). When the UE operates in MR-DC, one base station operates as a master node (MN) covering a primary cell (PCell), and the other base station operates as a secondary node (SN) covering 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 the resources of one base station at a time. A base station and / or the UE determines that the UE should establish a radio connection with another base station. For example, a base station determines to hand over the UE to a second base station and initiates a handover process.

[0008] When a UE moves from the coverage of one RAN cell to the coverage of another, the RAN should configure the UE for a serving cell change. To perform a serving cell change, the RAN configures the UE to send Layer 3 (L3) measurements. Based on the L3 measurements received from the UE, the RAN sends an RRC reconfiguration message (e.g., the RRC reconfiguration message includes a ReconfigurationWithSync IE) with synchronization for a serving cell change (e.g., PCell or PSCell). In the case where the UE operates with carrier aggregation (CA) of at least one secondary cell (SCell) with the PCell or PSCell, the RAN releases at least one SCell due to the PCell or PSCell change. A serving cell change involves a full L2 (and L1) reset, resulting in longer latency, greater overhead, and longer interruption time. Therefore, it is desirable to develop new mobility procedures to reduce the latency and overhead of fast serving cell changes. However, it is unclear how to configure and manage the UE to access a new serving cell in the new mobility procedures. Summary of the Invention

[0009] An example embodiment of the disclosed technology is a method implemented in a radio access network (RAN) node, the method comprising: sending, from the RAN node, a lower layer triggered mobility (LTM) configuration to a user equipment (UE) communicatively coupled to the RAN node via a serving cell, to configure a non-serving cell for the UE; in a first instance, when the non-serving cell is synchronized with the serving cell, sending a first indication from the RAN node to the UE to cause the UE to perform a serving cell change to the non-serving cell and to avoid performing a random access procedure; and in a second instance, when the non-serving cell is not synchronized with the serving cell, sending a second indication from the RAN node to the UE to cause the UE to perform the serving cell change and to perform the random access procedure.

[0010] Another example embodiment of the techniques is a method implemented in a user equipment (UE), the method comprising: receiving, at the UE, a lower layer triggered mobility (LTM) configuration from a radio access network (RAN) node communicatively coupled to the UE via a serving cell, to configure a non-serving cell for the UE; in a first instance, when the non-serving cell is synchronized with the serving cell, receiving a first indication from the RAN node to perform a serving cell change to the non-serving cell and to avoid performing a random access procedure; and in a second instance, when the non-serving cell is not synchronized with the serving cell, sending a second indication from the RAN node to perform the serving cell change and to perform the random access procedure.

[0011] Another example embodiment of the techniques is a device operating as a radio access network (RAN) node, the device comprising processing hardware and configured to implement the above method.

[0012] Another example embodiment of the techniques is a device operating as a user equipment (UE) comprising processing hardware and configured to implement the above method. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1A is a block diagram of an example system in which a radio access network (RAN) and a user device may implement the disclosed techniques for managing conditional procedures related to a secondary node (SN);

[0014] Figure 1B Yes, you can Figure 1A A block diagram of an example base station including a centralized unit (CU) and a distributed unit (DU) operating in a system;

[0015] Figure 2A is a block diagram of the example protocol stack, Figure 1A The UE communicates with the base station according to the protocol stack;

[0016] Figure 2B is a block diagram of an example protocol stack, Figure 1A The UE communicates with the CU and DU according to the protocol stack;

[0017] Figure 3 is a messaging diagram for an example scenario in which the CU provides a mobility configuration with reference to lower layer triggers to the DU for use in generating a configuration for the UE;

[0018] Figure 4 is with Figure 3 Message passing diagram for an example scenario similar to the scenario of FIG, but where the base station includes a source DU (S-DU) and a target DU (T-DU);

[0019] Figure 5A is with Figure 3 Message passing diagram of an example scenario similar to the scenario of FIG, but in which the UE communicates with the MN and the SN as DC;

[0020] Figure 5B is with Figure 5A Message passing diagram of an example scenario similar to the scenario of , but where the CU provides the mobility configuration with reference to a lower trigger to the UE via the MN;

[0021] Figure 6A is with Figure 3 Message passing diagram for a similar example scenario, but where the CU communicates with the S-DU and T-DU in the SN;

[0022] Figure 6B is with Figure 6A Message passing diagram of an example scenario similar to the scenario of , but where the CU provides the mobility configuration with reference to a lower trigger to the UE via the MN;

[0023] Figure 7A is with Figure 3 Message passing diagram for a similar example scenario, but where the CU communicates with both the M-DU and the S-DU;

[0024] Figure 7B is with Figure 7A Message passing diagram for an example scenario similar to the scenario of , but where the CU provides the mobility configuration with reference to a lower trigger to the UE via the M-DU;

[0025] Figure 8A is with Figure 3 Message passing diagram for a similar example scenario, but where the CU communicates with the M-DU, S-DU, and T-DU;

[0026] Figure 8B is with Figure 8A Message passing diagram for an example scenario similar to the scenario of , but where the CU provides the mobility configuration with reference to a lower trigger to the UE via the M-DU;

[0027] Figure 9A is a flow chart depicting an example method implemented in a DU, wherein the DU determines whether to generate an LTM configuration that configures a UE to perform or not perform a random access procedure based on whether a cell is synchronized with a serving cell;

[0028] Figure 9B It is depicted with Figure 9A a flowchart of an example method similar to the method of , but wherein the DU makes the determination based on whether the DU is a serving DU of the UE;

[0029] Figure 9C It is depicted with Figure 9Aa flowchart of an example method similar to the method of , but wherein the DU makes the determination based on whether the message from the CU is a UE context establishment request or a UE context modification request message;

[0030] Figure 9D It is depicted with Figure 9A a flowchart of an example method similar to the method of , but wherein the DU makes the determination based on whether the UE supports RACH-less LTM;

[0031] Figure 9E It is depicted with Figure 9A a flowchart of an example method similar to the method of , but wherein the DU makes the determination based on whether the UE supports deriving uplink transmission timing based on a reference signal;

[0032] Figure 9F It is depicted with Figure 9A a flowchart of an example method similar to the method of , but wherein the DU makes the determination based on whether a message from the CU requests that the UE be configured to perform a random access procedure after receiving an LTM command;

[0033] Figure 10 is a flow chart depicting an example method implemented in a CU, wherein the CU determines whether to generate a message requesting a DU to configure the UE to perform or not perform a random access procedure based on whether the UE supports RACH-less LTM;

[0034] Figure 11A is a flow chart depicting an example method implemented in a RAN node, wherein the RAN node generates an LTM configuration that does not include a reconfiguration with a synchronization field and includes a serving cell configuration and / or a UE ID;

[0035] Figure 11B It is depicted with Figure 11A a flowchart of an example method similar to the method of , but wherein the RAN node generates an LTM configuration including an indication to configure the UE to not perform a random access procedure;

[0036] Figure 12A is a flow chart depicting an example method implemented in a RAN node, wherein the RAN node determines whether to send an LTM command instructing a UE to perform or not perform a random access procedure concurrently with a serving cell change based on whether a cell is synchronized with a serving cell;

[0037] Figure 12B It is depicted with Figure 12Aa flowchart of an example method similar to the method of , but wherein the RAN node makes the determination based on whether the cell and the serving cell are operated by the RAN node;

[0038] Figure 12C It is depicted with Figure 12A a flowchart of an example method similar to the method of , but wherein the RAN node makes the determination based on whether the UE supports RACH-less LTM;

[0039] Figure 12D It is depicted with Figure 12A a flowchart of an example method similar to the method of , but wherein the RAN node makes the determination based on whether the UE supports deriving uplink transmission timing based on a reference signal;

[0040] Figure 12E It is depicted with Figure 12A a flowchart of an example method similar to the method of , but wherein the RAN node makes the determination based on whether the UE is configured with a reference signal for deriving uplink transmission timing;

[0041] Figure 12B It is depicted with Figure 12A a flowchart of an example method similar to the method of , but wherein the RAN node makes the determination based on whether the UE activates reception of a reference signal for deriving uplink transmission timing;

[0042] Figure 13A is a flow chart depicting an example method implemented in a RAN node, wherein the RAN node sends an LTM configuration and a non-LTM configuration to a UE before sending an LTM command to cause the UE to perform a serving cell change;

[0043] Figure 13B It is depicted with Figure 13A A flowchart of an example method similar to the method of , but wherein the RAN node sends an LTM command to cause the UE to additionally receive a reference signal;

[0044] Figure 13C It is depicted with Figure 13A a flowchart of an example method similar to the method of , but wherein the RAN node determines whether to send a non-LTM configuration based on whether the UE supports deriving uplink transmission timing based on a reference signal;

[0045] Figure 13B It is depicted with Figure 13C a flowchart of an example method similar to the method of , but wherein when the UE supports deriving uplink transmission timing based on a reference signal, the RAN node sends an LTM command to cause the UE to additionally receive the reference signal;

[0046] Figure 14Ais a flow chart depicting an example method implemented in a RAN node, wherein the RAN node determines whether to perform a random access procedure with a UE or attempt to receive a Physical Uplink Control Channel (PUCCH) transmission from the UE based on whether the RAN node configured the UE to perform a random access procedure; and

[0047] Figure 14B It is depicted with Figure 14A Flowchart of an example method similar to that of , but in which the RAN node determines whether to perform a random access procedure or attempt to receive a Physical Uplink Shared Channel (PUSCH) transmission from the UE. DETAILED DESCRIPTION

[0048] Figure 1A An example wireless communication system 100 is depicted in which a communication device may implement these techniques. Wireless communication system 100 includes a UE 102, a base station (BS) 104, a base station 106, and a core network (CN) 110. UE 102 initially connects to base station 104. In some scenarios, base station 104 may perform a SN add to configure UE 102 to operate in dual connectivity (DC) with base station 104 and base station 106. Base stations 104 and 106 operate as the mobile node and a network node, respectively, of UE 102.

[0049] 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 a MeNB and the base station 106 is an SgNB, the UE 102 can be in EUTRA-NR DC (EN-DC) with the MeNB and the SgNB.

[0050] In some cases, the MeNB or SeNB is implemented as an ng-eNB instead of an eNB. When the base station 104 is a master ng-eNB (Mng-eNB) and the base station 106 is an 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 a MgNB and the base station 106 is an SgNB, the UE 102 can be in NR-NR DC (NR-DC) with the MgNB and the SgNB. When the base station 104 is a MgNB and the base station 106 is a secondary ng-eNB (Sng-eNB), the UE 102 can be in NR-EUTRA DC (NE-DC) with the MgNB and the Sng-eNB.

[0051] In a scenario where UE 102 is handed over from base station 104 to base station 106, base stations 104 and 106 operate as a source base station (S-BS) and a target base station (T-BS), respectively. For example, before the handover, UE 102 may communicate with base station 104 and an additional base station ( Figure 1A After the handover is completed, UE 102 may continue to operate in DC with base station 106 and the additional base station or operate in single connectivity (SC) with base station 106. In this case, base stations 104 and 106 operate as a source MN (S-MN) and a target MN (T-MN), respectively.

[0052] The core network (CN) 110 may be an evolved packet core (EPC) 111 or a fifth generation core (5GC) 160, both of which are Figure 1A 1. The base station 104 may be an eNB supporting an S1 interface for communicating with the EPC 111, an ng-eNB supporting an NG interface for communicating with the 5GC 160, or a gNB supporting both an NR radio interface and an NG interface for communicating with the 5GC 160. To exchange messages directly with each other during the scenarios discussed below, the base stations 104 and 106 may support an X2 or Xn interface. Among other components, the EPC 111 may 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 deliver user plane packets associated with audio calls, video calls, internet services, 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, such as an internet network and / or an internet protocol (IP) multimedia subsystem (IMS) network. 5GC 160 includes a user plane function (UPF) 162, an access and mobility management (AMF) 164, and / or a session management function (SMF) 166. UPF 162 is generally configured to deliver user plane packets related to audio calls, video calls, Internet services, etc., AMF 164 is configured to manage authentication, registration, paging, and other related functions, and SMF 166 is configured to manage PDU sessions.

[0053] like Figure 1A As shown, base station 104 supports cell 124A, and base station 106 supports cell 126. Cells 124A and 126 may partially overlap, such that UE 102 may communicate with base station 104 and base station 106 in DC, where one of base stations 104 and 106 is a MN and the other is a SN. Base station 104 may support additional cells (such as cells 124B and 124C), and base station 106 may support additional cells ( Figure 1A(not shown). Cells 124A, 124B, and 124C may partially overlap, allowing UE 102 to communicate with base station 104 using carrier aggregation (CA). Base station 104 may operate cells 124A, 124B, and 124C via one or more transmission and reception points (TRPs). More specifically, when UE 102 operates in DC with base station 104 and base station 106, one of base stations 104 and 106 operates as a MeNB, Mng-eNB, or MgNB, while the other operates as an SgNB or Sng-eNB.

[0054] In general, the wireless communication network 100 may include any suitable number of base stations supporting NR cells and / or EUTRA cells. More specifically, the EPC 111 or the 5GC 160 may be connected to any suitable number of base stations supporting NR cells and / or EUTRA cells. Although the examples below specifically relate to specific CN types (EPC, 5GC) and RAT types (5G NR and EUTRA), in general, the techniques of the present disclosure may also be applicable to other suitable radio access technologies and / or core network technologies, such as sixth generation (6G) radio access and / or 6G core network or 5G NR-6G DC.

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

[0056] The processing hardware 130 may also include an LTM controller 136 configured to implement the following reference Figures 3 to 14B At least some of the techniques discussed.

[0057] UE 102 is equipped with processing hardware 150, which may include one or more general-purpose processors (such as CPUs) and non-transitory computer-readable memory storing machine-readable instructions that can be executed on one or more general-purpose processors, and / or dedicated processing units. A PHY controller (not shown) is also configured to receive data and control signals on physical DL channels and / or DL ​​reference signals with base station 104 or 106 via one or more cells (e.g., cells 124A, 124B, 124C, and / or 126) and / or one or more TRPs. The PHY controller is also configured to send data and control signals on physical UL channels and / or UL reference signals with base station 104 or 106 via one or more cells (e.g., cells 124A, 124B, 124C, and / or 126) and / or one or more TRPs. In an example implementation, processing hardware 150 includes a MAC controller 152, which is configured to perform MAC functions with base station 104 or 106. For example, MAC functions include random access procedures, managing UL timing advance for one or more user devices, and communicating UL / DL MAC PDUs with base stations 104 or 106. The processing hardware 150 may also include an RRC controller 154 to implement procedures and message delivery at the RRC sublayer of the protocol communication stack. In addition, the processing hardware 150 may also include an LTM controller 156 configured to implement the following reference Figures 3 to 14B At least some of the techniques discussed.

[0058] In operation, a UE 102 in DC may use radio bearers (e.g., DRBs or SRBs) that terminate at different times at the MN 104 or the SN 106. The UE 102 may apply one or more security keys when communicating on the radio bearers in the uplink (UL) (from the UE 102 to the base station) and / or downlink (from the base station to the UE 102) directions.

[0059] Figure 1BAn example distributed implementation of a base station, such as base station 104 or 106, is depicted. In this implementation, the base station may include a centralized unit (CU) 172 and one or more distributed units (DUs) 174. CU 172 is equipped with processing hardware, which may 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 dedicated processing units. In one example, CU 172 is equipped with processing hardware 130. In another example, CU 172 is equipped with processing hardware 140. In an example implementation, processing hardware 140 includes an SN RRC controller (not shown) configured to manage or control one or more RRC configurations and / or RRC procedures when base station 106 operates as an SN. DU 174 is also equipped with processing hardware, which may 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 dedicated processing units. In some examples, in an example implementation, the processing hardware includes: a medium access control (MAC) controller configured to manage or control one or more MAC operations or procedures (e.g., random access procedures); 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 a MN or a SN. The processing hardware may also include a physical layer controller configured to manage or control one or more physical layer operations or procedures.

[0060] Figure 2A An example protocol stack 200 is shown in a simplified manner, according to which a UE 240 (e.g., the UE may be implemented as UE 102) may communicate with an eNB / ng-eNB 230 (e.g., the eNB / ng-eNB may be implemented as base station 104 or 106) or a gNB (e.g., the gNB may be implemented as base station 104).

[0061] In the example stack 200, the EUTRA physical layer (PHY) 202A provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to the EUTRA PDCP sublayer 208 and, in some cases, to the NR PDCP sublayer 210. Similarly, the NRRPHY 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 delivery services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 may then provide data delivery services to the Service Data Adaptation Protocol (SDAP) 212 or the Radio Resource Control (RRC) sublayer ( Figure 2A In some implementations, the UE 102 supports both EUTRA and NR stacks, such as Figure 2A As shown, to support switching between EUTRA and NR base stations and / or support DC through EUTRA and NR interfaces. Figure 2A As shown, the UE 102 may support NR PDCP 210 layered on top of the EUTRA RLC 206A, and the SDAP sublayer 212 layered on top of the NR PDCP sublayer 210.

[0062] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets, which may be referred to as service data units (SDUs) (e.g., from an Internet Protocol (IP) layer layered directly or indirectly on the PDCP layer 208 or 210), and output packets, which may be referred to as protocol data units (PDUs) (e.g., to the RLC layer 206A or 206B). For simplicity, this disclosure refers to both SDUs and PDUs as "packets," except where the difference between SDUs and PDUs is relevant.

[0063] On the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide signaling radio bearers (SRBs) or RRC sublayers ( Figure 2A The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may exchange data (e.g., RRC messages or non-access stratum (NAS) messages) on the user plane. The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide data radio bearers (DRBs) to support data exchange. The data exchanged on the NR PDCP sublayer 210 may be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0064] Figure 2BAn example protocol stack 250 is shown in simplified form whereby 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 represented by Figure 2B 20. The CU at either base station 104 or 106 can maintain all control and upper layer functions (e.g., RRC 214, SDAP 212, NR PDCP 210), while lower layer operations (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support connectivity to the 5GC, NR PDCP 210 provides SRBs to RRC 214, and NR PDCP 210 provides DRBs to SDAP 212 and SRBs to RRC 214.

[0065] Next is the Figure 1A Several example scenarios are provided in which a base station operating in a system sends a configuration to a UE 102 and later activates the configuration for communication between the UE 102 and the base station. Figures 3 to 8B Similar events are marked with similar reference numerals (e.g., event 316 and Figure 4 A and Figure 4 B's event 416, Figure 5A Event 516, Figure 5B Event 517, Figure 6A Event 616, Figure 6B Event 617, Figure 7A Event 716, Figure 7B Event 717, Figure 8A Event 816 and Figure 8B 817 in the drawings), with differences discussed below where appropriate. In addition to the differences shown in the figures and discussed below, any of the alternative implementations discussed with respect to a particular event (e.g., for message delivery and processing) can be applied to events labeled with similar reference numbers in other figures.

[0066] First reference Figure 3 In scenario 300, base station 104 includes CU 172 and DU 174, and DU 174 operates cell 124A. UE 102 initially communicates 302 with DU 174 on cell 124A using a serving DU configuration, and communicates with CU 172 via DU 174 (e.g., using a serving CU configuration). In some implementations, UE 102 uses a serving DU configuration to communicate between cell 124A and other cells (e.g., Figure 1A174 operates other cells. In other implementations, UE 102 communicates with DU 174 only on cell 124A. In some implementations, UE 102 communicates with DU 174 on cell 124A and / or other cells via one or more TRPs. In some implementations, cell 124A is a PCell. In such cases, the other cells include SCells and / or additional cells associated with the PCell or SCell. In other implementations, cell 124A is an SCell and one of the other cells is a PCell. In such cases, the rest of the cells include SCells and / or additional cells associated with the PCell or SCell. In the following description, depending on the implementation, base station 104 is DU 174, CU 172, or DU 174 and CU 172.

[0067] In some implementations, at event 302, UE 102 sends UL PDUs and / or UL control signals to base station 104 on cell 124A and / or other cells via one or more TRPs. In some implementations, UE 102 communicates UL PDUs and / or DL ​​PDUs with base station 104 via radio bearers, which include SRBs and / or DRBs. In other implementations, base station 104 configures radio bearers for UE 102. In some implementations, the UL control signals include UL control information, channel state information, hybrid automatic repeat request (HARQ) acknowledgement (ACK), HARQ negative ACK, scheduling request, and / or sounding reference signal. Similarly, in other implementations, UE 102 receives DL PDUs and / or DL ​​control signals from base station 104 on cell 124A and / or other cells via one or more TRPs. In some implementations, the DL control signals include downlink control information (DCI) and reference signals (e.g., synchronization signal blocks, channel state information reference signals (CSI-RS), and / or tracking reference signals). In some implementations, the base station 104 sends the DCI on a physical downlink control channel (PDCCH) monitored by the UE 102 on cell 124A and / or other cells via one or more TRPs.

[0068] In some implementations, the serving DU configuration includes physical layer configuration parameters, MAC configuration parameters, and / or RLC configuration parameters. In some implementations, the DU 174 sends the configuration parameters to the CU 172. The CU 172 generates one or more messages (e.g., RRC reconfiguration messages) including the configuration parameters and sends the one or more messages to the UE 102 via the DU 174. In other implementations, the DU 174 sends the configuration parameters directly to the UE 102. In some implementations, the serving DU configuration is a CellGroupConfig IE (e.g., defined in 3GPP TS 38.331). In other implementations, the serving DU configuration includes configuration parameters in the CellGroupConfig IE. In some implementations, the serving CU configuration includes PDCP configuration parameters, measurement configuration parameters, and / or radio bearer configuration parameters. In some implementations, the serving CU configuration includes a MeasConfig IE and / or a RadioBearerConfig IE (e.g., defined in 3GPP TS 38.331), or includes configuration parameters in the MeasConfig IE and / or the RadioBearerConfig IE. In some implementations, the serving DU configuration includes a CSI-MeasConfig IE or configuration parameters for channel state information (CSI) measurement and reporting. In other implementations, the serving CU configuration includes a CSI-MeasConfig IE or configuration parameters for channel state information (CSI) measurement and reporting. In some implementations, the UE 102 receives the serving CU configuration or the configuration parameters in the serving CU configuration from the CU 172 via the DU 174. In other implementations, the UE 102 receives a portion of the serving CU configuration and / or a portion of the serving DU configuration from a base station other than the base station 104, and receives the remainder of these configuration parameters from the base station 104.

[0069] While communicating with base station 104, UE 102 sends 304 at least one measurement report to DU 174. In some implementations, the at least one measurement report includes a Layer 1 (L1) measurement report and / or a Layer 3 (L3) measurement report for at least one serving cell and / or at least one non-serving cell of UE 102. For each L3 measurement report, DU 174 sends 306 a DU-to-CU message to CU 172 including the L3 measurement report. In some implementations, the DU-to-CU message of event 306 is an F1 Application Protocol (F1AP) message (e.g., an UL RRC messaging message). In some implementations, DU 174 does not send or refrains from sending the L1 measurement report to CU 172. The at least one serving cell includes cell 124A and / or other cells, and the at least one non-serving cell includes cell 124B and / or cell 124C. In some implementations, a serving DU configuration or a serving CU configuration includes at least one measurement configuration. In some implementations, at event 302, UE 102 receives one or more RRC messages (e.g., RRCReconfiguration messages) from CU 172 via DU 174, including at least one measurement configuration. Based on the at least one measurement configuration, UE 102 performs measurements and sends 304 at least one measurement report to DU 174. In some implementations, the at least one measurement configuration includes an L3 measurement configuration (e.g., a MeasConfig IE) and / or an L1 measurement configuration. In some implementations, the L1 measurement configuration (e.g., a CSI-MeasConfig IE) includes an L1 measurement resource configuration and / or an L1 measurement report configuration. In another implementation, the L1 measurement resource configuration configures reference signal (e.g., CSI-RS) resources for UE 102 to measure and obtain L1 measurement results. For example, the L1 measurement resource configuration is a CSI-ResourceConfig IE. In another example, the L1 measurement report configuration configures the manner in which UE 102 sends L1 measurement results / reports. For example, the L1 measurement report configuration is a CSI-ReportConfig IE. For example, UE 102 sends an L3 measurement report to CU 172 via DU 174 according to the L3 measurement configuration. UE 102 sends an L1 measurement report to DU 174 according to the L1 measurement configuration or L1 measurement report configuration. In some implementations, DU 174 does not send an L1 measurement report to CU 172.

[0070] In some implementations, the L1 measurement configuration is an RRC IE specifically defined for lower layer triggered mobility (LTM) (e.g., in 3GPP TS 38.331). In some implementations, the L1 measurement resource configuration is an RRC IE specifically defined for LTM (e.g., in 3GPP TS 38.331). In some implementations, the L1 measurement report configuration is an RRC IE specifically defined for LTM (e.g., in 3GPP TS 38.331). In some implementations, each of the L1 measurement report configurations includes a triggering event configuration that configures a triggering event to trigger the UE 102 to send an L1 measurement report. If the UE 102 detects a triggering event, the UE 102 sends the L1 measurement report to the DU 174.

[0071] In some implementations, (each of) the L1 measurement reports includes at least one L1 measurement result. In some implementations, at least the L1 measurement result includes at least one L1 reference signal received power (L1-RSRP) value, L1 reference signal received quality (L1-RSRQ), and / or L1 signal-to-interference and noise ratio (L1-SINR) value. In some implementations, for each of the L1 measurement reports, the UE 102 sends a PUCCH transmission including the L1 measurement report to the DU 174. That is, the UE 102 sends each of the L1 measurement reports to the DU 174 on the PUCCH. In other implementations, for each of the L1 measurement reports, the UE 102 sends a PUSCH transmission including the L1 measurement report to the DU 174. That is, the UE 102 sends each of the L1 measurement reports to the DU 174 on the PUSCH. In yet other implementations, the UE 102 transmits a portion of the L1 measurement report to the DU 174 on the PUCCH and transmits the remainder of the L1 measurement report on the physical UL shared channel (PUSCH). That is, for each portion of the L1 measurement report, the UE 102 transmits a PUCCH transmission including the L1 measurement report to the DU 174, and for each of the remaining portions of the L1 measurement report, the UE 102 transmits a PUSCH transmission including the L1 measurement report to the DU 174. In some implementations, each of the L1 measurement reports is a portion of channel state information (CSI) (i.e., a CSI component) or CSI. In some implementations, the UE 102 includes other CSI components in (each of) the PUCCH transmission and / or PUSCH transmission described above. In some implementations, other CSI components include 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 send the L1 measurement report to the DU 174 in the format of an RRC message. In some implementations, each of the L1 measurement reports includes an L1 event ID for identifying or indicating a triggered L1 event. Alternatively, each of the L1 measurement reports does not include an L1 event ID for identifying or indicating a triggered L1 event.

[0072] In some implementations, each of the L3 measurement reports 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 sends each of the L3 measurement reports to the CU 172 via the DU 174 on the PUSCH. In some implementations, each of the L3 measurement reports is an RRC message (e.g., a MeasurementReport message). In some implementations, each of the L3 measurement configurations includes a specific measurement identifier (e.g., measId), and each of the L3 measurement reports includes a specific measurement identifier in a specific L3 measurement configuration. In some implementations, when the CU 172 receives the L3 measurement report including the measurement identifier and the L3 measurement result from the UE 102 via the DU 174, the CU 172 determines that the L3 measurement report is associated with the L3 measurement configuration identified by the measurement identifier.

[0073] In some alternative implementations, for each of at least one measurement report (e.g., an L1 measurement report), at event 304, the UE 102 sends a MAC control element (CE) including the measurement report to the DU 174. To send the MAC CE, at event 304, the UE 102 generates one or more MAC PDUs to the DU 174, each MAC PDU including one or more of the MAC CEs.

[0074] In some implementations, the UE 102 performs measurements on one or more reference signals according to at least one measurement configuration. Depending on the implementation, 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 at least one L1 measurement result and / or at least one L3 measurement result from the measurements. The DU 174 performs measurements on the cell 124A and other cells (e.g., cell 124B, cell 124C, and / or cell 124B). Figure 1A One or more reference signals are sent on a cell (not shown in the figure).

[0075] After receiving one or more of the at least one measurement report from UE 102 (e.g., in response to receiving one or more of the at least one measurement report from UE 102), base station 104 (i.e., CU 172 or DU 174) determines to prepare a first cell (e.g., cell 124B) for LTM for UE 102. In some implementations, base station 104 determines to prepare the first cell for UE 102 because at least one measurement report indicates that the first cell can be used by base station 104 to communicate with UE 102. In some implementations, base station 104 determines to prepare the first cell for UE 102 because at least one measurement report indicates that the first cell qualifies as a candidate cell that can be used for communication with UE 102. In some implementations, CU 172 determines to prepare the first cell for UE 102 if the L3 measurement report indicates that the signal strength and / or quality of the first cell is above a first predetermined threshold, is better than the strength and / or quality of cell 124A, and / or is better than the strength and / or quality of cell 124A by a first predetermined threshold. In other implementations, if the L1 measurement report indicates that the signal strength and / or quality of the first cell is above a first predetermined threshold, is better than the signal strength and / or quality of cell 124A, and / or is better than the signal strength and / or quality of cell 124A by a first predetermined threshold, then 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.

[0076] If the CU 172 determines to prepare the first cell for LTM, the CU 172 sends 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 identifier (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 identifier (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 LTM configuration (hereinafter referred to as LTM configuration 1) for the UE 102 to configure the first cell for LTM. The DU 174 then sends 310 a first DU-to-CU message including the LTM configuration 1 to the CU 172 in response to the first CU-to-DU message. In some implementations, DU 174 includes cell ID 1 along with LTM configuration 1 in the IE of the first DU-to-CU message to indicate that LTM configuration 1 is associated with the first cell (i.e., cell ID 1). If DU 174 determines to prepare the first cell, DU 174 initiates transmission of the first DU-to-CU message to CU 172 rather than responding to a CU-to-DU message received from CU 172.

[0077] In some implementations, DU 174 includes the cell ID of the first cell associated with LTM configuration 1 in the first DU-to-CU message to indicate that LTM configuration 1 is configured for or associated with the first cell. CU 172 recognizes that LTM configuration 1 is configured for or associated with the first cell. In some scenarios and implementations, CU 172 includes additional cell IDs (e.g., cell IDs 2, ..., N) in the first CU-to-DU message to prepare the additional cells (e.g., cells 2, ..., N) for LTM for UE 102, and DU 174 includes additional LTM configurations (e.g., LTM configurations 2, ..., N), each configuring a specific one of the additional cells, as described below. In such cases, DU 174 includes additional cell IDs associated with the additional LTM configurations in the first DU-to-CU message to indicate which LTM configuration is associated with which cell (ID). Cells 1 and / or 2, ..., N are candidate cells.

[0078] In some implementations, CU 172 does not include a (reference) LTM configuration in the first CU-to-DU message. In such cases, DU 174 generates a reference LTM configuration, generates LTM configurations 1 and / or 2, ..., N (i.e., non-reference LTM configurations) based on the reference LTM configuration, and includes the reference LTM configuration in the first DU-to-CU message. In other implementations, CU 172 includes a reference LTM configuration in the first CU-to-DU message. In such cases, DU 174 generates LTM configurations 1 and / or 2, ..., N, which are incremental configurations for enhancing the reference LTM configuration. In yet other implementations, CU 172 includes a reference LTM configuration (e.g., the first reference LTM configuration) in the first CU-to-DU message. In such cases, DU 174 generates a reference LTM configuration (e.g., a second reference LTM configuration) that replaces the first reference LTM configuration, generates LTM configurations 1 and / or 2, ..., N based on the second reference LTM configuration, and includes the second reference LTM configuration in the first DU to CU message.

[0079] In some implementations, the reference LTM configuration includes physical layer configuration parameters, MAC configuration parameters, and / or RLC configuration parameters. In some implementations, the reference LTM configuration is a CellGroupConfig IE (e.g., as defined in 3GPP TS 38.331). In other implementations, the reference LTM configuration includes configuration parameters in a CellGroupConfig IE. In some implementations, the reference LTM configuration includes a CSI-MeasConfig IE or configuration parameters for channel state information (CSI) measurement and / or reporting.

[0080] In some implementations, the reference LTM configuration is different from the serving DU configuration. In some implementations, a portion of the reference LTM configuration is identical to a portion of the serving DU configuration, and the remainder of the reference LTM configuration is different from the remainder of the serving DU configuration. In other implementations, the reference LTM configuration is identical to the serving DU configuration.

[0081] After receiving the first DU-to-CU message, CU 172 generates an RRC reconfiguration message (e.g., an RRCReconfiguration message) that includes LTM configuration 1 and sends 316 a second CU-to-DU message that includes the RRC reconfiguration message to DU 174. In some implementations, CU 172 includes a reference LTM configuration in RRC reconfiguration message 316. In other implementations, CU 172 does not include the reference LTM configuration in RRC reconfiguration message 316. In some implementations, if CU 172 sends a reference LTM configuration to UE 102 during event 302, CU 172 does not include the reference LTM configuration in RRC reconfiguration message 316. In other implementations, if CU 172 receives the reference LTM configuration from DU 174, CU 172 includes the LTM configuration in RRC reconfiguration message 316. Otherwise, if the CU 172 does not receive the reference LTM configuration from the DU 174 , the CU 172 does not include the reference LTM configuration in the RRC reconfiguration message 316 .

[0082] After receiving the RRC reconfiguration message 316, DU 174 sends 318 the RRC reconfiguration message to UE 102. In response, UE 102 sends 320 an RRC reconfiguration complete message (e.g., an RRCReconfigurationComplete message) to DU 174, which in turn sends 322 a second DU-to-CU message including the RRC reconfiguration complete message to CU 172. In some implementations, CU 172 performs security protection (e.g., integrity protection and / or encryption) on the RRC reconfiguration message. For example, CU 172 generates a message authentication code (MAC-I) for integrity 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, at events 316 and 318, sends a PDCP PDU including the encrypted RRC reconfiguration message and the encrypted MAC-I to UE 102 via DU 174. When UE 102 receives the PDCP PDU from CU 172 via DU 174 (i.e., events 316 and 318), UE 102 decrypts the encrypted RRC reconfiguration and the encrypted MAC-I to obtain the RRC reconfiguration message and the MAC-I and verifies whether the MAC-I is valid. If UE 102 verifies that the MAC-I is invalid, UE 102 discards or ignores the RRC reconfiguration message. In some implementations, UE 102 performs an RRC connection reestablishment procedure in response to the invalid MAC-I. Otherwise, in another implementation, if UE 102 verifies that the MAC-I is valid, UE 102 processes the RRC reconfiguration. UE 102 avoids applying (i.e., executing) LTM configuration 1 until a configuration activation command is received to activate LTM configuration 1 (e.g., event 330).

[0083] Events 308 (optional) and 310 Figure 3 are collectively referred to as the LTM preparation process 390. Events 316, 318, 320, and 322 are Figure 3 are collectively referred to as the LTM configuration delivery process 394.

[0084] In some implementations, prior to receiving the first CU-to-DU message, the DU 174 sends the reference LTM configuration to the UE 102 in a process similar to processes 390 and 392. In such cases, the DU 174 does not include the reference LTM configuration in the first DU-to-CU message.

[0085] In some implementations, where the CU 172 performs multiple LTM preparation processes 390, the DU 174 includes the reference LTM configuration in a first DU-to-CU message in a first LTM preparation process in the LTM preparation process 390. In some such cases, the DU 174 does not include the reference LTM configuration in DU-to-CU messages in the remainder of the LTM preparation process 390.

[0086] 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 or a UE Context Modification Required message. In some cases where a UE Context Modification Required message is included, CU 172 sends a UE Context Modification Confirmation message to DU 174 in response to the UE Context Modification Required message. In some implementations, the second CU-to-DU message is a DL RRC messaging message. In other implementations, the second CU-to-DU message is a UE Context Modification Request message, and DU 174 sends a second DU-to-CU message (e.g., a UE Context Modification Response message) to CU 172 in response to the second CU-to-DU message.

[0087] In some implementations, CU 172 includes LTM configuration 1 in a first container (e.g., a field / IE) and includes the first container in the RRC reconfiguration message at events 316 and 318. In such cases, CU 172 generates the first container. The first container is used to indicate to UE 102 that LTM configuration 1 is not to be immediately applied. In some scenarios or implementations, UE 102 receives an RRC reconfiguration message (e.g., the RRC reconfiguration message at event 318) that includes the configuration (e.g., LTM configuration 1). If the configuration is included in the first container, UE 102 avoids immediately applying the configuration. Otherwise, in another implementation, if the configuration is not included in the first container, UE 102 immediately applies the configuration. In some implementations, the first container is a first add or modify list (e.g., an ltm-ConfigToAddModList field, an LTM-ConfigToAddModList IE, an ltm-CandidateConfigToAddModList field, or an LTM-CandidateConfigToAddModList IE). CU 172 includes LTM configuration 1 in the first element of the first add or modify list (hereinafter referred to as element 1). For example, element 1 is an add or modify IE (ltm-ConfigToAddMod field, LTM-ConfigToAddMod IE, ltm-CandidateConfigToAddMod field, or LTM-CandidateConfigToAddMod IE). In some implementations, when UE 102 receives the first add or modify list, UE 102 stores the first add or modify list (e.g., in a variable in random access memory (RAM)). In other alternative implementations, DU 174 generates a first container and includes the first container in a first DU-to-CU message. In still other alternative implementations, DU 174 generates element 1 and includes element 1 in the first DU-to-CU message.

[0088] CU assigns ID to LTM configuration 1

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

[0090] In some implementations where CU 172 assigns or generates ID 1, CU 172 sends ID 1 to DU 174, and DU 174 associates ID 1 with LTM configuration 1. In some implementations, in a first CU-to-DU message, CU 172 includes ID 1 and indicates that ID 1 is associated with LTM configuration 1. In other implementations, after receiving the first DU-to-CU message, CU 172 sends 312 a third CU-to-DU message to DU 174 that includes ID 1, instead of including ID 1 in the first CU-to-DU message. In some implementations, in the third CU-to-DU message, CU 172 includes LTM configuration 1 and ID 1. CU 172 also indicates the association between ID 1 and LTM configuration 1. Thus, DU 174 directly associates ID 1 with LTM configuration 1. In other implementations, in the third CU-to-DU message, CU 172 includes cell ID 1 and ID 1 (i.e., the first LTM ID) and indicates an association between cell ID 1 and ID 1. Thus, in some such implementations, DU 174 associates ID 1 with LTM configuration 1 based on the association between cell ID 1 and ID 1 and the association between cell ID 1 and LTM configuration 1. In still other implementations, in the third CU-to-DU message, CU 172 includes LTM configuration 1, cell ID 1, and ID 1 and indicates an association between ID 1, LTM configuration 1, and cell ID 1. In some implementations, DU 174 sends 314 a third DU-to-CU message to CU 172 in response to the third CU-to-DU message. In some implementations, the third CU-to-DU message and the third DU-to-CU message are a UE context modification request message and a UE context modification response message. Events 312 (optional) and 314 (optional) are sent in Figure 3 392. In other implementations, CU 172 includes ID 1, cell ID 1, and / or LTM configuration 1 in the second CU-to-DU message, as described above. Therefore, CU 172 may omit the third CU-to-DU message.

[0091] In some implementations where CU 172 includes ID 1 in the first CU-to-DU message, DU 174 includes ID 1 in LTM configuration 1, first container, or element 1. Alternatively, DU 174 does not include ID 1 in LTM configuration 1, first container, and / or element 1.

[0092] DU assigns ID to LTM configuration 1

[0093] In some alternative implementations, DU 174 assigns ID 1, which identifies LTM configuration 1. In some implementations, DU 174 includes ID 1 in the first DU-to-CU message. In some implementations, CU 172 includes ID 1 in the RRC reconfiguration message, as described above. In other implementations, DU 174 includes ID 1 in LTM configuration 1, the first container, or element 1. Thus, CU 172 does not include the ID identifying LTM configuration 1 in the RRC reconfiguration message, the first container, and / or element 1.

[0094] In some implementations, CU 172 includes the reference LTM configuration in the first container. For example, CU 172 includes the reference LTM configuration in a field of the first container that is different from the field of the first container that includes LTM configuration 1. In other implementations, CU 172 includes the reference LTM configuration in RRC reconfiguration message 316 and outside of the first container. For example, CU 172 generates a third container (e.g., a field / IE) to include the first container and the reference LTM configuration, and includes the third container in RRC reconfiguration message 316. In still other implementations, DU 174 includes the reference LTM configuration in the first container. For example, DU 174 includes the reference LTM configuration in a field of the first container that is different from the field of the first container that includes LTM configuration 1. In still other implementations, DU 174 generates a fourth container (e.g., a field / IE) to include the first container and the reference LTM configuration, and includes the fourth container in the first DU-to-CU message 310. In such cases, CU 172 includes the fourth container in RRC reconfiguration message 316. Alternatively, CU 172 retrieves the reference LTM configuration and LTM configuration 1 from the fourth container and includes the reference LTM DU configuration and LTM DU configuration 1, as described above.

[0095] In some implementations, neither the CU 172 nor the DU 174 assigns an ID for identifying a reference LTM configuration. In such cases, there is no ID for the reference LTM configuration.

[0096] In some implementations, LTM Configuration 1 includes multiple configuration parameters for UE 102 to communicate with DU 174 on the first cell. In some implementations, the multiple configuration parameters include 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). In some other implementations, the multiple configuration parameters include special cell configuration (e.g., SpCellConfig IE) and / or one or more SCell configurations (e.g., SCellConfig IE). In some implementations, LTM Configuration 1 is a CellGroupConfig IE (e.g., defined in 3GPP TS 38.331). In other implementations, LTM Configuration 1 includes configuration parameters in the CellGroupConfig IE.

[0097] In some implementations, DU 174 includes the random access configuration in LTM configuration 1. In other implementations, DU 174 does not include the random access configuration in LTM configuration 1. In some implementations, if cell 124A and the first cell are not synchronized, DU 174 determines to include the random access configuration in LTM configuration 1. Otherwise, if cell 124A and the first cell are synchronized, DU 174 determines not to include the random access configuration in LTM configuration 1. In other implementations, if DU 174 determines that UE 102 is not yet synchronized with the first cell in the UL, DU 174 determines to include the random access configuration in LTM configuration 1. Otherwise, if DU 174 determines that UE 102 is already synchronized with the first cell in the UL, DU 174 determines not to include the random access configuration in LTM configuration 1. If LTM configuration 1 includes the random access configuration, UE 102 performs a random access procedure according to the random access configuration at event 332, as described below. Otherwise, if LTM configuration 1 does not include a random access configuration, UE 102 skips or avoids performing the random access procedure of event 332 in response to LTM configuration 1 excluding the random access configuration.

[0098] In some implementations, regardless of whether cell 124A and the first cell are synchronized, DU 174 includes the random access configuration parameters in LTM configuration 1 and / or the reference LTM configuration. UE 102 performs a random access procedure according to the random access configuration parameters at event 332, as described below.

[0099] In some implementations, if cell 124A is synchronized with the first cell, DU 174 determines to include a first indication in LTM configuration 1, which configures UE 102 not to perform a random access procedure on the first cell. Otherwise, if cell 124A is not synchronized with the first cell, DU 174 determines not to include the first indication in LTM configuration 1. In other implementations, if DU 174 determines that UE 102 is already synchronized with the first cell in the UL, DU 174 determines to include the first indication in LTM configuration 1. Otherwise, if DU 174 determines that UE 102 is not yet synchronized with the first cell in the UL, DU 174 determines not to include the first indication in LTM configuration 1. If LTM configuration 1 includes the first indication, UE 102 skips or avoids performing the random access procedure of event 332 based on or in response to the first indication. Otherwise, if LTM configuration 1 does not include the first indication, UE 102 performs a random access procedure according to the random access configuration at event 332 in response to LTM configuration 1 excluding the first indication, as described below.

[0100] In some implementations, the DU 174 includes a reconfiguration with sync configuration (e.g., a ReconfigurationWithSync IE) in the LTM configuration 1 or the special cell configuration. In other implementations, the DU 174 does not include the reconfiguration with sync configuration (e.g., a ReconfigurationWithSync IE) in the LTM configuration 1 or the special cell configuration. In some implementations, if the cell 124A is not synchronized with the first cell, the DU 174 determines to include the reconfiguration with sync configuration in the LTM configuration 1. Otherwise, if the cell 124A is synchronized with the first cell, the DU 174 determines not to include the reconfiguration with sync configuration in the LTM configuration 1. In other implementations, if the DU 174 determines that the UE 102 is not synchronized with the first cell in the UL, the DU 174 determines to include the reconfiguration with sync configuration in the LTM configuration 1. Otherwise, if DU 174 determines that UE 102 is already synchronized with the first cell in the UL, DU 174 determines not to include the reconfiguration configuration with synchronization in LTM configuration 1. In some implementations, if LTM configuration 1 includes the reconfiguration configuration with synchronization, UE 102 performs a random access procedure at event 332 in response to or according to the reconfiguration configuration with synchronization, as described below. Otherwise, if LTM configuration 1 does not include the reconfiguration configuration with synchronization, UE 102 skips or avoids performing the random access procedure of event 332. In some implementations, DU 174 includes the cell ID of cell 1 (i.e., the first cell) (i.e., cell ID 1) in LTM configuration 1. In some implementations, cell ID 1 is a PCI. In other implementations, cell ID 1 is a CGI. In some implementations, cell ID 1 included in LTM configuration 1 is a PCI, while cell ID 1 included in the first CU-to-DU message is a CGI. In some other implementations, LTM configuration 1 includes cell index 1 that indexes cell ID 1 or the first cell (e.g., cell index 1 is not a cell ID). A cell index occupies fewer bits than a cell ID. In some implementations, CU 172 sets cell index 1 to a value and includes cell index 1 in the first CU-to-DU message at event 308.

[0101] In some implementations, after receiving one or more of the at least one measurement report for event 304 (e.g., in response to receiving one or more of the at least one measurement report for event 304), base station 104 (i.e., CU 172 or DU 174) determines to prepare additional cells of base station 104 (i.e., cells 2, ..., N) for LTM for UE 102. In some implementations, base station 104 determines to prepare the additional cells for LTM for UE 102 because at least one measurement report indicates that base station 104 can use the additional cells to communicate with UE 102. In some implementations, the additional cells include cell 124C and / or cells other than cells 124A, 124B, and 124C. In some implementations, if the L3 measurement report indicates that the signal strength and / or quality of a particular cell among the additional cells is above a corresponding predetermined threshold and / or is better than cell 124A, then CU 172 determines to prepare the particular cell for LTM for UE 102. In other implementations, if the L1 measurement report indicates that the signal strength and / or quality of a particular cell among the additional cells is above a first predetermined threshold and / or better than cell 124A, DU 174 determines to prepare the particular cell for LTM for UE 102. In some implementations, the corresponding predetermined threshold for the additional cell is different from the first predetermined threshold. In other implementations, the corresponding predetermined threshold for the additional cell is the same as the first predetermined threshold. In some implementations, the corresponding predetermined threshold for the additional cell is the same as the first predetermined threshold. Alternatively, base station 104 determines to prepare the additional cell for UE 102 regardless of whether a measurement report is received from UE 102.

[0102] If CU 172 determines to prepare an additional cell, CU 172 and DU 174 initiate and perform at least one additional LTM preparation process to prepare the additional cell for LTM, wherein each of the LTM preparation processes is similar to process 390. If DU 174 determines to prepare an additional cell, DU 174 and CU 172 initiate and perform at least one additional LTM preparation process to prepare the additional cell for LTM, wherein each of the LTM preparation processes is similar to process 390.

[0103] In some implementations, the CU 172 and the DU 174 perform LTM preparation processes 2, ..., N to prepare cells 2, ..., N, respectively, similar to process 390. In some implementations, the CU 172 includes cell IDs 2, ..., N in CU-to-DU messages 2, ..., N, respectively, during the LTM preparation processes 2, ..., N, similar to the first CU-to-DU message. During the LTM preparation processes 2, ..., N, the DU 174 generates LTM configurations 2, ..., N that configure cells 2, ..., N, and includes the LTM configurations 2, ..., N in DU-to-CU messages 2, ..., N, respectively, as described for LTM configuration 1. Upon receipt of the CU-to-DU messages 2, ..., N by the DU 174, the DU-to-CU messages 2, ..., N respond to the CU-to-DU messages 2, ..., N, respectively. "N" is an integer greater 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, 32, etc. The examples and implementations of LTM configuration 1 can be applied to LTM configurations 2, ..., N.

[0104] In other implementations, the CU 172 and the DU 174 perform a single LTM preparation process (i.e., the LTM preparation process 390) to prepare cells 1, 2, ..., N. In such cases, the DU 174 includes LTM configurations 1, 2, ..., N for cells 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 cell IDs 1, 2, ..., N associated with the LTM configurations 1, 2, ..., N, respectively, to indicate that the LTM configurations 1, 2, ..., N are configured for cell IDs 1, 2, ..., N, respectively. If the CU 172 determines to perform the LTM preparation process 390, the CU 172 includes the cell IDs 1, 2, ..., N in the first CU-to-DU message to request the DU 174 to prepare cells 1, 2, ..., N, respectively, for LTM.

[0105] In some implementations, after receiving LTM configurations 2, ..., N from DU 174, CU 172 includes LTM configurations 2, ..., N in a first container. In some implementations, CU 172 includes LTM configurations 2, ..., N in elements 2, ..., N, respectively, and includes elements 2, ..., N in the first container. In some implementations, CU 172 includes LTM IDs (i.e., IDs 2, ..., N) for identifying LTM configurations 2, ..., N, respectively, in an RRC reconfiguration message. In some implementations, CU 172 includes IDs 2, ..., N in the first container. For example, CU 172 includes IDs 2, ..., N and LTM configurations 2, ..., N in elements 2, ..., N in a first addition or modification list.

[0106] In some implementations, the CU 172 assigns IDs 2, ..., N for LTM configurations 2, ..., N, respectively. In other implementations, the CU 172 receives the IDs 2, ..., N from the DU 174 in the first DU-to-CU message of process 390. In still other implementations, the CU 172 receives the IDs 2, ..., N from the DU 174 in DU-to-CU messages 2, ..., N of LTM preparation processes 2, ..., N, respectively.

[0107] In some implementations, the CU 172 and the DU 174 perform an LTM ID assignment process for each of the LTM configurations 2, ..., N, similar to process 392. In other implementations, the CU 172 includes the IDs 2, ..., N and the LTM configurations 2, ..., N in a third CU-to-DU message and indicates the association between the IDs 2, ..., N and the LTM configurations 2, ..., N, respectively. Thus, in some implementations, the DU 174 associates the LTM configurations 2, ..., N with the IDs 2, ..., N, respectively. In still other implementations, the CU 172 includes the cell IDs 2, ..., N and the IDs 2, ..., N in the third CU-to-DU message and indicates the association between the cell IDs 2, ..., N and the IDs 2, ..., N, respectively. Therefore, in another implementation, DU 174 associates LTM configurations 2, ..., N with IDs 2, ..., N, respectively, based on the associations between cell IDs 2, ..., N and IDs 2, ..., N and the associations between cell IDs 2, ..., N and LTM configurations 2, ..., N, respectively. In other implementations, CU 172 includes IDs 2, ..., N, cell IDs 2, ..., N, and / or LTM configurations 2, ..., N in the second CU-to-DU message, as described above. Therefore, CU 172 may omit the third CU-to-DU message. In yet other implementations, CU 172 includes IDs 2, ..., N in the first CU-to-DU message and indicates that IDs 2, ..., N are associated with cell IDs 2, ..., N, respectively. In some implementations, DU 174 includes IDs 2, ..., N in LTM configurations 2, ..., N. Therefore, CU 172 does not include ID2, ..., N in the RRC reconfiguration message, the first container and / or elements 2, ..., N.

[0108] In some alternative implementations, DU 174 assigns IDs 2, ..., N. In some implementations, DU 174 includes IDs 2, ..., N in the first DU-to-CU message of process 390. In still other implementations, DU 174 includes IDs 2, ..., N in DU-to-CU messages 2, ..., N of LTM preparation processes 2, ..., N. In some implementations, CU 172 includes IDs 2, ..., N in an RRC reconfiguration message. In other implementations, DU 174 includes IDs 2, ..., N in LTM configurations 2, ..., N. Thus, CU 172 does not include an ID identifying each of LTM configurations 2, ..., N (e.g., an LTM ID) in the RRC reconfiguration message, the first container, and / or element 1.

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

[0110] In some implementations, DU 174 includes cell IDs 2, ..., N in LTM configurations 2, ..., N, respectively, to identify cells 2, ..., N. In some implementations, each of cell IDs 2, ..., N is a PCI. In some other implementations, LTM configurations 2, ..., N include cell indexes 2, ..., N that index cell IDs 2, ..., N or cells 2, ..., N, respectively. In some cases where CU 172 prepares cells 2, ..., N for LTM in process 390, CU 172 sets cell indexes 2, ..., N to different values ​​and includes cell indexes 2, ..., N in the first CU-to-CU-to-DU message at event 308. In some cases where CU 172 prepares cells 2, ..., N in an additional LTM preparation process, CU 172 sets cell indexes 2, ..., N to different values ​​and includes cell indexes 2, ..., N in the CU-to-DU message of the additional LTM preparation process. CU 172 sets the cell index 1, ..., N to different values. In some implementations, the cell IDs 1, ..., N in LTM configurations 1, ..., N are different from the cell IDs 1, ..., N in the CU-to-DU messages described above.

[0111] In some implementations, each of LTM configurations 1, ..., N includes physical configuration parameters, MAC configuration parameters, RLC configuration parameters, and / or L1 measurement configuration. In some implementations, each of LTM configurations 1, ..., N is a CellGroupConfig IE (e.g., as defined in 3GPP TS 38.331). In some implementations, each of LTM configurations 1, ..., N includes configuration parameters included in a CellGroupConfig IE (e.g., as defined in 3GPP TS 38.331). In some other implementations, the plurality of configuration parameters in each of the LTM configurations includes a specific special cell configuration (e.g., SpCellConfig IE) and / or one or more SCell configurations (e.g., SCellConfig IE). In some implementations, LTM configurations 1, ..., N are a CellGroupConfig IE (e.g., as defined in 3GPP TS 38.331). In other implementations, LTM configurations 1, ..., N include configuration parameters in the CellGroupConfig IE.

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

[0113] In other implementations, DU 174 determines to release LTM configuration K. In response to the determination, DU 174 sends a DU-to-CU message to CU 172 to release LTM configuration K. In some implementations, to indicate that LTM configuration K is released, DU 174 includes cell ID K or ID (i.e., LTM ID) K in a release indication (e.g., a field or IE) in the DU-to-CU message. Furthermore, 1 ≤ K ≤ N. After receiving the DU-to-CU message (e.g., in response to receiving the DU-to-CU message), CU 172 generates a release list including ID (i.e., LTM ID) K to release LTM configuration K or element K, and sends an RRC reconfiguration message including the release list to UE 102 via DU 174. In response, UE 102 releases LTM configuration K or element K and sends an RRC reconfiguration complete message to UE 102 via DU 174. In some implementations, CU 172 sends a CU-to-DU message to DU 174 in response to the DU-to-CU message. In some implementations, the DU-to-CU message and the CU-to-DU message are a UE CONTEXT MODIFICATION REQUIRED message and a UE CONTEXT MODIFICATION CONFIRMATION message, respectively.

[0114] After receiving the RRC reconfiguration at event 318 or sending the RRC reconfiguration complete message at event 320, the UE 102 sends 324 at least one measurement report to the DU 174, similar to event 304. In some implementations, the DU 174 sends 326 a DU-to-CU message including the at least one measurement report to the CU 172, similar to event 306. In other implementations, the DU 174 does not send the at least one measurement report to the CU 172. In some implementations, the at least one measurement report of event 324 includes an L1 measurement report or an L3 measurement report, as described for event 304. In some implementations, the UE 102 sends 324 at least one measurement report to the DU 174 on the PUCCH and / or PUSCH, similar to event 304. In other implementations, the UE 102 sends 324 at least one MAC CE including the at least one measurement report to the DU 174, similar to event 304. In some implementations, the UE 102 does not send the L1 measurement report to the DU 174 in the format of an RRC message.

[0115] In some implementations, UE 102 sends 324 at least one measurement report to DU 174 based on at least one measurement configuration. The at least one measurement configuration configures UE 102 to perform measurements and report the measurement results. CU 172 sends the at least one measurement configuration to UE 102 via DU 174. For example, during event 302 and / or 316 and / or after event 306 or 316, CU 172 sends one or more RRC messages (e.g., RRCReconfiguration messages) to UE 102 via DU 174, including the at least one measurement configuration. Depending on the implementation, the one or more RRC messages may or may not include the RRCReconfiguration message of event 316. Based on the at least one measurement configuration, 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. UE 102 obtains at least one L1 measurement result and / or at least one L3 measurement result from the measurements and includes the at least one L1 measurement result and / or at least one L3 measurement result in at least the measurement report of event 324. DU 174 transmits one or more reference signals on cell 124A, cell 1, and / or cell 2, ..., N. Depending on the implementation, the one or more reference signals are CSI-RS or SSB.

[0116] In some implementations, at least one measurement configuration includes an L3 measurement configuration (e.g., a MeasConfig IE), as described for event 304. In other implementations, at least one measurement configuration includes an L1 measurement configuration, as described for event 304. For example, the L1 measurement configuration is a CSI-MeasConfig IE (e.g., defined in 3GPP TS 38.331). In some implementations, the L1 measurement configuration includes a measurement reporting configuration. UE 102 sends an L1 measurement report to DU 174 on a PUCCH or MAC CE based on the measurement reporting configuration. DU 174 receives the L1 measurement report on a PUCCH or MAC CE based on the measurement reporting configuration. In some implementations, the measurement reporting configuration is a CSI-ReportConfig IE. In other implementations, each of the measurement reporting configurations is a specifically defined RRC IE. In some implementations, (each of) the measurement reporting configurations configures periodic reporting and / or event-triggered reporting of L1 measurement results.

[0117] In yet other implementations, at least one measurement configuration includes a measurement configuration of a specifically defined type (e.g., an LTM measurement configuration). In some implementations, the measurement configuration of the specifically defined type is specifically defined for LTM (e.g., in a 3GPP TS). In some implementations, the measurement configuration of the specifically defined type includes a reference signal resource configuration, which configures the resources in which DU 174 transmits reference signals. For example, the reference signal resource configuration includes CSI-RS and / or SSB. In some implementations, the reference signal resource configuration is a CSI-ResourceConfig IE. In another implementation, the measurement configuration of the specifically defined type includes a measurement report configuration, as described above. UE 102 sends a measurement report to DU 174 on a PUCCH or MAC CE based on the measurement report configuration. DU 174 receives the measurement report on a PUCCH or MAC CE based on the measurement report configuration. In some such cases, the measurement report is an L1 measurement report or a measurement report of a specifically defined type (e.g., an LTM measurement report). In some implementations, a specifically defined type of measurement configuration includes configuration parameters (eg, specifically defined in a 3GPP TS).

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

[0119] In yet other implementations, the DU 174 includes a bitmap instead of ID 1 or cell index 1 in the first LTM command to activate LTM configuration 1. The number of bits in the bitmap is greater than or equal to "N". In some implementations, bits 1, ..., N correspond to: cell index 1, ..., N; ID 1, ..., N; LTM configuration 1, ..., N; or element 1, ..., N, respectively, and the DU 174 sets the corresponding bit (e.g., bit 1) in the bitmap to a first value to indicate cell index 1, ID 1, LTM configuration 1, or element 1. Thus, in some such implementations, the UE 102 determines cell index 1, ID 1, LTM configuration 1, or element 1 based on bit 1 in the bitmap being set to the first value. In another implementation, bits 0, ..., N-1 correspond to cell indices 1, ..., N; IDs 1, ..., N; LTM configurations 1, ..., N; or elements 1, ..., N, respectively, and DU 174 sets the corresponding bit (e.g., bit 0) in the bitmap to a first value to indicate cell index 1, ID 1, LTM configuration 1, or element 1. Thus, in some such implementations, UE 102 determines cell index 1, ID 1, LTM configuration 1, or element 1 based on bit 0 being set to the first value in the bitmap. In such implementations, DU 174 sets the remaining bits in the bitmap to a second value to indicate that the remainder of LTM configurations 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, depending on the implementation, if DU 174 determines to activate LTM configuration L or change the serving cell to cell L, DU 174 sets the corresponding bit in the bitmap (e.g., bit L or bit L-1) to a first value and sets the remaining bits to a second value, where 1 ≤ L ≤ N. In some implementations, DU 174 sets at most one bit in the bitmap to the first value.

[0120] In some implementations, the at least one measurement report (e.g., an L1 measurement report or a specifically defined type of measurement report) of event 324 includes at least one measurement result for the first cell, the TRP of the first cell, or a reference signal transmitted on the first cell. In some implementations, the reference signal is a CSI-RS or an SSB. DU 174 determines to activate LTM configuration 1 or to send a first LTM command based on the at least one measurement result. In some implementations, DU 174 determines to activate LTM 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 an L1-RSRP value, an L1-RSRQ value, and / or an L1-SINR value. In other implementations, the at least one measurement result includes an RSRP value, an RSRQ value, and / or an SINR value for a specifically defined type of measurement report. In some implementations, the second predetermined threshold is different from the first predetermined threshold. In some implementations, the second predetermined threshold is greater than the first predetermined threshold. In this case, the at least one measurement result indicates that the first cell is suitable for communication with UE 102. In another implementation, the second predetermined threshold is equal to the first predetermined threshold. In such a case, the at least one measurement result indicates that the first cell is continuously above the second predetermined threshold or the first predetermined threshold. This indicates that the first cell is suitable for communication with UE 102. Therefore, DU 174 determines to activate LTM configuration 1 in response to the signal strength or quality of the first cell for UE 102 being above the second predetermined threshold.

[0121] In some implementations, at least one measurement report (e.g., an L3 measurement report) of events 324 and 326 includes at least one measurement result for the first cell. CU 172 determines to activate LTM configuration 1 or send the first LTM command because the at least one measurement result indicates that the 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 greater than the first predetermined threshold. In such implementations, the at least one measurement report of event 326 indicates that the signal strength or quality of the first cell is suitable for communication with UE 102. In another implementation, the second predetermined threshold is equal to the first predetermined threshold. In such implementations, the at least one measurement report of event 326 indicates that the signal strength or quality of the first cell is consistently above the second predetermined threshold or the first predetermined threshold, further indicating that the first cell is suitable for communication with UE 102. Therefore, CU 172 determines to activate LTM configuration 1 in response to the signal strength or quality of the first cell being above the second predetermined threshold. In response to the determination, CU 172 sends 328 a fourth CU-to-DU message to DU 174 to activate LTM configuration 1 or trigger a serving cell change for UE 102 to cell 1. In some implementations, CU 172 includes ID 1 in the fourth CU-to-DU message. In other implementations, CU 172 includes cell index 1 in the fourth CU-to-DU message. In response to the fourth CU-to-DU message, DU 174 sends 330 a first LTM command to UE 102 and optionally sends a fourth DU-to-CU message to CU 172. In some implementations, CU 172 includes cell index 1 in the fourth CU-to-DU message. Thus, in some such implementations, DU 174 determines to activate LTM configuration 1 based on cell index 1. In other implementations, CU 172 may include cell ID 1 in the fourth CU-to-DU message. Thus, DU 174 determines to activate LTM configuration 1 based on cell ID 1. In yet other implementations, CU 172 may include ID 1 in the fourth CU-to-DU message. Thus, DU 174 may determine to activate LTM configuration 1 based on ID 1. In some implementations, the fourth CU-to-DU message and the 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 the fourth DU-to-CU message are interface messages specifically defined for such purposes (e.g., F1 Application Protocol (F1AP) messages (e.g., specifically defined in 3GPP TS 38.473)).

[0122] In some implementations, upon determining to activate LTM configuration 1 or sending the first LTM command, or in response to determining to activate LTM configuration 1 or sending the first LTM command, DU 174 sends 329 a DU-to-CU message to CU 172 indicating that LTM is being executed. In some implementations, DU 174 includes cell ID 1 or ID 1 (i.e., LTM ID) in DU-to-CU message 329 to indicate that DU 174 is to activate LTM configuration 1. Depending on the implementation, the DU sends DU-to-CU message 329 to CU 172 before or after sending LTM command 330.

[0123] In some implementations, the first LTM command is a MAC CE included in the MAC PDU that UE 102 receives from DU 174 at event 330. In some implementations, the MAC CE is a specifically defined MAC CE (e.g., in 3GPP TS 38.321). In some implementations, DU 174 includes a subheader that identifies the specifically defined MAC CE in the MAC PDU, and UE 102 identifies the specifically defined MAC CE in the MAC PDU based on the subheader. In some implementations, the subheader includes a logical channel ID or an extended logical channel ID (e.g., defined in 3GPP TS) to identify the specifically defined MAC CE. For example, the logical channel ID or extended logical channel ID is specifically defined (e.g., in 3GPP TS 38.321) to identify the specifically defined MAC CE. In other implementations, the first LTM command is a DCI that UE 102 receives from DU 174 on the PDCCH at event 330. DU 174 generates a CRC for the DCI, scrambles the CRC with the first C-RNTI of UE 102, and transmits the DCI and the scrambled CRC on the PDCCH at event 330. In some implementations, the format of the DCI is an existing DCI format (e.g., defined in 3GPP TS 38.212). In other implementations, the format of the DCI is a DCI format specifically defined therefor (e.g., defined in 3GPP TS 38.212).

[0124] 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 of the first LTM command in the UE 102 because the UE 102 does not perform security checks (e.g., decryption and / or integrity checks) on the first LTM command.

[0125] In some implementations, after receiving the first LTM command, UE 102 sends 331 an acknowledgment to DU 174 on cell 124A or cell 124D to indicate that UE 102 received the first LTM command. In some implementations, the acknowledgment is a HARQ ACK. In other implementations, the acknowledgment 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 specifically defined MAC CE (e.g., defined in 3GPP TS 38.321). In still other implementations, the acknowledgment is a PUCCH transmission.

[0126] In some implementations, the CU 172 sends 316 an RRC reconfiguration message in response to the L3 measurement report 306 for the first cell. In some implementations, to configure the UE 102 to send the L3 measurement report 306, the CU 172 sends a first RRC reconfiguration message to the UE 102 prior to event 306 that includes an L3 measurement configuration (e.g., a MeasConfig IE). In some implementations, the DU 174 sends 330 a first LTM command in response to the L1 measurement report 324 for the first cell. In some implementations, to configure the UE 102 to send the L1 or specifically defined type of measurement report 324, the CU 172 sends a second RRC reconfiguration message to the UE 102 that includes an L1 or specifically defined type of measurement configuration. In some implementations, the first RRC reconfiguration message and the second RRC reconfiguration message are the same message (i.e., the same instance). In other implementations, the first RRC reconfiguration message and the second RRC reconfiguration message are different messages. In some implementations, the second RRC reconfiguration message is the RRC reconfiguration message of event 316. In other implementations, the second RRC reconfiguration message is different from the RRC reconfiguration message of event 316.

[0127] After receiving the first LTM command (e.g., in response to receiving the first LTM command), UE 102 identifies LTM configuration 1 according to ID 1 and applies LTM configuration 1. In some implementations, UE 102 performs 332 a random access procedure with DU 174 on the first cell in response to applying LTM configuration 1 or receiving the first LTM command. In some implementations, after receiving the first LTM command (e.g., in response to receiving the first LTM command) or after sending an acknowledgment, UE 102 disconnects from cell 124A. In other words, after receiving 330 the first LTM command or sending 331 an acknowledgment (e.g., in response to receiving 330 the first LTM command or sending 331 an acknowledgment), UE 102 ceases communicating on cell 124A. In such cases, after disconnecting from cell 124A, UE 102 performs 332 a random access procedure. In some implementations, UE 102 determines whether to perform a random access procedure based on LTM configuration 1. In some implementations, if LTM configuration 1 configures UE 102 to perform a random access procedure, UE 102 performs a random access procedure in event 332. For example, LTM configuration 1 includes a reconfiguration with synchronization configuration (e.g., ReconfigurationWithSync IE) to configure UE 102 to perform a random access procedure. Otherwise, if LTM configuration 1 does not configure UE 102 to perform a random access procedure or configures UE 102 to skip a random access procedure, UE 102 avoids performing a random access procedure with DU 174 after receiving the first LTM command. In such a case, UE 102 skips event 316. For example, if LTM configuration 1 excludes a reconfiguration with synchronization configuration, LTM configuration 1 configures 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.

[0128] When UE 102 performs 332 a random access procedure, UE 102 communicates 336 with DU 174 on the first cell using LTM configuration 1 and a reference LTM configuration, and communicates with CU 172 via DU 174 after successfully completing the random access procedure. In such cases, DU 174 communicates with UE 102 on the first cell using LTM configuration 1 at event 332 and / or event 336. In some scenarios or implementations, UE 102 communicates UL PDUs, DL PDUs, and / or physical layer signals (e.g., PUCCH transmissions and PDCCH transmissions) with base station 104 at event 336. In some implementations, UE 102 determines that UE 102 has successfully completed the random access procedure when UE 102 receives contention resolution from DU 174. In the case where the random access procedure is a four-step random access procedure, UE 102 sends message 3 including a UE identity to DU 174 via the first cell during the random access procedure. If the random access procedure is a two-step random access procedure, UE 102 transmits a message A including a UE identity to DU 174 via the first cell during the random access procedure. In some implementations, if LTM configuration 1 includes a second C-RNTI, the UE identity is the second C-RNTI of UE 102. Otherwise, if LTM configuration 1 does not include a C-RNTI, the UE identity is the first C-RNTI. If the random access procedure is a contention-free random access procedure, UE 102 transmits a dedicated random access preamble to DU 174 via the first cell. In this case, LTM configuration 1 includes a dedicated random access preamble.

[0129] The DU 174 recognizes or determines that the UE 102 is connected to the first cell after receiving the UE identification or dedicated preamble from the UE 102 in the random access procedure 332 .

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

[0131] In the event that UE 102 receives the reference LTM configuration as described above, UE 102 communicates 336 with DU 174 on the first cell in accordance with LTM configuration 1 and at least a portion of the reference LTM configuration. In other words, UE 102 communicates 336 with DU 174 in accordance with the configuration parameters in LTM configuration 1 and the reference LTM configuration. Similarly, DU 174 communicates 336 with UE 102 on the first cell in accordance with LTM configuration 1 and at least a portion of the reference LTM configuration. In other words, DU 174 communicates 336 with UE 102 in accordance with the configuration parameters in LTM configuration 1 and the reference LTM configuration.

[0132] In some implementations, the UE 102 sends an RRC message (e.g., an RRC reconfiguration complete message) to the CU 172 via the DU 174 and the first cell to instruct the UE 102 to apply LTM configuration 1. In some implementations in which the UE 102 performs the random access procedure 332, the UE 102 includes the RRC message in message 3 or message A. Alternatively, the UE 102 sends the RRC message after completing the random access procedure. In the event that the UE 102 skips the random access procedure 332, the UE 102 includes the RRC message in a PUSCH transmission in at least one PUSCH transmission. In some implementations, if the UE 102 maintains communication with the base station 104 on cell 124A (i.e., the UE 102 is not disconnected from the cell 124A), the UE 102 sends the RRC message to the base station 104 via cell 124A. When the DU 174 receives the RRC message, the DU 174 sends the RRC message to the CU 172.

[0133] In other implementations, UE 102 refrains from sending an RRC message to base station 104 in response to applying LTM configuration 1 or receiving a first LTM command. In some such cases, UE 102 includes or sends data in Message 3, Message A, or a PUSCH transmission, as described above. In some implementations, UE 102 generates a MAC PDU and / or RLC PDU including the data and sends or includes the MAC PDU and / or RLC PDU in a PUSCH transmission. For example, depending on the implementation, the data is a PDCP PDU, a SDAP PDU, an LTE Positioning Protocol (LPP) PDU, an RRC PDU, and / or a NAS PDU. The RRC PDU includes an UL-DCCH-message excluding an RRC Reconfiguration Complete message. The NAS PDU includes a Mobility Management (MM) message or a Session Management (SM) message. Depending on the implementation, 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 .

[0134] In some implementations, when DU 174 determines that UE 102 is successfully connected to the first cell at event 332 or 336, DU 174 sends 334 a DU-to-CU message (e.g., an access success message) to CU 172 (e.g., the CP of CU 172). In some implementations, DU 174 includes the cell ID 1 of the first cell in the DU-to-CU message at event 334. In some implementations, the cell ID is a PCI or CGI. Therefore, upon receiving the DU-to-CU message at event 334, CU 172 determines that UE 102 is connected to the first cell. In some implementations, when DU 174 determines that UE 102 is successfully connected to the first cell at event 332 or 336, DU 174 sends a DL data delivery status message or frame to CU 172 (e.g., the UP of CU 172).

[0135] In some implementations, upon determining that UE 102 is connected to the first cell, sending 330 a first LTM command, or receiving 331 an acknowledgment, DU 174 stops communicating with UE 102 on cell 124A and / or releases resources of cell 124A configured for UE 102.

[0136] In some implementations, DU 174 generates some or all of LTM configuration 1 and / or LTM configurations 2, ..., N as complete configurations to replace the serving DU configuration. If LTM configuration 1 is a complete configuration, UE 102 and DU 174 communicate 336 with each other based on LTM configuration 1 rather than the serving DU configuration. In some implementations, DU 174 includes an indication in LTM configuration 1 that LTM configuration 1 is a complete configuration. In some implementations, in each of LTM configurations 2, ..., N, DU 174 includes an indication that the corresponding DU configuration is a complete configuration. In some implementations, each of the indications in LTM configurations 1, ..., N is a field or IE (i.e., the same field or IE). In other implementations, CU 172 includes a single indication that LTM configurations 1 and / or 2, ..., N are complete configurations in the RRC reconfiguration message for events 316 and 318. In some cases, for the second container, CU 172 includes a single indication that LTM configurations 2, ..., N are fully configured in the additional RRC reconfiguration message. In yet other implementations, CU 172 includes a single indication that LTM configurations 1 and / or 2, ..., N are fully configured in the first container. In yet other implementations, for each of LTM configurations 2, ..., N, CU 172 includes a specific indication in the first container that the corresponding LTM configuration is fully configured. In some cases, for the second container, CU 172 includes a single indication that LTM configurations 2, ..., N are fully configured in the second container. In yet other implementations, CU 172 includes an indication that LTM configuration 1 is fully configured in element 1. In some implementations, in each of elements 2, ..., N, CU 172 includes an indication that the corresponding LTM configuration is fully configured. In some implementations, UE 102 determines that LTM configuration 1 and / or LTM configurations 2, ..., N are fully configured based on the above indications. In some implementations, each of the above indications is different from the fullConfig field (e.g., as defined in current 3GPP TS). In some implementations, each of the above indications is a fullConfig field (e.g., as defined in current 3GPP TS). In the case where LTM configuration 1 is a full configuration, if a reference LTM configuration is received from base station 104 (e.g., in RRC reconfiguration message 318), UE 102 does not apply the reference LTM configuration in event 336. In some such cases, DU 174 does not include the reference LTM configuration in the first DU to CU message 310.

[0137] In other implementations, DU 174 generates LTM configuration 1 and / or LTM configuration 2, ..., N as incremental configurations that enhance at least a portion of a reference LTM configuration. In other words, DU 174 generates LTM configurations 1, ..., N based on the reference LTM configuration. For example, if LTM configuration 1 is an incremental configuration, UE 102 and DU 174 enhance at least the portion of the reference LTM configuration with LTM configuration 1. Thus, UE 102 and DU 174 communicate 336 with each other based on LTM configuration 1 and the unenhanced portion of the reference LTM configuration. In some implementations, LTM configurations 1 and / or 2, ..., N, the first container, the second container, or the elements 1, ..., N exclude the indication that LTM configurations 1 and / or 2, ..., N are full configurations to indicate that LTM configurations 1 and / or 2, ..., N are incremental configurations. In some implementations, UE 102 determines that each of LTM configurations 1 and / or 2, ..., N is an incremental configuration based on excluding the indication in LTM configurations 1 and / or 2, ..., N, the first container, the second container, or the elements 1 and / or 2, ..., N.

[0138] In some implementations, if the UE 102 does not receive a reference LTM configuration for LTM configuration 1 and / or LTM configuration 2, ..., N, the UE 102 determines that LTM configuration 1 and / or LTM configuration 2, ..., N are complete configurations. Correspondingly, if the DU 174 does not obtain a reference LTM configuration for the UE 102 (i.e., the DU 174 does not generate a reference LTM configuration for the UE 102 and / or does not receive a reference LTM configuration for the UE 102 from the CU 172), the DU 174 generates LTM configuration 1 and / or LTM configuration 2, ..., N as complete configurations.

[0139] In other implementations, if the UE 102 does not receive a reference LTM configuration for LTM configuration 1 and / or LTM configuration 2, ..., N, the UE 102 determines that LTM configuration 1 and / or LTM configuration 2, ..., N are delta configurations for enhancing the serving DU configuration. In such a case, the UE 102 communicates 336 with the DU 174 based on LTM configuration 1 and at least a portion of the serving DU configuration that is not enhanced by LTM configuration 1. Correspondingly, if the DU 174 does not obtain a reference LTM configuration for the UE 102 (i.e., the DU 174 does not generate a reference LTM configuration for the UE 102 and / or does not receive a reference LTM configuration for the UE 102 from the CU 172), the DU 174 generates LTM configuration 1 and / or LTM configuration 2, ..., N as delta configurations for enhancing the serving DU configuration. In such a case, the DU 174 communicates 336 with the UE 102 based on LTM configuration 1 and at least a portion of the serving DU configuration.

[0140] 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., 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 332 a random access procedure 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) sending the first LTM command, receiving an acknowledgment 331, or determining that the UE 102 is connected to the first cell.

[0141] 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 complete UE MAC reset): (i) initializes Bj of the configured logical channels to zero; (ii) stops one or more timers; (iii) if the UE 102 is configured to perform a random access procedure (e.g., event 332) in a configuration (e.g., configuration 1), then timeAlignmentTimer is considered expired; (iv) a new data indicator (NDI) of the UL HARQ process is set to a value of 0; (v) the NDI of the HARQ process ID is set to a value of 0 to monitor the PDCCH in sidelink resource allocation mode 1; (vi) the Msg3 buffer is flushed; (vii) the MSGA buffer is flushed; (viii) the triggered scheduling request procedure (if any) is canceled; (ix) the triggered buffer status report procedure (if any) is canceled; (x) the triggered power headroom report procedure (if any) is canceled; (xi) the triggered consistent LBT failure (if any) is canceled; (xii) the triggered BFR is canceled (if any); (xiii) cancel the triggered sidelink buffer status reporting process (if any); (xiv) cancel the triggered preemption buffer status reporting process (if any); (xv) cancel the triggered timing advance reporting process (if any); (xvi) cancel the triggered recommended bit rate query process (if any); (xvii) cancel the triggered configured uplink grant confirmation (if any); (xviii) cancel the triggered configured sidelink grant confirmation (if any); (xix) cancel the triggered expected guard symbol query (if any); (xx) cancel the triggered positioning measurement gap activation / deactivation request process (if any); (xxi) flush the soft buffer of the DL HARQ process; (xxii) for each of the DL HARQ processes, treat the next received transmission of the TB as the first transmission; (xxiii) release the temporary C-RNTI (if any); and / or (xiv) reset one or more counters (e.g., BFI_COUNTER and / or LBT_COUNTER).

[0142] In some implementations, when DU 174 resets the DU MAC entity, DU 174 performs at least one of the following actions for the DU MAC entity (i.e., a DU MAC reset or a full DU MAC reset): (i) stops one or more timers; (ii) if UE 102 is configured in a configuration (e.g., configuration 1) to perform a random access procedure (e.g., event 332), then the timeAlignmentTimer started and / or maintained by DU 174 for UE 102 is deemed expired; (iii) sets the NDI of the DL HARQ process to a value of 0; (iv) flushes the soft buffers of the UL HARQ process; (v) for each of the UL HARQ processes, considers the next received transmission of the TB to be the first transmission; and / or (vi) resets one or more counters (e.g., BFI_COUNTER and / or LBT_COUNTER).

[0143] Depending on the implementation, the UE 102 determines to partially or completely reset the UE MAC entity. In some implementations, when the UE 102 resets the UE MAC entity as described above, the UE 102 completely resets the UE MAC entity (i.e., a complete UE MAC reset). In a complete 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 a partial UE MAC reset, the UE 102 performs a subset or portion of some or all of the actions in the complete UE MAC reset.

[0144] In some implementations, the partial UE MAC reset includes at least one of the following actions: (i) if UE 102 is configured in a configuration (e.g., configuration 1) to perform a random access procedure (e.g., event 332), then treating the timeAlignmentTimer of UE 102 as expired; (ii) flushing the Msg3 buffer; (iii) flushing the MSGA buffer; (iv) releasing the temporary C-RNTI (if any); and / or (v) resetting one or more counters (e.g., BFI_COUNTER and / or LBT_COUNTER).

[0145] In some implementations, the partial UE MAC reset further includes at least one of the following actions: (i) cancelling a triggered scheduling request procedure (if any); (ii) cancelling a triggered buffer status report procedure (if any); (iii) cancelling a triggered power headroom report procedure (if any); (iv) cancelling a triggered consistent LBT failure (if any); (v) cancelling a triggered BFR. (if any); (vi) cancel the triggered sidelink buffer status reporting procedure (if any); (vii) cancel the triggered preemption buffer status reporting procedure (if any); (viii) cancel the triggered timing advance reporting procedure (if any); (ix) cancel the triggered recommended bit rate query procedure (if any); (x) cancel the triggered configured uplink grant confirmation (if any); (xi) cancel the triggered configured sidelink grant confirmation (if any); (xii) cancel the triggered expected guard symbol query (if any); and / or (xiii) cancel the triggered positioning measurement gap activation / deactivation request procedure (if any).

[0146] In some implementations, the partial UE MAC reset further includes at least one of the following actions: (i) stopping a first portion of one or more timers and retaining the remaining portion of one or more timers; (ii) setting a new data indicator (NDI) of an UL HARQ process to a value of 0; (iii) setting the NDI of the HARQ process ID to a value of 0 to monitor the PDCCH in sidelink resource allocation mode 1; (iv) flushing soft buffers of DL HARQ processes; and / or (v) for each of the DL HARQ processes, treating the next received transmission of the TB as the first transmission;

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

[0148] In some implementations, the partial DU MAC reset includes at least one of the following actions in the partial MAC reset: (i) if the UE 102 is configured in a configuration (e.g., configuration 1) to perform a random access procedure (e.g., event 332), then treating the timeAlignmentTimer started and / or maintained by the DU 174 for the UE 102 as expired, and / or (ii) resetting one or more counters (e.g., BFI_COUNTER and / or LBT_COUNTER).

[0149] In some implementations, when a partial DU MAC reset includes at least one of the following actions for the MAC entity (i.e., a DU MAC reset): (i) stopping a first portion of one or more timers and retaining the remainder of one or more timers; (ii) setting the NDI for the DL HARQ process to a value of 0; (iii) flushing the soft buffers for the UL HARQ process; (iv) for each of the UL HARQ processes, treating the next received transmission of the TB as the first transmission; and / or (v) resetting one or more counters (e.g., BFI_COUNTER and / or LBT_COUNTER).

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

[0151] 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., 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 332 a random access procedure 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) sending the first LTM command, receiving an acknowledgment 331, or determining that the UE 102 is connected to the first cell.

[0152] In some implementations, LTM configuration 1 may or may not include one or more RLC re-establishment indications (e.g., reestablishRLC fields) that configure UE 102 to re-establish some or all of at least one UE RLC entity. If LTM configuration 1 includes an RLC re-establishment indication that configures UE 102 to re-establish a first UE RLC entity among at least one UE RLC entity used by UE 102 to communicate RLC PDUs with DU 174, UE 102 re-establishes the first UE RLC entity in response to the RLC re-establishment indication and the first LTM command. In some implementations, UE 102 re-establishes the first UE RLC entity before performing a random access procedure 332 or communicating 336 with DU 174 via the first cell. In other implementations, UE 102 re-establishes the first UE RLC entity while or after performing the random access procedure 332. Otherwise, if LTM configuration 1 does not include an RLC re-establishment indication, UE 102 refrains from re-establishing the first UE RLC entity in response to the first LTM command.

[0153] In some implementations, when UE 102 reestablishes the first UE RLC entity, UE 102 performs at least one of the following actions for the first UE RLC entity: (i) discards RLC SDUs, RLC SDU segments, and RLC PDUs (if any); (ii) stops and resets timers (if running); and / or (iii) resets state variables to initial values. In some implementations, the state variables and timers are predefined (e.g., in 3GPP TS 38.322).

[0154] Otherwise, if LTM configuration 1 does not include an RLC re-establishment indication for the first UE RLC entity, UE 102 refrains from re-establishing the first UE RLC entity upon or upon receiving the first LTM command. In other words, UE 102 refrains from performing actions for re-establishing the first UE RLC entity of UE 102 upon or upon receiving the first LTM command. In some implementations, if LTM configuration 1 or element 1 does not include an RLC re-establishment indication and includes an indication that configuration 1 is a complete configuration, UE 102 re-establishes the first UE RLC entity of UE 102 upon or upon receiving the first LTM command. Otherwise, if LTM configuration 1 or element 1 does not include an RLC re-establishment indication and an indication that configuration 1 is a complete configuration, UE 102 refrains from re-establishing the first UE RLC entity upon or upon receiving the first LTM command.

[0155] Similarly, DU 174 reestablishes some or all of the at least one DU RLC entity (e.g., NR RLC 206B) used by DU 174 to communicate with at least one UE RLC entity of UE 102 (e.g., events 302, 304, 318, 320, 324, 330, and / or 331) in response to the RLC reestablishment indication. In some implementations, DU 174 reestablishes the first DU RLC entity in the at least one DU RLC entity after sending a first LTM command, receiving an acknowledgment for the first LTM command from UE 102, or determining that UE 102 is connected to the first cell. In some implementations, the acknowledgment is a HARQ ACK. In other implementations, the acknowledgment is a MAC CE. In still other implementations, the acknowledgment 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) discarding the RLC SDU, RLC SDU segments, and RLC PDUs (if any); (ii) stopping and resetting the timer (if running); and / or (iii) resetting the state variables to initial values. In some implementations, the state variables and timers are predefined (e.g., in 3GPP TS 38.322).

[0156] In other implementations, UE 102 avoids re-establishing some or all of the at least one UE RLC entities in response to receiving the first LTM command. Similarly, DU 174 avoids re-establishing some or more of the at least one DU RLC entities after sending the first LTM command, receiving the acknowledgment 331, or determining that UE 102 is connected to the first cell (e.g., in response to sending the first LTM command, receiving the acknowledgment 331, or determining that UE 102 is connected to the first cell). In other words, UE 102 communicates with DU 174 on the first cell using some or all of the at least one UE RLC entity (not re-established). For example, some or all of the at least one UE RLC entity includes the first UE RLC entity and / or the second UE RLC entity. Similarly, DU 174 communicates with UE 102 on the first cell during or after the random access procedure 332, or after determining that UE 102 is connected to the first cell, using some or all of the at least one DU RLC entity (not re-established). For example, some or all of the at least one DU RLC entity includes the first DU RLC entity and / or the second DU RLC entity.

[0157] In some implementations, at event 302, the UE 102 communicates UL PDCP PDUs and / or DL ​​PDCP PDUs with at least one CU PDCP entity (e.g., PDCP 210) of the CU 172 using at least one UE PDCP entity (e.g., PDCP 210). In some implementations, the UE 102 performs a PDCP recovery procedure for some or all of the at least one UE PDCP entity after receiving the first LTM command or in response to receiving the first LTM command. For example, the UE 102 performs a PDCP recovery procedure for a first UE PDCP entity among the at least one UE PDCP entity after receiving the first LTM command or in response to receiving the first LTM command. Depending on the implementation, during the PDCP recovery procedure, the UE 102 may or may not re-establish the first UE PDCP entity. In some implementations, after or in response to performing the PDCP recovery procedure, at event 336, UE 102 retransmits at least a portion of the UL PDCP PDU to CU 172 via DU 174 and the first cell. Similarly, CU 172 performs a PDCP recovery procedure for some or all of the at least one CU PDCP entity after or in response to sending the first LTM command. For example, CU 172 performs a PDCP recovery procedure for a first CU PDCP entity among the at least one CU PDCP entity after or in response to sending the first LTM command. In some implementations, 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, CU 172 performs the PDCP recovery procedure for the first CU PDCP entity in response to receiving the DL data delivery status message. Depending on the implementation, during the PDCP recovery procedure, CU 172 may or may not reestablish the first CU PDCP entity. In some implementations, after or in response to performing the PDCP recovery procedure, at event 336 , the CU 172 retransmits at least a portion of the DL PDCP PDU to the UE 102 via the DU 174 and the first cell.

[0158] In other implementations, UE 102 avoids re-establishing some or all of the at least one UE PDCP entities in response to receiving the first LTM command. For example, some or all of the at least one UE PDCP entities include the first UE PDCP entity and / or the second UE PDCP entity. Similarly, CU 172 avoids re-establishing some or more of the at least one CU PDCP entities after receiving (e.g., in response to) receiving the DU-to-CU message 329 or 340 or after receiving (e.g., in response to) receiving the DL data delivery status message. In other words, UE 102 communicates with CU 172 via DU 174 and the first cell using some or all of the at least one UE PDCP entities (not re-established). For example, some or all of the at least one UE PDCP entities include the first UE PDCP entity and / or the second UE PDCP entity. Similarly, CU 172 communicates with UE 102 via DU 174 and the first cell using some or all of the at least one CU PDCP entities (not re-established). For example, some or all of the at least one CU PDCP entity include a first CU PDCP entity and / or a second CU PDCP entity.

[0159] In some implementations, after determining that the UE 102 is connected to the first cell, the CU 172 sends 338 a CU-to-DU message (e.g., a UE CONTEXT MODIFY REQUEST message) to the DU 174 to instruct the DU 174 to cease communicating with the UE 102 and / or release or suspend resources of the cell 124A configured for the UE 102. In some implementations, in response, the DU 174 ceases communicating with the UE 102 on the cell 124A and / or releases or suspends resources of the cell 124A configured for the UE 102 and sends 340 a DU-to-CU message (e.g., a UE CONTEXT MODIFY RESPONSE message) to the CU 172. Events 338 (optional) and 340 (optional) occur at Figure 3 It is collectively referred to as the resource release process 396.

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

[0161] In some implementations, upon determining to activate LTM configuration 2 or to send the second LTM command, or in response to determining to activate LTM configuration 2 or to send the second LTM command, DU 174 sends 349 a DU-to-CU message to CU 172 indicating that LTM is being executed. In some implementations, DU 174 includes cell ID 2 or ID 2 (i.e., LTM ID) in DU-to-CU message 349 to indicate that DU 174 is to activate LTM configuration 2. In some implementations, the DU sends DU-to-CU message 349 to CU 172 before or after sending LTM command 350.

[0162] The description of events 324, 326, 328, 330, 331, 332, 334, and / or 336 may be applied to 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 “LTM configuration 1” may be replaced with “first cell,” “second LTM command,” “second cell,” “ID 2,” and / or “LTM configuration 2,” respectively.

[0163] Events 344, 346, 348, 350, 351, 352, and 354 Figure 3 are collectively referred to as LTM execution process 398. Events 304, 306, 390, 392, 394, 324, 326, 328, 329, 330, 331, 332, 334, 336, 396, 398, 356 are Figure 3 is collectively referred to as the LTM configuration and / or activation process 380.

[0164] Next reference Figure 4 In scenario 400, base station 104 includes CU 172, source DU (S-DU) 174A, and target DU (T-DU) 174B. S-DU 174A operates cell 124A and optionally additional cells, while T-DU 174B operates the first cell (e.g., cell 124C). Scenario 400 is similar to scenario 300. Therefore, the description of scenario 300 is generally applicable to scenario 400. The differences between scenarios 300 and 400 are described below.

[0165] Initially, UE 102 communicates 402 with S-DU 174A on cell 124A using a serving DU configuration and communicates with CU 172 via S-DU 174A. During communication 402, UE 102 sends 404, 406 at least one measurement report (e.g., an L3 measurement report) to CU 172 via S-DU 174A. Based on the at least one measurement report, CU 172 determines to prepare cells 1, ..., N for LTM for UE 102 (operated by T-DU 174B), where N is a positive integer greater than 0 or 1. Cells 1, ..., N are identified by cell IDs 1, ..., N, respectively. In response to the determination, CU 172 performs 490 an LTM preparation procedure with T-DU 174B to (request T-DU 174B) prepare cells 1, ..., N for LTM for UE 102. In some implementations, N is a positive integer greater than 0 or 1. In LTM preparation process 490, CU 172 sends a CU-to-DU message including cell IDs 1, ..., N to T-DU 174B, requesting T-DU 174B to prepare cells 1, ..., N for LTM for UE 102, similar to event 308. In response, T-DU 174B sends a DU-to-DU message including LTM configurations 1, ..., N to CU 172, similar to event 310. LTM configurations 1, ..., N configure cells 1, ..., N for LTM, respectively. Specifically, LTM configurations 1, ..., N include configuration parameters for communication on cells 1, ..., N, respectively. In some implementations, the CU-to-DU message and DU-to-CU message in process 490 are UE Context Setup Request messages and UE Context Setup Response messages, respectively. CU 172 then sends LTM configurations 1, ..., N in an RRC reconfiguration message in LTM configuration delivery process 494, similar to LTM configuration delivery process 394. In some implementations, the T-DU 174B includes cell indices 1, ..., N in LTM configurations 1, ..., N, respectively. In some implementations, the CU 172 sets cell indices 1, ..., N to different values ​​and includes cell indices 1, ..., N in the CU-to-DU message of process 490 .

[0166] In some implementations, after performing the LTM preparation procedure 490, the CU 172 performs an additional LTM preparation procedure with the T-DU 174B to prepare cells N+1, ..., N+M for the UE 102 for LTM, where M is a positive integer greater than zero. In other implementations, the CU 172 determines to do so based on one or more measurement reports received from the UE 102 via the S-DU 174A, similar to events 404 and 406. In the additional LTM preparation procedure, the CU 172 sends a CU-to-DU message including cell IDs N+1, ..., N+M to the T-DU 174B to request that the T-DU 174B prepare cells N+1, ..., N+M for the UE 102 for LTM. The cell IDs N+1, ..., N+M identify cells N+1, ..., N+M, respectively. In response to the CU-to-DU message, T-DU 174B sends a DU-to-DU message to CU 172 that includes LTM configurations N+1, ..., N+M. LTM configurations N+1, ..., N+M are for LTM configuration cells N+1, ..., N+M, respectively. Specifically, LTM configurations N+1, ..., N+M include configuration parameters for communication on cells N+1, ..., N+M, respectively. CU 172 then sends LTM configurations N+1, ..., N+M in an RRC reconfiguration message in an additional LTM configuration delivery procedure, similar to LTM configuration delivery procedure 394 or 494.

[0167] In some implementations, the LTM preparation procedure 490 is a UE context establishment procedure, and the additional LTM preparation procedure is a UE context modification procedure.

[0168] In some implementations, the CU 172 and the S-DU 174A perform process 380 with the UE 102, as described for Figure 3 In process 380, CU 172 and S-DU 174A perform processes 390 and / or 392 to prepare the cell of S-DU 174A for LTM for UE 102. In some implementations, the process 380 or the process for Figure 3 The value N described is the same as the Figure 4The value N described may be the same or different. In some implementations, in process 390, CU 172 may receive a first DU-to-CU message including a reference LTM configuration from S-DU 174A in event 310. In other implementations, CU 172 and S-DU 174A and UE 102 do not perform process 380. In some such cases, CU 172 and S-DU 174A perform 488 a reference LTM configuration query process to obtain a reference LTM configuration. In process 488, CU 172 sends 460 a CU-to-DU message to S-DU 174A to request or query the reference LTM configuration. In some implementations, CU 172 includes an indication of requesting or querying the reference LTM configuration in the CU-to-DU message. In response to the indication or CU-to-DU message 460, S-DU 174A sends 462 a DU-to-DU message including the reference LTM configuration to CU 172. In some implementations, the indication is a reference LTM configuration query indication. In other implementations, the indication is an LTM indication, and the CU 172 includes the query indication (e.g., a GNB-DU Configuration Query IE) in a CU-to-DU message. After receiving the reference LTM configuration (i.e., in process 390 or in process 488), the CU 172 includes the reference LTM configuration (received from the S-DU 174A) in the CU-to-DU message in the LTM preparation process 490. The T-DU 174B generates LTM configurations 1, ..., N based on the reference LTM configuration received from the CU 172. In such a case, the T-DU 174B does not include the reference LTM configuration in the DU-to-CU message in process 490. In the case of an additional LTM preparation process, the T-DU 174B does not include the reference LTM configuration in the DU-to-CU message in the additional LTM preparation process. In some implementations, CU 172 does not include the reference LTM configuration in the CU-to-DU message in the additional LTM preparation process with T-DU 174B. In the case of the additional LTM preparation process, T-DU 174B generates LTM configurations N+1, ..., N+M based on the reference LTM configuration received from CU 172.

[0169] In some implementations, the CU 172 does not provide a reference LTM configuration to the T-DU 174B during the LTM preparation process 490. In such cases, the T-DU 174B generates a reference LTM configuration and generates LTM configurations 1, ..., N based on the reference LTM configuration. In such cases, the T-DU 174B includes the reference LTM configuration in a DU-to-CU message during process 490. The CU 172 sends the reference LTM configuration in an RRC reconfiguration message during process 490. In the case of an additional LTM preparation process, the T-DU 174B generates LTM configurations N+1, ..., N+M based on the reference LTM configuration. In some such cases, the T-DU 174B includes the reference LTM configuration in a DU-to-CU message during the additional LTM preparation process. In some implementations, the reference LTM configuration generated by the T-DU 174B is different from the reference LTM configuration generated by the S-DU 174A. In other implementations, the reference LTM configuration generated by the T-DU 174B is the same as the reference LTM configuration generated by the S-DU 174A.

[0170] In some implementations, CU 172 assigns IDs 1, ..., N that respectively identify LTM configurations 1, ..., N (received from T-DU 174B) and performs process 492 with T-DU 174B to provide IDs 1, ..., N and / or cell IDs 1, ..., N to T-DU 174B, similar to process 392. Thus, T-DU 174B associates IDs 1, ..., N with LTM configurations 1, ..., N and / or cell IDs 1, ..., N, respectively. In other implementations, T-DU 174B assigns IDs 1, ..., N that respectively identify LTM configurations 1, ..., N (generated by T-DU 174B) and includes IDs 1, ..., N in a DU-to-CU message of process 490, similar to event 310. In some implementations, CU 172 assigns IDs N+1, ..., N+M that respectively identify LTM configurations N+1, ..., N+M, and performs a process (similar to process 492) with T-DU 174B to provide IDs N+1, ..., N+M and / or cell IDs N+1, ..., N+M to T-DU 174B, similar to process 392. Thus, T-DU 174B associates IDs N+1, ..., N+M with LTM configurations N+1, ..., N+M and / or cell IDs N+1, ..., N+M, respectively. In other implementations, T-DU 174B assigns IDs N+1, ..., N+M that respectively identify LTM configurations N+1, ..., N+M, and includes IDs 1, ..., N in a DU-to-CU message that appends an LTM preparation process, similar to event 310.

[0171] In some implementations, the CU 172 sends 412 a CU-to-DU message including IDs 1, ..., N to the S-DU 174A and, in response, receives 414 a DU-to-CU message from the S-DU 174A. The CU-to-DU message 412 and the DU-to-CU message 414 are transmitted in a sequential manner. Figure 4 , N and / or cell IDs 1, ..., N in the CU-to-DU message 412. In some implementations, the CU 172 includes the LTM configurations 1, ..., N and / or cell IDs 1, ..., N in the CU-to-DU message 412. In some implementations, the CU 172 includes the IDs 1, ..., N in the CU-to-DU message 412. In other implementations, the CU 172 includes the cell indexes 1, ..., N in the CU-to-DU message 412. In some alternative implementations, the CU 172 performs multiple LTM ID transfer procedures to send the IDs 1, ..., N; the cell IDs 1, ..., N; and / or the LTM configurations 1, ..., N to the S-DU 174A. In each of the described procedures, the CU 172 includes the following specific parts in a CU-to-DU message similar to message 412: IDs 1, ..., N; cell IDs 1, ..., N; and / or LTM configurations 1, ..., N. Thus, the S-DU 174A associates IDs 1, ..., N with LTM configurations 1, ..., N and / or cell IDs 1, ..., N, respectively. In other alternative implementations, the CU 172 performs multiple LTM cell index transfer procedures to send cell indexes 1, ..., N; cell IDs 1, ..., N; and / or LTM configurations 1, ..., N to the S-DU 174A. In each of the described procedures, the CU 172 includes the following specific parts in a CU-to-DU message similar to message 412: cell indexes 1, ..., N; cell IDs 1, ..., N; and / or LTM configurations 1, ..., N. Thus, the S-DU 174A associates cell indices 1, ..., N with LTM configurations 1, ..., N and / or cell IDs 1, ..., N, respectively.

[0172] In some implementations, the CU 172 sends a CU-to-DU message including IDs N+1, ..., N+M to the S-DU 174A and, in response, receives a DU-to-CU message from the S-DU 174A, similar to the CU-to-DU message 412 and the DU-to-CU message 414, respectively. In some implementations, the CU 172 includes the LTM configurations N+1, ..., N+M and / or the cell IDs N+1, ..., N+M in the CU-to-DU message. In some alternative implementations, the CU 172 performs multiple LTM ID transfer procedures to send the IDs N+1, ..., N+M; the cell IDs N+1, ..., N+M; and / or the LTM configurations N+1, ..., N+M to the S-DU 174A. In each of the processes, the CU 172 includes the following specific parts in a CU-to-DU message similar to message 412: IDs N+1, ..., N+M; cell IDs N+1, ..., N+M; and / or LTM configurations 1, ..., N. Thus, the S-DU 174A associates the IDs N+1, ..., N+M with the LTM configurations N+1, ..., N+M and / or cell IDs N+1, ..., N+M, respectively.

[0173] In some implementations, when the CU 172 and S-DU 174A perform process 380 with the UE 102, the values ​​of IDs 1, ..., N of process 380 differ from the values ​​of IDs 1, ..., N and IDs N+1, ..., N+M described for scenario 400. In some implementations, when the CU 172 and S-DU 174A perform process 380 with the UE 102, the values ​​of cell IDs 1, ..., N of process 380 differ from the values ​​of cell IDs 1, ..., N and cell IDs N+1, ..., N+M described for scenario 400. In some implementations, when the CU 172 and S-DU 174A perform process 380 with the UE 102, the values ​​of cell indexes 1, ..., N of process 380 differ from the values ​​of cell indexes 1, ..., N and cell indexes N+1, ..., N+M described for scenario 400.

[0174] In some implementations, at a later time, UE 102 sends 424 at least one measurement report to S-DU 174A, similar to event 324. The at least one measurement report (e.g., an L1 measurement report) includes the event ID, a first measurement result for cell 1 of T-DU 174B, and / or a second measurement result for cell 124A. In some implementations, the first measurement result is or includes RSRP, RSRQ, and / or SINR obtained by UE 102 from a reference signal transmitted on cell 1. Similarly, in other implementations, the second measurement result is or includes RSRP, RSRQ, and / or SINR obtained by UE 102 from a reference signal transmitted on cell 124A. In some implementations, the event ID, RSRP, RSRQ, and / or SINR are L1-EventID, L1-RSRP, L1-RSRQ, and / or L1-SINR, respectively. In some implementations, based on the first measurement result and / or the second measurement result, S-DU 174A sends 430 a first LTM command (i.e., LTM command 1) to UE 102, instructing UE 102 to perform a serving cell change to cell 1 of T-DU 174B. In some implementations, the first LTM command includes an ID of 1. In other implementations, the first LTM command includes a cell index of 1. When UE 102 receives the first LTM command, UE 102 performs a serving cell change from the serving cell to cell 1 according to LTM configuration 1. In some implementations, if a serving cell change occurs in process 380, the serving cell is cell 1 or cell 2 of S-DU 174A. Otherwise, if no serving cell change occurs in process 380 or process 380 is not performed, the serving cell is cell 124A. If the first LTM command includes ID 1, UE 102 identifies LTM configuration 1 and / or cell ID 1 (i.e., cell 1) based on ID 1, as described for Figure 3 If the first LTM command includes cell index 1, UE 102 identifies LTM configuration 1, cell ID 1 (i.e., cell 1), and / or LTM ID 1 based on cell index 1, as described for Figure 3 After receiving the first LTM command or successfully accessing cell 1 (eg, in response to receiving the first LTM command or successfully accessing cell 1), UE 102 applies LTM configuration 1 to communicate with T-DU 174B.

[0175] In some implementations, after receiving the first LTM command (e.g., in response to receiving the first LTM command), the UE 102 performs or does not perform 432 a random access procedure with the T-DU 174B, similar to event 332. In other implementations, after receiving the first LTM command or completing the random access procedure 432 (e.g., in response to receiving the first LTM command or completing the random access procedure 432), the UE 102 communicates 436 with the T-DU 174B on the first cell using LTM configuration 1 and / or the reference LTM configuration, and communicates with the CU 172 via the T-DU 174B, similar to event 336.

[0176] In some implementations, the resource release process 496 is similar to the process 396. Instead, in the resource release process 496, the CU 172 sends a CU-to-DU message (e.g., a UE CONTEXT RELEASE COMMAND message) to the S-DU 174A to release the UE context of the UE 102. In response, the S-DU 174A releases the UE context of the UE 102 and sends 440 a DU-to-CU message (e.g., a UE CONTEXT RELEASE COMPLETE message) to the CU 172.

[0177] Events 380, 404, 406, 490, 492, 494, 494, 424, 426, 428, 429, 430, 431, 432, 434, 436, 496, 498, 456 Figure 4 is collectively referred to as the LTM configuration and / or activation process 480.

[0178] Next reference Figure 5A In scenario 500A, base station 106 operates as a MN and base station 104 operates as a SN. SN 104 includes CU 172 and DU 174. Scenario 500A is similar to scenario 300, except that scenario 500A is a DC scenario and scenario 300 is a single connection (SC) scenario. MN 106 may include a CU and a DU, and Figure 3 The base station 104 is similar.

[0179] Initially, UE 102 communicates with MN 106 and SN 104 in DC. At event 502, UE 102 communicates with DU 174 on cell 124A using the serving DU configuration and communicates with CU 172 via DU 174 using the serving CU configuration, similar to event 302. In some alternative implementations, UE 102 does not communicate with CU 172 via DU 174 in event 302. In some implementations, UE 102 communicates 502 UL PDUs and / or DL ​​PDUs with MN 106 and / or SN 104 in DC via radio bearers, which may include SRBs and / or DRBs, depending on the implementation. In some implementations, MN 106 and / or SN 104 configure the radio bearers to UE 102. UE 102 communicates 502 UL PDUs and / or DL ​​PDUs with SN 104 in DC on an SCG (i.e., SCG radio resources) that SN 104 configures for communication with UE 102. UE 102 communicates UL PDUs and / or DL ​​PDUs with MN 106 in DC on an MCG (i.e., MCG radio resources) according to an MN configuration (i.e., MCG configuration). In some implementations, the service DU configuration is an SN configuration (i.e., SCG configuration). In the MN configuration, MN 106 configures an MCG that includes at least one service cell operated by MN 106 (e.g., cell 126 and / or other cells). In the service DU configuration, SN 106A configures an SCG that includes at least one service cell operated by SN 104 (e.g., cell 124A and / or other cells). In some implementations, the MN configuration includes multiple configuration parameters, and UE 102 receives the configuration parameters from MN 106 in one or more RRC messages. As described for Figure 3 As described, the service DU configuration includes a plurality of configuration parameters. In some implementations, UE 102 receives the configuration parameters from SN 104 in one or more RRC messages (e.g., via MN 106 and / or over an SRB (e.g., SRB3) configured by MN 106 or SN 104 to exchange RRC messages between UE 102 and SN 104).

[0180] In some implementations, while UE 102 is communicating in DC with MN 106 and SN 104, MN 106 performs 580 an LTM configuration and / or activation procedure with UE 102, similar to procedures 380 and / or 480. In some implementations, while communicating in DC with MN 106 and SN 104, UE 102 sends at least one measurement report to CU 172 via DU 174 and cell 124A in events 504 and 506, respectively, similar to events 304 and 306. In other implementations, while communicating in DC with MN 106 and SN 104, UE 102 sends 505 at least one measurement report to MN 106 via cell 126. MN 106, in turn, sends 507 at least one measurement report to CU 172. In some implementations, the MN 106 generates at least one SN message including at least one measurement report and sends the at least one SN message to the CU 172 in event 507. In some implementations, the at least one SN message includes an RRC transfer message and / or an SN modification request message.

[0181] After receiving at least one measurement report (e.g., in response to receiving at least one measurement report) or while SN 104 is communicating with UE 102, SN 104 determines to prepare a first cell for UE 102, such as for Figure 3 Events 590, 592, 594, 524, 526, 528, 529, 530, 531, 532, 534, 536, 596, 598, and 556 are similar to events 390, 392, 394, 324, 326, 328, 329, 330, 331, 332, 334, 336, 396, 398, and 356, respectively. After receiving the first LTM command 530, sending the confirmation 531, or determining that the UE 102 is successfully connected to the first cell 532 or 536, the UE 102 operating in DC with the MN 106 and the SN 104 communicates 536 with the DU 174 on the first cell according to LTM configuration 1 and communicates 536 with the CU 172 via the DU 174, similar to event 336. In some implementations, at a later time, the DU 174 and / or the CU 172 performs an 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 or 498. As a result of the procedure 598, the UE 102, operating in DC with the MN 106 and the SN 104, communicates 556 with the DU 174 on the second cell according to LTM configuration 2 and communicates 556 with the CU 172 via the DU 174, similar to event 356.

[0182] Events 504, 506, 505, 507, 590, 592, 594, 594, 524, 526, 528, 529, 530, 531, 532, 534, 536, 596, 598, 556 Figure 5A is collectively referred to as the LTM configuration and / or activation process 581.

[0183] Next reference Figure 5B Scenario 500B is generally similar to scenario 500A, except that SN 104 sends 517, 519 an RRC reconfiguration message to UE 102 via MN 106 and receives 521, 523 an RRC reconfiguration complete message from UE 102 via MN 106. RRC reconfiguration messages 517, 519 are similar to RRC reconfiguration messages 316, 318. RRC reconfiguration complete messages 521, 523 are similar to RRC reconfiguration messages 320, 322. In some implementations, SN 104 generates a first SN message (e.g., an SN modification required message, an SN modification required message, or an RRC transfer message) including the RRC reconfiguration message and sends the first SN message to MN 106 in event 517. MN 106 generates an MN RRC message including the RRC reconfiguration message and sends 519 the MN RRC message to UE 102. In response, UE 102 generates an MN RRC Response message including an RRC Reconfiguration Complete message and sends 521 the MN RRC Response message to MN 106. In some implementations, MN 106 generates a second SN message (e.g., an SN Reconfiguration Complete message or an RRC Transfer message) including the RRC Reconfiguration Complete message and sends the second SN message to SN 104 at event 523. In some implementations, the MN RRC message and the MN RRC Response message are an RRC Reconfiguration message and an RRC Reconfiguration Complete message, respectively.

[0184] Events 504, 506, 505, 507, 590, 592, 594, 517, 519, 521, 523, 524, 526, 528, 529, 530, 531, 532, 534, 536, 596, 598, 556 Figure 5B is collectively referred to as the LTM configuration and / or activation process 582.

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

[0186] Next reference Figure 6B , scenario 600B is similar to scenarios 300 to 500B and 600A, except that SN 104 sends 617 , 619 an RRC reconfiguration message to UE 102 via MN 106 and receives 621 , 623 an RRC reconfiguration complete message from UE 102 via MN 106 .

[0187] Next reference Figure 7A In scenario 700A, the base station 104 operates as a MN and a SN, similar to scenarios 300 to 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 and the M-DU 174A operate together as a MN, and Figure 3 Base station 104 or Figures 5A to 6B 106 in the same manner as the MN 106 in FIG, and the CU 172 and S-DU 174B operate together as SNs, with Figures 5A to 6B Similar to SN 104 in.

[0188] In scenario 700A, UE 102 initially communicates 702 with M-DU 174A and S-DU 174B in DC and communicates 702 with CU 172 via M-DU 174A and S-DU 174B. At event 702, UE 102 communicates with S-DU 174B on cell 124A using the serving DU configuration and communicates with CU 172 via S-DU 174B using the serving CU configuration, similar to event 302. Events 704 and 706 are similar to events 304 and 306. In some implementations, UE 102 sends 705 at least one measurement report to M-DU 174A, similar to event 304. M-DU 174A then sends 707 at least one DU-to-CU message including the at least one measurement report to CU 172, similar to event 306. In some implementations, while UE 102 is communicating in DC with M-DU 174A and S-DU 174B, CU 172 performs 780 an LTM configuration and / or activation procedure with UE 102 via M-DU 174A, similar to procedure 380 .

[0189] Events 704, 706, 705, 707, 790, 792, 794, 724, 726, 728, 729, 730, 731, 732, 734, 736, 796, 798, 756 Figure 7A are collectively referred to as the LTM configuration and / or activation process 781.

[0190] Next reference Figure 7B , scenario 700B is similar to scenarios 300 to 600B and 700A, except that CU 172 sends 717, 719 an RRC reconfiguration message to UE 102 via M-DU 174A and receives 721, 723 an RRC reconfiguration complete message from UE 102 via M-DU 174A.

[0191] Events 704, 706, 705, 707, 790, 792, 794, 717, 719, 721, 723, 724, 726, 728, 729, 730, 731, 732, 734, 736, 796, 798, 756 Figure 7B is collectively referred to as the LTM DU configuration and / or activation process 782.

[0192] Next reference Figure 8AIn scenario 800A, base station 104 operates as both a mobile node and a network node, similar to scenarios 300 through 700B. Base station 104 includes a control unit (CU) 172, a master DU (M-DU) 174A, a secondary DU (S-DU) 174B, and a target secondary DU (T-DU) 174C. CU 172 operates as a mobile node with M-DU 174A and as a network node with S-DU 174B. In some implementations, when UE 102 communicates with M-DU 174A and S-DU 174B in DC mode, CU 172 performs 880 an LTM configuration and / or activation procedure with UE 102 via M-DU 174A, similar to procedure 380. In some implementations, while UE 102 is communicating with M-DU 174A and S-DU 174B in DC, CU 172 performs 881 an LTM configuration and / or activation procedure with UE 102 via S-DU 174A, similar to procedure 581 or 582 .

[0193] Next reference Figure 8B , scenario 800B is similar to scenarios 300 to 700B and 800A, except that CU 172 sends 817, 819 an RRC reconfiguration message to UE 102 via M-DU 174A and receives 821, 823 an RRC reconfiguration complete message from UE 102 via M-DU 174A.

[0194] Next, refer to 9A to 14B Several example methods that can be implemented in a RAN (such as a DU or CU) to support configuration for LTM are discussed. Figures 3 to 8B The examples and implementations described can be applied to 9A to 14B .

[0195] Figure 9A An example method 900A is shown that may be implemented by a RAN (eg, base station 104 or 106, DU 174 of base station 104 or 106, or DU 174A, DU 174B, and / or DU 174C of base station 104) for configuring LTM to a UE (eg, UE 102).

[0196] Method 900A begins at block 902, where the DU receives a CU-to-DU message from the CU requesting that a first cell be prepared for LTM for the UE (e.g., events 308, 390, 380, 490, 480, 580, 590, 581, 582, 680, 690, 681, 682, 780, 790, 781, 782, 880, 890, 881, 882). At block 904A, the DU determines whether the first cell is synchronized with the UE's serving cell. If, at block 904A, the DU determines that the first cell is synchronized with the UE's serving cell, the flow proceeds to block 906. At block 906, the DU generates an LTM configuration that configures the first cell and the UE to not perform a random access procedure after receiving an LTM command instructing the UE to perform a serving cell change to the first cell (e.g., events 310, 390, 380, 490, 480, 580, 590, 581, 582, 680, 690, 681, 682, 780, 790, 781, 782, 880, 890, 881, 882). Otherwise, if at block 904A the DU determines that the first cell is not synchronized with the UE's serving cell, the flow proceeds to block 908. At block 908, the DU generates an LTM configuration that configures the UE to perform a random access procedure upon receiving an LTM command instructing the UE to perform a serving cell change to the first cell (e.g., events 310, 390, 380, 490, 480, 580, 590, 581, 582, 680, 690, 681, 682, 780, 790, 781, 782, 880, 890, 881, 882). Flow proceeds from 906 or 908 to block 910. At block 910 , the DU sends a DU-to-CU message including an LTM configuration to the CU (e.g., events 310 , 390 , 380 , 490 , 480 , 580 , 590 , 581 , 582 , 680 , 690 , 681 , 682 , 780 , 790 , 781 , 782 , 880 , 890 , 881 , 882 ).

[0197] In some implementations, the DU is a serving DU, which is either a primary DU or a secondary DU, depending on the implementation. In other implementations, the DU is a non-serving DU (i.e., a target DU). In some implementations, the first cell is a candidate PCell or a candidate PSCell. In some implementations, the LTM configuration is a non-reference LTM configuration for the LTM configuration of the first cell, as described for example for Figures 3 to 8B In some implementations, at block 910, the DU includes the reference LTM configuration in the DU to CU message. Alternatively, the DU sends another DU to CU message including the reference LTM configuration to the CU. In other implementations, the LTM configuration is the same as the one for the cell. Figures 3 to 8B In some implementations, the serving DU later sends an LTM command to the UE to instruct the UE to perform a serving cell change to the first cell (e.g., events 330, 380, 480, 430, 580, 530, 581, 582, 680, 630, 681, 682, 780, 730, 781, 782, 880, 830, 881, 882). In some cases where the DU is the serving DU, the serving DU stops communicating with the UE via the serving cell after sending the LTM command. After detecting that the UE accesses the first cell, the DU applies the non-reference LTM configuration and at least a portion of the reference LTM configuration to communicate with the UE via the first cell (e.g., events 336, 380, 580, 536, 581, 582, 780, 736, 781, 782).

[0198] In some implementations, the LTM configuration in block 906 is the LTM configuration in block 1104 or 1105 (e.g., as described below). In some implementations, the LTM configuration in block 906 includes random access configuration parameters. In other implementations, the LTM configuration in block 906 does not include random access configuration parameters. In some implementations, the LTM configuration in block 908 includes random access configuration parameters.

[0199] Figure 9B 900B is a flow chart of an example method 900B similar to method 900A, except that method 900B includes block 904B instead of block 904A. At block 904B, the DU determines whether the DU is the serving DU of the UE. If, at block 904B, the DU determines that the DU is the serving DU of the UE, the flow proceeds to block 906. Otherwise, if, at block 904B, the DU determines that the DU is not the serving DU of the UE, the flow proceeds to block 908.

[0200] Figure 9C FIG2 is a flow chart of an example method 900C similar to method 900A, except that method 900C includes block 904C instead of block 904A. At block 904C, the DU determines whether the CU-to-DU message is a UE context establishment request or a UE context modification request message. If, at block 904C, the DU determines that the CU-to-DU message is a UE context modification request message, the flow proceeds to block 906. Otherwise, if, at block 904C, the DU determines that the CU-to-DU message is a UE context establishment request, the flow proceeds to block 908.

[0201] Figure 9D900D is a flow chart of an example method 900D similar to method 900A, except that method 900D includes block 904D instead of block 904A. At block 904D, the DU determines whether the UE supports RACH-less LTM. If, at block 904D, the DU determines that the UE supports RACH-less LTM, the flow proceeds to block 906. Otherwise, if, at block 904D, the DU determines that the UE does not support RACH-less LTM, the flow proceeds to block 908.

[0202] If the UE supports RACH-free LTM, the UE supports performing a serving cell change without performing a random access procedure after receiving an LTM command. In some implementations, the DU receives the UE capabilities (e.g., UE-NR-Capability or UE-6G-Capability IE) of the UE from the CU. If the UE capabilities include LTM capabilities indicating that the UE supports RACH-free LTM, the DU determines that the UE supports RACH-free LTM. Otherwise, if the UE capabilities do not include LTM capabilities, the DU determines that the UE does not support RACH-free LTM. In some implementations, the UE capabilities include LTM capabilities indicating that the UE supports LTM.

[0203] Figure 9E 9 is a flow chart of an example method 900E similar to method 900A, except that method 900E includes block 904E instead of block 904A. At block 904E, the DU determines whether the UE supports deriving uplink transmission timing based on reference signals. If, at block 904E, the DU determines that the UE supports deriving uplink transmission timing based on reference signals, the flow proceeds to block 906. Otherwise, if, at block 904E, the DU determines that the UE does not support deriving uplink transmission timing based on reference signals, the flow proceeds to block 908.

[0204] In some implementations, if the UE supports deriving uplink transmission timing based on a reference signal, the UE supports performing a serving cell change without performing a random access procedure after receiving an LTM command. In some implementations, the DU transmits a reference signal on a first cell for the UE to derive uplink transmission timing for uplink transmission on the first cell. Upon receiving the reference signal, the UE determines the DL timing difference between the first cell and the serving cell, and derives the uplink transmission timing (e.g., timing advance value) for uplink transmission on the first cell based on the DL timing difference and the uplink transmission timing (e.g., timing advance value) for uplink transmission on the serving cell. In some implementations, the DU sends a DU configuration (e.g., CellGroupConfig IE) including configuration parameters for configuring reference signals or reception of reference signals to the UE directly or via the CU. For example, in the case of transmitting the DU configuration via the CU, the DU sends the DU configuration to the CU, and the CU sends a message (e.g., RRC reconfiguration message) including the DU configuration to the UE via the DU or another RAN node (e.g., another DU or base station). In some implementations, the UE starts receiving reference signals upon or after receiving the configuration parameters. In other implementations, the UE does not start receiving reference signals upon or after receiving the configuration parameters. In such cases, the DU or another DU sends a non-LTM command to the UE to instruct the UE to receive reference signals. In some implementations, the non-LTM command is a reference signal (reception) activation command for activating reception of reference signals. After receiving the non-LTM command (e.g., in response to receiving the non-LTM command), the UE starts receiving reference signals. In some implementations, if the DU determines that the UE supports deriving uplink transmission timing based on reference signals, the DU sends the DU configuration to the UE. Otherwise, if the DU determines that the UE does not support deriving uplink transmission timing based on reference signals, the DU avoids sending the DU configuration to the UE.

[0205] In some implementations, the DU receives the UE capabilities (e.g., UE-NR-Capability or UE-6G-Capability IE) of the UE from the CU. If the UE capabilities include LTM capabilities indicating that the UE supports deriving uplink transmission timing based on reference signals, the DU determines that the UE supports deriving uplink transmission timing based on reference signals. Otherwise, if the UE capabilities do not include LTM capabilities, the DU determines that the UE does not support deriving uplink transmission timing based on reference signals. In some implementations, the UE capabilities include LTM capabilities indicating that the UE supports LTM.

[0206] In some implementations, the reference signal includes a tracking reference signal (TRS), a channel state information reference signal (CSI-RS), and / or a synchronization signal and / or a physical broadcast channel block (SSB).

[0207] Figure 9F FIG1 is a flow chart of an example method 900F similar to method 900A, except that method 900F includes block 904F instead of block 904A. At block 904F, the DU determines whether the CU-to-DU message requests that the UE be configured to perform a random access procedure after receiving an LTM command instructing the UE to perform a serving cell change to the first cell. If, at block 904F, the DU determines that the CU-to-DU message requests that the UE be configured to perform a random access procedure after receiving an LTM command instructing the UE to perform a serving cell change to the first cell, the flow proceeds to block 906. Otherwise, if, at block 904F, the DU determines that the CU-to-DU message does not request that the UE be configured to perform a random access procedure after receiving an LTM command instructing the UE to perform a serving cell change to the first cell, the flow proceeds to block 908.

[0208] Figure 10 An example method 1000 is shown that a CU (eg, CU 172 of base station 104 or 106) may implement for configuring LTM for a UE (eg, UE 102).

[0209] Method 1000 begins at block 1002, where the CU determines to prepare a first cell for LTM for the UE. At block 1004, the CU determines whether the UE supports RACH-less LTM. If the CU determines that the UE does not support RACH-less LTM, the process proceeds to block 1006. At block 1006, the CU generates a CU-to-DU message requesting the DU to configure the UE to perform a random access procedure after receiving an LTM command instructing the UE to perform a serving cell change to the first cell. Otherwise, if the CU determines that the UE supports RACH-less LTM, the process proceeds to block 1008. At block 1008, the CU generates a CU-to-DU message requesting the DU to configure the UE not to perform a random access procedure after receiving an LTM command instructing the UE to perform a serving cell change to the first cell. The process proceeds from 1006 or 1008 to block 1010. At block 1010 , the CU sends a CU-to-DU message to the DU operating the first cell (e.g., events 308 , 390 , 380 , 490 , 480 , 580 , 590 , 581 , 582 , 680 , 690 , 681 , 682 , 780 , 790 , 781 , 782 , 880 , 890 , 881 , 882 ).

[0210] In some implementations, the CU receives a DU-to-CU message (e.g., events 310, 390, 380, 490, 480, 580, 590, 581, 582, 680, 690, 681, 682, 780, 790, 781, 782, 880, 890, 881, 882) from the DU in response to the CU-to-DU message. If the CU-to-DU message requests the DU not to configure the UE to perform a random access procedure after receiving the LTM command instructing the UE to perform a serving cell change to the first cell, the LTM configuration configures the UE not to perform a random access procedure after receiving the instruction for the UE to perform a serving cell change to the first cell. If the CU-to-DU message requests the DU to configure the UE to perform a random access procedure after receiving the LTM command instructing the UE to perform a serving cell change to the first cell, the LTM configuration configures the UE to perform a random access procedure after receiving the instruction for the UE to perform a serving cell change to the first cell.

[0211] In some implementations, the CU receives the UE capabilities (e.g., UE-NR-Capability or UE-6G-Capability IE) of the UE from the UE or a core network node (e.g., AMF). If the UE capabilities include LTM capabilities indicating that the UE supports RACH-free LTM, the CU determines that the UE supports RACH-free LTM. Otherwise, if the UE capabilities do not include LTM capabilities, the CU determines that the UE does not support RACH-free LTM. In some implementations, the UE capabilities include LTM capabilities indicating that the UE supports LTM.

[0212] Figure 11A An example method 1100A is shown that a RAN (eg, a RAN node such as base station 104 or 106, DU 174 of base station 104 or 106, or RAN 105) may implement for configuring and triggering LTM to a UE (eg, UE 102).

[0213] Method 1100A begins at block 1102, where the RAN prepares a first cell for the UE for LTM (e.g., events 308, 310, 390, 380, 490, 480, 580, 590, 581, 582, 680, 690, 681, 682, 780, 790, 781, 782, 880, 890, 881, 882). At box 1104, the RAN generates an LTM configuration that does not include a reconfiguration field with synchronization and includes at least one serving cell configuration and / or UE ID for accessing the first cell to configure the UE to not perform a random access procedure after receiving an LTM command instructing the UE to perform a serving cell change to the first cell (e.g., events 310, 390, 380, 490, 480, 580, 590, 581, 582, 680, 690, 681, 682, 780, 790, 781, 782, 880, 890, 881, 882). At block 1106, the RAN sends an LTM configuration to the UE (e.g., events 316, 318, 394, 380, 480, 494, 580, 594, 581, 517, 519, 582, 680, 694, 681, 617, 619, 682, 780, 794, 781, 717, 719, 782, 880, 894, 881, 817, 819, 882). At block 1108, the RAN sends an LTM command to the UE instructing the UE to access the first cell (e.g., events 330, 380, 480, 430, 580, 530, 581, 582, 680, 630, 681, 682, 780, 730, 781, 782, 880, 830, 881, 882). At block 1110 , the RAN communicates with the UE via the first cell according to the LTM configuration (e.g., events 336 , 380 , 436 , 480 , 580 , 536 , 581 , 582 , 680 , 636 , 681 , 682 , 780 , 736 , 781 , 782 , 880 , 836 , 881 , 882 ).

[0214] In some implementations, the first cell is a candidate PCell or PSCell. In some implementations, the RAN detects that the UE accesses the first cell according to the LTM configuration (e.g., after sending an LTM command) (e.g., events 332, 380, 432, 480, 580, 532, 581, 582, 680, 636, 681, 682, 780, 736, 781, 782, 880, 836, 881, 882).

[0215] Figure 11Bis a flow chart of an example method 1100B that is similar to method 1100A, except that method 1100B includes block 1105 instead of block 1104. At block 1105, the RAN generates an LTM configuration including a reconfiguration field with synchronization, wherein the LTM configuration includes an indication to configure the UE to not perform a random access procedure after receiving an LTM command instructing the UE to perform a serving cell change to a first cell.

[0216] In some implementations, the RAN includes the indication in a reconfiguration with synchronization field to include the indication in the LTM configuration. In other implementations, the RAN includes the indication in a field other than the reconfiguration with synchronization field and includes the field in the LTM configuration.

[0217] Figure 12A An example method 1200A is shown that a RAN node (eg, base station 104 or 106, or DU 174 of base station 104 or 106) may implement for configuring and triggering LTM to a UE (eg, UE 102).

[0218] Method 1200A begins at block 1202, where a RAN node communicates with a UE via a serving cell (e.g., events 302, 402, 502, 602, 702, 802). At block 1204, the RAN node sends an LTM configuration to the UE configuring a first cell (e.g., events 316, 318, 394, 380, 480, 494, 580, 594, 581, 517, 519, 582, 680, 694, 681, 617, 619, 682, 780, 794, 781, 717, 719, 782, 880, 894, 881, 817, 819, 882). At block 1206, the RAN node determines that the UE is instructed to perform a serving cell change to the first cell. At block 1208A, the RAN node determines whether the first cell is synchronized with the UE's serving cell. If, at block 1208A, the RAN node determines that the first cell is synchronized with the UE's serving cell, the flow proceeds to block 1210. At block 1210, the RAN node sends an LTM command to the UE, instructing the UE to perform a serving cell change to the first cell and not to perform a random access procedure (e.g., 330, 380, 480, 430, 580, 530, 581, 582, 680, 630, 681, 682, 780, 730, 781, 782, 880, 830, 881, 882). Otherwise, if, at block 1208A, the RAN node determines that the first cell is not synchronized with the UE's serving cell, the flow proceeds to block 1212. At block 1212, the RAN node sends an LTM command to the UE, instructing the UE to perform a serving cell change to the first cell and to perform a random access procedure (e.g., 330, 380, 480, 430, 580, 530, 581, 582, 680, 630, 681, 682, 780, 730, 781, 782, 880, 830, 881, 882).

[0219] In some implementations, after sending the LTM command, the RAN node stops communicating with the UE via the serving cell. If the RAN node operates the first cell, then upon or after (i) sending the LTM command or (ii) detecting that the UE accesses the first cell, the RAN node applies the LTM configuration to communicate with the UE via the first cell (e.g., events 336, 380, 436, 480, 580, 536, 581, 582, 680, 636, 681, 682, 780, 736, 781, 782, 880, 836, 881, 882).

[0220] In some implementations, the first cell is a candidate PCell or a candidate PSCell. In some implementations, the LTM configuration is as described for Figures 3 to 8BThe non-reference LTM configuration described is similar to the LTM configuration 1 for configuring cell 1. In some implementations, the RAN node sends a reference LTM configuration to the UE (e.g., events 316, 318, 394, 380, 480, 494, 580, 594, 581, 517, 519, 582, 680, 694, 681, 617, 619, 682, 780, 794, 781, 717, 719, 782, 880, 894, 881, 817, 819, 882). If the RAN node operates the first cell, then after sending the LTM command or detecting that the UE accesses the first cell, the RAN node applies the non-reference LTM configuration and at least a portion of the reference LTM configuration to communicate with the RAN via the first cell (e.g., events 336, 380, 436, 480, 580, 536, 581, 582, 680, 636, 681, 682, 780, 736, 781, 782, 880, 836, 881, 882).

[0221] Figure 12B FIG1 is a flow chart of an example method 1200B that is similar to method 1200A, except that method 1200B includes block 1208B instead of block 1208A. At block 1208B, the RAN node determines whether the first cell and the serving cell are operated by the same RAN node (e.g., DU). If, at block 1208B, the RAN determines that the first cell and the serving cell are operated by the same RAN node, the flow proceeds to block 1210. Otherwise, if, at block 1208B, the RAN determines that the first cell and the serving cell are operated by different RAN nodes, the flow proceeds to block 1212.

[0222] Figure 12C FIG1 is a flow chart of an example method 1200C similar to method 1200A, except that method 1200C includes block 1208C instead of block 1208A. At block 1208C, the RAN node determines whether the UE supports RACH-less LTM. If, at block 1208C, the RAN node determines that the UE supports RACH-less LTM, the flow proceeds to block 1210. Otherwise, if, at block 1208C, the RAN node determines that the UE does not support RACH-less LTM, the flow proceeds to block 1212.

[0223] against Figure 9D The examples and implementations described can be applied to Figure 12C .

[0224] Figure 12D12 is a flow chart of an example method 1200D similar to method 1200A, except that method 1200D includes block 1208D instead of block 1208A. At block 1208D, the RAN node determines whether the UE supports deriving uplink transmission timing based on reference signals. If, at block 1208D, the RAN node determines that the UE supports deriving uplink transmission timing based on reference signals, the flow proceeds to block 1210. Otherwise, if, at block 1208D, the RAN node determines that the UE does not support deriving uplink transmission timing based on reference signals, the flow proceeds to block 1212.

[0225] Figure 12E 12 is a flow chart of an example method 1200E similar to method 1200A, except that method 1200E includes block 1208E instead of block 1208A. At block 1208E, the RAN node determines whether the UE is configured with a reference signal for deriving uplink transmission timing. If, at block 1208E, the RAN node determines that the UE is configured with a reference signal for deriving uplink transmission timing, the flow proceeds to block 1210. Otherwise, if, at block 1208E, the RAN node determines that the UE is not configured with a reference signal for deriving uplink transmission timing, the flow proceeds to block 1212.

[0226] Figure 12F 12 is a flow chart of an example method 1200F similar to method 1200A, except that method 1200F includes block 1208F instead of block 1208A. At block 1208F, the RAN node determines whether the UE has activated reception of reference signals used to derive uplink transmission timing. If, at block 1208F, the RAN node determines that the UE has activated reception of reference signals used to derive uplink transmission timing, the flow proceeds to block 1210. Otherwise, if, at block 1208F, the RAN node determines that the UE has not activated reception of reference signals used to derive uplink transmission timing, the flow proceeds to block 1212.

[0227] against Figure 9E The examples and implementations described can be applied to 12D to 12F .

[0228] Figure 13A An example method 1300A is shown that a RAN node (eg, DU 174 of base station 104 or 106, or base station 104 or 106) may implement for configuring and triggering LTM to a UE (eg, UE 102).

[0229] Method 1300A begins at block 1302, where a RAN node communicates with a UE via a serving cell (e.g., events 302, 402, 502, 602, 702, 802). At block 1304, the RAN node sends an LTM configuration to the UE configuring a first cell (e.g., events 310, 390, 316, 318, 394, 380, 490, 494, 480, 580, 590, 594, 581, 517, 519, 582, 680, 690, 694, 681, 617, 619, 682, 780, 790, 794, 781, 717, 719, 782, 880, 890, 894, 881, 817, 819, 882). At block 1306, the RAN node sends one or more non-LTM configurations to the UE that configure reference signals for deriving uplink transmission timing. At block 1308, the RAN node sends a non-LTM command to the UE, instructing the UE to receive the reference signals. At block 1310, the RAN node sends an LTM command to the UE, instructing the UE to perform a serving cell change to the first cell (e.g., 330, 380, 480, 430, 580, 530, 581, 582, 680, 630, 681, 682, 780, 730, 781, 782, 880, 830, 881, 882).

[0230] In some implementations, if the non-LTM configuration configures the UE to start receiving reference signals, block 1308 is omitted. Otherwise, the RAN node sends a non-LTM command, and the UE starts receiving reference signals in response to the non-LTM command. In some implementations, the non-LTM command is a Reference Signal (Receive) Activation command for activating reception of reference signals.

[0231] In some implementations, the RAN node sends a non-LTM command and an LTM command to the UE in a time slot (i.e., the same time slot). In other implementations, the UE sends the non-LTM command and the LTM command to the UE in a first time slot and a second time slot, respectively. In other implementations, the RAN sends a MAC PDU including the non-LTM command and the LTM command to the UE. In other implementations, the RAN node sends a first MAC PDU including the non-LTM command to the UE and sends a second MAC PDU including the LTM command to the UE. In some implementations, the LTM command is a first MAC CE and the non-LTM command is a second MAC CE. In such a case, the RAN node sends a MAC PDU including the first MAC CE, the first subheader of the first MAC CE, the second MAC CE, and the second subheader of the second MAC CE to the UE. Alternatively, the RAN node sends a first MAC PDU including the first MAC CE and the first subheader of the first MAC CE to the UE and sends a second MAC PDU including the second MAC CE and the second subheader of the second MAC CE to the UE.

[0232] Figure 13B is a flow chart of an example method 1300B that is similar to method 1300A, except that method 1300B includes block 1311 instead of blocks 1308 and 1310. At block 1311, the RAN node sends an LTM command to the UE, instructing the UE to perform a serving cell change to the first cell and receive a reference signal.

[0233] In some implementations, the LTM command is a MAC CE.At block 1311, the RAN node sends a MAC PDU including a MAC CE and a sub-header of the MAC CE to the UE.

[0234] Figure 13C 1300A, except that method 1300C includes block 1305. At block 1305, the RAN node determines whether the UE supports derivation of uplink transmission timing based on reference signals. If, at block 1305, the RAN node determines that the UE supports derivation of uplink transmission timing based on reference signals, the flow proceeds to block 1306. Otherwise, if, at block 1305, the RAN node determines that the UE does not support derivation of uplink transmission timing based on reference signals, the flow proceeds to block 1310. Flow proceeds from block 1305 and either block 1306 or block 1308 to block 1310.

[0235] Figure 13Dis a flow chart of an example method 1300D that is similar to methods 1300A through 1300C, except that method 1300D includes block 1311 instead of block 1308 .

[0236] against 9A to 9F and 12A to 12F The examples and implementations described can be applied to 13A to 13D .

[0237] The following description applies to 13A to 13D .

[0238] In some implementations, a RAN node (e.g., a first RAN node) or a second RAN node transmits a reference signal according to a non-LTM configuration. In some implementations, the RAN node transmits the reference signal before or when transmitting a non-LTM configuration, a non-LTM command, or an LTM command to the UE. When the UE receives the reference signal, the UE derives the second uplink transmission timing from the received RS. In some implementations, the UE performs AGC adjustment and / or time / frequency synchronization based on the received reference signal.

[0239] In some implementations, the reference signal (RS) includes a CSI-RS or a tracking reference signal for automatic gain control (AGC) adjustment and / or time / frequency synchronization with the SpCell. In some implementations, the CSI-RS is specifically configured or used for tracking (i.e., CSI-RS (TRS) for tracking). In other implementations, the CSI-RS is configured or used for tracking and other purposes (e.g., CSI reporting). In some implementations, a non-LTM configuration (e.g., CellGroupConfig IE) includes one or more RS configurations for one or more (candidate) special cells (SpCells). Each of the RS configurations configures the RS and includes an RS configuration ID and / or quasi-co-location (QCL) information of the RS (e.g., for serving cell changes (i.e., SpCell changes)). The RS configuration ID in each of the RS configurations uniquely identifies the corresponding RS configuration. In some implementations, each of the RS configurations includes a resource set ID (e.g., NZP-CSI-RS-ResourceSetId) used to configure the RS. The resource set ID indicates RS resources, such as a set of RS resources. The first RAN node, the second RAN node, or the CU of the first RAN node sends one or more resource set configurations (e.g., NZP-CSI-RS-ResourceSet IEs) to the UE, where each resource set configuration configures a set of RS resources (i.e., a resource set) and a resource set ID that identifies the set of RS resources. The resource set ID in each of the RS configurations indicates a specific set of RS resources used for automatic gain control (AGC) adjustment and / or time / frequency synchronization with the SpCell. In some implementations, the set of RS resources includes at least one non-zero power (NZP) RS resource (e.g., NZP CSI-RS resource) in at least one time slot. For example, the set of RS resources includes four non-zero power NZP CSI-RS resources in two consecutive time slots, with two NZP CSI-RS resources in each time slot. In some implementations, the RS associated with the set of RS resources is located in a bandwidth part (BWP) addressed by a BWP ID (e.g., firstActiveDownlinkBWP-Id). The first RAN node, the second RAN node or the CU sends a BWP configuration including configuring a BWP and a BWP ID to the UE.

[0240] In some implementations, QCL information (e.g., qcl-Info, qcl-Info-v1800, or qcl-Info-r18) references TCI-State to provide a QCL source and QCL type for each RS resource (e.g., NZP-CSI-RS-Resource) in a resource configuration (e.g., NZP-CSI-RS-Resources) in a resource set (e.g., NZP-CSI-RS-ResourceSet) indicated by a resource set ID. The QCL information includes a TCI state ID (e.g., TCI-StateId), which refers to a transmission control indicator (TCI) state configuration (e.g., TCI-State) identified by the TCI state ID. In some implementations, a first RAN node, a second RAN node, or a CU sends a TCI state configuration to a UE that configures the TCI state and includes the TCI state ID. In another implementation, the first RAN node, the second RAN node, or the CU sends a TCI state configuration list (e.g., tciStatesToAddModList) to the UE. Each of the TCI state configurations includes a TCI state ID.

[0241] exist Figure 13A and Figure 13C In some implementations, the non-LTM command includes an RS configuration ID to instruct the UE to start receiving the RS configured in the RS configuration identified by the RS configuration ID. When the UE receives the non-LTM command, in response to the non-LTM command, the UE identifies the RS configuration based on the RS configuration ID and starts receiving the RS in the RS configuration identified by the RS configuration ID. In some such cases, the non-LTM command is a TRS activation command. In some implementations, Figure 13B and Figure 13D The LTM command in the RS configuration includes the RS configuration ID to instruct the UE to start receiving the RS configured in the RS configuration identified by the RS configuration ID. When the UE receives the LTM command, in response to the LTM command, the UE identifies the RS configuration based on the RS configuration ID and starts receiving the RS in the RS configuration.

[0242] Figure 14A An example method 1400A is shown that a RAN node (e.g., base station 104 or 106, DU 174 of base station 104 or 106, or S-DU 174A, T-DU 174B, M-DU 174A, S-DU 174B, or T-DU 174C) can implement for configuring and triggering LTM to a UE (e.g., UE 102).

[0243] Method 1400A begins at block 1402, where the RAN node sends an LTM configuration to the UE configuring a first cell (e.g., events 316, 318, 394, 380, 480, 494, 580, 594, 581, 517, 519, 582, 680, 694, 681, 617, 619, 682, 780, 794, 781, 717, 719, 782, 880, 894, 881, 817, 819, 882). At block 1404, the RAN node sends an LTM command to the UE, the LTM command instructing the UE to perform a serving cell change to the first cell (e.g., 330, 380, 480, 430, 580, 530, 581, 582, 680, 630, 681, 682, 780, 730, 781, 782, 880, 830, 881, 882). At block 1406, the RAN node determines whether the RAN node has configured the UE to perform a random access procedure after receiving the LTM command instructing the UE not to perform a serving cell change to the first cell. If, at block 1406, the RAN node determines that the RAN node has configured the UE to perform a random access procedure after receiving the LTM command instructing the UE not to perform a serving cell change to the first cell, the flow proceeds to block 1408. At block 1408, the RAN node performs a random access procedure with the UE on the first cell. At block 1410, the RAN node detects that the UE accesses the first cell during the random access procedure. Otherwise, if, at block 1406, the RAN node determines that the RAN node configured the UE not to perform a random access procedure after receiving an LTM command instructing the UE not to perform a serving cell change to the first cell, the flow proceeds to block 1412. At block 1412, the RAN node attempts to receive a PUCCH transmission from the UE on the first cell. In some implementations, the RAN node attempts to receive a PUCCH transmission from the UE on the first cell after sending the LTM configuration or sending the LTM command. At block 1414, the RAN node detects that the UE accessed the first cell after receiving the PUCCH transmission from the UE. Flow proceeds from blocks 1412 and 1414 to block 1416. At block 1416, the RAN node communicates with the UE on the first cell in accordance with the LTM configuration.

[0244] In some implementations, at block 1408, the RAN node receives the UE's ID in a random access procedure. Upon receiving the ID, the RAN detects that the UE has accessed the first cell. In some implementations, the RAN node includes or configures the ID in an LTM configuration. In some implementations, the ID is a dedicated preamble, and the RAN node receives the dedicated preamble during the random access procedure. In other implementations, the ID is the UE's C-RNTI, and the RAN node receives the C-RNTI in Message A or Message 3 of the random access procedure.

[0245] In some implementations, at block 1412, the RAN node attempts to receive a PUCCH transmission from the UE on the PUCCH resources on the first cell. In some implementations, the RAN node includes configuration parameters configuring the PUCCH resources in an LTM configuration. After receiving the LTM command (e.g., in response to receiving the LTM command), the UE sends a PUCCH transmission on the PUCCH resources in accordance with the configuration parameters. In other implementations, after sending the LTM configuration or sending the LTM command, the RAN node sends one or more DCIs on the PDCCH to the UE on the first cell. The one or more DCIs assign or configure the PUCCH resources. After receiving the LTM command (e.g., in response to receiving the LTM command), the UE sends a PUCCH transmission on the PUCCH resources in accordance with the one or more DCIs. If the RAN node receives one of the PUCCH transmissions on the PUCCH resources, the RAN node detects that the UE has accessed the first cell.

[0246] Figure 14B 14 is a flow chart of an example method 1400B similar to method 1400A, except that method 1400B includes blocks 1413 and 1415 instead of blocks 1412 and 1414. At block 1413, the RAN node attempts to receive a PUSCH transmission from the UE on the first cell. In some implementations, the RAN node attempts to receive a PUSCH transmission from the UE on the first cell after sending an LTM configuration or sending an LTM command. At block 1415, the RAN node detects that the UE has accessed the first cell after receiving the PUSCH transmission from the UE. Flow proceeds from blocks 1413 and 1415 to block 1416.

[0247] In some implementations, at block 1413, the RAN node attempts to receive a PUSCH transmission from the UE on the PUSCH resources on the first cell. In some implementations, the RAN node includes configuration parameters configuring the PUSCH resources in an LTM configuration. After receiving the LTM command (e.g., in response to receiving the LTM command), the UE sends a PUSCH transmission on the PUSCH resources in accordance with the configuration parameters. In other implementations, after sending the LTM configuration or sending the LTM command, the RAN node sends one or more DCIs to the UE on the PDCCH on the first cell. The one or more DCIs assign or configure the PUSCH resources. After receiving the LTM command (e.g., in response to receiving the LTM command), the UE sends a PUSCH transmission on the PUSCH resources in accordance with the one or more DCIs. If the RAN node receives one of the PUSCH transmissions on the PUSCH resources, the RAN node detects that the UE has accessed the first cell.

[0248] against 9A to 9F and 12A to 12F The examples and implementations described can be applied to FIG. 14A to FIG. 14B .

[0249] The following description can be applied to the above description.

[0250] In general, the description of one of the above figures may apply to another of the above figures. The examples, implementations, and methods described above may be combined if not in conflict. Events or blocks described above may be optional or omitted. For example, events or blocks with dashed lines in the figures may be optional. In some implementations, "message" is used and "information element (IE)" may be used instead of "message," and vice versa. In some implementations, "IE" is used and "field" may be used instead of "IE," and vice versa. In some implementations, "configurations" or "configuration parameters" may be used instead of "configuration," and vice versa. In some implementations, "serving cell change command," "layer 1 / layer 2 handover command," "lower layer handover command," or "lower layer serving cell change command" may be used instead of "LTM command." In some implementations, "some" means "one or more." In some implementations, "at least one" means "one or more." In some implementations, "cell group configuration" may be used instead of "DU configuration." In some implementations, "cell index" may be replaced by "candidate cell index," "serving cell index," "LTM cell index," "special cell (SpCell) index," "PCell index," or "PSCell index." In some implementations, "cell ID" may be replaced by names such as "candidate cell ID," "serving cell ID," "SpCell ID," "LTM cell ID," "PCell ID," or "PSCell ID." In some implementations, "cell ID" and "cell ID" in the CU-to-DU message may be replaced by different names listed above.

[0251] The user device (e.g., UE 102) in which the technology of the present disclosure may be implemented may be any suitable device capable of wireless communication, such as a smartphone, tablet computer, laptop computer, mobile game console, point of sale (POS) terminal, health monitoring device, drone, camera, media streaming dongle or another personal media device, wearable device (such as a smart watch), wireless hotspot, femtocell or broadband router. In addition, in some cases, the user device may be embedded in an electronic system (such as a head unit of a vehicle or an advanced driver assistance system (ADAS)). Furthermore, the user device may operate as an Internet of Things (IoT) device or a mobile Internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0252] Certain embodiments are described in this disclosure as including logic or multiple components or modules. A module can be a software module (e.g., code or machine-readable instructions stored on a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit that is capable of performing certain operations and can be configured or arranged in a certain manner. A hardware module can include dedicated circuitry or logic that is permanently configured (e.g., as a dedicated processor, such as a field programmable gate array (FPGA) or application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.) to perform certain operations. A hardware module can also include programmable logic or circuitry (e.g., as contained 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 a dedicated and permanently configured circuitry or in a temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

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

[0254] After reading this disclosure, those skilled in the art will understand additional and alternative structural and functional designs for handling mobility between base stations using the principles disclosed herein. Thus, while specific embodiments and applications have been shown and described, it should be understood that the disclosed embodiments are not limited to the precise configurations and components disclosed herein. Various modifications, changes, and variations that will be apparent to those skilled in the art may be made to the arrangement, operation, and details of the methods and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.

Claims

1. A method implemented in a Radio Access Network (RAN) node, the method comprising: sending a lower layer triggered mobility (LTM) configuration from the RAN node to a user equipment (UE) communicatively coupled to the RAN node via a serving cell to configure a non-serving cell for the UE; In a first example, when the non-serving cell is synchronized with the serving cell, sending a first indication from the RAN node to the UE to cause the UE to perform a serving cell change to the non-serving cell and avoid performing a random access procedure; as well as In a second example, when the non-serving cell is not synchronized with the serving cell, a second indication is sent from the RAN node to the UE to enable the UE to perform the serving cell change and the random access procedure.

2. The method of claim 1, wherein: The first indication is a first LTM indication; and The second indication is a second LTM indication.

3. The method of claim 1, wherein: The first indication is a first LTM command; and The second indication is a second LTM command.

4. The method according to any one of claims 1 to 3, wherein: The LTM configuration includes a reconfiguration configuration with synchronization.

5. The method of claim 4, wherein: The reconfiguration with synchronization configuration is the ReconfigurationWithSync information element (IE).

6. The method according to any one of claims 1 to 5, further comprising: It is determined at a centralized unit (CU) whether the UE supports LTM without a random access procedure.

7. The method of claim 6, wherein: The sending of the first indication is in response to determining that the UE supports LTM without a random access procedure.

8. The method according to any one of the preceding claims, further comprising: When the UE is to avoid performing the random access procedure, a physical uplink shared channel transmission is received from the UE.

9. The method according to any one of claims 1 to 7, further comprising: When the UE is to avoid performing the random access procedure, a physical uplink control channel transmission is received from the UE.

10. An apparatus operating as a Radio Access Network (RAN) node, comprising processing hardware and configured to implement the method according to any preceding claim.

11. A method implemented in a user equipment (UE), the method comprising: receiving, at the UE, a lower layer triggered mobility (LTM) configuration from a radio access network (RAN) node communicatively coupled to the UE via a serving cell to configure a non-serving cell for the UE; In a first example, when the non-serving cell is synchronized with the serving cell, receiving a first indication from the RAN node to perform a serving cell change to the non-serving cell and to avoid performing a random access procedure; as well as In a second example, when the non-serving cell is not synchronized with the serving cell, a second indication is sent from the RAN node to perform the serving cell change and the random access procedure.

12. The method of claim 11, wherein: The first indication is a first LTM indication; and The second indication is a second LTM indication.

13. The method of claim 11, wherein: The first indication is a first LTM command; and The second indication is a second LTM command.

14. The method of any one of claims 11 to 13, wherein: The LTM configuration includes a reconfiguration configuration with synchronization.

15. A device operating as a user equipment (UE), comprising processing hardware and configured to implement the method according to any one of claims 11 to 14.

Images