Method and apparatus for handling handover and lower layer triggered mobility in communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. A method performed by a first network node in a communication system is provided. The method includes receiving a user equipment (UE) context modification request message for mobility from a second network node; and transmitting a UE context modification failure message to the second network node in the case that the first network node cannot accept the UE context modification request message for mobility due to the L1 / L2 triggered mobility (LTM) command having been triggered to the UE.

Description

Technical Field

[0001] The present invention relates generally to wireless communication networking, and more particularly to methods and apparatus for handling handover and Lower Layer Triggered Mobility (LTM) in a communication system. Background Art

[0002] 5G mobile communications technology defines a wide frequency band, enabling high transmission rates and new services. This technology can be implemented not only in frequency bands "below 6 GHz," such as 3.5 GHz, but also in frequency bands "above 6 GHz," known as mmWave (millimeter waves), including 28 GHz and 39 GHz. Furthermore, consideration is being given to implementing 6G mobile communications technology in the terahertz band (e.g., the 95 GHz to 3 THz band) (referred to as "beyond 5G systems") in order to achieve transmission rates fifty times faster than 5G and ultra-low latency one-tenth that of 5G.

[0003] At the beginning of the development of 5G mobile communication technology, in order to support services and meet the performance requirements related to enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC) and massive machine type communication (mMTC), standardization has been underway on the following technologies: beamforming and massive multiple-input multiple-output (MIMO) for mitigating radio wave path loss and increasing radio wave transmission distance in mmWave, support for dynamic operation of parameter sets (e.g., operating multiple subcarrier spacings) and time slot formats for efficient utilization of mmWave resources, initial access technology supporting multi-beam transmission and broadband, definition and operation of BWP (bandwidth part), new channel coding methods (such as low-density parity-check (LDPC) codes for large-scale data transmission and polar codes for highly reliable transmission of control information), L2 preprocessing, and network slicing for providing dedicated networks dedicated to specific services.

[0004] Currently, discussions are underway on improvements and performance enhancements to initial 5G mobile communication technologies in view of the services they are to support, and there is already standardization of the physical layer regarding technologies such as vehicle-to-everything (V2E) for assisting driving determination of unmanned vehicles based on information about the position and status of a vehicle transmitted by the vehicle and for enhancing user convenience, NR-U (New Radio Unlicensed) designed to enable system operation in unlicensed bands to comply with various regulatory requirements, NR UE power saving, non-terrestrial network (NTN) for UE-satellite direct communication for providing coverage in areas where communication with terrestrial networks is unavailable, and positioning.

[0005] Furthermore, in the area of ​​radio interface architecture / protocols, standardization is underway on technologies such as the Industrial Internet of Things (IIoT) for supporting new services through interworking and integration with other industries, IAB (Integrated Access and Backhaul) for providing nodes for network service area expansion by integrating wireless backhaul links and access links, mobility enhancements including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access (NR two-step RACH) for simplifying the random access procedure. In terms of system architecture / services, standardization is also underway on the following: a 5G baseline architecture (e.g., a service-based architecture or service-based interface) for combining network function virtualization (NFV) and software-defined networking (SDN) technologies, and mobile edge computing (MEC) for receiving services based on UE location.

[0006] With the commercialization of 5G mobile communication systems, the already exponentially growing number of connected devices will be connected to the communication network, and it is therefore expected that enhanced functionality and performance of 5G mobile communication systems and the integrated operation of connected devices will become necessary. To this end, new research is planned related to: extended reality (XR) for effectively supporting AR (augmented reality), VR (virtual reality), MR (mixed reality), etc.; improving 5G performance and reducing 5G complexity by utilizing artificial intelligence (AI) and machine learning (ML); AI service support; metaverse service support; and drone communications.

[0007] Furthermore, such developments in 5G mobile communication systems will serve as the foundation for the development of not only new waveforms for providing terahertz band coverage for 6G mobile communication technology, multi-antenna transmission technologies (such as full-dimensional MIMO (FD-MIMO), array antennas, and massive antennas), metamaterial-based lenses and antennas for improving terahertz band signal coverage, high-dimensional spatial multiplexing technologies using OAM (orbital angular momentum), and RIS (reconfigurable smart surfaces), but also full-duplex technologies for increasing the frequency efficiency of 6G mobile communication technology and improving system networks, AI-based communication technologies for achieving system optimization by leveraging satellites and AI (artificial intelligence) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technologies for implementing services at a complexity level that exceeds the operational capabilities of UEs by utilizing ultra-high-performance communication and computing resources.

[0008] In wireless technologies such as fifth-generation (5G) New Radio (NR) technology, mobility of devices such as user equipment (UE) is achieved through a process called cell reselection in RRC_IDLE mode. Prior to NR Release 17, mobility was performed in RRC_CONNECTED mode using a process called handover. Network-controlled mobility applies to UEs in RRC_CONNECTED mode and requires explicit radio resource control (RRC) signaling triggered by the gNB in ​​NR. Handover in NR typically involves three steps: handover preparation, execution, and completion. The gNB can configure the UE to report measurements and perform the handover based on the reported measurements or its own understanding of the network topology. Alternatively, the gNB can configure the UE with execution conditions for triggering the handover. Once the conditions are met, the UE can move to the target cell and send an RRC reconfiguration complete message. 3GPP also introduced a new handover method called dual-active protocol stack (DAPS) handover in Release 16. However, these methods require the UE to send Layer 3 (RRC) messages, resulting in significant signaling overhead and latency. All of these can be categorized as L3 handover or L3 mobility.

[0009] 3GPP Release 18 is currently exploring Layer 1 / 2 Triggered Mobility (LTM), also known as Lower Layer Triggered Mobility, as a means of addressing issues related to latency, signaling overhead, and other concerns associated with Layer 3 mobility. LTM aims to facilitate serving cell changes via Layer 1 / 2 signaling, thereby reducing latency overhead and disruption time. To this end, a network (such as a gNB) can configure multiple candidate cells for a UE, allowing the configuration to be quickly applied. The network can also send a Media Access Control (MAC) Control Element (CE) or Layer 1 signaling to dynamically switch the UE from the source cell to one of the configured candidate cells. The MAC CE used to switch the UE may be referred to as a cell handover command. The term "cell handover command" may also be referred to as the term "LTM command" in this disclosure. A serving cell change via a cell handover command may be referred to as an LTM cell handover. Importantly, LTM can be triggered based on Layer 1 measurements rather than Layer 3 measurements. It is also possible for a UE to perform an LTM cell handover to an LTM candidate cell after a radio link failure without an explicit cell handover command (if configured to do so). The embodiments of the present invention are also applicable to any method of LTM cell handover.

[0010] 3GPP recommends performing LTM without resetting lower layers (such as MAC) to prevent data loss and minimize delays in data retrieval where feasible.

[0011] The gNB has the capability to provide LTMCandidateConfiguration. This requires configuring LTM candidate cells via a single RRC Reconfiguration message for the candidate target cell, or via a CellGroupConfig for each candidate target cell, or by means of any similar RRC structure or information element (IE) containing similar fields. An example of such an IE is the newly defined LTM-CandidateConfig, which is an ASN1 sequence that includes CellGroupConfig and other relevant information elements in RRCReconfiguration. Furthermore, the gNB is authorized to release or modify candidate configurations. Even after transitioning to a candidate cell via LTM, the UE can retain the LTM configuration for other candidate cells. Furthermore, the gNB can provide the UE with the necessary configuration for LTM measurements on various candidate frequencies and candidate cells, and further report based on the LTM measurements performed.

[0012] The above information is presented as background information only to assist the reader in understanding the present invention. Applicant has not made any determination and makes no assertion that any of the above content is applicable as prior art with respect to the present application. Summary of the Invention

[0013] Technical issues

[0014] The main purpose of the embodiments herein is to handle L3 handover and LTM handover in a telecommunication network.

[0015] Another object of the embodiments herein is to provide a gNB DU that prioritizes Layer 3 handover if a cell handover has been triggered.

[0016] Another object of embodiments herein is to provide a gNB DU that sends a F1AP UE Context Modification Failure and a Radio Network Cause value indicating activation of LTM upon receiving a F1AP UE Context Modification Request for triggering a synchronous reconfiguration if a cell handover has been triggered.

[0017] Another object of the embodiments herein is to provide a gNB DU that is capable of transmitting a failure to modify a UE context to a CU of a network device when the DU activates a cell handover command for the UE.

[0018] Another object of the embodiments herein is to provide a gNB DU that stops LTM-related operations of the DU for the UE when the DU does not trigger a cell handover command for the UE.

[0019] Another object of embodiments herein is to provide a UE capable of performing early handover triggered by Layer 3 (L3) handover (HO) and LTM.

[0020] Another object of the embodiments herein is to provide a UE that, in a case where both an L3 handover command and a cell switching command for LTM handover are received at the same time, prioritizes LTM handover over L3 handover.

[0021] Another object of embodiments herein is to provide a UE that performs LTM handover if an L3 handover instruction is received before a cell switching command.

[0022] Another object of embodiments herein is to provide a UE with the ability to perform an L3 handover upon receiving an L3 handover command, even if a cell switching command for performing an LTM handover has not been received.

[0023] Another object of the embodiments herein is to provide a UE with the ability to receive both a cell switching command and an L3 handover command within the same transport block when both commands are received simultaneously.

[0024] Solution to the problem

[0025] In an embodiment, a method performed by a first network node in a communication system is provided. The method includes: receiving a user equipment (UE) context modification request message for mobility from a second network node; and sending a UE context modification failure message to the second network node if the first network node cannot accept the UE context modification request message for mobility because a Layer 1 / L2 Triggered Mobility (LTM) command has been triggered to the UE.

[0026] In an embodiment, a method performed by a second network node in a communication system is provided. The method includes: sending a UE context modification request message for mobility to a first network node; receiving a UE context modification failure message from the first network node; and identifying, based on the UE context modification failure message, that the first network node cannot accept the UE context modification request message for mobility because an LTM command has been triggered to the UE.

[0027] In an embodiment, a first network node in a communication system is provided. The first network node includes a transceiver and a controller. The controller is configured to receive a UE context modification request message for mobility from a second network node via the transceiver, and to send a UE context modification failure message to the second network node via the transceiver if the first network node cannot accept the UE context modification request message for mobility (because an LTM command has been triggered to the UE).

[0028] In an embodiment, a second network node in a communication system is provided. The second network node includes a transceiver and a controller. The controller is configured to send a UE context modification request message for mobility to a first network node via the transceiver, receive a UE context modification failure message from the first network node via the transceiver, and identify, based on the UE context modification failure message, that the first network node cannot accept the UE context modification request message for mobility because an LTM command has been triggered to the UE.

[0029] In one aspect, these objects are achieved by providing a method for handling Layer 3 (L3) handover and LTM handover in a telecommunications network. The method includes receiving, by a DU of a network device, a UE context modification request for L3 handover of a UE from a CU of the network device. Furthermore, the method includes determining, by the DU of the network device, whether a cell handover command for the UE was triggered by the DU. In one embodiment, the method includes sending a UE context modification fault to the CU of the network device when the cell handover command for the UE was triggered by the DU. In another embodiment, the method includes stopping, by the DU, LTM-related operations for the UE when the cell handover command for the UE was not triggered by the DU.

[0030] In an embodiment, the UE CONTEXT MODIFICATION FAILURE is sent including a Radio Network Layer Cause Information Element (IE) in an F1AP UE CONTEXT MODIFICATION FAILURE message.

[0031] In an embodiment, a radio network layer cause information element (IE) indicates that lower layer mobility has been triggered.

[0032] In an embodiment, when the F1AP UE context modification includes the SpCellId IE, the DU identifies that the F1AP UE context modification is for L3 handover.

[0033] In an embodiment, the LTM-related operations include at least one of: triggering aperiodic downlink control information (DCI) when the source DU and the target DU are the same, processing LTM measurements, triggering LTM cell switching, and sending a random access response for LTM completion.

[0034] In one aspect, these objectives are achieved by providing a method for handling L3 handover and LTM handover in a telecommunications network. The method includes receiving, by a UE, an L3 handover command from a CU of a network device to perform the L3 handover. Furthermore, the method includes receiving, by the UE, a cell handover command from a DU of the network device to perform the LTM handover. Furthermore, the method includes determining, by the UE, whether the L3 handover command to perform the L3 handover and the cell handover command to perform the LTM handover are received at the same time or at different times. In an embodiment, the method includes prioritizing the LTM handover over the L3 handover when both the L3 handover command to perform the L3 handover and the cell handover command to perform the LTM handover are received simultaneously. In another embodiment, the method includes performing the LTM handover when the L3 handover command to perform the L3 handover is received before the cell handover command. In another embodiment, the method includes performing the L3 handover when the L3 handover command to perform the L3 handover is received before the cell handover command to perform the LTM handover.

[0035] In an embodiment, performing one of LTM handover and L3 handover when an L3 handover command for performing L3 handover and a cell switching command for performing LTM handover are received includes: determining, by the UE, whether the L3 handover command is received earlier than the cell switching command, and performing, by the UE, one of the following: when the L3 handover command is received earlier than the cell switching command, prioritizing the L3 handover command over the cell switching command, and when the L3 handover command is received later than the cell switching command, prioritizing the cell switching command over the L3 handover command.

[0036] In an embodiment, when the cell switching command and the L3 handover command are received simultaneously, the UE receives the cell switching command and the L3 handover command in the same transport block.

[0037] Advantageous Effects of the Invention

[0038] In one aspect, these objects are achieved by providing a DU of a network device for handling L3 handover and LTM handover in a telecommunications network. The DU includes a handover coexistence controller coupled to a memory and a processor. The handover coexistence controller is configured to receive a UE context modification request for L3 handover of a UE from a CU of the network device. In addition, the handover coexistence controller is configured to determine whether a cell handover command for the UE is triggered by the DU. In an embodiment, the handover coexistence controller is configured to send a UE context modification fault to the CU of the network device when the cell handover command for the UE is triggered by the DU. In another embodiment, the handover coexistence controller is configured so that LTM-related operations for the UE are stopped by the DU when the cell handover command for the UE is not triggered by the DU.

[0039] In one aspect, these objects are achieved by providing a UE for handling L3 handover and LTM handover in a telecommunications network. The UE includes a handover coexistence controller coupled to a memory and a processor. The handover coexistence controller is configured to receive an L3 handover command from a CU of a network device to perform an L3 handover. In addition, the handover coexistence controller is configured to receive a cell switching command from a DU of the network device to perform an LTM handover. The handover coexistence controller is configured to determine whether the L3 handover command to perform an L3 handover and the cell switching command to perform an LTM handover are received at the same time or at different times. In an embodiment, the handover coexistence controller is configured to prioritize LTM handover over L3 handover when both the L3 handover command to perform an L3 handover and the cell switching command to perform an LTM handover are received simultaneously. In another embodiment, the handover coexistence controller is configured to perform an LTM handover when the L3 handover command to perform an L3 handover is received before the cell switching command. In another embodiment, the handover coexistence controller is configured to perform L3 handover when receiving an L3 handover command to perform L3 handover before a cell switching command to perform LTM handover.

[0040] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and accompanying drawings. However, it should be understood that the following description, while indicating preferred embodiments and many of their specific details, is given by way of illustration and not limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the scope of the embodiments herein, and the embodiments herein include all such modifications. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] These and other features, aspects, and advantages of the present invention will be better understood when the following detailed description is read with reference to the accompanying drawings, in which like reference numerals represent like parts throughout the several views, and in which:

[0042] Figure 1 A block diagram showing the overall architecture of NG-RAN.

[0043] Figure 2 A sequence diagram showing intra-gNB-inter-DU mobility within NR.

[0044] Figure 3A A sequence diagram showing inter-gNB handover within the AMF / UPF.

[0045] Figure 3B A sequence diagram showing inter-gNB handover within the AMF / UPF.

[0046] Figure 4 A telecommunications network for handling L3 handover and LTM handover according to embodiments disclosed herein is shown.

[0047] Figure 5 Various hardware components of a UE according to embodiments disclosed herein are shown.

[0048] Figure 6 Various hardware components of a DU according to embodiments disclosed herein are shown.

[0049] Figure 7 A flow chart of a method implemented by a UE for handling L3 handover and LTM handover in a telecommunication network according to embodiments disclosed herein is shown.

[0050] Figure 8 A flow chart illustrating a method implemented by a DU for handling L3 handover and LTM handover in a telecommunications network according to embodiments disclosed herein is shown.

[0051] Figure 9 A flow chart of LTM processing at a DU according to embodiments disclosed herein is shown.

[0052] Figure 10 A flowchart of LTM and L3 HO processing at a CU according to embodiments disclosed herein is shown.

[0053] Figure 11 FIG. 4 is a flowchart illustrating a portion of L3 HO application candidate cell configuration according to an embodiment disclosed herein.

[0054] Figure 12 A first network node according to an embodiment of the present disclosure is shown.

[0055] Figure 13 A second network node according to an embodiment of the present disclosure is shown.

[0056] Furthermore, those skilled in the art will appreciate that the elements in the drawings are illustrated for simplicity and may not necessarily be drawn to scale. For example, a flow chart illustrates the method according to the most prominent steps involved to help improve understanding of the various aspects of the present invention. Furthermore, with respect to the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are relevant to understanding the embodiments of the present invention so as not to obscure the drawings with details that would be readily apparent to one of ordinary skill in the art having the benefit of the description herein. DETAILED DESCRIPTION

[0057] Various embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. In the following description, only specific details such as detailed configuration and components are provided to facilitate a comprehensive understanding of these embodiments of the present disclosure. Therefore, it will be apparent to those skilled in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope of the present disclosure. In addition, for the sake of clarity and conciseness, descriptions of well-known functions and structures have been omitted.

[0058] Furthermore, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments.

[0059] As used herein, the term "or" refers to a non-exclusive or unless otherwise indicated. The examples used herein are intended only to facilitate understanding of how the embodiments herein may be practiced and to further enable those skilled in the art to practice the embodiments herein. Therefore, the examples should not be construed as limiting the scope of the embodiments herein.

[0060] In this patent disclosure, the phrases "handover" and "conditional handover (CHO)" refer to Layer 3 mobility, including PSCellChange or conditional PSCellChange in the context of dual connectivity. Throughout the specification, the term "handover" is used generally to refer to L3 mobility.

[0061] In the context of this specification, it is important to note that the names “gNB” and “NR UE” are merely illustrative, and the embodiments discussed herein are equally applicable to technologies beyond 6G. In other words, gNB can refer to any type of network node, while UE can refer to any technology.

[0062] Embodiments disclosed herein provide a method for handling L3 handover and LTM handover in a telecommunications network. The method includes receiving, by a DU of a network device, a UE context modification request for L3 handover of a UE from a CU of the network device. Furthermore, the method includes determining, by the DU of the network device, whether a cell handover command for the UE is triggered by the DU. In one embodiment, the method includes sending a UE context modification fault to the CU of the network device when the cell handover command for the UE is triggered by the DU. In another embodiment, the method includes stopping, by the DU, LTM-related operations for the UE when the cell handover command for the UE is not triggered by the DU.

[0063] The proposed solution provides a method, network device, and UE for coexistence and interaction of handover and Lower Layer Triggered Mobility (LTM) in a telecommunications network. The proposed solution enables seamless coexistence and interaction between handover at the L3 mobility level and lower layer triggered mobility. In one embodiment, the UE is configured to perform measurements for both LTM (reported via CSI reports or MAC CEs) and L3 mobility (reported via measurement configuration). The UE only sends CSI reports and MAC CEs for LTM candidate cells configured for LTM and excludes L3 measurement results for LTM candidate cells from measurement reports sent to the network. In another embodiment, the UE is configured to perform LTM without lower layer resets, e.g., avoiding or partially performing MAC / RLC / PDCP resets. However, it performs lower layer resets, such as MAC resets, upon receiving RRC reconfiguration for handover or performing conditional handover. In an NRRRC reconfiguration involving RRCReconfigurationwithSync, the UE receives a handover.

[0064] This invention addresses the coordinated coexistence of long-term memory (LTM) and handover mechanisms, including: a) handling of cell handover triggers by the gNB DU when initiating a Layer 3 handover, b) management of Layer 3 handover cell handover triggers by the gNB DU when cell handover is activated, and c) UE-side implementation for efficiently managing the concurrency of LTM and L3 HO. The proposed solution facilitates gNB DU prioritization of Layer 3 handovers in the event of a triggered cell handover. Specifically, upon receiving an F1AP UE Context Modification Request for synchronized reconfiguration, if a cell handover has been triggered, the gNB DU sends an F1AP UE Context Modification Failure message with a Radio Network Cause value indicating that LTM has been triggered. Furthermore, the UE performs the earliest handover triggered by either L3 HO or LTM.

[0065] The proposed method can be used to synchronize different types of mobility, such as L3 handover and LTM. The proposed method brings deterministic behavior to mobility and reduces unnecessary signaling and implementation complexity. For example, if the DU has triggered an LTM cell handover and the CU is unaware of it, it can proceed with additional actions that incur signaling overhead on the network interface and on the air interface. These additional actions lead to increased implementation complexity because methods need to be defined to handle concurrency and possible non-deterministic behavior.

[0066] Referring now to the drawings, and more particularly to Figures 1 to 11 , where like reference numerals indicate corresponding features throughout the drawings, there is shown an example embodiment.

[0067] Figure 1 A block diagram showing the overall architecture of the Next Generation Radio Access Network (NG-RAN).

[0068] refer to Figure 1 , the NG-RAN (104) may include a set of gNBs (106a and 106b) connected to the 5GC (102) via an NG interface in the telecommunications network (1000). The gNBs (106a and 106b) may be interconnected via an Xn interface. The gNBs (106a and 106b) may include a gNodeB centralized unit (gNB-CU) (108) and one or more gNodeB distributed units (gNB-DU) (110a and 110b). The gNB (106a and 106b)-CU and the gNB-DU (110a and 110b) are connected via an F1 interface. The F1 Application Protocol (F1AP) is a protocol for signaling via the F1 interface. The F1AP provides signaling services required to implement F1AP functionality between the gNB-DU and the gNB-CU. The signaling services provided by the F1AP may include the following:

[0069] Non-UE associated services: They are associated with the entire F1 interface instance between the gNB-DU and gNB-CU using a non-UE associated signaling connection.

[0070] UE-associated services: These are associated with a single UE. The F1AP functions that provide these services are associated with the UE-associated signaling connection maintained for the UE in question. UE-associated signaling is used to set up the UE context (using the UE Context Setup Request message from the CU to the DU), modify the UE context (the UE Context Modify Request message from the CU to the DU), and release the UE context (the UE Context Release Command message from the CU to the DU), among other functions.

[0071] The F1AP UE context modification request may include different fields, such as SpCell ID, a list of radio bearers to be established (e.g., a list of signaling radio bearers (SRBs) or a list of data radio bearers (DRBs) to be established or released or modified), configuration for low layer triggered mobility (LTM), etc. The F1AP UE context modification request may also include an RRC container, which includes a downlink dedicated control channel (DL-DCCH message) encapsulated in a packet data convergence unit (PDCP) protocol data unit (PDU).

[0072] Measurement configuration : NR R17 UE (202) may be configured with a MeasConfig IE for performing layer 3 measurements. MeasConfig may include the information elements shown in Table 1 below.

[0073] [Table 1]

[0074]

[0075] Figure 2 A sequence diagram showing intra-gNB-inter-DU mobility within NR.

[0076] The Intra-gNB Inter-DU Mobility procedure is used when a UE (202) moves from one gNB-DU to another gNB-DU within the same gNB-CU (108) during NR operation. Figure 2 The inter-gNB-DU mobility procedure within NR is shown.

[0077] At step 201a, the UE (202) receives downlink user data from the gNB-CU (108) via the source gNB-DU (204a). At step 201b, the UE (202) sends uplink user data to the gNB-CU (108) via the source gNB-DU (204a). At step 201c, the UE (202) sends a MeasurementReport message to the source gNB-DU (204a).

[0078] At step 202a, the source gNB-DU (204a) sends an UL RRC Messaging message to the gNB-CU (108) to convey the received MeasurementReport message. At step 202b, the gNB-CU (108) may send a UE Context Modification Request message to the source gNB-DU (204a) to query for the latest configuration. At step 202c, the source gNB-DU (204a) responds with a UE Context Modification Response message including complete configuration information.

[0079] In step 203, the gNB-CU (108) sends a UE Context Setup Request message to the target gNB-DU (204b) to create a UE context and set it up with one or more data bearers. The UE Context Setup Request message includes HandoverPreparationInformation. In the case of NG-RAN sharing, the gNB-CU (108) includes the serving public land mobile network (PLMN) identifier (for a standalone non-public network (SNPN), the serving SNPN ID).

[0080] At step 204, the target gNB-DU (204a) responds to the gNB-CU (108) with a UE CONTEXT SETUP RESPONSE message. At step 205, the gNB-CU (108) sends a UE CONTEXT MODIFY REQUEST message to the source gNB-DU (204a), which includes the generated RRCReconfiguration message and instructs to stop data transmission of the UE (202). The source gNB-DU (204a) also sends a DOWNLINK DATA DELIVERY STATUS frame to notify the gNB-CU (108) of the downlink data that was not successfully transmitted to the UE (202).

[0081] In the case of a dual active protocol stack (DAPS) handover, the UE context modification request message in step 205 may indicate the cessation of data transmission for a specific data radio bearer (DRB) that is not subject to DAPS handover, or forgo any instructions to stop data transmission altogether. Instead, a downlink (DL) RRC messaging procedure may be employed to convey the handover command to the UE (202). After the gNB-CU (108) has confirmed that the UE (202) has successfully connected to the target gNB-DU (204b), a UE context modification request message signaling the cessation of data transmission for the UE (202) is dispatched to the source gNB-DU (204a). Upon receipt, the source gNB-DU (204a) sends a Dynamic Delegated Discovery System (DDDS) frame to the gNB-CU (108) regarding the downlink data that failed to be sent.

[0082] At step 206a, the source gNB-DU (204a) forwards the received RRCReconfiguration message to the UE (202). At step 206b, the source gNB-DU (204a) sends a Downlink Data Delivery Status message to the gNB-CU (108). At step 207, the source gNB-DU (204a) responds to the gNB-CU (108) with a UE Context Modification Response message.

[0083] At step 208a, a random access procedure is performed at the target gNB-DU (204b). At step 208b, the target gNB-DU (204b) transmits a downlink data delivery status frame to notify the gNB-CU (108). Downlink packets, which may include Packet Data Convergence Protocol (PDCP) PDUs that were not successfully transmitted in the source gNB-DU (204a), are transmitted from the gNB-CU (108) to the target gNB-DU (204b). Note that it is up to the gNB-CU to start transmitting DL user data to the gNB-DU (110) before or after receiving the downlink data delivery status.

[0084] At step 209a, the UE (202) responds to the target gNB-DU (204b) with an RRCReconfigurationComplete message. At step 209b, the target gNB-DU (204b) receives downlink user data from the gNB-CU (108). At step 210a, the target gNB-DU (204b) sends an UL RRC Messaging Transfer message to the gNB-CU (108) to convey the received RRCReconfigurationComplete message. At step 210b, downlink packets are sent to the UE (202). At step 210c, likewise, uplink packets are sent from the UE (202) and forwarded to the gNB-CU (108) via the target gNB-DU (204b).

[0085] In step 211, the gNB-CU (108) sends a UE CONTEXT RELEASE COMMAND message to the source gNB-DU (204a). In step 212, the source gNB-DU (204a) releases the UE context and responds to the gNB-CU (108) with a UE CONTEXT RELEASE COMPLETE message.

[0086] Figure 3A and 3B A sequence diagram showing inter-gNB handover within the AMF / UPF.

[0087] refer to Figure 3A and 3B Intra-NR RAN handover performs the preparation and execution phases of the handover procedure without involving the 5GC (102), i.e., preparation messages are exchanged directly between the gNBs (106a and 106b). The release of resources at the source gNB (204a) during the handover completion phase is triggered by the target gNB (204b). Figure 3A and Figure 3B A basic handover scenario is depicted, where both the Access and Mobility Management Function (AMF) and the User Plane Function (UPF) remain unchanged:

[0088] At step 301a, user data is provided between the UE (202) and the source gNB (204a). At step 301b, user data is provided between the UPF entity (304) and the source gNB (306). At step 301c, mobility control information is provided by the AMF entity (302). The UE context within the source gNB (306a) contains information about roaming and access restrictions, which is provided at connection establishment or at the last Tracking Area (TA) update. At step 301d, the source gNB (306a) configures the UE measurement procedures and UE reporting according to the measurement configuration.

[0089] In step 302, the source gNB (306a) decides to initiate a handover of the UE based on information collected from measurement reports and radio resource management (RRM). In step 303, the source gNB (306a) sends a handover request message to the target gNB (306b), which contains a transparent RRC container that includes all necessary information required to prepare the handover on the target side. This information includes, but is not limited to, the target cell identifier (ID) KgNB*, the cell radio network temporary identifier (C-RNTI) of the UE (202) in the source gNB (306a), RRM configuration, basic AS configuration, antenna information, downlink (DL) carrier frequency, the current quality of service (QoS) flow to DRB mapping rule applied to the UE (202), SIB1 from the source gNB (306a), UE capabilities of different radio access technologies (RATs), protocol data unit (PDU) session related information, and measurement information reported by the UE, including beam related information (if available). The PDU session related information also includes slice information and QoS flow level QoS profile. Additionally, the source gNB (306a) may request a DAPS handover for one or more DRBs. It is important to note that after issuing the handover request, the source gNB (306a) may avoid reconfiguring the UE (202), including performing reflective QoS flow to DRB mapping.

[0090] At step 304, the target gNB (306b) may perform admission control. If slice information has been sent to the target gNB (306b), this process involves slice-aware admission control. If any PDU session is associated with an unsupported slice, the target gNB (306b) rejects such PDU session. Continuing at step 305, the target gNB (306b) prepares for handover with L1 / L2 and sends an acknowledgment of the handover request to the source gNB (306a). The acknowledgment includes a transparent container, which will be sent to the UE (202) as an RRC message to perform the handover. Additionally, the target gNB (306b) indicates whether the DAPS handover has been accepted.

[0091] When the source gNB (306a) receives the Handover Request Acknowledgement, or initiates the Handover Command transmission in the downlink, data forwarding can begin. For DRBs equipped with DAPS, downlink PDCP SDUs are forwarded with the SN assigned by the source gNB (306a) until the SN assignment is communicated to the target gNB (306b) in step 308b, at which point normal data forwarding resumes.

[0092] In step 306a, the source gNB (306a) initiates a Uu handover by sending an RRCReconfiguration message to the UE (202). This message includes important information for accessing the target cell, such as the target cell ID, the new C-RNTI, the target gNB (306b), and the security algorithm identifier for the selected security algorithm. Additionally, it may include a set of dedicated random access channel (RACH) resources, the association between RACH resources and SSB(s), the association between RACH resources and UE-specific CSI-RS configuration(s), common RACH resources, and system information of the target cell, among other details.

[0093] In a DRB equipped with DAPS, the source gNB (306a) continues to send downlink packets until it receives a handover success message from the target gNB (306b) in step 308a. It is not possible to configure CHO at the same time as a DAPS handover.

[0094] In step 306b, the source gNB (306a) is given the task of transferring the buffered data and the new data from the UPF entity (304). In addition, in phase 6c, the UE (202) leaves the previous cell and coordinates with the new cell.

[0095] At step 307a, the source gNB (306a) sends an Early Status Transfer message for a DRB configured with DAPS. The communicated DL COUNT value indicates the PDCP SN and hyperframe number (HFN) of the first PDCP SDU forwarded to the target gNB (306b). Furthermore, the source gNB (306a) continues assigning SNs to downlink PDCP SDUs until an SN Status Transfer message is sent to the target gNB (306b) during step 308b.

[0096] At step 307b, if the DRB is not configured with DAPS, the source gNB (306a) sends an SN status transfer message to the target gNB (306b). The message conveys the uplink PDCP SN receiver status and downlink PDCP SN transmitter status of the DRB for which the PDCP status retention applies (i.e., for RLC AM). The uplink PDCP SN receiver status includes at least the PDCP SN of the first lost UL PDCP SDU. In addition, it may include a bitmap of the reception status of out-of-sequence UL PDCP SDUs that the UE (202) needs to retransmit in the target cell (if any). The downlink PDCP SN transmitter status indicates the next PDCP SN that the target gNB (306b) assigns to new PDCP SDUs that do not yet have a PDCP SN.

[0097] In step 307c, the UPF entity (304) sends the user data to the source gNB (306a). In step 307d, the source gNB (306a) sends the user data to the target gNB (306b). In step 307e, the target gNB (306b) receives the buffered user data from the source gNB (306a).

[0098] In case of DAPS handover, the transfer of uplink PDCP SN receiver status and downlink PDCP SN transmitter status for DRBs not configured with DAPS and using RLC-AM may occur through SN status transfer messages during step 308b instead of step 307a.

[0099] For DRBs configured with DAPS, the source gNB (306a) may additionally send an Early State Transfer message between steps 307a and 308b to notify the discard of the already forwarded PDCP SDUs. The target gNB (306b) does not send the forwarded downlink PDCP SDUs whose COUNT is less than the communicated DL COUNT value to the UE (202) and discards them if no transmission has been attempted.

[0100] At step 308a, the UE (202) synchronizes with the target cell by sending an RRCReconfigurationComplete message to the target gNB (306b), successfully concluding the RRC handover procedure. In the case of a DAPS handover, the UE (202) avoids detaching from the source cell upon receiving the RRCReconfiguration message. Instead, it releases the source resources and configuration only after receiving an explicit release from the target node, and stops DL / UL transmission and reception with the source.

[0101] From the RAN perspective, completion of a DAPS handover depends on the UE (202) releasing the source cell upon explicit request from the target node. Failure to do so will cause the RRC to suspend any subsequent handover or inter-RAT handover until the source cell has been released.

[0102] During the DAPS handover procedure, in steps 308b and 308c, the target gNB (306b) sends a handover success message to the source gNB (306a) to indicate that the UE (202) has successfully connected to the target cell. In response, the source gNB (306a) dispatches an SN Status Transfer message for the DRB configured with DAPS, as described in step 307, and follows the data forwarding procedure.

[0103] In step 308b, if DAPS is configured, the SN Status Transfer message also communicates the status of the uplink PDCP SN receiver and downlink PDCP SN transmitter for DRBs utilizing RLC-UM.

[0104] In a DRB configured with DAPS, the source gNB (306a) continues to deliver uplink QoS flows to the UPF entity (304) until it sends an SN Status Transfer message in step 308b. Similarly, the target gNB (306b) refrains from forwarding QoS flows of successfully received in-sequence uplink PDCP SDUs to the UPF entity (304) until it receives an SN Status Transfer message. This message contains the UL High Frequency Number (HFN) and the first missing SN in the uplink PDCP SN receiver status, which indicates the start of uplink PDCP SDUs to be delivered to the UPF. Furthermore, the target gNB (306b) does not deliver any uplink PDCP SDUs whose UL COUNT is lower than the provided value.

[0105] In step 309a, user data is exchanged between the UPF entity (304) and the source gNB (306b). Continuing to step 309b, user data is transferred between the target gNB (306b) and the source gNB (306a). In step 309c, user data is sent between the UE (202) and the target gNB (306b). In step 309d, user data is shared between the UPF entity (304) and the target gNB (306b). Furthermore, in step 309e, the target gNB (306b) initiates a path switch request message to the AMF entity (302) to prompt the 5GC (102) to shift the DL data path towards the target gNB (306b) and also establish an NG-C interface instance towards it.

[0106] During steps 310a to 310c, the 5GC (102) skillfully redirects the DL data path to the desired gNB (306b). Furthermore, for each PDU session / tunnel, the UPF entity (304) sends one or more "end marker" packets to the source gNB (306a) on the previous path in a timely manner. After this, it may relinquish any U-Plane / TNL resources (306a) towards the source gNB.

[0107] In step 311, the AMF entity (302) acknowledges the Path Switch Request message by responding with a Path Switch Request Confirm message. In step 312, upon receiving the Path Switch Request Confirm message from the AMF entity (302), the target gNB (306b) sends a UE Context Release signal to notify the source gNB (306a) of the successful handover. Furthermore, the source gNB (306a) may release the radio and C-plane related resources linked to the UE context. Any ongoing data forwarding may continue uninterrupted.

[0108] The RRM configuration may contain a combination of beam measurement data (related to Layer 3 mobility) associated with the SSB(s) and CSI-RS(s) of the associated cell(s), provided both forms of measurement are available. Additionally, if carrier aggregation (CA) has been implemented, the RRM configuration may include a list of the best cells on each frequency for which measurement data is accessible. The RRM measurement data may also contain beam measurements for cells listed under the target gNB (306b).

[0109] The standard RACH configuration for the beam in the desired cell is exclusively linked to the SSB(s). However, the network equipment may have a custom RACH configuration linked to the SSB(s) or CSI-RS(s) within the cell. When issuing a handover command to facilitate UE access to the target cell, the target gNB (306b) may select one of the available RACH configurations.

[0110] Public RACH configuration;

[0111] Common RACH configuration + dedicated RACH configuration associated with SSB; and

[0112] Common RACH configuration + dedicated RACH configuration associated with CSI-RS.

[0113] The allocated RACH configuration assigns a quality threshold to the RACH resource(s) for optimal utilization. When dedicated RACH resources are provided, the UE (202) prioritizes them and avoids switching to contention-based RACH resources as long as the quality threshold of the dedicated resources is maintained. The sequence used to access the dedicated RACH resources depends on the UE implementation.

[0114] Upon receiving a handover command requesting a DAPS handover, the UE (202) suspends the signaling radio bearer (SRB) of the source cell, stops sending and receiving any RRC control plane signaling to the source cell, and establishes an SRB for the target cell. Upon successful DAPS handover, the UE (202) releases the source cell SRB configuration upon receiving a source cell release indication from the target cell. In the event of a DAPS handover failure to the target cell, and if the source cell link is available, the UE (202) reverts to the source cell configuration and resumes the source cell SRB for control plane signaling transmission.

[0115] Figure 4 A telecommunications network (1000) for handling L3 handover and LTM handover according to embodiments disclosed herein is shown. The telecommunications network (1000) may include a range of technologies, including but not limited to fourth generation (4G), fifth generation (5G), or even sixth generation (6G) networks. In addition, it may also include an open radio access network (ORAN) or similar innovations.

[0116] In an embodiment, a telecommunications network (1000) includes a UE (202) and a network device (400). In an embodiment, the network may be a base station or a gNB. In an embodiment, the network device (400) includes a DU (410) and a CU (420). In another embodiment, the DU (410) and the CU (420) are located separately from each other. The UE (202) may be, for example, but not limited to, a laptop, a smartphone, a desktop computer, a notebook, a device-to-device (D2D) device, a vehicle-to-everything (V2X) device, a foldable phone, a smart TV, a tablet, an immersive device, and an Internet of Things (IoT) device.

[0117] The network device (400) sends a UE context modification request to the DU (410) for L3 handover of the UE (202). The DU (410) then evaluates whether a cell handover command for the UE (202) has been triggered. If the DU (410) determines that the cell handover command has been triggered, the DU (410) sends a UE context modification failure to the CU (420) of the network device (400), the UE context modification failure including a radio network layer cause IE in the F1AP UE context. The radio network layer cause IE indicates that lower layer mobility has been triggered. When the F1AP UE context modification includes the SpCellId IE, the DU (410) identifies that the F1AP UE context modification is for L3 handover.

[0118] Furthermore, if the DU 410 determines that a cell handover command has not been triggered, the DU (410) stops LTM-related operations for the UE (202). The operations may include, for example, triggering aperiodic DCI processing for LTM measurements, triggering LTM cell handover when the source DU and target DU are the same, and sending a random access response for LTM completion.

[0119] The embodiments presented herein depend on the capabilities of the UE reported to the network apparatus (400). Some UEs (202) may not have the necessary capabilities. To configure LTM, the following example sequence of Table 2 may be used.

[0120] [Table 2]

[0121]

[0122] The UE (202) receives the LTM configuration from the gNB (106a and 106b) via an RRC message. In addition, the gNB CU (108) may send the LTM configuration to the gNB DU (204), the LTM configuration including the LTM measurement configuration. The LTM measurement configuration sent from the gNB CU (108) to the gNB DU (110) includes the L1 measurement configuration for LTM, the measurement objects for LTM measurement (such as the frequency and cell to be measured), the measurement identifier, the measurement gap configuration, the reporting configuration (including the measurement filter, threshold and offset), and other related parameters.

[0123] Measurement reporting when both L1 and L3 measurements for LTM are configured:

[0124] In an embodiment, a UE (202) configured for measurement of both LTM (via CSI reporting or MAC CE reporting) and L3 mobility via measurement configuration only reports CSI reports and MAC CEs for LTM of candidate cells configured for LTM, and skips including L3 measurement results of the LTM candidate cells in a measurement report sent to a network device (400).

[0125] In an embodiment, the UE (202) receives an indication to skip reporting of layer 3 measurements. (e.g., a flag skipL3Meas). If the field (i.e., the above indication) is present or if the field is present and indicates skipping L3 measurements, the UE (202) skips reporting layer 3 measurements. In an embodiment, the network device (400) provides a flag skipL3meas for each candidate cell, and the UE (202) does not report layer 3 measurements to the network device (400) (i.e., does not include measurements of those candidate cells in the measurement report). In an embodiment, the network device (400) provides a list of candidate cells for which the UE (202) can skip L3 measurement reporting and the UE (202) does not report layer 3 measurements to the network device (400) (i.e., does not include measurements of those candidate cells in the measurement report).

[0126] In an embodiment, a UE (202) is configured to perform measurements for LTM via CSI reports or MAC CEs, and to perform measurements for L3 mobility via measurement configurations. Specifically, the UE (202) avoids reporting CSI reports and MAC CEs for LTM candidate cells designated for LTM, and instead incorporates L3 measurement results for the LTM candidate cells into the measurement report.

[0127] In an embodiment, a UE (202) is configured to measure both LTM (via CSI reporting or MAC CE reporting) and L3 mobility through a measurement configuration. The UE (202) reports both CSI reports of candidate cells configured for LTM and MAC CE for LTM, and skips including L3 measurement results of LTM candidate cells in the measurement.

[0128] Interaction between handover and LTM:

[0129] Assume that a source DU (204a) associated with a UE (202) has been configured with LTM candidate cells and is performing LTM measurements. The UE (202) is configured to report or report LTM measurements (such as periodic CSI reporting of LTM candidate cells, aperiodic CSI reporting of LTM candidate cells, event-triggered CSI reporting of LTM, event-triggered MAC CE reporting of LTM).

[0130] In an embodiment, when performing L3 handover, the gNB CU (108) instructs the source gNB DU (204a) to stop performing LTM.

[0131] In an embodiment of the L3 mobility procedure, the gNB CU (108) requests the source gNB DU (204a) to stop one or more LTM-related actions that the DU (410) then follows. In an embodiment, the source DU stops sending cell handover commands to stop LTM actions, while in another embodiment, the source DU stops sending triggers, such as DCI triggers for aperiodic CSI reporting, and avoids processing LTM measurements (202) received from the UE. Additionally, when the source cell and target cell are on the same DU, the source DU may also skip sending a random access response for LTM completion, among other actions.

[0132] In an embodiment, during the L3 mobility procedure, the gNB CU (108) may request the source gNB DU (204a) to stop one or more LTM related actions. This may be achieved by incorporating an information element (IE) in the F1AP UE Context Modification procedure.

[0133] In an embodiment, during the L3 mobility procedure, the gNB CU (108) makes a request to the source gNB DU (204a) to stop one or more LTM related actions by incorporating an IE in the F1AP UE Context Modification procedure, such as Figure 2 As shown, it is sent during step 202a.

[0134] In an embodiment, the gNB-CU (108) sends an F1AP UE Context Modification Request message to the source gNB (106a and 106b)-DU, requesting the latest configuration, such as Figure 2 In addition, the gNB-CU (108) provides an instruction to the gNB DU (110) to stop one or more LTM actions within the same UE Context Modification Request message.

[0135] In a different configuration, the gNB-CU (108) dispatches a message to modify the F1AP UE context to the source gNB-DU (204a). The message includes the generated RRCReconfiguration message and prompts the UE (202) to stop data transmission, such as Figure 2 In addition, within the same UE Context Modification Request message, the gNB-CU (108) issues an instruction to the gNB-DU (110) to interrupt one or more LTM actions.

[0136] In an embodiment, the gNB CU (108) incorporates an IE into the F1AP UE Context Modification Request to stop one or more LTM actions. The IE is an enumeration IE, specifically the enumerated CellSwitchStop indicator {true}. Upon receiving the F1AP UE Context Modification Request with the above enumeration set to true, the gNB DU (110) stops performing one or more LTM actions. These actions may include sending a cell handover command, triggering aperiodic CSI reporting, processing received LTM measurement reports (such as CSI reports for LTM or UL MAC CEs for LTM measurements), or avoiding sending a random access response for LTM completion when the source cell and target cell are on the same DU. Alternatively, in another embodiment, the request to stop one or more LTM actions is conveyed through the existing F1AP IE "Transmission Stop Indicator".

[0137] In an embodiment, during the L3 mobility procedure, the source DU stops one or more actions of LTM. In an embodiment, the LTM action stopping is performed by the source DU stopping sending cell handover commands. In an embodiment, the LTM action stopping is performed by the source DU stopping sending triggers (such as DCI triggers for aperiodic CSI reporting), not processing any received LTM measurements from the UE (202), stopping / skipping sending random access responses for LTM completion when the source cell and the target cell are on the same DU, etc. In an embodiment, the source DU stops LTM actions if it receives an F1AP UE Context Modification Request including an SpCell ID IE.

[0138] In an embodiment of the L3 mobility procedure, the gNB CU (108) issues an instruction to the source gNB DU (110) to stop one or more LTM actions for one or more candidate cells. The gNB CU (108) maintains a list of SpCell IDs for which the gNB DU (110) suspends LTM actions. The source DU may stop LTM actions (202) by interrupting the transmission of a cell handover command or trigger (e.g., a DCI trigger for aperiodic CSI reporting) and by refraining from processing any received LTM measurements from the UE. In addition, when the source cell and the target cell are on the same DU, the source DU may skip or stop sending a random access response for LTM completion. If the source DU receives an F1AP UE Context Modification Request including an SpCell ID IE, the DU stops LTM actions.

[0139] In an embodiment, upon completion of the L3 mobility procedure, the gNB DU (110) resumes LTM action if the cell to which the UE (202) has successfully handed over includes LTM configuration for one or more candidate cells in the DU (410).

[0140] In an embodiment, if the source DU receives a F1AP UE Context Modification Request including the SpCell ID IE while it has already triggered a cell handover command, the source DU sends a F1AP UE Context Modification Failure. In an embodiment, the source DU notifies the CU that the failure is due to lower layer mobility. In an embodiment, the source DU notifies the CU that the failure is due to lower layer mobility having been triggered. In an embodiment, the source DU notifies the CU that the failure is due to lower layer mobility being in progress. In an embodiment, the source DU notifies the CU of the failure by setting a Cause IE (Radio Network Layer Cause IE) in the F1AP UE Context Modification Failure message, as in the above-described embodiment.

[0141] In an embodiment, if the source DU receives an F1AP UE Context Modification Request (ReconfigurationWithSync) for handover while it has already triggered a cell handover command, the source DU sends an F1AP UE Context Modification Failure. In an embodiment, the source DU notifies the CU that the failure is due to lower layer mobility. In an embodiment, the source DU notifies the CU that the failure is due to lower layer mobility having been triggered. In an embodiment, the source DU notifies the CU that the failure is due to lower layer mobility being in progress. In an embodiment, the source DU notifies the CU of the failure by setting a Cause IE (Radio Network Layer Cause IE) in the F1AP UE Context Modification Failure message, as in the above-described embodiment.

[0142] In an embodiment, if the source DU is Figure 2 If the source DU receives an F1AP UE Context Modification Request for handover / mobility as in step 205 and has already triggered a Cell Handover Command, it sends an F1AP UE Context Modification Failure. In an embodiment, the source DU notifies the CU that the failure is due to underlying mobility. In an embodiment, the source DU notifies the CU that the failure is due to underlying mobility having been triggered. In an embodiment, the source DU notifies the CU that the failure is due to underlying mobility being in progress. In an embodiment, the source DU notifies the CU of the failure by setting a Cause IE (Radio Network Layer Cause IE) in the F1AP UE Context Modification Failure message as in the above embodiment. In an embodiment, the source DU sends a Cell Handover Command / LTM Command to the UE using a MAC CE.

[0143] In an embodiment, if the source DU receives an F1AP UE Context Modification Request for handover / mobility, as in step 202a, while it has already triggered a cell handover command, it sends an F1AP UE Context Modification Failure. In an embodiment, the source DU notifies the CU that the failure is due to lower layer mobility. In an embodiment, the source DU notifies the CU that the failure is due to lower layer mobility having already been triggered. In an embodiment, the source DU notifies the CU that the failure is due to lower layer mobility being in progress. In an embodiment, the source DU notifies the CU of the failure by setting a Cause IE (Radio Network Layer Cause IE) in the F1AP UE Context Modification Failure message, as in the above-described embodiments. In an embodiment, the source DU sends a Cell Handover Command / LTM Command to the UE using a MAC CE.

[0144] In an embodiment, the gNB CU (108) and the DU independently perform L3 mobility and LTM. The gNB CU (108) sends an RRC reconfiguration including an RRCReconfiguration with synchronization to initiate an L3 handover regardless of a cell handover triggered from the DU. The gNB DU (110) sends a cell handover command regardless of whether L3 mobility is triggered.

[0145] In an embodiment, upon LTM completion (receiving an indication of LTM completion from a target DU after the UE (202) has accessed the target cell, or receiving an RRC completion, such as an RRC reconfiguration complete), the CU cancels the ongoing L3 handover procedure. In an embodiment, this is particularly applicable when the CU receives information about successful LTM completion from the DU (410) or the UE (202) after the UE performs an LTM cell handover to an LTM candidate cell without an explicit cell handover command after a radio link failure. When there is an explicit cell handover command, the CU may cancel the L3 inter-gNB handover procedure before the completion indication, such as receiving a notification about LTM initiation from the source DU.

[0146] In an embodiment, upon receiving an indication of LTM completion from a target DU or UE (202) (receiving an indication of LTM completion from a DU after the UE (202) has accessed a target cell, or receiving an RRC completion, such as an RRC reconfiguration completion, from the UE), the CU cancels the ongoing L3 handover procedure. In an embodiment, this is particularly applicable when the CU receives information about successful LTM completion from a DU (410) or UE (202) after the UE performs an LTM cell handover to an LTM candidate cell without an explicit cell handover command after a radio link failure. When there is an explicit cell handover command, the CU may cancel the L3 inter-gNB handover procedure before the completion indication, such as receiving a notification of LTM initiation from a source DU.

[0147] In an embodiment, upon receiving an indication of LTM completion from a target DU or UE (202) (receiving an indication of LTM completion from the DU after the UE (202) has accessed a target cell, or receiving an RRC completion, such as an RRC reconfiguration completion, from the UE), the CU cancels the ongoing L3 handover procedure. In an embodiment, this is particularly applicable when the CU receives information about successful LTM completion from the DU (410) or UE (202) after the UE performs an LTM cell handover to an LTM candidate cell without an explicit cell handover command after a radio link failure. When there is an explicit cell handover command, the CU may cancel the L3 inter-gNB handover procedure before the completion indication, such as receiving a notification of LTM initiation from the source DU.

[0148] In an embodiment, upon receiving an indication of LTM completion from a target DU or UE (202) (receiving an indication of LTM completion from a DU after the UE (202) has accessed a target cell, or receiving an RRC completion, such as an RRC reconfiguration completion, from the UE), a source gNB CU (108) in an inter-gNB handover cancels an ongoing L3 inter-gNB handover procedure. In an embodiment, this is particularly applicable when the CU receives information about successful LTM completion from a DU (410) or UE (202) after the UE (202) performs an LTM cell handover to an LTM candidate cell without an explicit cell handover command after a radio link failure. When there is an explicit cell handover command, the CU may cancel the L3 inter-gNB handover procedure before the completion indication, such as receiving a notification of the initiation of LTM from the source DU.

[0149] In an embodiment, upon receiving an indication of LTM completion from a target DU or UE (202) (receiving an indication of LTM completion from a DU after the UE (202) has accessed a target cell, or receiving an RRC completion (such as RRC reconfiguration complete) from the UE), the source gNB CU (108) in the inter-gNB handover section cancels the ongoing L3 inter-gNB handover procedure by sending an Xn handover cancel request message. In an embodiment, this is particularly applicable when the CU receives information about successful LTM completion from the DU (410) or UE (202) after the UE (202) performs an LTM cell handover to an LTM candidate cell without an explicit cell handover command after a radio link failure. When there is an explicit cell handover command, the CU may cancel the L3 inter-gNB handover procedure before the completion indication, such as receiving a notification about the initiation of LTM from the source DU.

[0150] In an embodiment, upon receiving an L3 measurement report containing measurement results or upon deciding to perform an L3 handover to an LTM candidate cell (a cell for which the UE (202) already has LTM configuration), the gNB CU (108) instructs the source gNB DU (204a) to perform a cell handover command. The gNB DU (110) sends the cell handover command to the UE (202) instructing the UE (202) to perform LTM.

[0151] In an embodiment, the gNB CU (108) instructs the gNB DU (110) to perform a cell handover command. In an embodiment, the CU includes an IE (for example, cellswitch) and an IE for identifying a candidate cell for which a cell handover needs to be performed. In an embodiment, the IE for identifying the candidate cell is a candidate cell identifier. In an embodiment, the IE for identifying the candidate cell is a physical cell identifier (PCI). In an embodiment, the IE for identifying the candidate cell is an NR CGI. The gNB DU (110) sends a cell handover command to the UE (202), instructing the UE (202) to perform LTM.

[0152] In an embodiment, upon receiving an L3 measurement report containing measurement results or upon deciding to perform an L3 handover to an LTM candidate cell (a cell for which the UE (202) already has an LTM configuration), the gNB CU (108) sends an RRC message for handover (in NR, an RRC reconfiguration message including RRCReconfigurationwithsync). In an embodiment, upon receiving the RRC message for handover (in NR, an RRC reconfiguration message including RRCReconfigurationwithsync), the UE (202) performs the handover.

[0153] In an embodiment, upon receiving an L3 measurement report containing measurement results or upon deciding to perform an L3 handover to an LTM candidate cell (a cell for which the UE (202) already has LTM configuration), the gNB CU (108) sends an RRC message for handover (in NR, an RRC reconfiguration message including RRCReconfigurationwithsync), the RRC message including the cellgroupConfig for the LTM candidate cell configuration received from the gNBDU (110).

[0154] In an embodiment, upon receiving an L3 measurement report containing measurement results or upon deciding to perform an L3 handover to an LTM candidate cell (a cell for which the UE (202) already has LTM configuration), the gNB CU (108) sends an RRC message for handover (in NR, an RRC reconfiguration message including RRCReconfigurationWithSync) without performing the F1AP UE context establishment procedure (i.e., skipping the Figure 2 Steps 203 and 204).

[0155] In an embodiment, upon receiving an L3 measurement report containing measurement results or upon deciding to perform an L3 handover to an LTM candidate cell (a cell for which the UE (202) already has LTM configuration), the gNB CU (108) performs an F1AP UE context modification procedure (i.e., the CU in Figure 2 In step 203, the DU sends an F1AP UE context modification request to the DU, and the DU Figure 2 In step 204, the F1AP UE context modification response (ie, Figure 2 Steps 203 and 204 are F1AP UE context modification request and response, respectively, instead of F1AP UE context establishment request and response) to send an RRC message for handover (in NR, an RRC reconfiguration message including RRCReconfigurationwithsync).

[0156] In an embodiment, the gNB CU (108) instructs the UE (202) to perform a cell handover command and information for identifying an LTM candidate configuration in the above-mentioned RRC message send for performing the handover.

[0157] In an embodiment, the gNB CU (108) sends an RRC message for handover (in NR, an RRC reconfiguration message including RRCReconfigurationwithsync) to handover the UE (202) to the LTM candidate cell, and includes information for identifying the LTM candidate cell configuration (e.g., LTM candidate cell identifier) ​​in the handover message, and instructs the UE (202) to apply the LTM candidate cell configuration or a portion of the LTM candidate cell configuration identified by the information provided in ReconfigurationwithSync. The gNB CU (108) may also skip including an RRC IE corresponding to the LTM candidate configuration or a portion of the LTM candidate configuration in the RRC message (such as the RRC reconfiguration message including RRCReconfigurationwithsync). The UE (202) performs L3 handover, applying the LTM candidate cell configuration or a portion of the LTM candidate cell configuration identified by the information provided in ReconfigurationwithSync (e.g., LTM candidate cell identifier) ​​and other information provided in the handover message. In an embodiment, the portion of the LTM candidate cell configuration mentioned in the above embodiments includes one or more of CellGroupConfig, MeasConfig or RadioBearerConfig.

[0158] In an embodiment, the LTM candidate cell configuration may include the information elements shown in Table 3 below.

[0159] [Table 3]

[0160]

[0161] Instead of candLTM-ReconfigId, the gNB (106a and 106b) may send an alternative identifier (such as NR CGI or PCI) or any identifier as described above that enables the UE (202) to uniquely identify the LTM configuration or a portion of the LTM configuration and receive it by the UE (202).

[0162] In an embodiment, the UE (202) applies the LTM configuration identified by ApplyTMCandidateReconfigID during RRCReconfiguration (eg, during ReconfigurationWithSync).

[0163] In an embodiment, the UE (202) applies one or more of CellGroupConfig, MeasConfig, or RadioBearerConfig that are part of an LTM configuration identified by ApplylTMCandidateConfigID during an RRC reconfiguration procedure, such as during a reconfigurationWithSync when those parts of the LTM configuration are not received in an RRC reconfiguration message. If one or more of CellGroupConfig, MeasConfig, or RadioBearerConfig are present in an RRC message that includes ApplyTMCandidateConfigID, the UE (202) applies the one or more of CellGroupConfig, MeasConfig, or RadioBearerConfig present in the RRC message.

[0164] In an embodiment, if multiple HO procedures (e.g., LTM, L3 handover) are configured, the UE (202) applies the earliest triggered HO. In an embodiment, if both LTM and L3 handover are received at the same time, the UE (202) performs LTM. In an embodiment, if both LTM and L3 handover are triggered at the same time, the UE (202) performs L3 handover. In an embodiment, the UE (202) receives a configuration from the network as to whether to perform L3 handover or LTM when L3 handover and LTM are triggered at the same time. In an embodiment, the UE (202) performs L3 handover or LTM based on an internal configuration of the UE (202). In an embodiment, L3 handover is triggered when RRC reconfiguration for handover (in NR, RRC reconfiguration containing RRCReconfigurationwithSync is received), and LTM is triggered when a cell switching command is received.

[0165] In an embodiment, a UE (202) configured to perform LTM without lower layer reset (such as avoiding or partially performing MAC / RLC / PDCP reset) performs a lower layer reset like MAC reset upon receiving RRC reconfiguration for handover (in NR, receiving RRC reconfiguration including RRCReconfigurationwithSync).

[0166] Figure 5 Various hardware components of a UE (202) according to embodiments disclosed herein are shown.

[0167] In an embodiment, a UE (202) includes a processor (510), a communicator (520), a memory (530), and a handover coexistence controller (540). The processor (510) is coupled with the communicator (520), the memory (530), and the handover coexistence controller (540).

[0168] The handover coexistence controller (540) receives an L3 handover command from the CU of the network device (400) to perform an L3 handover. In addition, the handover coexistence controller (540) receives a cell switching command from the DU 410 of the network device (400) to perform an LTM handover. In addition, the handover coexistence controller (540) determines whether the L3 handover command for performing an L3 handover and the cell switching command for performing an LTM handover are received simultaneously or at different times. In an embodiment, when the L3 handover command for performing an L3 handover and the cell switching command for performing an LTM handover are received simultaneously, the handover coexistence controller (540) prioritizes the LTM handover over the L3 handover. In another embodiment, when the L3 handover command for performing an L3 handover is received before the cell switching command, the handover coexistence controller (540) performs the LTM handover. In another embodiment, when an L3 handover command to perform L3 handover is received before a cell switching command to perform LTM handover, the handover coexistence controller (540) performs L3 handover.

[0169] In an embodiment, the handover coexistence controller (540) determines whether the L3 handover command is received earlier than the cell handover command. When the L3 handover command is received earlier than the cell handover command, the handover coexistence controller (540) performs the L3 handover command on the cell handover command. When the L3 handover command is received later than the cell handover command, the handover coexistence controller (540) performs the cell handover command on the L3 handover command. In an embodiment, when the cell handover command and the L3 handover command are received simultaneously, the handover coexistence controller (540) receives the cell handover command and the L3 handover command in the same transmission block.

[0170] The handover coexistence controller (540) is implemented by analog and / or digital circuits, such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hard-wired circuits, etc., and may optionally be driven by firmware.

[0171] The processor (510) may include one or more processors. The one or more processors may be general-purpose processors (such as a central processing unit (CPU), an application processor (AP), etc.), graphics processing units (such as a graphics processing unit (GPU), a visual processing unit (VPU)), and / or AI-specific processors (such as a neural processing unit (NPU)). The processor (510) may include multiple cores and be configured to execute instructions stored in the memory (530).

[0172] Furthermore, the processor (510) is configured to execute instructions stored in the memory (530) and perform various processes. The communicator (520) is configured to communicate internally between internal hardware components and with external devices via one or more networks. The memory (530) also stores instructions to be executed by the processor (510). The memory (530) may include a non-volatile storage element. Examples of such non-volatile storage elements may include a magnetic hard disk, an optical disk, a floppy disk, a flash memory, or a form of electrically programmable memory (EPROM) or electrically erasable programmable memory (EEPROM). Additionally, in some examples, the memory (530) may be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or propagating signal. However, the term "non-transitory" should not be interpreted as meaning that the memory (530) is non-removable. In some instances, a non-transitory storage medium may store data that may change over time (e.g., in random access memory (RAM) or cache memory).

[0173] In an embodiment, the communicator (520) includes electronic circuitry specific to a standard for implementing wired or wireless communications. The communicator (520) is configured to communicate internally between internal hardware components of the UE (202) and with external devices via one or more networks.

[0174] although Figure 5 Various hardware components of the UE (202) are shown, but it should be understood that other embodiments are not limited thereto. In other embodiments, the UE (202) may include fewer or greater numbers of components. Furthermore, the labels or names of the components are for illustrative purposes only and do not limit the scope of the present invention. One or more components may be combined to perform the same or substantially similar functions in the UE (202).

[0175] Figure 6 Various hardware components of a DU (410) according to embodiments disclosed herein are shown.

[0176] In an embodiment, the DU (410) includes a processor (610), a communicator (620), a memory (630), and a handover coexistence controller (640). The processor (610) is coupled with the communicator (620), the memory (630), and the handover coexistence controller (640).

[0177] The handover coexistence controller (640) receives a UE context modification request for L3 handover of the UE (202) from the CU (420) of the network device (400). In addition, the handover coexistence controller (640) determines whether the DU (410) triggers a cell handover command for the UE 202. In an embodiment, when the DU (410) triggers a cell handover command for the UE (202), the handover coexistence controller (640) sends a UE context modification fault to the CU (420) of the network device (400). The UE context modification fault is sent including a radio network layer cause IE in an F1AP UE context modification fault message. The radio network layer cause IE indicates that lower layer mobility has been triggered. When the F1AP UE context modification includes the SpCellId IE, the DU (410) identifies that the F1AP UE context modification is for L3 handover. In another embodiment, when the DU (410) does not trigger a cell handover command for the UE (202), the handover coexistence controller 640 stops the LTM-related operations of the DU (410) for the UE (202). When the source DU and the target DU are the same, the LTM-related operations may be, for example, but not limited to, triggering aperiodic DCI, processing LTM measurements, triggering LTM cell handover, and sending a random access response for LTM completion.

[0178] The handover coexistence controller (640) is implemented by analog and / or digital circuits, such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hard-wired circuits, etc., and may optionally be driven by firmware.

[0179] The processor (610) may include one or more processors. The one or more processors may be general-purpose processors (such as a central processing unit (CPU), an application processor (AP), etc.), graphics processing units (such as a graphics processing unit (GPU), a visual processing unit (VPU)), and / or AI-specific processors (such as a neural processing unit (NPU)). The processor (610) may include multiple cores and be configured to execute instructions stored in the memory (120).

[0180] Furthermore, the processor (610) is configured to execute instructions stored in the memory (630) and perform various processes. The communicator (620) is configured to communicate internally between internal hardware components and with external devices via one or more networks. The memory (630) also stores instructions to be executed by the processor (610). The memory (630) may include a non-volatile storage element. Examples of such non-volatile storage elements may include a magnetic hard disk, an optical disk, a floppy disk, a flash memory, or a form of electrically programmable memory (EPROM) or electrically erasable programmable memory (EEPROM). Additionally, in some examples, the memory (630) may be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or propagating signal. However, the term "non-transitory" should not be interpreted as meaning that the memory (630) is non-removable. In some instances, a non-transitory storage medium may store data that may change over time (e.g., in random access memory (RAM) or cache memory).

[0181] In an embodiment, the communicator (620) includes electronic circuitry specific to a standard for implementing wired or wireless communications. The communicator (620) is configured to communicate internally between internal hardware components of the UE (202) and with external devices via one or more networks.

[0182] although Figure 6 Various hardware components of the DU (410) are shown, but it should be understood that other embodiments are not limited thereto. In other embodiments, the DU (410) may include fewer or greater numbers of components. Furthermore, the labels or names of the components are for illustrative purposes only and do not limit the scope of the present invention. One or more components may be combined to perform the same or substantially similar functions in the DU (410).

[0183] Figure 7 A flow chart (S700) is shown of a method implemented by a UE (202) for handling L3 handover and LTM handover in a telecommunications network (1000) according to embodiments disclosed herein. Operations (S702-S712) are handled by a handover coexistence controller (540).

[0184] At S702, the method includes receiving an L3 handover command from a CU (420) of a network device (400) to perform an L3 handover. At S704, the method includes receiving a cell switching command from a DU (410) of the network device (400) to perform an LTM handover. At S706, the method includes determining whether the L3 handover command to perform the L3 handover and the cell switching command to perform the LTM handover are received at the same time or at different times.

[0185] In one embodiment, at S708, the method includes prioritizing LTM handover over L3 handover when both an L3 handover command to perform L3 handover and a cell switching command to perform LTM handover are received simultaneously. In another embodiment, at S710, the method includes performing LTM handover when an L3 handover command to perform L3 handover is received before the cell switching command. In another embodiment, at S712, the method includes performing L3 handover when an L3 handover command to perform L3 handover is received before the cell switching command to perform LTM handover.

[0186] Figure 8 A flowchart S800 of a method implemented by a DU (410) for handling L3 handover and LTM handover in a telecommunications network 1000 according to embodiments disclosed herein is shown. The operations (S802-S614) are handled by a handover coexistence controller (640).

[0187] At S802, the method includes receiving a UE context modification request for L3 handover of a UE (202) from a CU (420) of a network device (400). At S804, the method includes determining whether a cell handover command for the UE (202) is triggered by the DU (410). In an embodiment, at S806, the method includes sending a UE context modification fault to the CU (420) of the network device (400) when the cell handover command for the UE (202) is triggered by the DU (410). In another embodiment, at S808, the method includes stopping LTM-related operations for the UE (202) by the DU (410) when the cell handover command for the UE (202) is not triggered by the DU (410).

[0188] Figure 9 A flow chart (S900) is shown of LTM processing at the DU (410) according to embodiments disclosed herein. Operations (S902-S906) are handled by the handover coexistence controller (640).

[0189] At S902, the method includes receiving an LTM mobility configuration. At S904, the method includes receiving information from a CU (420) to stop LTM mobility actions. At S906, the method includes stopping sending cell handover commands, aperiodic DCI triggers, processing of LTM measurements, and processing of LTM completed random access responses.

[0190] Figure 10A flow chart (S1000) of LTM and L3 HO processing at a CU (420) according to embodiments disclosed herein is shown. The flow is particularly applicable when the CU receives information about successful LTM completion from a DU (410) or UE (202) after the UE (202) performs an LTM cell handover to an LTM candidate cell without an explicit cell handover command after a radio link failure. At S1002, the method includes initiating an L3 handover. At S1004, the method includes receiving information about successful LTM completion from the DU (410) or UE (202). At S1006, the method includes canceling the L3 handover and sending an Xn Handover Cancel.

[0191] Figure 11 A flow chart (S1100) is shown for applying a portion of a candidate cell configuration for L3 HO according to an embodiment disclosed herein. At S1102, the method includes receiving an LTM mobility configuration. At S1104, the method includes receiving an L3 measurement report and selecting an LTM candidate cell for L3 handover. At S1106, the method includes sending an RRCReconfiguationwithSync and instructing the UE (202) to apply a portion of the candidate cell configuration.

[0192] The various actions, blocks, steps, etc. in the flowchart (S700-S1100) can be performed in the order presented, in a different order, or simultaneously. In addition, in some embodiments, some of the actions, blocks, steps, etc. can be omitted, added, modified, skipped, etc. without departing from the scope of the present invention.

[0193] Figure 12 A first network node according to an embodiment of the present disclosure is shown.

[0194] refer to Figure 12 , the first network node (1200) may include a controller (1210), a transceiver (1220) and a memory (1230). However, all of the components shown are not required. The first network node (1200) may be composed of Figure 12 Furthermore, according to another embodiment, the controller (1210), the transceiver (1220), and the memory (1230) may be implemented as a single chip.

[0195] The first network node (1200) may correspond to the gNB-DU described above. For example, the first network node (1200) may correspond to the source gNB-DU (110a-b, 204a) or the DU (410) described above.

[0196] The aforementioned components will now be described in detail.

[0197] The controller (1210) may include one or more processors or other processing devices that control the proposed functions, processes and / or methods.The operations of the first network node (1200) may be implemented by the controller (1210).

[0198] The transceiver (1220) may include an RF transmitter for up-converting and amplifying a transmit signal, and an RF receiver for down-converting the frequency of a receive signal. However, according to another embodiment, the transceiver (1220) may be implemented by more or fewer components than those illustrated in the components.

[0199] The transceiver (1220) can be connected to the controller (1210) and transmit and / or receive signals. The signals may include control information and data. In addition, the transceiver (1220) can receive signals through a wireless channel and output the signals to the controller (1210). The transceiver (1220) can transmit signals output from the controller (1210) through a wireless channel.

[0200] The memory (1230) may store control information or data included in the signal obtained by the first network node (1200). The memory (1230) may be connected to the controller (1210) and store at least one instruction or protocol or parameter for the proposed function, process and / or method. The memory (1230) may include a read-only memory (ROM) and / or a random access memory (RAM) and / or a hard disk and / or a CD-ROM and / or a DVD and / or other storage devices.

[0201] Figure 13 A second network node according to an embodiment of the present disclosure is shown.

[0202] refer to Figure 13 , the second network node (1300) may include a controller (1310), a transceiver (1320) and a memory (1330). However, all components shown are not required. The second network node (1300) may be composed of Figure 13 Furthermore, according to another embodiment, the controller (1310), the transceiver (1320), and the memory (1330) may be implemented as a single chip.

[0203] The second network node (1300) may correspond to the gNB-DU described above. For example, the second network node (1300) may correspond to the source gNB-CU (108) or the DU (420) described above.

[0204] The aforementioned components will now be described in detail.

[0205] The controller (1310) may include one or more processors or other processing devices that control the proposed functions, processes and / or methods.The operations of the second network node (1300) may be implemented by the controller (1310).

[0206] The transceiver (1320) may include an RF transmitter for up-converting and amplifying a transmit signal, and an RF receiver for down-converting the frequency of a receive signal. However, according to another embodiment, the transceiver (1320) may be implemented by more or fewer components than those shown in the figure.

[0207] The transceiver (1320) may be connected to the controller (1310) and transmit and / or receive signals. The signals may include control information and data. In addition, the transceiver (1320) may receive signals through a wireless channel and output the signals to the controller (1310). The transceiver (1320) may transmit signals output from the controller (1310) through a wireless channel.

[0208] The memory (1330) may store control information or data included in the signal obtained by the second network node (1300). The memory (1330) may be connected to the controller (1310) and store at least one instruction or protocol or parameter for the proposed function, process and / or method. The memory (1330) may include a read-only memory (ROM) and / or a random access memory (RAM) and / or a hard disk and / or a CD-ROM and / or a DVD and / or other storage devices.

[0209] The foregoing description of the specific embodiments will fully reveal the general nature of the embodiments herein so that others can easily modify or adapt such specific embodiments for various applications by applying current knowledge without departing from the general concepts, and therefore, such adjustments and modifications should and are intended to be understood as being within the meaning and range of equivalents of the disclosed embodiments. It should be understood that the wording or terminology employed herein is for purposes of description and not limitation. Therefore, although the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein may be practiced by modification within the scope of the embodiments as described herein.

Claims

1. A method performed by a first network node in a communication system, the method comprising: receiving a user equipment (UE) context modification request message for mobility from a second network node; and In case the first network node cannot accept a UE context modification request message for mobility because an L1 / L2 triggered mobility (LTM) command has been triggered to the UE, a UE context modification failure message is sent to the second network node.

2. The method according to claim 1, wherein The UE context modification failure message includes information about a failure cause indicating that the LTM command has been triggered.

3. The method according to claim 1, further comprising: Sending a control message for the LTM command to the UE; Identifying a target cell for access by the UE for LTM; and An access success message is sent to the second network node, indicating that the UE has successfully accessed the target cell.

4. The method according to claim 1, wherein The first network node operates as a distributed unit (DU) of a next generation Node B (gNB), and the second network node operates as a central unit (CU) of the gNB.

5. A method performed by a second network node in a communication system, the method comprising: sending a user equipment (UE) context modification request message for mobility to a first network node; receiving a UE context modification failure message from the first network node; and Based on the UE context modification failure message, it is identified that the first network node cannot accept the UE context modification request message for mobility because a L1 / L2 triggered mobility (LTM) command has been triggered to the UE.

6. The method according to claim 5, wherein: The UE context modification failure message includes information about a failure cause indicating that the LTM command has been triggered.

7. The method according to claim 5, further comprising: An access success message is received from the first network node indicating that the UE has successfully accessed a target cell for LTM.

8. The method according to claim 5, wherein The first network node operates as a distributed unit (DU) of a next generation Node B (gNB), and the second network node operates as a central unit (CU) of the gNB.

9. A first network node in a communication system, the first network node comprising: transceiver; and The controller is configured as: receiving a user equipment (UE) context modification request message for mobility from a second network node via the transceiver, and In case the first network node cannot accept the UE context modification request message for mobility because an L1 / L2 triggered mobility (LTM) command has been triggered to the UE, a UE context modification failure message is sent to the second network node via the transceiver.

10. The first network node according to claim 9, wherein: The UE context modification failure message includes information about a failure cause indicating that the LTM command has been triggered. The first network node according to claim 9 , wherein: The controller is further configured to: sending a control message for the LTM command to the UE via the transceiver, identifying the UE access target cell for LTM, and An access success message is sent to a second network node via the transceiver, indicating that the UE has successfully accessed the target cell.

12. The first network node according to claim 9, wherein: The first network node operates as a distributed unit (DU) of a next generation Node B (gNB), and the second network node operates as a central unit (CU) of the gNB.

13. A second network node in a communication system, the second network node comprising: transceiver; and The controller is configured as: sending a user equipment (UE) context modification request message for mobility to a first network node via the transceiver, receiving, via the transceiver, a UE context modification failure message from a first network node; and Based on the UE context modification failure message, it is identified that the first network node cannot accept the UE context modification request message for mobility because an L1 / L2 triggered mobility (LTM) command has been triggered to the UE. The second network node according to claim 13 , wherein: The UE context modification failure message includes information about a failure cause indicating that the LTM command has been triggered. The second network node according to claim 13 , wherein: The controller is further configured to receive, via the transceiver, an access success message from the first network node indicating that the UE has successfully accessed a target cell for LTM, and The first network node operates as a distributed unit (DU) of a next generation Node B (gNB), and the second network node operates as a central unit (CU) of the gNB.

Images