User equipment, central unit, and method

Abstract

This disclosure relates to wireless communication systems and devices, methods thereof, and lower-layer triggered mobility (LTM). Apparatus and methods for supporting CU-based LTM are disclosed. Apparatus and methods for exchanging security information in CU-based LTM are disclosed.

Description

[Technical Field]

[0001] This disclosure relates to a communication system. [Background technology]

[0002] This disclosure is not exclusive, but particularly relates to wireless communication systems and devices operating in accordance with the 3rd Generation Partnership Project (3GPP®) standards or their equivalents or derivatives (including LTE Advanced, Next Generation or 5G networks, Future Generation, and beyond), as well as lower-layer triggered mobility (LTM).

[0003] The evolution of 3GPP standards to date has been known as Long-Term Evolution (LTE) and Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) of Evolved Packet Core (EPC) networks, commonly referred to as "4G." More recently, the terms "5G" and "new radio (NR)" have begun to be used to refer to evolving communication technologies that are expected to support a variety of applications and services. Various details of 5G networks are described in the "NGMN 5G White Paper" V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, which can be obtained, for example, from https: / / www.ngmn.org / 5g-white-paper.html. 3GPP intends to support 5G through the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and 3GPP NextGen core network.

[0004] Under 3GPP standards, a NodeB (or eNB in ​​LTE, and gNB in ​​5G) is a radio access network (RAN) node (or simply “access node,” “access network node,” or “base station”) through which communication devices (user equipment or “UE”) connect to the core network and communicate with other communication devices or remote servers. For simplicity, this application uses the terms access network node, RAN node, or base station to refer to any such access node.

[0005] Furthermore, for the sake of simplification, this application uses the terms mobile device, user device, or UE to refer to any communication device that can connect to a core network via one or more base stations. While this application may refer to mobile devices in its description, it should be understood that the described technology can be implemented on any communication device (mobile and / or generally fixed) that can connect to a communication network to transmit / receive data, whether such communication device is controlled by human input or by software instructions stored in memory.

[0006] In the current 5G architecture, the structure of the gNB can be split into two or more parts. In some RAN implementations, there are two parts: a Central Unit (CU or gNB-CU), sometimes called a "control unit", connected by the F1 interface, and a Distributed Unit (DU or gNB-DU). This enables the use of a "split" architecture. Typically, in a "split" architecture, the "upper" CU layer (e.g., but not necessarily limited to, the Packet Data Convergence Protocol (PDCP) layer and the Radio Resource Control (RRC) layer), and the "lower" DU layer (e.g., but not necessarily limited to, the Radio Link Control (RLC) layer, Media Access Control (MAC) layer, and Physical (PHY) layer) are separated between a specific CU and one or more DUs connected to and controlled by that CU via the F1 interface. Thus, for example, the upper-layer CU functions of some gNBs can be implemented centrally (e.g., by a single processing unit or in a cloud-based or virtualized system) while locally retaining the lower-layer DU functions separately for each gNB.

Prior Art Documents

Non-Patent Documents

[0007]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0008] Historically, mobility between different cells in cellular communication has been based on communication in upper layers such as layer 3 (e.g., L3 or radio resource control (RRC) layer) signaling. More recently, for the purpose of providing enhanced mobility, mobility centered on layer 1 (e.g., L1 or physical (PHY) layer) and / or layer 2 (e.g., L2 or media access control (MAC) layer), also called L1 / L2 centered mobility, has been considered and supported instead of the upper layer (e.g., RRC layer). Such L1 / L2 centered mobility, also called L1 / L2 triggered mobility or "lower layer triggered mobility (LTM)", is expected to improve the mobility of devices operating in both sub-7GHz and mmWave bands, for example, by supporting lower latency handovers and improved robustness. However, LTM is currently only supported in the case of CU-internal handovers (including DU-internal and DU-internal scenarios).

[0009] Therefore, there is a need to develop communication devices (such as base stations and / or UEs) and corresponding methods that support an efficient / flexible mechanism for supporting CU-interconnect based LTM. In particular, there is a need for improved methods and apparatuses that support a reliable, safe, and efficient CU-interconnect based LTM handover for reducing latency and interruption time.

[0010] The present disclosure aims to provide devices and methods that at least partially address the above needs and / or problems.

Means for Solving the Problems

[0011] Detailed examples of the present disclosure are described herein by way of example with reference to the accompanying drawings.

Brief Description of the Drawings

[0012] [Figure 1] This is a schematic diagram of a mobile ("cellular" or "wireless") communication system 1. [Figure 2] This figure shows a typical frame structure that can be used in communication system 1 shown in Figure 1. [Figure 3] Examples of handover within and between CUs are shown. [Figure 4] Here is an example of key processing used for handover. [Figure 5] This document outlines the key update procedure for inter-CU handover. [Figure 6] This document describes a method for LTM (Long-Term Management) based on inter-DU (Duplex Unit) relationships within a CU (Unit of Cubic). [Figure 7] This shows the signaling flow for LTM(Uu). [Figure 8] This shows the further signaling flow of LTM. [Figure 9] This document describes a method for inter-CU-based LTM (Long-Term Management). [Figure 10] Further methods for inter-CU-based LTM, including the transmission of security parameters and security keys, are presented. [Figure 11] Further methods for inter-CU-based LTM are presented. [Figure 12] This document outlines how to perform security updates for multiple CU-based LTMs. [Figure 13] Figure 1 is a schematic block diagram showing the main components of UE3 for communication system 1. [Figure 14] Figure 1 is a schematic block diagram showing the main components of the distributed base station 5 for the communication system 1. [Figure 15] Figure 1 is a schematic block diagram showing the main components of the core network nodes or functions for communication system 1. [Modes for carrying out the invention]

[0013] overview Here, for illustrative purposes only, we will describe an exemplary telecommunications system in general terms, referring to Figures 1 through 5.

[0014] Figure 1 is a schematic diagram of a mobile ("cellular" or "wireless") communication system 1 to which this disclosure is applicable.

[0015] In communication system 1, user equipment (UE) 3-1, 3-2, 3-3 (e.g., mobile phones and / or other mobile devices) can communicate with each other via radio access network (RAN) nodes 5 operating according to one or more compatible radio access technologies (RATs). In the illustrated example, RAN node 5 comprises a distributed base station 5 or "gNB" operating one or more associated cells 9. Communication via the RAN is typically routed via an associated core network 7 (e.g., a 5G / 6G or later generation core network or evolved packet core network (EPC)).

[0016] As those skilled in the art will understand, three UE3s and one base station 5 are shown in Figure 1 for illustrative purposes, but the system, when implemented, typically includes other base stations 5 and UE3s.

[0017] Each base station 5 controls one or more associated cells 9, either directly or indirectly through one or more other nodes (such as home base stations, relays, remote radio heads, or distributed units). It will be understood that base stations 5 may be configured to support 4G, 5G, 6G, and / or later generations, as well as / or any other 3GPP or non-3GPP communication protocols.

[0018] In this example, the illustrated RAN node 5 comprises a distributed base station 5 having at least one distributed unit (DU) 5b (e.g., gNB-DU) and a central unit (CU) 5c (e.g., gNB-CU). The CU 5c utilizes a separate control plane and user plane, and is therefore divided into a control plane function (CU-CP) and a user plane function (CU-UP), which communicate with the DU via appropriate interfaces (e.g., F1-C interface) and appropriate interfaces (e.g., F1-U interface) (together forming an F1 interface (or "reference point")), and communicate with each other via appropriate interfaces (e.g., E1 interface). In this example, the DU provides the functionality of the lower part of the PHY layer and therefore includes the physical and virtual elements necessary to communicate with the UE3 via the air interface, but it will be understood that the RAN may alternatively (or additionally) include one or more separate radio units (RUs) (e.g., providing the functionality of the lower part of the PHY layer). Nevertheless, although distributed RAN node 5 is shown and described, it should be understood that RAN node 5 may also be provided in a non-distributed form, for example, as an integrated base station (e.g., gNB or eNB).

[0019] The UE3 and their serving base stations 5 are connected via an appropriate air interface (e.g., a so-called "Uu" interface). Adjacent base stations 5 may be connected to each other via appropriate base station-base station interfaces (such as a so-called "X2" interface, an "Xn" interface, etc.).

[0020] The core network 7 includes several logical nodes (or "functions") to handle communications in the telecommunications system 1. In this example, the core network 7 includes a control plane function (CPF) 10 and one or more network node entities for user data communications (e.g., user plane function (UPF) 11). The CPF 10 includes one or more network node entities for control signaling communications (e.g., Access and Mobility Management Function (AMF) 10-1), one or more work node entities for session management (e.g., Session Management Function (SMF) 10-2), and several other functions 10-n (e.g., Authentication Server Function (AUSF) to facilitate security processes, Unified Data Management (UDM) entities for managing user-specific data (e.g., access permissions, user registration, and data network profiles), Policy Control Function (PCF), Application Function (AF), etc.). It will be understood that nodes or functions may have different names in different systems.

[0021] RAN node 5 is connected to the core network nodes via appropriate interfaces (or "reference points"), such as the N2 reference point between RAN CU 5c (CU-CP) and AMF10-1 for control signaling communications, and the N3 reference point between RAN CU 5c (CU-UP) and each UPF11 for user data communications. Each UE3 is connected to AMF10-1 via a non-access stratum (NAS) connection through an appropriate reference point (e.g., the N1 reference point, similar to the S1 reference point in LTE). It will be understood that N1 communications are routed transparently through the RAN.

[0022] One or more UPF11s are connected to an external data network (e.g., an IP network such as the Internet) via a suitable reference point (e.g., an N6 reference point) for communicating user data.

[0023] The AMF10-1 performs mobility management-related functions, maintains NAS connectivity with each UE3, and manages UE registration. The AMF10-1 also manages paging. The SMF10-2 provides session management functions (which form part of the MME function in LTE) and combines several control plane functions (provided by the serving gateway and packet data network gateway in LTE). The SMF10-2 also assigns an IP address to each UE3.

[0024] The base station 5 of communication system 1 is configured to operate at least one cell 9 on an associated time-division duplex (TDD) carrier operating on a non-paired spectrum. It will be understood that base station 5 may also operate at least one cell 9 on an associated frequency-division duplex (FDD) carrier operating on a paired spectrum.

[0025] Furthermore, base station 5 is configured to transmit control information and user data via several downlink (DL) physical channels, and UE3 is configured to receive them and transmit several physical signals. DL physical channels correspond to resource elements (REs) that carry information transmitted from higher layers, and DL physical signals correspond to REs used in the physical layer that do not carry information transmitted from higher layers.

[0026] Physical channels may include, for example, a physical downlink shared channel (PDSCH), a physical broadcast channel (PBCH), and a physical downlink control channel (PDCCH). The PDSCH carries data that shares its capacity on a time and frequency basis. The PDSCH can carry various data items, including, for example, user data, UE-specific upper-layer control messages mapped from higher channels, system information blocks (SIBs), and paging. The PDCCH carries downlink control information (DCI) to support several functions, including scheduling downlink transmissions on the PDSCH and uplink data transmissions on the physical uplink shared channel (PUSCH). The PBCH provides the Master Information Block (MIB) to the UE3. The PBCH also works in conjunction with the PDCCH to support time and frequency synchronization, which assists in cell acquisition, selection, and re-selection. UE3 can receive Synchronization Signal Blocks (SSBs), and UE3 can assume that the reception timings of the PBCH, primary synchronization signal (PSS), and secondary synchronization signal (SSS) are consecutive symbols, forming an SS / PBCH block. Base station 5 can transmit several synchronization signal (SS) blocks corresponding to different DL beams. The total number of SS blocks may be limited, for example, to 5 ms in duration as an SS burst. The periodicity of SSB transmissions may be indicated to the UE using any appropriate signaling (e.g., per serving cell using ssb-periodicityServingCell). The periodicity value of the SSB may be, for example, 20 ms or more. For initial cell selection, UE3 may be configured to assume that SS bursts occur with a periodicity of 2 frames.UE3 may also provide instructions on which SSBs to send within a 5ms duration (for example, using ssb-PositionsInBurst).

[0027] DL physical signals may include, for example, a reference signal (RS) and a synchronization signal (SS). The reference signal (sometimes known as a pilot signal) is a signal with a predetermined special waveform known to both the UE3 and the base station 5. Reference signals may include, for example, a cell-specific reference signal, a UE-specific reference signal (UE-RS), a downlink demodulation signal (DMRS), and a channel state information reference signal (CSI-RS).

[0028] Similarly, UE3 is configured to transmit control information and user data via several uplink (UL) physical channels corresponding to REs that carry information transmitted from higher layers, and UL physical signals used in the physical layer that correspond to REs that do not carry information transmitted from higher layers, and base station 5 is configured to receive them. Physical channels may include, for example, PUSCH, physical uplink control channel (PUCCH), and / or physical random-access channel (PRACH). UL physical signals may include, for example, demodulation reference signal (DMRS) for UL control / data signals, and / or sounding reference signal (SRS) used for UL channel measurement.

[0029] When UE3 first establishes a radio resource control (RRC) connection with base station 5 via cell 9, UE3 registers with the appropriate core network node (e.g., AMF, MME). UE3 is in a so-called RRC connected state, and the associated UE context is maintained by the network. When UE3 is in a so-called RRC idle state, or RRC inactive state, UE3 selects an appropriate cell to camp on so that the network (not necessarily at the cell level) can recognize UE3's approximate location.

[0030] As described above, the base station 5 in this example is a “distributed” base station 5 divided between one or more distributed units (DUs) 5b and a Central Unit (CU) 5c, where the CU 5c typically performs higher-level functions and communication with the next-generation core, and the DU 5b performs lower-level functions and communication via an air interface with neighboring UE3s (i.e., within the cell operated by the base station 5). The distributed base station 5 may include, for example, the following function units that host the following functions: -Central Unit (CU): A logical node that hosts the Radio Resource Control (RRC) layer, Service Data Adaptation Protocol (SDAP) layer, and Packet Data Convergence Protocol (PDCP) layer of the base station 5, which controls the operation of one or more DUs. The CU terminates the appropriate interface (e.g., the so-called F1 interface) connected to the DU. - Distributed Unit (DU): A logical node that hosts the Radio Link Control (RLC), Medium Access Control (MAC), and Physical (PHY) layers of base station 5, and whose operation is partially controlled by the CU. One DU supports one or more cells. One cell is supported by only one DU. The DU terminates the appropriate interface (e.g., F1 interface) connected to the CU. -CU-Control Plane (CU-CP): A logical node that hosts the RRC and control plane portions of the PDCP protocol for the CU of base station 5. The CU-CP terminates the appropriate interface connected to the CU-UP (e.g., the so-called E1 interface) and the appropriate interface connected to the DU (e.g., the F1-C (F1 control plane) interface). -CU-User Plane (CU-UP): A logical node that hosts the user plane portion of the PDCP and SDAP protocols of the CU of base station 5. The CU-UP terminates the appropriate interface connected to the CU-CP (e.g., the E1 interface) and the appropriate interface connected to the DU (e.g., the F1-U (F1 user plane) interface).

[0031] Frame structure Referring to Figure 2, which shows a typical frame structure that may be used in communication system 1, the base station 5 and UE3 of communication system 1 communicate with each other in the time domain using resources organized into frames of length 10 ms. Each frame consists of 10 subframes of equal size, each 1 ms long. Each subframe is divided into one or more slots, each containing 14 orthogonal frequency-division multiplexing (OFDM) symbols of equal length.

[0032] As shown in Figure 2, communication system 1 supports multiple different numerologies (subcarrier spacing (SCS), slot length, and consequently OFDM symbol length). Specifically, each numerology is identified by the parameter μ, where μ=0 represents 15kHz (corresponding to LTE SCS). Currently, SCS for other values ​​of μ can actually be derived from μ=0 by scaling up by a power of 2 (i.e., SCS = 15 × 2μkHz). The relationship between the parameter μ and SCS(Δf) is shown in Table 1. [Table 1]

[0033] CU-DU information exchange In communication system 1, various messages may be exchanged between CU 5c and DU 5b during a configuration procedure (e.g., the "F1 configuration procedure") to configure communication between the DU and CU. The purpose of the configuration procedure is to exchange the necessary application-level data between DU 5b and CU 5c to ensure accurate interoperability (e.g., over the F1 interface). This procedure is an initial procedure triggered for control plane communication (e.g., via the F1-C interface) after the transport network layer (TNL) association has become operational. Typically, this procedure uses non-UE-related signaling.

[0034] During this procedure, DU 5b may send a configuration request message (e.g., an F1 configuration request) to CU 5c. If the configuration request message is an F1 configuration request, it may include, for example, the following information: -DU Service Target Cell List IE: Information about cells and related functions (e.g., NR-U) supported by DU. -DU System Information IE.

[0035] It should be understood that different names for information elements serving similar purposes may be used.

[0036] In response, CU 5c typically sends an F1 configuration response message to DU 5b. The following information may be included in the F1 configuration response message: - List of cells to be activated: A list of cells that IE:CU 5c requests activation from DU 5b.

[0037] In addition to the messages described above, other messages (containing relevant information elements) may be used to update the configuration between CU 5c and DU 5b. For example, information may be exchanged between CU 5c and DU 5b using Public Land Mobile Network (PLMN) lists, serviced cell information, GNB-DU configuration update, or GNB-CU configuration update messages.

[0038] For example, additional messaging may be used between CU 5c and DU 5b when establishing the UE context during the UE context setup procedure. The purpose of the UE context setup procedure is to establish a UE context that includes the signaling radio bearer (SRB) and data radio bearer (DRB). This procedure uses UE-related signaling.

[0039] During this procedure, CU 5c may send a UE context setup request message to DU 5b (this message may include, for example, an RRC container used to carry additional information in RRC information IE). The following information may be included in the UE context setup request message: -UE Capability RAT Container List: DU 5b may take this information into consideration for UE-specific configurations. -The DRX cycle IE:DU 5b may use the value provided by CU 5c. -RRC Information IE: If CU 5c receives UEAssistanceInformation IE from UE3, UEAssistanceInformation IE may be included in the RRC Information IE. DU 5b may take UE assistance information into consideration when configuring UE3 resources, if supported. -SRB To Be configuration list; -DRB To Be settings list.

[0040] In response, DU 5b sends a UE context setting response message to CU 5c. The following information may be included in the UE context setting response message: - A list of DRBs (and SRBs) that were successfully established and those that failed to be established. -When DU 5b reports a failure to establish a DRB or SRB, the associated causal value must be accurate enough for CU 5c to know the reason for the establishment failure. This could include the fact that a given function is not supported by DU 5b. -CellGroupConfig: As an Octet string transparently included within the RRC reconfiguration message sent to UE3 by CU 5c. -DRX Config: As an Octet string transparently included within the RRC reconfiguration message sent to UE3 by CU 5c.

[0041] Instead of the above message, an alternative message (containing relevant information elements) may be used to update the UE configuration between CU 5c and DU 5b.

[0042] For example, to further update the UE3 configuration between CU 5c and DU 5b (e.g., DRB / SRB), a UE context modification request message (from CU 5c to DU 5b) or a UE context modification requirement message (from DU 5b to CU 5c) may be used for information exchange between CU 5c and DU 5b.

[0043] System information and SIB It will be understood that transmissions in cell 9 of base station 5 may include one or more broadcast transmissions, one or more unicast transmissions for reception by UE3, and / or one or more multicast transmissions for reception by a group of UE3. System information (SI) transmitted within a cell may include "minimum SI (MSI)" and "other SI (OSI)". OSI may be broadcast on demand, for example, using a downlink shared channel (DL-SCH). OSI may be broadcast in response to a request from a UE3 that is in a radio resource control (RRC) idle or RRC inactive state. OSI may also be requested by a UE3 that is in an RRC connected state, for example, via one or more dedicated RRC transmissions.

[0044] The System Information Block (SIB) may include information that enables the UE3 to complete cell selection (for example, by configuring it to complete it), information that enables the UE3 to complete a cell re-selection procedure, or information that enables the UE3 to receive one or more paging messages transmitted within a cell. The SI may be broadcast using a Master Information Block (MIB) and one or more System Information Blocks (SIBs).

[0045] The MSI comprises an MIB and a system information block 1 (SIB1). The MIB includes information used by the UE3 to receive SIB1, such as the subcarrier interval for SIB1. The MIB provides information corresponding to the Control Resource Set (CORESET) and the search space. SIB1 is sometimes referred to as the “remaining MSI (RMSI)”. SIB1 may be transmitted in a dedicated RRC message, and other SIBs (such as SIB2-SIB9) may be transmitted using one or more other suitable RRC transmissions (such as another dedicated RRC message). The MIB and SIB1 can provide the UE3 with scheduling information for receiving and decoding other SIBs such as SIB2-SIB9, and can provide information used by the UE3 to receive one or more paging messages. The OSI may include, for example, SIB2-SIB9 transmitted using a downlink sharded channel (DL-SCH) in an SI message. The mapping of SIB2-SIB9 to the corresponding SI messages may be provided to the UE3 by the base station 5. MIBs and SIB1-SIB9 are described in more detail, for example, in 3GPP TS 38.331. SIB2 provides information for intra-frequency, inter-frequency, and inter-system cell reselection. SIB3 provides cell-specific information regarding intra-frequency cell reselection. SIB4 provides information regarding inter-frequency cell reselection. SIB5 provides information regarding inter-system cell reselection for 4G (LTE). SIB6 and SIB7 provide information regarding earthquake and tsunami warning systems (ETWS). SIB8 provides information regarding commercial mobile alert service (CMAS) notifications, for example, to provide warning messages to UE3.SIB9 includes information about coordinated universal time (UTC), global positioning system (GPS) time (for example, for GPS initial setup), and local time.

[0046] SIBs may be broadcast periodically (for example, according to a predetermined periodic pattern), or alternatively, they may be provided "on demand" in response to requests from, for example, UE3. For example, MIBs may be transmitted with a periodicity of 80ms and repetitions occurring within 80ms, while SIB1 may be transmitted with a periodicity of 15cm ms and variable transmission repetition periodicity within 15cm ms (for example, 20ms). SIB1 may be used to indicate to UE3 which SIBs are transmitted periodically and which SIBs are available on demand in response to requests from UE3. UE3 may be configured to request on-demand SIBs using message 1 (MSG1), which may be called an MSG1-based on-demand SI request, or message 3 (MSG3), which may be called an MSG3-based on-demand SI request.

[0047] A physical broadcast channel (PBCH) may be used to broadcast the MIB. Base station 5 can transmit the PBCH in an SS / PBCH block along with a synchronization signal (SS) (e.g., primary synchronization signal (PSS) and secondary synchronization signal (SSS)). The SS / PBCH block comprises four orthogonal frequency-division multiplexed (OFDM) symbols that map to the PSS, SSS, and PBCH associated with a demodulation reference signal (DM-RS). In the frequency domain, the SS / PBCH block contains 240 consecutive subcarriers. When UE3 is in an RRC connection state, base station 5 can provide UE3 with notification of the resources used for the SS / PBCH, for example, using dedicated signaling. SIB1 may be transmitted using a physical downlink shared channel (PDSCH). OSI may similarly be transmitted using a PDSCH, for example. If one or more beamformed transmissions are transmitted in a cell provided by base station 5, only some of the SIs (such as some SIBs) may be transmitted using specific beams or using specific transmission / reception points (TRPs).

[0048] Timing Advance (TA) UE3 may provide timing advance (TA) information in, for example, the "targetTA" information element, which contains the timing offset (N) between the uplink radio frame and the downlink radio frame for UE3 to use a timing advance group (TAG) (for example, primary TAG (PTAG) in the case of a handover, or primary secondary TAG (PSTAG) in the case of a secondary cell group (SCG) change) as the target.TA This refers to a timing adjustment indicator that shows the value of ). A TAG is a group of cells that share the same uplink transmit timing (e.g., a group of cells provided by the same RAN node). A time alignment timer (e.g., timeAlignmentTimer) can be configured to define the maximum time after UE3 receives TA information (e.g., TA commands) from base station 5, during which time UE3 is considered synchronized for uplink transmits in the cell. In other words, UE3 is considered synchronized for UL transmits in a particular cell while the corresponding time alignment timer is operating. Once the time alignment timer expires (because UE3 has not received TA information from base station 5 while the timer is operating), UE3 can be determined to no longer be synchronized for uplink transmits in the corresponding cell. Synchronization can be restored, for example, using a random access procedure. It will be understood that some cells may not require UE3 to provide TA information in order to achieve synchronization. For example, in the case of small cells, the propagation delay of the transmit between UE3 and base station 5 may be negligibly small.

[0049] Each TAG may include at least one serving cell with configured uplinks, and the mapping of each serving cell to the TAG can be configured by RRC. For primary TAGs, UE3 may use PCell as the timing reference, except for shared spectral channel access, which may also use SCell in some cases. For secondary TAGs, UE may use any of the TAG's activated SCells as the timing reference cell.

[0050] Timing advance is used to control the UL transmit timing of UE3 (e.g., PUSCH and PUCCH) and improve the synchronization of communication between UE3 and base station 5. UE3s farther from base station 5 may be configured to use a larger TA value to compensate for the propagation delay of radio signals between UE3 and base station 5. The TA value corresponds to the time difference between the beginning of the uplink radio frame transmitted by UE3 and the corresponding downlink radio frame received by UE3. The TA value is twice the propagation delay between UE3 and base station 5 plus an additional time offset (N TA It can be configured to be equal to (or approximately equal to) the sum of (an additional time offset corresponding to) the TA value. In other words, the TA value is TA = (2 × propagation delay) + N TA ×T c It may also be the case that, in the formula, N TA T is equal to 1 / (480000 × 4096) seconds. c It has units of N, used by UE3. TA The value of TA may be broadcast in the cell of base station 5 (e.g., using SIB1) or transmitted to UE3 using dedicated signaling. It will be understood that the mobility of UE3, whether closer to or further from base station 5, affects the propagation delay of signals transmitted between UE3 and base station 5, so that the TA may need to be updated as UE3 moves around the cell. The TA value may be updated by transmitting a change in the TA value to UE3. For example, base station 5 may transmit an instruction to decrease by 17 μs. Alternatively, for example, the absolute value of the new TA value can be explicitly transmitted to UE3. Base station 5 may be configured to determine the new value of TA based on the uplink transmission received from UE3. Timing advance updates can be signaled to UE3 by base station 5 using MAC CE commands.

[0051] Lower-tier trigger mobility Figure 3 shows examples of intra-CU handovers and inter-CU handovers. An inter-DU intra-CU handover is indicated by arrow A. In an inter-DU intra-CU handover, UE3 is handed over from the first DU 5b-1 to the second DU 5b-2, but CU 5c-1 remains unchanged. An inter-DU inter-CU handover is indicated by arrow B. In an inter-DU inter-CU handover, UE3's DU 5b changes from DU 5b-2 to DU 5b-3, and CU 5c changes from CU 5c-1 to CU 5c-2. It will be understood that intra-DU intra-CU handovers are also possible, where both the DU and CU remain unchanged (for example, a handover of UE3 to another cell provided by the same DU 5b and CU 5c).

[0052] Changes in service-providing cells may be triggered by layer 3 (L3) measurements and can be achieved using radio resource control (RRC) signaling. However, this process involves resetting layer 1 (L1) and layer 2 (L2), resulting in longer latency, greater overhead, and longer downtime. For inter-cell mobility, the UE may need to perform reconfiguration and downlink / uplink (DL / UL) synchronization toward the target cell. Lower-layer based (L1 or L2) handovers may be used to enable more efficient handovers. Advantageously, the methods and apparatus of this disclosure enable UE3, DU 5b, and CU 5c to be configured to perform an inter-CU LTM procedure, in which UE3 can switch between pre-configured candidate lower-layer triggered mobility (LTM) cells based on the content of lower-layer (L1 and / or L2) measurement reports (e.g., without potentially requiring RRC reconfiguration). Therefore, as UE3 moves around among pre-configured candidate LTM cells, it can perform fast cell switching in some cases without RRC reconfiguration.

[0053] Initial data transfer The initial data transfer can be used for Dual Active Protocol Stack (DAPS) handover. In the initial data transfer, the source (R)AN node 5 provides the target (R)AN node 5 with an initial status transfer indicating the COUNT value of the first PDCP SDU, and then an initial data transfer for the DL PDCP SDU with the assigned sequence number can be performed. Multiple initial status transfer messages can be sent from the source (R)AN node 5 to the target (R)AN node 5. The target (R)AN node 5 is configured to send the received PDCP SDU having a COUNT value greater than the transmitted COUNT to the UE3. The initial data transfer can also be used as part of the CU - to - CU LTM method.

[0054] Security handling for UE mobility Figure 4 shows an example of the key handling used for the handover of UE3. "NH" shown in Figure 4 is the next - hop parameter. NH is a key derived by the mobile equipment (ME or UE) 3 and the AMF10 - 1 to provide forward security. K SEAF (not shown) is K AUSF (K AUSF is an anchor key derived by the ME and the Authentication Server Function (AUSF) from the primary authentication procedure that can be stored in the AUSF). K SEAF is provided by the AUSF to the Security Anchor Function (SEAF) in the serving network. K AMF is K SEAF is a key derived by the ME and the SEAF from K AMF is further derived by the ME and the source AMF10 - 1 when performing horizontal key derivation. K gNB is K AMFThese are keys derived from ME and AMF10-1. The security architecture and key hierarchy are described in detail in 3GPP TS 33.501 17.10.0.

[0055] NH and K gNB This is derived by AMF10-1 and UE3 when an access stratum (AS) security context needs to be established between UE3 and (R)AN node 5. As shown in Figure 4, the NH Chaining Counter (NCC) is calculated for each K gNB and associated with the NH parameter. Each K gNB This is associated with the NCC corresponding to the NH value derived from it (associated with NCC=0 to NCC=3). gNB (Figure 4 shows this). In the initial settings, K gNB This uses the non-access tier uplink count value (NAS uplink COUNT) to determine K AMF It is directly derived from and associated with a virtual NH parameter where NCC=0, as shown in Figure 4.

[0056] UE3 and (R)AN node 5 are K gNB Use to ensure communication between UE3 and (R)AN node 5. In the case of handover, K is used between UE3 and target (R)AN node 5. gNB is, K NG-RAN * is currently active K gNB Alternatively, it can be derived from one of the NH parameters. K NG-RAN * is currently active K gNB When derived from, this is called a horizontal key derivation, and the derived K in Figure 4 gNB Each horizontal row is shown. K NG-RAN When * is derived from an NH parameter, this is called a vertical key derivation.

[0057] New initial K gNB ga K AMFBased on the calculation, AMF10-1 is serving a new K message to base station 5 to correct the security context at base station 5. gNB Send. The NCC value of 0 is the new K gNB It is associated with this. Then, base station 5 and UE3 are K for handover. NG-RAN * can be calculated. In the case of an in-CU handover, K gNB This can be maintained in some scenarios, or K NG-RAN * can be modified by deriving K. NG-RAN * is the target Physical Cell ID (PCI), downlink (DL) frequency, and (in the case of horizontal key derivation) the currently active K gNB Alternatively, (in the case of vertical key derivation) it is derived using either NH. Source (R) AN node 5 is {K NG-RAN *, the NCC pair is sent to Target(R)AN Node 5, and Target(R)AN Node 5 uses K for secure communication between UE3 and Target(R)AN Node 5. NG-RAN Use *.

[0058] In the case of selective secondary cell group (selective SCG) security, a secondary node (SN) counter may be used for fresh key derivation and SCG activation. The network may provide the SN counter value to UE3 for each SN, and UE3 will then... The UE3 may be configured to store the SN counter value along with the Conditional PSCell Change (CPC). The UE3 then stores the unused SN counter value, which is pre-supplied by the network, along with K gNB K is the key used for the double connection, which is used to derive further RRC and user plane keys used between UE3 and SN. SN This can be derived. UE3 is configured to change the SN counter value each time the SN is changed.

[0059] Key update procedure for CU handover Figure 5 shows the key update procedure for inter-CU handover.

[0060] In step S501, source CU 5c-1 sends a handover request to target CU 5c-2 that includes the {KNG-RAN*, NCC} pair.

[0061] In step S502, target CU 5c-2 is NCC and new K gNB Generates.

[0062] In step S503, target CU 5c-2 generates K gNB Send a handover acknowledgment containing a transparent container carrying the NCC value to source CU 5c-1.

[0063] In step S504, source CU 5c-1 sends an RRC reconfiguration message (handover command) to UE3, which includes a transparent container for carrying the NCC.

[0064] In step S505, "UE access to the target DU / CU" is performed using the Random Access (RA) procedure.

[0065] In step S506, UE3 sends an RRC reconfiguration complete message (e.g., RRCReconfigurationComplete) to target CU 5c-2.

[0066] In step S507, target CU 5c-2 sends a route switching request to AMF10-1.

[0067] In step S508a, UE3 and target CU 5c-2 establish a new K for secure communication between UE3 and target CU 5c-2. gNB Start using it. In step 508b, AMF10-1 increases the NCC value and generates fresh NH parameters.

[0068] In step S509, AMF10-1 sends a route switching acknowledgment containing a new {NH,NCC} pair to target CU 5c-2.

[0069] In step S510, target CU 5c-2 stores a new {NCC, NH} pair for the UE3 handover.

[0070] LTM CU inter-DU-based handover Figure 6 shows the method of inter-DU-based LTM within a CU.

[0071] In step S601, UE3 sends an L3 measurement report to source DU 5b-1 based on the measurement configuration. The measurement report is forwarded by source DU 5b-1 to CU 5c. In step S602, CU 5c sends a UE context setup request message to target DU 5b-2, and in step S603, target DU 5b-2 sends a UE context setup response to CU 5c, which includes the cell ID and cell radio network temporary identifier (C-RNTI).

[0072] In step S604, CU 5c determines a candidate set of UE3 for LTM, and in step S605, CU 5c sends an RRC reconfiguration message to UE3 including the LTM candidate configuration and the new C-RNTI. In step S606, UE3 sends an RRC Reconfiguration Complete message to CU 5c.

[0073] In step 607, UE3 sends an L1 measurement report for LTM to source DU 5b-1. In step S608, source DU 5b-1 makes an LTM handover decision based on the L1 measurement report received from UE3 and determines that an LTM handover will occur.

[0074] In step S609, source DU 5b-1 sends an LTM command carried by the MAC control element (MAC CE) to UE3. In step S610, UE3 performs access to target DU 5b-2 via a random access procedure. Target DU 5b-2 can identify UE3 via the C-RNTI or RA preamble sent by UE3 during the random access procedure. In the optional step S611, target DU sends an access success message to CU 5c.

[0075] LTM signaling Figure 7 shows the signaling flow for LTM. As shown in Figure 7, this method includes an LTM preparation (or "pre-configuration") phase, an initial synchronization phase, an LTM execution phase, and an LTM completion phase.

[0076] Pre-configuration At the start of the LTM preparation phase, UE3 is in an RRC connected state, and in step S701, UE3 transmits an L3 measurement report to base station 5 based on the measurement configuration.

[0077] In step S702, a candidate set for UE3 is prepared. In step S703, the base station sends an RRC reconfiguration message to UE3 that includes the LTM candidate configuration. UE3 stores the LTM candidate cell configuration. In step S704, UE3 sends an RRC reconfiguration complete message to base station 5.

[0078] Initial synchronization In steps S705a and S705b, UE3 performs L1 measurements and reports on reference signals (e.g., SSB or CSI-RS) corresponding to inter-cell beams, based on the configuration from the network. Based on the L1 measurement report, the network may activate several transmission configuration information (TCI) states where the physical cell ID (PCI) is quasi-co-located (QCL-ed) with a cell different from the serving cell. UE3 optionally performs DL and UL synchronization for these cells.

[0079] LTM execution and LTM completion In step S706, UE3 sends an L1 measurement report to base station 5 reporting one or more measurements performed by UE3 with respect to the configured candidate cell. In step S707, base station 5 determines, based on the L1 measurement report received from UE3, that an LTM handover should be performed, and in step S708, sends a corresponding cell switching command (including MAC CE) to UE3. The cell switching command indicates the LTM candidate cell configuration prepared by base station 5, and UE3 switches to the target cell according to the cell switching command. In step S709, UE3 detaches from the source cell and applies the configuration for the target cell. In step S710, if a valid timing advance (TA) value is not available, UE3 performs RACH toward the target cell. Alternatively, UE3 may skip the RA procedure, which may be referred to as RACH-less LTM.

[0080] In step S711, the LTM handover is complete and UE3 can communicate through the target cell. UE3 completes the LTM cell switching procedure by sending an RRCReconfigurationComplete message to the target cell. If the UE performed a random access procedure in step 710, UE3 considers the LTM execution to be successfully completed when the random access procedure is successfully completed. In the case of RACH-less LTM, UE3 considers the LTM execution to be successfully completed when it determines that the network has successfully received the first UL data.

[0081] Figure 8 shows a further signaling flow of inter-DU CU intra-LTM, illustrating the transmissions exchanged between UE3, source DU 5b-1, target DU 5b-2, and CU 5c. This method can be used when UE3 moves from one DU 5b-1 to another DU 5b-2 that has the same CU 5c.

[0082] In step S801, UE3 sends a measurement report message to source DU 5b-1 containing L3 measurement results, including measurements of neighboring cells. Source DU 5b-1 is configured to send a UL RRC message forwarding message to CU 5c, which forwards the received measurement report.

[0083] In step S802, CU 5c decides to initiate the LTM configuration.

[0084] In step S803, CU 5c sends a UE context setting request message containing one target candidate cell ID to (candidate) target DU 5b-2. In step S804, target DU 5b-2 sends a UE context setting response message to CU 5c containing the generated lower-layer RRC configuration for the accepted candidate target cell.

[0085] In step S805, CU 5c sends a DL RRC message forwarding message containing the generated RRC reconfiguration message having an LTM configuration to source DU 5b-1.

[0086] In step S806, source DU 5b-1 forwards the RRC reconstruction message to UE3. In step S807, UE3 sends an RRC reconstruction complete message to source DU 5b-1. In step S808, source DU 5b-1 forwards the RRC reconstruction complete message to CU 5c using the UL RRC message forwarding message.

[0087] In step S809, UE3 sends the lower layer measurement results to source DU 5b-1, and in step S810, source DU 5b-1 decides to perform LTM on the candidate target cell. In step S811, source DU 5b-1 sends the LTM command to UE3.

[0088] In step S812, source DU 5b-1 sends an LTM cell change notification message containing the target cell ID to CU 5c to indicate to UE3 that an LTM command has been initiated.

[0089] In step S813, target DU 5b-2 detects access to UE3, and in step S814, target DU 5b-2 sends an access success message containing the target cell ID to CU 5b.

[0090] In the optional step S815, CU 5c sends a UE context release command message to source DU 5b-1 to release the resources of the prepared cell, and in the optional step S816, source DU 5b01 sends a UE context release complete message to CU 5c.

[0091] Inter-CU based LTM A method and apparatus for inter-CU-based LTM will be described below with reference to Figures 9-12. Advantageously, this method enables LTM in the case of inter-CU handover and, beneficially, reduces the latency of inter-CU handover.

[0092] Inter-CU based LTM signaling Figure 9 illustrates a CU-based LTM method. Advantageously, this method includes signaling (e.g., Xn signaling) for the configuration of inter-CU candidate cells during LTM preparation, enabling LTM to be used for inter-CU handover.

[0093] In step S901, the measurement configuration and reporting are performed between UE3, source DU 5b-1, and source CU 5c-1. UE3 is configured to send a measurement report message (e.g., measurement report) containing L3 measurement results to source DU 5b-1. Advantageously, the measurement report message includes measurements of neighboring cells between CUs. Source DU 5b-1 forwards the measurement report from UE3 to source CU 5c-1 by sending a UL RRC message forwarding message to source CU 5c-1.

[0094] In step S902, source CU 5c-1 performs LTM candidate initial preparation to prepare the candidate cell set for UE3.

[0095] In step S903, source CU 5c-1 sends a handover request message to target CU 5c-2, as described above, for example, with reference to step S501 in Figure 5. However, advantageously, the handover request message additionally includes a new LTM handover readiness request IE. The LTM handover readiness request IE includes the following sub-IEs: - Inter-CU LTM instruction subIE indicating inter-CU LTM handover - A list of reference signal configurations that carry all reference signal configurations of candidate LTM cells hosted by source DU 5b-1 for LTM measurement. - LTM measurement report configuration for source DU 5b-1 cells - LTM RACH configuration that supports initial TA acquisition for source DU 5b-1 cells

[0096] In the case of inter-CU LTM, cells hosted by source DU 5b-1 or cells hosted by other DU 5b of source CU 5c-1 can also be assumed to be potential LTM candidate cells. Therefore, for example, each candidate DU 5b-2 needs to know the reference signal configuration of each candidate cell in order to provide the LTM candidate configuration. This is because, in step S903, when source CU 5c-1 sends the LTM handover readiness request IE in the handover request message to target CU 5c-2, it includes a reference signal configuration that carries the reference signal configuration of the candidate LTM cell hosted by source DU 5b-1.

[0097] If a new LTM handover readiness request IE is included in the handover request message in step S903, the target(R)AN node shall consider (determine) that the request is configured to initiate preparation for an LTM handover on the corresponding DU 5b-2 hosted on the CU 5c-2 node in the segmented RAN architecture. The target(R)AN node shall also include a new LTM handover readiness response IE in the handover request acknowledgment message sent in step S906.

[0098] In step S904, target CU 5c-2 sends a UE context setup request message to target DU 5b-2. Target (candidate) DU 5b-2 prepares the LTM configuration for UE3 and prepares the context for UE3. In step S905, target DU 5b-2 sends a UE context setup response message containing the LTM configuration to target CU 5c-2. The UE context setup response message may include the target cell ID and the target cell radio network temporary identifier (C-RNTI). Steps S904 and S905 are the same as steps S602 and S603 described above with reference to Figure 6 in the case of an intra-CU handover. However, advantageously, in the case of the inter-CU configuration in Figure 9, in order to assist target DU 5b-2 in preparing the LTM configuration, CU 5c-2 beneficially provides each target DU 5b-2 with all of its LTM configurations in step S904 (including the LTM reference signal configuration received from source CU 5c-1 in step S903 for inter-CU LTM preparation, and optionally, the LTM configuration of DU 5b-2 hosted by target CU 5c-2 for intra-CU LTM as supported by 3GPP Rel-18). Based on the information received from target CU 5c-2 in step S904, candidate DU 5b-2 generates a reference signal configuration in step S905 and transmits it to target CU 5c-2.

[0099] Before sending the handover request acknowledgment message in step S906, target CU 5c-2 receives all of the UE context setting responses (in step S905). In step S906, target CU 5c-2 sends the handover request acknowledgment message to source CU 5c-1. Target CU 5c-2 advantageously includes the prepared LTM configuration (e.g., reference signal configuration) in a new handover ready response IE contained in the handover request acknowledgment message via the Xn interface. The new LTM handover ready response includes the following sub-IEs: -DU 5b: Inter-CU LTM Acceptance Indicator subIE indicating acceptance of an inter-CU LTM handover. If accepted, the following IEs are also included: - For LTM measurements, a list of reference signal (RS) configurations including all RS configurations of candidate LTM cells hosted by target DU 5b-2 of target CU 5c-2. - LTM measurement reporting configuration for cells hosted by target DU 5b-2 of target CU 5c-2

[0100] In case of failure (not accepted), the cause value is included for each DU 5b, for each failure case.

[0101] In step S907, source CU 5c-1 prepares for the LTM handover by sending an RRC reconfiguration message containing a handover command to UE3. Source CU 5c-1 transparently transmits the LTM configuration received from target CU 5c-2 to UE3. Step S907 is similar to step S605 in Figure 6 above for the case within a CU, but in step S907, the message advantageously also includes the inter-CU cell configuration for the LTM.

[0102] Prior to step S907, the target CU 5c-2 may optionally send the LTM configuration of the hosted DU 5b-2 (not shown in Figure 9) to the source CU 5c-1, and the source CU 5c-1 may send the received LTM configuration to the hosted DU 5b-1 to assist the DU 5b-1 hosted by the source CU 5c-1 in preparing its LTM configuration (for example, to include the RS configuration of other candidate DU 5b-2 hosted by the target CU 5c-2).

[0103] In step S908, UE3 acknowledges receipt of the RRC reconstruction message in step S907 by sending an RRC reconstruction complete message to source CU 5c-1.

[0104] In step S909, the LTM candidate is determined in source CU 5c-1.

[0105] In step S910, UE3 transmits the L1 measurement results to source DU 5b-1. The L1 measurement is based on the LTM configuration transmitted in step S907.

[0106] After step S910, an initial TA acquisition procedure may be performed (not shown in Figure 9) to support inter-CU LTM. In this case, UE3 initiates a random access (RA) procedure with candidate DU 5b-2 hosted by target CU 5c-2. In the first option, the source cell is responsible for sending the timing advance (TA) in the random access response (RAR). In this case, candidate DU 5b-2 at target CU 5c-2 transfers the calculated TA value to target CU 5c-2, which then transfers the TA value to source CU 5c-1. Source CU 5c-1 then transfers the TA value to source DU 5b-1 before cell switching. However, this first option, which transfers the TA value from target DU 5b-2 to source DU 5b-1 via target and source CU 5c, is relatively time-consuming, and UE3 may not receive the TA value before cell switching occurs. In the second option, the LTM candidate cell is used to transmit the TA in the RAR. UE3 may be configured to perform the reception of the TA in the RAR from the target cell within the configured TA reception GAP (measurement period). If UE3 performs TA acquisition from multiple LTM candidate cells before LTM cell switching, UE3 may be configured to stop communication with the source cell within multiple TA reception GAPs, as it receives the TA in the RAR one by one from the LTM candidate cells. However, in the second option, receiving the TA via the target cell can result in a relatively large reception interruption at the source cell, so the first option may be preferred in some scenarios.

[0107] In step S911, similar to step S608 in Figure 6, the LTM handover decision is performed at source DU 5b-1.

[0108] In step S912, source DU 5b-1 transmits an LTM command to be carried by MAC CE. MAC CE enables UE3 to access the target cell via an inter-CU LTM handover. MAC CE may include an inter-CU LTM handover indicator to show UE3 that the type of handover is an inter-CU LTM handover.

[0109] In step S912a, source CU 5c-1 receives an LTM cell change notification from source DU 5b-1 (before the LTE cell switch is transmitted to UE3). This F1-based LTM cell change notification may reuse the message specified in the case of an intra-CU LTM handover. However, advantageously, the transmission in step S912a may include new parameters indicating that the handover is an inter-CU LTM handover.

[0110] In step S912b, source CU 5c-1 sends an LTM handover notification to target DU 5b-2 using an LTM cell change notification via a new Xn message. In step S912c, source CU 5c-1 begins notifying target CU 5c-1 via one or more legacy initial status transfer messages, and can then perform the initial data transfer to target CU 5c-2 for the LTM handover.

[0111] In step S912c, target CU 5c-2 sends an LTM handover notification to target DU 5b-2 using an LTM cell change notification, which target DU 5b-2 can then use to prepare to accept access by UE3.

[0112] In step S913, UE3 accesses target DU 5b-2 as described above, referring to step S610 in Figure 6 in the case of an LTM within a CU.

[0113] In the case of a non-LTM handover, handover completion is marked by the receipt of an RRC reconfiguration completion message at target(R)AN node 5, and target(R)AN node 5 exchanges data transmission status with source(R)AN node 5. However, in the case of LTM, (since RRC messages are not lower-layer messages) no RRC reconfiguration completion message is sent. If LTM is running on a segmented RAN architecture, when target DU 5b-2 decodes a random access message from UE3, target DU 5b-2 sends an access success message to target CU 5c-2 in step S914 indicating that the handover is complete. However, to support inter-CU LTM, in step S915, the completion of the LTM is also advantageously notified to source CU 5c-1 by target CU 5c-2. The handover success message sent in step S915 advantageously includes a new parameter indicating that the handover success is an inter-CU LTM handover success (as opposed to an intra-CU LTM handover success). Alternatively, instead of including an explicit indication that the handover success is an inter-CU LTM handover success, source CU 5c-2 may determine that the handover success is an inter-CU LTM handover success based on a handover success message received from another CU 5c-2. Advantageously, in step S915, the receipt of an access success message from target DU 5b-2 at target CU 5c-2 can be used to trigger the transmission of a handover success message via the Xn interface. Upon receiving the handover success message, source CU 5c-1 sends a PDCP sequence number status (SN status) to target CU 5c-2. In other words, the handover success message can be used to trigger the transmission of the SN status from source CU 5c-1 to target CU 5c-2.

[0114] Security updates The method by which security information is exchanged between network nodes during inter-CU LTM is described below with reference to Figures 10-12. Beneficially, the method and apparatus enable security updates to be supported during inter-CU LTM and enable support for multiple CU preparations having security key information.

[0115] As described above with reference to Figures 4 and 5, in legacy base station handover, source base station 5 sends a handover request (step S501 in Figure 5) via {K NG-RAN *, the NCC pair is provided to the target base station 5, and the target base station 5 generates a new key (K) based on this security information pair. gNB ) is generated. The new key and NCC are then sent to the source base station 5 using a handover request acknowledgment message (step S503 in Figure 5), and the security information is then transparently sent by the source base station 5 to the UE3 via the RRC reconfiguration message through the Uu interface (step S504 in Figure 5). Two advantageous options for providing the updated security information to the UE3 in the case of an inter-CU LTM handover are described below.

[0116] Figure 10 shows a CU-based LTM method illustrating the transmission of security parameters and security keys using the first option. The method in Figure 10 is generally the same as the method in Figure 9, and the corresponding steps will not be described again here, but Figure 10 further illustrates the transmission of security parameters and security keys. In this option, security information is provided in steps S1006 (a handover request acknowledgment message is sent from target CU 5c-2 to source CU 5c-1) and S1007 (an RRC reconfiguration message is sent from source CU 5c-1 to UE3). Advantageously, in the case of a CU-to-CU handover, different candidate CUs 5c may generate different security information, so UE3 is configured to store multiple security contexts.

[0117] In step S1003, source CU 5c-1 sends a handover request message {K NG-RAN *, the NCC pair is provided to target CU 5c-2. In step S1006, target CU 5c-2 receives security information {K NG-RAN *, Based on the NCC pair, a new key(K gNB ) is generated, and then the new key and NCC are sent to source CU 5c-1 in a handover request acknowledgment message.

[0118] In step S1007, security information (security context) is transmitted transparently from source CU 5c-1 to UE3 in an RRC reconfiguration message sent through the Uu interface. Advantageously, the LTM CU index is also sent to UE3 in step S1007, enabling UE3 to associate the security context with the receiving CU 5c. In other words, since each CU 5c has an independent security context, the LTM CU index can be used by UE3 to number the security contexts and associate them with a specific CU 5c. In step S1012, the LTM cell switching MAC CE also advantageously includes the LTM CU index. Thus, beneficially, when UE3 receives an LTM cell switching command, UE3 can use the LTM CU index to identify the security context to apply.

[0119] Figure 11 shows a CU-based LTM method illustrating the transmission of security parameters and security keys using a second option. The method in Figure 11 is generally the same as the method in Figure 9, and the corresponding steps will not be described again here, but Figure 11 further illustrates the transmission of security parameters and security information. In the example shown in Figure 11, the updated security context is sent to UE3 using MAC CE in the LTM cell switching command at step S1113 (rather than the RRC reconfiguration message as in the example in Figure 10). Advantageously, since the updated security context is sent to UE3 in a message after the LTM handover method, it is less likely that the security context is outdated (e.g., invalid).

[0120] As shown in Figure 11, a new step S1112 is introduced for CU-DU coordination via the F1 interface. During this step, source CU 5c-1 provides security information of UE3 to source DU 5b-1 to enable support for inter-CU LTM handover.

[0121] In step S1113, updated security information is provided to UE3. The new security information IE is included in MAC CE. After step S113, source DU 5b-1 notifies source CU 5c-1 of the updated security context using a new inter-CU LTM instruction via the LTM cell change notification in step S1113a. Source CU 5c-1 then sends the updated security information to target CU 5c-2 via a new Xn LTM cell change notification message in step S1113b. The Xn LTM cell change notification message helps target CU 5c-2 prepare the security context and PDCP establishment for UE3.

[0122] The updated security information sent to UE3 in step S1113 and to target CU 5c-2 in step S1113b may include one or more of the following IEs: -Key NG-RAN Star (See Figure 4 and see the K as described above) NG-RAN *) - Next-hop chain count (NCC as described above, see Figure 4) -LTM CU count (count of the number of CU 5c involved in inter-CU LTM - multiple CU-based LTMs are described later in Figure 12).

[0123] In a further alternative, if an LTM cell switchover is decided by source DU 5b-1, source DU 5b-1 sends an LTM notification to source CU 5c-1, which then sends updated security information via an RRC message to UE3 to assist UE3 in proceeding with the LTM cell switchover to a target cell hosted by a different CU.

[0124] Security updates for multiple CU-based LTMs Figure 12 shows how to perform security updates for multiple CU-based LTMs.

[0125] In step S1201, the measurement configuration and reporting used to trigger the inter-CU LTM handover readiness decision are performed, as described above with reference to step S901 in Figure 9.

[0126] In step S1202, initial preparation of LTM candidates is performed and, once source CU 5c-1 decides that multiple CU LTM procedures will be performed, in step S1203, source CU 5c-1 sends a new "LTM key request" to AMF10-1 via the NG interface. The LTM key request includes an IE indicating that source CU 5c-1 is requesting keys for several CU 5c. Thus, advantageously, source CU 5c-1 can request several {NH,NCC} pairs for multiple CU 5c.

[0127] In step S1204, AMF10-1 assigns {NH, NCC} pairs to LTM handovers involving multiple CUs, and in step S1205, sends a list of {NH, NCC} pairs to source CU 5c-1 in a new "Key Response to LTM" message via the NG interface. In step S1205, AMF10-1 may support multiple CU-based LTMs by replacing the NCC with an LTM CU counter for security key updates. In this case, the LTM fresh key derivation is performed at target CU 5c-2. gNB and can be based on the LTM CU counter. For example, if four CUs 5c are included in the inter-CU LTM, the LTM CU counters could be K0, K1, K2, or K3 (source CU 5c-1 is also counted). During LTM preparation, source CU 5c-1 is the LTM CU counter value for each cell (under different CUs 5c) K gNB Provided together, UE3 stores the information as a security context to be used after accessing the target cell. The LTM CU counter can be sent to UE3 with the LTM cell switching command. During the LTM configuration preparation in step S1202, source CU 5c-1 sends K to each candidate CU 5c participating in the inter-CU LTM handover. gNB And an LTM CU counter can be provided.

[0128] Following the handover preparation in step S1206, the method proceeds as described above with reference to Figure 9 (for example, steps S910 to S915 can be performed). However, source CU 5c-1 can advantageously prepare LTM handovers for multiple CUs simultaneously based on the {NH, NCC} pairs received from AMF10-1 in step S1205.

[0129] User equipment Figure 13 is a schematic block diagram showing the main components of UE3 as shown in Figure 1.

[0130] As shown in the figure, UE3 has a transceiver circuit 310 capable of transmitting and receiving signals to and from a base station 5 via one or more antennas 330 (including, for example, one or more antenna elements). UE3 has a controller 370 that controls the operation of UE3. The controller 370 is associated with memory 390 and coupled to the transceiver circuit 310. Although not necessarily required for its operation, UE3 can, of course, have all the usual features of a conventional UE3 (such as a user interface 350, such as a touchscreen / keypad / microphone / speaker, to enable direct user control and interaction with the user), which can be provided, as appropriate, by one or any combination of hardware, software, and firmware. The software may be pre-installed in memory 390 and / or downloaded, for example, via communication system 1 or from a removable data storage device (RMD).

[0131] In this example, the controller 370 is configured to control the overall operation of the UE3 by program instructions or software instructions stored in memory 390. As shown in the figure, these software instructions include, among other things, the operating system 410, the communications control module 430, and the L1 / L2 mobility module 450.

[0132] The communication control module 430 is operable to control communication between the UE3 and one or more service base stations 5 (and other communication devices connected to the base station 5, such as additional UEs and / or core network nodes). The communication control module 430 is configured to handle uplink communication in general via associated uplink channels (e.g., via the physical uplink control channel (PUCCH), random access channel (RACH), and / or physical uplink shared channel (PUSCH)), including both dynamic and quasi-static signaling (e.g., such as SRS). The communication control module 430 is also configured to handle the reception of downlink communication in general via associated downlink channels (e.g., via the physical downlink control channel (PDCCH) and / or physical downlink shared channel (PDSCH)), including both dynamic and quasi-static signaling (e.g., such as CSI-RS). The communication control module 430 is responsible for, for example, determining where to monitor downlink control information (such as the locations of CSS / USS, CORESET, and associated PDCCH candidates to be monitored), determining resources used by UE3 for transmitting / receiving UL / DL communications (including interleaved resources and resources subject to frequency hopping), managing frequency hopping on the UE side, determining how slots / symbols are configured (for example, for UL, DL, or SBFD communications), determining which one or more bandwidth portions are configured for UE3, determining how uplink transmissions should be encoded, and appropriately applying any SBFD-specific communication configurations. The communication control module 430 may be configured to control communications in any of the ways described above (for example, to transmit measurement reports in any of the ways described above).

[0133] The L1 / L2 mobility module 450 is responsible for performing control of L1 / L2 mobility. For example, the L1 / L2 mobility module 450 may be configured to perform one or more measurements of L1 / L2 mobility or to select candidate cells for handover. It will be understood that the L1 / L2 mobility module 450 may be configured to perform control in any of the aforementioned L1 / L2 mobility methods.

[0134] RAN (distributed) Figure 14 is a simplified block diagram showing the main components of a distributed RAN, including a distributed base station, for implementation in the system shown in Figure 1.

[0135] As shown in the figure, the RAN includes a central unit 5c and distributed units 5b (however, it may also include other DUs as described above). Each unit 5c, 5b includes its respective transceiver circuits 51c, 51b.

[0136] The transceiver circuit 51b of the distributed unit 5b is operable to transmit signals to UE3 via the air interface 53b and one or more antennas and to receive signals from UE3, and is also operable to transmit signals to the central unit 5c via the distributed unit side of an interface, for example, the F1 interface (which may be provided via a satellite radio interface) and to receive signals from the central unit 5c.

[0137] The transceiver circuit 51c of the central unit 5c is operable to transmit signals to and receive signals from the functions of the core network 7 and / or other RANs via the network interface 55c. The network interface typically includes N2 and / or N3 interfaces for communicating with the core network and base station-to-base station interfaces (e.g., Xn) for communicating with other RANs. The transceiver circuit 51c of the central unit 5c is also operable to transmit signals to and receive signals from one or more distributed units 5b, such as the central unit side of the provided F1 interface.

[0138] Each unit 5c, 5b includes its respective controller 57c, 57b, which controls the operation of the corresponding transceiver circuits 51c, 51b according to the software stored in the respective memories 59c, 59b of the central unit 5c and distributed unit 5b. The software for each unit may be pre-installed in the memories 59c, 59b and / or downloaded, for example, via the communication system 1 or from a removable data storage device (RMD). The software for each unit includes, among other things, its respective operating systems 61c, 61b, its respective communication control modules 63c, 63b, and its respective L1 / L2 mobility modules 65c, 65b.

[0139] Each communication control module 63c, 63b is operable to control the communication of the corresponding units 5c, 5b, including communication from one unit to the other. The communication control module 63b of the distributed unit 5b controls communication between the distributed unit 5b and the UE3, and the communication control module 63c of the central unit 5c controls communication between the central unit 5c and other network entities connected to the distributed RAN.

[0140] Communication control modules 63c and 63b also control the portions of the uplink and downlink user traffic flow that are handled by the distributed unit 5b and the central unit 5c, respectively, and control the data transmitted to communication devices serviced by the RAN, including, for example, data for managing the operation of UE3. Each communication control module 63c and 63b plays a role in controlling the portions of the uplink communication reception and decoding that are handled by the distributed unit 5b and the central unit 5c, respectively, via the relevant uplink channels (e.g., via the physical uplink control channel (PUCCH), random-access channel (RACH), and / or physical uplink shared channel (PUSCH)), including both dynamic and quasi-static signaling (e.g., SRS). Each communication control module 63c, 63b plays a role in controlling the portion of downlink communication transmission handled by the distributed unit 5b and the central unit 5c, respectively, via the associated downlink channel (e.g., via the physical downlink control channel (PDCCH) and / or the physical downlink shared channel (PDSCH)), which includes both dynamic and quasi-static signaling (e.g., CSI-RS, SSB, etc.).

[0141] It will be understood that the communication control modules 63c, 63b may also include several submodules (or "layers") to support specific functions of the corresponding units 5c, 5b. The included modules depend on how the corresponding units 5c, 5b are configured (e.g., the exact CU-DU partitioning). For example, the communication control module 63c of the distributed unit 5b may include a PHY submodule, a MAC submodule, and an RLC submodule, while the communication control module 63c of the central unit 5c may include a PDCP submodule, an SDAP submodule, an IP submodule, an RRC submodule, and so on.

[0142] The L1 / L2 mobility modules 65b and 65c are responsible for executing control of the L1 / L2 mobility procedure. For example, the L1 / L2 mobility modules 65b and 65c may control the transmission of a set of candidate cells to the UE3, or they may control the transmission of instructions for one or more measurements to be performed for L1 / L2 mobility by the UE3. It will be understood that the L1 / L2 mobility modules 65b and 65c may be configured to perform control as part of one of the L1 / L2 mobility methods described later.

[0143] Core network nodes / functions Figure 15 is a block diagram showing the main components of a core network node or function such as AMF, CPF, UPF, SMF, or OAM. As shown in the diagram, the core network function includes a transceiver circuit 710 that is capable of transmitting signals to and receiving signals from other nodes (including UE3, base station 5, and other core network nodes) via the network interface 720. The controller 730 controls the operation of the core network function according to software stored in memory 740. The software may be pre-installed in memory 740 and / or downloaded, for example, via communication system 1 or from a removable data storage device (RMD). The software includes, among other things, an operating system 750 and a communication control module 760.

[0144] The communication control module 760 is responsible for handling (generating / transmitting / receiving) signaling between the core network functions and other nodes such as UE3, base station 5, and other core network nodes.

[0145] The core network node / function also includes an L1 / L2 mobility module 770. It will be understood that the L1 / L2 mobility module 770 may be configured to perform control as part of one of the aforementioned L1 / L2 mobility methods.

[0146] Corrections and replacements As those skilled in the art will understand, several modifications and substitutions can be made to the above examples, but the disclosures therein are still beneficial.

[0147] For example, while specific terms for cellular communication generations (2G, 3G, 4G, 5G, 6G, etc.) may be used to refer to specific communication entities for clarity, it will be understood that the technical features described for a given entity are not limited to devices of that particular communication generation. Technical features can be implemented in any functionally equivalent communication entity, regardless of the differences in the terminology used to refer to them.

[0148] In the above description, the UE and base station are described as having several separate functional components or modules for the sake of ease of understanding. These modules may thus be provided in certain applications, for example, where an existing system is modified to implement the present disclosure, but in other applications, for example, a system designed from the outset with the features of the present invention in mind, these modules may be incorporated into the overall operating system or code, and therefore these modules may not be identified as separate entities.

[0149] In the detailed examples above, several software modules were described. As those skilled in the art will understand, software modules may be provided in compiled or uncompiled form and may be supplied as signals via a computer network or on a recording medium. Furthermore, the functions performed by some or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred because it facilitates the updating of base stations or UEs to update their functions.

[0150] Each controller may include any suitable form of processing circuitry, including (but not limited to) one or more hardware-implemented computer processors, microprocessors, central processing units (CPUs), arithmetic logic units (ALUs), input / output (IO) circuits, internal memory / cache (programs and / or data), processing registers, communication buses (such as control buses, data buses, and / or address buses), direct memory access (DMA) functions, hardware or software-implemented counters, pointers, and / or timers. Various other modifications are obvious to those skilled in the art and will not be described in further detail here.

[0151] In this disclosure, User Equipment (or “UE,” “Mobile Station,” “Mobile Device,” or “Radio Device”) is an entity connected to a network via a radio interface.

[0152] Please note that this disclosure is not limited to dedicated communication devices, but can be applied to any device having communication functions as described in the following paragraphs.

[0153] The terms “User Equipment” or “UE” (as used by 3GPP), “Mobile Station,” “Mobile Device,” and “Radio Device” are generally intended to be synonymous with each other and include standalone mobile stations such as terminals, cell phones, smartphones, tablets, cellular IoT devices, IoT devices, and machines. The terms “Mobile Station” and “Mobile Device” will be understood to also include devices that remain stationary for extended periods.

[0154] UE may be items of equipment for production or manufacturing and / or items of energy-related machinery, such as equipment or machinery (for example, boilers, engines, turbines, solar panels, wind turbines, hydroelectric generators, thermal generators, nuclear generators, batteries, nuclear systems and / or related equipment, heavy electrical machinery, pumps including vacuum pumps, compressors, fans, blowers, hydraulic equipment, pneumatic equipment, metalworking machinery, manipulators, robots and / or their application systems, tools, molds or dies, rolls, conveying equipment, elevators, material handling equipment, textile machinery, sewing machinery, printing and / or related machinery, paper conversion machinery, chemical machinery, mining machinery and / or construction machinery and / or related equipment, machinery and / or equipment for agriculture, forestry and / or fisheries, safety and / or environmental protection equipment, tractors, precision bearings, chains, gears, power transmission systems, lubrication equipment, valves, pipe fittings and / or application systems for any of the aforementioned equipment or machinery, etc.).

[0155] UE may be an item of transport equipment, for example (such as transport equipment such as railway cars, automobiles, motorcycles, bicycles, trains, buses, carts, rickshaws, ships and other vessels, aircraft, rockets, satellites, drones, balloons, etc.). UE may also be an item of information and communication equipment, for example (such as information and communication equipment such as electronic computers and related equipment, communication and related equipment, electronic components, etc.).

[0156] UE may include, for example, refrigerators, refrigerator applications, commercial and / or service industry equipment items, vending machines, automated service machines, office machines or equipment, and household appliances and electronic devices (such as audio equipment, video equipment, loudspeakers, radios, televisions, microwave ovens, rice cookers, coffee machines, dishwashers, washing machines, dryers, electronic fans or related equipment, vacuum cleaners, etc.).

[0157] The UE may be an electrical application system or device, for example, such as an X-ray system, particle accelerator, radioisotope equipment, sound wave equipment, electromagnetic application equipment, power application equipment, etc.

[0158] UE may include, for example, electronic lamps, lighting fixtures, measuring instruments, analyzers, testers, or measuring or detecting equipment (such as smoke detectors, human alarm sensors, motion sensors, wireless tags, etc.), watches or clocks, laboratory equipment, optical devices, medical equipment and / or systems, weapons, cutlery items, hand tools, etc.

[0159] The UE may be, for example, a wireless-equipped personal digital assistant or related device (such as a wireless card or module designed to be attached to or inserted into another electronic device, such as a personal computer or electrical measuring instrument).

[0160] The UE may be part of a device or system that uses various wired and / or wireless communication technologies to provide the following applications, services, and solutions related to the Internet of Things (IoT).

[0161] Internet of Things (IoT) devices (or "Things") may comprise appropriate electronics, software, sensors, network connectivity, etc., that enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may comprise automated devices that follow software instructions stored in internal memory. IoT devices may operate without requiring human supervision or interaction with humans. IoT devices may also remain stationary and / or inactive for extended periods. IoT devices may be implemented as part of (generally) stationary equipment. IoT devices may also be incorporated into non-stationary equipment (e.g., vehicles) or attached to animals or people to be monitored / tracked.

[0162] It will be understood that IoT technology can be implemented on any communication device that can connect to a communication network to send and receive data, regardless of whether such communication device is controlled by human input or by software instructions stored in memory.

[0163] It should be understood that IoT devices are sometimes referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices. It should be understood that a UE may support one or more IoT or MTC applications. Some examples of MTC applications are listed in the table below. This list is not exhaustive and is intended to illustrate several examples of machine-type communication applications. [Table 2]

[0164] Applications, services, and solutions may include MVNO (Mobile Virtual Network Operator) services, emergency radio communication systems, PBX (Private Branch eXchange) systems, PHS / digital cordless telecommunications systems, POS (Point of Sale) systems, incoming advertising systems, MBMS (Multimedia Broadcast and Multicast Service), V2X (Vehicle to Everything) systems, train radio systems, location-related services, disaster / emergency radio communication services, community services, video streaming services, femtocell application services, VoLTE (Voice over LTE) services, billing services, wireless on-demand services, roaming services, activity monitoring services, telecommunications carrier / communication network selection services, function restriction services, PoC (Proof of Concept) services, personal information management services, ad hoc network / DTN (Delay Tolerant Networking) services, and others.

[0165] Furthermore, the aforementioned UE categories are merely examples of applications of the technical concepts described in this document. Needless to say, these technical concepts are not limited to the aforementioned UEs and can be modified in various ways.

[0166] Various other variations are obvious to those skilled in the art and will not be described in further detail here.

[0167] For example, all or part of the exemplary embodiments disclosed above may be described, but are not limited to, as follows: (Note 1) A method performed by the first central unit of the first base station, Transmitting first information to the second central unit of the second base station, including the reference signal configuration of a candidate lower-layer triggered mobility (LTM) cell operated by the first distributed unit of the first base station, Receiving second information from the second central unit to each second distributed unit of the second base station indicating whether or not inter-central unit LTM handover is acceptable, Methods that include... (Note 2) The reference signal configuration of the candidate LTM cell operated by the first distributed unit of the first base station, and the reference signal configuration of the candidate LTM cell operated by at least one second distributed unit of the second base station are transmitted to each of the at least one second distributed unit of the second base station to determine whether or not an inter-central unit LTM handover is acceptable. The method described in Appendix 1. (Note 3) The second information includes a reference signal configuration for a candidate LTM cell operated by at least one second distributed unit of the second base station that accepted the central unit inter-LTM handover. The method described in Appendix 1 or 2. (Note 4) Transmitting the reference signal configuration of the candidate LTM cell operated by at least one second distributed unit of the second base station that has accepted the central unit inter-LTM handover to the first distributed unit of the first base station. The method described in Appendix 3, further including the method described in Appendix 3. (Note 5) The second information includes a failure cause value for each failed second distributed unit of the second base station, The method described in any one of the appendices 1 to 4. (Note 6) The first information includes a measurement reporting configuration for an LTM cell operated by a first distributed unit of the first base station, The method described in any one of the appendices 1 to 5. (Note 7) The first information includes an LTM random access channel (RACH) configuration for obtaining timing advance information of an LTM cell operated by a first distributed unit of the first base station, The method described in any one of the appendices 1 to 6. (Note 8) The second information includes a measurement reporting configuration for an LTM cell operated by at least one second distributed unit of the second base station that accepted the inter-central unit LTM handover. The method described in any one of the appendices 1 to 7. (Note 9) The second information includes an LTM random access channel (RACH) configuration for obtaining timing advance information of an LTM cell operated by at least one second distributed unit of the second base station that accepted the inter-central unit LTM handover. The method described in any one of the appendices 1 to 8. (Note 10) Receiving layer 1 (L1) measurement results from user equipment (UE), Prior to the cell switching related to the inter-central unit LTM handover, the procedure is initiated to provide the UE with timing advance information of an LTM cell operated by at least one second distributed unit of the second base station that accepted the inter-central unit LTM handover. The method described in any one of the appendices 1 to 9, further including the method described in any one of appendices 1 to 9. (Note 11) The above procedure, Receiving timing advance information from at least one second distributed unit of the second base station that has accepted the inter-central unit LTM handover, via the second central unit of the second base station, The timing advance information is transferred to the first distributed unit of the first base station, including, The method described in Appendix 10. (Note 12) Each of the aforementioned timing advance information is sent in the LTM cell change notification message. The method described in Appendix 11. (Note 13) The above procedure, The UE stops transmitting between the UEs in order to receive timing advance information from at least one second distributed unit of the second base station that has accepted the inter-central unit LTM handover. including, The method described in Appendix 10. (Note 14) Receiving an LTM cell change notification indicating an LTM handover between central units from the first distributed unit of the first base station, To transmit an LTM cell change notification via the second central unit of the second base station to at least one second distributed unit of the second base station that has accepted the inter-central unit LTM handover, The method described in any one of the appendices 1 to 13, further including the method described in any one of appendices 1 to 13. (Note 15) Receiving information from at least one second distributed unit of the second base station that accepted the inter-central unit LTM handover, via the second central unit of the second base station, indicating that the inter-central unit LTM handover was successful. The method described in Appendix 14, further including the method described in Appendix 14. (Note 16) To transmit security information along with the first information to the second central unit of the second base station, The system receives updated security information corresponding to the security information along with the second information from the second central unit, The method described in any one of the appendices 1 to 15, further including the method described in any one of appendices 1 to 15. (Note 17) Transfer the updated security information to the user equipment (UE). The method described in Appendix 16, further including the method described in Appendix 16. (Note 18) When the UE receives LTM cell switching information, including index information indicating the updated security information, from the first distributed unit of the first base station, the UE applies the updated security information to the central unit inter-LTM handover. The method described in Appendix 17. (Note 19) The updated security information includes information indicating the number of central units involved in the inter-central unit LTM handover, The aforementioned index information corresponds to one of the central units involved in the inter-central unit LTM handover, The method described in Appendix 18. (Note 20) The aforementioned index information is transmitted in the Media Access Control (MAC) Control Element (CE). The method described in Appendix 18 or 19. (Note 21) The updated security information is transmitted in the Radio Resource Control (RRC) reconfiguration message. The method described in any one of the appendices 17 to 20. (Note 22) Transmitting security information to the first distributed unit of the first base station, Receiving updated security information corresponding to the security information from the first distributed unit of the first base station, Transferring the updated security information corresponding to the security information to the second central unit of the second base station, It further includes, The updated security information is transmitted from the first distributed unit of the first base station to the user equipment (UE). The method described in any one of the appendices 1 to 15. (Note 23) The updated security information is transmitted by the Media Access Control (MAC) Control Element (CE). The method described in Appendix 22. (Note 24) Sending a request to the core network node for mobility management for updated security information about multiple central units of the base station, Receiving the updated security information for the multiple central units of the base station from the core network node, The method described in any one of the appendices 1 to 23, further including the method described in any one of the appendices 1 to 23. (Note 25) The updated security information mentioned above is Security key, Next hop chain counter, or Information indicating the number of central units involved in the aforementioned inter-central unit LTM handover, including at least one of the following: The method described in any one of the appendices 16 to 24. (Note 26) The updated security information includes information for each central unit. The method described in any one of the appendices 16 to 25. (Note 27) The first information is transmitted in the handover request message. The method described in any one of the appendices 1 to 26. (Note 28) The second information is transmitted in the handover request acknowledgment message. The method described in any one of the appendices 1 to 27. (Note 29) A method performed by the second central unit of the second base station, Receiving first information from a first central unit of a first base station, including the reference signal configuration of a candidate LTM cell operated by a first distributed unit of the first base station, The first central unit is to transmit second information to each second distributed unit of the second base station indicating whether or not an inter-central unit LTM handover is acceptable. Methods that include... (Note 30) To determine whether an inter-central unit LTM handover is acceptable, the reference signal configuration of the candidate LTM cell operated by the first distributed unit of the first base station and the reference signal configuration of the candidate LTM cell operated by the at least one second distributed unit of the second base station are transmitted to each of the at least one second distributed unit of the second base station. Receiving a response from each of the at least one second distributed unit of the second base station indicating whether the inter-central unit LTM handover is acceptable, The method described in Appendix 29, further including the method described in Appendix 29. (Note 31) A method performed by user equipment (UE), Receiving updated security information from the first central unit of the first base station, Receiving information about the updated security information from the first central unit, Based on the information regarding the updated security information, the updated security information is applied to the lower-layer triggered mobility (LTM) handover between central units from the first base station to the second base station. Methods that include... (Note 32) The information regarding the updated security information is Index information showing at least a portion of the updated security information, or Further updated security information, including at least one of the following: The method described in Appendix 31. (Note 33) The aforementioned support information is transmitted by the Media Access Control (MAC) Control Element (CE). The method described in Appendix 31 or 32. (Note 34) A method performed by core network nodes for mobility management, Receiving a request from the first central unit of the first base station for updated security information about multiple central units of the base station, Transmitting the updated security information for the multiple central units of the base station to the first central unit of the first base station, Methods that include... (Note 35) The first central unit of the first base station, Means for transmitting first information, including the reference signal configuration of a candidate LTM cell operated by the first distributed unit of the first base station, to the second central unit of the second base station, Means for receiving second information from the second central unit to each second distributed unit of the second base station indicating whether or not inter-central unit LTM handover is acceptable, A first central unit equipped with [a certain feature]. (Note 36) The second central unit of the second base station, Means for receiving first information from a first central unit of a first base station, including a reference signal configuration of a candidate LTM cell operated by a first distributed unit of the first base station, The first central unit is provided with means for transmitting to each second distributed unit of the second base station second information indicating whether or not inter-central unit LTM handover is acceptable, A second central unit equipped with [a specific feature]. (Note 37) User equipment (UE), A means for receiving updated security information from the first central unit of the first base station, Means for receiving information about the updated security information from the first central unit, Means for applying the updated security information to a central unit lower-layer triggered mobility (LTM) handover from the first base station to the second base station, based on the information regarding the updated security information, User equipment equipped with these features. (Note 38) A core network node for mobility management, A means for receiving a request from a first central unit of a first base station for updated security information regarding multiple central units of a base station, The first central unit of the first base station is provided with means for transmitting the updated security information for the plurality of central units of the base station, A core network node equipped with these features.

[0168] This application is based on and claims the priority of UK Patent Application No. 2311834.2, filed on 1 August 2023, and its disclosure is incorporated herein by reference in its entirety. [Explanation of Symbols]

[0169] 1. Communication System 3. User equipment 5 base station 5b Distributed Unit (DU) 5c CENTRAL UNIT (CU) 7 Core Network 9 cells 10 Control Plane Functions 11. User Plane Functions 20 External data network 310 Transceiver Circuit 330 Antenna 350 User Interfaces 370 Controller 390 memory 410 Operating Systems 430 Communication control module 450 L1 / L2 Mobility Module 51b Transceiver circuit (DU) 51c Transceiver Circuit (CU) 53b Air Interface 55c Network Interface 57b DU Controller 57c UC Controller 59b DU memory 59c CU memory 61b DU Operating System 61c CU Operating System 63b DU Communication Control Module 63c CU Communication Control Module 65b L1 / L2 Mobility Module 65c L1 / L2 Mobility Module 710 Transceiver Circuit 720 Network Interfaces 730 Controller 740 memory 750 Operating Systems 760 Communication Control Module 770 L1 / L2 Mobility Module

Claims

1. A method performed by the first central unit of the first base station, Transmitting first information to the second central unit of the second base station, including the reference signal configuration of a candidate lower-layer triggered mobility (LTM) cell operated by the first distributed unit of the first base station, The second central unit receives second information from the second central unit, for each second distributed unit of the second base station, indicating whether or not an inter-central unit LTM handover is acceptable. Methods that include...

2. The reference signal configuration of the candidate LTM cell operated by the first distributed unit of the first base station, and the reference signal configuration of the candidate LTM cell operated by at least one second distributed unit of the second base station are transmitted to each of the at least one second distributed unit of the second base station to determine whether an inter-central unit LTM handover is acceptable. The method according to claim 1.

3. The second information includes a reference signal configuration for a candidate LTM cell operated by at least one second distributed unit of the second base station that accepted the inter-central unit LTM handover. The method according to claim 1 or 2.

4. Transmitting the reference signal configuration of the candidate LTM cell operated by at least one second distributed unit of the second base station that has accepted the inter-central unit LTM handover to the first distributed unit of the first base station. The method according to claim 3, further comprising:

5. The second information includes the cause value of the failure for each failed second distributed unit of the second base station, The method according to any one of claims 1 to 4.

6. The first information includes a measurement reporting configuration for an LTM cell operated by the first distributed unit of the first base station, The method according to any one of claims 1 to 5.

7. The first information includes an LTM random access channel (RACH) configuration for obtaining timing advance information of an LTM cell operated by a first distributed unit of the first base station, The method according to any one of claims 1 to 6.

8. The second information includes a measurement reporting configuration for an LTM cell operated by at least one second distributed unit of the second base station that accepted the inter-central unit LTM handover. The method according to any one of claims 1 to 7.

9. The second information includes an LTM random access channel (RACH) configuration for obtaining timing advance information of an LTM cell operated by at least one second distributed unit of the second base station that accepted the inter-central unit LTM handover. The method according to any one of claims 1 to 8.

10. Receiving layer 1 (L1) measurement results from user equipment (UE), Before the cell switching related to the inter-central unit LTM handover, the procedure is initiated to provide the UE with timing advance information of an LTM cell operated by at least one second distributed unit of the second base station that accepted the inter-central unit LTM handover. The method according to any one of claims 1 to 9, further comprising:

11. The above procedure, Receiving timing advance information from at least one second distributed unit of the second base station that has accepted the inter-central unit LTM handover, via the second central unit of the second base station, Transferring the respective timing advance information to the first distributed unit of the first base station, including, The method according to claim 10.

12. Each of the aforementioned timing advance information is sent in the LTM cell change notification message. The method according to claim 11.

13. The above procedure, The UE stops transmitting between UEs in order to receive timing advance information from at least one second distributed unit of the second base station that accepted the inter-central unit LTM handover. including, The method according to claim 10.

14. Receiving an LTM cell change notification indicating an LTM handover between central units from the first distributed unit of the first base station, To transmit an LTM cell change notification via the second central unit of the second base station to at least one second distributed unit of the second base station that has accepted the inter-central unit LTM handover, The method according to any one of claims 1 to 13, further comprising:

15. Receiving information from at least one second distributed unit of the second base station that accepted the inter-central unit LTM handover, via the second central unit of the second base station, indicating that the inter-central unit LTM handover was successful. The method according to claim 14, further comprising:

16. The security information is transmitted to the second central unit of the second base station along with the first information. The second central unit receives updated security information corresponding to the security information along with the second information, The method according to any one of claims 1 to 15, further comprising:

17. Transfer the updated security information to user equipment (UE). The method according to claim 16, further comprising:

18. When the UE receives LTM cell switching information, including index information indicating the updated security information, from the first distributed unit of the first base station, the UE applies the updated security information to the inter-central unit LTM handover. The method according to claim 17.

19. The updated security information includes information indicating the number of central units involved in the inter-central unit LTM handover, The aforementioned index information corresponds to one of the central units involved in the inter-central unit LTM handover, The method according to claim 18.

20. The aforementioned index information is transmitted in the Media Access Control (MAC) Control Element (CE). The method according to claim 18 or 19.

21. The updated security information is transmitted in the Radio Resource Control (RRC) reconfiguration message. The method according to any one of claims 17 to 20.

22. Transmitting security information to the first distributed unit of the first base station, Receiving updated security information corresponding to the security information from the first distributed unit of the first base station, Transferring the updated security information corresponding to the security information to the second central unit of the second base station, It further includes, The updated security information is transmitted from the first distributed unit of the first base station to the user equipment (UE). The method according to any one of claims 1 to 15.

23. The updated security information is transmitted by the Media Access Control (MAC) Control Element (CE). The method according to claim 22.

24. Sending a request to the core network node for mobility management for updated security information about multiple central units of the base station, Receiving the updated security information for the multiple central units of the base station from the core network node, The method according to any one of claims 1 to 23, further comprising:

25. The updated security information mentioned above is Security key, Next hop chain counter, or Information indicating the number of central units involved in the aforementioned inter-central unit LTM handover, Including at least one of the following: The method according to any one of claims 16 to 24.

26. The updated security information includes information for each central unit. The method according to any one of claims 16 to 25.

27. The first information is transmitted in the handover request message. The method according to any one of claims 1 to 26.

28. The second information is transmitted in the handover request acknowledgment message. The method according to any one of claims 1 to 27.

29. A method performed by the second central unit of the second base station, Receiving first information from the first central unit of the first base station, including the reference signal configuration of a candidate LTM cell operated by the first distributed unit of the first base station, The first central unit is to transmit to each second distributed unit of the second base station second information indicating whether or not an inter-central unit LTM handover is acceptable, Methods that include...

30. To determine whether an inter-central unit LTM handover is acceptable, the reference signal configuration of the candidate LTM cell operated by the first distributed unit of the first base station and the reference signal configuration of the candidate LTM cell operated by the at least one second distributed unit of the second base station are transmitted to each of the at least one second distributed unit of the second base station. Receiving a response from each of the at least one second distributed unit of the second base station indicating whether the inter-central unit LTM handover is acceptable, The method according to claim 29, further comprising:

31. A method performed by user equipment (UE), Receiving updated security information from the first central unit of the first base station, Receiving information about the updated security information from the first central unit, Based on the information regarding the updated security information, the updated security information is applied to the lower-layer triggered mobility (LTM) handover between central units from the first base station to the second base station. Methods that include...

32. The information regarding the updated security information is Index information showing at least a portion of the updated security information, or Further updated security information, Including at least one of the following: The method according to claim 31.

33. The aforementioned support information is transmitted by the Media Access Control (MAC) Control Element (CE). The method according to claim 31 or 32.

34. A method performed by core network nodes for mobility management, Receiving a request from the first central unit of the first base station for updated security information regarding multiple central units of the base station, Transmitting the updated security information for the plurality of central units of the base station to the first central unit of the first base station, Methods that include...

35. The first central unit of the first base station, Means for transmitting first information, including the reference signal configuration of a candidate LTM cell operated by the first distributed unit of the first base station, to the second central unit of the second base station, Means for receiving second information from the second central unit to each second distributed unit of the second base station, indicating whether or not inter-central unit LTM handover is acceptable, A first central unit equipped with the following.

36. The second central unit of the second base station, Means for receiving first information from a first central unit of a first base station, including a reference signal configuration of a candidate LTM cell operated by a first distributed unit of the first base station, The first central unit is provided with means for transmitting to each second distributed unit of the second base station second information indicating whether or not inter-central unit LTM handover is acceptable, A second central unit equipped with [a certain feature].

37. User mode (UE), A means for receiving updated security information from the first central unit of the first base station, Means for receiving information about the updated security information from the first central unit, Means for applying the updated security information to a central unit lower-layer triggered mobility (LTM) handover from the first base station to the second base station, based on the information regarding the updated security information, User equipment equipped with these features.

38. A core network node for mobility management, Means for receiving a request from a first central unit of a first base station for updated security information regarding multiple central units of the base station, The first central unit of the first base station is provided with means for transmitting the updated security information for the plurality of central units of the base station, A core network node equipped with these features.

Images