Method, device and system for fast switching
By pre-sharing and autonomously generating baseline RRC configurations between source and target network nodes, and directly sending handover command messages to the UE, the problems of delay and signaling overhead between nodes in the prior art are solved, and an efficient, flexible and reliable handover process is achieved.
Patent Information
- Application Number
- CN202380072746.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2022-11-02
- Filing Date
- 2023-10-30
- Publication Date
- 2025-05-23
AI Technical Summary
The message sequence flow of the inter-node switching process in the prior art results in a long handover preparation time and multiple signaling exchanges, resulting in delays or failures of the entire handover process, especially in the decomposition scenario of NGAP handover, the delay can reach 60ms, increasing the possibility of handover failures and radio link failures.
By implementing pre-sharing and autonomous generation of baseline radio resource control (RRC) configuration between the source network node and the target network node, the source node decides whether to perform the handover according to the predefined standards, and generates a handover command message, which is sent directly to the user equipment (UE), skipping the conventional handover preparation signaling exchange.
It significantly reduces the delay and signaling overhead of the handover process, improves handover efficiency and flexibility, and reduces the possibility of handover failure and radio link failure.
Smart Images

Figure CN120036030A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to mobility, and in particular to a method, apparatus and system for supporting a fast handover procedure. Background Art
[0002] Any discussion of the background art throughout the specification should not be considered as an admission that such art is widely known or forms part of the common general knowledge in the field.
[0003] Broadly speaking, in an inter-node (e.g., inter-eNB, inter-gNB, etc.) process, a user equipment (UE) may be configured to report measurements of neighboring cell(s), for example, based on an event. Upon event conditions being met, the UE may be configured to send a measurement report indicating relevant measurements of a target cell (e.g., a target cell controlled by a target node such as an eNB or gNB). The source node (e.g., source eNB or gNB) may then decide to initiate a handover (HO) process (e.g., based on conditions such as coverage, load, etc.), and send a handover request message to the target node controlling the target cell, the handover request message having the current UE configuration used by the UE at the source node. In some possible cases where there is no Xn interface between the two nodes, the target node may be accessed through an AMF, which is generally referred to as a Next Generation Application Protocol (NGAP) handover. The target node may be configured to perform admission control, such as rejecting or accepting a handover request and providing initial access resources for the UE. As just some possible examples, the configuration provided by the target node may include a cell radio network temporary identifier (C-RNTI), a contention-free random access (CFRA) preamble, a data radio bearer (DRB) configuration, a quality of service (QoS) flow to DRB mapping, UE capability-related features enabled by the target node, etc. The source node may then be configured to send a handover command message with the UE configuration of the target cell to the UE. Subsequently, the UE may be configured to acquire downlink (DL) and uplink (UL) synchronization with the target node, and then complete the handover process.
[0004] However, a possible problem with the message sequence flow of the (conventional) handover procedure is that handover preparation usually requires time and multiple signaling to request resource reservation at the target node and to receive an acknowledgement (ACK) with the target cell configuration accordingly, resulting in delays (or even failures) in the overall handover procedure. The delay may vary depending on the deployment (e.g., NGAP handover or Xn handover) or architecture (e.g., decomposed or monolithic structure), but in some possible cases, in a decomposed scenario of NGAP handover, delays of up to 60ms can be expected. Such delays, in turn, may increase the likelihood of possible handover failures (HOF) and / or radio link failures (RLF).
[0005] Therefore, new mechanisms / techniques need to be proposed to support an enhanced and fast inter-node handover process to address some or all of the above issues, especially in an efficient, flexible yet reliable manner. Summary of the invention
[0006] According to one aspect of the present disclosure, there is provided a source network node configured to support an inter-node handover procedure involving at least one target network node and a user equipment (UE) served by the source network node, the source network node comprising:
[0007] at least one processor; and
[0008] at least one memory storing instructions that, when executed by the at least one processor, cause the source network node to at least:
[0009] acquiring, from the target network node, a baseline radio resource control (RRC) configuration, the baseline RRC configuration comprising configuration information usable by the UE to be handed over and connected to the target network node, and information indicating at least one criterion for performing an inter-node handover procedure;
[0010] determining whether to perform an inter-node handover procedure based on at least one criterion; and
[0011] Based on determining that at least one of the criteria is met:
[0012] generating a handover command message based on the baseline RRC configuration; and
[0013] A handover command message is sent to the UE to enable the UE to be handed over and connected to the target network node.
[0014] In some examples, the information indicative of at least one criterion includes information indicative of a load criterion for the target network node; and
[0015] The source network node is made to:
[0016] Obtaining load information of a target network node; and
[0017] Whether to perform the inter-node handover process is determined based on whether the load of the target network node indicated by the load information satisfies a load standard.
[0018] In some examples, the load information includes information about the target network node indicating at least one of: the number of RRC connections, the number of active UEs, the number of physical resource blocks (PRBs) in use, or a transport network load (TNL) capacity.
[0019] In some examples, the information indicative of at least one criterion includes information indicating a radio configuration supported or not supported by the target network node.
[0020] In some examples, the baseline RRC configuration includes a baseline low layer configuration for layer 1 (L1) and / or layer 2 (L2) and a baseline high layer configuration for layer 3 (L3) and / or above with respect to the target network node, which can be used by the UE for connecting to the target network node; and
[0021] The source network node is caused to generate a handover command message to include a baseline low layer configuration and a baseline high layer configuration.
[0022] In some examples, the baseline RRC configuration includes at least one of: a pool of at least one random access preamble or a pool of at least one cell radio network temporary identifier (C-RNTI) that can be used in an inter-node handover procedure to connect to a target network node and can be used to identify the UE by the target network node; and
[0023] The source network node is caused to generate a handover command message comprising:
[0024] determining a random access preamble and / or a C-RNTI of the UE from a corresponding pool; and generating a handover command message to include the determined random access preamble and / or C-RNTI.
[0025] In some examples, the source network node is further caused to:
[0026] A first message is sent to the target network node, the first message including information indicating the determined random access preamble and / or C-RNTI.
[0027] In some examples, the first message also includes information indicating a user plane configuration of the UE at the source network node.
[0028] In some examples, the source network node is further caused to:
[0029] After sending the first message, a second message is received from the target network node, the second message including information indicating that the determined random access preamble and / or C-RNTI is free to be reused for other UEs.
[0030] In some examples, the source network node is a next generation radio access network (NG-RAN) node, such as a gNB.
[0031] According to another aspect of the present disclosure, there is provided a target network node configured to support an inter-node handover procedure involving a source network node and a user equipment (UE) served by the source network node, the target network node comprising:
[0032] at least one processor; and
[0033] at least one memory storing instructions that, when executed by the at least one processor, cause the target network node to at least:
[0034] generating a baseline radio resource control (RRC) configuration, the baseline RRC configuration comprising configuration information that can be used by a UE to be handed over from a source network node to a target network node, and information indicating at least one criterion for performing an inter-node handover procedure; and
[0035] Send the baseline RRC configuration to the source network node.
[0036] In some examples, the information indicative of at least one criterion includes information indicative of a load criterion for the target network node; and
[0037] The information indicative of the load criterion includes at least one of the following: the number of RRC connections, the number of active UEs, the number of physical resource blocks (PRBs) in use, or a transport network load (TNL) capacity.
[0038] In some examples, the information indicative of at least one criterion includes information indicating a radio configuration supported or not supported by the target network node.
[0039] In some examples, the baseline RRC configuration includes a baseline low layer configuration for Layer 1 (L1) and / or Layer 2 (L2) and a baseline high layer configuration for Layer 3 (L3) and / or above with respect to the target network node, which can be used by the UE to connect to the target network node.
[0040] In some examples, the baseline RRC configuration includes at least one of the following items: a pool of at least one random access preamble code or a pool of at least one cell radio network temporary identifier (C-RNTI), which can be used in an inter-node handover process to connect to a target network node and can be used to identify the UE by the target network node.
[0041] In some examples, a pool of random access preambles and / or a pool of C-RNTIs are preconfigured or reserved at a target network node for an inter-node handover procedure.
[0042] In some examples, the target network node is also caused to:
[0043] A first message is received from a source network node, the first message including information indicating a random access preamble and / or a C-RNTI determined by the source network node from a corresponding pool.
[0044] In some examples, the first message also includes information indicating a user plane configuration of the UE at the source network node.
[0045] In some examples, the target network node is also caused to:
[0046] After receiving the first message, a second message is sent to the source network node, the second message including information indicating that the random access preamble and / or C-RNTI determined by the source network node is freely reused for other UEs.
[0047] In some examples, the source network node is a next generation radio access network (NG-RAN) node, such as a gNB.
[0048] According to another aspect of the present disclosure, a method of a source network node is provided, the method being used to support an inter-node handover procedure involving at least one target network node and a user equipment (UE) served by the source network node, the method comprising:
[0049] acquiring a baseline radio resource control (RRC) configuration from the target network node, the baseline RRC configuration comprising configuration information that can be used by the UE to handover and connect to the target network node, and information indicating at least one criterion for performing an inter-node handover procedure;
[0050] determining whether to perform an inter-node handover procedure based on at least one criterion; and
[0051] Based on determining that at least one of the criteria is met:
[0052] generating a handover command message based on the baseline RRC configuration; and
[0053] A handover command message is sent to the UE to enable the UE to be handed over and connected to the target network node.
[0054] According to another aspect of the present disclosure, a method of a target network node is provided, the method being used to support an inter-node handover procedure involving a source network node and a user equipment (UE) served by the source network node, the method comprising:
[0055] Generate a baseline radio resource control (RRC) configuration including configuration information that can be used by a UE to be handed over from a source network node to a target network node, and information indicating at least one criterion for performing an inter-node handover procedure; and send the baseline RRC configuration to the source network node.
[0056] According to another aspect of the present disclosure, there is provided a communication system for supporting an inter-node handover process, the communication system comprising:
[0057] a source network as disclosed in the present disclosure;
[0058] at least one target network as disclosed in the present disclosure; and
[0059] A User Equipment (UE) served by a source network node.
[0060] According to some example embodiments, a computer program is also provided. The computer program includes instructions for causing an apparatus to execute the method disclosed in the present disclosure.
[0061] According to some example embodiments, there is further provided a memory storing computer-readable instructions for causing an apparatus to execute the method disclosed in the present disclosure.
[0062] In addition, according to some example embodiments, a source network node is provided, which is configured to support an inter-node handover procedure involving at least one target network node and a user equipment (UE) served by the source network node, and the source network element includes corresponding suitable components configured to perform the corresponding steps disclosed in the present disclosure.
[0063] Similarly, according to some example embodiments, there is also provided a target network element configured to support an inter-node handover procedure involving a source network node and a user equipment (UE) served by the source network node, the target network element comprising corresponding suitable components configured to perform the corresponding steps disclosed in the present disclosure.
[0064] In addition, according to some other example embodiments, for example, a computer program product for a wireless communication device is provided, the wireless communication device comprising at least one processor, the at least one processor comprising a software code portion, the software code portion being used to perform the corresponding steps disclosed in the present disclosure when the above-mentioned product is run on the device. The computer program product may include a computer-readable medium having the above-mentioned software code portion stored thereon. In addition, the computer program product may be directly loadable into the internal memory of the computer and / or transmittable via a network by means of at least one of an upload, download, and push process.
[0065] Although some example embodiments will be described herein with particular reference to the above-mentioned applications, it will be appreciated that the present disclosure is not limited to such fields of use and is applicable in a wider context.
[0066] It is worth noting that it should be understood that the method according to the present disclosure relates to a method of operating a device (or system) according to the above-mentioned example embodiments and variations thereof, and corresponding statements made about the device (or system) are also applicable to the corresponding method, and vice versa, so similar descriptions may be omitted for the sake of brevity. In addition, even if not explicitly disclosed, the above aspects may be combined in a variety of ways. Those skilled in the art will understand that these aspects and feature / step combinations are possible unless it produces a contradiction that is explicitly excluded.
[0067] Implementation of the disclosed apparatus may include the use of, but is not limited to, one or more processors, one or more application specific integrated circuits (ASICs), and / or one or more field programmable gate arrays (FPGAs). Implementation of the apparatus may also include the use of other conventional and / or custom hardware, such as a software programmable processor, such as a graphics processing unit (GPU) processor.
[0068] Other and further example embodiments of the present disclosure will become apparent by reference to the accompanying drawings during the course of the following discussion. BRIEF DESCRIPTION OF THE DRAWINGS
[0069] Example embodiments of the present disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:
[0070] Figure 1 schematically illustrates an example of a signaling / messaging flow diagram of a handover (HO) procedure;
[0071] Figure 2 schematically illustrates an example of a signaling / message flow diagram of an enhanced fast HO procedure according to some example embodiments of the present disclosure; and
[0072] Figure 3 Examples of implementations of apparatuses according to some example embodiments of the present disclosure are schematically illustrated. DETAILED DESCRIPTION
[0073] It is worth noting that, unless otherwise specified, the same or similar reference numerals used in the drawings of the present disclosure may indicate the same or similar elements. Similarly, unless otherwise specified, the same or similar messages (and the contents included therein) used in the drawings of the present disclosure may indicate the same or similar messages (and the contents thereof), and therefore, for the sake of brevity, repeated descriptions thereof may be omitted.
[0074] In the following, different exemplary embodiments will be described using a communication network architecture based on 3GPP standards for communication networks (such as 5G / NR) as an example of an exemplary communication network to which the embodiments can be applied, without limiting the embodiments to such architectures. It is clear to those skilled in the art that the embodiments can also be applied to other types of communication networks in which the mobile communication principles are integrated with D2D (device to device) or V2X (vehicle to everything) configurations, such as SL (side link), e.g. Wi-Fi, Worldwide Interoperability for Microwave Access (WiMAX), Personal Communications Service (PCS), Wideband Code Division Multiple Access (WCDMA), systems using ultra-wideband (UWB) technology, mobile ad hoc networks (MANET), wired access, etc. In addition, without loss of generality, the description of some examples of the embodiments is related to mobile communication networks, but the principles of the present disclosure can be extended and applied to any other type of communication network, such as a wired communication network.
[0075] The following examples and embodiments should be understood as illustrative examples only. Although the specification may refer to "an", "one" or "some" examples or embodiments in multiple places, this does not necessarily mean that each such reference is related to the same (multiple) examples or embodiments, nor does it necessarily mean that the feature only applies to a single example or embodiment. Individual features of different embodiments may also be combined to provide other embodiments. In addition, terms such as "comprising" and "including" should be understood as not limiting the described embodiments to only those features that have been mentioned; such examples and embodiments may also include features, structures, units, modules, etc. that are not specifically mentioned.
[0076] The basic system architecture of a communication (telecommunication) network including a mobile communication system (in which some examples of the embodiments are applicable) may include the architecture of one or more communication networks, including (multiple) radio access network subsystems and (multiple) core networks. Such an architecture may include one or more communication network control elements or functions, access network elements, radio access network elements, access service network gateways or base transceiver stations (such as base stations (BS), access points (AP), NodeBs (NBs), eNBs or gNBs), distributed units (DUs) or centralized / central units (CUs), which control the corresponding coverage area or (multiple) cells and one or more communication stations (such as communication elements or functions, such as user equipment or terminal equipment, such as user equipment (UE), or another device with similar functions, such as a modem chipset, chip, module, etc., which may also be part of a station, element, function or application capable of communication, such as a UE, element or function capable of machine-to-machine communication architecture, or as a separate element attached to an element, function or application capable of communication, etc.) through which it can communicate via one or more channels via one or more communication beams to send several types of data in multiple access domains. Furthermore, core network elements or network functions may be included, such as gateway network elements / functions, mobility management entities, mobile switching centers, servers, databases, etc.
[0077] The following description may provide further details of alternatives, modifications, and variations: The gNB includes, for example, a node that provides NR user plane and control plane protocol termination towards the UE and is connected to the 5GC via an NG interface, for example, in accordance with Section 3.2 of 3GPP TS 38.300 V16.6.0 (2021-06) incorporated by reference.
[0078] The gNB Central Unit (gNB-CU) comprises, for example, a logical node that hosts, for example, the RRC, SDAP and PDCP protocols of a gNB, or the RRC and PDCP protocols of an en-gNB that controls the operation of one or more gNB-DUs. The gNB-CU terminates the F1 interface connected to the gNB-DU.
[0079] The gNB distributed unit (gNB-DU) comprises, for example, a logical node that hosts, for example, the RLC, MAC, and PHY layers of a gNB or en-gNB, and whose operation is partially controlled by the gNB-CU. One gNB-DU supports one or more cells. One cell is supported by only one gNB-DU. The gNB-DU terminates the F1 interface connected to the gNB-CU.
[0080] The gNB-CU control plane (gNB-CU-CP) comprises, for example, a logical node that hosts the control plane portion of the RRC and PDCP protocols, for example, for a gNB-CU of an en-gNB or gNB. The gNB-CU-CP terminates the E1 interface with the gNB-CU-UP and the F1-C interface with the gNB-DU.
[0081] The gNB-CU user plane (gNB-CU-UP) includes, for example, a logical node that hosts, for example, the user plane part of the PDCP protocol for the gNB-CU of the en-gNB, and the user plane parts of the PDCP protocol and the SDAP protocol for the gNB-CU of the gNB. The gNB-CU-UP terminates the E1 interface connected to the gNB-CU-CP and the F1-U interface connected to the gNB-DU, for example, according to Section 3.1 of 3GPP TS 38.401 V16.6.0 (2021-07) incorporated by reference.
[0082] There can be different functional splits between central and distributed units, called options for example:
[0083] Option 1 (Class 1A Split):
[0084] The functional split in this option is similar to the 1A architecture in DC. RRC is located in the central unit. PDCP, RLC, MAC, physical layer and RF are located in the distributed unit.
[0085] Option 2 (Class 3C Split):
[0086] The functional split in this option is similar to the 3C architecture in DC. RRC and PDCP are located in the central unit. RLC, MAC, physical layer and RF are located in the distributed unit.
[0087] Option 3 (split within RLC):
[0088] • Low RLC (partial functions of RLC), MAC, physical layer and RF are located in the distributed unit. PDCP and High RLC (other partial functions of RLC) are located in the central unit.
[0089] Option 4 (RLC-MAC Split):
[0090] MAC, physical layer and RF are located in the distributed unit. PDCP and RLC are located in the central unit.
[0091] Otherwise, for example, according to 3GPP TR 38.801 V14.0.0 incorporated by reference
[0092] (2017-03) Section 11.
[0093] gNB supports different protocol layers, such as Layer 1 (L1) - the physical layer.
[0094] NR's Layer 2 (L2) is split into the following sublayers: Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), and Service Data Adaptation Protocol (SDAP), where for example:
[0095] The physical layer provides transport channels to the MAC sublayer;
[0096] The MAC sublayer provides logical channels to the RLC sublayer;
[0097] The RLC sublayer provides RLC channels to the PDCP sublayer;
[0098] The PDCP sublayer provides radio bearers to the SDAP sublayer;
[0099] The SDAP sublayer provides QoS flows to the 5GC;
[0100] Comp. refers to header compression and Segm. refers to segmentation;
[0101] Control channels include (BCCH, PCCH).
[0102] Layer 3 (L3) includes, for example, Radio Resource Control (RRC), for example according to Section 6 of 3GPP TS 38.300 V16.6.0 (2021-06), incorporated by reference.
[0103] A RAN (Radio Access Network) node or network node (such as a gNB, base station, gNB CU or gNB DU or part thereof) may be implemented using, for example, a device having at least one processor and / or at least one memory having computer-readable instructions (computer program) configured to support and / or provide and / or process CU and / or DU related functions and / or features, and / or at least one protocol (sub) layer of a RAN (Radio Access Network), such as Layer 2 and / or Layer 3.
[0104] The gNB CU and gNB DU parts may be, for example, co-located or physically separated. The gNB DU may be even further split into two parts, for example, one part including a processing device and the other part including an antenna. The central unit (CU) may also be referred to as BBU / REC / RCC / C-RAN / V-RAN, O-RAN or a part thereof. The distributed unit (DU) may also be referred to as RRH / RRU / RE / RU or a part thereof. Hereinafter, in various exemplary embodiments of the present disclosure, the CU-CP (or more generally, CU) may also be referred to as a (first) network node supporting at least one of the central unit control plane functions or the layer 3 protocols of the radio access network; and similarly, the DU may be referred to as a (second) network node supporting at least one of the distributed unit functions or the layer 2 protocols of the radio access network.
[0105] The gNB-DU supports one or more cells and can thus serve as, for example, a serving cell for a user equipment (UE).
[0106] User equipment (UE) may include a wireless or mobile device, a device having a radio interface that interacts with a RAN (Radio Access Network), a smartphone, an in-vehicle device, an IoT device, an M2M device, etc. Such a UE or device may include: at least one processor; and at least one memory, the at least one memory including a computer program code; wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the device to at least perform certain operations, such as an RRC connection with the RAN. The UE is, for example, configured to generate a message (e.g., including a cell ID) to be sent to the RAN via radio (e.g., to reach a serving cell and communicate with it). The UE may generate, send and receive an RRC message containing one or more RRC PDUs (packet data units).
[0107] The UE may have different states (e.g., according to sections 42.1 and 4.4 of 3GPP TS 38.331 V16.5.0 (2021-06), incorporated herein by reference).
[0108] When the RRC connection has been established, the UE is in, for example, an RRC_CONNECTED state or an RRC_INACTIVE state.
[0109] In the RRC_CONNECTED state, the UE may:
[0110] Store AS context;
[0111] ·Transmit unicast data to / from UE;
[0112] Monitor the control channel associated with the shared data channel to determine if it is data
[0113] Channel scheduling data;
[0114] Provide channel quality and feedback information;
[0115] Perform neighbor cell measurements and measurement reporting.
[0116] The RRC protocol includes the following main functions:
[0117] RRC connection control;
[0118] Measurement configuration and reporting;
[0119] · Establish / modify / publish measurement configurations (e.g., intra-frequency, inter-frequency, and inter-RAT)
[0120] Measurement);
[0121] ·Measure the establishment and release of the gap;
[0122] Measurement report.
[0123] The general functionality and interconnection of the described elements and functions (also depending on the actual network type) are known to those skilled in the art and are described in the corresponding specifications, so for the sake of brevity, a detailed description thereof may be omitted here. However, it should be noted that in addition to those described in detail below, several additional network elements and signaling links may be employed to communicate with elements, functions or applications (such as communication endpoints), communication network control elements (such as servers, gateways, radio network controllers), and other elements of the same or other communication networks.
[0124] The communication network architecture considered in the example of the embodiment may also be able to communicate with other networks such as the public switched telephone network or the Internet. The communication network may also support cloud services for virtual network elements or their functions, wherein it should be noted that the virtual network part of the telecommunications network may also be provided by non-cloud resources, such as an internal network, etc. It should be understood that the network elements and / or corresponding functions of the access system, core network, etc. may be implemented by using any node, host, server, access node or entity, etc. suitable for such purpose. In general, the network functions may be implemented as network elements on dedicated hardware, software instances running on dedicated hardware, or virtualized functions instantiated on an appropriate platform (e.g., cloud infrastructure).
[0125] In addition, network elements (such as communication elements, such as UE, terminal equipment, control elements or functions, such as access network elements, such as base stations / BS, gNB, radio network controllers, core network control elements or functions, such as gateway elements, or other network elements or functions described herein), and any other elements, functions or applications may be implemented by software, such as a computer program product of a computer; and / or by hardware. In order to perform its corresponding processing, the correspondingly used devices, nodes, functions or network elements may include several components, modules, units, components, etc. (not shown) required for control, processing and / or communication / signaling functions. For example, such components, modules, units and components may include one or more processors or processor units, including one or more processing parts for executing instructions and / or programs and / or for processing data, storage or memory units or components (e.g., ROM, RAM, EEPROM, etc.) for storing instructions, programs and / or data as work areas for processors or processing parts, input or interface components for inputting data and instructions by software (e.g., floppy disks, CD-ROMs, EEPROMs, etc.), user interfaces for providing monitoring and manipulation possibilities to users (e.g., screens, keyboards, etc.), other interfaces or components for establishing links and / or connections under the control of processor units or parts (e.g., wired and wireless interface components, radio interface components including, for example, antenna units, components for forming radio communication parts, etc.), etc., wherein the corresponding components forming the interfaces (such as radio communication parts) may also be located at remote sites (e.g., radio heads or radio stations, etc.). It should be noted that in this specification, a processing part should not be regarded as representing only a physical part of one or more processors, but may also be regarded as a logical division of the indicated processing tasks performed by one or more processors. It should be understood that according to some examples, a so-called "liquid" or flexible network concept may be adopted, wherein the operations and functions of a network element, a network function, or another entity of the network may be performed in a flexible manner in different entities or functions, such as in a node, a host, or a server. In other words, the "division of labor" between the network elements, functions, or entities involved may vary from case to case.
[0126] Before describing in detail the exemplary embodiments of the present disclosure, Figure 1 In the example shown, it is worth briefly describing some exemplary main steps of a conventional (inter-node) handover process, which involves a UE, a source network node currently serving (connected to) the UE, and at least one target network node (although for simplicity reasons, Figure 1Only one target network node is shown in the example of FIG), as described below. It is worth noting that, as shown in detail above, according to various implementations, the source network node and the target network node (or sometimes also referred to as network entity, network component, etc.) can be suitable next generation radio access network (NG-RAN) nodes, such as gNB, etc., as understood and recognized by those skilled in the art.
[0127] In particular, in such an inter-node (e.g., inter-gNB) handover scenario, the UE may be configured to report measurements of one or more neighboring cells, for example based on an event (as illustrated in step S101). When the event condition is met, the UE may be configured to send a measurement report indicating relevant measurements of a target cell controlled by (one of) the target network nodes (step S102). Measurements may be performed on any suitable object, according to various configurations and requirements, as understood and appreciated by those skilled in the art. As some possible examples (but should not be construed as any type of limitation), based on the measurements performed and reported by the UE, the source network node may be configured to derive information indicating at least one of the following items: the number of active (e.g., connected) UEs, the number of RRC connections, the number of physical resource blocks (PRBs) in use, the transport network load (TNL) capacity, etc.
[0128] Subsequently, in step S103, the source network node may decide to initiate a handover procedure, and in step S104, a handover request message is sent to the target network node controlling the target cell, the handover request message including the configuration of the UE currently used / applied / configured at the source node. In some possible cases where there is no Xn interface between the two network nodes, the target network node may be accessed through the AMF, which is generally referred to as Next Generation Application Protocol (NGAP) handover.
[0129] The target network node may be configured to perform necessary admission control, such as rejecting or accepting the handover request and providing the UE with initial access resources if accepted (as illustrated in step S105). The configuration provided by the target node may include (but is certainly not limited to) a cell radio network temporary identifier (C-RNTI), a contention-free random access (CFRA) preamble, a data radio bearer (DRB) configuration, a quality of service (QoS) flow to DRB mapping, UE capability-related features enabled by the target node, and the like.
[0130] Then, the source node may be configured to send a handover command message to the UE, as shown in step S106, where the handover command message includes the UE configuration of the target cell.
[0131] Finally, the UE may be configured to acquire DL and UL synchronization with the target network node and then complete the handover process, as exemplarily shown in steps S107 to S109.
[0132] However, as pointed out above, a possible problem with the message sequence flow of the (conventional) handover procedure is that the handover preparation phase typically requires a lot of time and multiple signaling exchanges to, for example, request resource reservation at the target node and correspondingly receive an acknowledgement (ACK) with the target cell configuration, which may lead to delays (or even failures) during the entire handover procedure. The delay may vary depending on the deployment (e.g., NGAP handover or Xn handover) or architecture (e.g., decomposed or monolithic structure), but in some possible cases, such as in a decomposed scenario of NGAP handover, delays of up to 60ms can be expected. Such delays, in turn, may increase the likelihood of possible handover failures (HOF) and / or radio link failures (RLF).
[0133] The so-called Conditional Handover (CHO) procedure introduced in 3rd Generation Partnership Project (3GPP) Release 16 may be considered as a potential candidate for solving some of the problems discussed above with conventional handover procedures.
[0134] Broadly speaking, in the case of CHO, the UE may be configured with a CHO command that contains a target cell configuration and one or more target cells' conditions for performing a handover. The condition may be based on radio measurements. The target cell / node may have prepared the necessary configuration for the UE, such as contention-free random access (CFRA) resources. This configuration may then be transmitted to the UE in a CHO command. When the UE evaluates the CHO condition and determines that the condition is applicable to a specific target cell, the UE may be configured to apply the CHO command and may use the reserved CFRA resources to initiate a random access procedure to the target cell. As those skilled in the art may understand and appreciate, the UE may be configured with multiple conditions for multiple target cells.
[0135] It can be seen that the design of the CHO process enables the UE to Figure 1 The handover is then performed / implemented without the serving cell triggering the HO execution (for a conventional HO, such as Figure 1 , as shown in step S106 in FIG.
[0136] Although CHO can be considered helpful in enhancing mobility robustness in some cases, it appears to present the following challenges and complexities compared to the regular handover process. First, in the CHO use case, multiple target cells can be prepared, each of which must reserve radio resources for a period of time, which may be up to 15 seconds in some possible cases.
[0137] Secondly, CHO is generally considered to be an optional feature that may not be implemented by all UEs (e.g., regular UEs). For these (regular) UEs, it would be beneficial to have a method that can be applied by the network to improve the mobility robustness of the handover mechanism without affecting the UE.
[0138] Third, if the preparations are performed at different times (which is a very likely scenario), each CHO configuration of the prepared target cell may require additional radio signaling, such as RRC reconfiguration or the like.
[0139] Fourth, the CHO configuration may need to be updated as the prepared target cells change (eg, due to degradation of the radio link, these target cells may no longer be relevant for preparation). Such reconfiguration also requires additional radio and network signaling exchanges.
[0140] Finally, the UE may be configured with multiple CHO conditions that must be constantly evaluated, which will lead to increased complexity for the UE.
[0141] In view of this, the present disclosure generally proposes mechanisms / techniques for supporting such (enhanced and fast) mobility use cases, such as (inter-node) handovers, etc., in particular in an efficient, flexible but reliable manner.
[0142] Reference now Figure 2 , Figure 2 The proposed fast switching mechanism / technique is described in more detail. It should be noted that, as noted above, unless otherwise specified, the same or similar reference numerals used in the drawings of the present disclosure may indicate the same or similar elements. Similarly, unless otherwise specified, the same or similar messages (and the contents included therein) used in the drawings of the present disclosure may indicate the same or similar messages (and their contents), so for the sake of brevity, repeated descriptions thereof may be omitted.
[0143] Specifically, Figure 2 As shown, in step S201, the target (network) node / element may be configured to generate and share with the source node a baseline RRC configuration for fast HO without requiring a previous handover request from the source node (e.g., Figure 1 The source node may then send a corresponding confirmation message to the target node, for example, in any suitable (existing or new) message, such as the handover request message exemplarily shown in step S104 of step S202. Thus, as illustrated in step S202, the source node may send a corresponding confirmation message to the target node. In a broad sense, the baseline RRC configuration may be considered to be generated specific to a cell pair (or in other words, specific to the source and target cells).
[0144] Depending on various implementations and / or requirements, the baseline RRC configuration generated by the target node may include (but is certainly not limited to) for example a baseline low layer configuration (i.e., configuration for (multiple) lower layers, such as Layer 1 / L1, e.g., a physical (PHY) layer, Layer 2 / L2, e.g., a medium access control (MAC) layer, a radio link control (RLC) layer, or a packet data convergence protocol (PDCP) layer, etc.). For example, in some possible examples, the baseline low layer configuration may include appropriate L1 / 2 (e.g., cell-specific) configurations, and may also include configurations related to L1 measurements. In some exemplary cases, multiple low layer configurations (for the same UE, but possibly for different use cases / scenarios) may also be included as part of the baseline configuration of the UE. For example, possible instances of multiple low layer configurations may include configuration information (e.g., PDCP and / or RLC configurations) for a radio bearer that is specific to a (e.g., predetermined) network slice ID and / or QoS parameters associated with the bearer. A possible illustrative example is that in some cases, the target network node (e.g., target DU) can be configured to provide a low-level configuration that should only be used for DRBs associated with ultra-reliable low-latency communication (URLLC) PDU sessions or that generally require high reliability. Of course, as those skilled in the art can well understand and appreciate, any other suitable (low-level related) configuration can also be included in the baseline configuration.
[0145] The baseline RRC configuration may also include a baseline higher layer configuration (i.e., configuration for (multiple) higher layers, such as layer 3 / L3 or even higher layers, e.g., a radio resource control (RRC) layer, a non-access stratum (NAS) layer, etc.). The baseline higher layer configuration may also include measurement-related configurations for higher layers (as opposed to L1 measurement configurations).
[0146] However, it is worth mentioning that this grouping or separation of the configuration of the various layers is provided for illustration purposes only. For example, in some possible cases, as understood and appreciated by those skilled in the art, some or all of the L2 sublayers (such as the Service Data Adaptation Protocol (SDAP) layer (e.g., for SRB), etc.) can be included in the baseline high-layer configuration (rather than the low-layer configuration). In some possible cases, the baseline low-layer configuration and the baseline high-layer configuration can be collectively referred to as the baseline (target cell / node) configuration (i.e., the baseline configuration related to the target cell / node).
[0147] In addition, the baseline RRC configuration may also include at least one criterion (e.g., a set of various criteria) that generally determines whether the proposed fast handover procedure with the corresponding target node (cell) is to be used, initiated or performed. As a possible illustrative example (but certainly not any type of limitation), there may be a criterion for indicating that the UE shall not use a guaranteed bit rate (GBR) configuration that the target cell cannot support (e.g., controlled by the target node (such as a gNB)). Some other possible examples related to the radio (related) configuration of the UE that is supported or not supported by the target cell / node may include, for example, a bandwidth configuration used by the UE, certain high-layer configurations (e.g., RLC, PDCP-related configurations), such as configurations regarding robust header compression (ROHC), etc. In other words, if the UE is configured with a GBR that the target cell cannot support (as shown above), the proposed fast handover procedure should not be used or initiated (by the source node) for the UE. As another possible illustrative example, the criterion for initiating the execution of a fast handover may be that the (current) load of the target cell is below a predetermined or predefined load criterion (e.g., a threshold value, such as 50%, 30%, etc.). As will be understood and appreciated by those skilled in the art, such load criteria or thresholds may be determined by the target cell or node itself or by any other suitable network entity / element (e.g., operation, administration and maintenance (OAM)) of the communication system, according to various implementations and / or requirements. The (current) load information of the target cell may be (recently) reported by the target cell / node (e.g., at the request of the source node, or periodically) or estimated by the source node (e.g., based on earlier reports from the target cell). The load information (and corresponding load criteria / thresholds) may be indicated according to any suitable parameters, which may include (but are not limited to) the number of RRC connections maintained by the target cell / node, the number of active UEs served by the target cell / node, the number of PRBs in use in the target cell / node, the TNL capacity of the target cell / node, etc.
[0148] In some possible implementations, the baseline RRC configuration may also include a pool or list of one or more random access preambles (sometimes also referred to as RACH preambles) that may be used for the fast switching process. The pool or list of RACH preambles may, for example, be predetermined, preconfigured, or (pre) reserved at the target node, so that any one of the preambles selected from the pool or list and assigned to the UE (by the source node) may be identified later by the target cell / node during a subsequent synchronization / random access process (e.g., to avoid conflicts or contention with other conventional UEs). In some possible implementations, for example, after some RACH preambles are used / occupied, reconfigured, released, etc., the corresponding pool may be updated by the source node and the target node. In this sense, it may be considered that such a pool of (preconfigured or reserved) RACH preambles may generally be used exclusively for the proposed fast switching process.
[0149] Similarly, in some possible implementations, the baseline RRC configuration may also include a pool or list of one or more C-RNTIs, which may be used / controlled by the source node (to be assigned to the UE) in the case of a handover to a cell controlled by the target node. The pool or list of C-RNTIs may also be predetermined, preconfigured or (pre) reserved at the target node, for example, so that any one of the preambles selected from the pool or list and assigned to the UE (by the source node) may be easily identified by the target cell / node later during any suitable subsequent process. In some possible implementations, for example, after some C-RNTIs are used / occupied, reconfigured, released, etc., the corresponding pool may be updated by the source node and the target node. Similar to the above-mentioned pool of RACH preambles, it may also be considered that such a pool of (preconfigured or reserved) C-RNTIs is typically used exclusively for the proposed fast handover process.
[0150] It is worth noting that, generally, the source network node can control the determination or selection of the RACH preamble and / or C-RNTI from the corresponding pool to avoid possible conflict issues of the RACH preamble and / or C-RNTI. However, in some examples, the target network node can still be configured to determine or select (e.g., reserve) a RACH preamble and / or C-RNTI for the UE.
[0151] In some possible implementations, the target network node (e.g., target gNB) may be configured / enabled to control more than one cell. Therefore, in some possible implementations, the target network node may be correspondingly configured to generate a corresponding baseline RRC configuration for each individual cell controlled by the target node. As will be understood and appreciated by those skilled in the art, such multiple baseline RRC configurations generated by the target network node may be sent from the target network node to the source network node as separate suitable messages or as a single (e.g., aggregated, etc.) suitable message according to various implementations. On the other hand, other source network nodes in the system may receive corresponding different baseline RRC configurations from the associated target node. In this sense, the baseline RRC configuration may be considered to be source-target pair specific.
[0152] Subsequently, in steps S203 and S204, the UE may be configured to perform measurements on the target cell(s) and report to the source node (similar to Figure 1 Steps S101 and S102 shown).
[0153] Based on the measurements reported from the UE, the source node may be configured to decide (as shown in step S205) to perform a handover to a cell having suitable measurement results reported by the UE (similar to Figure 1 . , step S103 in the above process.
[0154] However, with Figure 1 In contrast to the example of steps S104 and S105 of the conventional handover process of sending a handover request message to the target node and receiving a corresponding confirmation message from the target node, Figure 2 In the example embodiment, the source node may be configured to determine by itself (as illustrated in step S206) whether the UE and / or (multiple) potential target cells reported by the UE meet the criteria obtained from the target node in step S201. Therefore, the conventional message / signaling exchange between the source node and the target node for handover preparation may be skipped, thereby improving waiting time issues and overall handover efficiency. In other words, it may also be considered that in the example embodiments described in the present disclosure, the source node (rather than the target node in conventional technology) is responsible for performing the necessary admission control-related processes. For example, according to various implementations of the standards as detailed above, in some possible examples, the source node may be configured to check whether the UE uses a GBR configuration (or other suitable radio configuration of the UE) that the target cell cannot support, whether the current load of the target node is lower than a (predetermined) standard / threshold (e.g., 50%), and so on.
[0155] When it is determined that the criteria for initiating / performing a fast handover are all met, the source node may be configured to send a handover command message with necessary UE-related configuration to the UE in step S208. The UE-related configuration may include (part or all of) the baseline fast handover configuration obtained from the target network node in step S201. According to various implementations, the UE-related configuration may also include a C-RNTI determined / selected by the source network node (e.g., from a corresponding C-RNTI pool that has been received from the target network node). Similarly, the UE-related configuration may also include a random access preamble determined / selected by the source network node (e.g., from a corresponding random access preamble pool that has been received from the target network node). The C-RNTI pool and / or the random access preamble pool may be specific to the source and target cell pairs, and may be reserved for use by the source node only during the fast handover process to the target cell. As described above, the C-RNTI pool and / or the random access preamble pool may be controlled by the source network node, thereby avoiding possible C-RNTI and / or preamble conflict problems. As understood and appreciated by those skilled in the art, the UE-related configuration may also include any other suitable configuration / information required for the UE to successfully switch and connect to the target cell / node. For example, in some possible examples, the UE-related configuration may include user plane configuration (e.g., DRB and SDAP, PDCP, RLC configuration, etc.). In some additional possible examples, the UE-related configuration may also include a new key for the target node to use for (multiple) security-related processes. In some possible implementations, the UE may be configured to derive a new key from a current key and a target cell identifier (ID).
[0156] As exemplarily shown in step S207, the source network node may also be configured to also send the UE-related configuration to the target cell / node. According to various implementations, the UE-related configuration sent to the target cell / node may include information similar to or identical to the information sent to the UE (as shown in reference step S208 above). It is worth noting that this step may be considered particularly necessary, especially when the source network node has determined / selected the C-RNTI and / or random access preamble from the corresponding pool. In this case, it seems necessary to notify the target cell / node which C-RNTI and / or random access preamble has been selected from the corresponding pool. In addition, in some possible implementations, the user plane configuration (e.g., DRB-related configuration) of the UE at the source node should also be notified to the target cell / node. All of these can be prepared / generated by the source network node and sent to the target cell in a suitable (existing or newly introduced) message (or as a separate message). It is worth mentioning that, as those skilled in the art can also understand and appreciate, if necessary, such configuration (e.g., C-RNTI, DRB configuration) determined / selected / configured by the source network node can be reconfigured by the target network node later (e.g., after the handover process is successfully completed).
[0157] It should be noted that according to the exemplary embodiments of the present disclosure, the reliance on target cell configuration preparation in conventional techniques can be eliminated, so that the handover execution to the UE (i.e., the handover command message illustrated in step S208) and the handover information notification to the target node (i.e., in step S207) can be performed in any sequence or in parallel, thereby significantly saving waiting time / delay.
[0158] After receiving the handover command message sent in step S208, the UE may be configured to Figure 1The method of the present invention is similar to the conventional techniques shown in steps S107 to S109 of the present invention, performing the necessary UL / DL synchronization / random access procedures in order to successfully connect to the target cell controlled by the target network node (steps S209 to S211). Therefore, generally, no (significant / substantial) changes are required on the UE side, so conventional UEs can also be used to benefit from the fast switching process proposed by the present disclosure. It is worth noting that, as shown above, since the messages toward the target cell and the UE as shown in steps S207 and S208, respectively, can be sent in any sequence or in parallel, in some cases, step S209 can occur before step S207 (or before the complete configuration information received in step S207 is completely updated on the target cell side). In this case, the target cell / node can be configured to be able to identify that the UE is undergoing a fast switching process, for example based on a fast switching specific identifier, which can be a preamble allocated from a pool of (preconfigured / reserved) fast switching preambles and / or a C-RNTI allocated from a pool of (preconfigured / reserved) fast switching C-RNTIs. Thus, the target cell / node may be configured to wait for complete receipt or processing of the message of step S207 before sending a confirmation or acknowledgement of the message sent from the UE in step S209.
[0159] Finally, in some possible implementations, the target node may be configured to notify the source node (e.g., by transmission of a handover success message including necessary indication information, etc.) of the successful handover and connection of the UE (as illustrated in step S212). In addition, the target node may also be configured to notify the source network node that the resources allocated to the UE (e.g., RACH preamble and / or C-RNTI) can now be released (e.g., returned to the corresponding pool) so that they can be reused or reallocated to other UEs. For example, in some possible (non-limiting) examples, the RACH preamble can theoretically be released after the random access process is successful. In some other possible (non-limiting) examples, after the handover process is completed, some UE-related configurations (such as C-RNTI, DRB, etc.) can be reconfigured by the target cell / node according to various situations so that these configurations can also be released (e.g., upon receiving a corresponding notification from the target node).
[0160] In summary, as described above, although the conditional handover process can generally be used to perform (relatively) fast handover execution (compared to conventional techniques) in some possible cases, it also has disadvantages, such as in terms of resource reservation. In addition, each time the UE configuration changes, the CHO configuration may have to be re-prepared, and therefore, the correct / updated configuration may have to be signaled to the UE again. In addition, in some possible cases, the UE may need to perform a handover when the CHO information is updated, which may cause a failure. In contrast, it is worth noting that the mechanism / technique proposed in the present disclosure generally avoids unnecessary resource reservation and / or signaling overhead, thereby greatly improving the waiting time problem of conventional techniques. More specifically, the target node can be configured to prepare a corresponding default (baseline) target configuration for each of its cells, and share the default configuration with neighboring nodes as well as the relevant criteria for using the default configuration (e.g., the UE should not have a GBR DRB configuration that the target cannot support, etc.). In a broad sense, it can be considered that the preparation of the baseline / default configuration should be such that it generally only contains the (minimum) (critical) configuration (e.g., certain cell-specific configurations) set required for the UE to successfully switch and connect to the target cell / node. Then, when the source node has a UE that meets the relevant criteria corresponding to the default target configuration, a fast enhanced handover process can be initiated (without the need for a conventional handover preparation phase between the source node and the target node). As shown above, the criterion can be, for example, that the target cell / node load is less than a given threshold. The target cell configuration may also include information related to resources (e.g., preambles, C-RNTIs, etc.) from a (predetermined or reserved) small fixed pool. For example, each node (e.g., an NG-RAN node) may be configured to reserve one (or more) preambles to neighboring nodes in a cell and provide this information together with the default target cell configuration. Whenever the source node is ready to switch to the given target node in question, it may configure CFRA HO for the UE using the reserved preambles. Similar considerations apply to the C-RNTI pool. In general, it can be considered that the baseline configuration may include at least necessary cell-specific configurations (e.g., the above-mentioned low-level configurations and high-level configurations), which are generally independent of the UE (i.e., non-UE-specific). In addition, if necessary, the baseline configuration may also include certain UE-specific configurations that are usually (pre)prepared / configured as a corresponding pool or list (e.g., the above-mentioned random access preamble, C-RNTI, etc.). In addition, as described above, since the reliance on the target cell configuration preparation is eliminated during the proposed fast switching process, the switching execution (towards the UE) and the switching information notification (towards the target node) can be performed in any sequence or in parallel, which will greatly save waiting time. Therefore, the efficiency and flexibility of the switching process can be significantly improved, thereby significantly improving the efficiency and flexibility of the entire communication system.
[0161] Finally, it should be noted that although in the above-described example embodiments (with reference to the accompanying drawings), the messages transmitted / exchanged between network components / elements may appear to have specific / clear names and / or contents included therein, depending on various implementations (e.g., underlining technology), these messages may have different names, contents and / or be transmitted / exchanged in different forms / formats, as understood and appreciated by those skilled in the art.
[0162] According to some example embodiments, corresponding methods suitable for being performed by an apparatus (network element / component) as described above, such as a UE, a source and / or a target network node (e.g., a gNB, etc.) are also provided.
[0163] It should also be noted that the above-mentioned device (or system) features correspond to corresponding method features, but for reasons of simplicity, these method features may not be explicitly described. The disclosure of this document is considered to also extend to such method features. In particular, the present disclosure is understood to relate to methods of operating the above-mentioned devices and / or providing and / or arranging corresponding elements of these devices.
[0164] In addition, according to some other example embodiments, a corresponding device (for example, implementing the source network node, target network node, etc. as described above) is also provided, which includes at least one processing circuit system and at least one memory, and the at least one memory is used to store instructions executed by the processing circuit system, wherein the at least one memory and the instructions are configured to work with the at least one processing circuit system to enable the corresponding device to at least perform the corresponding steps described above.
[0165] Figure 3An illustrative (non-limiting) example of such an apparatus 300 is schematically illustrated in FIG. The apparatus 300 may be configured to implement a source network node (cell) or a target network node (cell) proposed in the present disclosure. In some possible cases, the apparatus 300 may also be implemented as any suitable network node / component / element for a communication system, such as a station coupled to and / or used to control an access system, such as a RAN node, such as a base station, eNB or gNB, a relay node or a core network node, such as an MME or S-GW or P-GW, or a core network function, such as an AMF / SMF, a server or a host, or a UE in some possible implementations. According to various implementations, the method described in the present disclosure may be implemented in a single device or across multiple devices. The device may be integrated with or located outside a node or module of a core network, RAN, etc. In particular, the apparatus 300 may be arranged to provide control over communications in a service area of the system. The apparatus 300 may include at least one memory 301, at least one data processing unit (or circuit system) 302, 302 and an input / output interface 304. Via interface 304, apparatus 300 may be coupled to any other suitable components of apparatus 300 (e.g., a receiver and / or a transmitter), or to any other suitable other apparatus(es). In some possible examples, the receiver and / or the transmitter may be implemented as a radio front end or a remote radio head.
[0166] However, in some other example embodiments, a corresponding apparatus (eg, implementing a source network node, a target network node, etc. as described above) is provided, the apparatus comprising corresponding components configured to at least perform the corresponding steps as described above.
[0167] It should be noted that the examples of the embodiments of the present disclosure are applicable to a variety of different network configurations. In other words, the examples shown in the above figures used as the basis for the above examples are merely illustrative and do not limit the present disclosure in any way. That is, based on the defined principles, other existing and proposed new functions available in the corresponding operating environment can be used in conjunction with the examples of the embodiments of the present disclosure.
[0168] It should also be noted that the disclosed example embodiments can be implemented in a variety of ways using hardware and / or software configurations. For example, the disclosed embodiments can be implemented using dedicated hardware and / or hardware associated with software that can be executed thereon. The components and / or elements in the accompanying drawings are merely examples and do not limit the scope of use or functionality of any hardware, software combined with hardware, firmware, embedded logic components, or a combination of two or more such components that implement a specific embodiment of the present disclosure.
[0169] It should be further noted that the description and the accompanying drawings illustrate only the principles of the present disclosure. Those skilled in the art will be able to implement various arrangements, which, although not explicitly described or illustrated herein, embody the principles of the present disclosure and are included in its spirit and scope. In addition, all examples and embodiments outlined in the present disclosure are primarily for explanatory purposes only, to help the reader understand the principles of the proposed method. In addition, all statements of the principles, aspects, and embodiments of the present disclosure and their specific examples provided herein are intended to cover their equivalents.
Claims
1. A source network node configured to support an inter-node handover procedure, the inter-node handover procedure involving at least one target network node and a user equipment UE served by the source network node, the source network node include: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the source network node to at least: acquiring a baseline radio resource control (RRC) configuration from the target network node, the baseline RRC configuration comprising configuration information that can be used by the UE to be handed over and connected to the target network node, and information indicating at least one criterion for performing the inter-node handover procedure; determining whether to perform the inter-node handover procedure based on the at least one criterion; as well as Based on determining that the at least one criterion is met: generating a handover command message based on the baseline RRC configuration; as well as The handover command message is sent to the UE to enable the UE to be handed over and connected to the target network node.
2. The source network node according to claim 1, wherein the information indicating at least one criterion comprises information indicating a load criterion of the target network node; and The source network node is caused to: Obtaining load information of the target network node; and Whether to perform the inter-node handover process is determined based on whether the load of the target network node indicated by the load information meets the load standard.
3. The source network node according to claim 2, wherein the load information comprises information about the target network node, the information indicating at least one of the following items: the number of RRC connections, the number of active UEs, the number of physical resource blocks (PRBs) in use, or the transport network load (TNL) capacity.
4. The source network node according to any of the preceding claims, wherein the information indicative of at least one criterion comprises information indicative of a radio configuration supported or not supported by the target network node.
5. A source network node according to any preceding claim, wherein the baseline RRC configuration comprises a baseline low layer configuration for layer 1 and / or layer 2 and a baseline high layer configuration for layer 3 and / or above with respect to the target network node, which can be used by the UE to connect to the target network node; and Wherein the source network node is caused to generate the handover command message to include the baseline low layer configuration and the baseline high layer configuration.
6. A source network node according to any of the preceding claims, wherein the baseline RRC configuration comprises at least one of the following: a pool of at least one random access preamble or a pool of at least one cell radio network temporary identifier (C-RNTI) which can be used in the inter-node handover procedure to connect to the target network node and can be used to identify the UE by the target network node ; and The source network node is caused to generate the handover command message, comprising: Determine a random access preamble and / or a C-RNTI for the UE from a corresponding pool; as well as The handover command message is generated to include the determined random access preamble and / or C-RNTI.
7. The source network node according to claim 6, wherein the source network node is further caused to: A first message is sent to the target network node, wherein the first message includes information indicating the determined random access preamble and / or C-RNTI.
8. The source network node according to claim 7, wherein the first message further comprises information indicating a user plane configuration of the UE at the source network node.
9. The source network node according to claim 7 or 8, wherein the source network node is further caused to: After sending the first message, a second message is received from the target network node, the second message comprising information indicating that the determined random access preamble and / or C-RNTI is free to be reused for other UEs.
10. A source network node according to any of the preceding claims, wherein the source network node is a Next Generation Radio Access Network, NG-RAN, node, such as a gNB.
11. A target network node configured to support an inter-node handover procedure, the inter-node handover procedure involving a source network node and a user equipment UE served by the source network node, the target network node include: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the target network node to at least: generating a baseline radio resource control (RRC) configuration, the baseline RRC configuration comprising configuration information that can be used by the UE to be handed over from the source network node to the target network node, and information indicating at least one criterion for performing the inter-node handover procedure; as well as The baseline RRC configuration is sent to the source network node.
12. The target network node according to claim 11, wherein the information indicating at least one criterion comprises information indicating a load criterion of the target network node; and The information indicating the load criterion includes at least one of the following items: the number of RRC connections, the number of active UEs, the number of physical resource blocks PRBs in use, or a transport network load TNL capacity.
13. The target network node according to claim 11 or 12, wherein the information indicating at least one criterion comprises information indicating a radio configuration supported or not supported by the target network node.
14. The target network node according to any one of claims 11 to 13, wherein the baseline RRC configuration comprises a baseline low layer configuration for layer 1 and / or layer 2 and a baseline high layer configuration for layer 3 and / or above with respect to the target network node, which can be used by the UE for connecting to the target network node.
15. The target network node according to any one of claims 11 to 14, wherein the baseline RRC configuration comprises at least one of the following items: a pool of at least one random access preamble code or a pool of at least one cell radio network temporary identifier C-RNTI, which can be used in the inter-node handover procedure to connect to the target network node and can be used to identify the UE by the target network node.
16. The target network node according to claim 15, wherein the pool of random access preambles and / or the pool of C-RNTIs are preconfigured or reserved at the target network node for the inter-node handover procedure.
17. The target network node according to claim 15 or 16, wherein the target network node is further caused to: A first message is received from the source network node, the first message including information indicating a random access preamble and / or a C-RNTI determined by the source network node from a corresponding pool.
18. The target network node according to claim 17, wherein the first message further comprises information indicating a user plane configuration of the UE at the source network node.
19. The target network node according to claim 17 or 18, wherein the target network node is further caused to: After receiving the first message, a second message is sent to the source network node, the second message comprising information indicating that the random access preamble and / or C-RNTI determined by the source network node is freely reused for other UEs.
20. The target network node according to any one of claims 11 to 19, wherein the target network node is a Next Generation Radio Access Network NG-RAN node, such as a gNB.
21. A method of a source network node, for supporting an inter-node handover procedure, the inter-node handover procedure involving at least one target network node and a user equipment UE served by the source network node, the method include: acquiring a baseline radio resource control (RRC) configuration from the target network node, the baseline RRC configuration comprising configuration information that can be used by the UE to be handed over and connected to the target network node, and information indicating at least one criterion for performing the inter-node handover procedure; determining whether to perform the inter-node handover procedure based on the at least one criterion; as well as Based on determining that the at least one criterion is met: generating a handover command message based on the baseline RRC configuration; as well as The handover command message is sent to the UE to enable the UE to be handed over and connected to the target network node.
22. A method of a target network node, for supporting an inter-node handover procedure, the inter-node handover procedure involving a source network node and a user equipment UE served by the source network node, the method include: generating a baseline radio resource control (RRC) configuration, the baseline RRC configuration comprising configuration information that can be used by the UE to switch from the source network node to the target network node, and information indicating at least one criterion for performing the inter-node handover procedure; as well as The baseline RRC configuration is sent to the source network node.
23. A communication system for supporting a handover process between nodes, the communication system include: A source network node according to any one of claims 1 to 10; at least one target network according to any one of claims 11 to 20; as well as A user equipment UE is served by the source network node.
24. A computer program comprising instructions for causing an apparatus to perform the method according to claim 21 or 22.
25. A memory storing computer-readable instructions for causing an apparatus to execute the method according to claim 21 or 22.