Managing layer 3 (L3) mobility procedure related LTM configurations

Abstract

Embodiments include a method for a user equipment (UE) configured to perform a Layer 3 (L3) mobility procedure in a Radio Access Network (RAN). Such a method includes receiving, via a source cell in the RAN, a configuration of an inter-cell mobility (LTM) procedure for layer 1 or layer 2 triggering in the RAN. Such a method includes managing LTM configurations during preparation or execution of an L3 mobility procedure to a target cell in the RAN, including one or more of the following management operations: maintaining the LTM configuration, releasing the LTM configuration, modifying the LTM configuration, and adding a second LTM configuration. Other embodiments include supplemental methods for a RAN node configured to serve a source cell and a target cell, as well as UEs and RAN nodes configured to perform such methods.

Description

TECHNICAL FIELD

[0001] The present application relates generally to the field of wireless networks, and more specifically, to improving user equipment (UE) mobility across multiple cells in a wireless network based on managing UE configuration for layer 1 (LI) or layer 2 (L2) triggered inter-cell mobility (LTM) in conjunction with performing layer 3 (L3) mobility procedures. BACKGROUND

[0002] Currently, a fifth generation (5G) cellular system is being standardized in the Third Generation Partnership Project (3GPP). 5G is being developed for maximum flexibility to support a variety of use cases, including enhanced mobile broadband (eMBB), machine type communication (MTC), ultra-reliable low-latency communication (URLLC), sidelink device-to-device (D2D), and several other use cases. 5G was initially standardized in Release 15 (Rel-15) and continues to evolve in subsequent releases.

[0003] Figure 1 A high-level view of an exemplary 5G network architecture is shown, consisting of a Next Generation Radio Access Network (NG-RAN, 199) and a 5G Core (5GC, 198). The NG-RAN can include one or more gNodeBs (gNBs), such as gNBs (100, 150) connected to the 5GC via one or more NG interfaces, such as respective interfaces (102, 152). More specifically, a gNB can connect to one or more Access and Mobility Management Functions (AMFs) in the 5GC via respective NG-C interfaces, and to one or more User Plane Functions (UPFs) in the 5GC via respective NG-U interfaces. The 5GC can include various other network functions (NFs), such as Session Management Function(s) (SMF).

[0004] Although not shown, in some deployments the 5GC can be replaced by an Evolved Packet Core (EPC), which has conventionally been used with a Long Term Evolution (LTE) evolved UMTS RAN (E-UTRAN). In such deployments, a gNB (e.g., 100, 150) can connect to one or more Mobility Management Entities (MMEs) in the EPC 198 via respective S1-C interfaces. Similarly, a gNB can connect to one or more Serving Gateways (SGWs) in the EPC via respective NG-U interfaces.

[0005] In addition, gNBs can be connected to one another via one or more Xn interfaces, such as the Xn interface (140) between gNBs (100, 150). The radio technology used for the NG-RAN is often referred to as "New Radio" (NR). With respect to the NR interface to UEs, each of the gNBs can support frequency division duplex (FDD), time division duplex (TDD), or a combination thereof. Each of the gNBs can serve a geographic coverage area including one or more cells, and in some cases, can also provide coverage for a given cell using various directional beams. Generally speaking, a DL "beam" is a coverage area for a network-transmitted reference signal (RS) that can be measured or monitored by a UE.

[0006] An NG RAN logical node (e.g., gNB 100) can include a central unit (CU or gNB-CU, e.g., 110) and one or more distributed units (DU or gNB-DU, e.g., 120, 130). The CU is a logical node that hosts higher layer protocols and performs various gNB functions, such as controlling the operation of the DUs. The DUs are decentralized logical nodes that host lower layer protocols and can include various subsets of gNB functions depending on the functional split option. Each CU and DU can include various circuitry needed to perform their respective functions, including processing circuitry, communication interface circuitry (e.g., transceivers), and power supply circuitry.

[0007] The gNB-CU is connected to one or more gNB-DUs by respective Fl logical interfaces (e.g., 124 and 134 shown in FIG. 1). Figure 1 However, a gNB-DU can only be connected to a single gNB-CU. The gNB-CU and its connected gNB-DU(s) are only visible to other gNBs and the 5GC as a gNB. In other words, the Fl interface is not visible outside the gNB-CU.

[0008] Figure 2 An exemplary configuration of NR user plane (UP) and control plane (CP) protocol stacks between a UE (210), a gNB (220), and an AMF (230) is shown. The physical layer (PHY), medium access control layer (MAC), radio link control layer (RLC), and packet data convergence protocol layer (PDCP) between the UE and the gNB are common to both UP and CP. PDCP provides ciphering / deciphering, integrity protection, sequence numbering, reordering, and duplication detection for both CP and UP, as well as header compression and retransmission for UP data.

[0009] On the UP side, Internet Protocol (IP) packets arrive at the PDCP as Service Data Units (SDUs), and the PDCP creates Protocol Data Units (PDUs) for delivery to the RLC. The Service Data Adaptation Protocol (SDAP) layer handles Quality of Service (QoS), including mapping between QoS flows and Data Radio Bearers (DRBs), and marking QoS Flow Identifiers (QFIs) in UL and DL packets. The RLC passes the PDCP PDUs to the MAC via the Logical Channel (LCH). The RLC provides error detection / correction, concatenation, segmentation / reassembly, sequence numbering, and reordering of data passed to / from higher layers. The MAC provides mapping between the LCH and the PHY transport channel, LCH prioritization, multiplexing into or demultiplexing from transport blocks (TBs), Hybrid ARQ (HARQ) error correction, and dynamic scheduling (in gNBs). The PHY provides transport channel services to the MAC and handles transmissions over the NR radio interface, for example, via modulation, decoding, antenna mapping, and beamforming.

[0010] On the CP side, the Non-Access Stratum (NAS) between the UE and AMF handles UE / gNB authentication, mobility management, and security control. Within the UE, the RRC resides below the NAS but terminates at the gNB, not the AMF. The RRC controls communication between the UE and gNB at the radio interface, as well as the UE's mobility between cells in the NG-RAN. The RRC also broadcasts System Information (SI) and performs the establishment, configuration, maintenance, and release of DRBs and Signaling Radio Bearers (SRBs) for use by the UE. Additionally, the RRC controls the addition, modification, and release of carrier aggregation (CA) and dual connectivity (DC) configurations for the UE and performs various security functions such as key management.

[0011] After the UE is powered on, it will be in the RRC_IDLE state until an RRC connection is established with the network, at which point the UE will transition to the RRC_CONNECTED state (e.g., where data transfer can occur). The UE must execute a random access (RA) procedure to move from the RRC_IDLE state to the RRC_CONNECTED state, where the cell serving the UE is known and an RRC context is established for the UE in the serving gNB, so that the UE and the gNB can communicate.

[0012] Long Term Evolution (LTE) Rel-10 introduced support for channel bandwidths greater than 20 MHz, a feature carried over to NR. To maintain compatibility with legacy UEs from earlier versions (e.g., Rel-8), wideband LTE Rel-10 carriers are presented as multiple component carriers (CCs), each with a Rel-8 carrier structure. Rel-10 UEs can receive multiple CCs based on carrier aggregation (CA). A CC can be considered a "cell," allowing a UE in a CA to have a primary cell (PCell) and one or more secondary cells (SCells). These are collectively referred to as a "cell group." Starting with Rel-15, NR also supports CA.

[0013] As specified in 3GPP document RP-213565, NR Rel-18 includes work items related to NR mobility enhancements, including the technical field of L1 / L2-based inter-cell mobility (also known as L1 / L2-triggered mobility (LTM)). When a UE moves between the coverage areas of two cells, a serving cell change needs to be performed at some point. Currently, serving cell changes are triggered by Layer 3 (L3, e.g., RRC) measurements and involve RRC signaling to change the PCell and PSCell (e.g., when dual connectivity is configured), and to release / add SCells (e.g., when CA is configured).

[0014] Currently, all inter-cell mobility involves a complete Layer 2 (L2) and Layer 1 (L1, i.e., PHY) reset, resulting in longer latency, increased signaling overhead, and longer outages compared to intra-cell beam switching. Therefore, the goal of Rel-18 L1 / L2 Mobility Enhancement is to facilitate serving cell changes via L1 / L2 signaling to address these issues and / or difficulties. Summary of the Invention

[0015] According to the 3GPP protocol, when a UE is configured with an LTM candidate cell, the UE can also execute any L3 handover command sent by the network. 3GPP also agrees that the RAN will handle any race conditions (or conflicts) between LTM cell handover procedures and L3 mobility procedures (e.g., handover). However, it is unclear how the UE's LTM candidate cell configuration is handled during L3 mobility procedures. Furthermore, it is unclear whether L3 mobility procedures are affected by any LTM-related procedures other than LTM cell handover.

[0016] The purpose of embodiments of this disclosure is to address these and related problems, issues and / or difficulties, thereby facilitating UE L1 / L2 mobility between cells in a RAN (e.g., NG-RAN).

[0017] Some embodiments of this disclosure include methods (e.g., procedures) for a UE configured to execute a Layer 3 (L3) mobility procedure in the RAN.

[0018] These exemplary methods include receiving configuration for LTM procedures in the RAN via a source cell in the RAN. These exemplary methods also include managing the LTM configuration during the preparation or execution of L3 mobility procedures to a target cell in the RAN. This includes one or more of the following management operations: • Maintain the LTM configuration; • Release the LTM configuration; • Modify the LTM configuration; and • Add a second LTM configuration.

[0019] In some embodiments, when the target cell is provided by a different RAN node than the source cell, the release LTM configuration is performed, while when the target cell is provided by the same RAN node as the source cell, the maintain LTM configuration is performed.

[0020] In some embodiments, these exemplary methods further include receiving an indication from the RAN of one or more management operations to be performed. In such cases, the LTM configuration is managed based on this indication. In some of these embodiments, the indication is received in an L3 mobility command (e.g., a handover command).

[0021] In some embodiments, the exemplary method further includes sending an acknowledgment or response to the RAN (e.g., to the source or target RAN node, as appropriate) that the instructed management operation has been performed.

[0022] Other embodiments include methods (e.g., procedures) for a RAN node of a source cell configured to provide UE L3 mobility protocols. Generally, these exemplary methods complement the exemplary methods for UEs summarized above.

[0023] These exemplary methods may include sending configuration for LTM procedures in the RAN to the UE via the source cell. These exemplary methods may also include releasing at least a portion of the LTM configuration during the preparation or execution of L3 mobility procedures from the UE to the target cell in the RAN.

[0024] In some embodiments, at least a portion of the release of the LTM configuration is performed based on the target cell of the L3 mobility protocol provided by another RAN node.

[0025] In some embodiments, these exemplary methods further include sending an indication to the UE to release at least a portion of the LTM configuration. In some of these embodiments, the indication is sent in an L3 mobility command (e.g., a handover command). In some of these embodiments, these exemplary methods further include receiving from the UE an acknowledgment or response that the indicated management operation has been performed.

[0026] In some embodiments, these exemplary methods further include sending a request to a target RAN node providing the target cell to execute the UE's L3 mobility protocol; and receiving from the target RAN node the following: the configuration of the UE's L3 mobility protocol, and an indication to release at least a portion of the LTM configuration. In such cases, releasing at least a portion of the LTM configuration is in response to the received indication.

[0027] Other embodiments include methods (e.g., procedures) for a RAN node of a target cell configured to provide UE L3 mobility protocols.

[0028] These exemplary methods can include managing the configuration of LTM procedures for the UE from the source cell in the RAN during the preparation or execution of L3 mobility procedures from the UE to the target cell. This includes one or more of the following management operations: • Maintain the LTM configuration; • Release the LTM configuration; • Modify the LTM configuration; and • Add a second LTM configuration.

[0029] In some embodiments, when the source cell is provided by another RAN node, the LTM configuration is released, while when the source cell is provided by a RAN node, the LTM configuration is maintained.

[0030] In some embodiments, these exemplary methods may further include sending an indication to the UE of one or more corresponding management operations to be performed by the UE on the LTM configuration. For example, the indication may be sent to the UE in an L3 mobility command (e.g., a handover command). In some of these embodiments, these exemplary methods may also include receiving from the UE an acknowledgment or response that the corresponding management operation has been performed.

[0031] In some embodiments, these exemplary methods may further include receiving a request from the source RAN node providing the source cell to execute the UE's L3 mobility procedure; and sending the following to the source RAN node: the configuration of the UE's L3 mobility procedure, and an indication to release at least a portion of the LTM configuration.

[0032] In various embodiments, the L3 mobility procedure can be any of the following: handover, reconfiguration with synchronization, conditional handover, conditional reconfiguration, primary SCG cell (PSCell) change, conditional PSCell change, conditional PSCell addition, secondary node (SN) change, SN modification, and primary node (MN) change.

[0033] Other embodiments include UEs and RAN nodes configured to perform operations corresponding to any of the exemplary methods described herein. Other embodiments also include a non-transitory computer-readable medium storing computer-executable instructions that, when executed by processing circuitry, configure such UEs and RAN nodes to perform operations corresponding to any of the exemplary methods described herein.

[0034] The embodiments described herein and others facilitate proper operation of L3 mobility when LTM is also configured for the UE, by releasing LTM configurations that are inapplicable after L3 mobility procedures, such as LTM configurations(one or more) within a CU that are inapplicable after inter-CU L3 mobility procedures. The embodiments also facilitate LTM configuration for the UE during L3 mobility procedure configuration or execution, such as a target RAN node providing LTM(one or more) configurations(one or more) applicable after the UE completes the L3 mobility procedure. Furthermore, the embodiments can improve UE mobility in the RAN (e.g., NG-RAN) by promoting interoperability between L3 mobility and LTM.

[0035] These and other objects, features, and advantages of this disclosure will become apparent from the accompanying drawings, which are briefly described below, and from the following detailed description. Attached Figure Description

[0036] Figure 1 This shows a high-level view of an exemplary 5G network architecture.

[0037] Figure 2 An exemplary configuration of the NR UP and CP protocol stack is shown.

[0038] Figures 3-4 Showing the use of in Figure 1 The logical architecture of the gNB arranged in the CU / DU (or split gNB) architecture shown.

[0039] Figure 5 The signaling flow for the L3 mobility protocol between DUs / within CUs for the UE is shown.

[0040] Figure 6 Example RANs are shown that can implement various embodiments of this disclosure.

[0041] Figures 7 to 9 and Figures 10A to 10B The diagram illustrates signaling diagrams for various L3 mobility procedures according to various embodiments of the present disclosure, during which the LTM configuration of the UE is managed by various entities.

[0042] Figure 11 Exemplary methods (e.g., procedures) for a UE are shown according to various embodiments of this disclosure.

[0043] Figure 12 Exemplary methods (e.g., procedures) for source RAN nodes are illustrated according to various embodiments of this disclosure.

[0044] Figure 13 Exemplary methods (e.g., procedures) for a target RAN node are illustrated according to various embodiments of this disclosure.

[0045] Figure 14 Communication systems according to various embodiments of the present disclosure are shown.

[0046] Figure 15 The UE is shown according to various embodiments of the present disclosure.

[0047] Figure 16 Network nodes according to various embodiments of this disclosure are shown.

[0048] Figure 17 A host computing system according to various embodiments of the present disclosure is shown.

[0049] Figure 18 This is a block diagram of a virtualized environment in which the functionality implemented by some embodiments of the present disclosure can be virtualized.

[0050] Figure 19 The present disclosure illustrates various embodiments of communication between a host computing system, a network node, and a UE via multiple connections, at least one of which is wireless. Detailed Implementation

[0051] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. However, other embodiments are included within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided as examples to convey the scope of the subject matter to those skilled in the art.

[0052] Generally, all terms used herein shall be interpreted according to their common meaning to those skilled in the art, unless a different meaning is expressly defined and / or implied from the context of use. All references to "a / an / element, device, component, means, step, etc." shall be construed as referring to at least one instance of that element, device, component, means, step, etc., unless otherwise expressly stated or clearly implied from the context of use. Operation of any methods and / or procedures disclosed herein need not be performed in the exact order disclosed, unless one operation is explicitly described as occurring after or before another, and / or it is implied that one operation must occur after or before another. Any feature of any embodiment disclosed herein may be applied to any other disclosed embodiment, as appropriate. Similarly, any advantage of any embodiment described herein may be applied to any other disclosed embodiment, as appropriate.

[0053] In addition, the following terms are used throughout the description given below: • Radio Access Node: As used herein, a “radio access node” (or equivalently a “radio network node,” “radio access network node,” or “RAN node”) can be any node operating in a radio access network (RAN) to wirelessly transmit and / or receive signals. Some examples of radio access nodes include, but are not limited to: base stations (e.g., gNBs in 3GPP 5G / NR networks or enhanced or eNBs in 3GPP LTE networks), base station distributed components (e.g., CUs and DUs), high-power or macro base stations, low-power base stations (e.g., micro, pico, femto, or femto base stations), integrated access backhaul (IAB) nodes, transport points (TPs), transport receiver points (TRPs), remote radio units (RRUs or RRHs), and relay nodes.

[0054] • Core Network Node: As used in this document, a “core network node” is any type of node in the core network. Some examples of core network nodes include, for example, Mobility Management Entity (MME), Serving Gateway (SGW), PDN Gateway (P-GW), Policy and Charging Rules Function (PCRF), Access and Mobility Management Function (AMF), Session Management Function (SMF), User Plane Function (UPF), Charging Function (CHF), Policy Control Function (PCF), Authentication Server Function (AUSF), Location Management Function (LMF), and so on.

[0055] • Wireless Device: As used herein, a “wireless device” (or “WD” for short) is any type of device capable of, configured to, arranged to, and / or operable to wirelessly communicate with network nodes and / or other wireless devices. Wireless communication can involve transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information through the air. Unless otherwise indicated, the term “wireless device” may be used interchangeably herein with the term “user equipment” (or “UE” for short), which have different meanings from the term “network node”.

[0056] • Radio node: As used herein, “radio node” can be a “radio access node” (or equivalent term) or a “wireless device”.

[0057] • Network Node: As used herein, a “network node” is any node that is part of a radio access network (e.g., a radio access node or an equivalent term) or part of the core network of a cellular communication network (e.g., a core network node discussed above). Functionally, a network node is a device that is capable of, configured to, arranged to, and / or operable to communicate directly or indirectly with a wireless device and / or with other network nodes or devices in the cellular communication network to enable and / or provide wireless access to the wireless device, and / or perform other functions (e.g., control) in the cellular communication network.

[0058] • Node: As used herein, the term “node” (without prefix) can be any type of node that is in or with a wireless network (including RAN and / or core network), including radio access nodes (or equivalent terms), core network nodes, or wireless devices. However, the term “node” may be limited to a particular type (e.g., radio access node, IAB node) based on its specific characteristics in any given context.

[0059] The above definitions are not intended to be exclusive. In other words, the same or similar technical terms may be used elsewhere in this disclosure to describe and / or illustrate various terms mentioned above. However, in the event of any conflict between such other descriptions and / or illustrations and the above definitions, the above definitions shall prevail.

[0060] Note that the descriptions presented herein focus on 3GPP cellular communication systems, and 3GPP technical terms or similar technical terms are frequently used. However, the concepts disclosed herein are not limited to 3GPP systems, but can be applied to any communication system from which one can benefit.

[0061] Figure 3 This illustrates a gNB (such as) arranged in a CU / DU (or split gNB) architecture.Figure 1 The logical architecture of gNB 100 (in the context of the CU) divides the CU into CP and UP functionalities, referred to as CU-C and CU-U respectively. Furthermore, each of the NG, Xn, and F1 interfaces is split into a CP interface (e.g., NG-C) and a UP interface (e.g., NG-U). Note that... Figure 3 The terms "central entity" and "distributed entity" refer to physical network nodes.

[0062] Figure 4 Another exemplary gNB logical architecture is shown, comprising two gNB-DUs, one gNB-CU-CP, and multiple gNB-CU-UPs. The gNB-CU-CP can be connected to the gNB-DU via an F1-C interface, while the gNB-CU-UP can be connected to the gNB-DU via an F1-U interface and to the gNB-CU-CP via an E1 interface. Each gNB-DU can only be connected to one gNB-CU-CP, and each gNB-CU-UP can only be connected to one gNB-CU-CP. A gNB-DU can be connected to multiple gNB-CU-UPs under the control of the same gNB-CU-CP. Furthermore, a gNB-CU-UP can be connected to multiple DUs under the control of the same gNB-CU-CP. When this document refers to operations performed by a “CU,” it should be understood that such operations can be performed by any entity within the CU (e.g., CU-CP, gNB-CU-CP) unless otherwise stated.

[0063] When a UE moves between the coverage areas of two cells, a serving cell change needs to be performed at some point. Currently, serving cell changes are triggered by Layer 3 (L3, e.g., RRC) measurements and involve RRC signaling to change the PCell and / or PSCell (e.g., when dual connectivity is configured), and to release / add SCells (e.g., when CA is configured).

[0064] A UE in the RRC_CONNECTED state can be configured to perform measurements of its serving cell(s) and neighboring cells(s) and report them to its serving RAN node. When the reported measurements meet specific conditions or thresholds, the serving RAN node can send a handover command to the UE, indicating the target cell for the handover. In NR, the handover command is an RRCReconfiguration message with the reconfigurationWithSync field. The handover procedure is sometimes referred to as "L3 mobility" because it is controlled by Layer 3 (L3, i.e., RRC), and the exchanged messages are part of L3.

[0065] These reconfigurations are actually prepared in advance by the target RAN node serving the target cell based on a request from the UE's serving RAN node. If both the serving and target RAN nodes are part of NG-RAN, this request is transmitted via the Xn interface. The reconfiguration in the handover command takes into account the UE's existing RRC configuration in its current serving cell (also known as the "source cell"), which is provided in the inter-node request. In some cases, the reconfiguration can be provided as an "increment" of the UE's existing configuration in the source cell, which reduces the size of the handover command.

[0066] The reconfiguration provided by the target RAN node contains all the information required for the UE to access the target cell, such as the random access configuration, the new cell radio network temporary identifier (C-RNTI) assigned to the UE in the target cell, and parameters that enable the UE to calculate the security key it can use when communicating with the target cell (including sending handover completion messages).

[0067] Generally speaking, UE mobility in the RRC_CONNECTED state is network-based because the network has the most information about the current conditions, such as cell load (UE and / or services), available node resources (e.g., processing), available frequencies, etc.

[0068] The UE uses the provided C-RNTI, which begins in message 3 of the random access to the target cell, allowing the target RAN node to identify the UE without context extraction (unless a failure occurs). Furthermore, because the UE receives the target cell random access configuration during reconfiguration, the UE does not need to obtain this information from the SI before handover.

[0069] In some cases, random access configuration may include dedicated, contention-free random access (CFRA) resources that the UE uses in message 1 for random access to the target cell. In this case, the target identifies the UE from the preamble (MSG.1). In this way, dedicated CFRA resources optimize the random access procedure.

[0070] In a CU / DU (or split gNB) architecture, some handovers may involve cell changes between DUs / within a CU, where the UE’s source and target cells are served by different source and target DUs associated with a single CU. Figure 5 The signaling flow for inter-DU / intra-CU mobility procedures for the UE (510) is shown, where the source DU (520) and the target DU (530) are associated with the same CU (540), i.e., part of a single RAN node (550), such as a gNB. Although Figure 5 The operations shown are given numerical labels, but this is done for illustrative purposes and not to require or imply any particular order of operations, unless otherwise explicitly stated.

[0071] In operation 1, the UE sends a MeasurementReport message to the source DU. In operation 2, the source DU sends an "ULRRC Messaging" message to the CU to convey the received MeasurementReport message. In operation 2a (optional), the CU may send a "UE Context Modification Request" message to the source DU to query the latest configuration. In operation 2b, the source DU responds with a "UE Context Modification Response" message including full configuration information.

[0072] In operation 3, the CU sends a "UE Context Setup Request" message to the target DU to create a UE context and set up one or more data bearers. The "UE Context Setup Request" message includes HandoverPreparationInformation. In operation 4, the target DU responds to the CU with a "UE Context Setup Response" message.

[0073] In operation 5, the CU sends a "UE Context Modification Request" message to the source DU, which includes the generated RRCReconfiguration message and instructs the CU to stop data transmission to the UE. The source DU also sends a downlink data delivery status frame to notify the CU of the failure to successfully transmit downlink data to the UE. In operation 6, the source DU forwards the received RRCReconfiguration message to the UE. In operation 7, the source DU responds to the CU with a "UE Context Modification Response" message.

[0074] In operation 8, the UE executes the random access procedure performed at the target DU. The target DU sends a downlink data delivery status frame to notify the CU. Downlink packets are sent from the CU to the target DU, which may include PDCP PDUs that were not successfully delivered in the source DU. Whether DL user data transmission to the DU begins before or after receiving the downlink data delivery status frame depends on the CU implementation.

[0075] In operation 9, the UE responds to the target DU with an RRCReconfigurationComplete message. In operation 10, the target DU sends a "UL RRC Message Transmission" message to the CU to convey the received RRCReconfigurationComplete message. Downlink packets are sent to the UE. Additionally, uplink packets are sent from the UE, and these packets are forwarded to the CU via the target DU. In operation 11, the CU sends a "UE Context Release Command" message to the source DU. In operation 12, the source DU releases the UE context.

[0076] like Figure 5As shown, the execution of L3 mobility is triggered by the source DU transmitting an RRCReconfiguration message (Operation 6) generated by and received from the CU during the preparation phase to the UE. This message is based on the CU requesting the target DU to set the UE context and providing the CU with the target cell configuration (e.g., CellGroupConfig). Therefore, when the target DU receives the "UE context setting request" (Operation 3), it knows that the UE will arrive at the target cell shortly after it receives the RRCReconfiguration from the CU via the source DU, so that any target cell resources reserved for the incoming UE will be used quickly.

[0077] As specified in 3GPP document RP-213565, 3GPP Rel-18 includes work items on NR mobility enhancements, including the technical field of L1 / L2-based inter-cell mobility (also known as L1 / L2-triggered mobility (LTM)). Conventionally, all inter-cell mobility operations are triggered by L3 RSRP measurements and involve a complete Layer 2 (L2) and Layer 1 (L1, i.e., PHY) reset, resulting in longer latency, increased signaling overhead, and longer outages than those used for intra-cell beam switching. Therefore, the high-level objective of Rel-18 L1 / L2 mobility enhancements is to facilitate serving cell changes via L1 / L2 signaling to address these issues and / or difficulties. Some more specific objectives include specifying the following: • Configuration and maintenance of multiple candidate cells to allow for rapid application of candidate cell configurations; • A dynamic handover mechanism between candidate serving cells (including SpCell and SCell) based on L1 / L2 signaling for potential applicable scenarios; • L1 enhancements for inter-cell beam management, including L1 measurement and reporting, and beam indication; • Scheduled advance management; and • CU-DU interface signaling to support L1 / L2 mobility, if needed.

[0078] These Rel-18 L1 / L2 mobility enhancements must also be considered Figure 1 and Figures 3 to 4 The illustrated CU / DU (or split gNB) architecture includes intra-DU and inter-DU / intra-CU cell changes. In the inter-DU / intra-CU scenario, the candidate cell for LTM is the cell served by the neighboring DU of the (serving or source) DU of the PCell (or PSCell, used for SCG changes in DC) currently providing the UE.

[0079] In LTM, the UE is pre-configured by its serving RAN with an RRC configuration for each LTM candidate cell, sometimes referred to as the "LTM candidate cell configuration". This configuration can be an RRCReconfiguration message or a part thereof, such as one or more IEs / fields / parameters (e.g., CellGroupConfig IE). The UE performs measurements on these LTM candidate cells and transmits the corresponding measurement reports to the RAN, which triggers an LTM cell handover procedure executed by the UE to one of the LTM candidate cells. This triggering is accomplished by transmitting an LTM cell handover command to the UE in lower-layer signaling (e.g., MAC control element (CE)). Based on this command, the UE connects to the associated LTM candidate cell and uses the previously received RRC configuration for this LTM candidate cell.

[0080] Since one of the goals of LTM is to reduce UE data transmission downtime, the UE needs to be ready to communicate with the target cell as soon as it receives L1 / L2 signaling for mobility execution from the source cell (or shortly thereafter). For example, the UE must be able to transmit UL data or scheduling requests (SRs) to the target cell and / or monitor the DL control channel (e.g., PDCCH) from the target cell. In other words, the UE needs to know the cell it is moving to so that it can apply the appropriate configuration, including the correct timing alignment and / or Transport Configuration Indicator (TCI) status of that cell. Similarly, when the source DU transmits L1 / L2 signaling for mobility execution, the target DU needs to be ready to schedule UL and DL transmissions for the UE in the target cell, and to receive scheduling requests (SRs) from the UE.

[0081] To further reduce downtime and latency during LTM execution, the UE can perform early UL and DL synchronization with the LTM candidate cell before receiving the LTM cell handover command. For early UL synchronization, the UE obtains a timing advance (TA) value. This can be triggered by the network transmitting a PDCCH command to the UE in the source cell, after which the UE transmits a random access (RA) preamble in the LTM candidate cell indicated by the received PDCCH command. The TA value for the LTM candidate cell can be provided to the UE by the network before LTM execution. For example, the TA value can be included in the RAR (Random Access Response) in the RA preamble, a MAC control element (CE) similar to the RAR, or in the LTM cell handover command.

[0082] 3GPP has agreed on the following principles for LTM in Rel-18: • LTM does not support security updates in Rel-18.

[0083] • RAN2 confirms that CellGroupConfig IE is required (mandatory) within the LTM candidate cell configuration.

[0084] • RadioBearerConfig IE can be optionally supported in LTM candidate configurations.

[0085] • MeasConfig IE can be optionally supported in LTM candidate configurations.

[0086] • OtherConfig IE does not need to be part of the LTM candidate cell configuration.

[0087] • LTM candidate cell configurations should be designed as an "add / modify / release" structure.

[0088] • The LTM candidate cell configuration ASN.1 data structure includes at least a CellGroupConfig IE and a configuration ID.

[0089] • 3GPP also agreed on the following principles for LTM “incremental” configurations in Rel-18: • The UE stores the LTM reference configuration as a separate configuration.

[0090] • The LTM reference configuration is managed separately.

[0091] • Use “Model 1”, that is, one RRCReconfiguration message for each candidate target configuration for LTM candidate cells.

[0092] • When an LTM candidate cell is configured, the UE can also execute any L3 handover command sent by the network. The network should avoid any race conditions between LTM execution and L3 handover commands, such as avoiding sending LTM cell handover commands and L3 handover commands in the same transport block (TB).

[0093] • The RRCReconfigurationComplete message is always sent after each LTM execution.

[0094] According to these 3GPP protocols, when a UE is configured with an LTM candidate cell, the UE can also execute any L3 handover command sent by the RAN, where the RAN is responsible for handling any race conditions (or conflicts) between the LTM cell handover procedure and the L3 mobility procedure (e.g., handover). However, it is unclear how the UE's LTM candidate cell configuration is handled during the L3 mobility procedure. Furthermore, it is unclear whether the L3 mobility procedure is affected by any LTM-related procedures other than LTM cell handover.

[0095] Embodiments of this disclosure address these and other problems, difficulties, and / or issues by providing flexible and efficient techniques for managing LTM configurations in conjunction with the UE's L3 mobility procedures, such as maintaining, releasing, modifying, or adding one or more LTM configurations, or a portion thereof. Exemplary L3 mobility procedures include handover, reconfiguration with synchronization, PSCell change, and conditional mobility procedures such as Conditional Handover (CHO), Conditional PSCell Change (CPC), and Conditional PSCell Addition (CPA).

[0096] Some embodiments include methods for a UE to manage one or more LTM configurations when executing L3 mobility procedures, such as by retaining, releasing, modifying, or adding one or more LTM configurations. Other embodiments include methods for a source RAN node to manage one or more LTM configurations of a UE when executing L3 mobility procedures, such as by retaining, releasing, modifying, or adding one or more LTM configurations. Still other embodiments include methods for a target RAN node to manage one or more LTM configurations of a UE when executing L3 mobility procedures, such as by retaining, releasing, modifying, or adding one or more LTM configurations.

[0097] The embodiments of this disclosure are particularly applicable when L3 mobility procedures involve cells served by different gNBs, which may be referred to as inter-CU L3 mobility. Since Rel-18 only supports intra-CU (including inter-DU and intra-DU) LTM, there are situations where a UE's existing intra-CU LTM configuration needs to be managed in some way related to the inter-CU L3 mobility procedure for the UE / to-UE. For example, a UE's (one or more) existing LTM candidate cell configurations may not be applicable to the target RAN node (or target CU) because they involve cells served by DUs associated with different CUs. Since LTM procedures to these cells are not possible when the UE is served by the target RAN node, either the source RAN node (before the L3 mobility procedure) or the target RAN node (after the L3 mobility procedure) may initiate the release of at least a portion of the UE's (one or more) LTM configurations, such as the inapplicable LTM candidate cell configurations.

[0098] In some embodiments, when the source RAN node decides to execute an L3 mobility procedure, it releases at least a portion of one or more LTM configurations and then (i.e., after the release has been executed) requests the target RAN node to prepare an L3 mobility procedure (e.g., a handover).

[0099] In other embodiments, the source RAN node requests the target RAN node to prepare the UE's L3 mobility protocol, and the target RAN node determines that at least a portion of the UE's LTM configuration should be released. The target RAN node includes an indication in its L3 mobility command (e.g., an RRCReconfiguration message) for the UE to release at least a portion of its LTM configuration. The target RAN node may also indicate to the source RAN node (e.g., in a response to a request) that at least a portion of the UE's LTM configuration should be released.

[0100] In other embodiments, the source RAN node requests the target RAN node to prepare the L3 mobility procedure for the UE, and the target RAN node determines that one or more LTM configurations (e.g., LTM candidate cell configurations) need to be added for the UE. The target RAN node includes an indication for adding one or more LTM configurations for the UE in the L3 mobility command (e.g., an RRCReconfiguration message).

[0101] In some embodiments, one or more LTM configurations of the UE are managed during the configuration or execution of a conditional reconfiguration such as a CHO, CPC, or CPA. For example, during a conditional reconfiguration, the UE can maintain, release, modify, or add one or more LTM configurations. As another example, the source RAN node determines that at least a portion of the UE's LTM configurations should be released during the configuration of a conditional reconfiguration (e.g., a CHO command) for the UE. In one embodiment, the target RAN node determines that one or more LTM configurations are maintained, released, modified, or added during the configuration of a conditional reconfiguration (e.g., a CHO command) for the UE.

[0102] Implementations can provide various benefits and / or advantages. For example, implementations can facilitate proper operation of L3 mobility when LTM is also configured for the UE by releasing LTM configurations that are not applicable after L3 mobility procedures, such as LTM configurations (one or more) within a CU that are not applicable after inter-CU L3 mobility procedures. Implementations can also facilitate LTM configuration for the UE during L3 mobility procedure configuration or execution, such as a target RAN node providing LTM configurations (one or more) applicable after the UE completes the L3 mobility procedure. Furthermore, implementations can improve mobility in the RAN (e.g., NG-RAN) by promoting L3 mobility and LTM interoperability.

[0103] In this disclosure, the following terms are used interchangeably: “L1 / L2-based inter-cell mobility,” “L1 / L2 mobility,” “L1 mobility,” “L1-based mobility,” “L1 / L2-centric inter-cell mobility,” “L1 / L2 inter-cell mobility,” “inter-cell beam management,” “inter-DU L1 / L2-based inter-cell mobility,” and “L1 / L2-triggered mobility” (or LTM). These terms refer to scenarios where a UE receives lower-layer (i.e., below RRC, such as MAC or PHY) signaling from the network, instructing the UE to change its serving cell (e.g., PCell) from a source cell to a target cell. The content of the lower-layer signaling may be referred to as an “LTM cell handover command.” Exemplary lower-layer signaling includes L1 DL control information (DCI) and L2 MAC control elements (CE). Compared to conventional RRC signaling, lower-layer signaling reduces processing time and downtime during mobility and also increases mobility robustness because the network can respond more quickly to changes in UE channel conditions.

[0104] A change in the serving cell (e.g., PCell) may also result in a change in one or more SCells within the same cell group, for example, if a command triggers the UE to change to another cell group configuration of the same type (e.g., another MCG configuration). For instance, LTM cell handover may include changes in SpCells (e.g., pCell for MCG, PSCell for SCG) and changes in SCells within the same cell group (e.g., addition, modification, and / or release).

[0105] In this disclosure, the following terms are used interchangeably with respect to L1 / L2 inter-cell mobility: “neighbor DU”, “non-service DU”, “candidate DU”, and “destination DU”. Similarly, the terms “service DU” and “source DU” are used interchangeably with respect to L1 / L2 inter-cell mobility.

[0106] Before the UE receives the LTM cell handover command, the UE is configured by the network with one or more "LTM candidate cell configurations" via the RRCReconfiguration message. The terms "(LTM) candidate configuration", "LTM configuration", "(LTM) candidate target cell configuration" and "(LTM) target candidate (cell) configuration" are used interchangeably with LTM candidate cell configuration.

[0107] LTM candidate cell configurations can be included in RRC IEs, such as CellGroupConfig, SpCellConfig, or SCellConfig, and / or in embedded RRCReconfiguration messages for LTM candidate cells. LTM candidate cell configurations include configuration parameters that the UE needs to operate in the LTM candidate cell when executing LTM cell handover procedures, such as upon receiving an LTM cell handover command. As some more specific examples, LTM candidate cell configurations can include the PCell configuration of the MCG and one or more SCell configurations, or the PSCell configuration of the SCG and one or more SCell configurations. The exact content and / or structure of the IEs and / or embedded messages for LTM candidate cell configurations may be referred to as an "RRC model for candidate configuration" or more simply as an "RRC model".

[0108] The UE can receive the LTM candidate cell configuration either in its complete form or as an incremental (or differential) configuration relative to a reference configuration (which can be signaled separately). In the latter case, the actual LTM candidate configuration is a combination of the incremental and reference configurations.

[0109] Lower-layer signaling from the RAN may include an identifier (or index) associated with the LTM candidate cell configuration. This identifier may be sent along with an LTM cell handover command, instructing the UE to perform an LTM cell handover to the associated LTM candidate cell.

[0110] The term "LTM configuration" refers to a data structure used for or relating to UE LTM operations, and includes one or more of the following elements: • One or more LTM candidate cells are configured, i.e., for the corresponding LTM candidate cells; • Measurement configurations for LTM, such as L1 measurement and reporting configurations for LTM candidate cells; • Configuration for DL ​​pre-synchronization of LTM, for example, for early TCI state activation; • Configuration for UL pre-synchronization for LTM, such as for receiving PDCCH ordered preamble transmission and receiving TA; • Configuration for executing LTM cell handover procedures based on a given LTM candidate cell configuration (e.g., whether to perform RA, RLC reconstruction, MAC reset, PDCP recovery, etc.).

[0111] The term “part of LTM configuration” may refer to a subset of the elements in the list above, and / or include a subset of any existing elements (e.g., a subset of the configuration used for DL ​​pre-synchronization).

[0112] The phrase "LTM cell handover procedure" refers to the process by which a UE uses LTM to hand over (or change) its cell from a source cell to a target cell (i.e., an LTM candidate cell). The LTM cell handover procedure can also be referred to as "L1 / L2-based inter-cell mobility execution," "LTM execution," "dynamic handover," "LTM handover," "(LTM) cell handover," "(LTM) serving cell change," or "(LTM) cell change." Similarly, the phrase "switching to LTM candidate cell configuration" means that the UE applies an LTM candidate cell configuration, causing the associated candidate cell to become its new special cell (SpCell), for example, a PCell for LTM in an MCG or a PSCell for LTM in an SCG.

[0113] The phrase "L3 mobility procedure" generally refers to the process by which a UE, while in the RRC_CONNECTED state, uses an RRC procedure to change its cell from a source cell to a target cell; this is sometimes called RRC mobility. Examples include handover, reconfiguration with synchronization, CHO, PSCell change, SN change, SN modification, MN change, conditional reconfiguration, CPC, CPA, and Dual Active Protocol Stack (DAPS) handover, or any combination thereof. An L3 mobility procedure may include one or more of the following operational phases: • Configuration, such as the target RAN node preparing UE configuration for L3 mobility procedures and sending it to the source RAN node, and the source RAN node providing UE configuration to the UE; • Evaluation, in which the UE performs L3 measurements, and the source RAN node (or UE) evaluates the measurements against the execution conditions; and • Execution, including UE execution based on the received configuration and any supporting operations taken by the source RAN node and / or the target RAN node.

[0114] As pointed out above, Figure 5 Examples of L3 mobility procedures involving configuration, evaluation, and execution are shown.

[0115] The embodiments will not be described in more detail. Figure 6 Example RAN (600) is shown that can implement various embodiments of the present disclosure. The RAN (e.g., NG-RAN) includes a UE (601) configured to communicate with a source RAN node (602) via a radio interface (604) in a source cell (607) or a first target cell (608), and with a target RAN node (603) via a radio interface (605) in a second target cell (609). For example, the respective radio interfaces may be NR or LTE.

[0116] In the context of LTM procedures, the source cell can be referred to as the UE's serving cell (or special cell, SpCell), while the first target cell can be referred to as the UE's LTM candidate cell. The second target cell can be the target cell of the UE's L3 mobility procedure, i.e., from the source cell. In the context of geographical distribution, the first and second target cells can be referred to as neighboring cells of the UE's source (or serving) cell.

[0117] When the UE is configured with dual connectivity (e.g., MR-DC or NR-DC), the source and destination RAN nodes are either source and destination MN or source and destination SN, depending on whether the L3 mobility protocol involves MCG or SCG. The source and destination RAN nodes can be connected via interface (606). If both nodes are gNBs in NG-RAN, the interface between them can be an Xn (or Xn-C) interface.

[0118] Source and target RAN nodes can also be deployed in a CU / DU (or split gNB) architecture, such as Figure 1 and Figures 3 to 4 As shown. In this case, the source RAN node includes a source CU (609), a source DU (610), and a second DU (619), while the target RAN node includes a target CU (612) and a target DU (613). The interfaces between the corresponding CUs and DUs (e.g., 611, 620, 614) can be F1 interfaces. In a CU / DU (or split gNB) architecture, the source DU can provide the UE's source cell, while the first target cell can be provided by either the source DU or the second DU. Similarly, the target DU can provide the second target cell.

[0119] Figure 6 The RAN also includes a core network (CN) node (615), which is connected to the source and destination RAN nodes via corresponding interfaces (616, 617). For example, the CN node could be a User Plane Function (UPF) or an Access and Mobility Management Function (AMF). In such cases, the corresponding interface to the RAN node could be an NG interface.

[0120] In various embodiments, any of the UE, the source RAN node, or the target RAN node can manage the UE's LTM configuration associated with the UE's L3 mobility protocol. Some examples are discussed below.

[0121] In some embodiments, a UE can maintain one or more of its existing LTM configurations when executing intra-CU L3 mobility procedures (including intra-DU and intra-cell procedures). In some embodiments, a UE can release one or more of its existing LTM configurations when executing inter-CU L3 mobility procedures (i.e., to a target cell provided by a RAN node different from the RAN node of the source cell of the UE providing the L3 mobility procedure). In other embodiments, a UE can release one or more of its existing LTM configurations when executing any L3 mobility procedure.

[0122] In some embodiments, a UE can modify one or more of its existing LTM configurations when executing an in-CU L3 mobility procedure. For example, a UE can release a portion of one of its existing LTM configurations while maintaining other portions of the LTM configuration. As another example, a UE can add to one of its existing LTM configurations while maintaining other portions of the LTM configuration. As a more specific example, a UE can release a subset of LTM candidate cell configurations that include the LTM configuration, and / or add additional LTM candidate cell configurations to the LTM configuration while maintaining the remaining portions of the LTM configuration.

[0123] In some embodiments, the UE can manage its LTM configuration (including adding new LTM configurations) in response to instructions from the RAN (such as the source RAN node or target RAN node of an L3 mobility protocol). For example, the provision of such instructions can be based on any of the following embodiments: Included in RRC messages (e.g., RRCReconfiguration) from the source RAN node or the target RAN node, such as ToAddMod, ToRelease, or SetupRelease structures; or Included in MAC CE or downlink control information (DCI) sent by the source RAN node or the target RAN node.

[0124] In other embodiments, the UE's management of LTM configuration is pre-configured, for example, based on 3GPP specifications.

[0125] In various embodiments, the UE can manage its LTM configuration (including adding new LTM configurations) during the configuration, evaluation, and / or execution phases of the L3 mobility procedure. In some embodiments, the UE can manage its LTM configuration during the execution of conditional reconfiguration (such as the execution of CHO, CPC, or CPA). For example, the conditional configuration of the L3 mobility candidate cell applied by the UE during execution includes indications on whether to maintain, release, modify, or add one or more LTM configurations or portions thereof (e.g., whether to add / modify or release LTM candidate cell configurations).

[0126] In some embodiments, the source RAN node (or source CU) can maintain one or more LTM configurations for the UE when executing the UE's intra-CU L3 mobility procedures (including intra-DU and intra-cell procedures). In other embodiments, the source RAN node (or source CU) can maintain one or more LTM configurations for the UE, including LTM candidate cell configurations for the target cell served by the target RAN node. In other words, the source RAN node can maintain LTM configurations applicable to the UE for the target RAN node.

[0127] In some embodiments, the source RAN node (or source CU) can release one or more LTM configurations of the UE when executing an inter-CU L3 mobility procedure for the UE (i.e., to a target cell provided by a different RAN node). In other embodiments, the source RAN node can release one or more LTM configurations of the UE when executing any L3 mobility procedure. In other embodiments, the source RAN node (or source CU) can release one or more LTM configurations of the UE, excluding LTM candidate cell configurations for the target cell served by the target RAN node. In other words, the source RAN node can release LTM configurations of the UE that are not applicable to the target RAN node.

[0128] In some embodiments, the source RAN node (or source CU) can modify one or more LTM configurations of the UE when executing L3 mobility procedures within the CU. For example, the source RAN node can release a portion of the LTM configuration while maintaining other parts of the LTM configuration. As another example, the source RAN node can add to the UE's existing LTM configuration while maintaining other parts of the LTM configuration. As a more specific example, the source RAN node can release a subset of LTM candidate cell configurations that include the LTM configuration, and / or add additional LTM candidate cell configurations to the LTM configuration while maintaining the remaining parts of the LTM configuration.

[0129] In some embodiments, the source RAN node (or source CU) can manage one or more LTM configurations of the UE in response to an instruction from the target RAN node for L3 mobility procedures. For example, this instruction can be included in a message via the Xn interface between the source RAN node and the target RAN node. More specifically, the instruction can be included in an XnAP message such as a handover request response (e.g., in F1AP content or in an RRC message embedded in a container). Optionally, the instruction can also be included in an F1 message from the source CU to the source DU.

[0130] In various embodiments, the indication from the target RAN node can be any of the following: • The target RAN node does not support the LTM indication, based on which the source RAN node can infer all LTM configurations of the UE; • One or more LTM candidate cell configurations that are part of an LTM configuration that needs to be released.

[0131] • One or more LTM candidate cell configurations to add to the LTM configuration; and • One or more LTM candidate cell configurations that are part of the LTM configuration that needs to be modified.

[0132] In other embodiments, the source RAN node's management of the LTM configuration is pre-configured, for example, based on 3GPP specifications.

[0133] In various embodiments, the source RAN node can manage the UE's LTM configuration (including adding new LTM configurations) during the configuration, evaluation, and / or execution portions of the L3 mobility procedure. In some embodiments, the source RAN node can manage the UE's LTM configuration during the configuration of conditional reconfiguration for the UE to perform CHO, CPC, or CPA. For example, conditional configuration for an L3 mobility candidate cell (e.g., prepared by a target RAN node serving the cell) includes indications on whether to maintain, release, modify, or add one or more LTM configurations or portions thereof (e.g., whether to add / modify or release LTM candidate cell configurations).

[0134] In some embodiments, the target RAN node (or target CU) can maintain one or more LTM configurations of the UE when executing the UE's intra-CU L3 mobility procedures (including intra-DU and intra-cell procedures). In other embodiments, the target RAN node (or source CU) can maintain one or more LTM configurations of the UE, including LTM candidate cell configurations for the target cell served by the target RAN node. In other words, the target RAN node can maintain LTM configurations applicable to the UE of the target RAN node.

[0135] In some embodiments, the target RAN node (or target CU) can release one or more LTM configurations of the UE when executing inter-CU L3 mobility procedures for the UE (i.e., from a source cell provided by a different RAN node). In other embodiments, the target RAN node can release one or more LTM configurations of the UE when executing any L3 mobility procedure. In other embodiments, the target RAN node (or target CU) can release one or more LTM configurations of the UE, excluding LTM candidate cell configurations for the target cell served by the target RAN node. In other words, the target RAN node can release LTM configurations of the UE that are not applicable to the target RAN node.

[0136] In some embodiments, a target RAN node (or target CU) can modify one or more LTM configurations of a UE when executing L3 mobility procedures within the CU. For example, the target RAN node can release a portion of the LTM configuration while maintaining other parts of the LTM configuration. As another example, the target RAN node can add to the UE's existing LTM configuration while maintaining other parts of the LTM configuration. As a more specific example, the target RAN node can release a subset of LTM candidate cell configurations that include the LTM configuration, and / or add additional LTM candidate cell configurations to the LTM configuration while maintaining the remaining parts of the LTM configuration.

[0137] In some embodiments, the target RAN node (or target CU) can send an indication for L3 mobility procedures to the source RAN node, based on which the source RAN node can manage one or more LTM configurations of the UE. For example, the indication can be included in a message via the Xn interface between the source RAN node and the target RAN node. As a more specific example, the indication can be included in an XnAP message such as a handover request response (e.g., in F1AP content or in an RRC message embedded in a container). Optionally, the indication can also be included in an F1 message from the source CU to the source DU.

[0138] In various embodiments, the indication from the target RAN node can be any of the following: • The target RAN node does not support the LTM indication, based on which the source RAN node can infer all LTM configurations of the UE; • One or more LTM candidate cell configurations that are part of an LTM configuration that needs to be released.

[0139] • One or more LTM candidate cell configurations that need to be added to the LTM configuration; and • One or more LTM candidate cell configurations that are part of the LTM configuration that needs to be modified.

[0140] In some embodiments, the target RAN will indicate that the data sent to the source RAN node can be based on one or more of the following: Does the target RAN node support LTM? The UE capabilities used to manage LTM configuration can be indicated by the source RAN node in a message associated with L3 mobility procedures (e.g., a handover request message) to the target RAN node.

[0141] In other embodiments, the management of LTM configuration by the target RAN node is pre-configured, for example, based on 3GPP specifications.

[0142] In various embodiments, the target RAN node can manage the UE's LTM configuration (including adding new LTM configurations) during the configuration, evaluation, and / or execution portions of the L3 mobility procedure. In some embodiments, the target RAN node can manage the UE's LTM configuration during the configuration of conditional reconfiguration for the UE to perform CHO, CPC, or CPA. For example, conditional configuration for an L3 mobility candidate cell (e.g., prepared by the target RAN node serving the cell) includes indications on whether to maintain, release, modify, or add one or more LTM configurations or portions thereof (e.g., whether to add / modify or release LTM candidate cell configurations).

[0143] The above embodiments can be further derived from Figures 7 to 1 Figure 0 shows the signaling diagrams used for various L3 mobility protocols, in which the UE's LTM configuration is managed by various entities. Specifically, Figures 7 to 1 The entities involved in 0 are from and Figure 6 The same names and reference numbers are used. Although Figures 7 to 1 The operations shown in 0 are given numerical labels, but this is done for illustrative purposes and not to imply or require any particular order of operations, unless otherwise expressly stated.

[0144] Figure 7 The diagram illustrates a signaling diagram of an L3 mobility procedure for a UE to move from a source cell served by a source RAN node to a target cell served by a target RAN node, according to some embodiments of the present disclosure.

[0145] In Operation 1, which can be considered a prerequisite, the UE must have at least one LTM configuration; for clarity and simplicity, this will be referred to below as "LTM configuration." In Operations 2-3, the source RAN node receives the L3 measurement report from the UE and decides to trigger (or initiate) the UE's L3 mobility procedures, specifically the L3 handover procedure to the target cell served by the target RAN node. In Operation 4, the source RAN node sends a handover request message to the target RAN node, indicating a request to prepare for the UE's handover to the target cell. This message includes various parameters of the UE's current configuration in the source cell, including the LTM configuration.

[0146] In operation 5, the target RAN node performs admission control and prepares a handover command message. In this example, the RRCReconfiguration message includes a reconfiguration with synchronization. The target RAN node also determines how to manage the UE's LTM configuration. In this example, the target RAN node determines to release the LTM configuration, and therefore it includes an indication to release the LTM configuration in or along with the RRCReconfiguration message. In operation 6, the target RAN node transmits a handover request response message to the source RAN node to confirm successful preparation for L3 handover of the UE to the target cell. This message includes a handover command message (prepared in operation 5) and an indication to release the LTM configuration. In some embodiments, the indication to release the LTM configuration is included in the RRCReconfiguration message within the RRC container of the handover request response message. In other embodiments, the handover request response includes an XnAP information element containing an indication to release the LTM configuration.

[0147] In operation 7, the source RAN node releases (e.g., discards or deletes) its stored LTM configuration for the UE and sends a handover command message and the indication received in operation 6 to the UE. In some embodiments, the handover command message is an RRCReconfiguration message with synchronized reconfiguration and includes an indication to release the LTM configuration. In operation 8, based on the message received in operation 7, the UE initiates an L3 handover to the target cell. In conjunction with the L3 handover, the UE releases the LTM configuration according to the received indication.

[0148] In operations 9-10, the UE executes the random access procedure in the target cell (if necessary) and sends a handover completion message (e.g., RRCReconfigurationComplete) to the target RAN node to confirm a successful handover to the target cell. In operation 11, the target RAN node initiates a path handover for the data path towards the CN node. In operation 12, the target RAN node completes the handover procedure by requesting the source RAN node to release the UE context; based on this, the source RAN node deletes the UE context it has stored.

[0149] Figure 8 The diagram illustrates a signaling diagram of an L3 mobility procedure for a UE moving from a source cell served by a source RAN node to a target cell served by a target RAN node, according to other embodiments of the present disclosure.

[0150] Operations 1-3 are the same as those described above. Figure 7Operations 1-3 are the same. In operation 4, the source RAN node determines how to manage the UE's LTM configuration. In this example, the source RAN node determines to release the LTM configuration. In operation 5, the source RAN node releases (e.g., discards or deletes) its stored UE LTM configuration and sends an indication to the UE to release the LTM configuration. In this example, the indication is sent in an RRCReconfiguration message.

[0151] In operations 6-7, the UE releases (e.g., discards or deletes) its stored LTM configuration according to the received instruction and sends an RRCReconfigurationComplete message to the source RAN node to confirm the completion of the procedure. In operation 8, the source RAN node sends a handover request message to the target RAN node, indicating a request to prepare for the UE's handover to the target cell. This message includes various parameters of the UE's current configuration in the source cell, but does not include the previously released LTM configuration.

[0152] In operation 8a, the target RAN node performs admission control and prepares a handover command message. In this example, the RRCReconfiguration message includes a synchronized reconfiguration. In operation 9, the target RAN node sends a handover request response message to the source RAN node to confirm successful preparation for L3 handover from the UE to the target cell. This message includes the handover command message.

[0153] In operation 10, the source RAN node sends the handover command message received in operation 9 to the UE, for example, as an RRCReconfiguration message with synchronous reconfiguration. In operation 11, based on the message received in operation 10, the UE initiates an L3 handover to the target cell. Operations 12-15 are the same as described above. Figure 7 The operation is the same as 9-12.

[0154] Figure 9 The diagram illustrates a signaling diagram of an L3 mobility procedure for a UE moving from a source cell served by a source RAN node to a target cell served by a target RAN node, according to other embodiments of the present disclosure.

[0155] Operations 1-8 are the same as those above. Figure 8 The operations 1-8 are the same.

[0156] In operation 8a, the target RAN node performs admission control and prepares a handover command message. In this example, the RRCReconfiguration message includes a reconfiguration with synchronization. The target RAN node also determines how to manage the UE's LTM configuration. In this example, the target RAN node determines to add an LTM configuration and therefore includes an indication to add the LTM configuration in or along with the RRCReconfiguration message. In some embodiments, the target RAN node may include the LTM configuration to be added in or along with the RRCReconfiguration message.

[0157] In operation 9, the target RAN node transmits a handover request response message to the source RAN node to confirm successful preparation for L3 handover from the UE to the target cell. This message includes a handover command message (prepared in operation 8a) and an indication to add LTM configuration (and optionally, the LTM configuration to be added). In some embodiments, the indication to add LTM configuration is included in an RRCReconfiguration message within an RRC container in the handover request response message. In other embodiments, the handover request response includes an XnAP information element containing an indication to add LTM configuration.

[0158] In operation 10, the source RAN node sends a handover command message and the indication received in operation 9 to the UE. In some embodiments, the handover command message is an RRCReconfiguration message with synchronized reconfiguration and includes an indication to add LTM configuration (and optionally, the LTM configuration to be added). In operation 11, based on the message received in operation 10, the UE initiates an L3 handover to the target cell. In conjunction with the L3 handover, the UE adds LTM configuration according to the received indication. Operations 12-15 are similar to those described above. Figure 7 The operation is the same as 9-12.

[0159] Figure 10 (which includes) Figures 10A to 10B Figure 10 illustrates a signaling diagram of an L3 mobility procedure for a UE moving from a source cell served by a source RAN node to a target cell served by a target RAN node, according to other embodiments of this disclosure. Specifically, Figure 10 relates to the source DU and CU of the source RAN node and the target DU and CU of the target RAN node.

[0160] In Operation 1, which can be considered a prerequisite, the UE must have at least one LTM configuration, which will be referred to as "LTM configuration" below for clarity and simplicity. The source CU performs this operation together with the UE. In Operations 2-3, the source DU receives the L3 measurement report from the UE and forwards the report to the source CU in a "UL RRC Message Transmission" message.

[0161] In Operation 4, based on the L3 measurement report, the source CU decides to trigger (or initiate) the UE's L3 mobility procedure, specifically the L3 handover procedure to the target cell served by the target CU of the target RAN node. In Operation 5, the source CU determines how to manage the UE's LTM configuration associated with the L3 mobility procedure. In this example, the source RAN node determines to release the LTM configuration.

[0162] In operation 6, the source CU sends a "UE Context Modification Request" message to the source DU, which indicates the release of the UE's LTM configuration. This message also includes an RRCReconfiguration message, which includes the indication to release the LTM configuration. In operation 7, the source DU releases (e.g., discards or deletes) its stored UE LTM configuration and sends an indication to the UE to release the LTM configuration. In this example, the indication is sent in an RRCReconfiguration message. In operation 8, the source DU sends a "UE Context Modification Response" message to the source DU, which includes confirmation that the LTM configuration has been released.

[0163] In some embodiments, the source CU may include a query about the latest configuration of the UE in the "UE context modification request message" of operation 6. If so, the source DU includes the complete configuration information of the UE in the "UE context modification response" message of operation 7.

[0164] In operations 9-10, the UE releases (e.g., discards or deletes) its stored LTM configuration according to the received instruction and sends an RRCReconfigurationComplete message to the source DU to confirm the completion of the procedure. In operation 11, the source DU forwards the received RRCReconfigurationComplete message to the source CU in a "UL Messaging" message.

[0165] In operation 12, the source CU sends a handover request message to the target CU, indicating a request to prepare for the UE's handover to the target cell. This message includes various parameters of the UE's current configuration in the source cell, but does not include any previously released LTM configuration.

[0166] In operation 13, the target CU determines how to manage the UE's LTM configuration. In this example, the target CU determines to add LTM configuration and therefore includes the instruction to add LTM configuration in the "UE Context Setting Request" message sent to the target DU in operation 14. This message also requests the target DU to prepare lower-layer configurations for the UE in the target cell, including the relevant portions of the LTM configuration. In operation 15, based on the "UE Context Setting Request" message, the target DU performs admission control, prepares the requested UE configuration, and returns it to the target CU in a "UE Context Setting Response" message.

[0167] In operation 16, the target CU prepares a handover command message (e.g., an RRCReconfiguration message with synchronous reconfiguration) based on the received UE configuration, and includes an indication to add LTM configuration in or together with the RRCReconfiguration message. The target CU sends the prepared handover command (e.g., an RRCReconfiguration message with synchronous reconfiguration) and the indication to the source CU in a handover request response message. In some embodiments, the indication to add LTM configuration is included in the RRCReconfiguration message within the RRC container of the handover request response message. In other embodiments, the handover request response includes an XnAP information element containing the indication to add LTM configuration.

[0168] In operation 17, the source CU transmits a "UE Context Modification Request" message to the source DU. This message includes a handover command message and an indication of adding the LTM configuration for the UE received in operation 16, along with an indication of DL data transmission. In operation 18, the source DU also sends a "Downlink Data Delivery Status" frame to notify the source CU that DL data was not successfully transmitted to the UE. In operation 19, the source DU forwards the handover command and the indication of adding the LTM configuration to the UE. In operation 20, the source DU responds to the gNB-CU with a "UE Context Setting Response" message, indicating that the handover command was successfully provided to the UE.

[0169] In operation 21, the UE performs an L3 handover to the target cell according to the received handover command and adds LTM configuration according to the received instructions. In operations 22-23, the UE executes the random access procedure in the target cell (if necessary) and sends a handover completion message (e.g., RRCReconfigurationComplete) to the target DU to confirm the successful handover to the target cell. In operation 24, the target DU sends a "Downlink Data Delivery Status" frame to notify the target CU of the successful delivery of DL data to the UE in the target cell. In operation 25, the target DU forwards the handover completion message (e.g., RRCReconfigurationComplete) received in operation 23 to the target CU.

[0170] In operation 26, the target CU initiates a path handover of the data path towards the CN node. In operation 27, the target CU completes the handover procedure by requesting the source CU to release the UE context. In operations 28-29, the source CU requests the source DU to release the UE context and receives a response to this action.

[0171] The technology disclosed herein can also be embodied in 3GPP specifications. Below are some sample texts from 3GPP TS 38.423 (XnAP protocol specification), where ellipses indicate text omitted for brevity, and underscores indicate text particularly relevant to embodiments of this disclosure.

[0172] ***Start of 3GPP 38.423 text*** 8.2.1 Switchover Preparation 8.2.1.1 Overview This procedure is used to establish the necessary resources in the NG-RAN node for an incoming handover. If the procedure involves a conditional handover, parallel transactions are allowed. When the source UE AP ID is the same, possible parallel requests are identified by the target cell ID. This procedure uses the signaling associated with the UE.

[0173] 8.2.1.2 Successful operation … If the "Switch Request Response" message contains the LTM Release Indicator (IE), the source NG-RAN node will release the LTM configuration.

[0174] … 9.1.1.2 "Handover Request Response" This message is sent by the target NG-RAN node to notify the source NG-RAN node about the resources prepared at the target.

[0175] Direction: Target NG-RAN node · Source NG-RAN node. IE / Group Name Pres. Range IE Type / Index Semantic Description Message Type M 9.2.3.1 Source NG-RAN Node UE XnAP ID M NG-RAN Node UE XnAP ID 9.2.3.16 Allocated by the source NG-RAN node … LTM Release Indicator ]]> ​ O ]]> ​ ]]> ​ Enumerated (Release,...) ]]> ​ ]]> ​

[0176] ***End of 3GPP 38.423 text*** The above embodiments can be used as a reference. Figures 11 to 13 To further explain, Figures 11 to 13 Exemplary methods (e.g., procedures) for the UE, source RAN node, and target RAN node are described respectively. In other words, the various features of the operations described below correspond to the various embodiments described above. Figures 11 to 13 The exemplary methods shown can be used in combination to provide various benefits, advantages, and / or solutions to the problems described herein. Although Figures 11 to 13 Exemplary methods are shown in a specific order through specific boxes, but operations corresponding to these boxes can be performed in a different order than shown, and can be combined and / or divided into boxes and / or operations with different functionality than shown. Optional boxes or operations are indicated by dashed lines.

[0177] More specifically, Figure 11 Exemplary methods (e.g., procedures) for configuring a UE to perform Layer 3 (L3) mobility procedures in the RAN are shown according to various embodiments of the present disclosure. Figure 11 The exemplary method shown can be performed by a UE (e.g., a wireless device) such as those described elsewhere in this document.

[0178] An exemplary method includes the operation of box 1110, wherein the UE receives configuration for LTM procedures in the RAN via a source cell in the RAN. The exemplary method also includes the operation of box 1130, wherein the UE can manage the LTM configuration during preparation or execution of L3 mobility procedures to a target cell in the RAN. This includes one or more of the following management operations, labeled with corresponding sub-box numbers: • (1131) Maintain LTM configuration; • (1132) Release LTM configuration; • (1133) Modify LTM configuration; and • (1134) Add a second LTM configuration.

[0179] In some embodiments, managing the LTM configuration in block 1130 is based on whether the target cell is provided by a different RAN node than the source cell based on the L3 mobility protocol. For example, when the target cell is provided by a different RAN node than the source cell, releasing the LTM configuration is performed in block 1132, while maintaining the LTM configuration is performed in sub-block 1131 when the target cell is provided by the same RAN node as the source cell.

[0180] In some embodiments, the exemplary method further includes the operation of block 1120, wherein the UE receives an indication from the RAN of one or more management operations to be performed. In such cases, management LTM configuration is performed based on the indication.

[0181] In some of these embodiments, the indication is received in one of the following ways: via an L3 (e.g., RRC) message from the source or target cell, via an L2 (e.g., MAC) message from the source or target cell, or via an L1 (e.g., PHY) message from the source cell. As a more specific example, the indication may be received in an L3 mobility command (e.g., a handover command), as described above regarding the various... Figures 7 to 1 0 describes this. In some variations, this instruction is in one of the following data structures of the L3 mobility command: ToAddMod, ToRelease, or SetupRelease.

[0182] In some of these embodiments, the L3 mobility procedure is an unconditional mobility procedure, and the instruction is received in or with a command to execute the unconditional mobility procedure. In other embodiments of these embodiments, the L3 mobility procedure is a conditional mobility procedure, and the instruction is received in or with a conditional configuration of the conditional mobility procedure.

[0183] In some of these embodiments, the instruction includes one or more of the following: • Instruction to release the LTM configuration; • The second LTM configuration to be added; • An indication of which part of the LTM configuration to release or modify; and • Information to be added to the LTM configuration.

[0184] In some variations of these embodiments, the indicated portion of the LTM configuration to be released or modified includes one or more LTM candidate cell configurations. In some variations of these embodiments, the information to be added includes one or more LTM candidate cell configurations.

[0185] In some of these embodiments, the exemplary method also includes the operation of block 1140, in which the UE sends an acknowledgment or response to the RAN (e.g., to the source or target RAN node, as appropriate) that the indicated management operation has been performed.

[0186] In some embodiments, the LTM configuration includes one or more of the following: • One or more LTM candidate cells configured; • Configuration for measurement and reporting of LTM candidate cells; • Downlink (DL) pre-synchronization configuration for LTM; • Uplink (UL) pre-synchronization configuration for LTM; and • Configuration for executing LTM cell handover procedures to the corresponding LTM candidate cell.

[0187] In some of these embodiments, when the LTM configuration includes one or more LTM candidate cell configurations, modifying the LTM configuration in subframe 1133 includes one or more of the following operations: Release one of the LTM candidate cell configurations while maintaining the others in the LTM candidate cell configurations; and Add additional LTM candidate cell configurations to the one or more LTM candidate cell configurations.

[0188] In various embodiments, the L3 mobility procedure can be any of the following: handover, dual active protocol stack (DAPS) handover synchronization reconfiguration, conditional handover, conditional reconfiguration, primary SCG cell (PSCell) change, conditional PSCell change, conditional PSCell addition, secondary node (SN) change, SN modification, primary node (MN) change.

[0189] also, Figure 12 Exemplary methods (e.g., procedures) for configuring a source cell to provide UE L3 mobility procedures are shown according to various embodiments of this disclosure. Figure 12 The exemplary methods shown can be performed by RAN nodes (e.g., base stations, gNBs, etc.) or their (one or more) units (e.g., CUs and / or DUs), as described elsewhere herein.

[0190] An exemplary method includes the operation of block 1210, wherein the RAN node sends a configuration for LTM procedures in the RAN to the UE via the source cell. The exemplary method also includes the operation of block 1240, wherein the RAN node releases at least a portion of the LTM configuration during the preparation or execution of L3 mobility procedures from the UE to the target cell in the RAN.

[0191] In some embodiments, at least a portion of releasing the LTM configuration in block 1240 is performed based on the target cell of the L3 mobility protocol provided by another RAN node.

[0192] In some embodiments, the exemplary method further includes the operation of block 1250, wherein the RAN node sends an indication to the UE to release at least a portion of the LTM configuration. In some of these embodiments, the indication is sent via the source cell in one of the following: an L3 (e.g., RRC) message, an L2 (e.g., MAC) message, or an L1 (e.g., PHY) message. As a more specific example, the indication may be sent in an L3 mobility command (e.g., a handover command), as described above regarding the various... Figures 7 to 10 describes. In some variations of these embodiments, the instruction is in one of the following data structures of the L3 mobility command: ToAddMod, ToRelease, or SetupRelease.

[0193] In some of these embodiments, the L3 mobility procedure is an unconditional mobility procedure, and the instruction is sent to the UE in or along with a command to execute the unconditional mobility procedure. In other embodiments of these embodiments, the L3 mobility procedure is a conditional mobility procedure, and the instruction is sent to the UE in or along with a conditional configuration of the conditional mobility procedure.

[0194] In some of these embodiments, the exemplary method may also include the operation of block 1240, wherein the RAN node can receive from the UE an acknowledgment or response that the indicated management operation has been performed.

[0195] In some embodiments, the LTM configuration includes one or more of the following: • One or more LTM candidate cells configured; • Configuration for measurement and reporting of LTM candidate cells; • DL pre-synchronization configuration for LTM; • UL pre-synchronization configuration for LTM; and • Configuration for executing LTM cell handover procedures to the corresponding LTM candidate cell.

[0196] In some embodiments, the exemplary method further includes the operations in blocks 1220-1230, wherein the RAN node sends a request to a target RAN node providing the target cell to execute the UE's L3 mobility protocol, and receives from the target RAN node the following: the configuration of the UE's L3 mobility protocol, and an indication to release at least a portion of the LTM configuration. In such cases, releasing at least a portion of the LTM configuration in block 1240 is in response to the indication received in block 1230.

[0197] In some of these embodiments, the instruction to release at least a portion of the LTM configuration is one of the following: • The target RAN node does not support LTM indication; • An explicit instruction to release the LTM configuration; and • An indication of one or more LTM candidate cell configurations of the LTM configuration to be released.

[0198] In various embodiments, the L3 mobility procedure can be any of the following: handover, DAPS handover synchronization reconfiguration, conditional handover, conditional reconfiguration, PSCell change, conditional PSCell change, conditional PSCell addition, SN change, SN modification, MN change.

[0199] also, Figure 13 Exemplary methods (e.g., procedures) for configuring a target cell to provide UE L3 mobility procedures are illustrated according to various embodiments of this disclosure. Figure 13 The exemplary methods shown can be performed by RAN nodes (e.g., base stations, gNBs, etc.) or their (one or more) units (e.g., CUs and / or DUs), as described elsewhere herein.

[0200] An exemplary method includes the operation of box 1340, wherein during the preparation or execution of the UE-to-target cell L3 mobility procedure, the RAN node manages the configuration for the UE's LTM procedure from the source cell in the RAN. This includes one or more of the following management operations, marked with the corresponding sub-box numbers: • (1341) Maintain LTM configuration; • (1342) Release LTM configuration; • (1343) Modify LTM configuration; and • (1344) Add a second LTM configuration.

[0201] In some embodiments, managing the LTM configuration in block 1340 is based on whether the source cell is provided by another RAN node according to the L3 mobility protocol. In some of these embodiments, releasing the LTM configuration is performed in sub-block 1342 when the source cell is provided by another RAN node, while maintaining the LTM configuration is performed in sub-block 1341 when the source cell is provided by a RAN node.

[0202] In some embodiments, the exemplary method further includes the operation at block 1350, wherein the RAN node sends an indication to the UE of one or more corresponding management operations to be performed by the UE on the LTM configuration. In some of these embodiments, the indication is sent via the target cell in one of the following: an L3 (e.g., RRC) message or an L2 (e.g., MAC) message. As a more specific example, the indication is sent in an L3 mobility command (e.g., a handover command), as described above regarding the various... Figures 7 to 1 0 describes this. In some variations, this instruction is included in one of the following data structures of the L3 mobility command: ToAddMod, ToRelease, or SetupRelease.

[0203] In some of these embodiments, the indication sent to the UE includes one or more of the following: • The target RAN node does not support LTM indication; • Instruction to release the LTM configuration; • The second LTM configuration to be added; • An indication of which part of the LTM configuration to release or modify; and • Information to be added to the LTM configuration.

[0204] In some of these embodiments, the exemplary method also includes the operation of block 1360, wherein the RAN node receives from the UE an acknowledgment or response that a corresponding management operation has been performed.

[0205] In some embodiments, the LTM configuration includes one or more of the following: • One or more LTM candidate cells configured; • Configuration for measurement and reporting of LTM candidate cells; • DL pre-synchronization configuration for LTM; • UL pre-synchronization configuration for LTM; and • Configuration for executing LTM cell handover procedures to the corresponding LTM candidate cell.

[0206] In some of these embodiments, when the LTM configuration includes one or more LTM candidate cell configurations, modifying the LTM configuration in subframe 1343 includes one or more of the following operations: • Release one of the LTM candidate cell configurations while maintaining the others in the LTM candidate cell configuration; and • Add additional LTM candidate cell configurations to one or more LTM candidate cell configurations.

[0207] In some embodiments, the exemplary method further includes the operations in blocks 1320-1330, wherein the RAN node receives a request from the source RAN node providing the source cell to execute the L3 mobility procedure of the UE; and sends the following to the source RAN node: configuration of the L3 mobility procedure for the UE, and an indication to release at least a portion of the LTM configuration.

[0208] In some of these embodiments, the request to execute L3 mobility procedures includes at least a portion of the LTM configuration. In some of these embodiments, the instruction to release at least a portion of the LTM configuration is one of the following: • The target RAN node does not support LTM indication; • Explicit instructions for releasing LTM configuration; • The second LTM configuration to be added; and • An indication of one or more LTM candidate cell configurations of the LTM configuration to be released.

[0209] In various embodiments, the L3 mobility procedure can be any of the following: handover, DAPS handover synchronization reconfiguration, conditional handover, conditional reconfiguration, PSCell change, conditional PSCell change, conditional PSCell addition, SN change, SN modification, MN change.

[0210] Although various embodiments have been described above in terms of methods, techniques and / or procedures, those skilled in the art will readily understand that such methods, techniques and / or procedures can be implemented by various combinations of hardware and software in various systems, communication devices, computing devices, control devices, equipment, non-transitory computer-readable media, computer program products, etc.

[0211] Figure 14 An example of a communication system 1400 according to some embodiments is shown. In this example, the communication system 1400 includes a telecommunications network 1402, which includes an access network 1404 (e.g., RAN) and a core network 1406, which includes one or more core network nodes 1408. The access network 1404 includes one or more access network nodes, such as network nodes 1410a-b (one or more of which may be collectively referred to as network node 1410), or any other similar 3GPP access node or non-3GPP access point. Furthermore, as those skilled in the art will appreciate, network nodes are not necessarily limited to implementations of radio and baseband portions provided and integrated by a single vendor. Thus, it will be understood that network nodes include de-aggregation implementations or portions thereof. For example, in some embodiments, the telecommunications network 1402 includes one or more Open RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunications network 1402 that supports ORAN specifications (e.g., specifications published by the O-RAN Alliance or any similar organization) and can operate independently or in conjunction with other nodes to enable one or more functionalities of any node in the telecommunications network 1402 (including one or more network nodes 1410 and / or core network node 1408).

[0212] Examples of ORAN network nodes include Open Radio Units (O-RUs), Open Distributed Units (O-DUs), Open Central Units (O-CUs) (including O-CU Control Plane (O-CU-CP) or O-CU User Plane (O-CU-UP)), RAN Intelligent Controllers (near real-time or non-real-time) that host software or software plugins (such as near real-time control applications (e.g., xApp) or non-real-time control applications (e.g., rApp)), or any combination thereof (the adjective "open" indicates support for ORAN specifications). Network node support for specifications can be achieved, for example, by supporting interfaces defined by ORAN specifications, such as A1, F1, W1, E1, E2, X2, Xn interfaces, Open Fronthaul User Plane Interfaces, or Open Fronthaul Management Plane Interfaces. Furthermore, ORAN access nodes can be logical nodes within physical nodes. Additionally, ORAN network nodes can be implemented in a virtualized environment (further described below) in which one or more network functions are virtualized. For example, the virtualized environment may include an O-cloud computing platform orchestrated by a service management and orchestration framework via an O-2 interface defined by the O-RAN Alliance or comparable technologies. Network node 1410 facilitates direct or indirect connections for UEs, such as connecting UEs 1412a-d (one or more of which may be collectively referred to as UE 1412) to core network 1406 via one or more wireless connections.

[0213] Examples of wireless communication via wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information, without the use of wires, cables, or other conductors. Furthermore, in various embodiments, communication system 1400 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that can facilitate or participate in data and / or signal communication (whether via wired or wireless connection). Communication system 1400 may include and interface with any type of communication, telecommunications, data, cellular, radio network, and / or other similar type of system.

[0214] UE 1412 can be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with network node 1410 and other communication devices. Similarly, network node 1410 is arranged, capable, configured, and / or operable to communicate directly or indirectly with UE 1412 and / or with other network nodes or devices in telecommunication network 1402 to implement and / or provide network access (such as wireless network access), and / or to perform other functions, such as control in telecommunication network 1402.

[0215] In the depicted example, core network 1406 connects network node 1410 to one or more hosts, such as host 1416. These connections may be direct or indirect via one or more intermediate networks or devices. In other examples, network nodes may be directly coupled to hosts. Core network 1406 includes one or more core network nodes (e.g., 1408) constructed with hardware and software components. The characteristics of these components may be substantially similar to those described with respect to UE, network nodes, and / or hosts, such that the description generally applies to the corresponding components of core network node 1408. Example core network nodes include functions of one or more of the following: Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier Dehiding Function (SIDF), Unified Data Management (UDM), Secure Edge Protection Agent (SEPP), Network Exposure Function (NEF), and / or User Plane Function (UPF).

[0216] Host 1416 may be owned or controlled by a service provider other than the operator or provider of access network 1404 and / or telecommunications network 1402, and may be operated by or on behalf of the service provider. Host 1416 may host various applications to provide one or more services. Examples of such applications include live and pre-recorded audio / video content, data collection services (such as retrieving and compiling data about various environmental conditions detected by multiple UEs), analytics functionality, social media, functionality for controlling or otherwise interacting with remote devices, functionality for alarm and monitoring centers, or any other such functionality performed by a server.

[0217] As a whole, Figure 14 The communication system 1400 enables connectivity between the UE, network nodes, and hosts. In this sense, the communication system can be configured to operate according to predefined rules or procedures, such as specific standards, including but not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); Wireless Local Area Network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi); and / or any other suitable wireless communication standards, such as Global Microwave Access Interoperability (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any Low Power Wide Area Network (LPWAN) standards, such as LoRa and Sigfox.

[0218] In some examples, telecommunications network 1402 is a cellular network implementing 3GPP standardized features. Therefore, telecommunications network 1402 can support network slicing to provide different logical networks to different devices connected to it. For example, telecommunications network 1402 can provide ultra-reliable low-latency communication (URLLC) services to some UEs while providing enhanced mobile broadband (eMBB) services to other UEs, and / or massive machine-type communication (mMTC) / massive IoT services to yet another UE.

[0219] In some examples, UE 1412 is configured to transmit and / or receive information without direct human interaction. For example, the UE may be designed to transmit information to access network 1404 according to a predetermined schedule when triggered by an internal or external event, or in response to a request from access network 1404. Additionally, the UE may be configured to operate in single RAT, multi-RAT, or multi-standard modes. For example, the UE may operate with any one or a combination of Wi-Fi, NR (New Radio), and LTE, i.e., configured for multiple radio dual connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) NR-Dual Connectivity (EN-DC).

[0220] In this example, hub 1414 communicates with access network 1404 to facilitate indirect communication between one or more UEs (e.g., 1412c and / or 1412d) and a network node (e.g., 1410b). In some examples, hub 1414 may be a controller, router, content source, and analysis device, or any other communication device relating to the UE described herein. For example, hub 1414 may be a broadband router that enables the UE to access core network 1406. As another example, hub 1414 may be a controller that sends commands or instructions to one or more actuators in the UE. The command or instruction may be received from the UE, network node 1410, or via executable code, script, procedure, or other instructions in hub 1414. As another example, hub 1414 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform data analysis or other processing. As another example, hub 1414 may be a content source. For example, for a UE acting as a VR headset, display, speaker, or other media delivery device, hub 1414 can retrieve VR assets, video, audio, or other media or data related to sensory information via network nodes, and then hub 1414 provides them to the UE either directly, after performing local processing, and / or after adding additional local content. In yet another example, hub 1414 acts as a proxy server or orchestrator for the UE, particularly when one or more of the UEs are low-power IoT devices.

[0221] Hub 1414 may have a persistent / persistent or intermittent connection to network node 1410b. Hub 1414 may also consider different communication schemes and / or scheduling between hub 1414 and UE (e.g., 1412c and / or 1412d) and between hub 1414 and core network 1406. In other examples, hub 1414 is connected to core network 1406 and / or one or more UEs via a wired connection. Furthermore, hub 1414 may be configured to connect to an M2M service provider via access network 1404 and / or to another UE via a direct connection. In some scenarios, a UE may establish a wireless connection with network node 1410 while still being connected via hub 1414 via a wired or wireless connection. In some embodiments, hub 1414 may be a dedicated hub—that is, a hub whose primary function is to route communication from network node 1410b to UE / from UE to network node 1410b. In other embodiments, hub 1414 may be a non-dedicated hub—that is, an apparatus capable of operating to route communication between the UE and network node 1410b, but additionally capable of operating as a communication start and / or end point for a particular data channel.

[0222] Figure 15 The illustration shows a UE 1500 according to some embodiments. Examples of UEs include, but are not limited to, smartphones, mobile phones, cellular phones, Voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, return dischargers, wearable terminal devices, wireless endpoints, mobile stations, tablets, laptops, laptop embedded devices (LEEs), laptop-mounted devices (LMEs), smart devices, wireless customer premises equipment (CPEs), vehicles, vehicle-mounted or vehicle-embedded / integrated wireless devices, etc. Other examples include any UE identified by 3GPP, including narrowband Internet of Things (NB-IoT) UEs, machine-type communication (MTC) UEs, and / or enhanced MTC (eMTC) UEs.

[0223] The UE may support device-to-device (D2D) communication, for example, by implementing 3GPP standards for sidelink communication, dedicated short-range communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, the UE may not necessarily have a user in the sense of a human user who owns and / or operates the associated device. Instead, the UE may represent a device intended for sale to a human user, or operated by a human user but which may not be associated with, or initially may not be associated with, a particular human user (e.g., a smart sprinkler controller). Alternatively, the UE may represent a device not intended for sale to an end user, or operated by an end user but which may be associated with or operated for the benefit of a user (e.g., a smart meter).

[0224] UE 1500 includes processing circuitry 1502, which is operatively coupled via bus 1504 to input / output interface 1506, power supply 1508, memory 1510, communication interface 1512, and / or any other components, or any combination thereof. A particular UE may utilize... Figure 15 All components or subsets of components are shown. The degree of integration between components can vary from one UE to another. In addition, a particular UE may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0225] Processing circuitry 1502 is configured to process instructions and data and can be configured to implement any sequential state machine operable to execute instructions stored in memory 1510 as a machine-readable computer program. Processing circuitry 1502 can be implemented as one or more hardware-implemented state machines (e.g., using discrete logic, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.); programmable logic along with appropriate firmware; one or more stored computer programs, general-purpose processors such as microprocessors or digital signal processors (DSPs), along with appropriate software; or any combination of the foregoing. For example, processing circuitry 1502 may include multiple central processing units (CPUs).

[0226] In this example, the input / output interface 1506 can be configured to provide one or more interfaces to input devices, output devices, or one or more input and / or output devices. Examples of output devices include speakers, sound cards, video cards, displays, monitors, printers, actuators, transmitters, smart cards, another output device, or any combination thereof. Input devices allow users to capture information into the UE 1500. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital camcorders, webcams, etc.), microphones, sensors, mice, trackballs, steering wheels, touchpads, scroll wheels, smart cards, etc. Presence-sensitive displays may include capacitive or resistive touch sensors to sense input from the user. Sensors may include, for example, accelerometers, gyroscopes, tilt sensors, force sensors, magnetometers, light sensors, proximity sensors, biosensors, etc., or any combination thereof. Output devices may use the same type of interface port as input devices. For example, a Universal Serial Bus (USB) port can be used to provide both input and output devices.

[0227] In some embodiments, power supply 1508 is configured as a battery or battery pack. Other types of power sources may be used, such as external power sources (e.g., electrical outlets), photovoltaic devices, or individual battery cells. Power supply 1508 may also include power circuitry for delivering power from power supply 1508 itself and / or external power sources to various parts of UE 1500 via input circuitry or an interface such as a power cable. Delivering power may, for example, be used to charge power supply 1508. The power circuitry may perform any formatting, conversion, or other modifications on the power from power supply 1508 to suit the appropriate components of the UE 1500 to which power is supplied.

[0228] Memory 1510 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), disk, optical disk, hard disk, removable storage enclosure, flash drive, etc. In one example, memory 1510 includes one or more applications 1514, such as an operating system, web browser application, widget, utility engine, or other application, and corresponding data 1516. Memory 1510 can store any of a wide variety of different operating systems for use by UE 1500, or a combination of operating systems.

[0229] The memory 1510 can be configured to include multiple physical drive units, such as a redundant array of independent disks (RAID), flash memory, a USB flash drive, an external hard drive, a thumb drive, a pen drive, a key drive, a high-density digital multifunction disc (HD-DVD) optical disc drive, an internal hard drive, a Blu-ray disc drive, a holographic digital data storage (HDDS) optical disc drive, an external mini dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro DIMM SDRAM, smart card memory (such as a tamper-proof module in the form of a universal integrated circuit card (UICC), including one or more subscriber identity modules (SIMs), such as USIM and / or ISIM), other memory, or any combination thereof. The UICC can be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly referred to as a "SIM card." The memory 1510 allows the UE 1500 to access instructions, applications, etc., stored on transient or non-transient memory media to offload or upload data. Articles of manufacture such as those utilizing communication systems may be tangibly embodied in or contained in memory 1510, which may be or include a device-readable storage medium.

[0230] Processing circuitry 1502 may be configured to communicate with an access network or other network using communication interface 1512. Communication interface 1512 may include one or more communication subsystems and may include or be communicatively coupled to antenna 1522. Communication interface 1512 may include one or more transceivers for communication, such as through one or more remote transceivers communicating with another device capable of wireless communication (e.g., a network node in the access network or another UE). Each transceiver may include a transmitter 1518 and / or a receiver 1520 suitable for providing network communication (e.g., optical, electrical, frequency allocation, etc.). Furthermore, transmitter 1518 and receiver 1520 may be coupled to one or more antennas (e.g., antenna 1522) and may share circuitry, software, or firmware, or alternatively may be implemented separately.

[0231] In the illustrated embodiment, the communication functions of the communication interface 1512 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication (such as using a Global Positioning System (GPS) to determine location), another similar communication function, or any combination thereof. The communication may be implemented according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Optical Networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so on.

[0232] Regardless of the type of sensor, the UE can provide the output of data captured by its sensors via its communication interface 1512 through a wireless connection to the network node. Data captured by the UE's sensors can be transmitted to the network node via another UE through a wireless connection. The output can be periodic (e.g., every 15 minutes if it reports the sensed temperature), random (e.g., balancing the load of reports from several sensors), responsive to a triggered event (e.g., sending an alarm when humidity is detected), responsive to a request (e.g., a user-initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0233] As another example, the UE includes actuators, motors, or switches associated with a communication interface configured to receive wireless input from a network node via a wireless connection. The state of the actuator, motor, or switch may change in response to the received wireless input. For example, the UE may include a motor that adjusts the control surfaces or rotors of a flying drone based on the received input, or adjusts a robotic arm performing medical procedures based on the received input.

[0234] When a UE takes the form of an Internet of Things (IoT) device, it can be a device used in one or more application areas, including but not limited to urban wearable technology, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices include devices that are, or are embedded in, devices such as: connected refrigerators or freezers, televisions, connected lighting fixtures, electricity meters, robotic vacuum cleaners, voice-activated smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door / window sensors, flood / humidity sensors, electronic door locks, connected doorbells, air conditioning systems like heat pumps, autonomous vehicles, monitoring systems, weather monitoring devices, vehicle parking monitoring devices, electric vehicle charging stations, smartwatches, fitness trackers, head-mounted displays for augmented reality (AR) or virtual reality (VR), wearable devices for haptic or sensory enhancement, sprinklers, animal or object tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any kind of medical device, such as heart rate monitors or remote-controlled surgical robots. (Except for...) Figure 15 In addition to the other components described in UE 1500 shown, a UE in the form of an IoT device includes circuitry and / or software that depends on the intended application of the IoT device.

[0235] As another specific example, in IoT scenarios, a UE can represent a machine or other device that performs monitoring and / or measurement and transmits the results of such monitoring and / or measurement to another UE and / or network node. In this case, the UE can be an M2M device, which may be referred to as an MTC device in the 3GPP context. As a specific example, the UE can implement the 3GPP NB-IoT standard. In other scenarios, a UE can represent a vehicle such as a car, bus, truck, ship, or airplane, or other devices capable of monitoring and / or reporting their operational status or other functions associated with their operation.

[0236] In practice, any number of UEs can be used together for a single use case. For example, the first UE can be a drone or integrated into a drone, providing the drone's speed information (obtained via a speed sensor) to a second UE that acts as a remote controller for operating the drone. When the user makes a change from the remote controller, the first UE can adjust the throttle on the drone (e.g., by controlling the actuators) to increase or decrease the drone's speed. The first UE and / or the second UE can also include more than one of the aforementioned functionalities. For example, a UE may include sensors and actuators, and handle data communication for both the speed sensor and the actuators.

[0237] Figure 16A network node 1600 is shown according to some embodiments. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, node Bs, eNBs, gNBs), and O-RAN nodes or components of O-RAN nodes (e.g., O-RUs, O-DUs, O-CUs).

[0238] Base stations can be categorized based on the coverage they provide (or in other words, their transmission power level), and therefore, depending on the coverage provided, they can be referred to as femtocells, picocells, microcells, or macrocells. A base station can be a relay node or a relay donor node that controls the relay. Network nodes can also include one or more (or all) parts of a distributed radio base station, such as centralized digital units, distributed units (e.g., in O-RAN access nodes), and / or remote radio units (RRUs), sometimes referred to as remote radio headends (RRHs). Such remote radio units may or may not be integrated with an antenna as antenna-integrated radio devices. The parts of a distributed radio base station can also be referred to as nodes in a distributed antenna system (DAS).

[0239] Other examples of network nodes include multi-transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) devices such as MSR BS, network controllers such as radio network controllers (RNC) or base station controllers (BSC), base transceiver stations (BTS), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCE), operations and maintenance (O&M) nodes, operations support system (OSS) nodes, self-organizing network (SON) nodes, location nodes (e.g., evolved Serving Mobility Location Center (E-SMLC)), and / or driver test minimization (MDT).

[0240] Network node 1600 includes processing circuitry 1602, memory 1604, communication interface 1606, and power supply 1608. Network node 1600 may consist of multiple physically separate components (e.g., NodeB components and RNC components, or BTS components and BSC components, etc.), each with its own corresponding components. In certain scenarios where network node 1600 includes multiple separate components (e.g., BTS components and BSC components), one or more of these separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such scenarios, each unique NodeB and RNC pair may be considered a single, separate network node in some instances. In some embodiments, network node 1600 may be configured to support multiple Radio Access Technologies (RATs). In such embodiments, some components may be replicated (e.g., separate memory 1604 for different RATs), and some components may be reused (e.g., the same antenna 1610 may be shared by different RATs). Network node 1600 may also include a plurality of components comprising various wireless technologies, such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, RFID, or Bluetooth. These wireless technologies may be integrated into the same or different chips or chipsets and other components within network node 1600.

[0241] The processing circuitry 1602 may include a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field-programmable gate array, or any other suitable computing device or resource, or a combination of hardware, software and / or coding logic operable to provide the functionality of the network node 1600, either alone or in combination with other network node 1600 components (such as memory 1604).

[0242] In some embodiments, the processing circuitry 1602 includes a system-on-a-chip (SOC). In some embodiments, the processing circuitry 1602 includes one or more of a radio frequency (RF) transceiver circuitry 1612 and a baseband processing circuitry 1614. In some embodiments, the RF transceiver circuitry 1612 and the baseband processing circuitry 1614 may be on separate chips (or chipsets), boards, or units (such as radio units and digital units). In alternative embodiments, some or all of the RF transceiver circuitry 1612 and the baseband processing circuitry 1614 may be on the same chip or chipset, board, or unit.

[0243] Memory 1604 may include any form of volatile or non-volatile computer-readable memory, including, but not limited to, permanent storage devices, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drives, optical discs (CDs), or digital video discs (DVDs)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions usable by processing circuitry 1602. Memory 1604 may store any suitable instructions, data, or information, including one or more applications of computer programs, software, containing logic, rules, code, tables, and / or other instructions executable by processing circuitry 1602 and usable by network node 1600 (collectively, computer program 1604a, which may be in the form of a computer program product). Memory 1604 may be used to store any calculations performed by processing circuitry 1602 and / or any data received via communication interface 1606. In some embodiments, the processing circuitry 1602 and the memory 1604 are integrated.

[0244] Communication interface 1606 is used in wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As shown, interface 1606 includes one or more ports / terminals 1616 for transmitting and receiving data to and from a network, for example, via a wired connection. Communication interface 1606 also includes radio front-end circuitry 1618 that can be coupled to antenna 1610, or in certain embodiments may be part of antenna 1610. Radio front-end circuitry 1618 includes filter 1620 and amplifier 1622. Radio front-end circuitry 1618 can be connected to antenna 1610 and processing circuitry 1602. Radio front-end circuitry 1618 can be configured to modulate the signal transmitted between antenna 1610 and processing circuitry 1602. Radio front-end circuitry 1618 can receive digital data to be transmitted wirelessly to other network nodes or UEs. Radio front-end circuitry 1618 can use a combination of filter 1620 and / or amplifier 1622 to convert digital data into radio signals with appropriate channel and bandwidth parameters. Radio signals can then be transmitted via antenna 1610. Similarly, when data is received, antenna 1610 can collect radio signals, which are then converted into digital data by radio front-end circuitry 1618. The digital data can be transmitted to processing circuitry 1602. In other embodiments, the communication interface may include different components and / or different combinations of components.

[0245] In certain alternative embodiments, network node 1600 does not include a separate radio front-end circuitry 1618; instead, processing circuitry 1602 includes radio front-end circuitry and is connected to antenna 1610. Similarly, in some embodiments, all or part of RF transceiver circuitry 1612 is part of communication interface 1606. In other embodiments, communication interface 1606 includes one or more ports or terminals 1616, radio front-end circuitry 1618, and RF transceiver circuitry 1612 as part of a radio unit (not shown), and communication interface 1606 communicates with baseband processing circuitry 1614, which is part of a digital unit (not shown).

[0246] Antenna 1610 may include one or more antennas, or an antenna array, configured to transmit and / or receive wireless signals. Antenna 1610 may be coupled to radio front-end circuitry 1618 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In a particular embodiment, antenna 1610 is separate from network node 1600 and may be connected to network node 1600 via an interface or port.

[0247] Antenna 1610, communication interface 1606, and / or processing circuitry 1602 may be configured to perform any receive operation and / or specific acquisition operation described herein as being performed by a network node. Any information, data, and / or signals may be received from the UE, another network node, and / or any other network device. Similarly, antenna 1610, communication interface 1606, and / or processing circuitry 1602 may be configured to perform any transmit operation described herein as being performed by a network node. Any information, data, and / or signals may be transmitted to the UE, another network node, and / or any other network device.

[0248] Power supply 1608 provides power to the various components of network node 1600 in a form appropriate to the respective components (e.g., the voltage and current levels required for each respective component). Power supply 1608 may also include, or be coupled to, power management circuitry to supply power to the components of network node 1600 for performing the functions described herein. For example, network node 1600 may be connected to an external power source (e.g., mains, electrical outlet) via input circuitry or interface such as a cable, thereby supplying power to the power circuitry of power supply 1608. As another example, power supply 1608 may include a power source in the form of a battery or battery pack connected to or integrated into the power circuitry. The battery can provide backup power in the event of an external power failure.

[0249] Embodiments of network node 1600 may include, in addition to Figure 16Additional components beyond those shown are used to provide specific aspects of the functionality of the network node, including any of the functionalities described herein and / or any functionality necessary to support the subject matter described herein. For example, network node 1600 may include a user interface device that allows information to be input to and output from network node 1600. This allows users to perform diagnostic, maintenance, repair, and other control functions for network node 1600.

[0250] Figure 17 This is a block diagram of the host 1700, which may be based on the various aspects described herein. Figure 14 An embodiment of host 1416. As used herein, host 1700 can be or include various combinations of hardware and / or software, including standalone servers, blade servers, cloud-implemented servers, distributed servers, virtual machines, containers, or processing resources in a server farm. Host 1700 can provide one or more services to one or more UEs.

[0251] Host 1700 includes processing circuitry 1702 operatively coupled via bus 1704 to input / output interface 1706, network interface 1708, power supply 1710, and memory 1712. Other components may be included in other embodiments. These components may be characterized substantially similarly to those shown in the foregoing figures (such as...). Figure 15 and Figure 16 The features described in the device make its description generally applicable to the corresponding components of the host 1700.

[0252] Memory 1712 may include one or more computer programs, including one or more host applications 1714 and data 1716, the data including user data, such as data generated by the UE for the host 1700 or data generated by the host 1700 for the UE. Embodiments of the host 1700 may utilize only a subset or all of the illustrated components. The host application 1714 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Universal Video Decoding (VVC), High Efficiency Video Decoding (HEVC), Advanced Video Decoding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Decoding (AAC), MPEG, G.711), including code translation for multiple different categories, types, or implementations of UEs (e.g., mobile phones, desktop computers, wearable display systems, head-up display systems). The host application 1714 may also provide user authentication and authorization checks and may periodically report health, routing, and content availability to a central node (such as a device in or at the edge of the core network). Therefore, host 1700 can select and / or instruct different hosts for overhead services for the UE. Host application 1714 can support various protocols, such as HTTP Live Streaming (HLS), Real-time Messaging Protocol (RTMP), Real-time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0253] Figure 18 This is a block diagram illustrating a virtualized environment 1800 in which functionality implemented by some embodiments can be virtualized. In this context, virtualization means creating a virtual version of a device or apparatus that may include a virtualized hardware platform, storage devices, and networking resources. As used herein, virtualization can be applied to any apparatus or component thereof described herein and involves implementing at least a portion of its functionality as one or more virtual components. Some or all of the functionality described herein can be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1800 hosted by one or more hardware nodes, such as hardware computing devices operating as network nodes, UEs, core network nodes, or hosts. Additionally, in embodiments where virtual nodes do not require radio connectivity (e.g., core network nodes or hosts), then the nodes can be fully virtualized. In some embodiments, the virtualized environment 1800 includes components defined by the O-RAN Alliance, such as an O-cloud environment orchestrated via an O-2 interface by a service management and orchestration framework.

[0254] Application 1802 (which may alternatively be referred to as a software instance, virtual device, network function, virtual node, virtual network function, etc.) runs in virtualization environment 1800 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0255] Hardware 1804 includes processing circuitry, memory storing software and / or instructions executable by the hardware processing circuitry (collectively, referred to as computer program 1804a, which may be in the form of a computer program product), and / or other hardware devices described herein, such as network interfaces, input / output interfaces, etc. The software may be executed by the processing circuitry to instantiate one or more virtualization layers 1806 (also referred to as a hypervisor or virtual machine monitor (VMM)), provide VMs 1808a-b (one or more of which may be collectively referred to as VM 1808), and / or perform any of the functions, features, and / or benefits described with respect to some embodiments described herein. Virtualization layer 1806 may present a virtual operating platform that appears to VM 1808 as networked hardware.

[0256] VM 1808 includes virtual processing, virtual memory, virtual networking or interfaces, and virtual storage devices, and can be run by a corresponding virtualization layer 1806. Different embodiments of instances of virtual device 1802 can be implemented on one or more of VMs 1808, and this implementation can be done in different ways. Hardware virtualization is referred to in some contexts as Network Functions Virtualization (NFV). NFV can be used to consolidate many types of network devices into industry-standard high-capacity server hardware, physical switches, and physical storage devices, which can reside in data centers and customer premises.

[0257] In the context of NFV, each VM 1808 can be a software implementation of the physical machine running the program as if it were running on a physical, non-virtualized machine. Each VM 1808, and the portion of the hardware 1804 that executes that VM (whether it is dedicated to that VM and / or shared by that VM and other VMs within it), forms a separate virtual network element. Still within the context of NFV, the virtual network function is responsible for handling the specific network functions running on top of the hardware 1804 within one or more VMs 1808, and corresponds to application 1802.

[0258] Hardware 1804 may be implemented in a standalone network node with general or specific components. Hardware 1804 may implement some functions via virtualization. Alternatively, hardware 1804 may be part of a larger hardware cluster (e.g., in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1810, which, among other things, oversees the lifecycle management of application 1802. In some embodiments, hardware 1804 is coupled to one or more radio units, each radio unit including one or more transmitters and one or more receivers that can be coupled to one or more antennas. The radio units may communicate directly with other hardware nodes via one or more suitable network interfaces and may be used in combination with virtual components to provide radio capabilities to virtual nodes, such as radio access nodes or base stations. In some embodiments, some signaling may be provided using a control system 1812, which may alternatively be used for communication between hardware nodes and radio units.

[0259] Figure 19 This diagram illustrates a communication between host 1902 and UE 1906 via a partial wireless connection through network node 1904, according to some embodiments. Reference will now be made to various embodiments. Figure 19 Describe the UEs discussed in the preceding paragraphs (such as...) Figure 14 UE 1412a and / or Figure 15 UE 1500), network nodes (such as Figure 14 Network node 1410a and / or Figure 16 Network node 1600), and hosts (such as Figure 14 Host 1416 and / or Figure 17 Example implementation of host 1700.

[0260] Like host 1700, embodiments of host 1902 include hardware such as a communication interface, processing circuitry, and memory. Host 1902 also includes software stored in or accessible by host 1902 and executable by the processing circuitry. This software includes a host application operable to provide services to remote users, such as UE 1906 connected via an over-the-top (OTT) connection 1950 extending between UE 1906 and host 1902. In providing services to remote users, the host application can provide user data transmitted using OTT connection 1950.

[0261] Network node 1904 includes hardware that enables it to communicate with host 1902 and UE 1906. Connection 1960 can be direct or via a core network (like...). Figure 14The core network (1406) and / or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network could be a backbone network or the Internet.

[0262] UE 1906 includes hardware and software, the software being stored in or accessible by UE 1906 and executable by the UE's processing circuitry. The software includes client applications, such as web browsers or carrier-specific "apps," operable to provide services to human or non-human users via UE 1906 with the support of host 1902. In host 1902, the executing host application can communicate with the executing client application via OTT connection 1950, which terminates at both UE 1906 and host 1902. When providing services to a user, the UE's client application can receive request data from the host application of the host and provide user data in response to the request data. OTT connection 1950 can transmit both request data and user data. The UE's client application can interact with the user to generate user data, which is provided to the host application via OTT connection 1950.

[0263] OTT connection 1950 can be extended via connection 1960 between host 1902 and network node 1904 and via wireless connection 1970 between network node 1904 and UE 1906 to provide connectivity between host 1902 and UE 1906. Connection 1960 and wireless connection 1970, through which OTT connection 1950 is provided, have been abstractly depicted to illustrate communication between host 1902 and UE 1906 via network node 1904, without explicitly mentioning any intermediate devices or the precise message routing via these devices.

[0264] As an example of data transmission via OTT connection 1950, in step 1908, host 1902 provides user data, which can be performed by executing a host application. In some embodiments, the user data is associated with a specific human user interacting with UE 1906. In other embodiments, the user data is associated with UE 1906, which shares data with host 1902 without explicit human interaction. In step 1910, host 1902 initiates a transmission carrying user data toward UE 1906. Host 1902 may initiate the transmission in response to a request transmitted by UE 1906. This request may be caused by human interaction with UE 1906 or by the operation of a client application executed on UE 1906. According to the teachings of the embodiments described throughout this disclosure, the transmission may be carried out via network node 1904. Thus, in step 1912, according to the teachings of the embodiments described throughout this disclosure, network node 1904 transmits the user data carried in the transmission initiated by host 1902 to UE 1906. In step 1914, UE1906 receives user data carried in the transmission, which can be performed by a client application running on UE1906, which is associated with a host application running by host1902.

[0265] In some examples, UE 1906 executes a client application that provides user data to host 1902. The user data may be provided as a reaction or response to data received from host 1902. Thus, in step 1916, UE 1906 can provide user data, which can be done by executing a client application. When providing user data, the client application may further consider user input received from a user via the input / output interface of UE 1906. Regardless of the specific manner in which user data is provided, in step 1918, UE 1906 initiates user data transmission toward host 1902 via network node 1904. In step 1920, in accordance with the teachings of the embodiments described throughout this disclosure, network node 1904 receives user data from UE 1906 and initiates transmission of the received user data toward host 1902. In step 1922, host 1902 receives the user data carried in the transmission initiated by UE 1906.

[0266] One or more embodiments in various implementations can improve the performance of OTT services provided to UE 1906 using OTT connection 1950, where radio connection 1970 forms the final segment. More precisely, embodiments can facilitate proper operation of L3 mobility when LTM is also configured for the UE by releasing LTM configurations that are not applicable after L3 mobility procedures, such as LTM configurations(one or more) within CUs that are not applicable after inter-CU L3 mobility procedures. Embodiments can also facilitate LTM configuration for the UE during L3 mobility procedure configuration or execution, such as when a target RAN node provides LTM configurations(one or more) applicable after the UE completes L3 mobility procedures. Furthermore, embodiments can improve UE mobility in the RAN (e.g., NG-RAN) by improving L3 mobility and LTM interoperability. By improving UE and RAN operation in this way, embodiments can increase the value of OTT services delivered to / from the UE via the RAN.

[0267] In the example scenario, host 1902 can collect and analyze plant status information. As another example, host 1902 can process audio and video data that may have been retrieved from the UE for map creation. As another example, host 1902 can collect and analyze real-time data to assist in controlling traffic congestion (e.g., controlling traffic lights). As another example, host 1902 can store surveillance video uploaded by the UE. As another example, host 1902 can store or control access to media content such as video, audio, VR, or AR, which the host can broadcast, multicast, or unicast to the UE. As other examples, host 1902 can be used for energy pricing, remotely controlling non-time-critical electrical loads to balance generation demand, location services, presentation services (such as compiling diagrams based on data collected from remote devices), or any other function that collects, retrieves, stores, analyzes, and / or transmits data.

[0268] In some examples, measurement procedures may be provided for the purpose of monitoring data rates, latency, and other factors that improve upon one or more embodiments. Optional network functionality may further exist for reconfiguring the OTT connection 1950 between host 1902 and UE 1906 in response to changes in measurement results. Measurement procedures and / or network functionality for reconfiguring the OTT connection may be implemented using software and hardware of host 1902 and / or UE 1906. In some embodiments, sensors (not shown) may be deployed in or associated with other devices traversed by the OTT connection 1950; sensors may participate in the measurement procedure by providing values ​​of the monitored quantities illustrated above, or by providing values ​​of other physical quantities from which software can calculate or estimate the monitored quantities. Reconfiguring the OTT connection 1950 may include message formats, retransmission settings, preferred routing, etc.; reconfiguration does not require direct changes to the operation of network node 1904. Such procedures and functionality may be known and practiced in the art. In certain embodiments, the measurement may involve proprietary UE signaling that facilitates measurements of throughput, propagation time, latency, etc., by host 1902. The measurement can be implemented by software enabling the transmission of messages, particularly empty or “false” messages, using OTT connection 1950, while simultaneously monitoring propagation time, errors, etc.

[0269] The foregoing has merely illustrated the principles of this disclosure. Various modifications and variations to the described embodiments will be apparent to those skilled in the art in light of the teachings herein. Thus, it will be appreciated that those skilled in the art will be able to design numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of this disclosure and are therefore within the spirit and scope of this disclosure. As will be understood by those skilled in the art, the various embodiments can be used together and interchangeably.

[0270] The foregoing has merely illustrated the principles of this disclosure. Various modifications and variations to the described embodiments will be apparent to those skilled in the art in light of the teachings herein. Thus, it will be appreciated that those skilled in the art will be able to design numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of this disclosure and are therefore within the spirit and scope of this disclosure. As will be understood by those skilled in the art, the various embodiments can be used together and interchangeably.

[0271] As used herein, the term "unit" can have a conventional meaning in the fields of electronics, electrical devices and / or electronic devices, and can include, for example, electrical and / or electronic circuits, devices, modules, processors, memories, logic solid-state and / or discrete devices, computer programs or instructions for performing corresponding tasks, procedures, calculations, outputs and / or display functions, etc., as described herein.

[0272] Any suitable steps, methods, features, functions, or benefits disclosed herein may be performed by one or more functional units or modules of one or more virtual devices. Each virtual device may include several such functional units. These functional units may be implemented via processing circuitry and other digital hardware, which may include one or more microprocessors or microcontrollers, and the digital hardware may include digital signal processors (DSPs), application-specific digital logic, etc. The processing circuitry may be configured to execute program code stored in memory, which may include one or more types of memory, such as read-only memory (ROM), random access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. The program code stored in memory includes program instructions for executing one or more telecommunications and / or data communication protocols, and instructions for executing one or more of the techniques described herein. In some implementations, according to one or more embodiments of this disclosure, the processing circuitry may be used to cause corresponding functional units to perform corresponding functions.

[0273] As described herein, devices and / or apparatuses may be represented by semiconductor chips, chipsets, or (hardware) modules including such chips or chipsets; however, this does not preclude the possibility that the functionality of a device or apparatus may be implemented as a software module rather than by hardware, such a software module being a computer program or computer program product comprising executable software code portions for execution or execution on a processor. Furthermore, the functionality of a device or apparatus may be achieved through any combination of hardware and software. A device or apparatus may also be considered as an assembly of multiple devices and / or apparatuses, whether functionally cooperative or independent of each other. Moreover, devices and apparatuses may be implemented in a distributed manner throughout a system, provided that the functionality of the device or apparatus is preserved. Such and similar principles are considered to be known to those skilled in the art.

[0274] Furthermore, the functions performed by wireless devices or network nodes as described herein can be distributed across multiple wireless devices and / or network nodes. In other words, it is conceivable that the functions of the network nodes and wireless devices described herein are not limited to being performed by a single physical device, and in fact, can be distributed among several physical devices.

[0275] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It will be further understood that the terms used herein shall be interpreted as having the same meaning as they have in the context of this specification and the relevant field, and shall not be interpreted in an idealized or overly formal sense unless expressly defined herein.

[0276] Furthermore, certain terms used in this disclosure (including the specification and drawings) may be used synonymously in certain circumstances (e.g., "data" and "information"). It should be understood that although these terms (and / or other terms that are synonymous with each other) may be used synonymously herein, there may be instances where such terms are not intended to be used synonymously.

[0277] The technologies and devices described herein include, but are not limited to, the following examples: A1. A method for a user equipment (UE) configured to perform a Layer 3 (L3) mobility procedure in a radio access network (RAN), the method comprising: Receive configuration for inter-cell mobility (LTM) procedures triggered by Layer 1 (L2) or Layer 2 (L2) in the RAN via the source cell in the RAN; Managing LTM configurations related to L3 mobility procedures involving target cells in the RAN includes one or more of the following management operations: Maintain the LTM configuration; Release the LTM configuration; Modify the LTM configuration; and Add a second LTM configuration.

[0278] A2. The method of embodiment A1, wherein managing LTM configuration is performed during or during the execution of L3 mobility procedures.

[0279] A3. The method of embodiment A2, wherein managing LTM configuration is based on whether the target cell is provided by a different RAN node than the source cell based on the L3 mobility protocol.

[0280] A3a. The method of embodiment A3, wherein managing the LTM configuration includes: When the target cell is provided by a different RAN node than the source cell, release the LTM configuration; and When the target cell is provided by the same RAN node as the source cell, maintain the LTM configuration.

[0281] A4. The method of any of the embodiments A1-A2 further includes receiving an indication from the RAN of one or more management operations to be performed, wherein the management LTM configuration is in response to the indication.

[0282] A4a. The method of embodiment A4, wherein the instruction is received in one of the following ways: L3 messages from the source cell or the target cell; L2 messages from the source cell or the target cell; L1 message from the source cell.

[0283] A4b. The method of embodiment A4, wherein the instruction is in one of the following data structures of the L3 message: ToAddMod, ToRelease, or SetupRelease.

[0284] A4c. The method of any of the embodiments A4-A4b, wherein the L3 mobility procedure is an unconditional mobility procedure, and the instruction is received in or together with a command to execute the unconditional mobility procedure.

[0285] A4d. The method of any of the embodiments A4-A4b, wherein the L3 mobility procedure is a conditional mobility procedure, and the indication is received in or together with a conditional configuration for the conditional mobility procedure.

[0286] A4e. The method of any of the embodiments A4-A4d, wherein the indication includes one or more of the following: Instructions to release the LTM configuration; The second LTM configuration to be added; Instructions to release or modify a portion of the LTM configuration; and Information to be added to the LTM configuration.

[0287] A4f. The method of embodiment A4e, wherein one or more of the following are applicable: The portion of the LTM configuration to be released or modified includes one or more LTM candidate cell configurations; and The information to be added includes one or more LTM candidate cell configurations.

[0288] A4g. The method of any of the embodiments A4-A4f further includes sending an acknowledgment or response to the RAN that the indicated management operation has been performed.

[0289] A5. The method of any of the embodiments A1-A4g, wherein the LTM configuration includes one or more of the following: One or more LTM candidate cells are configured; Measurement and reporting configuration for LTM candidate cells; Downlink (DL) pre-synchronization configuration for LTM; Uplink (UL) pre-synchronization configuration for LTM; and Configuration for executing LTM cell handover procedures to the corresponding LTM candidate cell.

[0290] A5a. The method of embodiment A5, wherein modifying the LTM configuration includes one or more of the following: Release one of the multiple LTM candidate cell configurations while maintaining the others; and Add another LTM candidate cell configuration to the LTM candidate cell configuration.

[0291] A6. The method of any of the embodiments A1-A5a, wherein the L3 mobility procedure is one of the following: handover, dual active protocol stack (DAPS) handover synchronization reconfiguration, conditional handover, conditional reconfiguration, primary SCG cell (PSCell) change, conditional PSCell change, conditional PSCell addition, secondary node (SN) change, SN modification, primary node (MN) change.

[0292] B1. A method for a radio access network RAN ​​node, the RAN node being configured to provide a source cell for a user equipment (UE) Layer 3 (L3) mobility protocol, the method comprising: The configuration for inter-cell mobility (LTM) procedures triggered by Layer 1 (L2) or Layer 2 (L2) in the RAN is sent to the UE via the source cell; and Managing LTM configuration related to L3 mobility procedures for UEs in a target cell within the RAN includes one or more of the following management operations: Maintain the LTM configuration; Release the LTM configuration; Modify the LTM configuration; and Add a second LTM configuration.

[0293] B2. The method of embodiment B1, wherein managing LTM configuration is performed during or during the execution of L3 mobility procedures.

[0294] B3. The method of embodiment B2, wherein managing LTM configuration is based on whether the target cell of the L3 mobility protocol is provided by another RAN node.

[0295] B3a. The method of embodiment B3, wherein managing the LTM configuration includes: When the target cell is provided by another RAN node, release the LTM configuration; and When the target cell is provided by the RAN node, maintain the LTM configuration.

[0296] B4. The method of any of the embodiments B1-B2 further includes sending an instruction to the UE for one or more corresponding management operations to be performed by the UE on the LTM configuration.

[0297] B4a. The method of embodiment B4, wherein the instruction is sent to the UE via the source cell in one of the following ways: L3 message, L2 message or L1 message.

[0298] B4b. The method of embodiment B4a, wherein the instruction is in one of the following data structures of the L3 message: ToAddMod, ToRelease, or SetupRelease.

[0299] B4c. The method of any of the embodiments B4-B4b, wherein the L3 mobility procedure is an unconditional mobility procedure, and the instruction is sent to the UE in or together with the command to execute the unconditional mobility procedure.

[0300] B4d. The method of any of the embodiments B4-B4b, wherein the L3 mobility procedure is a conditional mobility procedure, and the instruction is sent to the UE in or together with the conditional configuration for the conditional mobility procedure.

[0301] B4e. The method of any of the embodiments B4-B4d, wherein the indication sent to the UE includes one or more of the following: Instructions to release the LTM configuration; The second LTM configuration to be added; Instructions to release or modify a portion of the LTM configuration; and Information to be added to the LTM configuration.

[0302] B4f. The method of embodiment B4e, wherein one or more of the following are applicable: The portion of the LTM configuration to be released or modified includes one or more LTM candidate cell configurations; and The information to be added includes one or more LTM candidate cell configurations.

[0303] B4g. The method of any of the embodiments B4-B4f further includes receiving from the UE an acknowledgment or response that the corresponding management operation has been performed.

[0304] B5. The method of any of the embodiments B1-B4g, wherein the LTM configuration includes one or more of the following: One or more LTM candidate cells are configured; Measurement and reporting configuration for LTM candidate cells; Downlink (DL) pre-synchronization configuration for LTM; Uplink (UL) pre-synchronization configuration for LTM; and Configuration for executing LTM cell handover procedures to the corresponding LTM candidate cell.

[0305] B5a. The method of embodiment B5, wherein modifying the LTM configuration includes one or more of the following: Release one of the multiple LTM candidate cell configurations while maintaining the others; and Add another LTM candidate cell configuration to the LTM candidate cell configuration.

[0306] B6. The method of any of the embodiments B1-B5a further includes: Send a request to the target RAN node providing the target cell to execute the UE's L3 mobility procedure; and Receive the following from the target RAN node: configuration of the L3 mobility protocol for the UE, and instructions for one or more management operations to be performed on the LTM configuration.

[0307] B6a. The method of embodiment B6, wherein the request to execute the L3 mobility procedure includes at least a portion of the LTM configuration.

[0308] B6b. The method of any of the embodiments B6-B6a, wherein the indication from the target RAN node includes one or more of the following: The target RAN node does not support LTM indication; Instructions to release the LTM configuration; The second LTM configuration to be added; Instructions to release or modify a portion of the LTM configuration; and Information to be added to the LTM configuration.

[0309] B6c. The method of embodiment B6b, wherein one or more of the following are applicable: The portion of the LTM configuration to be released or modified includes one or more LTM candidate cell configurations; and The information to be added includes one or more LTM candidate cell configurations.

[0310] B7. The method of any of the embodiments B1-B6c, wherein the L3 mobility procedure is one of the following: handover, dual active protocol stack (DAPS) handover synchronization reconfiguration, conditional handover, conditional reconfiguration, primary SCG cell (PSCell) change, conditional PSCell change, conditional PSCell addition, secondary node (SN) change, SN modification, primary node (MN) change.

[0311] C1. A method for a radio access network (RAN) node configured to provide a target cell with a user equipment (UE) Layer 3 (L3) mobility protocol, the method comprising: Regarding L3 mobility procedures involving UEs in the target cell, the management of configuration for Layer 1 (L2) or Layer 2 (L2) triggered inter-cell mobility (LTM) procedures involving UEs in the source cell of the RAN includes one or more of the following management operations: Maintain the LTM configuration; Release the LTM configuration; Modify the LTM configuration; and Add a second LTM configuration.

[0312] C2. The method of embodiment C1, wherein managing LTM configuration is performed during or during the execution of L3 mobility procedures.

[0313] C3. The method of embodiment C2, wherein managing LTM configuration is based on whether the source cell is provided by another RAN node.

[0314] C3a. The method of embodiment C3, wherein managing the LTM configuration includes: When the source cell is provided by another RAN node, release the LTM configuration; and When the source cell is provided by the RAN node, maintain the LTM configuration.

[0315] C4. The method of any of the embodiments B1-B2 further includes sending an indication to the UE of one or more corresponding management operations to be performed by the UE on the LTM configuration.

[0316] C4a. The method of embodiment C4, wherein the instruction is sent to the UE via the target cell in an L3 message or an L2 message.

[0317] C4b. The method of embodiment C4a, wherein the instruction is in one of the following data structures of the L3 message: ToAddMod, ToRelease, or SetupRelease.

[0318] C4c. A method of any of embodiments C4-C4b, wherein the indication sent to the UE includes one or more of the following: The target RAN node does not support LTM indication; Instructions to release the LTM configuration; The second LTM configuration to be added; Instructions to release or modify a portion of the LTM configuration; and Information to be added to the LTM configuration.

[0319] C4d. The method of embodiment C4c, wherein one or more of the following are applicable: The portion of the LTM configuration to be released or modified includes one or more LTM candidate cell configurations; and The information to be added includes one or more LTM candidate cell configurations.

[0320] C4e. The method of any of the embodiments C4-C4d further includes receiving from the UE an acknowledgment or response that the corresponding management operation has been performed.

[0321] C5. The method of any of the embodiments C1-C4e, wherein the LTM configuration includes one or more of the following: One or more LTM candidate cells are configured; Measurement and reporting configuration for LTM candidate cells; Downlink (DL) pre-synchronization configuration for LTM; Uplink (UL) pre-synchronization configuration for LTM; and Configuration for executing LTM cell handover procedures to the corresponding LTM candidate cell.

[0322] C5a. The method of embodiment C5, wherein modifying the LTM configuration includes one or more of the following: Release one of the multiple LTM candidate cell configurations while maintaining the others; and Add another LTM candidate cell configuration to the LTM candidate cell configuration.

[0323] C6. The method of any one of the embodiments C1-C5a further includes: Receive a request from the source RAN node providing the source cell to execute the UE's L3 mobility procedure; and Receive the following from the target RAN node: configuration of the L3 mobility protocol for the UE, and instructions for one or more management operations to be performed on the LTM configuration.

[0324] C6a. The method of embodiment C6, wherein the request to execute the L3 mobility procedure includes at least a portion of the LTM configuration.

[0325] C6b. The method of any of the embodiments C6-C6a, wherein the indication sent to the source RAN node includes one or more of the following: The target RAN node does not support LTM indication; Instructions to release the LTM configuration; The second LTM configuration to be added; Instructions to release or modify a portion of the LTM configuration; and Information to be added to the LTM configuration.

[0326] C6c. The method of embodiment C6b, wherein one or more of the following are applicable: The portion of the LTM configuration to be released or modified includes one or more LTM candidate cell configurations; and The information to be added includes one or more LTM candidate cell configurations.

[0327] C7. The method of any of the embodiments C1-C6c, wherein the L3 mobility procedure is one of the following: handover, dual active protocol stack (DAPS) handover synchronization reconfiguration, conditional handover, conditional reconfiguration, primary SCG cell (PSCell) change, conditional PSCell change, conditional PSCell addition, secondary node (SN) change, SN modification, primary node (MN) change.

[0328] D1. A user equipment (UE) configured to perform a Layer 3 (L3) mobility procedure from a source cell to a destination cell in a radio access network (RAN), the UE comprising: The communication interface circuit is configured to communicate with both the source and target cells; and The processing circuit is operatively coupled to the communication interface circuit, wherein the processing circuit and the communication interface circuit are further configured to perform operations corresponding to any of the methods in embodiments A1-A7.

[0329] D2. A user equipment (UE) configured to perform a Layer 3 (L3) mobility procedure from a source cell to a target cell in a radio access network (RAN), the UE being further configured to perform an operation corresponding to any of the methods in embodiments A1-A7.

[0330] D3. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by a user equipment (UE) processing circuit configured to perform an operation corresponding to any of the methods in embodiments A1-A7, in accordance with the method of embodiment A1-A7.

[0331] D4. A computer program product including computer-executable instructions that, when executed by a user equipment (UE) processing circuit configured to perform an operation corresponding to any of the methods in embodiments A1-A7, in accordance with the method of embodiment A1-A7.

[0332] E1. A radio access network (RAN) node configured to provide a source cell for a user equipment (UE) Layer 3 (L3) mobility protocol, the RAN node comprising: A communication interface circuit is configured to communicate with the UE via a source cell and with a target RAN node of a target cell configured to provide the UE's L3 mobility protocol; and The processing circuit is operatively coupled to the communication interface circuit, wherein the processing circuit and the communication interface circuit are configured to perform operations corresponding to any of the methods in embodiments B1-B7.

[0333] E2. A radio access network (RAN) node configured to provide a source cell for a user equipment (UE) layer 3 (L3) mobility protocol, the RAN node being further configured to perform operations corresponding to any of the methods in embodiments B1-B7.

[0334] E3. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by processing circuitry of a radio access network (RAN) node of a source cell configured to provide a user equipment (UE) Layer 3 (L3) mobility protocol, configure the RAN node to perform operations corresponding to any of the methods in embodiments B1-B7.

[0335] E4. A computer program product including computer-executable instructions that, when executed by processing circuitry of a radio access network (RAN) node of a source cell configured to provide a user equipment (UE) Layer 3 (L3) mobility protocol, configure the RAN node to perform operations corresponding to any of the methods in embodiments B1-B7.

[0336] F1. A radio access network (RAN) node configured to provide a target cell with a user equipment (UE) Layer 3 (L3) mobility protocol, the RAN node comprising: The communication interface circuitry is configured to communicate with the UE via a target cell and with the source RAN node of the source cell configured to provide the UE's L3 mobility protocol; and The processing circuit is operatively coupled to the communication interface circuit, wherein the processing circuit and the communication interface circuit are configured to perform operations corresponding to any of the methods in embodiments C1-C7.

[0337] F2. A radio access network (RAN) node configured to provide a target cell for a user equipment (UE) layer 3 (L3) mobility protocol, the RAN node being further configured to perform operations corresponding to any of the methods in embodiments C1-C7.

[0338] F3. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by processing circuitry of a radio access network (RAN) node of a target cell configured to provide a user equipment (UE) Layer 3 (L3) mobility protocol, configure the RAN node to perform operations corresponding to any of the methods in embodiments C1-C7.

[0339] F4. A computer program product including computer-executable instructions that, when executed by processing circuitry of a radio access network (RAN) node of a target cell configured to provide a user equipment (UE) Layer 3 (L3) mobility protocol, configure the RAN node to perform operations corresponding to any of the methods in embodiments C1-C7.

Claims

1. A method for a user equipment, UE, configured to perform a layer 3, L3, mobility procedure in a radio access network, RAN, the method comprising: receiving, via a source cell in the RAN, a configuration for a layer 1 or layer 2 triggered inter-cell mobility, LTM, procedure in the RAN; managing (1130) the LTM configuration during preparation or execution of an L3 mobility procedure to a target cell in the RAN, including one or more of the following management operations: maintaining (1131) the LTM configuration; releasing (1132) the LTM configuration; modifying (1133) the LTM configuration; and adding (1134) a second LTM configuration.

2. The method of claim 1, wherein: releasing (1132) the LTM configuration is performed when the target cell is provided by a different RAN node than the source cell; and maintaining (1131) the LTM configuration is performed when the target cell is provided by a same RAN node as the source cell.

3. The method of any of claims 1-2, further comprising receiving (1120), from the RAN, an indication of one or more of the management operations to perform, wherein, managing (1130) the LTM configuration is performed based on the indication.

4. The method of claim 3, wherein, the indication is received in an L3 mobility command.

5. The method of any one of claims 3-4, wherein, the L3 mobility procedure is a conditional mobility procedure and the indication is received in or with a conditional configuration for the conditional mobility procedure.

6. The method of any one of claims 3-5, wherein, the indication comprises one or more of: an indication to release the LTM configuration; a second LTM configuration to add; an indication of a part of the LTM configuration to release or modify; and information to add to the LTM configuration.

7. The method of claim 6, wherein, one or more of the following apply: the indicated part of the LTM configuration to release or modify comprises one or more LTM candidate cell configurations; and the information to add comprises one or more LTM candidate cell configurations.

8. The method of any of claims 3-7, further comprising sending (1140) an acknowledgement or reply to the RAN that the indicated management operation has been performed.

9. The method of any of claims 1-8, wherein: the LTM configuration comprises one or more LTM candidate cell configurations; and modifying (1133) the LTM configuration comprises one or more of: releasing one of the LTM candidate cell configurations while maintaining others of the LTM candidate cell configurations; and adding a further LTM candidate cell configuration to the one or more LTM candidate cell configurations.

10. The method of any one of claims 1-9, wherein, the L3 mobility procedure is one of: handover; reconfiguration with sync; conditional handover; conditional reconfiguration; primary SCG cell, PSCell, change; conditional PSCell change; conditional PSCell addition; secondary node, SN, change; SN modification; and master node, MN, change.

11. A method for a radio access network, RAN, node configured to provide a target cell for a user equipment, UE, layer 3, L3, mobility procedure, the method comprising: managing (1340), during preparation or execution of a L3 mobility procedure of the UE to the target cell, a configuration of a layer 1 or layer 2 triggered inter-cell mobility, LTM, procedure for the UE from a source cell in the RAN, including one or more of the following management operations: maintaining (1341) the LTM configuration; releasing (1342) the LTM configuration; modifying (1343) the LTM configuration; and adding (1344) a second LTM configuration.

12. The method of claim 11, wherein: releasing (1342) the LTM configuration is performed when the source cell is provided by another RAN node; and maintaining (1341) the LTM configuration is performed when the source cell is provided by the RAN node.

13. The method of any of claims 11-12, further comprising sending (1350), to the UE via the target cell, an indication of one or more corresponding management operations to be performed by the UE on the LTM configuration.

14. The method of claim 13, wherein, the indication is sent in a L3 mobility command.

15. The method of any one of claims 13-14, wherein, the indication sent to the UE comprises one or more of: an indication that the target RAN node does not support LTM; an indication to release the LTM configuration; a second LTM configuration to be added; an indication of a part of the LTM configuration to be released or modified; and information to be added to the LTM configuration.

16. The method of any of claims 13-15, further comprising receiving (1360), from the UE, a confirmation or acknowledgement that the corresponding management operations have been performed.

17. The method of any of claims 11-16, wherein: the LTM configuration comprises one or more LTM candidate cell configurations; and modifying (1343) the LTM configuration comprises one or more of: releasing one of the LTM candidate cell configurations while maintaining others of the LTM candidate cell configurations; and adding further LTM candidate cell configurations to the one or more LTM candidate cell configurations.

18. The method of any of claims 11-17, further comprising: receiving (1320), from a source RAN node providing the source cell, a request to perform the L3 mobility procedure of the UE; sending (1330), to the source RAN node, a configuration for the L3 mobility procedure of the UE and an indication to release at least a part of the LTM configuration. the indication to release at least a part of the LTM configuration is one of: an indication that the target RAN node does not support LTM; 19. The method of claim 18, wherein, an explicit indication to release the LTM configuration; and an indication of one or more LTM candidate cell configurations of the LTM configuration to be released. the L3 mobility procedure is one of: handover; reconfiguration with sync; conditional handover; conditional reconfiguration; primary SCG cell, PSCell, change; conditional PSCell change; conditional PSCell addition; secondary node, SN, change; SN modification; and master node, MN, change. ​ 20. The method of any one of claims 11-19, wherein, ​ 21. A method for a radio access network, RAN, node configured to provide a source cell of a user equipment, UE, layer 3, L3, mobility procedure, the method comprising: sending (1210), via the source cell, to a UE, a configuration for a layer 1 or layer 2 triggered inter-cell mobility, LTM, procedure in the RAN; and releasing (1240), during preparation or execution of the L3 mobility procedure of the UE to a target cell in the RAN, at least a part of the LTM configuration.

22. The method of claim 21, wherein, The releasing (1240) of at least a part of the LTM configuration is performed based on the target cell of the L3 mobility procedure provided by another RAN node.

23. The method of any of claims 21-22, further comprising sending (1250), via the source cell, to the UE, a L3 mobility command comprising an indication to release at least a part of the LTM configuration.

24. The method of any one of claims 21-23, wherein, The L3 mobility procedure is a conditional mobility procedure and the indication is sent to the UE in or with a conditional configuration for the conditional mobility procedure.

25. The method of any of claims 21-24, further comprising receiving (1260), from the UE, an acknowledgement or reply that the UE released at least a part of the LTM configuration.

26. The method of any of claims 21-25, further comprising: sending (1220) to a target RAN node providing the target cell, a request to perform the L3 mobility procedure of the UE; and receiving (1230), from the target RAN node, a configuration for the L3 mobility procedure of the UE and an indication to release at least a part of the LTM configuration, wherein the releasing (1240) of at least a part of the LTM configuration is in response to the received indication.

27. The method of claim 26, wherein, The indication to release at least a part of the LTM configuration is one of: an indication that the target RAN node does not support LTM; an explicit indication to release the LTM configuration; and an indication of one or more LTM candidate cell configurations of the LTM configuration to be released.

28. The method of any one of claims 21-27, wherein, The L3 mobility procedure is one of: handover; reconfiguration with sync; conditional handover; conditional reconfiguration; primary SCG cell, PSCell, change; conditional PSCell change; conditional PSCell addition; secondary node, SN, change; SN modification; and master node, MN, change.

29. A user equipment, UE (210, 510, 601, 1412, 1500) configured to perform a layer 3, L3, mobility procedure from a source cell to a target cell in a radio access network, RAN (199, 600, 1404), the UE comprising: communication interface circuitry (1512) configured to communicate with the source cell and the target cell; and processing circuitry (1502) operably coupled to the communication interface circuitry, wherein the processing circuitry and the communication interface circuitry are configured to: receive, via the source cell, a configuration for a layer 1 or layer 2 triggered inter-cell mobility, LTM, procedure in the RAN; and manage the LTM configuration during preparation or execution of the L3 mobility procedure to a target cell in the RAN, including one or more of the following management operations: maintain the LTM configuration; release the LTM configuration; modify the LTM configuration; and add a second LTM configuration.

30. The UE of claim 29, wherein, the processing circuitry and the communication interface circuitry are further configured to perform operations corresponding to the methods of any of claims 2-10.

31. A user equipment, UE (210, 510, 601, 1412, 1500) configured to perform a layer 3, L3, mobility procedure from a source cell to a target cell in a radio access network, RAN (199, 600, 1404), the UE further configured to: receive, via the source cell, a configuration for a layer 1 or layer 2 triggered inter-cell mobility, LTM, procedure in the RAN; and manage the LTM configuration during preparation or execution of the L3 mobility procedure to a target cell in the RAN, including one or more of the following management operations: maintain the LTM configuration; release the LTM configuration; modify the LTM configuration; and add a second LTM configuration.

32. The UE of claim 31, further configured to perform operations corresponding to the methods of any of claims 2-10.

33. A non-transitory computer-readable medium (1510) storing computer-executable instructions that, when executed by processing circuitry (1502) of a user equipment, UE (210, 510, 601, 1412, 1500) configured to perform a layer 3, L3, mobility procedure from a source cell to a target cell in a radio access network, RAN (199, 600, 1404), configure the UE to perform operations corresponding to the methods of any of claims 1-10.

34. A computer program product (1514) comprising computer-executable instructions that, when executed by processing circuitry (1502) of a user equipment, UE (210, 510, 601, 1412, 1500) configured to perform a layer 3, L3, mobility procedure from a source cell to a target cell in a radio access network, RAN (199, 600, 1404), configure the UE to perform operations corresponding to the methods of any of claims 1-10.

35. A radio access network, RAN, node (100, 150, 220, 530, 603, 1410, 1600, 1802) configured to provide a target cell for a layer 3, L3, mobility procedure of a user equipment, UE (210, 510, 601, 1412, 1500), the RAN node comprising: a communication interface circuit (1606, 1804) configured to communicate with a UE via the target cell and to communicate with a source RAN node (100, 150, 220, 530, 602, 1410, 1600, 1802) configured to provide a source cell of a layer 3, L3, mobility procedure for the UE; and a processing circuit (1602, 1804) operably coupled to the communication interface circuit, wherein the processing circuit and the communication interface circuit are configured to: manage configuration of a layer 1 or layer 2 triggered inter-cell mobility, LTM, procedure for the UE from the source cell during preparation or execution of the L3 mobility procedure for the UE to the target cell, including one or more of the following management operations: maintain the LTM configuration; release the LTM configuration; modify the LTM configuration; and add a second LTM configuration.

36. The RAN node of claim 35, wherein, the processing circuit and the communication interface circuit are further configured to perform operations corresponding to the methods of any of claims 12-20.

37. A radio access network, RAN, node (100, 150, 220, 530, 603, 1410, 1600, 1802) configured to provide a target cell of a layer 3, L3, mobility procedure for a user equipment, UE (210, 510, 601, 1412, 1500), the RAN node being further configured to: manage configuration of a layer 1 or layer 2 triggered inter-cell mobility, LTM, procedure for the UE from a source cell in the RAN during preparation or execution of the L3 mobility procedure for the UE to the target cell, including one or more of the following management operations: maintain the LTM configuration; release the LTM configuration; modify the LTM configuration; and add a second LTM configuration.

38. The RAN node of claim 37, further configured to perform operations corresponding to the methods of any of claims 12-20.

39. A non-transitory computer-readable medium (1604, 1804) storing computer-executable instructions that, when executed by a processing circuit (1602, 1804) of a radio access network, RAN, node (100, 150, 220, 530, 603, 1410, 1600, 1802) configured to provide a target cell of a layer 3, L3, mobility procedure for a user equipment, UE (210, 510, 601, 1412, 1500), configure the RAN node to perform operations corresponding to the methods of any of claims 11-20.

40. A computer program product (1604a, 1804a) comprising computer-executable instructions that, when executed by processing circuitry (1602, 1804) of a radio access network, RAN, node (100, 150, 220, 530, 603, 1410, 1600, 1802) configured to provide a target cell of a user equipment, UE (210, 510, 601, 1412, 1500), layer 3, L3, mobility procedure, configure the RAN node to perform operations corresponding to the methods of any of claims 11-20.

41. A radio access network, RAN, node (100, 150, 220, 520, 602, 1410, 1600, 1802) configured to provide a source cell of a user equipment, UE (210, 510, 601, 1412, 1500), layer 3, L3, mobility procedure, the RAN node comprising: communication interface circuitry (1606, 1804) configured to communicate with a UE via the target cell and with a target RAN node (100, 150, 220, 530, 603, 1410, 1600, 1802) configured to provide a target cell of a UE L3 mobility procedure; and processing circuitry (1602, 1804) operably coupled to the communication interface circuitry, wherein the processing circuitry and the communication interface circuitry are configured to: send, to the UE via the source cell, a configuration for a layer 1 or layer 2 triggered inter-cell mobility, LTM, procedure in the RAN; and release at least a portion of the LTM configuration during preparation or execution of the UE’s L3 mobility procedure to the target cell.

42. The RAN node of claim 41, wherein, the processing circuitry and the communication interface circuitry are further configured to perform operations corresponding to the methods of any of claims 22-28.

43. A radio access network, RAN, node (100, 150, 220, 520, 602, 1410, 1600, 1802) configured to provide a source cell of a user equipment, UE (210, 510, 601, 1412, 1500), layer 3, L3, mobility procedure, the RAN node being further configured to: send, to the UE via the source cell, a configuration for a layer 1 or layer 2 triggered inter-cell mobility, LTM, procedure in the RAN; and release at least a portion of the LTM configuration during preparation or execution of the UE’s L3 mobility procedure to a target cell in the RAN.

44. The RAN node of claim 43, being further configured to perform operations corresponding to the methods of any of claims 22-28.

45. A non-transitory computer-readable medium (1604, 1804) storing computer-executable instructions that, when executed by processing circuitry (1602, 1804) of a radio access network, RAN, node (100, 150, 220, 520, 602, 1410, 1600, 1802) configured to provide a source cell of a user equipment, UE (210, 510, 601, 1412, 1500), layer 3, L3, mobility procedure, configure the RAN node to perform operations corresponding to the methods of any of claims 21-28.

46. A computer program product (1604a, 1804a) comprising computer-executable instructions that, when executed by processing circuitry (1602, 1804) of a radio access network, RAN, node (100, 150, 220, 520, 602, 1410, 1600, 1802) configured to provide a source cell of a user equipment, UE (210, 510, 601, 1412, 1500), layer 3, L3, mobility procedure, configure the RAN node to perform operations corresponding to the methods of any of claims 21-28.

Images