Managing fast serving cell changes in radio access network

Abstract

A centralized unit (CU) of a distributed radio access network (RAN) node may implement a method for managing a lower layer triggered mobility protocol procedure. The method comprises: sending, from a CU to a distributed unit (DU) communicatively coupled with the CU, a request for a reference LTM configuration from the DU for generating a DU configuration for a user equipment (UE); receiving, at the CU, a reference LTM configuration in response to sending the request; and transmitting, from the CU, a reference LTM configuration for generating the DU configuration for the UE.

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,709, entitled “MANAGING A FAST SERVING CELLCHANGE IN A RADIO ACCESS NETWORK,” filed on February 14, 2023. The entire contents of that provisional application are hereby expressly incorporated herein by reference. Technical Field

[0003] The present disclosure relates to wireless communications, and more particularly to managing fast serving cell changes for user equipment (UE). 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 user plane data transfer, encryption, integrity protection, etc. For example, the PDCP layer defined for the Evolved Universal Terrestrial Radio Access (EUTRA) radio interface (see 3GPP Technical Specification (TS) 36.323) and New Radio (NR) (see 3GPP TS 38.323) provides sequencing of protocol data units (PDUs) in the uplink direction (from a user device (also referred to as user equipment (UE)) to a base station) and in the downlink direction (from a base station to a UE). Further, the PDCP sublayer provides signaling radio bearers (SRBs) and data radio bearers (DRBs) to the radio resource control (RRC) sublayer. Generally speaking, in some 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 under dual connectivity (DC), the cells associated with the base station operating the master node (MN) define the master cell group (MCG), while 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 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. Further, 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 simultaneously utilizes 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 under MR-DC, one base station operates as a master node (MN) covering a primary cell (PCell), while 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. One base station and / or the UE determines that the UE should establish a radio connection with another base station. For example, one base station determines to hand over the UE to a second base station and initiates a handover process.

[0008] When a UE moves from the coverage area of ​​one cell in the RAN to 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 that configures a reconfiguration with synchronization (e.g., the RRC reconfiguration message includes a ReconfigurationWithSync IE) for a serving cell (e.g., PCell or PSCell) change. In the case where the UE operates in carrier aggregation (CA) of at least one secondary cell (SCell) with a 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 latency and overhead for fast serving cell changes. In some scenarios, the RAN prepares multiple cells for LTM for the UE and therefore sends multiple LTM configurations, each configuring a specific cell. Multiple LTM configurations impose significant signaling overhead on the UE and the RAN. In some scenarios, to reduce signaling overhead, the RAN generates each of the multiple LTM configurations as an incremental configuration based on the service configuration (i.e., the most recent service configuration) used by the RAN and UE to communicate with each other. In some further scenarios, after providing the multiple LTM configurations to the UE, the RAN updates the service configuration, which, depending on the scenario, causes the RAN to update multiple LTM configurations. In some cases, the RAN frequently updates the service configuration, which, depending on the scenario, results in frequent updates to the LTM configuration. In some scenarios, frequent updates to the LTM configuration impose significant signaling overhead on the RAN and the UE. In some scenarios, to reduce overhead, the RAN generates a reference LTM configuration and generates multiple LTM configurations based on the reference LTM configuration. Because the reference LTM configuration is not a service configuration, updating the service configuration does not affect the UE's LTM configuration.

[0009] In some scenarios, when the CU communicates with the UE via the serving DU and the serving cell, the CU prepares the first cell of the serving DU for LTM using the serving DU. In some scenarios, when preparing the first cell for LTM using the serving DU, the CU receives a reference LTM configuration and a non-reference LTM configuration from the serving DU. Later, when the CU determines to prepare a second cell for the non-serving DU, the CU transmits the reference LTM configuration to the non-serving DU to prepare the second cell for LTM. Therefore, the non-serving DU generates one or more LTM configurations based on the reference LTM configuration. However, this prevents the CU from preparing the cell of the non-serving DU for LTM before preparing the cell of the serving DU for LTM, because the CU does not have the reference DU configuration before preparing the cell of the serving DU for LTM, resulting in inefficient use of LTM. Summary of the Invention

[0010] An example embodiment of the technology disclosed herein is a method implemented in a centralized unit (CU) of a radio access network (RAN) node, the method comprising: sending a request from the CU to a distributed unit (DU) communicatively coupled to the CU for a reference LTM configuration from the DU for generating a DU configuration for a user equipment (UE); receiving the reference LTM configuration at the CU in response to sending the request; and sending the reference LTM configuration from the CU for generating the DU configuration for the UE.

[0011] Another example embodiment of these techniques is a method implemented in a DU of a distributed radio access network (RAN) node, the method comprising: receiving, at the DU, a request for DU configuration from a centralized unit (CU) communicatively coupled to the DU; generating, at the DU in response to the request, a message based on whether the request from the CU requests reference to a lower layer triggered mobility (LTM) configuration; and sending the message from the DU to the CU.

[0012] Another example embodiment of the techniques is a radio access network (RAN) node 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 It includes Figure 1A A block diagram of an example base station of 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 example protocol stack;

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

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

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

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

[0020] Figure 5B is similar to Figure 5A but a message passing diagram for an example scenario in which the CU provides a reference lower layer triggered mobility configuration to the UE via the MN;

[0021] Figure 6A is similar to Figure 3 Message passing diagram of an example scenario where the CU communicates with the S-DU and T-DU in the SN;

[0022] Figure 6B is similar to Figure 6A but a message passing diagram for an example scenario in which the CU provides a reference lower layer triggered mobility configuration to the UE via the MN;

[0023] Figure 7A is similar to Figure 3 Example scenario but a message passing diagram of an example scenario where the CU communicates with the M-DU and S-DU;

[0024] Figure 7B is similar to Figure 7A but a messaging diagram for an example scenario where the CU provides a reference to a lower layer triggering mobility configuration to the UE via an M-DU;

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

[0026] Figure 8B is similar to Figure 8A but a messaging diagram for an example scenario where the CU provides a reference to a lower layer triggering mobility configuration to the UE via an M-DU;

[0027] Figure 9 is a flow chart depicting an example method implemented in a CU, wherein the CU determines whether to obtain a reference LTM configuration based on whether the CU receives the reference LTM configuration from a first DU;

[0028] Figure 10A is a flow chart depicting an example method implemented in a CU, wherein the CU sends a reference LTM configuration query indication to a first DU and sends a reference LTM to a second DU after receiving a reference DU from the LTM;

[0029] Figure 10B is a description similar to Figure 10A but a flowchart of an example method in which the CU sends a GNB-DU Configuration Query IE and an LTM indication to the first DU;

[0030] Figure 11A is a flow chart depicting an example method implemented in a CU, wherein the CU determines whether to send a reference LTM configuration query indication or a GNB-DU configuration query IE based on whether the CU queries a DU configuration for LTM;

[0031] Figure 11B is a description similar to Figure 11A Flowchart of an example method wherein the CU determines whether to send an LTM indication along with the GNB-DU Configuration Query IE;

[0032] Figure 12A is a flow chart depicting an example method implemented in a DU, wherein the DU determines whether to include a reference LTM configuration in a message based on whether the DU receives a reference LTM configuration query indication;

[0033] Figure 12B is a description similar to Figure 12A a flowchart of an example method of an embodiment wherein the DU further determines whether to include a first DU configuration based on whether the DU receives a GNB-DU Configuration Query IE;

[0034] Figure 13A is a flow chart depicting an example method implemented in a DU, wherein the DU determines whether to include a reference LTM configuration or a first DU configuration in a message based on whether the DU receives an LTM indication;

[0035] Figure 13B is a description similar to Figure 13A A flowchart of an example method of an example method wherein the DU makes a determination based on whether the query indication refers to an LTM Configuration Query Indication or a GNB-DU Configuration Query IE;

[0036] Figure 14 is a flow chart depicting an example method implemented in a CU, wherein the CU determines whether to include a reference LTM configuration or a serving DU configuration in a message to a DU based on whether the CU receives a reference LTM configuration for the UE;

[0037] Figure 15A is a flow chart depicting an example method implemented in a DU, wherein the DU determines whether to generate an LTM configuration using a reference LTM configuration or using a serving DU configuration based on whether the DU receives a reference LTM configuration; and

[0038] Figure 15B is a description similar to Figure 15A Flowchart of an example method of an embodiment wherein the DU further makes a determination based on whether the DU already has a reference LTM configuration. DETAILED DESCRIPTION

[0039] 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 (MN) and a network node (SN) of UE 102, respectively.

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

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

[0042] 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. UE 102 may, for example, communicate with base station 104 and an additional base station (T-BS) in DC before the handover. Figure 1A After the handover is completed, UE 102 may continue to operate with base station 106 and the additional base station in DC or operate with base station 106 in single connectivity (SC). In this case, base stations 104 and 106 operate as a source MN (S-MN) and a target MN (T-MN), respectively.

[0043] 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 1A1. The base station 104 can be an eNB supporting the S1 interface for communicating with the EPC 111, an ng-eNB supporting the NG interface for communicating with the 5GC 160, or a gNB supporting the NR radio interface and the NG interface for communicating with the 5GC 160. In order to exchange messages directly with each other during the scenarios discussed below, the base stations 104 and 106 can support the X2 or Xn interface. Among other components, the EPC 111 can also 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 transmit user plane packets associated with audio calls, video calls, internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from the UE to one or more external packet data networks (e.g., an internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network). 5GC 160 includes a user plane function (UPF) 162 and an access and mobility management (AMF) 164 and / or a session management function (SMF) 166. UPF 162 is generally configured to transmit 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.

[0044] 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 with base station 104 and base station 106 in DC, one of base stations 104 and 106 operates as a MeNB, Mng-eNB, or MgNB, and the other operates as an SgNB or Sng-eNB.

[0045] 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 applied to other suitable radio access and / or core network technologies, such as sixth generation (6G) radio access and / or 6G core network or 5G NR-6G DC.

[0046] 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 executed by the one or more general-purpose processors. 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 further include an RRC controller 134 to implement procedures and message delivery at the RRC sublayer of the protocol communication stack. For example, the RRC controller 134 may be configured to support RRC message delivery associated with a handover process and / or support necessary operations when the base station 104 operates as an MN relative to an SN or an SN relative to an MN. The base station 106 may include processing hardware 140 similar to the processing hardware 130. Specifically, components 142, 144, and 146 may be similar to components 132, 134, and 136, respectively.

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

[0048] 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 of one or more user devices, and communicating UL / DL MAC PDUs with base station 104 or 106. The processing hardware 150 may further include an RRC controller 154 to implement procedures and message delivery at the RRC sublayer of the protocol communication stack. Further, the processing hardware 150 may also include an LTM controller 156 configured to implement the following reference Figures 3 to 15B At least some of the techniques discussed.

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

[0050] 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 further include a physical layer controller configured to manage or control one or more physical layer operations or procedures.

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

[0052] 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 transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 can then provide data transfer 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 SDAP sublayer 212 layered on top of the NR PDCP sublayer 210.

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

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

[0055] Figure 2BAn example protocol stack 250 is shown in simplified form in which the UE 102 can communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). The radio protocol stack 200 is functionally split, such as 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.

[0056] 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 is similar to 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), with differences discussed below where appropriate. Except for 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) may apply to events labeled with similar reference numbers in other figures.

[0057] 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 the serving CU configuration). In some implementations, UE 102 uses the 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 cell includes 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.

[0058] 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 including SRBs and / or DRBs. In further 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 further 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) on cell 124A and / or other cells monitored by the UE 102 via one or more TRPs.

[0059] In some implementations, the serving DU configuration includes physical layer configuration parameters, MAC layer configuration parameters, and / or RLC configuration parameters. In some implementations, DU 174 sends the configuration parameters to CU 172. CU 172 generates one or more messages (e.g., RRC reconfiguration messages) including the configuration parameters and sends the one or more messages to UE 102 via DU 174. In other implementations, DU 174 sends the configuration parameters directly to UE 102. In some implementations, the serving DU configuration is a CellGroupConfig IE (e.g., as defined in 3GPP TS 38.331). In other implementations, the serving DU configuration includes configuration parameters in a 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., as 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.

[0060] 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 further implementations, 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.

[0061] In some implementations, the L1 measurement configuration is an RRC IE defined specifically 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 defined specifically for LTM (e.g., in 3GPP TS 38.331). In some implementations, the L1 measurement report configuration is an RRC IE defined specifically 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 UE 102 to send an L1 measurement report. If UE 102 detects a triggering event, UE 102 sends an L1 measurement report to DU 174.

[0062] 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 the other CSI components in (each of) the aforementioned PUCCH transmissions and / or PUSCH transmissions. 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 to identify or indicate a triggered L1 event. Alternatively, each of the L1 measurement reports does not include an L1 event ID to identify or indicate a triggered L1 event.

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

[0064] In some alternative implementations, for each of at least one measurement report (e.g., an L1 measurement report), the UE 102 sends a MAC control element (CE) including the measurement report to the DU 174 at event 304. 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.

[0065] 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).

[0066] After receiving one or more of the at least one measurement report from the UE 102 (e.g., in response thereto), the base station 104 (i.e., the CU 172 or the DU 174) determines to prepare a first cell (e.g., cell 124B) for LTM for the UE 102. In some implementations, the base station 104 determines to prepare the first cell for the UE 102 because the at least one measurement report indicates that the first cell can be used by the base station 104 for communicating with the UE 102. In some implementations, the base station 104 determines to prepare the first cell for the UE 102 because the at least one measurement report indicates that the first cell qualifies as a candidate cell that can be used for communicating with the UE 102. In some implementations, the CU 172 determines to prepare the first cell for the 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 the cell 124A, and / or is better than the strength and / or quality of the 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 DU 174 determines to prepare the first cell for UE 102. Alternatively, base station 104 determines to prepare the first cell for UE 102 regardless of whether a measurement report is received from UE 102.

[0067] 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, which configures 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 sending the first DU-to-CU message to CU 172 rather than responding to a CU-to-DU message received from CU 172.

[0068] 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 identifies 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 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 the additional cell IDs associated with each additional LTM configuration 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.

[0069] 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 to enhance 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.

[0070] In some implementations, the reference LTM configuration includes physical layer configuration parameters, MAC layer 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.

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

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

[0073] 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 for integrity (MAC-I) for the RRC reconfiguration message, encrypts the RRC reconfiguration message and the MAC-I to obtain an encrypted RRC reconfiguration message and an encrypted MAC-I, and sends a PDCP PDU including the encrypted RRC reconfiguration message and the encrypted MAC-I to UE 102 via DU 174 at events 316 and 318. 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 message 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 further implementations, 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).

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

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

[0076] 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 of 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.

[0077] In some implementations, the first CU-to-DU message is a UE Context Modification Request message, and the first DU-to-CU message is a UE Context Modification Response message or 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 Confirm 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.

[0078] 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 should not be immediately applied. In some scenarios and 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 further implementations, 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.

[0079] CU assigns ID to LTM configuration 1

[0080] In some implementations, CU 172 includes a first LTM ID (hereinafter referred to herein 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 in a first DU-to-CU message from DU 174, as described below.

[0081] 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 further 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 the 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 the 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.

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

[0083] DU assigns ID to LTM configuration 1

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

[0085] 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 first DU-to-CU message 310. In such cases, CU 172 includes the fourth container in RRC reconfiguration message 316. Alternatively, the 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.

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

[0087] 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 further 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., as defined in 3GPP TS 38.331). In other implementations, LTM Configuration 1 includes configuration parameters in the CellGroupConfig IE.

[0088] 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 has 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 has 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 random access configuration, UE 102 skips or avoids performing the random access procedure of event 332 in response to LTM configuration 1 excluding random access configuration.

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

[0090] 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, then in response to LTM configuration 1 excluding the first indication, UE 102 performs a random access procedure according to the random access configuration at event 332, as described below.

[0091] In some implementations, the DU 174 includes the reconfiguration with synchronization configuration (e.g., ReconfigurationWithSync IE) in LTM Configuration 1 or the special cell configuration. In other implementations, the DU 174 does not include the reconfiguration with synchronization configuration (e.g., ReconfigurationWithSync IE) in LTM Configuration 1 or the special cell configuration. In some implementations, if the cell 124A and the first cell are not synchronized, the DU 174 determines to include the reconfiguration with synchronization configuration in LTM Configuration 1. Otherwise, if the cell 124A and the first cell are synchronized, the DU 174 determines not to include the reconfiguration with synchronization configuration in LTM Configuration 1. In other implementations, if the DU 174 determines that the UE 102 has not yet synchronized with the first cell in the UL, the DU 174 determines to include the reconfiguration with synchronization 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 a reconfiguration with a synchronization configuration in LTM configuration 1. In some implementations, if LTM configuration 1 includes a reconfiguration with a synchronization configuration, UE 102 performs a random access procedure at event 332 in response to or in accordance with the reconfiguration with a synchronization configuration, as described below. Otherwise, if LTM configuration 1 does not include a reconfiguration with synchronization configuration, 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 further 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 further 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). The cell index occupies fewer bits than the 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.

[0092] In some implementations, after receiving one or more of the at least one measurement report for event 304 (e.g., in response thereto), base station 104 (i.e., CU 172 or DU 174) determines to prepare additional cells of base station 104 for LTM (i.e., cell 2, ..., N) for UE 102. In some implementations, base station 104 determines to prepare additional cells for LTM for UE 102 because at least one measurement report indicates that base station 104 can use 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, CU 172 determines to prepare a particular cell of the additional cells for LTM for UE 102 if the L3 measurement report indicates that the signal strength and / or quality of the particular cell is above a corresponding predetermined threshold and / or is better than cell 124A. 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 further 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.

[0093] In the event that CU 172 determines to prepare an additional cell, CU 172 initiates and performs at least one additional LTM preparation procedure with DU 174 to prepare the additional cell for LTM, wherein each of the LTM preparation procedures is similar to procedure 390. In the event that DU 174 determines to prepare an additional cell, DU 174 initiates and performs at least one additional LTM preparation procedure with CU 172 to prepare the additional cell for LTM, wherein each of the LTM preparation procedures is similar to procedure 390.

[0094] In some implementations, the CU 172 and the DU 174 perform LTM preparation processes 2, ..., N similar to process 390 to prepare cells 2, ..., N, respectively. In some implementations, the CU 172 includes cell IDs 2, ..., N in CU-to-DU messages 2, ..., N, similar to the first CU-to-DU message, in the LTM preparation processes 2, ..., N, respectively. In 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. When the DU 174 receives the CU-to-DU messages 2, ..., N, the DU-to-CU messages 2, ..., N, respectively, 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.

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

[0096] 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) used to identify 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.

[0097] 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 in the first DU-to-CU message of process 390 from the DU 174. In still other implementations, the CU 172 receives the IDs 2, ..., N in DU-to-CU messages 2, ..., N of LTM preparation processes 2, ..., N, respectively, from the DU 174.

[0098] In some implementations, CU 172 performs an LTM ID assignment process similar to process 392 with DU 174 for each of LTM configurations 2, ..., N. In other implementations, CU 172 includes IDs 2, ..., N and LTM configurations 2, ..., N in a third CU-to-DU message and indicates the association between IDs 2, ..., N and LTM configurations 2, ..., N, respectively. Thus, in some implementations, DU 174 associates LTM configurations 2, ..., N with IDs 2, ..., N, respectively. In still other implementations, CU 172 includes cell IDs 2, ..., N and IDs 2, ..., N in a third CU-to-DU message and indicates the association between cell IDs 2, ..., N and IDs 2, ..., N, respectively. Therefore, in further implementations, 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, respectively, 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.

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

[0100] In some alternative implementations, instead of using the first container, CU 172 generates a second container including LTM configurations 2, ..., N or elements 2, ..., N. Then, similar to events 316 and 318, CU 172 sends an additional RRC reconfiguration message including the second container to UE 102 via DU 174. In response, similar to events 320 and 322, UE 102 sends an additional RRC reconfiguration complete message to CU 172 via DU 174. 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)).

[0101] 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 further 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 may be different from the cell IDs 1, ..., N in the CU-to-DU message described above.

[0102] 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 other 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 further 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.

[0103] In some implementations, CU 172 determines to release LTM configuration M (or element M) from LTM configurations 1, ..., N (or element M from elements 1, ..., M), 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 for releasing LTM configuration M or element M, including ID (i.e., LTM ID) 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, CU 172 includes the 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 to indicate to DU 174 that the LTM configuration M is to be released. In response, DU 174 releases the 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.

[0104] In other implementations, DU 174 determines to release LTM configuration K. In response to this 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 may include 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. Further, 1 ≤ K ≤ N. After receiving the DU-to-CU message (e.g., in response thereto), 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, in response to the DU to CU message, the CU 172 sends a CU to DU message to the DU 174. 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 confirm message, respectively.

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

[0106] 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, CU 172 sends one or more RRC messages (e.g., RRCReconfiguration messages) including the at least one measurement configuration to UE 102 via DU 174 during event 302 and / or 316 and / or after event 306 or 316. 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.

[0107] In some implementations, the at least one measurement configuration includes an L3 measurement configuration (e.g., a MeasConfig IE), as described for event 304. In other implementations, the 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 report configuration. UE 102 sends an L1 measurement report to DU 174 on a PUCCH or MAC CE based on the measurement report configuration. DU 174 receives the L1 measurement report on a PUCCH or MAC CE based on the measurement report configuration. In some implementations, the measurement report configuration is a CSI-ReportConfig IE. In other implementations, each of the measurement report configurations is a specially defined RRC IE. In some implementations, (each of) the measurement report configurations configures periodic reporting and / or event-triggered reporting of L1 measurement results.

[0108] In yet other implementations, at least one measurement configuration includes a specifically defined type of measurement configuration (e.g., an LTM measurement configuration). In some implementations, the specifically defined type of measurement configuration is defined specifically for LTM (e.g., in a 3GPP TS). In some implementations, the specifically defined type of measurement configuration includes a reference signal resource configuration that configures 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 further implementations, as described above, the specifically defined type of measurement configuration includes a measurement report configuration. 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 specifically defined type of measurement report (e.g., an LTM measurement report). In some implementations, the specifically defined type of measurement configuration includes configuration parameters (e.g., specifically defined in a 3GPP TS).

[0109] After receiving at least one measurement report at event 324 (e.g., in response thereto), 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.

[0110] In yet other implementations, the DU 174 includes a bitmap in the first LTM command to activate LTM configuration 1 instead of ID 1 or cell index 1. The number of bits in the bitmap is greater than or equal to "N". In some implementations, bits 1, ..., N correspond to cell indexes 1, ..., N, IDs 1, ..., N, LTM configurations 1, ..., N, or elements 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 further implementations, bits 0, ..., N-1 correspond to cell indices 1, ..., N, IDs 1, ..., N, LTM configurations 1, ..., N, or elements 1, ..., N, respectively, and the 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, the 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, the DU 174 sets the remaining bits in the bitmap to a second value to indicate that the remaining 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. In general, depending on the implementation, if the DU 174 determines to activate LTM configuration L or change the serving cell to cell L, the 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, the DU 174 sets at most one bit in the bitmap to the first value.

[0111] In some implementations, the at least one measurement report of event 324 (e.g., an L1 measurement report or a specifically defined type of measurement report) includes at least one measurement result of the first cell, a 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 transmit 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 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 of 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, in response to the signal strength or quality of the first cell being above the second predetermined threshold for UE 102, DU 174 determines to activate LTM configuration 1.

[0112] 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 further implementations, 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 has been continuously above the second predetermined threshold or the first predetermined threshold, further indicating that the first cell is suitable for communication with UE 102. Therefore, in response to the signal strength or quality of the first cell being above the second predetermined threshold, CU 172 determines to activate LTM configuration 1. In response to this 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 to cell 1 for UE 102. 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)).

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

[0114] In some implementations, the first LTM command is a MAC CE included in a MAC PDU received by UE 102 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) that identifies the specifically defined MAC CE. For example, the logical channel ID or the extended logical channel ID (e.g., in 3GPP TS 38.321) is specifically defined for identifying the specifically defined MAC CE. In other implementations, the first LTM command is a DCI received by UE 102 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., as defined in 3GPP TS 38.212). In further implementations, the format of the DCI is a DCI format specifically defined for this purpose (e.g., as defined in 3GPP TS 38.212).

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

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

[0117] 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 including an L3 measurement configuration (MeasConfig IE) to the UE 102 before event 306. 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 a specifically defined type of measurement report 324, the CU 172 sends a second RRC reconfiguration message including an L1 or a specifically defined type of measurement configuration to the UE 102. 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.

[0118] After receiving the first LTM command (e.g., in response thereto), UE 102 identifies LTM configuration 1 based on ID 1 and applies LTM configuration 1. In some implementations, UE 102 performs 332 a random access procedure on the first cell with DU 174 in response to applying LTM configuration 1 or receiving the first LTM command. In some implementations, UE 102 disconnects from cell 124A after receiving the first LTM command or after sending an acknowledgment (e.g., in response thereto). In other words, after receiving 330 the first LTM command or sending 331 an acknowledgment (e.g., in response thereto), UE 102 ceases communicating on cell 124A. In such cases, UE 102 performs 332 a random access procedure after disconnecting from cell 124A. 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., a 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 does not configure UE 102 to skip a random access procedure, UE 102 avoids performing a random access procedure with DU 174 upon 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.

[0119] 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 337 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.

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

[0121] In the event that the UE 102 skips the random access procedure, the UE 102, after receiving the first LTM command (e.g., in response thereto), communicates 336 directly with the DU 174 on the first cell according to LTM configuration 1 and communicates with the CU 172 via the DU 174. For example, 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 at event 336. In some implementations, the DU 174 includes configuration parameters in the LTM configuration 1 that configure resources for the UE 102 to transmit at least one PUCCH or PUSCH transmission, and the UE 102 uses the configuration parameters to transmit at least one PUCCH or PUSCH transmission on the resources to indicate that the UE 102 is connected to the first cell. In other implementations, the DU 174 transmits at least one DCI to the UE 102 on the PDCCH on the first cell to instruct the UE 102 to transmit at least one PUCCH or PUSCH transmission after transmitting the first LTM command. The at least one DCI configures resources for UE 102 to transmit at least one PUCCH or PUSCH transmission, and UE 102 transmits at least one PUCCH or PUSCH transmission on the resources. DU 174 identifies or determines that UE 102 is connected to the first cell upon receiving the PUCCH or PUSCH transmission. DU 174 identifies or determines that UE 102 is connected to the first cell upon receiving the PUCCH or PUSCH transmission on the resources configured in LTM configuration 1 or the at least one DCI.

[0122] 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 LTM configuration 1 and the configuration parameters in 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 LTM configuration 1 and the configuration parameters in the reference LTM configuration.

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

[0124] 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 may be 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 .

[0125] 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. Thus, CU 172 determines that UE 102 is connected to the first cell upon receiving the DU-to-CU message at event 334. 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).

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

[0127] 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 that LTM configuration 1 is a complete configuration in LTM configuration 1. In some implementations, DU 174 includes an indication in each of LTM configurations 2, ..., N 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 complete configurations 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 complete configurations in the first container. In yet other implementations, for each of LTM configurations 2, ..., N, CU 172 includes a specific indication that the corresponding LTM configuration is a complete configuration in the first container. In some cases for the second container, CU 172 includes a single indication that LTM configurations 2, ..., N are complete configurations in the second container. In yet other implementations, CU 172 includes an indication that LTM configuration 1 is a complete configuration in element 1. In some implementations, in each of elements 2, ..., N, CU 172 includes an indication that the corresponding LTM configuration is a complete configuration. In some implementations, UE 102 determines that LTM configuration 1 and / or LTM configurations 2, ..., N are complete configurations 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 the fullConfig field (e.g., as defined in current 3GPP TS). In the case where LTM configuration 1 is a full configuration, if received from base station 104 (e.g., in RRC reconfiguration message 318), UE 102 in event 336 does not apply the reference LTM configuration. In some such cases, DU 174 does not include the reference LTM configuration in the first DU to CU message 310.

[0128] 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 utilize LTM configuration 1 to enhance at least a portion of the reference LTM configuration. 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 complete configurations to indicate that LTM configurations 1 and / or 2, ..., N are incremental configurations. In some implementations, the UE 102 determines that each of the LTM configurations 1 and / or 2, ..., N is an incremental configuration based on an indication being excluded in the LTM configurations 1 and / or 2, ..., N, the first container, the second container, or the elements 1 and / or 2, ..., N.

[0129] 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 receives 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.

[0130] 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 incremental 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 receives 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 incremental 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.

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

[0132] In some implementations, when the UE 102 resets the UE MAC entity, the UE 102 performs at least one of the following actions with respect to the UE MAC entity (i.e., a UE MAC reset or a 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), deems timeAlignmentTimer expired; (iv) sets UL (v) Set the New Data Indicator (NDI) of the HARQ process to a value of 0; (vi) Set the NDI of the HARQ process ID to a value of 0 for monitoring PDCCH in sidelink resource allocation mode 1; (vi) Flush the Msg3 buffer; (vii) Flush the MSGA buffer; (viii) Cancel (if any) the triggered scheduling request procedure; (ix) Cancel (if any) the triggered buffer status report procedure; (x) Cancel (if any) the triggered power headroom report procedure; (xi) Cancel (if any) the triggered consistent LBT failure; (xii) Cancel (if any) the triggered BFR; (xiii) Cancel (if any) ) triggered sidelink buffer status reporting procedure; (xiv) cancel (if any) the triggered preemptive buffer status reporting procedure; (xv) cancel (if any) the triggered timing advance reporting procedure; (xvi) cancel (if any) the triggered recommended bit rate query procedure; (xvii) cancel (if any) the triggered configured uplink grant confirmation; (xviii) cancel (if any) the triggered configured sidelink grant confirmation; (xix) cancel (if any) the triggered expected protection symbol query; (xx) cancel (if any) the triggered positioning measurement gap activation / deactivation request procedure; (xxi) flush the soft buffer for the DL HARQ process; (xxii) for each of the DL HARQ processes, treat the next received transmission of the TB as the initial transmission; (xxiii) release (if any) the temporary C-RNTI; and / or (xiv) reset one or more counters (e.g., BFI_COUNTER and / or LBT_COUNTER).

[0133] In some implementations, when DU 174 resets the DU MAC entity, DU 174 performs at least one of the following actions with respect to 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 to perform a random access procedure (e.g., event 332) in a configuration (e.g., configuration 1), deems a timeAlignmentTimer started and / or maintained by DU 174 for UE 102 to have expired; (iii) sets the NDI for the DL HARQ process to a value of 0; (iv) flushes the soft buffers for the UL HARQ processes; (v) for each of the UL HARQ processes, treats the next received transmission of the TB as the initial transmission; and / or (vi) resets one or more counters (e.g., BFI_COUNTER and / or LBT_COUNTER).

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

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

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

[0137] 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 a 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 a HARQ process ID to a value of 0 for monitoring the PDCCH in sidelink resource allocation mode 1; (iv) flushing soft buffers for DL ​​HARQ processes; and / or (v) for each of the DL HARQ processes, treating the next received transmission of the TB as the initial transmission;

[0138] 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 complete DU MAC reset). In a complete 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 complete DU MAC reset.

[0139] 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 to perform a random access procedure (e.g., event 332) in a configuration (e.g., configuration 1), deeming the timeAlignmentTimer started and / or maintained by the DU 174 for the UE 102 to be expired and / or (ii) resetting one or more counters (e.g., BFI_COUNTER and / or LBT_COUNTER).

[0140] 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 buffer for the UL HARQ process; (iv) for each of the UL HARQ processes, treating the next received transmission of the TB as the initial transmission; and / or (v) resetting one or more counters (e.g., BFI_COUNTER and / or LBT_COUNTER).

[0141] 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 (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 uses the UE MAC entity (not reset) to communicate with DU 174 on the first cell. Similarly, DU 174 uses the DU MAC entity (not reset) to communicate 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.

[0142] 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 the acknowledgment 331, or determining that the UE 102 is connected to the first cell.

[0143] 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 that UE 102 uses 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 332 a random access procedure 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 332 a random access procedure. 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.

[0144] 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) discarding RLC SDUs, RLC SDU segments, and RLC PDUs (if any); (ii) stopping a timer and resetting the timer (if running); and / or (iii) resetting a state variable to an initial value. In some implementations, the state variables and timers are predefined (e.g., in 3GPP TS 38.322).

[0145] 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 refrains from re-establishing 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.

[0146] 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 a first DU RLC entity among the at least one DU RLC entity after sending a first LTM command, receiving an acknowledgment of 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 segment, and RLC PDU (if any); (ii) stopping and resetting the timer (if running); and / or (iii) resetting the state variable to an initial value. In some implementations, the state variable and timer are predefined (e.g., in 3GPP TS 38.322).

[0147] In other implementations, UE 102 refrains from reestablishing some or all of the at least one UE RLC entities in response to receiving the first LTM command. Similarly, DU 174 refrains from reestablishing some or more of the at least one DU RLC entities after (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 uses some or all of the at least one UE RLC entity (not reestablished) to communicate with DU 174 on the first cell. 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 uses some or all of the at least one DU RLC entity (not reestablished) to communicate 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. 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.

[0148] In some implementations, the UE 102 uses at least one UE PDCP entity (e.g., PDCP 210) to communicate UL PDCP PDUs and / or DL ​​PDCP PDUs with at least one CU PDCP entity (e.g., PDCP 210) of the CU 172 at event 302. In some implementations, the UE 102 performs a PDCP recovery procedure for some or all of the at least one UE PDCP entity after or in response to receiving the first LTM command. 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 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, the UE 102 resends at least a portion of the UL PDCP PDU to the CU 172 via the DU 174 and the first cell at event 336. Similarly, CU 172 performs a PDCP recovery procedure for some or all of the at least one CU PDCP entities 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 entities 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 re-establish the first CU PDCP entity. In some implementations, after or in response to performing the PDCP recovery procedure, CU 172 resends at least a portion of the DL PDCP PDU to UE 102 via DU 174 and the first cell at event 336.

[0149] In other implementations, the 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, after receiving (e.g., in response to) the DU to CU message 329 or 340 or after receiving (e.g., in response to) the DL data delivery status message, the CU 172 avoids re-establishing some or more of the at least one CU PDCP entities. In other words, the UE 102 uses some or all of the at least one UE PDCP entity (not re-established) to communicate with the CU 172 via the DU 174 and the first cell. For example, some or all of the at least one UE PDCP entity include the first UE PDCP entity and / or the second UE PDCP entity. Similarly, the CU 172 uses some or all of the at least one CU PDCP entity (not re-established) to communicate with the UE 102 via the DU 174 and the first cell. 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.

[0150] 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 Modification Request message) to the DU 174 to instruct the DU 174 to cease communicating with the UE 102 and / or release or suspend the 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 the resources of the cell 124A configured for the UE 102 and sends 340 a DU-to-CU message (e.g., a UE Context Modification 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.

[0151] 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, respectively, occur, similar to events 324, 326, 328, 330, 331, 332, 334, and / or 336. 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 thereto), 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). The DU 174 then sends 350 a second LTM command to the UE 102 on the first cell.

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

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

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

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

[0156] 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 cells 1, ..., N to be prepared 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, similar to event 308, 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. In response, similar to event 310, T-DU 174B sends a DU-to-CU message including LTM configurations 1, ..., N to CU 172. LTM configurations 1, ..., N respectively configure cells 1, ..., N for LTM. Specifically, LTM configurations 1, ..., N respectively include configuration parameters for communication on cells 1, ..., N. 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. Similar to LTM configuration delivery process 394, CU 172 then sends LTM configurations 1, ..., N in an RRC reconfiguration message in LTM configuration delivery process 494. 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 .

[0157] 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 LTM for the UE 102, where M is a positive integer greater than zero. In further implementations, similar to events 404 and 406, the CU 172 determines to do so based on one or more measurement reports received from the UE 102 via the S-DU 174A. 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 LTM for the UE 102. 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-CU message to CU 172 that includes LTM configurations N+1, ..., N+M. LTM configurations N+1, ..., N+M respectively configure cells N+1, ..., N+M for LTM. Specifically, LTM configurations N+1, ..., N+M respectively include configuration parameters for communication on cells N+1, ..., N+M. Similar to LTM configuration delivery procedures 394 or 494, CU 172 then sends LTM configurations N+1, ..., N+M in an RRC reconfiguration message in an additional LTM configuration delivery procedure.

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

[0159] 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 receives a first DU-to-CU message from S-DU 174A at event 310, including a reference LTM configuration. In other implementations, CU 172 and S-DU 174A do not perform process 380 with UE 102. In some such cases, CU 172 performs 488 a reference LTM configuration query process with S-DU 174A 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 in the CU-to-DU message to request or query the reference LTM configuration. In response to the indication or CU-to-DU message 460, S-DU 174A sends 462 a DU-to-CU message to CU 172 including the reference LTM configuration. 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 a query indication (e.g., a GNB-DU Configuration Query IE) in the 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 cases, 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, the CU 172 does not include the reference LTM configuration in the CU-to-DU message in the additional LTM preparation process with the T-DU 174B. In case of an additional LTM preparation process, the T-DU 174B generates LTM configurations N+1, . . . , N+M based on the reference LTM configuration received from the CU 172 .

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

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

[0162] In some implementations, the CU 172 sends 412 a CU-to-DU message including IDs 1, ..., N to the S-DU 174A and receives 414 a DU-to-CU message from the S-DU 174A in response. The CU-to-DU message 412 and the DU-to-CU message 414 are transmitted in parallel. 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 further 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 procedures, the CU 172 includes a specific portion of the IDs 1, ..., N; the cell IDs 1, ..., N and / or the LTM configurations 1, ..., N in a CU-to-DU message similar to message 412. Thus, the S-DU 174A associates the IDs 1, ..., N with the LTM configurations 1, ..., N and / or the cell IDs 1, ..., N, respectively. In other alternative implementations, the CU 172 performs multiple LTM cell index transfer procedures to send the cell indexes 1, ..., N; the cell IDs 1, ..., N and / or the LTM configurations 1, ..., N to the S-DU 174A. In each of the procedures, the CU 172 includes a specific portion of the cell indexes 1, ..., N; the cell IDs 1, ..., N and / or the LTM configurations 1, ..., N in a CU-to-DU message similar to message 412. Thus, the S-DU 174A associates cell indices 1, ..., N with LTM configurations 1, ..., N and / or cell IDs 1, ..., N, respectively.

[0163] In some implementations, similar to CU-to-DU message 412 and DU-to-CU message 414, respectively, CU 172 sends a CU-to-DU message including IDs N+1, ..., N+M to S-DU 174A and receives a DU-to-CU message from S-DU 174A in response. In some implementations, CU 172 includes LTM configurations N+1, ..., N+M and / or cell IDs N+1, ..., N+M in the CU-to-DU message. In some alternative implementations, CU 172 performs multiple LTM ID transfer procedures to send IDs N+1, ..., N+M; cell IDs N+1, ..., N+M; and / or LTM configurations N+1, ..., N+M to S-DU 174A. In each of the processes, the CU 172 includes specific portions of the IDs N+1, ..., N+M; cell IDs N+1, ..., N+M and / or LTM configurations 1, ..., N in a CU-to-DU message similar to message 412. 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.

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

[0165] In some implementations, later, similar to event 324, UE 102 sends 424 at least one measurement report to S-DU 174A. 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 includes 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 further 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 event ID, 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. Upon receiving 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 or process 380 is not performed in process 380, 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 thereto), UE 102 applies LTM configuration 1 to communicate with T-DU 174B.

[0166] In some implementations, similar to event 332, after receiving the first LTM command (e.g., in response thereto), the UE 102 performs or does not perform 432 a random access procedure with the T-DU 174B. In further implementations, similar to event 336, after receiving the first LTM command or completing the random access procedure 432 (e.g., in response thereto), 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.

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

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

[0169] 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 similar to Figure 3 CU and DU of base station 104.

[0170] Initially, UE 102 communicates with MN 106 and SN 104 in DC. At event 502, similar to event 302, UE 102 communicates with DU 174 on cell 124A using a serving DU configuration and communicates with CU 172 via DU 174 using a serving CU configuration. 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 a radio bearer that includes an SRB and / or a DRB, depending on the implementation. In some implementations, MN 106 and / or SN 104 configures the radio bearer to UE 102. UE 102 communicates 502 UL PDUs and / or DL ​​PDUs with SN 104 under 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 under 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 in one or more RRC messages from MN 106. As described for Figure 3 As described above, the service DU configuration includes a plurality of configuration parameters. In some implementations, UE 102 receives the configuration parameters in one or more RRC messages from SN 104 (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).

[0171] In some implementations, when UE 102 communicates with MN 106 and SN 104 in DC, MN 106 and UE 102 perform 580 an LTM configuration and / or activation procedure similar to procedures 380 and / or 480. In some implementations, when communicating with MN 106 and SN 104 in DC, 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, when communicating with MN 106 and SN 104 in DC, 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 Modify Request message.

[0172] After receiving at least one measurement report (e.g., in response thereto) 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. 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, similar to event 336, the UE 102 operating under 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. In some implementations, later, the DU 174 and / or the CU 172 perform an LTM execution process 598 with the UE 102, similar to process 398 or 498, to instruct the UE 102 to perform a cell change from the first cell to the second cell. As a result of process 598, similar to event 356, the UE 102 operating under 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.

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

[0174] Next reference Figure 5B Scenario 500B is generally similar to scenario 500A, except that SN 104 sends 517, 519 RRC reconfiguration messages to UE 102 via MN 106, and receives 521, 523 RRC reconfiguration complete messages 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.

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

[0176] Next reference Figure 6AIn scenario 600A, similar to scenarios 300-500B, base station 106 operates as a MN and base station 104 operates as a SN. Similar to base station 104 in scenario 400, SN 104 includes CU 172, S-DU 174A, and T-DU 174B. 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 similar to procedures 380 and / or 480 with UE 102. 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 similar to procedures 581 and / or 582 with UE 102 via M-DU 174A or S-DU 174B.

[0177] Next reference Figure 6B , scenario 600B is similar to scenarios 300 - 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 .

[0178] Next reference Figure 7A In scenario 700A, similar to scenarios 300-600B, base station 104 operates as both a MN and a SN. Base station 104 includes CU 172, primary DU (M-DU) 174A, and secondary DU (S-DU) 174B. Figure 3 Base station 104 or Figures 5A to 6B MN 106 in, CU 172 operates with M-DU 174A as MN and similarly Figures 5A to 6B In the SN 104, the CU 172 operates with the S-DU 174B as the SN.

[0179] 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, similar to event 302, 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. Events 704 and 706 are similar to events 304 and 306. In some implementations, similar to event 304, UE 102 sends 705 at least one measurement report to M-DU 174A. Similar to event 306, M-DU 174A then sends 707 at least one DU-to-CU message to CU 172 including the at least one measurement report. In some implementations, when the UE 102 communicates with the M-DU 174A and the S-DU 174B in DC, the CU 172 performs 780 an LTM configuration and / or activation procedure similar to the procedure 380 with the UE 102 via the M-DU 174A.

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

[0181] Next reference Figure 7B , scenario 700B is similar to scenarios 300-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.

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

[0183] Next reference Figure 8AIn scenario 800A, similar to scenarios 300-700B, base station 104 operates as both a mobile node and a network node. 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 with M-DU 174A as a mobile node and with S-DU 174B as a network node. 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 similar to process 380 with UE 102 via M-DU 174A. In some implementations, when UE 102 communicates with M-DU 174A and S-DU 174B under DC, CU 172 performs 881 an LTM configuration and / or activation process similar to process 581 or 582 with UE 102 via S-DU 174A.

[0184] Next reference Figure 8B , scenario 800B is similar to scenarios 300-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.

[0185] Next, refer to Figures 9 to 15B Several example methods for a RAN node 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 Figures 9 to 15B .

[0186] Figure 9 An example method 900 is illustrated that a CU (eg, CU 172 of base station 104 or 106 ) may implement for configuring LTM for a UE (eg, UE 102 ).

[0187] Method 900 begins at block 902, where the CU communicates with the UE via a first DU (e.g., events 402, 602, 802). At block 904, the CU determines to utilize a second DU to prepare LTM for the UE. At block 906, the CU determines whether to receive a reference LTM configuration for the UE from the first DU. If, at block 906, the CU determines not to receive a reference LTM configuration for the UE from the first DU, the process proceeds to block 908. At block 908, the CU obtains a reference LTM configuration for the UE from the first DU (e.g., events 460, 462, 488, 688, 888). Otherwise, if, at block 906, the CU determines to receive a reference LTM configuration for the UE from the first DU, the process proceeds to block 910. At block 910, the CU includes the reference LTM configuration in a CU-to-DU message (e.g., events 490, 690, 890). The process proceeds from blocks 906 and 908 to block 910. At block 912, the CU sends a CU-to-DU message to the second DU (e.g., events 490, 690, 890). At block 914, the CU receives a DU-to-CU message including at least one LTM configuration from the second DU (e.g., events 490, 690, 890). At block 916, the CU sends the at least one LTM configuration to the UE via the first DU (e.g., events 494, 694, 617, 619, 894, 817, 819).

[0188] In some implementations, the CU sends a CU-to-DU message including a reference LTM configuration to the third DU to request that the cell be prepared for LTM. In some implementations, the CU sends the CU-to-DU message to the third DU after the CU receives an indication from the second DU that the UE is connected to the second DU. In other implementations, the CU sends the CU-to-DU message to the third DU while communicating with the UE via the first DU. In response to the CU-to-DU message, the third DU generates an LTM configuration for configuring the cell for LTM based on the reference LTM configuration, and sends a DU-to-CU message including the LTM configuration to the CU. The CU sends the LTM configuration to the UE via the first DU.

[0189] Figure 10A An example method 1000A is illustrated that a CU (eg, CU 172 of base station 104 or 106) may implement to configure LTM for a UE (eg, UE 102).

[0190] Method 1000A begins at block 1002, where a CU determines a query reference LTM configuration. At block 1004, the CU sends a CU-to-DU message including a reference LTM configuration query indication to a first DU (e.g., events 460, 488, 688, 888). At block 1006, the CU receives a DU-to-CU message including a reference LTM configuration from the first DU (e.g., events 462, 488, 688, 888). At block 1008, the CU sends a CU-to-DU message including a reference LTM configuration to a second DU (e.g., events 494, 694, 894). At block 1010, the CU receives a DU-to-CU message including at least one LTM configuration from the second DU (e.g., events 494, 694, 894). At block 1012, the CU sends the reference LTM configuration and at least one LTM configuration to the UE (e.g., events 494, 694, 617, 619, 894, 817, 819).

[0191] In some implementations, the first DU sends a DU-to-CU message including a reference LTM configuration in response to a CU-to-DU message including a reference LTM configuration query indication.

[0192] Figure 10B is a flow chart of an example method 1000B that is similar to method 1000A, except that method 1000B includes block 1005 instead of block 1004. At block 1005, the CU sends a CU-to-DU message including a GNB-DU Configuration Query IE and an LTM indication to the first DU.

[0193] In some implementations, the first DU sends a DU-to-CU message including a reference LTM configuration in response to a CU-to-DU message including a GNB-DU Configuration Query IE and an LTM indication.

[0194] Figure 11A An example method 1100A is illustrated that a CU (eg, CU 172 of base station 104 or 106) may implement to configure LTM for a UE (eg, UE 102).

[0195] Method 1100A begins at block 1102, where the CU determines to query the DU configuration. At block 1104, the CU determines whether to query the DU configuration for LTM. If, at block 1104, the CU determines to query the DU configuration for LTM, the process proceeds to block 1106. At block 1106, the CU sends a first CU-to-DU message including a reference LTM configuration query indication to the first DU (e.g., events 460, 488, 688, 888). Otherwise, if, at block 1104, the CU determines not to query the DU configuration for LTM, the process proceeds to block 1108. At block 1108, the CU sends a first CU-to-DU message including a GNB-DU configuration query IE to the first DU. The process proceeds from block 1106 or 1108 to block 1110. At block 1110, the CU receives a first DU-to-CU message including the first DU configuration from the first DU (e.g., events 460, 488, 688, 888). At block 1112, the CU sends a second CU-to-DU message including the first DU configuration to the second DU. At block 1114, the CU receives a second DU-to-CU message including the second DU configuration from the second DU. At block 1116, the CU sends the second DU configuration to the UE (e.g., events 494, 694, 617, 619, 894, 817, 819).

[0196] In some implementations, the second DU configuration is an incremental configuration that enhances the first DU configuration.

[0197] In some implementations, the first CU-to-DU message and the first DU-to-CU message may be a UE context modification request message and a UE context modification response message, respectively. In other implementations, the first CU-to-DU message and the first DU-to-CU message may be a UE context establishment request message and a UE context establishment response message, respectively. In some implementations, the second CU-to-DU message and the second DU-to-CU message may be a UE context modification request message and a UE context modification response message, respectively. In other implementations, the second CU-to-DU message and the second DU-to-CU message may be a UE context establishment request message and a UE context establishment response message, respectively.

[0198] Figure 11B is a flow chart of an example method 1100B that is similar to method 1100A, except that method 1100B includes block 1107 instead of block 1106. At block 1007, the CU sends a first CU-to-DU message including a GNB-DU Configuration Query IE and an LTM indication to the first DU.

[0199] Figure 12AAn example method 1200A is illustrated that a DU (eg, S-DU 174A or S-DU 174B of base station 104) may implement to configure LTM for a UE (eg, UE 102).

[0200] Method 1200A begins at block 1202, where the DU receives a CU-to-DU message from the CU (e.g., events 460, 488, 490, 493, 688, 690, 693, 888, 890, 893). At block 1204, the DU determines whether the CU-to-DU message includes a reference LTM configuration query indication. If, at block 1204, the DU determines that the CU-to-DU message includes a reference LTM configuration query indication, the flow proceeds to block 1206. At block 1206, the DU includes the reference LTM configuration in the DU-to-CU message (e.g., events 462, 488, 688, 888). At block 1208, the DU includes the first DU configuration in the DU-to-CU message. Otherwise, if, at block 1204, the DU determines that the CU-to-DU message does not include a reference LTM configuration query indication, the flow proceeds to block 1210. At block 1210 , the DU sends a DU-to-CU message to the CU (eg, events 490 , 493 , 690 , 693 , 890 , 893 ). Flow proceeds from blocks 1204 and 1208 to block 1210 .

[0201] In some implementations, the DU communicates with the UE based on the serving DU configuration, and the DU generates a first DU configuration to update the serving DU configuration. For example, the first DU configuration (e.g., CellGroupConfig IE) includes an L3 measurement configuration (e.g., MeasConfig IE), a measurement configuration for LTM, and / or a measurement configuration for CSI (e.g., CSI-MeasConfig). In some implementations, the CU sends the first DU configuration to the UE via the DU after receiving the first DU configuration from the UE.

[0202] Figure 12B 12 is a flow chart of an example method 1200B that is similar to method 1200A, except that method 1200B includes block 1207. Flow proceeds from blocks 1206 and 1204 to block 1207. At block 1207, the DU determines whether the CU-to-DU message includes a GNB-DU Configuration Query IE. If, at block 1207, the DU determines that the CU-to-DU message includes a GNB-DU Configuration Query IE, flow proceeds to block 1208. Otherwise, if, at block 1207, the DU determines that the CU-to-DU message does not include a GNB-DU Configuration Query IE, flow proceeds to block 1210.

[0203] Figure 13AAn example method 1300A is illustrated that a DU (e.g., S-DU 174A or S-DU 174B of base station 104) may implement to configure LTM for a UE (e.g., UE 102).

[0204] Method 1300A begins at block 1302, where the DU receives a CU-to-DU message from the CU that includes a GNB-DU Configuration Query IE (e.g., events 460, 488, 688, 888). At block 1304, the DU determines whether the CU-to-DU message includes an LTM indication. If, at block 1304, the DU determines that the CU-to-DU message includes an LTM indication, the flow proceeds to block 1306. At block 1306, the DU includes a reference LTM configuration in the DU-to-CU message (e.g., events 462, 488, 688, 888). Otherwise, if, at block 1304, the DU determines that the CU-to-DU message does not include an LTM indication, the flow proceeds to block 1308. At block 1308, the DU includes a first DU configuration in the DU-to-CU message. Flow proceeds from either 1306 or 1308 to block 1310. At block 1310, the DU sends a DU-to-CU message to the CU.

[0205] Figure 13B 1300B is a flow chart of an example method 1300B that is similar to method 1300A, except that method 1300B includes blocks 1303 and 1305 instead of blocks 1302 and 1304. At block 1303, the DU receives a CU-to-DU message from the CU that includes a query indication. At block 1305, the DU determines whether the query indication is a GNB-DU configuration query IE or a reference LTM configuration query indication. If, at block 1305, the DU determines that the query indication is a reference LTM configuration query indication, the flow proceeds to block 1306. Otherwise, if, at block 1305, the DU determines that the query indication is a GNB-DU configuration query IE, the flow proceeds to block 1308.

[0206] against Figure 12A The examples and implementations described can be applied to Figure 13A and Figure 13B .

[0207] Figure 14 An example method 1400 is illustrated that a CU (eg, CU 172 of base station 104 or 106) may implement for configuring LTM for a UE (eg, UE 102).

[0208] Method 1400 begins at block 1402, where a CU communicates with a UE via a first DU (e.g., events 402, 602, 802). At block 1403, the CU performs an LTM preparation process for the UE with the first DU (e.g., events 308, 310, 390, 380, 590, 580, 581, 582, 680, 681, 682, 790, 780, 781, 782, 880, 881, 882). At block 1404, the CU determines to utilize a second DU to prepare LTM for the UE. At block 1406, the CU determines whether the CU received a reference LTM configuration for the UE from the first DU. If, at block 1406, the CU determines that the CU received a reference LTM configuration for the UE from the first DU, the process proceeds to block 1408. At block 1408, the CU includes the reference LTM configuration in a CU-to-DU message (e.g., events 490, 480, 680, 690, 880, 890). Otherwise, if at block 1406, the CU determines that the CU does not receive a reference LTM configuration for the UE from the first DU, the flow proceeds to block 1410. At block 1410, the CU includes the serving DU configuration in the CU-to-DU message. Flow proceeds from block 1410 and from block 1408 to block 1412. At block 1412, the CU sends a CU-to-DU message to the second DU. At block 1414, the CU receives a DU-to-CU message including at least one LTM configuration from the second DU in response to the CU-to-DU message including the reference LTM configuration (e.g., events 490, 480, 680, 690, 880, 890). At block 1416 , the CU sends at least one LTM configuration (eg, events 494 , 694 , 617 , 619 , 894 , 817 , 819 ) to the UE via the first DU.

[0209] Figure 15A An example method 1500A is illustrated that a DU (eg, S-DU 174A or S-DU 174B of base station 104) may implement to configure LTM for a UE (eg, UE 102).

[0210] Method 1500A begins at block 1502, where a DU receives a CU-to-DU message from a CU requesting LTM preparation 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 1504, the DU determines whether the CU-to-DU message includes a reference LTM configuration. If, at block 1504, the DU determines that the CU-to-DU message includes a reference LTM configuration, the flow proceeds to block 1506. At block 1506, the DU generates at least one first LTM configuration based on the reference LTM configuration (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 1508, the DU sends a DU-to-CU message 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) including the at least one first LTM configuration.

[0211] Otherwise, if at block 1504 the DU determines that the CU-to-DU message does not include a reference LTM configuration, flow proceeds to block 1510. At block 1510, the DU generates at least one second LTM configuration based on the serving DU configuration (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 1512, the DU sends 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) to the CU including the second LTM configuration. In some implementations, the DU is a serving DU and uses the serving DU configuration to communicate with the UE. In other implementations, the DU is a non-serving DU and receives the serving DU configuration in the CU-to-DU message.

[0212] Figure 15B15 is a flow chart of an example method 1500B that is similar to method 1500A, except that method 1500B includes block 1509. Specifically, if at block 1504 the DU determines that the CU-to-DU message does not include a reference LTM configuration, the flow proceeds to block 1509. At block 1509, the DU determines whether the DU has a reference LTM configuration. If at block 1509 the DU determines that the DU has a reference LTM configuration, the flow proceeds to block 1506. Otherwise, if at block 1509 the DU determines that the DU does not have a reference LTM configuration, the flow proceeds to block 1510.

[0213] The following description may be applicable to the above description.

[0214] In general, the description of one of the figures above may apply to another of the figures above. The examples, implementations, and methods described above may be combined if not in conflict. The above-described events or blocks may be optional or omitted. For example, events or blocks with dashed lines in the figures may be optional. In some implementations, the term "message" may be used and "information element (IE)" may be substituted for "message," and vice versa. In some implementations, the term "IE" may be used and "field" may be substituted for "IE," and vice versa. In some implementations, the term "configuration" may be substituted for "configurations" or "configuration parameters," and vice versa. In some implementations, the term "LTM command" may be substituted for "serving cell change command," "layer 1 / layer 2 handover command," "lower layer handover command," or "lower layer serving cell change command." In some implementations, "some" means "one or more." In some implementations, the term "at least one" means "one or more." In some implementations, the term "cell group configuration" may be substituted for "DU configuration." In some implementations, "Cell Index" may be replaced with "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 with 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 CU-to-DU messages may be replaced with the different names listed above.

[0215] 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. Further, in some cases, the user device may be embedded in an electronic system such as a head unit or an advanced driver assistance system (ADAS) of a vehicle. Further, 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.

[0216] 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 particular manner. A hardware module can include dedicated circuitry or logic that is permanently configured to perform certain operations (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.). A hardware module can also include programmable logic or circuitry that is temporarily configured by software to perform certain operations (e.g., as contained within a general-purpose processor or other programmable processor). The decision to implement a hardware module with dedicated and permanently configured circuitry or with temporarily configured circuitry (e.g., configured by software) can be driven by cost and time considerations.

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

[0218] Upon reading this disclosure, those skilled in the art will appreciate 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, variations, and changes 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 centralized unit (CU) of a distributed base station, the method comprising: sending, from the CU to a distributed unit DU communicatively coupled to the CU, a request for a reference LTM configuration from the DU for generating a DU configuration for a user equipment UE; receiving, at the CU, the reference LTM configuration in response to sending the request; and The reference LTM configuration used to generate the DU configuration for the UE is sent from the CU.

2. The method of claim 1, wherein: The request includes a reference LTM query indication for the DU to generate the DU configuration including the reference LTM configuration.

3. The method of claim 2, wherein: The DU is a first DU; Receiving the reference LTM configuration includes receiving the reference LTM configuration from the first DU; and Sending the reference LTM configuration includes sending the reference LTM configuration to a second DU.

4. The method of claim 3, further comprising: The DU configuration is sent to the UE via the second DU.

5. The method according to claim 3 or 4, further comprising: The reference LTM configuration is sent to the UE via the second DU.

6. The method of claim 2, wherein: Receiving the reference LTM configuration includes receiving the reference LTM configuration from the DU; and Sending the reference LTM configuration includes sending the reference LTM configuration to the DU to cause the DU to generate the DU configuration.

7. The method of claim 1, wherein: Sending the request and receiving the reference LTM configuration occur in a first instance; and The method further comprises, in a second instance: sending a non-LTM DU configuration query from the CU to the DU; and A non-LTM DU configuration is received from the DU in response to sending the non-LTM DU configuration query.

8. A method implemented in a distributed unit (DU) of a distributed base station, the method comprising: receiving, at the DU from a centralized unit CU communicatively coupled to the DU, a request for a DU configuration from the DU; generating, at the DU in response to the request, a message based on whether the request from the CU requests reference to a lower layer triggered mobility (LTM) configuration; as well as The message is sent from the DU to the CU.

9. The method of claim 8, wherein: Generating the message includes generating the message including the reference LTM configuration when the request from the CU requests the reference LTM configuration.

10. The method according to claim 8 or 9, wherein: Generating the message includes generating the message that avoids including the reference LTM configuration when the request from the CU avoids requesting the reference LTM configuration.

11. The method according to any one of claims 8 to 10, wherein: Generating the message is further based on whether the request includes a non-LTM configuration query information element (IE).

12. The method of claim 11, wherein: Generating the message includes generating the message including a non-LTM DU configuration when the request includes the non-LTM configuration query IE.

13. The method according to claim 11 or 12, wherein: Generating the message includes generating the message to avoid including a non-LTM DU configuration when the request omits the non-LTM configuration query IE.

14. The method of any one of claims 8 to 13, wherein: When the request from the CU includes a reference LTM query indication, the request from the CU requests the reference LTM configuration.

15. A distributed base station comprising processing hardware and configured to implement the method according to any one of the preceding claims.

Images