Method, central unit, user equipment and core network node
Patent Information
- Authority / Receiving Office
- EP · EP
- Patent Type
- Applications
- Current Assignee / Owner
- NEC CORP
- Filing Date
- 2024-07-12
- Publication Date
- 2026-06-10
AI Technical Summary
Current 5G communication systems lack efficient mechanisms for inter-CU based Lower Layer Triggered Mobility (LTM), leading to increased latency and interruption time during handovers.
The implementation of methods and apparatus that enable inter-CU based LTM by allowing user equipment (UE) to switch between pre-configured candidate LTM cells based on lower layer measurements, without requiring RRC reconfiguration.
This approach reduces latency and interruption time during handovers, enabling faster and more efficient mobility management in 5G networks.
Smart Images

Figure JP2024025195_06022025_PF_FP_ABST
Abstract
Description
METHOD, CENTRAL UNIT, USER EQUIPMENT AND CORE NETWORK NODE
[0001] The present disclosure relates to a communication system.
[0002] The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (including LTE-Advanced, Next Generation or 5G networks, future generations, and beyond), and to lower layer triggered mobility (LTM).
[0003] Earlier developments of the 3GPP standards were referred to as the Long-Term Evolution (LTE) of Evolved Packet Core (EPC) network and Evolved UMTS Terrestrial Radio Access Network (E-UTRAN), also commonly referred as '4G'. More recently, the term '5G' and 'new radio' (NR) has started to be used to refer to an evolving communication technology that is expected to support a variety of applications and services. Various details of 5G networks are described in, for example, the 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, which document is available from https: / / www.ngmn.org / 5g-white-paper.html. 3GPP intends to support 5G by way of the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and the 3GPP NextGen core network.
[0004] Under the 3GPP standards, a NodeB (or an eNB in LTE, and gNB in 5G) is the radio access network (RAN) node (or simply 'access node', 'access network node' or 'base station') via which communication devices (user equipments or 'UEs') connect to a core network and communicate with other communication devices or remote servers. For simplicity, the present application will use the term access network node, RAN node or base station to refer to any such access nodes.
[0005] Also for simplicity, the present application will use the term mobile device, user device, or UE to refer to any communication device that is able to connect to the core network via one or more base stations. Although the present application may refer to mobile devices in the description, it will be appreciated that the technology described can be implemented on any communication devices (mobile and / or generally stationary) that can connect to a communications network for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.
[0006] In the current 5G architecture, the gNB structure may be split into two or more parts. In some RAN implementations there are two parts, known as the Central Unit (CU or gNB-CU) - sometimes referred to as a 'control unit' - and the Distributed Unit (DU or gNB-DU), connected by an F1 interface. This enables the use of a 'split' architecture in which the typically 'higher' CU layers (for example, but not necessarily or exclusively, Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) layers) and the, 'lower' DU layers (for example, but not necessarily or exclusively, Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) layers) are separated between a particular CU, and one or more DUs that are connected to and controlled by that CU via the F1 interface. Thus, for example, the higher layer CU functionality for a number of gNBs may be implemented centrally (for example, by a single processing unit, or in a cloud-based or virtualised system), whilst retaining the lower layer DU functionality locally separately for each gNB.
[0007] NPL 1: 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN), available from https: / / www.ngmn.org / 5g-white-paper.html.
[0008] Historically, mobility between different cells in cellular communications has been based on communication at higher layers, such as layer 3 (e.g., the L3 or radio resource control (RRC) layer) signalling. More recently, with a view to providing enhanced mobility, consideration has given to developing and providing support for layer 1 (e.g., the L1 or physical (PHY) layer) and / or layer 2 (e.g., the L2 or media access control (MAC) layer) centric mobility (also referred to as L1 / L2 centric mobility) rather than at higher layers (e.g., the RRC layer). Such L1 / L2 centric mobility (also referred to as L1 / L2 triggered mobility, or 'lower layer triggered mobility' (LTM)) has prospects for improving mobility for devices operating both below 7 GHz and in mmWave bands, for example by supporting lower latency handover and improved robustness. However, LTM is currently only supported for the case of intra-CU handover (including inter-DU and intra-DU scenarios).
[0009] There is, therefore, a need for the development of communication devices (such as base stations and / or UEs), and corresponding methods, that support efficient / flexible mechanisms for inter-CU based LTM. In particular, there is a need for improved methods and apparatus for supporting reliable, secure and efficient inter-CU based LTM handover, for reducing the latency and interruption time.
[0010] The disclosure aims to provide apparatus and methods that at least partially address the above needs and / or issues.
[0011] Detailed examples of the disclosure will now be described, by way of example, with reference to the accompanying drawings in which:
[0012] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system 1;Fig. 2 illustrates a typical frame structure that may be used in the communication system 1 of Fig. 1;Fig.3 illustrates examples of intra-CU and inter-CU handovers;Fig. 4 illustrates an example of key handling used for handovers;Fig. 5 illustrates a key update procedure for inter-CU handover;Fig. 6 illustrates a method of intra-CU inter-DU based LTM;Fig. 7 illustrates a signalling flow for LTM (Uu);Fig. 8 illustrates a further signalling flow for LTM;Fig. 9 illustrates a method of inter-CU based LTM;Fig. 10 illustrates a further method of inter-CU based LTM including transmission of security parameters and security keys;Fig. 11 illustrates a further method of inter-CU based LTM;Fig. 12 illustrates a method for a security update for multiple CU based LTM;Fig. 13 is a schematic block diagram illustrating the main components of a UE 3 for the communication system 1 of Fig. 1;Fig. 14 is a schematic block diagram illustrating the main components of a base station 5 of a distributed type for the communication system 1 of Fig. 1; andFig. 15 is a schematic block diagram illustrating the main components of a core network node or function for the communication system 1 of Fig. 1.
[0013] Overview An exemplary telecommunication system will now be described in general terms, by way of example only, with reference to Figs. 1 to 5.
[0014] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system 1 to which examples of the present disclosure are applicable.
[0015] In the communication system 1, user equipment (UEs) 3-1, 3-2, 3-3 (e.g. mobile telephones and / or other mobile devices) can communicate with each other via a radio access network (RAN) node 5 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, the 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 through 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 appreciate, whilst three UEs 3 and one base station 5 are shown in Fig. 1 for illustration purposes, the system, when implemented, will typically include other base stations 5 and UEs 3.
[0017] Each base station 5 controls one or more associated cells 9 either directly, or indirectly via one or more other nodes (such as home base stations, relays, remote radio heads, distributed units, and / or the like). It will be appreciated that the base stations 5 may be configured to support 4G, 5G, 6G and / or later generations, and / or any other 3GPP or non-3GPP communication protocols.
[0018] In this example the illustrated RAN node 5 comprises a distributed base station 5 comprising at least one distributed unit (DU) 5b (e.g., a gNB-DU or the like), and a central unit (CU) 5c (e.g., a gNB-CU or the like). The CU 5c employs a separated control plane and user plane and so is, itself, split between a control plane function (CU-CP) and a user plane function (CU-UP) which respectively communicate, with the DU via an appropriate interface (e.g. an F1-C interface) and an appropriate interface (e.g. an F1-U interface) (together forming an F1 interface (or 'reference point')), and with one another via an appropriate interface (e.g. an E1 interface). It will be appreciated that while, in this example, the DU includes the physical and virtual elements required to provide the functionality of the lower parts of the PHY layer and hence communicate with the UEs 3 over the air interface, the RAN may alternatively (or additionally) include one or more separate radio units (RUs) (e.g., providing this functionality of the lower parts of the PHY layer). It will, nevertheless, be appreciated that whilst distributed RAN node 5 is shown and described, the RAN node 5 may be provided in a non-distributed form, for example as an integrated base station (e.g. gNB or eNB).
[0019] The UEs 3 and their serving base station 5 are connected via an appropriate air interface (for example the so-called 'Uu' interface and / or the like). Neighbouring base stations 5 may be connected to each other via an appropriate base station to base station interface (such as the so-called 'X2' interface, 'Xn' interface and / or the like).
[0020] The core network 7 includes a number of logical nodes (or 'functions') for supporting communication in the telecommunication system 1. In this example, the core network 7 comprises control plane functions (CPFs) 10 and one or more network node entities for the communication of user data (e.g. user plane functions (UPFs) 11). The CPFs 10 include one or more network node entities for the communication of control signalling (e.g. Access and Mobility Management Functions (AMFs) 10-1), one or more network node entities for session management (e.g. Session Management Functions (SMFs) 10-2) and a number of other functions 10-n (such as, for example, an Authentication Server Function (AUSF) which facilitates security processes, a Unified Data Management (UDM) entity for managing user specific data (e.g., for access authorization, user registration, and data network profiles), a Policy Control Function (PCF), an Application Function (AF), and / or the like). It will be appreciated that the nodes or functions may have different names in different systems.
[0021] The RAN node 5 is connected to the core network nodes via appropriate interfaces (or 'reference points') such as an N2 reference point between the CU 5c (CU-CP) of the RAN and the AMF 10-1 for the communication of control signalling, and an N3 reference point between the CU 5c (CU-UP) of the RAN and each UPF 11 for the communication of user data. The UEs 3 are each connected to the AMF 10-1 via a non-access stratum (NAS) connection over an appropriate reference point (e.g. an N1 reference point (analogous to the S1 reference point in LTE)). It will be appreciated, that N1 communications are routed transparently via the RAN.
[0022] One or more UPFs 11 are connected to an external data network (e.g., an IP network such as the Internet) via an appropriate reference point (e.g. a N6 reference point) for communication of the user data.
[0023] The AMF 10-1 performs mobility management related functions, maintains the NAS connection with each UE 3 and manages UE registration. The AMF 10-1 is also responsible for managing paging. The SMF 10-2 provides session management functionality (that formed part of MME functionality in LTE) and additionally combines some control plane functions (provided by the serving gateway and packet data network gateway in LTE). The SMF 10-2 also allocates IP addresses to each UE 3.
[0024] The base station 5 of the communication system 1 may be configured to operate at least one cell 9 on an associated time-division duplex (TDD) carrier that operates in unpaired spectrum. It will be appreciated that the base station 5 may also operate at least one cell 9 on an associated frequency-division duplex (FDD) carrier that operates in paired spectrum.
[0025] The base station 5 is also configured for transmission of, and the UEs 3 are configured for the reception of, control information and user data via a number of downlink (DL) physical channels and for transmission of a number of physical signals. The DL physical channels correspond to resource elements (REs) carrying information originating from a higher layer, and the DL physical signals are used in the physical layer and correspond to REs which do not carry information originating from a higher layer.
[0026] The 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 sharing the PDSCH's capacity on a time and frequency basis. The PDSCH can carry a variety of items of data including, for example, user data, UE-specific higher layer control messages mapped down from higher channels, system information blocks (SIBs), and paging. The PDCCH carries downlink control information (DCI) for supporting a number of functions including, for example, scheduling the downlink transmissions on the PDSCH and also the uplink data transmissions on a physical uplink shared channel (PUSCH). The PBCH provides UEs 3 with the Master Information Block (MIB). It also, in conjunction with the PDCCH, supports the synchronisation of time and frequency, which aids cell acquisition, selection and re-selection. The UE 3 may receive a Synchronization Signal Block (SSB), and the UE 3 may assume that reception occasions of a PBCH, primary synchronization signal (PSS) and secondary synchronization signal (SSS) are in consecutive symbols and form a SS / PBCH block. The base station 5 may transmit a number of synchronization signal (SS) blocks corresponding to different DL beams. The total number of SS blocks may be confined, for example, within a 5 ms duration as an SS burst. The periodicity of the SSB transmissions may be indicated to the UE using any suitable signalling (e.g. per serving cell using ssb-periodicityServingCell). The periodicity value for the SSB may be, for example, greater than or equal to 20 ms. For initial cell selection, the UE 3 may be configured to assume that an SS burst occurs with a periodicity of 2 frames. The UE 3 may also be provided with an indication of which SSBs within a 5 ms duration are transmitted (e.g. using ssb-PositionsInBurst).
[0027] The DL physical signals may include, for example, reference signals (RSs) and synchronization signals (SSs). A reference signal (sometimes known as a pilot signal) is a signal with a predefined special waveform known to both the UE 3 and the base station 5. The reference signals may include, for example, cell specific reference signals, UE-specific reference signal (UE-RS), downlink demodulation signals (DMRS), and channel state information reference signal (CSI-RS).
[0028] Similarly, the UEs 3 are configured for transmission of, and the base station 5 is configured for the reception of, control information and user data via a number of uplink (UL) physical channels corresponding to REs carrying information originating from a higher layer, and UL physical signals which are used in the physical layer and correspond to REs which do not carry information originating from a higher layer. The physical channels may include, for example, the PUSCH, a physical uplink control channel (PUCCH), and / or a physical random-access channel (PRACH). The UL physical signals may include, for example, demodulation reference signals (DMRS) for a UL control / data signal, and / or sounding reference signals (SRS) used for UL channel measurement.
[0029] When the UE 3 initially establishes a radio resource control (RRC) connection with a base station 5 via a cell 9 it registers with an appropriate core network node (e.g., AMF, MME). The UE 3 is in the so-called RRC connected state and an associated UE context is maintained by the network. When the UE 3 is in the so-called RRC idle state, or is in the RRC inactive state, it selects an appropriate cell for camping so that the network is aware of the approximate location of the UE 3 (although not necessarily on a cell level).
[0030] As mentioned above, the base station 5 in this example is a 'distributed' base station 5 that is split between one or more distributed units (DUs) 5b and a central unit (CU) 5c, with a CU 5c typically performing higher level functions and communication with the next generation core, and with the DU 5b performing lower level functions and communication over an air interface with UEs 3 in the vicinity (i.e. in a cell operated by the base station 5). A distributed base station 5 may, for example, include the following functional units hosting the following functions: - Central Unit (CU): a logical node hosting Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP) and Packet Data Convergence Protocol (PDCP) layers of the base station 5 that controls the operation of one or more DUs. The CU terminates an appropriate interface (e.g. the so-called F1 interface) connected with the DU. - Distributed Unit (DU): a logical node hosting Radio Link Control (RLC), Medium Access Control (MAC) and Physical (PHY) layers of the base station 5, and its operation is partly controlled by the CU. One DU supports one or multiple cells. One cell is supported by only one DU. The DU terminates an appropriate interface (e.g. the F1 interface) connected with the CU. - CU-Control Plane (CU-CP): a logical node hosting the RRC and the control plane part of the PDCP protocol of the CU for a base station 5. The CU-CP terminates an appropriate interface (e.g. the so-called E1 interface) connected with the CU-UP and an appropriate interface (e.g. the F1-C (F1 control plane) interface) connected with the DU. - CU-User Plane (CU-UP): a logical node hosting the user plane part of the PDCP protocol and the SDAP protocol of the CU for a base station 5. The CU-UP terminates an appropriate interface (e.g. the E1 interface) connected with the CU-CP and an appropriate interface (e.g. the F1-U (F1 user plane) interface) connected with the DU.
[0031] Frame Structure Referring to Fig. 2, which illustrates a typical frame structure that may be used in the communication system 1, the base station 5 and UEs 3 of the communication system 1 communicate with one another using resources that are organised, in the time domain, into frames of length 10 ms. Each frame comprises ten equally sized subframes of 1 ms length. Each subframe is divided into one or more slots comprising 14 orthogonal frequency-division multiplexing (OFDM) symbols of equal length.
[0032] As seen in Fig. 2, the communication system 1 supports multiple different numerologies (subcarrier spacing (SCS), slot lengths and hence OFDM symbol lengths). Specifically, each numerology is identified by a parameter, μ, where μ=0 represents 15 kHz (corresponding to the LTE SCS). Currently, the SCS for other values of μ can, in effect, be derived from μ = 0 by scaling up in powers of 2 (i.e. SCS = 15 x 2μ kHz). The relationship between the parameter, μ, and SCS (Δf) is as shown in Table 1:
[0033] CU-DU Information Exchange In the communication system 1, various messages may be exchanged between the CU 5c and the DU 5b, for instance during a setup procedure for configuring communication between the DU and CU (e.g., an 'F1 setup procedure'). The purpose of the setup procedure is to exchange application level data needed for the DU 5b and the CU 5c to interoperate correctly (e.g., on the F1 interface). This procedure is the initial procedure triggered for control plane communication (e.g., over the F1-C interface) after a transport network layer (TNL) association has become operational. Typically, this procedure will use non-UE associated signalling.
[0034] During such a procedure, the DU 5b may transmit a setup request message (e.g., an F1 Setup Request) to the CU 5c. Where the setup request message is an F1 Setup Request it may, for example, include the following information: - DU Served Cells List IE: Information about the cells supported by the DU and associated features (e.g., NR-U); - DU System Information IE.
[0035] It will be appreciated that differently named information elements, having a similar purpose, may be used.
[0036] In response, the CU 5c typically transmits an F1 Setup Response message to the DU 5b. The following information may be included in the F1 Setup Response message: - Cells to be Activated List IE: a list of cells that the CU 5c requests the DU 5b to activate.
[0037] Further to the above messages, other messages (with associated information elements) may be used to update the configuration between the CU 5c and the DU 5b. For example, Public Land Mobile Network (PLMN) list, served cell information, GNB-DU Configuration Update or GNB-CU Configuration Update messages may be used to exchange information between the CU 5c and the DU 5b.
[0038] Additional messaging may be used between the CU 5c and the DU 5b, for instance when establishing a UE's context during a UE Context Setup procedure. The purpose of the UE Context Setup procedure is to establish the UE Context including, signalling radio bearer (SRB), and data radio bearer (DRB). This procedure uses UE associated signalling.
[0039] During such a procedure, the CU 5c may transmit a UE Context Setup Request message to the DU 5b (this message may comprise an RRC container used to carry additional information, e.g. in an RRC information IE). The following information may be included in the UE Context Setup Request message: - UE-CapabilityRAT-ContainerList: the DU 5b may take this information into account for UE specific configurations; - DRX Cycle IE: the DU 5b may use the provided value from the CU 5c; - RRC Information IE; in the case where the CU 5c receives a UEAssistanceInformation IE from the UE 3, the UEAssistanceInformation IE may be included in the RRC Information IE. The DU 5b may, if supported, take the UE's assistance information into account when configuring resources for the UE 3. - SRB To Be Setup List; - DRB To Be Setup List.
[0040] In response, the DU 5b transmits a UE Context Setup Response message to the CU 5c. The following information may be included in the UE Context Setup Response message: - A list of DRBs (and SRBs) which are successfully established and DRBs (and SRBs) which failed to establish; - When the DU 5b reports the unsuccessful establishment of a DRB or SRB, an associated cause value should be precise enough to enable the CU 5c to know the reason for the unsuccessful establishment. This may include the reason that a given feature is not supported by the DU 5b; - CellGroupConfig: As an Octet string which is included by CU 5c transparently within an RRC reconfiguration message sent to UE 3; - DRX Config: As an Octet string which is included by CU 5c transparently within the RRC reconfiguration message sent to UE 3.
[0041] Instead of the above messages, alternative messages (with associated information elements) may be used to update the UE's configuration between the CU 5c and the DU 5b.
[0042] For example, to further update the UE 3 configuration between CU 5c and DU 5b (e.g., DRB / SRB), UE Context Modification Request message (from CU 5c to DU 5b) or UE Context Modification Required (from DU 5b to CU 5c) messages may be used for information exchange between the CU 5c and the DU 5b.
[0043] System information and SIB It will be appreciated that transmissions in a cell 9 of a base station 5 may include one or more broadcast transmissions, one or more unicast transmissions for reception by a UE 3, and / or one or more multicast transmissions for reception by a group of UEs 3. System information (SI) transmitted in a cell may include 'minimum SI' (MSI) and 'other SI' (OSI). The OSI may be broadcast on-demand, for example using a downlink shared channel (DL-SCH). The OSI may be broadcast upon request from a UE 3 that is in a radio resource control (RRC) idle or RRC inactive state. The OSI may also be requested by a UE 3 that is in the RRC connected state, for example via one or more dedicated RRC transmissions.
[0044] The SI may include information for enabling (e.g. configuring) the UE 3 to complete a cell selection, may include information for enabling the UE 3 to complete a cell reselection procedure, or for enabling the UE 3 to receive one or more paging messages transmitted in a cell. SI may be broadcast using a Master Information Block (MIB) and one or more System Information Blocks (SIB).
[0045] The MSI comprises the MIB and system information block 1 (SIB1). The MIB includes information for use by the UE 3 to receive SIB1, for example a subcarrier spacing for SIB1. The MIB provides information corresponding to a Control Resource Set (CORESET) and Search Space. SIB1 may be referred to as 'remaining MSI' (RMSI). SIB1 may be transmitted in a dedicated RRC message, and other SIB (e.g. SIB2 to SIB9) may be transmitting using one or more other suitable RRC transmissions (e.g. another dedicated RRC message). The MIB and SIB1 may provide the UE 3 with an indication of scheduling information for receiving and decoding the other SIB, such as SIB2 to SIB9, and may provide information for use by the UE 3 to receive one or more paging messages. The OSI may comprise, for example, SIB2 to SIB9 transmitted using a downlink sharded channel (DL-SCH) in SI messages. A mapping of SIB2 to SIB9 to corresponding SI messages may be provided to the UE 3 by the base station 5. MIB and SIB1 to 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 for intra-frequency cell reselection. SIB4 provides information for inter-frequency cell reselection. SIB5 provides information regarding inter-system cell reselection towards 4G (LTE). SIB6 and SIB7 provide information for an earthquake and tsunami warning system (ETWS). SIB8 provides information for a commercial mobile alert service (CMAS) notification, for example to provide warning text messages to the UE 3. SIB9 includes information regarding coordinated universal time (UTC), global positioning system (GPS) time (e.g. for GPS initialisation) and local time.
[0046] SIB may be broadcast periodically (e.g. according to a predetermined periodic pattern), or alternatively may be provided 'on-demand', for example in response to a request from a UE 3. For example, MIB may be transmitted with a periodicity of 80 ms and repetitions made within 80 ms, and SIB1 may be transmitted with a periodicity of 15c ms and a variable transmission repetition periodicity within 15c ms (e.g. 20 ms). SIB1 can be used to indicate to a UE 3 which SIB are transmitted periodically and which SIB are available on-demand in response to a request from the UE 3. A UE 3 may be configured to request on-demand SIB using message 1 (MSG1), which may be referred to as a MSG1-based on-demand SI request, or message 3 (MSG3), which may be referred to as a MSG3-based on-demand SI request.
[0047] A physical broadcast channel (PBCH) can be used to broadcast the MIB. The base station 5 may transmit the PBCH with synchronisation signals (SS) (e.g. primary synchronisation signal (PSS) and secondary synchronisation signal (SSS)) in a SS / PBCH Block. The SS / PBCH block comprises four orthogonal frequency-division multiplexed (OFDM) symbols that are mapped to PSS, SSS and PBCH associated with a demodulation reference signal (DM-RS). In the frequency domain, an SS / PBCH block comprises 240 contiguous subcarriers. When the UE 3 is in an RRC connected state, the base station 5 may provide the UE 3 with an indication of resources used for the SS / PBCH, for example using dedicated signalling. SIB1 may be transmitted using a physical downlink shared channel (PDSCH). The OSI may be similarly transmitted, for example, using a PDSCH. When one or more beamformed transmissions are transmitted in a cell provided by the base station 5, some of the SI (e.g. some of the SIB) may only be transmitted using particular beams, or using a particular transmission / reception point (TRP).
[0048] Timing Advance (TA) The UE 3 may be provided with timing advance (TA) information, e.g. in a 'targetTA' information element that refers to a timing adjustment indication indicating a value of a timing offset (NTA) between uplink and downlink radio frames, for the UE 3 to use for a target timing advance group (TAG) (e.g., a primary TAG (PTAG) in the case of a handover or a primary secondary TAG (PSTAG) in the case of a secondary cell group (SCG) change). A TAG is a group of cells sharing the same uplink transmission 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 since the UE 3 has received TA information (e.g. a TA command) from the base station 5, during which the UE 3 is considered to be synchronised for uplink transmissions in the cell. In other words, the UE 3 is considered to be syncronised for UL transmissions in a particular cell whilst the corresponding time alignment timer is running. If the time alignment timer expires (because the UE 3 has not received TA information from the base station 5 whilst the timer is running), the UE 3 can determine that the UE 3 is no longer synchronised for uplink transmissions in the corresponding cell. Synchronisation can be restored, for example, using a random access procedure. It will be appreciated that some cells may not require the UE 3 to be provided with TA information in order for synchronisation to be achieved. For example, for small cells the propagation delay of transmissions between the UE 3 and the base station 5 may be negligible.
[0049] Each TAG may comprise at least one serving cell with configured uplink, and the mapping of each serving cell to a TAG can be configured by RRC. For the primary TAG, the UE 3 may use the PCell as a timing reference, except with shared spectrum channel access where an SCell can also be used in some cases. In a secondary TAG, the UE may use any of the activated SCells of the TAG as a timing reference cell.
[0050] The timing advance is used to control UL transmission timing for a UE 3 (e.g. for PUSCH and PUCCH), and improves synchronisation of communication between the UE 3 and the base station 5. UEs 3 that are further from a base station 5 may be configured to use larger TA values to compensate for the propagation delay of radio signals between the UE3 and the base station 5. The TA value corresponds to the time difference between the beginning of an uplink radio frame transmitted by the UE 3, and a corresponding downlink radio frame received at the UE 3. The TA value may be configured to be equal to (or approximately equal to), twice the propagation delay between the UE 3 and the base station 5, plus an additional time offset (the additional time offset corresponding to NTA). In other words, the TA value may be: TA = (2 × propagation delay) + NTA× Tc, where NTAhas units of Tc, which is equal to 1 / (480000 × 4096) seconds. A value of NTAfor use by the UE 3 may be broadcast in a cell of the base station 5 (e.g. using SIB1), or could be transmitted to the UE 3 using dedicated signalling. It will be appreciated that the TA may need to be updated as the UE 3 moves around a cell, since mobility of the UE 3 closer to or further from the base station 5 affects the propagation delay of signals transmitted between the UE 3 and the base station 5. The TA value may be updated by transmitting a change in the TA value to the UE 3. For example, the base station 5 may transmit an indication that the TA value is to be decreased by 17 μs. Alternatively, for example, an absolute value for the new TA value could be transmitted to the UE 3 explicitly. The base station 5 may be configured to determine a new value for the TA based on uplink transmissions received from the UE 3. Timing advance updates can be signalled by the base station 5 to the UE 3 using MAC CE commands.
[0051] Lower Layer Triggered Mobility Fig. 3 illustrates examples of intra-CU and inter-CU handovers. An inter-DU intra-CU handover is illustrated by arrow A. In the inter-DU intra-CU handover the UE 3 is handed over from a first DU 5b-1 to a second DU 5b-2, but the CU 5c-1 remains unchanged. An inter-DU inter-CU handover is illustrated by arrow B. In the inter-DU inter-CU handover the UE 3 the DU 5b changes from DU 5b-2 to DU 5b-3, and the CU 5c changes from CU 5c-1 to CU 5c-2. It will be appreciated that an intra-DU intra-CU handover is also possible, in which both he DU and the CU are unchanged (e.g. handover of the UE 3 to another cell provided by the same DU 5b and CU 5c).
[0052] Serving cell change may be triggered by layer 3 (L3) measurements and can be achieved using radio resource control (RRC) signalling. However, this process involves layer 1 (L1) and layer 2 (L2) resets, resulting in increased latency, larger overhead and longer interruption time. For inter-cell mobility the UE may need to perform reconfiguration and downlink / uplink (DL / UL) synchronisation towards the target cell. In order to enable more efficient handover, lower-layer based (L1 or L2) handover may be used. Advantageously, methods and apparatus of the present disclosure enable the UE 3, DUs 5b and CUs 5c to be configured for implementing an inter-CU LTM procedure in which the UE 3 is able to 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., potentially without requiring any RRC reconfiguration). Accordingly, as the UE 3 moves around the pre-configured candidate LTM cells, it can execute fast cell switches, potentially without RRC reconfiguration.
[0053] Early Data Forwarding Early data forwarding can be used for Dual Active Protocol Stack (DAPS) handover. In early data forwarding, the source (R)AN node 5 can provide an Early Status Transfer, indicating a COUNT value of the first PDCP SDU, to the target (R)AN node 5, and then early data forwarding for the DL PDCP SDUs with assigned sequence numbers can take place. Multiple early status transfer message may be transmitted from the source (R)AN node 5 to the target (R)AN node 5. The target (R)AN node 5 is configured to transmit the received PDCP SDUs to the UE 3 having a COUNT value larger than the conveyed COUNT. Early data forwarding can also be used as part of inter-CU LTM methods.
[0054] Security Handling for UE Mobility Fig. 4 illustrates an example of key handling used for handover of a UE 3. 'NH' illustrated in Fig. 4 is a Next Hop parameter. NH is a key derived by the mobile equipment (ME, or UE) 3 and AMF 10-1 to provide forward security. KSEAF(not illustrated in the figure) is an anchor key derived by the ME and the Authentication Server Function (AUSF) from KAUSF(KAUSFis an intermediate key that results from a primary authentication procedure, that can be stored at the AUSF). KSEAFis provided by the AUSF to the Security Anchor Function (SEAF) in the serving network. KAMFis a key derived by the ME and SEAF from KSEAF. KAMFis further derived by the ME and source AMF 10-1 when performing horizontal key derivation. KgNBis a key derived by the ME and AMF 10-1 from KAMF. The security architecture and key hierarchy is described in more detail in 3GPP TS 33.501 17.10.0.
[0055] The NH and KgNBare derived by the AMF 10-1 and the UE 3 when an access stratum (AS) security context needs to be established between the UE 3 and the (R)AN node 5. As illustrated in Fig. 4, an NH Chaining Counter (NCC) is associated with each KgNBand NH parameter. Each KgNBis associated with the NCC corresponding to the NH value from which it was derived (KgNBassociated with NCC=0 to NCC=3 are illustrated in Fig. 4). At initial setup KgNBis derived directly from KAMF, using a non access stratum uplink count value (NAS uplink COUNT), and is associated with a virtual NH parameter with NCC=0, as illustrated in Fig. 4.
[0056] The UE 3 and the (R)AN node 5 use KgNBto secure the communication between the UE 3 and the (R)AN node 5. For the case of handover, the KgNBthat will be used between the UE 3 and the target (R)AN node 5 is KNG-RAN*, and is derived from either the currently active KgNBor from the NH parameter. If KNG-RAN* is derived from the currently active KgNBthen this is referred to as horizontal key derivation, illustrated by each horizonal row of derived KgNBin Fig. 4. If the KNG-RAN* is derived from the NH parameter then this is referred to as a vertical key derivation.
[0057] When a new initial KgNBis calculated from KAMF,the AMF 10-1 transmits the new KgNBto the serving base station 5 in a message for modifying the security context at the base station 5. An NCC value of 0 is associated with the new KgNB. The base station 5 and the UE 3 can then compute KNG-RAN* for handover. For intra-CU handover, KgNBmay be maintained in some scenarios, or may be changed by deriving KNG-RAN*. KNG-RAN* is derived using the target Physical Cell ID (PCI), downlink (DL) frequency, and using either the currently active KgNB(for the case of horizontal key derivation) or the NH (for the case of vertical key derivation). The source (R)AN node 5 transmits the {KNG-RAN*, NCC} pair to the target (R)AN node 5, and the target (R)AN node 5 uses KNG-RAN* for secure communication between the UE 3 and the target (R)AN node 5.
[0058] For selective secondary cell groups (selective SCG) security, a secondary node (SN) counter may be used for fresh key derivation and SCG activation. The network may provide an SN counter value to the UE 3 for each SN, the UE 3 may be configured to stores the SN counter values along with the Conditional PSCell Change (CPC). The UE 3 can then derive KSN, a key used for dual connectivity that is used to derive further RRC and user plane keys that are used between the UE 3 and the SN, using KgNBtogether with an unused SN Counter value that is pre-provisioned by the network. The UE 3 is configured to change the SN Counter value upon each SN change.
[0059] Key Update Procedure for Inter-CU Handover Fig. 5 illustrates a key update procedure for inter-CU handover.
[0060] In step S501 the source CU 5c-1 transmits a handover request, that includes the {KNG-RAN*, NCC} pair, to the target CU 5c-2.
[0061] In step S502 the target CU 5c-2 generates the new KgNBwith the NCC.
[0062] In step S503 the target CU 5c-2 transmits a handover acknowledgement to the source CU 5c-1, including a transparent container carrying the NCC value for the generated KgNB.
[0063] In step S504 the source CU 5c-1 transmits an RRC reconfiguration message (handover command) to the UE 3, comprising the transparent container carrying the NCC.
[0064] In step S505 'UE access to the target DU / CU' is performed using a Random Access (RA) procedure.
[0065] In step S506 the UE 3 transmits an RRC Reconfiguration Complete message (e.g. RRCReconfigurationComplete) to the target CU 5c-2.
[0066] In step S507 the target CU 5c-2 transmits a path switch request to the AMF 10-1.
[0067] In step S508a the UE 3 and the target CU 5c-2 begin to use the new KgNBfor secure communication between the UE 3 and the target CU 5c-2. In step 508b the AMF 10-1 increases the NCC value, and generates the fresh NH parameter.
[0068] In step S509 the AMF 10-1 transmits a patch switch acknowledgement, comprising the new {NH, NCC} pair, to the target CU 5c-2.
[0069] In Step S510 the target CU 5c-2 stores the new {NCC, NH} pair for handover of the UE 3.
[0070] LTM Intra-CU Inter-DU Based Handover Fig. 6 illustrates a method of intra-CU inter-DU based LTM.
[0071] In step S601 the UE 3 transmits a L3 measurement report to the source DU 5b-1 based on a measurement configuration. The measurement report is forwarded to CU 5c by the source DU 5b-1. In step S602 the CU 5c transmits a UE Context Setup Request message to the target DU 5b-2, and in step S603 the target DU 5b-2 transmits a UE Context Setup Response, including Cell ID and cell radio network temporary identifier (C-RNTI), to the CU 5c.
[0072] In step S604 the CU 5c determines a candidate set for the UE 3 for LTM, and in step S605 the CU 5c transmits an RRC Reconfiguration message to the UE 3, including the LTM candidate configurations and the new C-RNTI. In step S606 the UE 3 transmits an RRC Reconfiguration Complete (RRCReconfigurationComplete) message to the CU 5c.
[0073] In Step 607 the UE 3 transmits a L1 measurement report for LTM to the source DU 5b-1. In step S608 the source DU 5b-1 makes an LTM handover decision based on the L1 measurement report received from the UE 3, and determines that LTM handover is to occur.
[0074] In step S609 the source DU 5b-1 transmits an LTM commence to the UE 3, carried by a MAC control element (MAC CE). In step S610 the UE 3 performs access to the target DU 5b-2 via a random access procedure. The target DU 5b-2 is able to identify the UE 3 via the C-RNTI or RA preambles transmitted by the UE 3 during the random access procedure. In optional step S611 the target DU transmits an Access Success message to the CU 5c.
[0075] Signalling for LTM Fig. 7 illustrates a signalling flow for LTM. As illustrated in Fig. 7, the method includes an LTM preparation (or 'pre-configuration') phase, and early synchronization phase, an LTM execution phase, and an LTM completion phase.
[0076] Pre-configuration At the beginning of the LTM preparation phase the UE 3 is in the RRC connected state, and in step S701 the UE 3 transmits a L3 measurement report to the base station 5 based on a measurement configuration.
[0077] In step S702 a candidate set for UE 3 is prepared. In step S703 the base station transmits an RRC reconfiguration message to the UE 3, comprising the LTM candidate configuration. The UE 3 stores the LTM candidate cell configurations. In step S704. the UE 3 transmits an RRC reconfiguration complete message to the base station 5.
[0078] Early synchronisation In steps S705a and S705b the UE 3 performs L1 measurements and reports for reference signals (e.g. SSB or CSI-RS) corresponding to inter-cell beams, based on configurations from the network. Based on L1 measurement reports, the network may activate some transmission configuration information (TCI) states quasi co-located (QCL-ed) with cells whose physical cell ID (PCI) is different from serving cell. The UE 3 optionally performs DL and UL synchronisation for these cells.
[0079] LTM Execution and LTM Completion In step S706 the UE 3 transmits a L1 measurement report to the base station 5, reporting one or more measurements performed by the UE 3 for on the configured candidate cells. In step S707 the base station 5 determines that LTM handover is to be performed, based on the L1 measurement report received from the UE 3, and transmits a corresponding cell switch command (including a MAC CE) to the UE 3 in step S708. The cell switch command indicates the LTM candidate cell configuration prepared by the base station 5, and the UE 3 switches to the target cell according to the cell switch command. In step S709 the UE 3 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, the UE 3 performs RACH towards the target cell. Alternatively, the UE 3 may skip the RA procedure, which may be referred to as RACH-less LTM.
[0080] In step S711 the LTM handover is complete, and the UE 3 can communication via the target cell. The UE 3 completes the LTM cell switch procedure by sending RRCReconfigurationComplete message to target cell. If the UE has performed a random access procedure in step 710 the UE 3 considers that the LTM execution is successfully completed when the random access procedure is successfully completed. For RACH-less LTM, the UE 3 considers that LTM execution is successfully completed when the UE 3 determines that the network has successfully received its first UL data.
[0081] Fig. 8 illustrates a further signalling flow for inter-DU intra-CU LTM, illustrating transmissions exchanged between a UE 3, source DU 5b-1, target DU 5b-2 and a CU 5c. This method can be used when the UE 3 moves from one DU 5b-1 to another DU 5b-2 with the same CU 5c.
[0082] In step S801 the UE 3 transmits a measurement report message comprising a L3 measurement result to the source DU 5b-1, containing measurements of neighbouring cells. The source DU 5b-1 is configured to transmit an UL RRC MESSAGE TRANSFER message forwarding the received measurement report to the CU 5c.
[0083] In step S802 the CU 5c determines to initiate LTM configuration.
[0084] In step S803 the CU 5c transmits a UE context setup request message, comprising one target candidate cell ID, to the (candidate) target DU 5b-2. In step S804 the target DU 5b-2 transmits a UE context setup response message to the CU 5c, including the generated lower layer RRC configuration for the accepted candidate target cell.
[0085] In step S805 the CU 5c transmits a DL RRC message transfer message, comprising the generated RRC Reconfiguration message with the LTM configuration, to the source DU 5b-1.
[0086] In step S806, the source DU 5b-1 forwards the RRC reconfiguration message to the UE 3. In step S807, the UE 3 transmits an RRC Reconfiguration complete message to the source DU 5b-1. In step S808, the source DU 5b-1 forwards the RRC Reconfiguration complete message to the CU 5c using an UL RRC message transfer message.
[0087] In step S809 the UE 3 transmits the lower layer measurement result to the source DU 5b-1, and in step S810 the source DU 5b-1 determines to execute LTM to a candidate target cell. In step S811 the source DU 5b-1 transmits the LTM command to the UE 3.
[0088] In step S812 the source DU 5b-1 transmits an LTM cell change notification message to the CU 5c, including the target cell ID, to indicate the initiation of the LTM command to the UE 3.
[0089] In step S813 the target DU 5b-2 detects access of the UE 3, and in step S814 the target DU 5b-2 transmits an access success message to the CU 5b, including the target cell ID.
[0090] In optional step S815 the CU 5c transmits a UE context release command message to the source DU 5b-1 to release the resources of the prepared cells, and in optional step S816 the source DU 5b01 transmits a UE context release complete message to the CU 5c.
[0091] Inter-CU Based LTM Methods and apparatus for inter-CU based LTM will now be described with reference to Figs. 9 to 12. Advantageously, the methods enable LTM to be achieved for the case of inter-CU handover, beneficially reducing the latency for the inter-CU handovers.
[0092] Signalling for inter-CU based LTM Fig. 9 shows illustrates a method of inter-CU based LTM. Advantageously, the method includes signalling (e.g. Xn signalling) for the configuration of inter-CU candidate cells during LTM preparation, and enables LTM to be used for inter-CU handover.
[0093] In step S901, measurement configuration and reporting are performed between the UE 3, the source DU 5b-1 and the source CU 5c-1. The UE 3 is configured to transmit a measurement report message (e.g. MeasurementReport), including a L3 measurement result, to the source DU 5b-1. Advantageously, the measurement report message includes measurements of inter-CU neighbouring cells. The source DU 5b-1 transmits an UL RRC message transfer message to the source CU 5c-1, to forward the measurement report from the UE 3 to the source CU 5c-1.
[0094] In step S902, the source CU 5c-1 performs LTM candidate initial preparation, in which a candidate cell set for the UE 3 is prepared.
[0095] In step S903 the source CU 5c-1 transmits a handover request message to the target CU 5c-2, for example as described above with reference to step S501 of Fig. 5. However, advantageously, the handover request message additionally includes a new LTM Handover Preparation Request IE. The LTM Handover Preparation Request IE includes the following sub-IEs: - Inter-CU LTM indication sub-IE to indicate the inter-CU LTM handover - A list of Reference Signal configurations, carrying the reference signal configuration of all of the candidate LTM cells hosted by the source DU 5b-1, for LTM measurement - LTM Measurement report configuration on the cells of the source DU 5b-1 - LTM RACH configuration to support early TA acquisition towards the cells of the source DU 5b-1
[0096] For inter-CU LTM, it may be assumed that the cell hosted by the source DU 5b-1 or the cells hosted by other DUs 5b of the source CU 5c-1 are also 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 the reason that, in step S903, when the source CU 5c-1 transmits the LTM Handover Preparation Request IE within the Handover Request message to target CU 5c-2, it includes the Reference Signal configurations, carrying the reference signal configuration of the candidate LTM cell hosted by the source DU 5b-1.
[0097] In step S903, if the new LTM Handover Preparation Request IE is included in the handover request message, then the target (R)AN node shall consider (determine) that the request concerns an LTM handover, and is configured to initiate the preparation with the corresponding DU 5b-2 hosted at the CU 5c-2 node in the split RAN architecture. The target (R)AN node shall also include the new LTM Handover Preparation Response IE in the handover request acknowledge message transmitted in step S906.
[0098] In step S904 the target CU 5c-2 transmits a UE Context Setup Request message to the target DU 5b-2. The target (candidate) DU 5b-2 prepares an LTM configuration for the UE 3, and prepares a context for the UE 3. In step S905 the target DU 5b-2 transmits a UE Context Setup Response message, including the LTM configuration, to the target CU 5c-2. The UE Context Setup Response message may include the target Cell ID and target cell radio network temporary identifier (C-RNTI). Steps S904 and S905 are similar to steps S602 and S603 described above with reference to Fig. 6 for the case of intra-CU handover. However, advantageously, for the inter-CU case of Fig. 9, in order to assist the target DU 5b-2 in preparing the LTM configuration, the CU 5c-2 beneficially provides all of the LTM configurations (including the LTM reference signal configuration received from the source CU 5c-1 in step S903 for inter-CU LTM preparation, and optionally the LTM configuration of the DU 5b-2 hosted by the target CU 5c-2 for intra-CU LTM as supported by 3GPP Rel-18) to each target DU 5b-2 in step S904. Based on the information received from the target CU 5c-2 in step S904, the candidate DU 5b-2 generates the reference signal configuration to send to the target CU 5c-2 in step S905.
[0099] The target CU 5c-2 receives all of the UE Context Setup Responses (in step S905) before transmitting the Handover Request Acknowledge message of step S906. In step S906 the target CU 5c-2 transmits the handover request acknowledge message to the source CU 5c-1. The target CU 5c-2 advantageously includes the prepared LTM configuration (e.g. reference signal configuration) in a new Handover Preparation Response IE included in the handover request acknowledge message, over the Xn interface. The new LTM Handover Preparation Response includes the following sub-IEs: - Inter-CU LTM Acceptance Indication sub-IE, to indicate the acceptance of inter-CU LTM handover, per DU 5b. For the accepted cases the following IEs are also included: -- A list of reference signal (RS) configurations, including the RS configuration for all of the candidate LTM cells hosted by the target DU 5b-2 of the target CU 5c-2, for LTM measurement -- LTM Measurement Report configuration for the cells hosted by the target DU 5b-2 of the target CU 5c-2
[0100] For the failure cases (non-acceptance cases), a cause value is included for each failed case, per DU 5b.
[0101] In step S907 the source CU 5c-1 transmits the RRC Reconfiguration message to the UE 3 including the handover command, to prepare an LTM handover. The source CU 5c-1 transmits the LTM configuration received from the target CU 5c-2 to the UE 3 in a transparent manner. Step S907 is similar to step S605 of Fig. 6 described above for the intra-CU case, but in step S907 the message advantageously also includes inter-CU cell configurations for LTM.
[0102] Before step S907, the target CU 5c-2 may optionally transmit (not shown in Fig. 9) the LTM configuration for its hosted DU 5b-2 to the source CU 5c-1, and the source CU 5c-1 may transmit the received LTM configuration to its hosted DU 5b-1, to assist the DU 5b-1 hosted by the source CU 5c-1 in preparing its LTM configuration (e.g. to include the RS configuration of the other candidate DUs 5b-2 hosted by the target CU 5c-2).
[0103] In step S908 the UE 3 acknowledges receipt of the RRC Reconfiguration message of step S907 by transmitting an RRC Reconfiguration Complete message to the source CU 5c-1.
[0104] In step S909 the LTM candidates are finalised at the source CU 5c-1.
[0105] In step S910 the UE 3 transmits a L1 measurement result to the source DU 5b-1. The L1 measurement is based on the LTM configuration transmitted in step S907.
[0106] After step S910, an early TA acquisition procedure may be performed (not shown in the Fig. 9), to support inter-CU LTM. In this case, the UE 3 initiates a random access (RA) procedure with the candidate DU 5b-2 hosted by the target CU 5c-2. In a first option, the source cell is responsible for timing advance (TA) transmission in a random access response (RAR). In this case, the candidate DU 5b-2 at the target CU 5c-2 forwards the calculated TA value to the target CU 5c-2, and the target CU 5c-2 forwards the TA value to the source CU 5c-1. The source CU 5c-1 then forwards the TA value to the source DU 5b-1 before the cell switch. However, this first option of forwarding the TA value from the target DU 5b-2 to the source DU 5b-1 via the target and source CUs 5c is relatively time consuming, and so the UE 3 may not receive the TA value before the cell switch occurs. In a second option, the LTM candidate cell is used for transmission of the TA in the RAR. The UE 3 may be configured to perform reception of the TA in the RAR from the target cell with a configured TA Receiving GAP (measurement duration). If the UE 3 performs the TA acquisition from multiple LTM candidate cells before the LTM cell switch, then the UE 3 may be configured to stop communication with the source cell with multiple TA Receiving GAPs, in order to receive the TA in the RAR from the LTM candidate cells one-by-one. However, in the second option, reception of the TA via the target cell may result in relatively large reception interruptions in the source cell, and so the first option may be preferable in some scenarios.
[0107] In step S911, similar to step S608 of Fig. 6, the LTM handover decision is performed at the Source DU 5b-1.
[0108] In step S912, the source DU 5b-1 transmits an LTM command carried by a MAC CE. The MAC CE enables the UE 3 to access the target cell via the inter-CU LTM handover. The MAC CE may comprise an inter-CU LTM handover indicator, to indicate to the UE 3 that the type of handover is inter-CU LTM handover.
[0109] In step S912a, the source CU 5c-1 receives an LTM Cell Change Notification from the source DU 5b-1 (before the LTE cell switch is sent to the UE 3). This F1-based LTM Cell Change Notification may reuse the message specified for the case of intra-CU LTM handover. However, advantageously, the transmission of step S912a may include a new parameter indicating that the handover is an inter-CU LTM handover.
[0110] In step S912b, the source CU 5c-1 transmits a notification of the LTM handover to the target DU 5b-2 using a LTM Cell Change Notification via a new Xn message. During step S912c, the source CU 5c-1 can begin to notify the target CU 5c-1 via one or more legacy Early Status Transfer messages, and then perform the early data forwarding to the target CU 5c-2 for the LTM handover.
[0111] In step S912c, the target CU 5c-2 transmits a notification of the LTM handover to the target DU 5b-2 using an LTM Cell Change Notification, which can be used by the target DU 5b-2 to prepare to accept the access by the UE 3.
[0112] In step S913 the UE 3 access the target DU 5b-2, as described above with reference to step S610 of Fig. 6 for the intra-CU LTM case.
[0113] For non-LTM handover, handover completion is marked by the reception of an RRC Reconfiguration Complete message at the target (R)AN node 5, and the target (R)AN node 5 exchanges a data sending status with the source (R)AN node 5. However, for LTM, the RRC Reconfiguration Complete message is not transmitted (since the RRC message is not a message of the lower layers). When LTM is performed in the split RAN architecture, when the target DU 5b-2 resolves the random access message from the UE 3, the target DU 5b-2 transmits an Access Success message, in step S914, to the target CU 5c-2 to indicate that the handover has been completed. However, in order to support inter-CU LTM, the completion of the LTM is advantageously also notified to the source CU 5c-1 by the target CU 5c-2 in step S915. The Handover Success message transmitted in step S915 beneficially includes a new parameter that indicates that the handover success is an inter-CU LTM handover success (as opposed to an intra-CU LTM handover success). Alternatively, rather than including an explicit indication that the handover success is an inter-CU LTM handover success, the source CU 5c-2 may determine that the handover success is an inter-CU LTM handover success based on having received the Handover Success message from another CU 5c-2. Advantageously, receipt of the Access Success message at the target CU 5c-2 from the target DU 5b-2 can be used to trigger transmission of the Handover Success message via the Xn interface in step S915. Upon receipt of the Handover Success message, the source CU 5c-1 transmits the PDCP sequence number status (SN status) to the target CU 5c-2. In other words, the Handover Success message can be used to trigger transmission of the SN status from the source CU 5c-1 to the target CU 5c-2.
[0114] Security Updates Methods in which security information is exchanged between the nodes of the network during inter-CU LTM will now be described with reference to Figs. 10 to 12. Benefically, the methods and apparatus enable security updates to be supported during inter-CU LTM, and enable multiple CU preparation with security key information to be supported.
[0115] As described above with reference to Figs. 4 and 5, in legacy inter-base station handover the source base station 5 provides the {KNG-RAN*, NCC} pair to the target base station 5 via a handover request (step S501 of Fig. 5), and the target base station 5 generates the new key (KgNB) based on this pair of security information. The new key and NCC are then sent to the source base station 5 using a Handover Request Acknowledgement message (step S503 of Fig. 5), and the security information is ten transmitted transparently by the source base station 5 to the UE 3 via an RRC Reconfiguration message over the Uu interface (step S504 of Fig. 5). Two advantageous options for providing updated security information to the UE 3 in the case of inter-CU LTM handover will now be described.
[0116] Fig. 10 illustrates a method of inter-CU based LTM, showing transmission of security parameters and security keys according to a first option. The method of Fig. 10 is generally the same as the method of Fig. 9, and the corresponding steps will not be described again here, but Fig. 10 further illustrates the transmission of the security parameters and security keys. In this option, security information is provided in steps S1006 (Handover Request Acknowledge message transmitted to the source CU 5c-1 from the target CU 5c-2) and S1007 (RRC Reconfiguration message transmitted to the UE 3 by the source CU 5c-1). Advantageously, for the case of inter-CU handover, the UE 3 is configured to store multiple security contexts, since different candidate CUs 5c may generate different security information.
[0117] In step S1003 the source CU 5c-1 provides the {KNG-RAN*, NCC} pair to the target CU 5c-2 in the Handover Request message. In step S1006, the target CU 5c-2 generates the new key (KgNB) based on the pair of security information {KNG-RAN*, NCC}, and then transmits the new key and NCC to the source CU 5c-1 in the Handover Request Acknowledgement message.
[0118] In step S1007, the security information (security context) is transmitted transparently from the source CU 5c-1 to the UE 3 in the RRC Reconfiguration message transmitted over the Uu interface. Advantageously, an LTM CU Index is transmitted to the UE 3 in step S1007, that enables the UE 3 to associate the security context with the CU 5c from which it is received. In other words, the LTM CU Index can be used by the UE 3 to number the security contexts and associated it with a particular CU 5c, since each CU 5c has an independent security context. In step S1012, the LTM cell switch MAC CE advantageously also includes an LTM CU index. Beneficially, therefore, when the UE 3 receives the LTM Cell Switch command, the UE 3 can identify, using the LTM CU index, the security context to apply.
[0119] Fig. 11 illustrates a method of inter-CU based LTM, showing transmission of security parameters and security keys according to a second option. The method of Fig. 11 is generally the same as the method of Fig. 9, and the corresponding steps will not be described again here, but Fig. 11 further illustrates the transmission of the security parameters and security information. In the example illustrated in Fig. 11, the updated security context is transmitted to the UE 3 in the LTM cell switch command of step S1113 (rather than in the RRC Reconfiguration message, as in the example of Fig. 10) using the MAC CE. Advantageously, since the updated security context is transmitted to the UE 3 in a later message of the LTM handover method, the security context is less likely to have become out of date (e.g. invalid).
[0120] As shown in Fig. 11, a new step S1112 is introduced for CU-DU coordination over the F1 interface. During this step, the source CU 5c-1 provides the security information for the UE 3 to the source DU 5b-1, to enable support for the inter-CU LTM handover.
[0121] In step S1113 a new Security Information IE is included in the MAC CE, that is used to provide the UE 3 with the updated security information. After step S113, the source DU 5b-1 notifies the source CU 5c-1 via the LTM Cell Change Notification of step S1113a, using a new inter-CU LTM indication, of the updated security context. The source CU 5c-1 then transmits the updated security information to the target CU 5c-2 via a new Xn LTM Cell Change Notification message in step S1113b. The Xn LTM Cell Change Notification message beneficially assists the target CU 5c-2 to prepare the security context and PDCP establishment for the UE 3.
[0122] The updated security information that is transmitted to the UE 3 in step S1113, and that is transmitted to the target CU 5c-2 in step S1113b, may include one or more of the following IEs: - Key NG-RAN Star (KNG-RAN*, as described above with reference to Fig. 4) - Next Hop Chaining Count (NCC, as described above with reference to Fig. 4) - LTM CU Count (a count of the number of CUs 5c involved for the inter-CU LTM - multiple CU based LTM will be described below with reference to Fig. 12).
[0123] In a further alternative, when the LTM cell switch has been determined by the source DU 5b-1, the source DU 5b-1 transmits an LTM notification to the source CU 5c-1, and the source CU 5c-1 transmits the updated security information to the UE 3 via an RRC message to assist the UE 3 in proceeding with the LTM cell switch to the target cell hosted by a different CU.
[0124] Security Update for Multiple-CU based LTM Fig. 12 illustrates a method for a security update for multiple CU based LTM.
[0125] In step S1201 measurement configuration and reporting is performed, that is used to trigger the inter-CU LTM handover preparation decision, as described above with reference to step S901 of Fig. 9.
[0126] In step S1202 LTM candidate initial preparation is performed, and when the source CU 5c-1 determines than a multiple-CU LTM procedure is to be performed, the source CU 5c-1 transmits a new 'Key Request for LTM' to the AMF 10-1 over the NG interface in step S1203. The Key Request for LTM includes an IE that indicates that the source CU 5c-1 is requesting keys for a number of CUs 5c. Advantageously, therefore, the Source CU 5c-1 is able to request a number of {NH, NCC} pairs for a plurality of CUs 5c.
[0127] In step S1204 the AMF 10-1 allocates the {NH, NCC} pairs for the LTM handover involving multiple CU, and transmits the list of {NH, NCC} pairs to the source CU 5c-1 in step S1205 in a new 'Key Response for LTM' message via the NG interface. In step S1205, the AMF 10-1 may replace the NCC with an LTM CU counter for security key update, to support multiple CU based LTM. In this case, the LTM fresh key derivation can be based on KgNBand the LTM CU counter at the target CU 5c-2. For example, in a case where four CUs 5c are involved in the inter-CU LTM, the LTM CU counter may be K0, K1, K2 or K3 (the source CU 5c-1 is also counted). During LTM preparation, the source CU 5c-1 provides the LTM CU counter value for each cell (under different CUs 5c), together with KgNB, and the UE 3 stores the information as a security context to be used after access to the target cell. The LTM CU counter may be transmitted to the UE 3 in the LTM cell switch command. During the LTM configuration preparation of step S1202, the source CU 5c-1 may provide the KgNBand LTM CU counter to each candidate CU 5c that is participating in the inter-CU LTM handover.
[0128] Following the Handover Preparation of step S1206, the method proceeds as described above with reference to Fig. 9 (e.g. steps S910 to S915 can be performed). However, the source CU 5c-1 can advantageously prepare the LTM handover for multiple CU simultaneously based on the pairs of {NH, NCC} received from the AMF 10-1 in step S1205.
[0129] User Equipment Fig. 13 is a schematic block diagram illustrating the main components of a UE 3 as shown in Fig. 1.
[0130] As shown, the UE 3 has a transceiver circuit 310 that is operable to transmit signals to and to receive signals from a base station 5 via one or more antenna 330 (e.g., comprising one or more antenna elements). The UE 3 has a controller 370 to control the operation of the UE 3. The controller 370 is associated with a memory 390 and is coupled to the transceiver circuit 310. Although not necessarily required for its operation, the UE 3 might, of course, have all the usual functionality of a conventional UE 3 (e.g. a user interface 350, such as a touch screen / keypad / microphone / speaker and / or the like for, allowing direct control by and interaction with a user) and this may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 390 and / or may be downloaded via the communications system 1 or from a removable data storage device (RMD), for example.
[0131] The controller 370 is configured to control overall operation of the UE 3 by, in this example, program instructions or software instructions stored within memory 390. As shown, these software instructions include, among other things, an operating system 410, a communications control module 430, and an L1 / L2 mobility module 450.
[0132] The communications control module 430 is operable to control the communication between the UE 3 and its one or more serving base stations 5 (and other communication devices connected to the base station 5, such as further UEs and / or core network nodes). The communications control module 430 is configured for the overall handling uplink communications via associated uplink channels (e.g. via a physical uplink control channel (PUCCH), random access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communications control module 430 is also configured for the overall handling of receipt of downlink communications via associated downlink channels (e.g. via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-static signalling (e.g., CSI-RS). The communications control module 430 is responsible, for example: for determining where to monitor for downlink control information (e.g., the location of CSSs / USSs, CORESETs, and associated PDCCH candidates to monitor); for determining the resources to be used by the UE 3 for transmission / reception of UL / DL communications (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the UE side; for determining how slots / symbols are configured (e.g., for UL, DL or SBFD communication, or the like); for determining which one or more bandwidth parts are configured for the UE 3; for determining how uplink transmissions should be encoded; for applying any SBFD specific communication configurations appropriately; and the like. The communications control module 430 may be configured to control communications in accordance with any of the methods described above (for example, to transmit a measurement report according to any of the methods described above).
[0133] The L1 / L2 mobility module 450 is responsible for performing control for L1 / L2 mobility. For example, the L1 / L2 mobility module 450 may be configured to perform one or more measurements for L1 / L2 mobility, or to select a candidate cell for handover. It will be appreciated that the L1 / L2 mobility module 450 may be configured to perform control as part of any of the L1 / L2 mobility methods described above.
[0134] RAN (Distributed Type) Fig. 14 is a simplified block schematic illustrating the main components of a distributed RAN comprising a distributed type of base station for implementation in the system of Fig. 1.
[0135] As shown, the RAN includes a central unit 5c and a distributed unit 5b (although it may include other DUs as described above). Each unit 5c, 5b includes respective transceiver circuitry 51c, 51b.
[0136] The transceiver circuitry 51b of the distributed unit 5b is operable to transmit signals to and to receive signals from UEs 3 via an air interface 53b and one or more antennas and is also operable to transmit signals to and to receive signals from the central unit 5c via an interface, for example the distributed unit side of an F1 interface (which may be provided over a satellite radio interface).
[0137] The transceiver circuitry 51c of the central unit 5c is operable to transmit signals to and to receive signals from functions of the core network 7 and / or other RANs via a network interface 55c. The network interface typically includes an N2 and / or N3 interfaces for communicating with the core network and a base station to base station (e.g. Xn) interface for communicating with other RANs. The central unit 5c transceiver circuitry 51c is also operable to transmit signals to and to receive signals from one or more distributed units 5b, for example the central unit side of the F1 interface provided.
[0138] Each unit 5c, 5b includes a respective controller 57c, 57b which controls the operation of the corresponding transceiver circuitry 51c, 51b in accordance with software stored in the respective memories 59c and 59b of the distributed unit 5b and the central unit 5c. The software of each unit may be pre-installed in the memory 59c, 59b and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The software of each unit includes, among other things, a respective operating system 61c, 61b, a respective communications control module 63c, 63b and an L1 / L2 mobility module 65c, 65b.
[0139] Each communications control module 63c, 63b is operable to control the communication of its corresponding unit 5c, 5b including the communication from one unit to the other. The communications control module 63b of the distributed unit 5b controls communication between the distributed unit 5b and the UEs 3, and the communications control module 63c of the central unit 5c controls communication between the central unit 5c and other network entities that are connected to the distributed RAN.
[0140] The communications control modules 63c, 63b also respectively control the part played by the distributed unit 5b and central unit 5c in the flow of uplink and downlink user traffic and control data to be transmitted to the communications devices served by the RAN including, for example, control data for managing operation of the UEs 3. Each communication control module 63c, 63b is responsible, for example, for controlling the respective part played by the distributed unit 5b and central unit 5c in the reception and decoding of uplink communications, via associated uplink channels (e.g. via a physical uplink control channel (PUCCH), a random-access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). Each communication control module 63c, 63b is responsible for controlling the respective part played by the distributed unit 5b and central unit 5c in the transmission of downlink communications via associated downlink channels (e.g. via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-static signalling (e.g., CSI-RS, SSBs etc.).
[0141] It will be appreciated that the communications control modules 63c, 63b may also include a number of sub-modules (or 'layers') to support specific functionalities for the corresponding unit 5c, 5b. The modules included will depend on how the corresponding unit 5c, 5b is configured (e.g., the precise CU-DU split). For example, the communications control modules 63c of the distributed unit 5b may include a PHY sub-module, a MAC sub-module, and an RLC sub-module, whereas the communications control modules 63c of the central unit 5c may include a PDCP sub-module, an SDAP sub-module, an IP sub-module, an RRC sub-module, etc.
[0142] The L1 / L2 mobility module 65b, 65c is responsible for performing control for L1 / L2 mobility procedures. For example, the L1 / L2 mobility module 65b, 65c may control the transmission of a set of candidate cells to a UE 3, or may control transmission of an indication of one or more measurements to be performed by the UE 3 for L1 / L2 mobility. It will be appreciated that the L1 / L2 mobility module 65b, 65c may be configured to perform control as part of any of the L1 / L2 mobility methods described above.
[0143] Core Network Node / Function Fig. 15 is a block diagram illustrating the main components of a core network node or function, such as the AMF, CPF, the UPF, the SMF or OAM. As shown, the core network function includes a transceiver circuit 710 which is operable to transmit signals to and to receive signals from other nodes (including the UE 3, the base station 5, and other core network nodes) via a network interface 720. A controller 730 controls the operation of the core network function in accordance with software stored in a memory 740. The software may be pre-installed in the memory 740 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The software includes, among other things, an operating system 750, and a communications control module 760.
[0144] The communications control module 760 is responsible for handling (generating / sending / receiving) signalling between the core network function and other nodes, such as the UE 3, the 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 appreciated that the L1 / L2 mobility module 770 may be configured to perform control as part of any of the L1 / L2 mobility methods described above.
[0146] Modifications and Alternatives As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above examples whilst still benefiting from the disclosures therein.
[0147] It will be appreciated, for example, that whilst cellular communication generation (2G, 3G, 4G, 5G, 6G etc.) specific terminology may be used, in the interests of clarity, to refer to specific communication entities, the technical features described for a given entity are not limited to devices of that specific communication generation. The technical features may be implemented in any functionally equivalent communication entity regardless of any differences in the terminology used to refer to them.
[0148] In the above description, the UEs and the base station are described for ease of understanding as having a number of discrete functional components or modules. Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the disclosure, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities.
[0149] In the above detailed examples, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied as a signal over a computer network, or on a recording medium. Further, the functionality performed by part, or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the base station or the UE in order to update their functionalities.
[0150] Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input / output (IO) circuits; internal memories / caches (program and / or data); processing registers; communication buses (e.g. control, data and / or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and / or timers; and / or the like. Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.
[0151] The User Equipment (or "UE", "mobile station", "mobile device" or "wireless device") in the present disclosure is an entity connected to a network via a wireless interface.
[0152] It should be noted that the present disclosure is not limited to a dedicated communication device and can be applied to any device having a communication function as explained in the following paragraphs.
[0153] The terms "User Equipment" or "UE" (as the term is used by 3GPP), "mobile station", "mobile device", and "wireless device" are generally intended to be synonymous with one another, and include standalone mobile stations, such as terminals, cell phones, smart phones, tablets, cellular IoT devices, IoT devices, and machinery. It will be appreciated that the terms "mobile station" and "mobile device" also encompass devices that remain stationary for a long period of time.
[0154] A UE may, for example, be an item of equipment for production or manufacture and / or an item of energy related machinery (for example equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal power generators; nuclear electricity generators; batteries; nuclear systems and / or associated equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; oil hydraulic equipment; pneumatic equipment; metal working machinery; manipulators; robots and / or their application systems; tools; molds or dies; rolls; conveying equipment; elevating equipment; materials handling equipment; textile machinery; sewing machines; printing and / or related machinery; paper converting machinery; chemical machinery; mining and / or construction machinery and / or related equipment; machinery and / or implements for agriculture, forestry and / or fisheries; safety and / or environment preservation equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubricating equipment; valves; pipe fittings; and / or application systems for any of the previously mentioned equipment or machinery etc.).
[0155] A UE may, for example, be an item of transport equipment (for example transport equipment such as: rolling stocks; motor vehicles; motorcycles; bicycles; trains; buses; carts; rickshaws; ships and other watercraft; aircraft; rockets; satellites; drones; balloons etc.). A UE may, for example, be an item of information and communication equipment (for example information and communication equipment such as: electronic computer and related equipment; communication and related equipment; electronic components etc.).
[0156] A UE may, for example, be a refrigerating machine, a refrigerating machine applied product, an item of trade and / or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, a consumer electronic and electronic appliance (for example a consumer electronic appliance such as: audio equipment; video equipment; a loud speaker; a radio; a television; a microwave oven; a rice cooker; a coffee machine; a dishwasher; a washing machine; a dryer; an electronic fan or related appliance; a cleaner etc.).
[0157] A UE may, for example, be an electrical application system or equipment (for example an electrical application system or equipment such as: an x-ray system; a particle accelerator; radio isotope equipment; sonic equipment; electromagnetic application equipment; electronic power application equipment etc.).
[0158] A UE may, for example, be an electronic lamp, a luminaire, a measuring instrument, an analyser, a tester, or a surveying or sensing instrument (for example a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.), a watch or clock, a laboratory instrument, optical apparatus, medical equipment and / or system, a weapon, an item of cutlery, a hand tool, or the like.
[0159] A UE may, for example, be a wireless-equipped personal digital assistant or related equipment (such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).
[0160] A UE may be a device or a part of a system that provides applications, services, and solutions described below, as to "internet of things (IoT)", using a variety of wired and / or wireless communication technologies.
[0161] Internet of Things devices (or "things") may be equipped with appropriate electronics, software, sensors, network connectivity, and / or the like, which enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may comprise automated equipment that follow software instructions stored in an internal memory. IoT devices may operate without requiring human supervision or interaction. IoT devices might also remain stationary and / or inactive for a long period of time. IoT devices may be implemented as a part of a (generally) stationary apparatus. IoT devices may also be embedded in non-stationary apparatus (e.g. vehicles) or attached to animals or persons to be monitored / tracked.
[0162] It will be appreciated that IoT technology can be implemented on any communication devices that can connect to a communications network for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.
[0163] It will be appreciated that IoT devices are sometimes also referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices. It will be appreciated that a UE may support one or more IoT or MTC applications. Some examples of MTC applications are listed in the following table. This list is not exhaustive and is intended to be indicative of some examples of machine type communication applications.
[0164] Applications, services, and solutions may be an MVNO (Mobile Virtual Network Operator) service, an emergency radio communication system, a PBX (Private Branch eXchange) system, a PHS / Digital Cordless Telecommunications system, a POS (Point of sale) system, an advertise calling system, an MBMS (Multimedia Broadcast and Multicast Service), a V2X (Vehicle to Everything) system, a train radio system, a location related service, a Disaster / Emergency Wireless Communication Service, a community service, a video streaming service, a femto cell application service, a VoLTE (Voice over LTE) service, a charging service, a radio on demand service, a roaming service, an activity monitoring service, a telecom carrier / communication NW selection service, a functional restriction service, a PoC (Proof of Concept) service, a personal information management service, an ad-hoc network / DTN (Delay Tolerant Networking) service, etc.
[0165] Further, the above-described UE categories are merely examples of applications of the technical ideas described in the present document. Needless to say, these technical ideas are not limited to the above-described UE and various modifications can be made thereto.
[0166] Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.
[0167] For example, the whole or part of the exemplary embodiments disclosed above can be described as, but not limited to, the following supplementary notes. (Supplementary note 1) A method performed by a first central unit of a first base station, the method comprising: transmitting, to a second central unit of a second base station, first information including reference signal configuration of candidate lower layer triggered mobility, LTM, cells operated by a first distributed unit of the first base station; receiving, from the second central unit, second information indicating whether inter-central unit LTM handover is acceptable or not per second distributed unit of the second base station. (Supplementary note 2) The method according to supplementary note 1, wherein the reference signal configuration of the candidate LTM cells operated by the first distributed unit of the first base station and reference signal configuration of candidate LTM cells 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 inter-central unit LTM handover is acceptable or not. (Supplementary note 3) The method according to supplementary note 1 or 2, wherein the second information includes reference signal configuration of candidate LTM cells operated by at least one second distributed unit of the second base station which accepted the inter-central unit LTM handover. (Supplementary note 4) The method according to supplementary note 3, further comprising: transmitting, to a first distributed unit of the first base station, the reference signal configuration of the candidate LTM cells operated by the at least one second distributed unit of the second base station which accepted the inter-central unit LTM handover. (Supplementary note 5) The method according to any one of supplementary notes 1 to 4, wherein the second information includes a cause value of failure per failed second distributed unit of the second base station. (Supplementary note 6) The method according to any one of supplementary notes 1 to 5, wherein the first information includes measurement report configuration of LTM cells operated by a first distributed unit of the first base station. (Supplementary note 7) The method according to any one of supplementary notes 1 to 6, wherein the first information includes LTM random access channel, RACH, configuration for acquiring timing advance information for LTM cells operated by a first distributed unit of the first base station. (Supplementary note 8) The method according to any one of supplementary notes 1 to 7, wherein the second information includes measurement report configuration of LTM cells operated by at least one second distributed unit of the second base station which accepted the inter-central unit LTM handover. (Supplementary note 9) The method according to any one of supplementary notes 1 to 8, wherein the second information includes LTM random access channel, RACH, configuration for acquiring timing advance information for LTM cells operated by at least one second distributed unit of the second base station which accepted the inter-central unit LTM handover. (Supplementary note 10) The method according to any one of supplementary notes 1 to 9, further comprising: receiving, from a user equipment, UE, a layer 1, L1, measurement results; and initiating a procedure for providing the UE with timing advance information for LTM cells operated by at least one second distributed unit of the second base station which accepted the inter-central unit LTM handover, before cell switching regarding the inter-central unit LTM handover. (Supplementary note 11) The method according to supplementary note 10, wherein the procedure includes: receiving, from at least one second distributed unit of the second base station which accepted the inter-central unit LTM handover, via the second central unit of the second base station, respective timing advance information; and forwarding, to the first distributed unit of the first base station, the respective timing advance information. (Supplementary note 12) The method according to supplementary note 11, wherein the respective timing advance information is transmitted in a LTM Cell Change Notification message. (Supplementary note 13) The method according to supplementary note 10, wherein the procedure includes: stopping transmission between the UE in order for the UE to receive respective timing advance information from at least one second distributed unit of the second base station which accepted the inter-central unit LTM handover. (Supplementary note 14) The method according to any one of supplementary notes 1 to 13, further comprising: receiving, from the first distributed unit of the first base station, LTM cell change notification indicating the inter-central unit LTM handover; and transmitting, to at least one second distributed unit of the second base station which accepted the inter-central unit LTM handover via the second central unit of the second base station, LTM cell change notification. (Supplementary note 15) The method according to supplementary note 14, further comprising: receiving, from the at least one second distributed unit of the second base station which accepted the inter-central unit LTM handover via the second central unit of the second base station, information indicating the inter-central unit LTM handover has been succeeded. (Supplementary note 16) The method according to any one of supplementary notes 1 to 15, further comprising: transmitting, to the second central unit of the second base station, security information along with the first information; and receiving, from the second central unit, updated security information corresponding to the security information, along with the second information. (Supplementary note 17) The method according to supplementary note 16, further comprising: forwarding, to a user equipment, UE, the updated security information. (Supplementary note 18) The method according to supplementary note 17, wherein the UE applies the updated security information, to the inter-central unit LTM handover, in a case where the UE receives, from the first distributed unit of the first base station, LTM cell switch information including index information indicating the updated security information. (Supplementary note 19) The method according to supplementary note 18, wherein the updated security information includes information indicating a number of central units involved by the inter-central unit LTM handover, and the index information corresponds to one of the number of central units involved by the inter-central unit LTM handover. (Supplementary note 20) The method according to supplementary note 18 or 19, wherein the index information is transmitted in a Medium Access Control, MAC, Control Element, CE. (Supplementary note 21) The method according to any one of supplementary notes 17 to 20, wherein the updated security information is transmitted in a Radio Resource Control, RRC, Reconfiguration message. (Supplementary note 22) The method according to any one of supplementary notes 1 to 15, further comprising: transmitting, to the first distributed unit of the first base station, security information; receiving, from the first distributed unit of the first base station, an updated security information corresponding to the security information; and forwarding, to the second central unit of the second base station, the updated security information corresponding to the security information, and wherein the updated security information is transmitted from the first distributed unit of the first base station to a user equipment, UE. (Supplementary note 23) The method according to supplementary note 22, wherein the updated security information is transmitted in a Medium Access Control, MAC, Control Element, CE. (Supplementary note 24) The method according to any one of supplementary notes 1 to 23, further comprising: transmitting, to a core network node for mobility management, a request for updated security information for a plurality of central units of base stations; and receiving, from the core network node, the updated security information for the plurality of the central units of the base stations. (Supplementary note 25) The method according to any one of supplementary notes 16 to 24, wherein the updated security information includes at least one of: a security key; a next hop chaining counter; or information indicating a number of central units involved by the inter-central unit LTM handover. (Supplementary note 26) The method according to any one of supplementary notes 16 to 25, wherein the updated security information includes information per central unit. (Supplementary note 27) The method according to any one of supplementary notes 1 to 26, wherein the first information is transmitted in a handover request message. (Supplementary note 28) The method according to any one of supplementary notes 1 to 27, wherein the second information is transmitted in a handover request acknowledge message. (Supplementary note 29) A method performed by a second central unit of a second base station, the method comprising: receiving, from a first central unit of a first base station, first information including reference signal configuration of candidate LTM cells operated by a first distributed unit of the first base station; transmitting, to the first central unit, second information indicating whether inter-central unit LTM handover is acceptable or not per second distributed unit of the second base station. (Supplementary note 30) The method according to supplementary note 29, further comprising: transmitting, to each of the at least one second distributed unit of the second base station, the reference signal configuration of the candidate LTM cells operated by the first distributed unit of the first base station and reference signal configuration of candidate LTM cells operated by at least one second distributed unit of the second base station, in order to determine whether inter-central unit LTM handover is acceptable or not; and receiving, from the each of the at least one second distributed unit of the second base station, response indicating whether the inter-central unit LTM handover is acceptable or not. (Supplementary note 31) A method performed by a user equipment, UE, the method comprising: receiving, from a first central unit of a first base station, updated security information; receiving, from the first central unit, information for the updated security information; and applying the updated security information, to an inter-central unit lower layer triggered mobility, LTM, handover from the first base station to a second base station, based on the information for the updated security information. (Supplementary note 32) The method according to supplementary note 31, wherein the information for the updated security information includes at least one of: index information indicating at least a part of the updated security information, or further updated security information. (Supplementary note 33) The method according to supplementary note 31 or 32, wherein the support information is transmitted in a Medium Access Control, MAC, Control Element, CE. (Supplementary note 34) A method performed by a core network node for mobility management, the method comprising: receiving, from a first central unit of a first base station, a request for updated security information for a plurality of central units of base stations; and transmitting, to the first central unit of the first base station, the updated security information for the plurality of the central units of the base stations. (Supplementary note 35) A first central unit of a first base station comprising: means for transmitting, to a second central unit of a second base station, first information including reference signal configuration of candidate LTM cells operated by a first distributed unit of the first base station; means for receiving, from the second central unit, second information indicating whether inter-central unit LTM handover is acceptable or not per second distributed unit of the second base station. (Supplementary note 36) A second central unit of a second base station comprising: means for receiving, from a first central unit of a first base station, first information including reference signal configuration of candidate LTM cells operated by a first distributed unit of the first base station; means for transmitting, to the first central unit, second information indicating whether inter-central unit LTM handover is acceptable or not per second distributed unit of the second base station. (Supplementary note 37) A user equipment, UE, comprising: means for receiving, from a first central unit of a first base station, updated security information; means for receiving, from the first central unit, information for the updated security information; and means for applying the updated security information, to an inter-central unit lower layer triggered mobility, LTM, handover from the first base station to a second base station, based on the information for the updated security information. (Supplementary note 38) A core network node for mobility management comprising: means for receiving, from a first central unit of a first base station, a request for updated security information for a plurality of central units of base stations; and means for transmitting, to the first central unit of the first base station, the updated security information for the plurality of the central units of the base stations.
[0168] This application is based upon and claims the benefit of priority from Great Britain Patent Application No. 2311834.2, filed on August 1, 2023, the disclosure of which is incorporated herein in its entirety by reference.
[0169] 1 COMMUNICATION SYSTEM 3 USER EQUIPMENT 5 BASE STATION 5b DISTRIBUTED UNIT (DU) 5c CENTRAL UNIT (CU) 7 CORE NETWORK 9 CELL 10 CONTROL PLANE FUNCTIONS 11 USER PLANE FUNCTIONS 20 EXTERNAL DATA NETWORK 310 TRANSCEIVER CIRCUIT 330 ANTENNA 350 USER INTERFACE 370 CONTROLLER 390 MEMORY 410 OPERATING SYSTEM 430 COMMUNICATIONS 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 MOMMUNICATIONS CONTROL MODULE 63c CU MOMMUNICATIONS CONTROL MODULE 65b L1 / L2 MOBILITY MODULE 65c L1 / L2 MOBILITY MODULE 710 TRANSCEIVER CIRCUIT 720 NETWORK INTERFACE 730 CONTROLLER 740 MEMORY 750 OPERATING SYSTEM 760 COMMUNICATIONS CONTROL MODULE 770 L1 / L2 MOBILITY MODULE
Claims
1. A method performed by a first central unit of a first base station, the method comprising: transmitting, to a second central unit of a second base station, first information including reference signal configuration of candidate lower layer triggered mobility, LTM, cells operated by a first distributed unit of the first base station; receiving, from the second central unit, second information indicating whether inter-central unit LTM handover is acceptable or not per second distributed unit of the second base station.
2. The method according to claim 1, wherein the reference signal configuration of the candidate LTM cells operated by the first distributed unit of the first base station and reference signal configuration of candidate LTM cells 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 inter-central unit LTM handover is acceptable or not.
3. The method according to claim 1 or 2, wherein the second information includes reference signal configuration of candidate LTM cells operated by at least one second distributed unit of the second base station which accepted the inter-central unit LTM handover.
4. The method according to claim 3, further comprising: transmitting, to a first distributed unit of the first base station, the reference signal configuration of the candidate LTM cells operated by the at least one second distributed unit of the second base station which accepted the inter-central unit LTM handover.
5. The method according to any one of claims 1 to 4, wherein the second information includes a cause value of failure per failed second distributed unit of the second base station.
6. The method according to any one of claims 1 to 5, wherein the first information includes measurement report configuration of LTM cells operated by a first distributed unit of the first base station.
7. The method according to any one of claims 1 to 6, wherein the first information includes LTM random access channel, RACH, configuration for acquiring timing advance information for LTM cells operated by a first distributed unit of the first base station.
8. The method according to any one of claims 1 to 7, wherein the second information includes measurement report configuration of LTM cells operated by at least one second distributed unit of the second base station which accepted the inter-central unit LTM handover.
9. The method according to any one of claims 1 to 8, wherein the second information includes LTM random access channel, RACH, configuration for acquiring timing advance information for LTM cells operated by at least one second distributed unit of the second base station which accepted the inter-central unit LTM handover.
10. The method according to any one of claims 1 to 9, further comprising: receiving, from a user equipment, UE, a layer 1, L1, measurement results; and initiating a procedure for providing the UE with timing advance information for LTM cells operated by at least one second distributed unit of the second base station which accepted the inter-central unit LTM handover, before cell switching regarding the inter-central unit LTM handover.
11. The method according to claim 10, wherein the procedure includes: receiving, from at least one second distributed unit of the second base station which accepted the inter-central unit LTM handover, via the second central unit of the second base station, respective timing advance information; and forwarding, to the first distributed unit of the first base station, the respective timing advance information.
12. The method according to claim 11, wherein the respective timing advance information is transmitted in a LTM Cell Change Notification message.
13. The method according to claim 10, wherein the procedure includes: stopping transmission between the UE in order for the UE to receive respective timing advance information from at least one second distributed unit of the second base station which accepted the inter-central unit LTM handover.
14. The method according to any one of claims 1 to 13, further comprising: receiving, from the first distributed unit of the first base station, LTM cell change notification indicating the inter-central unit LTM handover; and transmitting, to at least one second distributed unit of the second base station which accepted the inter-central unit LTM handover via the second central unit of the second base station, LTM cell change notification.
15. The method according to claim 14, further comprising: receiving, from the at least one second distributed unit of the second base station which accepted the inter-central unit LTM handover via the second central unit of the second base station, information indicating the inter-central unit LTM handover has been succeeded.
16. The method according to any one of claims 1 to 15, further comprising: transmitting, to the second central unit of the second base station, security information along with the first information; and receiving, from the second central unit, updated security information corresponding to the security information, along with the second information.
17. The method according to claim 16, further comprising: forwarding, to a user equipment, UE, the updated security information.
18. The method according to claim 17, wherein the UE applies the updated security information, to the inter-central unit LTM handover, in a case where the UE receives, from the first distributed unit of the first base station, LTM cell switch information including index information indicating the updated security information.
19. The method according to claim 18, wherein the updated security information includes information indicating a number of central units involved by the inter-central unit LTM handover, and the index information corresponds to one of the number of central units involved by the inter-central unit LTM handover.
20. The method according to claim 18 or 19, wherein the index information is transmitted in a Medium Access Control, MAC, Control Element, CE.
21. The method according to any one of claims 17 to 20, wherein the updated security information is transmitted in a Radio Resource Control, RRC, Reconfiguration message.
22. The method according to any one of claims 1 to 15, further comprising: transmitting, to the first distributed unit of the first base station, security information; receiving, from the first distributed unit of the first base station, an updated security information corresponding to the security information; and forwarding, to the second central unit of the second base station, the updated security information corresponding to the security information, and wherein the updated security information is transmitted from the first distributed unit of the first base station to a user equipment, UE.
23. The method according to claim 22, wherein the updated security information is transmitted in a Medium Access Control, MAC, Control Element, CE.
24. The method according to any one of claims 1 to 23, further comprising: transmitting, to a core network node for mobility management, a request for updated security information for a plurality of central units of base stations; and receiving, from the core network node, the updated security information for the plurality of the central units of the base stations.
25. The method according to any one of claims 16 to 24, wherein the updated security information includes at least one of: a security key; a next hop chaining counter; or information indicating a number of central units involved by the inter-central unit LTM handover.
26. The method according to any one of claims 16 to 25, wherein the updated security information includes information per central unit.
27. The method according to any one of claims 1 to 26, wherein the first information is transmitted in a handover request message.
28. The method according to any one of claims 1 to 27, wherein the second information is transmitted in a handover request acknowledge message.
29. A method performed by a second central unit of a second base station, the method comprising: receiving, from a first central unit of a first base station, first information including reference signal configuration of candidate LTM cells operated by a first distributed unit of the first base station; transmitting, to the first central unit, second information indicating whether inter-central unit LTM handover is acceptable or not per second distributed unit of the second base station.
30. The method according to claim 29, further comprising: transmitting, to each of the at least one second distributed unit of the second base station, the reference signal configuration of the candidate LTM cells operated by the first distributed unit of the first base station and reference signal configuration of candidate LTM cells operated by at least one second distributed unit of the second base station, in order to determine whether inter-central unit LTM handover is acceptable or not; and receiving, from the each of the at least one second distributed unit of the second base station, response indicating whether the inter-central unit LTM handover is acceptable or not.
31. A method performed by a user equipment, UE, the method comprising: receiving, from a first central unit of a first base station, updated security information; receiving, from the first central unit, information for the updated security information; and applying the updated security information, to an inter-central unit lower layer triggered mobility, LTM, handover from the first base station to a second base station, based on the information for the updated security information.
32. The method according to claim 31, wherein the information for the updated security information includes at least one of: index information indicating at least a part of the updated security information, or further updated security information.
33. The method according to claim 31 or 32, wherein the support information is transmitted in a Medium Access Control, MAC, Control Element, CE.
34. A method performed by a core network node for mobility management, the method comprising: receiving, from a first central unit of a first base station, a request for updated security information for a plurality of central units of base stations; and transmitting, to the first central unit of the first base station, the updated security information for the plurality of the central units of the base stations.
35. A first central unit of a first base station comprising: means for transmitting, to a second central unit of a second base station, first information including reference signal configuration of candidate LTM cells operated by a first distributed unit of the first base station; means for receiving, from the second central unit, second information indicating whether inter-central unit LTM handover is acceptable or not per second distributed unit of the second base station.
36. A second central unit of a second base station comprising: means for receiving, from a first central unit of a first base station, first information including reference signal configuration of candidate LTM cells operated by a first distributed unit of the first base station; means for transmitting, to the first central unit, second information indicating whether inter-central unit LTM handover is acceptable or not per second distributed unit of the second base station.
37. A user equipment, UE, comprising: means for receiving, from a first central unit of a first base station, updated security information; means for receiving, from the first central unit, information for the updated security information; and means for applying the updated security information, to an inter-central unit lower layer triggered mobility, LTM, handover from the first base station to a second base station, based on the information for the updated security information.
38. A core network node for mobility management comprising: means for receiving, from a first central unit of a first base station, a request for updated security information for a plurality of central units of base stations; and means for transmitting, to the first central unit of the first base station, the updated security information for the plurality of the central units of the base stations.