Instructions for LTM candidates after execution

Abstract

Methods, apparatus, and systems for improved Layer 1 / Layer 2 triggered mobility (LTM) in wireless networks. An exemplary method for user equipment (UE) includes receiving an LTM candidate cell configuration from a wireless network (910), performing a first LTM cell switching procedure (930), and sending an LTM cell switching complete message to the wireless network, including instructions for the applied LTM candidate (940).

Description

Technical Field

[0001] This application generally relates to the field of wireless networks, and more particularly to the mobility of user equipment (UE) across multiple cells in a wireless network, specifically mobility based on layer 1 (L1) and / or layer 2 (L2) procedures, also referred to as L1 / L2-triggered mobility or “LTM”.

Background Art

[0002] Currently, the fifth generation (“5G”) of cellular systems, also referred to as New Radio (NR), is being standardized within the 3rd Generation Partnership Project (3GPP). NR has been developed for maximum flexibility to support a plurality of substantially different use cases. These include enhanced mobile broadband (eMBB), machine type communication (MTC), ultra-reliable low latency communication (URLLC), sidelink D2D (device-to-device), and several other use cases.

[0003] FIG. 1 is a high-level diagram of a 5G network architecture consisting of a next generation RAN (NG-RAN) 199 and a 5G core (5GC) 198. The NG-RAN 199 can include one or more g-node Bs (gNBs) 100, 150, etc., connected via interfaces 102, 152, respectively, and connected to the 5GC via one or more NG interfaces. More specifically, the gNBs 100, 150 can be connected to one or more access and mobility management functions (AMFs) in the 5GC 198 via their respective NG-C interfaces. Similarly, the gNBs 100, 150 can be connected to one or more user plane functions (UPFs) in the 5GC 198 via their respective NG-U interfaces. The 5GC 198 can include various other network functions (NFs), such as a session management function (SMF).

[0004] Although not illustrated, in some deployments, the 5GC198 can be replaced by the conventionally used Extended Packet Core (EPC) with the Long-Term Evolution (LTE) Extended UMTS RAN (E-UTRAN). In such deployments, the gNB100, 150 can connect to one or more Mobility Management Entities (MMEs) in the EPC198 via their respective S1-C interfaces. Similarly, the gNB100, 150 can connect to one or more Serving Gateways (SGWs) in the EPC via their respective NG-U interfaces.

[0005] gNBs can be connected to each other via one or more Xn interfaces, such as the Xn interface 140 between gNBs 100 and 150. The radio technology for NG-RAN is often called "New Radio" (NR). With respect to the NR interface to the UE, each gNB can support frequency division duplex (FDD), time division duplex (TDD), or a combination thereof.

[0006] NG-RAN199 is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The NG-RAN architecture, i.e., the NG-RAN logical nodes and the interfaces between them, is defined as part of the RNL. For each NG-RAN interface (NG, Xn, F1), the associated TNL protocols and functions are specified. The TNL provides services for user-plane transport and signaling transport.

[0007] The NG RAN logical node shown in Figure 1 includes a central unit (CU or gNB-CU) and one or more distributed units (DU or gNB-DU). For example, gNB 100 includes gNB-CU110 and gNB-DU120 and 130. A CU is a logical node that hosts higher-layer protocols and performs various gNB functions such as controlling the operation of DUs, while a DU is a logical node that hosts lower-layer protocols and may include various subsets of gNB functions. Thus, each CU and DU may include various circuits necessary to perform their respective functions, including processing circuits, communication interface circuits (e.g., transceivers), and power supply circuits.

[0008] A gNB-CU connects to one or more gNB-DUs on their respective F1 logical interfaces, such as interfaces 122 and 132 shown in Figure 1. A gNB-DU may be connected to multiple gNB-CUs by appropriate implementation. A gNB-CU and its connected gNB-DUs appear only as gNBs to other gNBs and 5GCs. In other words, the F1 interface is invisible beyond the gNB-CU.

[0009] Dual connectivity (DC) was introduced in LTE Rel-12. In DC operation, a UE in the RRC_CONNECTED state consumes radio resources provided by at least two different network nodes connected to each other using a non-ideal backhaul. Several DC (or more generally, multi-connectivity) configurations are also supported in 5G / NR. These include NR-DC, which is similar to LTE DC except that both network nodes use NR interfaces to communicate with the UE, and various multi-RAT DCs (MR-DC) with both LTE and NR access by the same UE. More generally, one node acts as a master node (MN) providing the UE's master cell group (MCG), and the other node acts as a secondary node (SN) providing the UE's secondary cell group (SCG), with at least the MN connected to the core network (e.g., EPC or 5GC).

[0010] Each CG contains one MAC entity, a primary cell (PCell), and optionally one or more secondary cells (SCells). The term “Special Cell” (or “SpCell” for short) refers to either an MCG PCell or an SCG PCell (also called a “PSCell”), depending on whether the UE’s MAC entity is associated with an MCG or an SCG, respectively. In non-DC operation (e.g., carrier aggregation, CA), SpCell refers to a PCell. SpCells are always activated and support physical UL control channel (PUCCH) transmission and competition-based random access by the UE.

[0011] When a UE moves between the coverage areas of two cells, a serving cell change must be performed at a certain point. Currently, serving cell changes are triggered by Layer 3 (L3, e.g., RRC) measurements and involve RRC signaling to modify PCell and / or PSCell (e.g., when dual connectivity is set), as well as to release / add SCell (e.g., when CA is set). For example, a handover command is sent by an RRCReconfiguration message containing a reconfigurationWithSync information element (IE).

[0012] Currently, L3 inter-cell mobility involves a complete Layer 2 (L2) and Layer 1 (L1, i.e., PHY) reset, which leads to longer latency, increased signaling overhead, and longer interruptions compared to intra-cell beam switching. To address these issues, NR Rel-18 included a work item on NR mobility enhancements, including features called L1 / L2-based inter-cell mobility, L1 / L2-triggered mobility (LTM), or lower-layer-triggered mobility. This work item is further described in 3GPP document RP-213565. The goal of the Rel-18 L1 / L2 mobility (or LTM) enhancements is to facilitate serving cell changes via L1 / L2 signaling to reduce the latency, signaling overhead, and interruptions associated with conventional L3 inter-cell mobility. Another work item in 3GPP, titled “Further NR mobility enhancements,” is described in 3GPP RP-223520.

[0013] These work items specify the purpose of the following tasks: 1. Specify the following mechanisms and procedures for L1 / L2-based inter-cell mobility to reduce mobility latency: ○Setting and maintenance for multiple candidate cells to enable fast application of settings for candidate cells [RAN2, RAN3] ○ Dynamic switching mechanism between candidate serving cells (including SpCell and SCell) for potential applicable scenarios based on L1 / L2 signaling [RAN2, RAN1] ○L1 extension for inter-cell beam management, including L1 measurement and reporting, and beam indication [RAN1, RAN2] Note 1: Early involvement of RAN2 is needed, including the possibility of further clarifying the interaction between this item and the previous item. ○Timing Advance Management [RAN1, RAN2] ○CU-DU interface signaling [RAN3] to support L1 / L2 mobility when necessary. Note 2: FR2-specific extensions, if any, are not excluded. Note 3: The L1 / L2-based inter-cell mobility procedure is applicable to the following scenarios. ■ Standalone, CA, and NR-DC with serving cell changes within a single CG ■ Within a DU and between DUs within a CU (Applicable to standalone and CA: No new RAN interface is expected) ■Both within and between frequencies ■Both FR1 and FR2 ■ Source cells and target cells can be synchronous or asynchronous.

[0014] The fundamental principle of LTM is that the UE is pre-configured by the network with one RRC setting for each LTM candidate target cell. This pre-configured RRC setting is sometimes called the LTM candidate cell setting. Such an LTM candidate cell setting may be one or more IEs / fields / parameters such as an RRCReconfiguration message or CellGroupConfig.

[0015] After receiving these LTM candidate cell configurations, the UE performs measurements on these LTM candidate cells and sends the corresponding measurement reports to the network. The network then triggers an LTM cell switchover in the UE to one of these LTM candidate cells by sending an LTM cell switchover command (such as MAC CE) to the UE, and the UE then connects to the specific LTM candidate cell and switches to the RRC configuration of that LTM candidate cell.

[0016] Relevant agreements reached by the 3GPP Working Group include the following: ●When cell switching between L1 / L2 mobility candidates occurs without RRC resetting in between, the term “subsequent” LTM is used. ●RAN2 assumes that sequential L1L2 cell changes between candidates can be supported without RRC resetting. ●RAN2 assumes that the MAC CE for L1 / 2 mobility triggers includes at least a candidate configuration index. ●RAN2 assumes that during L1L2 cell switching, the network explicitly controls whether the UE performs a partial MAC reset or a full MAC reset (to be investigated in the future: for example, what constitutes a partial reset to avoid data loss), re-establishes the RLC, or performs data recovery using PDCP. RAN2 assumes this can be configured by RRC. Further consideration: MAC CE instruction will be required. ● We agree to use Model 1, i.e., one RRCReconfiguration message for each candidate target setting RRCReconfiguration to set the target candidate cell. ●RAN2 assumes that the RRCReconfigurationComplete message is always sent during each LTM execution. ●In RACH-based LTM, the target cell recognizes the arrival of the UE based on the reception of the preamble in the CFRA and the reception of Msg3 / MsgA in the CBRA, similar to legacy handover (HO). ●In LTM without RACH, the target cell recognizes the arrival of the UE based on the reception of the first UL transmission from this UE. ● In LTM without RACH, RRCReconfigurationComplete can be the content of the first UL MAC PDU / transmit to indicate UE arrival, meaning there is no need to introduce new signaling to indicate UE arrival (in the case of MCG switching).

[0017] Further improvements are needed for L1 / L2 triggered mobility, i.e., LTM. [Overview of the Initiative]

[0018] The following detailed explanation describes several cases in which the sequential execution of multiple LTM cell procedures can cause problems in the network, as one or more involved nodes may be unable to reliably determine the status of the UE due to signaling ambiguity caused by race conditions, poor signaling conditions, etc. Several methods described below address these problems by having the UE indicate the LTM candidate settings applied during LTM cell switching.

[0019] An example of such a method includes receiving at least one LTM candidate cell configuration from a network node, performing an LTM cell switching procedure by applying the received and indicated LTM candidate cell configuration, and transmitting an LTM cell switching completion message including an indication of the applied LTM candidate to a network node such as a first target network node, a second target network node, or a third network node. In various embodiments, the indication of the applied LTM candidate can be an indication of a target cell, an indication of an LTM candidate cell configuration, an indication of a beam, or an identifier of a procedure, transaction, or message instance.

[0020] Other techniques described herein include methods for a first target network node (such as a first target gNB, a first target DU, etc.) to process a UE's LTM cell switching procedure, and an example of such a method includes receiving, from the UE, an LTM cell switching completion message including an indication of the applied LTM candidate. Similarly, the techniques described herein include methods for a second target network node (such as a second target gNB, a second target DU, etc.) to process a UE's LTM cell switching procedure, and an exemplary method includes receiving, from the UE, an LTM cell switching completion message including an indication of the applied LTM candidate. Similarly, an exemplary method for a third network node (or serving network node) such as a (serving) central unit (CU), a (serving) gNB-CU, etc. to process a UE's LTM cell switching procedure includes transmitting at least one LTM candidate cell configuration to the UE and, upon transmitting an LTM cell switching command to initiate the LTM cell switching procedure, receiving, from the UE, an LTM cell switching completion message including an indication of the applied LTM candidate.

[0021] An exemplary method for L1 / L2-triggered mobility in a wireless network according to some embodiments described herein is performed by a UE. The method includes receiving an LTM candidate cell configuration from a wireless network, performing a first LTM cell handover procedure, and transmitting an LTM cell handover completion message including an indication of the applied LTM candidate to the wireless network.

[0022] An exemplary method for supporting LTM in a wireless network according to some embodiments described herein is performed by a network node. The method includes receiving, from a UE, a first LTM cell handover completion message, the first LTM cell handover completion message including an indication of the applied LTM candidate.

[0023] The indication of the applied LTM candidate cell in the LTM cell handover completion message resolves potential ambiguities that may arise in the case of multiple LTM procedures.

[0024] One or some of these techniques can be used, in particular, to enable the network to know which LTM candidate cell configuration the UE has applied after the execution of an LTM cell handover, especially when the UE performs a first LTM cell handover followed immediately by a second subsequent LTM cell handover. As described above and further detailed below, in these cases, an LTM cell handover completion message, such as an RRCReconfiguration completion message transmitted after the first LTM cell handover, may or may not be received by the network when the second LTM cell handover is triggered.

[0025] These and other objects, features, and advantages of the present disclosure will become apparent upon reading the following detailed description of the invention in view of the drawings briefly described below.

Brief Description of the Drawings

[0026] [Figure 1]This is a high-level diagram of an exemplary 5G / NR network architecture. [Figure 2] This is a high-level diagram of an exemplary 5G / NR network architecture. [Figure 3] This diagram shows an exemplary configuration of the NR user plane (UP) and control plane (CP) protocol stacks. [Figure 4] This is a message sequence chart showing signaling for LTM in a DU (Unit-of-Service) scenario. [Figure 5] This figure shows a system structure including entities involved in the techniques described herein. [Figure 6] This is a message sequence chart illustrating signaling and steps according to several embodiments of the techniques described herein for improving LTM. [Figure 7A] This is another message sequence chart illustrating signaling and steps according to some embodiments of the techniques described herein for improving LTM. [Figure 7B] This is another message sequence chart illustrating signaling and steps according to some embodiments of the techniques described herein for improving LTM. [Figure 8A] Here is yet another message sequence chart illustrating the signaling and steps according to some embodiments of the techniques described herein for improving LTM. [Figure 8B] Here is yet another message sequence chart illustrating the signaling and steps according to some embodiments of the techniques described herein for improving LTM. [Figure 9] This is a process flow illustrating an exemplary method for UE (Unified Element). [Figure 10] This figure shows exemplary methods for network nodes according to various embodiments of the present disclosure. [Figure 11] This figure shows a communication system according to various embodiments of the present disclosure. [Figure 12]This figure shows a UE according to various embodiments of the present disclosure. [Figure 13] This figure shows network nodes according to various embodiments of the present disclosure. [Figure 14] This figure shows a host computing system according to various embodiments of the present disclosure. [Figure 15] This is a block diagram of a virtualization environment in which the functions implemented by some embodiments of this disclosure may be virtualized. [Figure 16] This figure shows a communication between a host computing system, a network node, and an UE via multiple connections, according to various embodiments of the present disclosure, wherein at least one of the connections is wireless. [Modes for carrying out the invention]

[0027] Next, the embodiments briefly summarized above will be described in more detail with reference to the attached drawings. These descriptions are provided as examples to those skilled in the art to illustrate the subject matter and should not be construed as limiting the scope of the subject matter to the embodiments described herein. More specifically, examples demonstrating the operation of various embodiments in accordance with the advantages described above are provided below.

[0028] In general, all terms used herein should be interpreted according to their common meanings in the art to which they relate unless a different meaning is explicitly given and / or implied by the context in which the term is used. All references to elements, apparatus, components, means, steps, etc., should be openly interpreted as referring to at least one instance of the elements, apparatus, components, means, steps, etc., unless otherwise expressly presented. Steps of methods and / or procedures disclosed herein do not need to be performed in the strict order disclosed unless it is explicitly stated that a step follows or precedes another step, and / or it is implicit that a step must follow or precede another step. Any feature of any embodiment disclosed herein may be applied to any other embodiment as needed. Similarly, any advantage of any embodiment may be applied to any other embodiment, and vice versa. Other objectives, features, and advantages of the enclosed embodiments will become apparent from the following description.

[0029] Furthermore, the following terms will be used throughout the explanation given below. ●Radio Access Node: As used herein, “radio access node” (or equally, “radio network node,” “radio access network node,” or “RAN node”) can be any node in a radio access network (RAN) that operates to transmit and / or receive signals wirelessly. Some examples of radio access nodes include, but are not limited to, base stations (e.g., gNBs in 3GPP 5G / NR networks, or extensions 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 base stations, pico base stations, femto base stations, or home base stations), radio access backhaul integrated transmission (IAB) nodes, transmit points (TPs), transmit / receive points (TRPs), remote radio units (RRUs or RRHs), and relay nodes. ● Core Network Nodes: As used herein, “core network nodes” refers to 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 Billing Rule Function (PCRF), Access and Mobility Management Function (AMF), Session Management Function (SMF), User Plane Function (UPF), Billing Function (CHF), Policy Control Function (PCF), Authentication Server Function (AUSF), Location Management Function (LMF), etc. ● Wireless Device: As used herein, “Wireless Device” (or “WD” for short) is any type of device that is capable of, set up, configured, and / or operable to communicate wirelessly with network nodes and / or other wireless devices. Wireless communication may involve transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information in the air. Unless otherwise stated, the term “Wireless Device” is used herein interchangeably with “User Equipment” (or “UE” for short), and both of these terms have meanings distinct from the term “Network Node.” ● Wireless node: As used herein, “wireless node” may be either “wireless access node” (or equivalent term) or “wireless device”. ●Network Node: As used herein, “Network Node” refers to any node that is either part of a wireless access network (e.g., a wireless access node or equivalent term) or part of the core network of a cellular communication network (e.g., a core network node as discussed above). Functionally, a network node is a device that is capable of communicating directly or indirectly with wireless devices and / or other network nodes or devices in a cellular communication network, in order to enable and / or provide wireless access to wireless devices and / or to perform other functions in a cellular communication network (e.g., management). ●Base station: As used herein, “base station” may include physical or logical nodes that transmit or control the transmission of radio signals, such as eNBs, gNBs, ng-eNBs, en-gNBs, centralized units (CUs) / distributed units (DUs), transmitting radio network nodes, transmitting points (TPs), transmitting receiving points (TRPs), remote radio heads (RRHs), remote radio units (RRUs), distributed antenna systems (DASs), relays, and the like. ● Node: As used herein, the term “node” (without prefix) can refer to any type of node that may be in or with a wireless network (including the RAN and / or core network), including a wireless access node (or equivalent term), a core network node, or a wireless device. However, the term “node” may be limited to a specific type (e.g., a wireless access node) based on the specific characteristics of a node in a given context.

[0030] It should be noted that the descriptions provided herein focus on 3GPP cellular communication systems, and therefore, 3GPP terminology or terminology similar to 3GPP terminology will generally be used. However, the concepts disclosed herein are not limited to 3GPP systems. Other radio systems, including but not limited to, broadband code division multiple access (WCDMA), global interoperability for microwave access (WiMAX), ultra-mobile broadband (UMB), and pan-European digital mobile telephone system (GSM), may also benefit from the concepts, principles, and / or embodiments described herein.

[0031] To provide additional context for the techniques described in detail below, Figure 2 shows a high-level diagram of an exemplary 5G network architecture including NG-RAN299 and 5GC298. As shown in the figure, NG-RAN299 may include gNBs (e.g., 210a, b) and ng-eNBs (e.g., 220a, b) interconnected with each other via their respective Xn interfaces. The gNBs and ng-eNBs are also connected to the 5GC via NG interfaces, and more specifically, to access and mobility management functions (AMFs, e.g., 230a, b) via their respective NG-C interfaces and to user plane functions (UPFs, e.g., 240a, b) via their respective NG-U interfaces. Furthermore, the AMFs can communicate with one or more policy control functions (PCFs, e.g., 250a, b) and network exposure functions (NEFs, e.g., 260a, b).

[0032] Each gNB can support an NR radio interface, including frequency division duplex (FDD), time division duplex (TDD), or a combination thereof. Each ng-eNB can support an LTE radio interface. However, unlike conventional LTE eNBs, the ng-eNB220 connects to 5GC via the NG interface. Each gNB and ng-eNB can serve a geographical coverage area that includes another cell, such as cells 211a~b and 221a~b shown in Figure 2. Depending on the cell it is located in, the UE205 can communicate with the gNB or ng-eNB serving that cell, respectively, via the NR or LTE radio interface. Although Figure 2 shows gNBs and ng-eNBs separately, it is also possible for a single NG-RAN node to provide both types of functionality.

[0033] Figure 3 shows an exemplary configuration of the NR User Plane (UP) and Control Plane (CP) protocol stacks between the UE(310), gNB(320), and AMF(330), as shown in Figures 1 and 2. The Physical (PHY) layer, Media Access Control (MAC) layer, Radio Link Control (RLC) layer, and Packet Data Convergence Protocol (PDCP) layer between the UE and gNB are common to both the UP and CP. The PDCP layer provides encryption / decryption, integrity protection, sequence numbering, sorting, and duplicate detection for both CP and UP. In addition, PDCP provides header compression and retransmission for UP data.

[0034] On the UP side, Internet Protocol (IP) packets arrive at the PDCP layer as Service Data Units (SDUs), and the PDCP creates Protocol Data Units (PDUs) for distribution to the RLC. The Service Data Adaptive Protocol (SDAP) layer handles QoS, including mapping QoS flows to data radio bearers (DRBs) and marking QoS flow identifiers (QFIs) in UL and DL packets. The RLC layer forwards PDCP PDUs to the MAC through logical channels (LCHs). The RLC provides error detection / correction, concatenation, segmentation / reassembly, sequence numbering, and sorting of data being forwarded to and from higher layers. The MAC layer provides mapping between LCHs and PHY transport channels, LCH prioritization, multiplexing to or demultiplexing from transport blocks (TBs), hybrid ARQ (HARQ) error correction, and dynamic scheduling (gNB side). The PHY layer provides transport channel services to the MAC layer, handling transmissions on the NR radio interface, for example, through modulation, coding, antenna mapping, and beamforming.

[0035] On the CP side, the Non-Access Layer (NAS) layer lies between the UE and the AMF, handling UE / gNB authentication, mobility management, and security control. The RRC layer is located below the NAS within the UE but terminates within the gNB, not the AMF. The RRC controls communication between the UE and the gNB on the radio interface, as well as the mobility of the UE between cells within the NG-RAN. The RRC also broadcasts system information (SI) and implements the establishment, configuration, maintenance, and release of DRBs and signaling radio bearers (SRBs) for use by the UE. Furthermore, the RRC controls the addition, modification, and release of carrier aggregation (CA) and dual connectivity (DC) configurations for the UE. The RRC also implements various security functions, such as key management.

[0036] After power-on, the UE is in the RRC_IDLE state until an RRC connection with the network is established, at which point the UE transitions to the RRC_CONNECTED state (e.g., data transfer may occur). After the connection with the network is released, the UE returns to RRC_IDLE. In the RRC_IDLE state, the UE's radio is active on the intermittent receive (DRX) schedule set by the higher layer. During the DRX active period (also called the "DRX-on duration"), the RRC_IDLE UE receives SI broadcasts in the cell the UE is camping, performs neighbor cell measurements to support cell reselection, and monitors the paging channel on the PDCCH for paging from 5GC via the gNB. An NR UE in the RRC_IDLE state is unknown to the gNB serving the cell the UE is camping. However, NR RRC includes the RRC_INACTIVE state, where the UE is known by the serving gNB (e.g., via the UE context). RRC_INACTIVE has some properties similar to the "interrupted" state used in LTE.

[0037] Seamless mobility is a key feature of 3GPP Radio Access Technology (RAT). Generally, the network configures UEs to perform and report RRM measurements to assist in network-controlled mobility decisions, such as for handovers from a serving cell to a neighbor cell while the UE is in the RRC_CONNECTED state. Seamless handover ensures that UEs can move around within the coverage areas of different cells without causing too much disruption to data transmission.

[0038] The network can configure UEs in the RRC_CONNECTED state to perform and report RRM measurements that assist in network-controlled mobility decisions, such as UE handovers between cells and SN changes. A UE may lose coverage of its current serving cell (e.g., a PCell in a DC) and attempt to hand over to a target cell. Similarly, a UE within a DC may lose coverage of its current PSCell and attempt an SN change. Other events may trigger other mobility-related procedures. The Radio Link Fault (RLF) procedure is typically triggered in a UE when something unexpected occurs in any of these mobility-related procedures. The RLF procedure involves interaction between the RRC and lower-layer protocols such as PHY (or L1), MAC, and RLC, including Radio Link Monitoring (RLM) on L1.

[0039] The principle of RLM is similar in LTE and NR. Generally, a UE monitors the link quality of its serving cell (i.e., SpCell) and uses that information to determine whether the UE is synchronized (IS) or out of sync (OOS) with respect to that serving cell. In LTE, RLM is performed by the UE measuring the downlink reference signal (e.g., CRS) in the RRC_CONNECTED state. If the RLM (i.e., by L1 / PHY) indicates a number of consecutive OOS states to the UE RRC layer, the RRC initiates a Radio Link Failure (RLF) procedure and declares the RLF after the timer (e.g., T310) expires. The L1 RLM procedure is performed by comparing the estimated CRS measurement with several target block error rates (BLER) called Qout and Qin. In particular, Qout and Qin correspond to the BLER of hypothetical PDCCH / PCIFCH transmissions from the serving cell, with exemplary values ​​of 10% and 2%, respectively. In NR, the network can define the RS type (e.g., CSI-RS and / or SSB), the specific resources to be monitored, and even BLER targets for IS and OOS instructions.

[0040] In addition to providing coverage via "cells," as in the case of LTE, NR networks also provide coverage via "beams." Generally, a DL "beam" is the coverage area of ​​network-transmitted RS that can be measured or monitored by a UE. Such RS may include, alone or in combination, any of the following: SS / PBCH block (SSB), channel state information RS (CSI-RS), tertiary reference signal (or any other synchronization signal), positioning RS (PRS), demodulation RS (DMRS), phase-tracking reference signal (PTRS), etc. Generally, SSB is available to all UEs regardless of the RRC state, while other RS ​​(e.g., CSI-RS, DMRS, PTRS) are related to specific UEs that have network connectivity, i.e., are in the RRC_CONNECTED state.

[0041] To support beam management, a CSI measurement configuration may be set up on the UE, which instructs the UE to monitor CSI-RS and send various CSI reports to the RAN (e.g., NG-RAN). For example, the RAN specifies an explicit list of CSI resources that the UE should monitor for each type of CSI report that the UE is configured to send. Similar techniques may be used for beam management based on SSB transmitted over the network.

[0042] During preparation for handover of the UE to the target node, the source node sends the current UE configuration to the target node in a HANDOVER REQUEST message. The target node prepares a target configuration for the UE based on the current configuration and the capabilities of the target node and the UE. The target node sends the target configuration to the source node in a HANDOVER REQUEST ACKNOWLEDGE message, and the source node encapsulates it in an RRCReconfiguration message to the UE. As a streamlined option, the target configuration may be signaled as a “delta configuration” that includes only the difference from the current configuration of the UE in the source cell.

[0043] In summary, handovers and other serving cell changes are triggered by Layer 3 (L3, e.g., RRC) measurements, involving RRC signaling to change PCell and / or PSCell (e.g., when DC is set), as well as to release / add SCell (e.g., when CA is set). Currently, L3 inter-cell mobility involves a complete Layer 2 (L2) and Layer 1 (L1, i.e., PHY) reset, which leads to longer latency, increased signaling overhead, and longer interruptions than in the case of intra-cell beam switching. As discussed in the background technology section above, the objective of the LTM trigger mobility procedure is to mitigate and / or completely avoid these problems in appropriate situations by providing a dynamic cell switching mechanism that does not require the execution of a Layer 3 (RRC) reset procedure.

[0044] This specification refers to the term "L1 / L2-based inter-cell mobility" as used in the description of 3GPP work items, but also uses interchangeably the terms L1 / L2 mobility, L1 mobility, L1-based mobility, L1 / L2-centric inter-cell mobility, L1 / L2 inter-cell mobility, L1 / L2 triggered mobility, lower-layer triggered mobility, or LTM. The basic principle is that a UE receives lower-layer signaling from the network indicating a change (or switching or activation) of its serving cell (e.g., a change of PCell from a source PCell to a target PCell), and lower-layer signaling is a message / signaling of a lower-layer protocol, sometimes called an L1 / L2 inter-cell mobility execution command or an LTM cell switching command. A change in a serving cell (e.g., a change in PCell) can also lead to a change in an Scell ​​for the same cell group, for example, if a command triggers the UE to change to a different cell group configuration of the same type (e.g., a different MCG configuration). Before the UE receives an LTM cell switching command, the UE is configured by the network with one or more LTM candidate cell configurations (for example, by receiving an RRC reconfiguration message with at least one LTM candidate cell configuration). The LTM candidate cell configuration may include an information element (IE) CellGroupConfig and / or parameters in the embedded RRC reconfiguration for the LTM candidate cell. The LTM cell switching command includes an LTM candidate configuration index that identifies the target LTM candidate cell.

[0045] The term LTM cell switching procedure refers to the process by which a UE uses L1 / L2 triggered mobility (LTM) to switch (or change) its cell from a source cell to a target cell (sometimes referred to here as an LTM candidate cell or neighbor cell). In the context of L1 / L2 triggered mobility (LTM), an LTM cell switching procedure may sometimes also be known as an L1 / L2-based inter-cell mobility execution, LTM execution, dynamic switching, LTM switching, (LTM) cell switching, (LTM) serving cell change, or (LTM) cell change. In the context of the techniques described herein, switching to an LTM candidate cell involves the UE considering that the LTM candidate cell will become its new special cell (SpCell), for example, a PCell if the LTM is set up for a master cell group (MCG), and / or a PSCell if the LTM is set up for a secondary cell group (SCG), or changing that SpCell from the current PCell to the designated LTM candidate cell. While the terms “switching” or “changing cells” may be used to describe these procedures, it should be noted that this switching or changing of a cell may include changing a SpCell (e.g., changing a PCell, or changing a PSCell) and changing a SCell in a cell group (e.g., adding, modifying, and / or releasing one or more SCells), as well as switching or changing the entire cell group configuration.

[0046] The LTM cell switching procedure can be triggered in the UE by receiving an LTM cell switching command, or alternatively, by some other event, such as the fulfillment of a condition, for example, a trigger condition used for conditional settings such as conditional handover, as a result of recovery from a radio link failure or handover failure.

[0047] This specification refers to LTM candidate cells, which are cells to which a UE is configured when configured with L1 / L2 triggered mobility. That is, an LTM candidate cell is a cell to which a UE can move in the LTM cell switching procedure upon receiving an LTM cell switching command. Such cells may also be called candidate cells, candidates, mobility candidates, non-serving cells, additional cells, target candidate cells, target candidates, etc. An LTM candidate cell is a cell to which a UE can perform measurements (e.g., CSI measurements), as a result of which the UE reports these measurements, and the network can make knowledgeable decisions about which beam (e.g., TCI state) and / or cell the UE should switch to. An LTM candidate cell may be a candidate to become a target PCell or PSCell, or a SCell of a cell group (e.g., an MCG SCell or SCG SCell).

[0048] This specification also refers to “at least one configured LTM candidate cell” to indicate that a UE has received at least one LTM candidate cell configuration. This may sometimes also be called an LTM candidate cell configuration and may be an RRC configuration encapsulated within an RRC reconfiguration message that a UE receives when configured using L1 / L2 triggered mobility. An LTM candidate cell configuration includes the configuration that a UE should take action in response to when it performs an LTM cell switching procedure to that LTM candidate cell, for example, when it receives an LTM cell switching command instructing the UE to perform an LTM cell switching procedure to that LTM candidate cell which will become a target cell and the current (new) SpCell, or a SCell in the serving frequency.

[0049] The LTM candidate cell configuration includes parameters for a serving cell (or multiple serving cells, such as a cell group), which include one or more of the following groups of parameters: RRCReconfiguration message, IE CellGroupConfig, or IE SpCellConfig (or, in the case of a secondary cell, IE SCellConfig). The LTM candidate cell configuration may include, for example, one or more of the following: i) PCell configuration and one or more SCell configurations for a master cell group (MCG), or i) PSCell configuration and one or more SCell configurations for a secondary cell group (SCG). The terms (LTM) candidate configuration, LTM configuration, (LTM) candidate target cell configuration, and (LTM) target candidate (cell) configuration may be used interchangeably when referring to the configuration of an LTM candidate cell.

[0050] An LTM candidate cell setting is associated with an identifier used in signaling when referring to a particular LTM candidate cell setting, such as when the UE receives an LTM candidate cell setting and when the UE receives an LTM cell switching command instructing the UE to execute an LTM cell switching procedure to that LTM candidate cell. This identifier may be known as the LTM candidate cell setting identifier or LTM candidate setting index (or similar).

[0051] Therefore, in L1 / L2 triggered mobility, the UE receives an LTM cell switching command that includes an LTM candidate setting index, and during the LTM cell switching procedure, this index is used by the UE to identify the LTM candidate cell setting. The UE then executes an RRC procedure, here called the RRC LTM execution procedure, or sometimes the LTM execution procedure or LTM execution RRC procedure, to apply and process the contents of the LTM candidate cell setting, and then, based on the information elements (IEs) and fields contained within the LTM candidate setting, triggers the execution of other RRC procedures related to those IEs and fields, including the settings of lower layers (e.g., L1, and possibly RLC and / or MAC), according to those IEs and fields contained.

[0052] The actual LTM candidate cell configuration and its exact contents and / or the structure and / or embedded messages of this IE may be referred to as the RRC model for candidate configuration, or simply the RRC model. The LTM candidate cell configuration includes the configuration that the UE should operate accordingly when it performs (executes) an L1 / L2-based inter-cell mobility to an LTM candidate cell, upon receiving lower layer signaling (MAC CE) indicating L1 / L2-based inter-cell mobility to an LTM candidate cell (which will be the target cell and the current (new) PCell, or SCell within the serving frequency), or upon receiving lower layer signaling (MAC CE) indicating L1 / L2-based inter-cell mobility to an LTM candidate cell configuration indicated by a candidate configuration index (sometimes denoted as a candidate configuration ID). The UE may be configured with multiple LTM candidate cell configurations, for example, so that a candidate distribution unit (DU) generates multiple configurations and sends them to a central unit (CU). The actual LTM candidate cell configuration that the UE receives during LTM configuration may be delta signaling that should be applied on top of the baseline configuration. Therefore, the actual configuration that the UE should use in the candidate cell when LTM cell switching occurs is a combination of the LTM candidate cell configuration and the baseline configuration (which is separately signaled to the UE by the network, for example).

[0053] LTM cell switching commands may also include beam indications. The term “beam” may refer to the spatial direction in which a signal is transmitted (e.g., by a network node) or received (e.g., by a UE), or to a spatial filter applied to the transmitted or received signal. Therefore, transmitting a signal on a different beam may refer to transmitting a signal in a different spatial direction. When this specification refers to “selected beam,” it may refer to a reference signal (RS) index or identifier, such as a beam index and / or a synchronous signal block (SSB) index, or a CSI-RS resource identifier. Therefore, selecting a beam may refer to selecting an SSB associated with an SSB index, or selecting a beam may refer to selecting a CSI-RS associated with a CSI-RS resource identifier.

[0054] The descriptions of various techniques in this specification refer to the “indication of the applied LTM candidate.” This indication of the applied LTM candidate may be an indication of the target cell, such as a cell identifier (e.g., PCI, CGI); an indication of the LTM candidate cell configuration, such as an LTM candidate cell configuration index or LTM candidate cell configuration identification information; an indication of the beam, such as an SSB index or CSI-RS resource identifier; or an indication of an index that identifies a particular RRC message previously transmitted by the network and received by the UE.

[0055] Many details of the procedures for L1 / L2-based inter-cell mobility are still publicly available in 3GPP. This also applies to the details of the LTM cell switching procedure.

[0056] Figure 4 shows an example of a possible signaling flow for an LTM cell switching procedure. This example begins with the execution of an LTM cell switching procedure triggered by an L1 measurement report from the UE. Prior to this step, the UE is already configured with LTM candidate cell settings, each of which is represented as an individual RRCReconfiguration message stored by the UE. When the UE executes the LTM cell switching procedure, it sends an RRCReconfigurationComplete message on the target cell. This message can be considered a “response” message confirming that the UE has applied the RRCReconfiguration message representing the LTM candidate cell settings for a particular LTM candidate cell.

[0057] This example shows the case between DUs, but signaling is also applicable within a DU, with the difference being that the source gNB-DU and candidate gNB-DU are both single gNB-DUs.

[0058] In the agreed solution for how a UE should indicate its arrival in the target cell, the UE sends an RRCReconfigurationComplete message after each LTM execution. This RRCReconfigurationComplete message is received and interpreted by the gNB-CU, and since the message is encrypted, its contents are transparent to the candidate gNB-DU. However, according to the RAN2 agreed solution, in a RACH-based LTM, the candidate gNB-DU becomes aware of the UE's arrival based on the receipt of the preamble in the CFRA and the receipt of Msg3 / MsgA in the CBRA, so the candidate gNB-DU is made aware of the UE's arrival at an earlier point in time (in steps 9-10 of the signaling flow in Figure 4). In the case of an LTM without RACH, the candidate gNB-DU becomes aware of the UE's arrival based on the receipt of a first UL transmission from this UE (this first transmission may be an RRCReconfigurationComplete message for at least the LTM for the master cell group).

[0059] After an LTM cell switchover, once the candidate gNB-DU recognizes the arrival of the UE in the target cell (or, in this context, the "first" target cell), the candidate gNB-DU (which from this point onward assumes the role of the new serving gNB-DU) may trigger a subsequent LTM cell switchover procedure to the second target cell (which may be the previous source cell during what is sometimes known as "ping-pong" mobility). In small cell scenarios and at high frequencies, cell switches may occur frequently, and therefore, a subsequent cell switchover may be triggered immediately after the UE arrives at the first target cell.

[0060] However, if these LTM cell switching procedures are close together in time, the UERRCReconfigurationComplete message sent by the UE in the first target cell after the first LTM cell switching may not yet be successfully received by the gNB-CU when the candidate gNB-DU triggers the subsequent LTM cell switching. For example, if the subsequent LTM cell switching is triggered when the UE has poor uplink radio conditions in the current serving cell, the RRCReconfigurationComplete triggered message sent by the first LTM cell switching may be delayed, even though the UE can still receive LTM cell switching commands regarding the subsequent LTM cell switching. In this case, if RLC re-establishment was not performed (for example, in an in-DU LTM cell switching), the UE may still hold the RRCReconfigurationComplete message in the RLC or PDCP buffer to resend the message if necessary, as it may not yet have received confirmation that the message was successfully delivered.

[0061] This could mean that, after a subsequent LTM cell switching procedure, the RRCReconfigurationComplete message sent in the first target cell may be retransmitted in the second target cell. When the third network node receives this RRCReconfigurationComplete message via the second target cell, it has already received this message via the first target cell due to a network race condition. Therefore, the third network node may misinterpret this RRCReconfigurationComplete message received via the second target cell as an instruction that the UE has arrived at the second target cell and applied the corresponding LTM candidate cell configuration to the second target cell.

[0062] A similar situation occurs when the UE receives an RRCReconfiguration message, initiates sending an RRCReconfigurationComplete message, and the network triggers the LTM cell switching procedure. In such a case, the RRCReconfigurationComplete message may not have been sent to the network, or at least the UE may not be aware of whether this RRCReconfigurationComplete was received by the network when it receives the LTM cell switching command. In this case, this first RRCReconfigurationComplete message may be retransmitted within the target cell and therefore received by the gNB-CU before a second RRCReconfigurationComplete message sent as a result of the execution of the LTM cell switching procedure. In this case, the network will receive two RRCReconfigurationComplete messages within the target cell and will need to correlate the received messages with the respective procedures that were triggered when the UE was in the source cell.

[0063] In RRC signaling, the solution used to associate a response with a request is the use of a transaction identifier, where the transaction ID is included in the request, and the UE uses the same transaction ID in the response sent, as specified in 3GPP TS38.331 Section 5.1.2 below. TIFF2026520848000002.tif20170 This allows the network to send multiple messages to the UE without waiting for a response before sending the next one, and the network can still correlate the response with the request.

[0064] When a UE sends an RRCReconfigurationComplete message upon arriving at a target cell during an LTM cell switchover, the UE also includes a transaction identifier. However, the RRCReconfiguration message containing the LTM candidate cell configuration is provided to the UE well in advance, meaning that the transaction ID, being only two bits as defined in 3GPP TS38.331 Section 6.3.4, can typically expire by the time the UE sends the message. -- ASN1START -- TAG-RRC-TRANSACTIONIDENTIFIER-START RRC-TransactionIdentifier ::= INTEGER (0..3) -- TAG-RRC-TRANSACTIONIDENTIFIER-STOP -- ASN1STOP This means that when a network receives an RRCReconfigurationComplete message from a UE being configured for an LTM, it needs a way to determine whether to associate this received RRCReconfigurationComplete message with an RRCReconfiguration message previously sent to the UE that contains an RRCReconfiguration message used to configure a given LTM candidate cell configuration.

[0065] For conditional PSCell modification (CPC) and conditional PSCell addition (CPA), the UE indicates the selected cell in the RRCReconfigurationComplete message as specified in 3GPP TS 38.3312 section 5.3.5.3, as follows: TIFF2026520848000003.tif93170

[0066] However, this solution can only be used for CPC / CPA in the cases described above, and therefore cannot be applied to L1 / L2 triggered mobility (LTM).

[0067] The techniques described below address these issues by causing the UE to indicate the LTM candidate configuration applied during LTM cell switching. As will be described in more detail below, an example of how these techniques are performed by the UE includes receiving at least one LTM candidate cell configuration from a network node, executing an LTM cell switching procedure by applying the received indicated LTM candidate cell configuration, and sending an LTM cell switching completion message containing the applied LTM candidate configuration to a network node, such as a first target network node, a second target network node, or a third network node. In various embodiments, the applied LTM candidate configuration may be a target cell configuration, an LTM candidate cell configuration configuration configuration, a beam configuration, or an identifier for a procedure, transaction, or message instance. Corresponding complementary techniques performed by other nodes involved in the LTM cell switching procedure are also described in detail herein. One or more of these techniques may be used, in particular, to allow the network to know which LTM candidate cell configuration the UE applied after an LTM cell switchover occurred, especially when the UE performs a first LTM cell switchover that is immediately followed by a second subsequent LTM cell switchover.

[0068] Figure 5 shows a system structure including entities involved in the technique described herein. User device (UE) 501 is a wireless terminal such as a cellular smartphone, which may be connected to source network node 502 via wireless interface 504, or to a first target network node 503 to which UE 501 is connected via wireless interface 505. In some cases, UE 501 is connected to a second target network node 513 via wireless interface 514.

[0069] In the context of mobility procedures such as the LTM cell switching procedure for the UE, the source network node 502, sometimes called the serving network node, controls the source cell 509 (sometimes called the serving cell or special cell (SpCell)). The first target network node 503 controls the first target cell 510 (sometimes called the target cell, neighbor cell, candidate cell, or LTM candidate cell). In the context of the UE mobility procedure, the second target network node 513 controls the second target cell 516.

[0070] Each of the source network node 502, the first target network node 503, and the second target network node 513 may be a base station such as a gNB, or a distributed unit sometimes known as either a gNB-DU or a DU in the case of a distributed CU / DU RAN architecture. These nodes were described above in relation to Figures 1 and 2. Thus, the source network node 502 may correspond to a source DU (S-DU), sometimes also known as a serving DU; the first target network node 503 may correspond to a target DU (T-DU); and the second target network node 513 may correspond to a second target DU. The first or second target DU may be called a neighbor DU or candidate DU (C-DU).

[0071] Source network node 502, the first target network node 503, and the second target network node 513 are all connected to a third network node 506, sometimes called the serving network node. In Figure 5, these connections are via interfaces 507, 508, and 515, respectively. The source network node and either the first or second target network node may be the same network node. In some scenarios, the source network node and either the first or second target network node may be connected to different third network nodes 506.

[0072] Furthermore, the third network node 506 may be a central unit (CU), sometimes called a serving CU, known as gNB-CU, CU, gNB-CU-CP, or gNB-CU-UP, in the case of a distributed CU / DU RAN architecture, or a core network node such as a user plane function (UPF) or access and mobility management function (AMF).

[0073] Figure 6 is a message sequence chart illustrating the signaling and steps according to several embodiments of the techniques described herein for improving LTM. In the scenarios shown here, only one LTM cell switching procedure is triggered. The main steps and signals shown in this figure are as follows: ●Step 1. The network prepares at least one LTM candidate cell configuration. In this example, the first target cell controlled by the first target CU is included in one LTM candidate cell configuration. ●Step 2. The CU sends a DL RRC MESSAGE TRANSFER to the Serving DU, which includes an RRCReconfiguration message containing at least one LTM candidate cell configuration. ●Step 3. The Serving DU sends an RRCReconfiguration message to the UE that includes at least one LTM candidate cell configuration. ●Step 4. The UE stores the received LTM candidate cell configuration and responds to the Serving DU with the RRCReconfigurationComplete message. ●Step 5. The Serving DU sends a UL RRC MESSAGE TRANSFER containing the received RRCReconfigurationComplete message to the CU. ●Step 6. The UE takes measurements on the configured LTM candidate cells and sends measurement reports, such as lower-layer measurement reports including CSI measurements, to the Serving DU. ●Step 7. The Serving DU decides to trigger the LTM cell switching procedure to the target cell, in this example, the first target cell controlled by the first target DU. ●Step 8. The Serving DU sends an LTM cell switching command to the UE to trigger the LTM cell switching procedure. The LTM cell switching command includes instructions for setting up an LTM candidate cell for the first target cell. ●Step 9. In response to the received LTM cell switching command, the UE executes an LTM cell switching procedure that includes applying the indicated LTM candidate cell settings and switching to the first target cell. ● Steps 10 and 11.UE send an LTM cell switching complete message, such as an RRCReconfigurationComplete message, to the first target DU in the first target cell after the potential random access procedure, according to the applied LTM candidate cell configuration. The LTM cell switching complete message includes instructions for the applied LTM candidate, such as instructions for the LTM candidate cell configuration for the first target cell. ●Steps 12 and 13. When the first target DU detects the receipt of uplink data or signaling from the UE, it sends an ACCESS SUCCESS to the CU indicating that the UE has arrived at the first target cell. The first target DU also forwards any received LTM cell switching complete messages to the CU, such as the RRCReconfigurationComplete message, which is carried within the UL RRC MESSAGE TRANSFER message. ●Step 14. Upon receiving an LTM cell switching complete message, such as the RRCReconfigurationComplete message, the CU uses the applied LTM candidate instructions to determine that the UE has applied a specific LTM candidate cell configuration, in this case the LTM candidate cell configuration for the first target cell. ●Step 15.CU sends a message to the Serving DU to notify about the applied LTM candidate, including instructions for setting the LTM candidate cell for the first target cell. This message can be, for example, a new message for a Class 2 procedure, or a UE context modification procedure can be used.

[0074] Figures 7A and 7B provide another message sequence chart illustrating the signaling and steps according to some embodiments of the techniques described herein for improving LTM. In the scenarios shown here, two consecutive LTM cell switching procedures are triggered. Thus, the sequences shown in Figures 7A and 7B differ from the sequence in Figure 6, which begins at step 11. The main steps and signals shown in this figure are as follows: ●Step 1. The network prepares at least one LTM candidate cell configuration. In this example, the first target cell controlled by the first target CU is included in one LTM candidate cell configuration. ●Step 2. The CU sends a DL RRC MESSAGE TRANSFER to the Serving DU, which includes an RRCReconfiguration message containing at least one LTM candidate cell configuration. ●Step 3. The Serving DU sends an RRCReconfiguration message to the UE that includes at least one LTM candidate cell configuration. ●Step 4. The UE stores the received LTM candidate cell configuration and responds to the Serving DU with the RRCReconfigurationComplete message. ●Step 5. The Serving DU sends a UL RRC MESSAGE TRANSFER containing the received RRCReconfigurationComplete message to the CU. ●Step 6. The UE takes measurements on the configured LTM candidate cells and sends measurement reports, such as lower-layer measurement reports including CSI measurements, to the Serving DU. ●Step 7. The Serving DU decides to trigger the first LTM cell switching procedure to the target cell, in this example, the first target cell controlled by the first target DU. ●Step 8. The Serving DU sends an LTM cell switching command to the UE to trigger the first LTM cell switching procedure. The LTM cell switching command includes instructions for setting up an LTM candidate cell for the first target cell. ●Step 9. In response to the received LTM cell switching command, the UE executes a first LTM cell switching procedure, which includes applying the indicated LTM candidate cell settings and switching to the first target cell. ●Steps 10 and 11. The UE, after a potential random access procedure, sends a first LTM cell switching complete message, such as a first RRCReconfigurationComplete message, to the first target DU in the first target cell, according to the applied LTM candidate cell configuration. The first LTM cell switching complete message includes instructions for the applied LTM candidate, such as instructions for the LTM candidate cell configuration for the first target cell. However, in this scenario, the first target DU may not have yet successfully received the LTM cell switching complete message, for example, due to poor signaling conditions, or it may receive uplink signaling from the UE, but be unable to see the contents of the uplink signaling or data (including RRCReconfigurationComplete) when it is encrypted. In the latter case, the UE only knows that it has sent something on the signaling radio bearer, and in this case, the UE forwards the data to the CU when it has successfully concatenated all segments (in HARQ or RLC) of that message. However, in this case, it has not received all the segments, so it cannot yet forward the complete message. ●Step 12. In this example, the first target DU detects the receipt of uplink data or signaling from the UE and sends an ACCESS SUCCESS to the CU indicating that the UE has arrived at the first target cell. Note that this can happen even if the first target DU is unable to read the contents of the signaling or data (including RRCReconfigurationComplete), but the fact that the first target DU has received something from the UE is sufficient for the first target DU to recognize the arrival of the UE and therefore trigger the ACCESS SUCCESS message shown in the figure. ●Step 13. The first target DU decides to trigger a second LTM cell switching procedure to a second target cell controlled by the second target DU. ●Step 14. The first target DU (shown at the top of Figure 7B) sends an LTM cell switching command to the UE to trigger the second LTM cell switching procedure. The LTM cell switching command includes instructions for setting up the LTM candidate cell for the second target cell. In this example, at this point, the RRCReconfigurationComplete message sent by the UE in the first target cell has not yet been successfully received by the first target DU. ●Step 15. In response to the received LTM cell switching command, the UE executes a second LTM cell switching procedure, which includes applying the indicated LTM candidate cell settings and switching to the second target cell. ● Steps 16 and 17. Since the UE has not yet received confirmation from the network that the first LTM cell switchover complete message sent in step 11 has been received, the UE now resends this message to the second target DU in the second target cell after a potential random access procedure. The LTM cell switchover complete message includes instructions for the applied LTM candidate, such as instructions for setting up the LTM candidate cell for the first target cell. ● Steps 18 and 19. When the second target DU detects the receipt of uplink data or signaling from the UE, it sends an ACCESS SUCCESS to the CU indicating that the UE has arrived at the second target cell. The second target DU also forwards any received first LTM cell switching complete messages to the CU, such as the RRCReconfigurationComplete message, which is carried within the UL RRC MESSAGE TRANSFER message. ●Step 20. Upon receiving a first LTM cell switching completion message, such as the RRCReconfigurationComplete message, the CU uses the applied LTM candidate instructions to determine that the UE has applied a specific LTM candidate cell configuration, in this case the LTM candidate cell configuration for the first target cell. ●Step 21.CU sends a message to the Serving DU to notify about the applied LTM candidate, including instructions for setting the LTM candidate cell for the first target cell. This message can be a new message for a Class 2 procedure, or a UE context modification procedure can be used. ●Steps 22 and 23. Here, the UE sends a second LTM cell switching complete message, such as the RRCReconfigurationComplete message, to the second target DU in the second target cell. The second LTM cell switching complete message includes instructions for the applied LTM candidate, such as instructions for the LTM candidate cell configuration for the second target cell. The second target DU forwards this message to the CU in a UL RRC MESSAGE TRANSFER message. ●Step 24. Upon receiving a second LTM cell switching completion message, such as the RRCReconfigurationComplete message, the CU uses the applied LTM candidate instructions to determine that the UE has applied a specific LTM candidate cell configuration, in this case, the LTM candidate cell configuration for the second target cell. ●Step 25.CU sends a message to the first target DU to notify about the applied LTM candidate, including instructions for setting the LTM candidate cell for the second target cell. This message can be a new message for a Class 2 procedure, or a UE context modification procedure can be used.

[0075] Figures 8A and 8B together provide yet another message sequence chart illustrating the signaling and steps according to several embodiments of the techniques described herein for improving LTM. In the scenarios shown here, two consecutive LTM cell switching procedures are triggered. The sequences shown in Figures 8A and 8B differ from the sequence in Figure 6, which begins at step 12. The remaining steps and signals shown in this figure are as follows: ●Steps 12 and 13. When the first target DU detects the receipt of uplink data or signaling from the UE, it sends an ACCESS SUCCESS to the CU indicating that the UE has arrived at the first target cell. The first target DU also forwards any received LTM cell switching complete messages, such as the RRCReconfigurationComplete message, which are carried within the UL RRC MESSAGE TRANSFER message, to the CU. Note that even though this LTM cell switching complete message is received by the first target DU, in this example the lower-layer acknowledgment sent to the UE for this message has been lost, so the UE still needs to assume that the message has not yet been received by the network. ●Step 14. (Shown in the upper right of Figure 8B). Upon receiving an LTM cell switching complete message, such as the RRCReconfigurationComplete message, the CU uses the applied LTM candidate instructions to determine that the UE has applied a specific LTM candidate cell configuration, in this case the LTM candidate cell configuration for the first target cell. ●Step 15.CU sends a message to the Serving DU to notify about the applied LTM candidate, including instructions for setting the LTM candidate cell for the first target cell. This message can be a new message for a Class 2 procedure, or a UE context modification procedure can be used. ●Steps 16-22. Same as steps 13-19 in Figure 6. ●Step 23. Upon receiving a first LTM cell switching completion message, such as the RRCReconfigurationComplete message, the CU uses the applied LTM candidate instructions to determine that the UE has applied a specific LTM candidate cell configuration, in this case, the LTM candidate cell configuration for the first target cell. However, the CU determines that this indication is a duplicate of an instruction previously received in step 13. ●Steps 24-27. Same as steps 22-25 in Figure 6.

[0076] Figure 9 is a process flow diagram illustrating the steps of an exemplary method using the techniques described herein, as implemented by the UE. The steps performed by the UE in this example are as follows: ●Step 910.UE receives at least one LTM candidate cell configuration from the network. ●Step 920. The UE receives an LTM cell switching command and triggers the LTM cell switching procedure. The LTM cell switching command includes instructions for setting up an LTM candidate cell with respect to a first target cell. Note that, as described elsewhere in this specification, the UE may also perform an LTM cell switching that is not triggered by receiving an LTM cell switching command, for example, in response to the fulfillment of certain conditions or when the LTM cell switching procedure is triggered by fault recovery. Box 920 in Figure 9 is outlined with a dashed line to indicate that it is not necessary to be present in all examples or embodiments of the illustrated method. ●Step 930. In response to the LTM cell switching command, the UE executes an LTM cell switching procedure, which includes applying the indicated LTM candidate cell settings. ● Step 940.UE sends an LTM cell switching complete message, such as an RRCReconfigurationComplete message, in the first target cell according to the applied LTM candidate cell configuration. The LTM cell switching complete message includes instructions for the applied LTM candidate, such as instructions for the LTM candidate cell configuration for the first target cell.

[0077] Accordingly, embodiments of the techniques described herein include methods in a wireless device or UE operating within a wireless network, the exemplary method including receiving an LTM candidate cell configuration from a network node in the wireless network and performing an LTM cell switching procedure by applying the received indicated LTM candidate cell configuration. This exemplary method further includes sending an LTM cell switching complete message to the network node, which includes instructions for the LTM candidate to be applied to the LTM cell switching procedure. This LTM cell switching complete message may be, for example, an RRCReconfigurationComplete message, which includes the instructions described herein.

[0078] The instruction for the applied LTM candidate could be any one of the following: a cell instruction such as a cell identifier (e.g., PCI, CGI); an instruction for the LTM candidate cell configuration such as an LTM candidate cell configuration index or LTM candidate cell configuration identification information; a beam instruction such as an SSB index or CSI-RS resource identifier; an instruction for an RRC message for the LTM, such as a message identifier for an RRC message used to provide the LTM candidate cell configuration; and an instruction that the LTM cell switchover complete message is for the LTM. Thus, the instruction for the applied LTM candidate is an identifier or other instruction that enables nodes in the network to match the cell switchover complete message to the LTM candidate cell configuration and / or cell switchover procedure. This allows the network to resolve the aforementioned ambiguous scenarios arising from certain situations in which multiple LTM cell switchover procedures are executed sequentially.

[0079] For example, considering scenarios like those shown in Figures 7 and 8, as well as the "normal" scenario shown in Figure 6, it will be understood that the LTM cell switching complete message can be sent to any of several network nodes. In some cases, it is sent to the first target network node, i.e., the network node that controls the target cell for the LTM cell switching procedure. An example of this is shown in Figure 6. In other cases, the LTM cell switching procedure to the first target cell is followed by a second LTM cell switching procedure to a second target cell controlled by a second target network node, in which case the LTM cell switching complete message corresponding to the first LTM cell switching procedure may be sent to the second target network node, along with instructions for the applied LTM candidate corresponding to the first LTM cell switching procedure. Examples of this are shown in Figures 7 and 8. In these cases, the UE may then send a second LTM cell switching complete message, along with instructions for the applied LTM candidate corresponding to the second LTM cell switching procedure, to, for example, the second target network node. Again, this example is shown in Figures 7 and 8. In various other cases, an LTM cell switching complete message, which includes instructions for the applied LTM candidate for the first LTM cell switching procedure, may be sent to a third network node, such as a central unit (CU) controlling a first or second network node, in various scenarios as described above.

[0080] In some of the examples or embodiments described above, the execution of the LTM cell switching procedure can be triggered by the reception of an LTM cell switching command. (This is shown as an example in block 920.) This command may be received, for example, from a source network node such as a Serving Distribution Unit (DU) (see Figures 6-8), and triggers, for example, an LTM cell switching procedure to a first target cell controlled by a first target network node, as described above. Note that this first target network node may, in some cases, be the same network node that controls the source cell, i.e., the source network node, or the first target network node may be a different network node. In some cases, for example, as shown in Figures 7 and 8, the execution of the LTM cell switching procedure to the first target cell may be followed by the reception of a second LTM cell switching command, which triggers a second LTM cell switching procedure to a second target cell controlled by a second target network, and this second LTM cell switching command is sent by the first target network node.

[0081] Figure 10 is a process flow diagram showing the steps of an exemplary method performed by a network node, which may be, for example, the central unit (CU) of a gNB, for example, the third network node 506 in Figure 5. The steps performed by the network node in this example include: ●Step 1010.CU prepares at least one LTM candidate cell configuration and sends it to the UE. ●Step 1020.CU receives an LTM cell switching complete message indicating that the UE has executed the LTM cell switching procedure, which includes instructions for the applied LTM candidate. ●Step 1030.CU uses the applied LTM candidate instructions to determine that the UE has applied a certain LTM candidate cell setting, in this case an LTM candidate cell setting for the first target cell. ●Step 1040.CU sends a message to the source DU to notify about the applied LTM candidate (instructions for the applied LTM candidate), which includes instructions for setting up the LTM candidate cell for the first target cell.

[0082] For example, from Figures 6 to 8, it will be understood that there are corresponding complementary methods performed on other network nodes, including a first target network node (e.g., a first target gNB or DU0) and a second target network node. An exemplary method performed by the first target network node to process the LTM cell switching procedure includes receiving an LTM cell switching complete message from the UE, which includes an indication of the applied LTM candidate. As mentioned above, the LTM cell switching complete message may be, for example, an RRCReconfigurationComplete message. Similarly, the indication of the applied LTM candidate may be, for example, one of the various indicators or identifiers mentioned above in relation to Figure 9. This exemplary method may further include determining, based on the LTM cell switching complete message, for example, based on the indication of the applied LTM candidate, that the execution of the LTM cell switching procedure for the UE is complete.

[0083] In various embodiments and / or examples, the first target network node determines, based on the LTM cell switching complete message, that the UE has performed one of the following actions: switching to a specific cell controlled by the first or second target network node; applying a specific LTM candidate cell configuration controlled by the first, second, or third network node; switching to a specific beam controlled by the first or second target network node; or executing a specific procedure, transaction, or message instance, such as a specific RRC procedure or MAC CE instance. In some embodiments or examples, the first target network sends an instruction to the source network node for the LTM cell switching procedure, or to the second target network node (e.g., the target for the second LTM cell switching procedure for the UE), or to the third network node (e.g., the CU), indicating that the execution of the LTM cell switching procedure for the UE is complete. This instruction that execution is complete may be included, for example, in a UL RRC MESSAGE TRANSFER message, an ACCESS SUCCESS message, a UE CONTEXT MODIFICATION REQUIRED message, or a new type of F1AP message.

[0084] In some embodiments or examples, the first target network node may receive an instruction from a second target network node or a third network node indicating that the execution of the LTM cell switching procedure for the UE is complete. This instruction, which may take the form of a UE CONTEXT MODIFICATION REQUEST message, may relate to a second LTM cell switching procedure executed by the UE and triggered by the first target network node.

[0085] An exemplary method for a second target network node (such as a second target gNB, a second target DU, etc.) to process an LTM cell switching procedure for a UE may include receiving an LTM cell switching completion message from the UE, which includes an indication of the applied LTM candidate. This indication of the applied LTM candidate, which may be one of the indicators or identifiers described above, may relate, for example, to a previous LTM cell switching procedure by the UE to a target network node other than the second target network node. The method to be performed by the second target network node may further include determining based on the message, for example, based on the indication that the execution of the LTM cell switching procedure for the UE is complete. This decision by the second target network node may, in various examples or embodiments, include determining that the UE has performed one of the following actions: switching to a specific cell controlled by the second or first target network node; applying a specific LTM candidate cell configuration controlled by the second, first, or third network node; switching to a specific beam controlled by the second or first target network node; and executing a specific procedure, transaction, or message instance, such as a specific RRC procedure or MAC CE instance.

[0086] In some embodiments or examples, a second target network node may send an instruction to, for example, a source network node, a first target network node, or a third network node, indicating that the execution of the LTM cell switching procedure for the UE is complete. This instruction may relate to a previous LTM cell switching procedure targeting the first target network node, as determined, for example, from an instruction in the LTM cell switching complete message. In various embodiments and / or examples, this instruction may be a UL RRC MESSAGE TRANSFER message containing the LTM cell switching complete message, an ACCESS SUCCESS message, a UE CONTEXT MODIFICATION REQUIRED message, or a new type of F1AP message.

[0087] In some embodiments or examples, a second target network node may receive an instruction from the first target network node or the third network node indicating that the execution of the LTM cell switching procedure for the UE is complete. This instruction may be, for example, a UE CONTEXT MODIFICATION REQUEST message.

[0088] A third network node, or a corresponding method in a serving network node such as a serving central unit (CU) or gNB, for processing an LTM cell switching procedure for a UE, includes the steps of: sending at least one LTM candidate cell configuration to the UE; and receiving an LTM cell switching complete message from the UE, the LTM cell switching complete message including an indication of the applied LTM candidate in response to sending an LTM cell switching command to initiate the LTM cell switching procedure.

[0089] In various embodiments, when a third network node sends at least one LTM candidate cell configuration to the UE, the third network node includes, along with or within the message carrying the LTM candidate cell configuration, one or more of the following instructions: an identifier for a procedure, transaction, or message instance, such as an RRC transaction identifier used only when sending the LTM candidate cell configuration; an identifier for a procedure, transaction, or message instance, such as an RRC transaction identifier; an identifier for a procedure, transaction, or message instance, such as an RRC transaction identifier, which is an extension of an existing identifier for a procedure, transaction, or message instance; and / or, when the UE sends an LTM cell switchover complete message, the RRC message carrying the LTM cell switchover complete message should also include an instruction that this LTM cell switchover complete message is related to LTM.

[0090] As described above, the applied LTM candidate instructions received from the UE may include cell instructions such as cell identifiers (e.g., PCI, CGI), LTM candidate cell setting instructions such as LTM candidate cell setting index or LTM candidate cell setting identification information, beam instructions such as SSB index or CSI-RS resource identifier, procedure, transaction, or message instance identifiers such as RRC transaction identifier, and / or instructions that the LTM cell switchover completion message is related to LTM.

[0091] In some embodiments or cases, the third network node determines that the execution of the LTM cell switching procedure for the UE is complete, and the applied LTM candidate designation may be used for the determination in some cases or embodiments. The third network node may determine that the UE has performed one of the following: switching to a specific cell controlled by the first or second target network node; applying a specific LTM candidate cell configuration controlled by the third network node, the first target network node, or the second target network node; switching to a specific beam, the first target network node, or the second target network node; or executing a specific procedure, transaction, or message instance, such as a specific RRC procedure or MAC CE instance.

[0092] In some embodiments or examples, the third network node sends an instruction to the first or second target network node indicating that the execution of the LTM cell switching procedure for the UE is complete. This may be, for example, a UE CONTEXT MODIFICATION REQUEST message.

[0093] In other embodiments or examples, a third network node may receive an instruction from the first or second target network node that the execution of the LTM cell switching procedure for the UE is complete. This could be, for example, a UL RRC MESSAGE TRANSFER message containing an LTM cell switching completion message, or an ACCESS SUCCESS message, or a UE CONTEXT MODIFICATION REQUIRED message, or a new type of F1AP message.

[0094] In some embodiments or examples, a third network node receives a first LTM cell switching complete message following the execution of a first LTM cell switching procedure, and a second LTM cell switching complete message following the execution of a second LTM cell switching procedure. In some of these embodiments or examples, the third network node may determine that the first and second LTM cell switching complete messages are redundant, and this determination may be based on the instructions for the applied LTM candidate in the first and second LTM cell switching complete messages, such that the first and second LTM cell switching complete messages contain the same instructions for the applied LTM candidate.

[0095] Similarly, in some embodiments or examples, a third network node may receive a first LTM cell switching completion message following the execution of a first LTM cell switching procedure, and may further receive second and third LTM cell switching completion messages following the execution of a second LTM cell switching procedure. In these embodiments, the third network node may determine that two of the first, second, or third LTM cell switching completion messages are redundant, for example, by including the fact that the applied LTM candidate instructions in two of the first, second, or third LTM cell switching completion messages contain the same applied LTM candidate instructions.

[0096] Although various embodiments have been described above with respect to methods, techniques, and / or procedures, those skilled in the art will readily understand that such methods, techniques, and / or procedures can be implemented in various combinations of hardware and software in various systems, communication devices, computing devices, control devices, apparatus, non-temporary computer-readable media, computer program products, and the like.

[0097] Figure 11 shows examples of communication systems 1100 according to several embodiments. In this example, communication system 1100 includes a communication network 1102, which includes an access network 1104 (e.g., RAN) and a core network 1106, which includes one or more core network nodes 1108. The access network 1104 includes one or more access network nodes, such as network nodes 1110a-b (one or more of which may generally be referred to as network node 1110), or any other similar 3GPP access nodes or non-3GPP access points. The network nodes 1110 facilitate direct or indirect connections of UEs, such as by connecting UEs 1112a-d (one or more of which may generally be referred to as UE1112) to the core network 1106 over one or more wireless connections.

[0098] Exemplary wireless communication on a wireless connection includes transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information, without using wires, cables, or other material conductors. Furthermore, in different embodiments, the communication system 1100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals, whether or not via a wired or wireless connection. The communication system 1100 may include and / or interface with any type of communication, remote communication, data, cellular, wireless network, and / or other similar types of systems.

[0099] UE1112 may be any of a wide variety of communication devices, including wireless devices that are configured, set up, and / or capable of communicating wirelessly with network node 1110 and other communication devices. Similarly, network node 1110 may be configured, capable, set up, and / or capable of communicating directly or indirectly with UE1112 and / or other network nodes or devices in the communication network 1102 to enable and / or provide network access, such as wireless network access, and / or perform other functions, such as management within the communication network 1102.

[0100] In the illustrated example, the core network 1106 connects network node 1110 to one or more hosts, such as host 1116. 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. The core network 1106 includes one or more core network nodes (e.g., core network node 1108) constructed of hardware and software components. The characteristics of these components may be substantially similar to those described for the UE, network nodes, and / or hosts, and therefore, their descriptions are generally applicable to the corresponding components of core network node 1108. An exemplary core network node includes one or more functions from among 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), Subscriber Identifier Decryption Function (SIDF), Unified Data Management (UDM), Security Edge Protected Proxy (SEPP), Network Exposure Function (NEF), and / or User Plane Function (UPF).

[0101] Host 1116 may be owned or controlled by a service provider other than the operator or provider of the access network 1104 and / or the communication network 1102, and may be operated by or on behalf of the service provider. Host 1116 may host a variety of applications to provide one or more services. Examples of such applications include live and pre-recorded audio / video content, data acquisition services such as extracting and compiling data on various ambient conditions detected by multiple UEs, analytical functions, social media, functions for controlling or, optionally, interacting with remote devices, functions for alarms and surveillance centers, or any other such functions performed by the server.

[0102] Overall, the communication system 1100 in Figure 11 enables connectivity between UEs, network nodes, and hosts. In this sense, the communication system may be configured to operate according to predefined rules or procedures, including but not limited to, certain standards: Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G, or any applicable next-generation standard (e.g., 6G); Wireless Local Area Network (WLAN) standards such as the IEEE 802.11 standard (WiFi); and / or any other suitable wireless communication standards such as Global Interoperability for Microwave Access (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.

[0103] In some examples, the communication network 1102 is a cellular network implementing 3GPP standardization functions. Therefore, the communication network 1102 can support network slicing to provide different logical networks to different devices connected to the communication network 1102. For example, the communication network 1102 can provide ultra-high reliability low latency communication (URLLC) services to several UEs while providing extended mobile broadband (eMBB) services to other UEs and / or massive machine-type communications (mMTC) / massive IoT services to even further UEs.

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

[0105] In this example, the hub 1114 communicates with the access network 1104 to facilitate indirect communication between one or more UEs (e.g., UE1112c and / or 1112d) and a network node (e.g., network node 1110b). In some examples, the hub 1114 may be a controller, a router, a content source and content analysis device, or any other communication device described herein with respect to the UE. For example, the hub 1114 may be a broadband router that enables the UE to access the core network 1106. In another example, the hub 1114 may be a controller that sends commands or instructions to one or more actuators within the UE. The commands or instructions may be received from the UE, the network node 1110, or by executable code, scripts, processes, or other instructions in the hub 1114. In yet another example, the hub 1114 may be a data collector acting as temporary storage for UE data, and in some embodiments may perform data analysis or other processing. In yet another example, the hub 1114 may be a content source. For example, with respect to a UE that is a VR headset, display, loudspeaker, or other media distribution device, the hub 1114 can retrieve VR assets, video, audio, or other media or data related to sensory information via network nodes, which the hub 1114 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In yet another example, the hub 1114 functions as a proxy server or orchestrator for the UE, especially if one or more of the UEs are low-energy IoT devices.

[0106] Hub 1114 can have a permanent / persistent or intermittent connection to network node 1110b. Hub 1114 can also enable different communication methods and / or schedules between Hub 1114 and UEs (e.g., UE 1112c and / or 1112d), and between Hub 1114 and the core network 1106. In other examples, Hub 1114 connects to the core network 1106 and / or one or more UEs via a wired connection. Furthermore, Hub 1114 may be configured to connect to an M2M service provider on the access network 1104 and / or another UE via a direct connection. In some scenarios, a UE may establish a wireless connection with network node 1110 while still connected via Hub 1114 via a wired or wireless connection. In some embodiments, Hub 1114 may be a dedicated hub, i.e., a hub whose primary function is to route communications to and from UEs to and from network node 1110b. In other embodiments, the hub 1114 may be a non-dedicated hub, i.e., a device capable of routing communication between the UE and the network node 1110b, but additionally capable of acting as a communication start and / or end point for a specific data channel.

[0107] Figure 12 shows a UE1200 in some embodiments. Examples of UEs include, but are not limited to, smartphones, mobile phones, cell 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, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablets, laptop computers, laptop embedded devices (LEEs), laptop computer-equipped devices (LMEs), smart devices, wireless customer premises equipment (CPEs), and vehicle-mounted or vehicle-embedded / integrated wireless devices. Other examples include any UE identified by 3GPP, including narrowband Internet of Things (NB-IoT) UEs, machine-type communications (MTC) UEs, and / or enhanced MTC (eMTC) UEs.

[0108] A UE can support device-to-device (D2D) communication, for example, by implementing 3GPP standards for side-link communication, dedicated short-range communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-board (V2I), or vehicle-to-all (V2X). In other examples, a UE does not necessarily have a user in the sense of a human user who owns and / or operates the associated device. Instead, a UE may represent a device (e.g., a smart sprinkler controller) that is intended for sale to or operation by a human user, but may not be associated with a specific human user, or may not be initially associated with a specific human user. Alternatively, a UE may represent a device (e.g., a smart electricity meter) that is not intended for sale to or operation by an end user, but may be associated with a user or operated for the user's benefit.

[0109] The UE1700 includes a processing circuit 1202 operably coupled via bus 1204 to an input / output interface 1206, a power supply 1208, memory 1210, a communication interface 1212, and / or any other components, or any combination thereof. Several UEs may utilize all or a subset of the components shown in Figure 12. The level of integration between components may vary from one UE to another. Furthermore, some UEs may include multiple instances of components, such as multiple processors, memories, transceivers, transmitters, and receivers.

[0110] The processing circuit 1202 is configured to process instructions and data and may be configured to implement any sequential state machine capable of executing instructions stored in memory 1210 as machine-readable computer programs. The processing circuit 1202 may be implemented as one or more stored computer programs, general-purpose processors, or any combination of the above, such as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), programmable logic with appropriate firmware, or microprocessors or digital signal processors (DSPs) with appropriate software. For example, the processing circuit 1202 may have multiple central processing units (CPUs).

[0111] In this example, the input / output interface 1206 may 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, emitters, smart cards, other output devices, or any combination thereof. Input devices may allow a user to bring information into the UE1200. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital video cameras, webcams, etc.), microphones, sensors, mice, trackballs, directional pads, trackpads, scroll wheels, smart cards, etc. Presence-sensitive displays may include capacitive or resistive touch sensors for detecting user input. Sensors may include, for example, accelerometers, gyroscopes, tilt sensors, force sensors, magnetometers, light sensors, proximity sensors, biosensors, 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 may be used to provide input and output devices.

[0112] In some embodiments, the power supply 1208 is constructed as a battery or battery pack. Other types of power sources may be used, such as an external power source (e.g., an electrical outlet), a photovoltaic device, or a battery. The power supply 1208 may further include a power circuit for distributing power from the power supply 1208 itself and / or from an external power source via an interface such as an input circuit or power cable. Distributing power may, for example, be for charging the power supply 1208. The power circuit may perform any formatting, converting, or other modifications to the power from the power supply 1208 to make that power suitable for each component of the UE2200 being powered.

[0113] Memory 1210 is or may be configured to include 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), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and other types of memory. In one example, memory 1210 includes one or more application programs 1214, such as an operating system, a web browser application, a widget, a gadget engine, or other application, and corresponding data 1216. Memory 1210 can store a wide variety of operating systems or combinations of operating systems for use by the UE2200.

[0114] Memory 1210 may be configured to include several physical drive units such as a redundant array of independent disks (RAID), flash memory, USB flash drives, external hard disk drives, thumb drives, pen drives, key drives, high-density digital versatile disk (HD-DVD) optical disc drives, internal hard disk drives, Blu-ray optical disc drives, holographic digital data storage (HDDS) optical disc drives, external mini dual in-line memory modules (DIMMs), synchronous dynamic random access memory (SDRAM), external microDIMM SDRAM, smart card memory such as a tamper-resistant module in the form of a universal integrated circuit card (UICC) containing one or more subscriber identification modules (SIMs) such as USIM and / or ISIM, other memory, or any combination thereof. The UICC may be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly known as a "SIM card". Memory 1210 can enable UE 1200 to access instructions, application programs, etc., stored on temporary or non-temporary memory media, offload data, or upload data. Products that utilize a communication system, such as manufactured goods, may be tangibly embodied as a memory 1210 or within the memory 1210, and the memory 1210 may be a device-readable storage medium or may include a device-readable storage medium.

[0115] The processing circuit 1202 may be configured to communicate with an access network or other networks using a communication interface 1212. The communication interface 1212 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 1222. The communication interface 1212 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or network node in the access network). Each transceiver may include a transmitter 1218 and / or receiver 1220 suitable for providing network communication (e.g., optical, electrical, frequency-allocated, etc.). Furthermore, the transmitter 1218 and receiver 1220 may be coupled to one or more antennas (e.g., antenna 1222) and may share circuit components, software or firmware, or alternatively, be implemented separately.

[0116] In the illustrated embodiment, the communication functions of the communication interface 1212 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 the use of the Global Positioning System (GPS) for determining location, other similar communication functions, or any combination thereof. The communication may be implemented in accordance with 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 Network (SONET), Asynchronous Transfer Mode (ATM), QUIC, and Hypertext Transfer Protocol (HTTP).

[0117] Regardless of the sensor type, the UE can provide an output of data captured by its sensors through its communication interface 1212 via a wireless connection to a network node. The data captured by the UE's sensors can be communicated via another UE through a wireless connection to a network node. The output may be periodic (e.g., once every 15 minutes if reporting detected temperature), in response to a triggering event (e.g., an alarm is sent when humidity is detected), in response to a request (e.g., a user-initiated request), random (e.g., to equalize the load from reports from several sensors), or a continuous stream (e.g., a live video feed of a patient).

[0118] As another example, the UE may include actuators, motors, or switches related to a communication interface configured to receive radio input from a network node via a wireless connection. The state of the actuators, motors, or switches may change in response to the received radio input. For example, the UE may include a motor that adjusts the control surface or rotors of a drone in flight according to the received input, or a robotic arm that performs a medical procedure according to the received input.

[0119] When in the form of an Internet of Things (IoT) device, a UE may be a device for use in one or more application areas, which include, but are not limited to, urban wearable technology, augmented industrial applications, and healthcare. Non-exclusive examples of such IoT devices include connected refrigerators or freezers, TVs, connected lighting devices, electricity meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door / window sensors, flood / humidity sensors, electric door locks, connected doorbells, air conditioning systems such as heat pumps, autonomous vehicles, surveillance 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), wearables for haptic augmentation or sensory augmentation, water sprinklers, animal or product 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 remotely controlled surgical robots, or devices incorporated into them. The UE in the form of an IoT device comprises circuitry and / or software depending on the intended application of the IoT device, in addition to the other components described with respect to the UE1200 shown in Figure 12.

[0120] In another specific example, in an IoT scenario, a UE may 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 may be an M2M device, which may be called an MTC device in the context of 3GPP. In one specific example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, the UE may represent a vehicle such as a car, bus, truck, ship, and airplane, or other equipment capable of monitoring its operating status and / or reporting on its operating status, or other functions associated with its operation.

[0121] In practice, any number of UEs can be used together for a single use case. For example, the first UE may be the drone itself, or integrated within the drone, providing speed information of the drone (acquired through a speed sensor) to the second UE, which is a remote controller that operates the drone. When the user makes a change from the remote controller, the first UE can adjust the throttle on the drone (for example, by controlling an actuator) to increase or decrease the drone's speed. The first and / or second UEs can also include two or more of the functions described above. For example, the UE may be equipped with sensors and actuators and be able to handle the communication of data about both the speed sensor and the actuator.

[0122] Figure 13 shows a network node 1300 according to some embodiments. Examples of network nodes include, but are not limited to, access points (e.g., wireless access points) and base stations (e.g., wireless base stations, node B, eNB, and gNB).

[0123] Base stations may be classified based on the amount of coverage they provide (or, in other words, the base station's transmit power level), and therefore may be called femto base stations, pico base stations, micro base stations, or macro base stations in response to the amount of coverage they provide. A base station may also be a relay node or relay donor node that controls relays. A network node may also include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit and / or a remote radio unit (RRU), which may be called a remote radio head (RRH). Such a remote radio unit may or may not be integrated with an antenna as an antenna-integrated radio. Parts of a distributed radio base station may also be called nodes in a distributed antenna system (DAS).

[0124] Other examples of network nodes include multiple transmit point (multi-TRP) 5G access nodes, MSR equipment such as multi-standard radio (MSR) BS, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base station transceiver stations (BTSs), transmit points, transmit nodes, multi-cell / multicast coordination entities (MCEs), operation and maintenance (O&M) nodes, operation support system (OSS) nodes, self-organizing network (SON) nodes, positioning nodes (e.g., extended serving mobile location centers (E-SMLCs)), and / or drive test minimization (MDTs).

[0125] Network node 1300 includes processing circuitry 1302, memory 1304, communication interface 1306, and power supply 1308. Network node 1300 may consist of multiple physically separate components (e.g., node B components and RNC components, or BTS components and BSC components), each of which may have its own separate components. In certain scenarios where network node 1300 has multiple separate components (e.g., BTS components and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple node Bs. In such a scenario, each unique node B-RNC pair may, in some cases, be considered a single separate network node. In some embodiments, network node 1300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 1304 for different RATs), and some components may be reused (e.g., the same antenna 1310 may be shared by different RATs). The network node 1300 may also include multiple sets of various indicated components for different radio technologies, such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, radio frequency identification (RFID), or Bluetooth radio technologies, which are integrated into the network node 1300. These radio technologies may be integrated into the same or different chips or sets of chips and other components within the network node 1300.

[0126] The processing circuit 1302 may include one or more combinations of microprocessors, controllers, microcontrollers, central processing units, digital signal processors, application-specific integrated circuits, field-programmable gate arrays, or any other suitable computing devices, resources, or combinations of hardware, software, and / or encoded logic, which are capable of operating alone or in combination with other network node 1300 components such as memory 1304 to provide network node 1300 functionality.

[0127] In some embodiments, the processing circuit 1302 includes a system-on-a-chip (SOC). In some embodiments, the processing circuit 1302 includes one or more of the radio frequency (RF) transceiver circuit 1312 and the baseband processing circuit 1314. In some embodiments, the radio frequency (RF) transceiver circuit 1312 and the baseband processing circuit 1314 may be on separate chips (or sets of chips), boards, or units such as radio and digital units. In alternative embodiments, some or all of the RF transceiver circuit 1312 and the baseband processing circuit 1314 may be on the same chip or set of chips, board, or unit.

[0128] Memory 1304 may include, but is not limited to, any form of volatile or non-volatile computer-readable and / or computer-executable memory device that stores information, data, and / or instructions that can be used by processing circuit 1302, including persistent storage, 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 drive, compact disc (CD), or digital video disc (DVD)), and / or any other volatile or non-volatile non-temporary device-readable and / or computer-executable memory device. Memory 1304 may store any suitable instructions, data, or information, including other instructions (collectively referred to as computer program product 1304a) that can be executed by one or more computer programs, software, logic, rules, code, or tables, and / or by processing circuit 1302 and utilized by network node 1300. The memory 1304 may be used to store calculations performed by the processing circuit 1302 and / or data received via the communication interface 1306. In some embodiments, the processing circuit 1302 and the memory 1304 are integrated.

[0129] The communication interface 1306 is used in wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As illustrated, the communication interface 1306 includes, for example, a port / terminal 1316 for sending and receiving data to and from the network over a wired connection. The communication interface 1306 also includes a wireless front-end circuit 1318, which is coupled to or, in some embodiments, may be part of the antenna 1310. The wireless front-end circuit 1318 includes a filter 1320 and an amplifier 1322. The wireless front-end circuit 1318 can be connected to the antenna 1310 and the processing circuit 1302. The wireless front-end circuit may be configured to adjust signals communicated between the antenna 1310 and the processing circuit 1302. The wireless front-end circuit 1318 may receive digital data transmitted to other network nodes or UEs via the wireless connection. The wireless front-end circuit 1318 can convert digital data into a radio signal with appropriate channel and bandwidth parameters using a combination of the filter 1320 and / or amplifier 1322. The radio signal may then be transmitted via the antenna 1310. Similarly, when receiving data, the antenna 1310 can collect the radio signal, which is then converted into digital data by the wireless front-end circuit 1318. The digital data may then be passed to the processing circuit 1302. In other embodiments, the communication interface may include different components and / or different combinations of components.

[0130] In certain alternative embodiments, the network node 1300 does not include a separate radio front-end circuit 1318; instead, the processing circuit 1302 includes the radio front-end circuit and is connected to the antenna 1310. Similarly, in some embodiments, all or part of the RF transceiver circuit 1312 is part of the communication interface 1306. In yet another embodiment, the communication interface 1306, as part of a radio unit (not shown), includes one or more ports or terminals 1316, the radio front-end circuit 1318, and the RF transceiver circuit 1312, and the communication interface 1306 communicates with a baseband processing circuit 1314, which is part of a digital unit (not shown).

[0131] Antenna 1310 may include one or more antennas or antenna arrays configured to transmit and / or receive radio signals. Antenna 1310 may be coupled to the radio front-end circuit 1318 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In certain embodiments, antenna 1310 may be isolated from the network node 1300 and connectable to the network node 1300 via an interface or port.

[0132] Antenna 1310, communication interface 1306, and / or processing circuit 1302 may be configured to perform any receiving operations and / or some acquiring operations as 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 equipment. Similarly, antenna 1310, communication interface 1306, and / or processing circuit 1302 may be configured to perform any transmitting operations as 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 equipment.

[0133] Power supply 1308 powers the various components of network node 1300 in a form appropriate to each component (for example, at the voltage and current levels required for each component). Power supply 1308 may further include, or be coupled to, a power management circuit for supplying power to the components of network node 1300 to perform the functions described herein. For example, network node 1300 may be connectable to an external power source (e.g., a power grid, an electrical outlet) via an interface such as an input circuit or electrical cable, thereby allowing the external power source to power the power circuit of power supply 1308. As a further example, power supply 1308 may include a power source in the form of a battery or battery pack connected to or integrated into the power circuit. The battery can provide backup power in the event of an external power failure.

[0134] Embodiments of network node 1300 may include additional components other than those shown in Figure 13 to provide some aspects of the network node's functionality, including any of the functions described herein and / or functions necessary to support the subject matter described herein. For example, network node 1300 may include user interface equipment for enabling information input to and output from network node 1300. This may enable a user to perform diagnostic, maintenance, repair, and other management functions of network node 1300.

[0135] Figure 14 is a block diagram of host 1400, which may be an embodiment of host 1116 of Figure 11, according to various aspects described herein. Host 1400 as used herein may be a variety of hardware and / or software combinations, or comprise a variety of hardware and / or software combinations, including standalone servers, blade servers, cloud implementation servers, distributed servers, virtual machines, containers, or processing resources in a server farm. Host 1400 can provide one or more services to one or more UEs.

[0136] The host 1400 includes an input / output interface 1406, a network interface 1408, a power supply 1410, and a processing circuit 1402 operably coupled via a bus 1404 to a memory 1412. Other embodiments may include other components. The characteristics of these components may be substantially the same as those described with respect to the devices in previous figures, such as Figures 12 and 13, and thereafter, their descriptions are generally applicable to the corresponding components of the host 1400.

[0137] Memory 1412 may include one or more computer programs, each containing one or more host application programs 1414 and data 1416, the data 1416 of which may include user data, for example, data generated by the UE for host 1400, or data generated by host 1400 for the UE. Embodiments of host 1400 may utilize only a subset or all of the illustrated components. Host application programs 1414 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Multipurpose Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementation forms of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application program 1414 can also provide user authentication and licensing checks and periodically report health, route, and content availability to central nodes such as devices within or on the edge of the core network. Thus, host 1400 can select and / or direct different hosts for over-the-top services for the UE. The host application program 1414 can support various protocols such as HTTP Live Streaming (HLS), Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), and Dynamically Adaptive HTTP Streaming Over (MPEG-DASH).

[0138] Figure 15 is a block diagram showing a virtualization environment 1500 in which functions implemented by some embodiments may be virtualized. In this context, virtualization means creating a virtual version of an apparatus or device, which may include virtualizing hardware platforms, storage devices, and networking resources. The virtualization used herein may apply to any device or its components described herein and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components run by one or more virtual machines (VMs) implemented within one or more virtualization environments 1500, which are hosted by one or more hardware nodes, such as network nodes, UEs, core network nodes, or hardware computing devices acting as hosts. Furthermore, in embodiments in which the virtual nodes do not require wireless connectivity (e.g., core network nodes or hosts), the nodes may be fully virtualized.

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

[0140] Hardware 1504 includes processing circuits, memory for storing software (collectively referred to as computer program product 1504a) and / or instructions executable by the hardware processing circuits, and / or other hardware devices described herein, such as network interfaces and input / output interfaces. The software is executed by the processing circuits to instantiate one or more virtualization layers 1506 (also called a hypervisor or virtual machine monitor (VMM)), providing VMs 1508a-b (one or more of them may commonly be referred to as VM 1508), and / or implementing any of the functions, features and / or benefits described with respect to some embodiments described herein. The virtualization layer 1506 may present a virtual operating platform that appears to the VM 1508 as networking hardware.

[0141] VM1508 may feature virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and may be powered by the corresponding virtualization layer 1506. Different embodiments of the virtual appliance 1502 example may be implemented in one or more VM1508s, and the implementation may be carried out in different ways. Hardware virtualization is referred to in some contexts as network function virtualization (NFV). NFV may be used to aggregate many types of network equipment on industry-standard high-volume server hardware, physical switches, and physical storage that can be located in data centers and customer premises equipment.

[0142] In the context of NFV, VM1508 may be a software implementation of a physical machine that runs the program as if it were running on a physical, non-virtualized machine. Each VM1508 and its portion of the hardware 1504 on which it runs, whether that hardware is dedicated to that VM and / or shared by that VM with other VMs in the VM, form a separate virtual network element. Furthermore, in the context of NFV, the virtual network function is responsible for handling specific network functions running on one or more VM1508s on the hardware 1504 and corresponds to application 1502.

[0143] Hardware 1504 may be implemented in a standalone network node with general or specific components. Hardware 1504 may implement some functions through virtualization. Alternatively, hardware 1504 may be part of a larger cluster of hardware (e.g., within a data center or CPE) where many hardware nodes cooperate and are managed via management and organization 1510, which oversees, among other things, the lifecycle management of application 1502. In some embodiments, hardware 1504 is coupled to one or more radio units, each including one or more transmitters and one or more receivers, which may 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 a virtual node with radio capabilities, such as a radio access node or base station. In some embodiments, some signaling may be provided using a control system 1512, which may be used alternatively for communication between hardware nodes and radio units.

[0144] Figure 16 shows a communication diagram of a host 1602 communicating with a UE 1606 via a network node 1604 through a partial wireless connection, according to one embodiment. Next, exemplary implementations of the UEs (such as UE 1112a in Figure 11 and / or UE 1200 in Figure 12), network nodes (such as network node 1110a in Figure 11 and / or network node 1300 in Figure 13), and hosts (such as host 1116 in Figure 11 and / or host 1400 in Figure 14), discussed in the previous paragraph, according to various embodiments, will be described with reference to Figure 16.

[0145] Similar to host 1400, embodiments of host 1602 include hardware such as a communication interface, processing circuitry, and memory. Host 1602 also includes software that is stored in or accessible by host 1602 and executable by the processing circuitry. The software may include a host application that can operate to serve remote users, such as UE 1606, which connects via an over-the-top (OTT) connection 1650 extending between UE 1606 and host 1602. When serving remote users, the host application may provide user data transmitted using the OTT connection 1650.

[0146] Network node 1604 includes hardware that enables network node 1604 to communicate with host 1602 and UE 1606. The connection 1660 may be direct or pass through a core network (similar to core network 1106 in Figure 11) and / or one or more other intermediate networks, such as one or more public networks, private networks, or hosted networks. For example, the intermediate network could be a backbone network or the internet.

[0147] UE1606 includes hardware and software stored in or accessible by UE1606 and executable by the UE's processing circuitry. The software includes client applications, such as a web browser or operator-specific “app,” which may operate to serve human or non-human users via UE1606 with the support of host 1602. On host 1602, a running host application can communicate with a running client application via an OTT connection 1650 terminating at UE1606 and host 1602. When serving a user, the UE's client application can receive request data from the host's host application and provide user data in response to the request data. The OTT connection 1650 can transfer both request data and user data. The UE's client application can interact with the user and generate user data to provide to the host application via the OTT connection 1650.

[0148] The OTT connection 1650 can provide connectivity between host 1602 and UE 1606 by extending through connection 1660 between host 1602 and network node 1604, and through radio connection 1670 between network node 1604 and UE 1606. Connections 1660 and radio connection 1670, which the OTT connection 1650 may provide, are depicted abstractly to illustrate communication between host 1602 and UE 1606 via network node 1604 without explicitly referring to any intermediate devices and the exact routing of messages through these devices.

[0149] As an example of transmitting data via the OTT connection 1650, in step 1608, host 1602 provides user data, which may be done by running a host application. In some embodiments, the user data is associated with a specific human user interacting with UE 1606. In other embodiments, the user data is associated with UE 1606 sharing data with host 1602 without explicit human interaction. In step 1610, host 1602 initiates a transmission carrying user data toward UE 1606. Host 1602 may initiate a transmission in response to a request sent by UE 1606. The request may be triggered by human interaction with UE 1606 or by the operation of a client application running on UE 1606. The transmission may pass through network node 1604, as taught in the embodiments described throughout this disclosure. Accordingly, in step 1612, the network node 1604 transmits the user data carried in the transmission initiated by host 1602 to UE 1606 in accordance with the teachings of the embodiments described throughout this disclosure. In step 1614, UE 1606 receives the user data carried in the transmission, which may be executed by a client application running on UE 1606 associated with a host application run by host 1602.

[0150] In some examples, UE1606 runs a client application that provides user data to host 1602. User data may be provided in response to or in reaction to data received from host 1602. Thus, in step 1616, UE1606 can provide user data, which may be done by running a client application. When providing user data, the client application may further consider user input received from the user via the input / output interface of UE1606. Regardless of the particular way in which the user data is provided, in step 1618, UE1606 initiates transmission of the user data to host 1602 via network node 1604. In step 1620, in accordance with the teachings of embodiments described throughout this disclosure, network node 1604 receives user data from UE1606 and initiates transmission of the received user data to host 1602. In step 1622, host 1602 receives the user data carried in the transmission initiated by UE1606.

[0151] One or more of the various embodiments improve the execution of OTT services provided to UE 1606 by using an OTT connection 1650 in which the wireless connection 1670 forms the final segment. More precisely, the teachings of these embodiments can prevent a rogue RAN node from succeeding by repeatedly attempting to "guess" the security token associated with the LTM cell switching command for the UE. The embodiments can also prevent the UE from responding to a correct "guess" after repeated attempts. In this way, the embodiments can facilitate predictable UE behavior in LTM execution and prevent overload conditions in cells served by legitimate RAN nodes resulting from actions by a rogue RAN node. When the UE and RAN nodes thus improved are used to deliver OTT services, they increase the value of the OTT services to end users and service providers.

[0152] In an exemplary scenario, factory status information may be collected and analyzed by host 1602. As another example, host 1602 may process audio and video data that may have been extracted from the UE for use in creating maps. As yet another example, host 1602 may collect and analyze real-time data to assist in controlling traffic congestion (e.g., controlling traffic signals). As yet another example, host 1602 may store surveillance video uploaded by the UE. As yet another example, host 1602 may store or control access to media content, such as video, audio, VR or AR, which host 1602 can broadcast, multicast, or unicast to the UE. As yet another example, host 1602 may be used for energy pricing, remote control of non-time-constrained electrical loads to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, extracting, storing, analyzing, and / or transmitting data.

[0153] In some embodiments, measurement procedures may be provided for the purpose of monitoring data rate, latency, and other factors, which are improved by one or more embodiments. Furthermore, optional network functions may exist for reconfiguring the OTT connection 1650 between host 1602 and UE 1606 in response to variations in measurement results. The measurement procedures and / or network functions for reconfiguring the OTT connection may be implemented in the software and hardware of host 1602 and / or UE 1606. In some embodiments, sensors (not shown) may be deployed in or in relation to other devices through which the OTT connection 1650 passes, and the sensors may participate in the measurement procedures by supplying values ​​of the monitored quantities exemplified above, or values ​​of other physical quantities that the software can calculate or estimate the monitored quantities of. Reconfiguring the OTT connection 1650 may include message formatting, retransmission settings, preferred routing, etc., and the reconfiguration does not require direct modification of the operation of network node 1604. Such procedures and functions are known and may be practiced in the art. In certain embodiments, the measurements may involve proprietary UE signaling that facilitates measurements such as throughput, propagation time, and latency by host 1602. The measurements may be implemented in such a way that software uses the OTT connection 1650 to ensure that messages, particularly empty or "dummy" messages, are sent while monitoring propagation time, errors, etc.

[0154] The foregoing is merely an illustration of the principles of this disclosure. In view of the teachings herein, various modifications and alterations of the embodiments described will become apparent to those skilled in the art. Therefore, it will be understood that a number of systems, configurations, and procedures not expressly shown or described herein, but which embody the principles of this disclosure and thus fall within the spirit and scope of this disclosure, can be devised by those skilled in the art. Various embodiments can be used together and interchangeably with one another, as should be understood by those skilled in the art.

[0155] The term "unit" as used herein may have its conventional meaning in the field of electronics, electrical devices and / or electronic devices, and may 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 their respective tasks, procedures, calculations, outputs, and / or display functions, as described herein.

[0156] Any suitable step, method, feature, function, or benefit disclosed herein may be performed through one or more functional units or modules of one or more virtual devices. Each virtual device may comprise several of these functional units. These functional units may be implemented via processing circuits, which may include one or more microprocessors or microcontrollers, and other digital hardware, which may include digital signal processors (DSPs), dedicated digital logic, etc. The processing circuits may be configured to execute program code store-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 performing one or more of the techniques described herein. In some implementations, the processing circuits may be used to cause each functional unit to perform the corresponding function according to one or more embodiments of this disclosure.

[0157] As described herein, devices and / or apparatus may be represented by semiconductor chips, chipsets, or (hardware) modules comprising such chips or chipsets, but this does not exclude the possibility that the functionality of the device or apparatus may be implemented as a software module, such as a computer program or computer program product, comprising executable software code portions for or running on a processor, instead of being implemented in hardware. Furthermore, the functionality of a device or apparatus may be implemented by any combination of hardware and software. A device or apparatus may also be considered as an assembly of multiple devices and / or apparatus, whether functionally cooperating with each other or independent of each other. Moreover, devices and apparatus may be implemented distributed across a system, as long as the functionality of the device or apparatus is maintained. Such and similar principles are considered to be known to those skilled in the art.

[0158] Furthermore, the functions described herein as being implemented by a wireless device or network node may be distributed across multiple wireless devices and / or network nodes. In other words, the functions of network nodes and wireless devices described herein are not limited to implementation by a single physical device, but can actually be distributed across several physical devices.

[0159] Furthermore, some terms used in this disclosure, including in the specification, drawings, and embodiments, may be used synonymously in some cases, including, for example, data and information. It should be understood that while these and / or other words that may be synonymous with each other may be used synonymously in this specification, there may be instances where such words are not intended to be used synonymously. Furthermore, unless prior art knowledge is expressly incorporated herein by reference above, the entirety of the prior art knowledge is expressly incorporated herein. All referenced publications are incorporated herein by reference in their entirety.

[0160] Unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as those generally understood by those skilled in the art to which this disclosure belongs. Terms used herein should be interpreted as having the meanings of those terms in the context of this specification and related art, and not in an ideal or overly formal sense unless expressly provided herein.

[0161] In addition, some terms used in this disclosure, including in the specification and drawings, may be used synonymously in some cases (for example, “data” and “information”). While these terms (and / or other terms that may be synonymous with each other) may be used synonymously in this specification, it should be understood that there may be instances where such words are not intended to be used synonymously.

[0162] The techniques and apparatus described herein include, but are not limited to, the following listed examples:

[0163] A1. A method for user equipment (UE) for L1 / L2 triggered mobility (LTM) in a wireless network, Receiving LTM candidate cell settings from the wireless network, Execute the first LTM cell switching procedure, Send an LTM cell switching completion message to the wireless network, including instructions for the applied LTM candidate. A method that includes this.

[0164] A2. The LTM cell switching completion message is the RRCReconfigurationComplete message, according to Embodiment A1.

[0165] A3. The method according to embodiment A1 or A2, wherein the method includes receiving an LTM cell switching command, and the execution of a first LTM cell switching procedure is in response to the receipt of the LTM cell switching command.

[0166] A4. The instructions for the applied LTM candidate are: Cell instructions or identifiers, Instructions or identifiers for setting LTM candidate cells, Beam designation or identifier, Instructions or identifiers for the RRC message regarding LTM, The LTM cell switching complete message indicates that it is related to LTM. The method according to any one of embodiments A1 to A3, which is any one of the above, or includes the above.

[0167] A5. The method according to any one of embodiments A1 to A4, wherein an LTM cell switching completion message is sent to a first target network node, and the first target network node controls the target cell for the first LTM cell switching procedure.

[0168] A6. The method according to any one of Embodiments A1 to A4, further comprising executing a second LTM cell switching procedure following a first LTM cell switching procedure, wherein an LTM cell switching complete message is sent to a second target network node, which corresponds to the first LTM cell switching procedure, and the second target network node controls the target cell for the second LTM cell switching procedure.

[0169] A7. The method according to Embodiment A6, further comprising sending a second LTM cell switching complete message corresponding to a second LTM cell switching procedure, wherein the second LTM cell switching complete message includes a second instruction for the applied LTM candidate.

[0170] B1. A method for supporting L1 / L2 triggered mobility (LTM) of user equipment (UE) within a wireless network, with respect to network nodes within a wireless network, A method comprising receiving a first LTM cell switchover completion message from the UE, wherein the first LTM cell switchover completion message includes an indication of the applicable LTM candidate.

[0171] B2. The method according to Embodiment B1, wherein the first LTM cell switching completion message is the RRCReconfigurationComplete message.

[0172] B3. The instructions for the applied LTM candidate are: Cell instructions or identifiers, Instructions or identifiers for setting LTM candidate cells, Beam designation or identifier, Instructions or identifiers for the RRC message regarding LTM, The LTM cell switching complete message indicates that it is related to LTM. The method of Embodiment B1 or B2, which is any one of the above, or includes the above.

[0173] The method according to any one of Embodiments B1 to B3, wherein the network node that receives the LTM cell switching complete message is a first target network node, and the first target network node controls the target cell for the first LTM cell switching procedure.

[0174] B5. The method according to any one of embodiments B1 to B3, wherein the first LTM cell switching complete message corresponds to a first LTM cell switching procedure performed by the UE to a target cell controlled by a first target network node, but the network node receiving the first LTM cell switching complete message is a second target network node, and the second target network node controls the target cell for a second LTM cell switching procedure.

[0175] B6. The method according to Embodiment B6, further comprising receiving a second LTM cell switching completion message corresponding to a second LTM cell switching procedure, wherein the second LTM cell switching completion message includes a second instruction for the applied LTM candidate.

[0176] B7. The method according to any one of Embodiments B1 to B6, further comprising sending a signal to another network node indicating that the execution of the LTM cell switching procedure for the UE is complete.

[0177] B8. The method according to any one of Embodiments B1 to B7, further comprising receiving a signal from another network node that the execution of the LTM cell switching procedure for the UE has been completed.

[0178] B9. The method according to any one of embodiments B1 to B8, further comprising sending an LTM candidate cell setting to the UE before receiving the first LTM cell switchover completion message.

[0179] B10. The method according to embodiment B9, further comprising sending an LTM cell switch command to the UE before receiving the first LTM cell switch completion message.

[0180] B11. The applied LTM candidate instruction corresponds to the LTM candidate cell setting and / or LTM cell switching command, as described in exemplary embodiment B9 or B10.

[0181] B12. The method according to exemplary embodiment B9 or B10, wherein the applied LTM candidate instruction corresponds to another LTM candidate cell setting and / or another LTM cell switching command.

[0182] The method according to any one of embodiments B9 to B12, further comprising receiving a second LTM cell switching completion message from B13.UE, the second LTM cell including a second instruction for the applied LTM candidate.

[0183] B14. The method according to Embodiment 13, further comprising determining that the first and second LTM cell switchover completion messages correspond to the same LTM cell switchover procedure based on the instructions for the applied LTM candidate in the first and second LTM cell switchover completion messages.

[0184] B15. The method according to Embodiment 13, further comprising determining that the first and second LTM cell switchover completion messages correspond to different LTM cell switchover procedures based on the instructions for the applied LTM candidate in the first and second LTM cell switchover completion messages.

[0185] C1. User equipment (UE) adapted to support L1 / L2 triggered mobility (LTM) in a wireless network, A communication interface circuit configured to communicate with a wireless network via at least one serving cell, A processing circuit operably coupled to a communication interface circuit, wherein the processing circuit and the communication interface circuit are configured to perform an operation corresponding to the method described in any one of embodiments A1 to A7. User equipment (UE) equipped with these features.

[0186] C2. User equipment (UE) adapted to support L1 / L2 triggered mobility (LTM) in a wireless network, further adapted to perform operations corresponding to the method described in any one of embodiments A1 to A7.

[0187] C3. A non-temporary computer-readable medium that stores computer-executable instructions that, when executed by the processing circuit of a user device (UE), cause the UE to perform an operation corresponding to the method described in any one of embodiments A1 to A7.

[0188] C4. A computer program product comprising computer-executable instructions that, when executed by the processing circuit of a user device (UE), cause the UE to perform an operation corresponding to the method described in any one of embodiments A1 to A7.

[0189] D1. A network node adapted to support L1 / L2 triggered mobility (LTM) of user equipment (UE) in a wireless network, A communication interface circuit configured to communicate with the UE via at least one serving cell, A processing circuit operably coupled to a communication interface circuit, wherein the processing circuit and the communication interface circuit are configured to perform an operation corresponding to the method described in any one of embodiments B1 to B15. A network node equipped with the following features.

[0190] D2. A network node adapted to support L1 / L2 triggered mobility (LTM) of user equipment (UE) in a wireless network, further configured to perform operations corresponding to the method described in any one of embodiments B1 to B15.

[0191] D3. A non-temporary computer-readable medium for storing computer-executable instructions that, when executed by the processing circuit of a network node, configure a RAN node to perform operations corresponding to the method described in any one of embodiments B1 to B15.

[0192] D4. A computer program product comprising computer-executable instructions that, when executed by a network node's processing circuit, configure a RAN node to perform operations corresponding to the method described in any one of embodiments B1 to B15.

[0193] Below, an example of the present invention is shown, illustrating an exemplary implementation in the 3GPP RRC specification, TS38.331v17.4.0.

[0194] Example: Include instructions for setting up LTM candidate cells in the RRCReconfigurationComplete message. -------------------------------------Start example------------------------------------------------------- - RRCReconfigurationComplete The RRCReconfigurationComplete message is used to confirm the successful completion of the RRC connection reconfiguration. Signaling radio bearer: SRB1 or SRB3 RLC-SAP:AM Logical Channel: DCCH Direction: UE to network RRCReconfigurationComplete message -- ASN1START -- TAG-RRCRECONFIGURATIONCOMPLETE-START RRCReconfigurationComplete ::= SEQUENCE { rrc-TransactionIdentifier RRC-TransactionIdentifier, criticalExtensions CHOICE { rrcReconfigurationComplete RRCReconfigurationComplete-IEs, criticalExtensionsFuture SEQUENCE {} } } RRCReconfigurationComplete-IEs ::= SEQUENCE { lateNonCriticalExtension OCTET STRING OPTIONAL, nonCriticalExtension RRCReconfigurationComplete-v1530-IEs OPTIONAL } RRCReconfigurationComplete-v1530-IEs ::= SEQUENCE { uplinkTxDirectCurrentList UplinkTxDirectCurrentList OPTIONAL, nonCriticalExtension RRCReconfigurationComplete-v1560-IEs OPTIONAL } RRCReconfigurationComplete-v1560-IEs ::= SEQUENCE { scg-Response CHOICE { nr-SCG-Response OCTET STRING (CONTAINING RRCReconfigurationComplete), eutra-SCG-Response OCTET STRING } OPTIONAL, nonCriticalExtension RRCReconfigurationComplete-v1610-IEs OPTIONAL } RRCReconfigurationComplete-v1610-IEs ::= SEQUENCE { ue-MeasurementsAvailable-r16 UE-MeasurementsAvailable-r16 OPTIONAL, needForGapsInfoNR-r16 NeedForGapsInfoNR-r16 OPTIONAL, nonCriticalExtension RRCReconfigurationComplete-v1640-IEs OPTIONAL } RRCReconfigurationComplete-v1640-IEs ::= SEQUENCE { uplinkTxDirectCurrentTwoCarrierList-r16 UplinkTxDirectCurrentTwoCarrierList-r16 OPTIONAL, nonCriticalExtension RRCReconfigurationComplete-v1700-IEs OPTIONAL } RRCReconfigurationComplete-v1700-IEs ::= SEQUENCE { needForGapNCSG-InfoNR-r17 NeedForGapNCSG-InfoNR-r17 OPTIONAL, needForGapNCSG-InfoEUTRA-r17 NeedForGapNCSG-InfoEUTRA-r17 OPTIONAL, selectedCondRRCReconfig-r17 CondReconfigId-r16 OPTIONAL, nonCriticalExtension RRCReconfigurationComplete-v1720-IEs OPTIONAL } RRCReconfigurationComplete-v1720-IEs ::= SEQUENCE { uplinkTxDirectCurrentMoreCarrierList-r17 UplinkTxDirectCurrentMoreCarrierList-r17 OPTIONAL, nonCriticalExtension RRCReconfigurationComplete-v1800-IEs OPTIONAL } RRCReconfigurationComplete-v1800-IEs ::= SEQUENCE { isForLTM LTMCandidateConfigurationId OPTIONAL } -- TAG-RRCRECONFIGURATIONCOMPLETE-STOP -- ASN1STOP TIFF2026520848000004.tif254170TIFF2026520848000005.tif111170------------------------------------- End of example-------------------------------------------------------

[0195] The following shows an example of the present invention, specifically the implementation configuration in the 3GPP F1 AP specification, TS38.473v17.4.0. ------------------------------------- Start the example------------------------------------------------------- 8.3.4 UE Context Correction (gNB-CU Start) 8.3.4.1 General The purpose of the UE context modification procedure is to modify an established UE context, for example, by establishing, modifying, and releasing radio or sidelink resources. This procedure is also used to instruct the gNB-DU to stop transmitting data to the UE for mobility purposes (see TS38.401[4]). The procedure uses UE-related signaling. 8.3.4.2 Successful Operation Text omitted If the instructions for the applied LTM candidate IE are included in the UE context correction request message, the gNB-DU shall understand that the LTM cell switching was successful in the indicated candidate cell. Text omitted 9.2.2.7 UE Context Correction Request This message is sent by gNB-CU to provide gNB-DU with UE context information changes. Direction: gNB-CU→gNB-DU TIFF2026520848000006.tif212170-------------------------------------End example-------------------------------------------------------

[0196] List of Abbreviations TIFF2026520848000007.tif248170TIFF2026520848000008.tif240170TIFF20265208480 00009.tif248170TIFF2026520848000010.tif247170TIFF2026520848000011.tif193170

Claims

1. A method for user equipment (UE) for L1 / L2 triggered mobility (LTM) in a wireless network, Receiving LTM candidate cell settings from the aforementioned wireless network (910), Execute the first LTM cell switching procedure (930), (940) Send an LTM cell switching completion message to the wireless network, which includes instructions for the applied LTM candidate. A method that includes this.

2. The method according to claim 1, wherein the LTM cell switching completion message is an RRCReconfigurationComplete message.

3. The method according to claim 1 or 2, wherein the method includes receiving an LTM cell switching command (920), and the execution (930) of the first LTM cell switching procedure is in response to the receipt of the LTM cell switching command.

4. The above-mentioned instruction for the applied LTM candidate is, Cell instructions or identifiers, Instructions or identifiers for setting LTM candidate cells, Beam designation or identifier, Instructions or identifiers in the RRC message regarding LTM, The LTM cell switching completion message indicates that it pertains to the LTM. The method according to any one of claims 1 to 3, comprising any one of the above, or including the above.

5. The method according to any one of claims 1 to 3, wherein the instruction of the applied LTM candidate is or includes an instruction or identifier for setting an LTM candidate cell.

6. The method according to any one of claims 1 to 5, wherein the LTM cell switching completion message is transmitted to a first target network node, and the first target network node controls the target cell for the first LTM cell switching procedure.

7. The method according to any one of claims 1 to 5, further comprising executing a second LTM cell switching procedure following the first LTM cell switching procedure, wherein an LTM cell switching completion message is sent to a second target network node, which corresponds to the first LTM cell switching procedure, and the second target network node controls the target cell for the second LTM cell switching procedure.

8. The method according to claim 7, further comprising sending a second LTM cell switching completion message corresponding to the second LTM cell switching procedure, wherein the second LTM cell switching completion message includes a second instruction for the applied LTM candidate.

9. A method for supporting L1 / L2 triggered mobility (LTM) of user equipment (UE) within a wireless network, with respect to a network node within the wireless network, A method comprising receiving a first LTM cell switching completion message from a UE (1020), wherein the first LTM cell switching completion message includes an indication of an applicable LTM candidate.

10. The method according to claim 9, wherein the first LTM cell switching completion message is an RRCReconfigurationComplete message.

11. The above-mentioned instruction for the applied LTM candidate is, Cell instructions or identifiers, Instructions or identifiers for setting LTM candidate cells, Beam designation or identifier, Instructions or identifiers in the RRC message regarding LTM, The LTM cell switching completion message indicates that it pertains to the LTM. The method according to claim 9 or 10, comprising any one of the above.

12. The method according to claim 9 or 10, wherein the instruction of the applied LTM candidate is or includes an instruction or identifier for setting an LTM candidate cell.

13. The method according to any one of claims 9 to 12, wherein the network node that receives the LTM cell switching completion message is a first target network node, and the first target network node controls the target cell for the first LTM cell switching procedure.

14. The method according to any one of claims 9 to 12, wherein the first LTM cell switching completion message corresponds to a first LTM cell switching procedure performed by the UE to a target cell controlled by a first target network node, the network node receiving the first LTM cell switching completion message is a second target network node, and the second target network node controls the target cell for a second LTM cell switching procedure.

15. The method according to claim 14, further comprising receiving a second LTM cell switching completion message corresponding to the second LTM cell switching procedure, wherein the second LTM cell switching completion message includes a second instruction for the applied LTM candidate.

16. The method according to any one of claims 9 to 15, further comprising sending an instruction to another network node that the execution of the LTM cell switching procedure for the UE has been completed (1040).

17. The method according to any one of claims 9 to 16, further comprising receiving a signal from another network node that the execution of the LTM cell switching procedure for the UE has been completed.

18. The method according to any one of claims 9 to 17, further comprising sending an LTM candidate cell setting to the UE before receiving the first LTM cell switching completion message (1010).

19. The method of claim 18, further comprising receiving a second LTM cell switching completion message from the UE, wherein the second LTM cell includes a second instruction for the applied LTM candidate.

20. The method according to claim 19, further comprising determining that the first and second LTM cell switchover completion messages correspond to the same LTM cell switchover procedure based on the instructions for the applied LTM candidate in the first and second LTM cell switchover completion messages.

21. The method according to claim 19, further comprising determining that the first and second LTM cell switching completion messages correspond to different LTM cell switching procedures based on the instructions for the applied LTM candidates in the first and second LTM cell switching completion messages.

22. A user device (UE) (1200) configured to support L1 / L2 triggered mobility (LTM) in a wireless network, A communication interface circuit (1212) configured to communicate with the aforementioned wireless network, A processing circuit (1202) and a memory (1210) are operably coupled to the communication interface circuit. The processing circuit (1202), the memory (1210), and the communication interface circuit (1212) are provided, The LTM candidate cell settings are received from the aforementioned wireless network. Execute the first LTM cell switching procedure, User equipment (UE) (1200) is configured to send an LTM cell switching completion message to the wireless network, which includes instructions for the applied LTM candidate.

23. The UE(1200) according to claim 22, wherein the LTM cell switching completion message is an RRCReconfigurationComplete message.

24. The UE (1200) according to claim 22 or 23, wherein the processing circuit (1202), the memory (1210), and the communication interface circuit (1212) are further configured to receive an LTM cell switching command and to execute the first LTM cell switching procedure in response to the receipt of the LTM cell switching command.

25. The above-mentioned instruction for the applied LTM candidate is, Cell instructions or identifiers, Instructions or identifiers for setting LTM candidate cells, Beam designation or identifier, Instructions or identifiers in the RRC message regarding LTM, The LTM cell switching completion message indicates that it pertains to the LTM. A UE (1200) according to any one of claims 22 to 24, which is any one of or includes the following.

26. The UE(1200) according to any one of claims 22 to 24, wherein the instruction of the applied LTM candidate is an instruction or identifier for setting an LTM candidate cell, or includes such instruction.

27. The UE (1200) according to any one of claims 22 to 26, wherein the processing circuit (1202), the memory (1210), and the communication interface circuit (1212) are configured to send the LTM cell switching completion message to a first target network node, and the first target network node controls the target cell for the first LTM cell switching procedure.

28. The processing circuit (1202), the memory (1210), and the communication interface circuit (1212) are further configured to execute a second LTM cell switching procedure following the first LTM cell switching procedure, and to send the LTM cell switching complete message to a second target network node that controls the target cell for the second LTM cell switching procedure, wherein the LTM cell switching complete message corresponds to the first LTM cell switching procedure, according to the UE(1200) of any one of claims 22 to 26.

29. The UE(1200) according to claim 28, wherein the processing circuit (1202), the memory (1210), and the communication interface circuit (1212) are further configured to send a second LTM cell switching completion message corresponding to the second LTM cell switching procedure, the second LTM cell switching completion message includes a second instruction for the applied LTM candidate.

30. A network node (1300) configured to support L1 / L2 triggered mobility (LTM) of user equipment (UE) in a wireless network, A communication interface circuit (1306) configured to communicate with the UE via at least one serving cell, A processing circuit (1302) and a memory (1304) are operably coupled to the communication interface circuit. The processing circuit (1302), the memory (1304), and the communication interface circuit (1306) are provided, A network node (1300) is configured to receive a first LTM cell switching completion message from the UE, which includes instructions for the applicable LTM candidate.

31. The network node (1300) according to claim 30, wherein the first LTM cell switching completion message is an RRCReconfigurationComplete message.

32. The above-mentioned instruction for the applied LTM candidate is, Cell instructions or identifiers, Instructions or identifiers for setting LTM candidate cells, Beam designation or identifier, Instructions or identifiers in the RRC message regarding LTM, The LTM cell switching completion message indicates that it pertains to the LTM. A network node (1300) according to claim 30 or 31, which is any one of the above, or includes one of them.

33. The network node (1300) according to claim 30 or 31, wherein the instruction of the applied LTM candidate is or includes an instruction or identifier for setting an LTM candidate cell.

34. The network node that receives the LTM cell switching completion message is a first target network node, and the first target network node controls the target cell for the first LTM cell switching procedure, according to any one of claims 30 to 33 (1300).

35. The network node (1300) according to any one of claims 30 to 33, wherein the first LTM cell switching completion message corresponds to a first LTM cell switching procedure performed by the UE to a target cell controlled by a first target network node, the network node receiving the first LTM cell switching completion message is a second target network node, and the second target network node controls the target cell for a second LTM cell switching procedure.

36. The network node (1300) according to claim 35, wherein the processing circuit (1302), the memory (1304), and the communication interface circuit (1306) are further configured to receive a second LTM cell switching completion message corresponding to the second LTM cell switching procedure, the second LTM cell switching completion message includes a second instruction for the applied LTM candidate.

37. The network node (1300) according to any one of claims 30 to 36, wherein the processing circuit (1302), the memory (1304), and the communication interface circuit (1306) are further configured to send an instruction to another network node that the execution of the LTM cell switching procedure for the UE has been completed.

38. The network node (1300) according to any one of claims 30 to 37, wherein the processing circuit (1302), the memory (1304), and the communication interface circuit (1306) are further configured to receive an instruction from another network node that the execution of the LTM cell switching procedure for the UE has been completed.

39. The network node (1300) according to any one of claims 30 to 38, wherein the processing circuit (1302), the memory (1304), and the communication interface circuit (1306) are further configured to transmit an LTM candidate cell setting to the UE before receiving the first LTM cell switching completion message.

40. The network node (1300) according to claim 39, wherein the processing circuit (1302), the memory (1304), and the communication interface circuit (1306) are further configured to receive a second LTM cell switching completion message from the UE, and the second LTM cell includes a second instruction for the applied LTM candidate.

41. The network node (1300) according to claim 40, wherein the processing circuit (1302) and the memory (1304) are further configured to determine that the first and second LTM cell switching completion messages correspond to the same LTM cell switching procedure based on the instructions for the applied LTM candidates in the first and second LTM cell switching completion messages.

42. The network node (1300) according to claim 40, wherein the processing circuit (1302) and the memory (1304) are further configured to determine that the first and second LTM cell switching completion messages correspond to different LTM cell switching procedures based on the instructions for the applied LTM candidates in the first and second LTM cell switching completion messages.

43. User equipment (UE) (1200) adapted to support L1 / L2 triggered mobility (LTM) in a wireless network, The LTM candidate cell settings are received from the aforementioned wireless network. Execute the first LTM cell switching procedure, User equipment (UE) (1200) adapted to transmit an LTM cell switching completion message, including instructions for the applied LTM candidate, to the wireless network.

44. The UE (1200) according to claim 43, further adapted to perform an operation corresponding to the method described in any one of claims 2 to 8.

45. A computer program product comprising a computer executable instruction, which, when executed by the processing circuit of a user device (UE), causes the UE to perform an operation corresponding to the method described in any one of claims 1 to 8.

46. A computer-readable medium on which the computer program product described in claim 45 is stored.

47. A network node (1300) adapted to support L1 / L2 triggered mobility (LTM) of user equipment (UE) in a wireless network, A network node (1300) is adapted to receive a first LTM cell switching completion message from the UE, which includes instructions for the applicable LTM candidate.

48. A network node (1300) according to claim 48, further adapted to perform operations corresponding to the method described in any one of claims 10 to 21.

49. A computer program product comprising a computer executable instruction, which, when executed by a processing circuit of a network node, causes the network node to perform an operation corresponding to the method described in any one of claims 9 to 21.

50. A non-temporary computer-readable medium on which the computer program product described in claim 49 is stored.

Images