A method performed by a node in a wireless communication system and a node

Abstract

The present disclosure provides a method performed by a node in a wireless communication system and a node, according to one embodiment, a method performed by a second node in a wireless communication system, comprising: sending a first request message to the second node, the first request message being used to request an identity of an early random access channel (RACH) resource requester to which a candidate cell of a layer 1 / layer 2 triggered mobility (LTM) handover belongs; receiving a first response message from the second node, the first response message comprising an identity of the candidate cell and an identity of the early RACH resource requester to which the candidate cell belongs; wherein the first node is a central unit (CU) of a source node, and the second node is a CU of a candidate node; or the first node is a master node, and the second node is a secondary node.

Description

Technical Field

[0001] This disclosure relates to the field of wireless communication technology, and in particular to a method performed by nodes in a wireless communication system and the nodes themselves. Background Technology

[0002] To meet the increased demand for wireless data communication services since the deployment of 4G communication systems, efforts have been made to develop improved 5G or near-5G communication systems. Therefore, 5G or near-5G communication systems are also referred to as "super 4G networks" or "post-LTE systems".

[0003] Wireless communication is one of the most successful innovations in modern history. Recently, the number of subscribers to wireless communication services surpassed 5 billion and continues to grow rapidly. The demand for wireless data services is growing rapidly due to the increasing prevalence of smartphones and other mobile data devices (such as tablets, laptops, netbooks, e-book readers, and machine-type devices) among consumers and businesses. To meet the rapid growth of mobile data services and support new applications and deployments, improving the efficiency and coverage of wireless interfaces is crucial. Summary of the Invention

[0004] According to one aspect of this disclosure, a method performed by a first node in a wireless communication system is provided, comprising: sending a first request message to a second node, the first request message being used to request the identifier of an Early Random Access Channel (RACH) resource requester to which a candidate cell belongs for a Layer 1 / L2 Triggered Mobility (LTM) handover; receiving a first response message from the second node, the first response message including the identifier of the candidate cell and the identifier of the Early RACH resource requester to which the candidate cell belongs; wherein, the first node is a centralized unit (CU) of a source node, and the second node is a CU of a candidate node; or, the first node is a primary node, and the second node is a secondary node.

[0005] According to an exemplary embodiment, the first response message may also include the identifier of the node to which the earlier RACH resource requester belongs.

[0006] According to an exemplary embodiment, the first request message may include an identifier of the candidate cell and indication information for identifying an entity requesting early RACH resources. The identifier of the early RACH resource requester is an identifier indicating an entity requesting early RACH resources.

[0007] According to an exemplary embodiment, the first request message may include at least one of the following: an Xn establishment request message; an Xn application protocol AP query early RACH resource requester identifier request message; and an Xn AP next-generation radio access network node configuration update message.

[0008] According to an exemplary embodiment, the first response message may include at least one of the following: an Xn establishment response message; an Xn application protocol AP query early RACH resource requester identifier response message; and an Xn AP next-generation radio access network node configuration update confirmation message.

[0009] According to an exemplary embodiment, the method may further include: receiving a second message from a second node, the second message including at least one of the following: information related to the timing advanced (TA) of the candidate cell; the identifier of the early RACH resource requester; and the identifier of the node to which the early RACH resource requester belongs.

[0010] According to an exemplary embodiment, the method may further include: sending information about the TA of the candidate cell to the node indicated by the identifier of the node to which the early RACH resource requester belongs or to the node indicated by the identifier of the early RACH resource requester.

[0011] According to an exemplary embodiment, the method may further include: receiving a second request message, the second request message including information requesting early RACH resources allocated to a node by a candidate cell based on a UE or based on a DU configuration; and sending a second response message, the second response message including information relating to the early RACH resources allocated to a node by a candidate cell based on a UE or based on a DU configuration.

[0012] According to an exemplary embodiment, the second request message may include: an identifier of the candidate cell; and indication information for requesting early RACH resources allocated to the node by the candidate cell based on the UE or DU configuration.

[0013] According to an exemplary embodiment, the second response message may include: the identifier of the candidate cell; and early uplink synchronization configuration information.

[0014] According to an exemplary embodiment, the second request message may include at least one of the following: an early RACH resource request message; a UE context modification request; a UE context modification requirement message; a secondary node SN modification requirement message; and an SN modification request message.

[0015] According to an exemplary embodiment, the second response message may include at least one of the following: an early RACH resource request confirmation message; an early RACH resource response message; a UE context modification response message; a UE context modification confirmation message; an SN modification confirmation message; and an SN modification request confirmation message.

[0016] According to another aspect of this disclosure, a method performed by a second node in a wireless communication system is provided, comprising: receiving a first request message from a first node, the first request message being used to request the identifier of an Early Random Access Channel (RACH) resource requester to which a candidate cell to which a mobility LTM handover triggered by Layer 1 / Layer 2 belongs; and sending a first response message to the first node, the first response message including the identifier of the candidate cell and the identifier of the early RACH resource requester to which the candidate cell belongs; wherein the first node is a centralized unit (CU) of a source node and the second node is a CU of a candidate node; or, the first node is a primary node and the second node is a secondary node.

[0017] According to an exemplary embodiment, the first response message may also include the identifier of the node to which the earlier RACH resource requester belongs.

[0018] According to an exemplary embodiment, the first request message may include an identifier of the candidate cell and indication information for identifying an entity requesting early RACH resources. The identifier of the early RACH resource requester is an identifier indicating an entity requesting early RACH resources.

[0019] According to an exemplary embodiment, the first request message may include at least one of the following: an Xn establishment request message; an Xn application protocol AP query early RACH resource requester identifier request message; and an Xn AP next-generation radio access network node configuration update message.

[0020] According to an exemplary embodiment, the first response message may include at least one of the following: an Xn establishment response message; an Xn application protocol AP query early RACH resource requester identifier response message; and an Xn AP next-generation radio access network node configuration update confirmation message.

[0021] According to an exemplary embodiment, the method may further include: sending a second message to a first node, the second message including at least one of the following: information related to the TA of the candidate cell; the identifier of the early RACH resource requester; and the identifier of the node to which the early RACH resource requester belongs.

[0022] According to an exemplary embodiment, the method may further include: sending a second request message, the second request message including information requesting early RACH resources allocated to a node by a candidate cell based on the UE or based on the DU configuration; and receiving a second response message, the second response message including information relating to the early RACH resources allocated to a node by a candidate cell based on the UE or based on the DU configuration.

[0023] According to an exemplary embodiment, the second request message may include: an identifier of the candidate cell; and indication information for requesting early RACH resources allocated to the node by the candidate cell based on the UE or DU configuration.

[0024] According to an exemplary embodiment, the second response message may include: the identifier of the candidate cell; and early uplink synchronization configuration information.

[0025] According to an exemplary embodiment, the second request message may include at least one of the following: an early RACH resource request message; a UE context modification request; a UE context modification requirement message; a secondary node SN modification requirement message; and an SN modification request message.

[0026] According to an exemplary embodiment, the second response message may include at least one of the following: an early RACH resource request confirmation message; an early RACH resource response message; a UE context modification response message; a UE context modification confirmation message; an SN modification confirmation message; and an SN modification request confirmation message.

[0027] According to an exemplary embodiment, the method further includes: sending a second message to a first node, the second message including at least one of the following: information related to the timing advance (TA) of the candidate cell; an identifier of the early RACH resource requester; and an identifier of the node to which the early RACH resource requester belongs.

[0028] According to another aspect of this disclosure, a method is provided performed by a distribution unit (DU) of a source node in a wireless communication system, comprising: sending a second request message to a first node, the second request message including information requesting early RACH resources allocated to the node by a candidate cell based on a UE or based on the DU; and receiving a second response message from the first node, the second response message including information relating to the early RACH resources allocated to the node by the candidate cell based on the UE or based on the DU.

[0029] According to an exemplary embodiment, the second request message may include: an identifier of the candidate cell; and indication information for requesting early RACH resources allocated to the node by the candidate cell based on the UE or DU configuration.

[0030] According to an exemplary embodiment, the second response message may include: the identifier of the candidate cell; and early uplink synchronization configuration information.

[0031] According to an exemplary embodiment, the second request message may include at least one of the following: an early RACH resource request message; a UE context modification request; a UE context modification requirement message; a secondary node SN modification requirement message; and an SN modification request message.

[0032] According to an exemplary embodiment, the second response message may include at least one of the following: an early RACH resource request confirmation message; an early RACH resource response message; a UE context modification response message; a UE context modification confirmation message; an SN modification confirmation message; and an SN modification request confirmation message.

[0033] According to an exemplary embodiment, the first request message is sent by a first node, and the first request message is used to request the identifier of the Early Random Access Channel (RACH) resource requester to which the candidate cell to which the mobility LTM handover triggered by Layer 1 / Layer 2 belongs; the first response message is sent by a second node, and the first response message includes the identifier of the candidate cell and the identifier of the early RACH resource requester to which the candidate cell belongs; wherein, the first node is the centralized unit (CU) of the source node, and the second node is the CU of the candidate node; or, the first node is the primary node, and the second node is the secondary node.

[0034] According to an exemplary embodiment, the first response message may also include the identifier of the node to which the earlier RACH resource requester belongs.

[0035] According to an exemplary embodiment, the first request message may include an identifier of the candidate cell and indication information for identifying an entity requesting early RACH resources. The identifier of the early RACH resource requester is an identifier indicating an entity requesting early RACH resources.

[0036] According to an exemplary embodiment, the first request message may include at least one of the following: an Xn establishment request message; an Xn application protocol AP query early RACH resource requester identifier request message; and an Xn AP next-generation radio access network node configuration update message.

[0037] According to an exemplary embodiment, the first response message may include at least one of the following: an Xn establishment response message; an Xn application protocol AP query early RACH resource requester identifier response message; and an Xn AP next-generation radio access network node configuration update confirmation message.

[0038] According to another aspect of this disclosure, a method is provided performed by a user equipment U in a wireless communication system, comprising: receiving a Radio Resource Control (RRC) reconfiguration message and sending an RRC reconfiguration completion message; a first request message is sent by a first node, the first request message being used to request the identifier of an Early Random Access Channel (RACH) resource requester to which a candidate cell for a mobility LTM handover triggered by Layer 1 / Layer 2 belongs;

[0039] The first response message is sent by the second node. The first response message includes the identifier of the candidate cell and the identifier of the early RACH resource requester to which the candidate cell belongs.

[0040] In this configuration, the first node is the CU of the source node, and the second node is the CU of the candidate node; or, the first node is the master node, and the second node is the auxiliary node.

[0041] According to an exemplary embodiment, the first response message may also include the identifier of the node to which the earlier RACH resource requester belongs.

[0042] According to an exemplary embodiment, the first request message may include an identifier of the candidate cell and indication information for identifying an entity requesting early RACH resources. The identifier of the early RACH resource requester is an identifier indicating an entity requesting early RACH resources.

[0043] According to an exemplary embodiment, the first request message may include at least one of the following: an Xn establishment request message; an Xn application protocol AP query early RACH resource requester identifier request message; and an Xn AP next-generation radio access network node configuration update message.

[0044] According to an exemplary embodiment, the first response message may include at least one of the following: an Xn establishment response message; an Xn application protocol AP query early RACH resource requester identifier response message; and an Xn AP next-generation radio access network node configuration update confirmation message.

[0045] According to an exemplary embodiment, the method may further include: a second request message sent by a second node, a second response message sent by a first node, the second request message including information requesting early RACH resources allocated to the node by the candidate cell based on the UE or DU configuration; and the second response message including information related to the early RACH resources allocated to the node by the candidate cell based on the UE or DU configuration.

[0046] According to an exemplary embodiment, the second request message may include: an identifier of the candidate cell; and indication information for requesting early RACH resources allocated to the node by the candidate cell based on the UE or DU configuration.

[0047] According to an exemplary embodiment, the second response message may include: the identifier of the candidate cell; and early uplink synchronization configuration information.

[0048] According to an exemplary embodiment, the second request message may include at least one of the following: an early RACH resource request message; a UE context modification request; a UE context modification requirement message; a secondary node SN modification requirement message; and an SN modification request message.

[0049] According to an exemplary embodiment, the second response message may include at least one of the following: an early RACH resource request confirmation message; an early RACH resource response message; a UE context modification response message; a UE context modification confirmation message; an SN modification confirmation message; and an SN modification request confirmation message.

[0050] According to an exemplary embodiment, the second message is sent by the second node, and the second message includes at least one of the following: information related to the timing advance (TA) of the candidate cell; the identifier of the early RACH resource requester; and the identifier of the node to which the early RACH resource requester belongs.

[0051] According to other aspects of this disclosure, a first node, a second node, a source node DU, and a user equipment are also disclosed for performing the above-described method. According to other aspects of this disclosure, a computer-readable storage medium storing computer-executable instructions is also disclosed, which, when executed by a processor, perform the method described above by the first node, the second node, the source node DU, or the user equipment.

[0052] According to the embodiments of this disclosure, it is possible to determine which gNB-DU under the base station a candidate cell belongs to. Attached Figure Description

[0053] The above and additional aspects and advantages of this disclosure will become clearer and more readily understood from the following description taken in conjunction with the accompanying drawings, wherein:

[0054] Figure 1 This is an example system architecture that is an evolution of the system architecture according to various embodiments of this disclosure;

[0055] Figure 2 These are example system architectures based on various embodiments of this disclosure;

[0056] Figure 3 This is an exemplary flowchart of the inter-base station mobility mechanism according to this disclosure.

[0057] Figure 4 This is another exemplary flowchart of the inter-base station mobility mechanism according to this disclosure.

[0058] Figure 5 This is a flowchart of a method performed by a first node according to an exemplary embodiment of the present disclosure;

[0059] Figure 6 This is a flowchart of a method performed by a second node according to an exemplary embodiment of the present disclosure;

[0060] Figure 7 This is a flowchart of a method executed by the DU of the source node according to an exemplary embodiment of this disclosure;

[0061] Figure 8 This is a flowchart of a method performed by a UE according to an exemplary embodiment of the present disclosure;

[0062] Figure 9 Exemplary structures applicable to the various nodes of this disclosure are shown. Detailed Implementation

[0063] The following description, with reference to the accompanying drawings, is provided to aid in a thorough understanding of the various embodiments of this disclosure as defined by the claims and their equivalents. This description includes various specific details to aid understanding but should be considered exemplary only. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the various embodiments described herein without departing from the scope and spirit of this disclosure. Furthermore, for clarity and brevity, descriptions of well-known functions and structures may be omitted.

[0064] The terms and wording used in the following description and claims are not limited to their dictionary meanings, but are merely used by the inventors to enable a clear and consistent understanding of this disclosure. Therefore, it will be apparent to those skilled in the art that the following description of various embodiments of this disclosure is for illustrative purposes only and not for limiting the purpose of this disclosure as defined in the appended claims and their equivalents.

[0065] It should be understood that the singular forms of “one,” “an,” and “the” include plural references unless the context clearly indicates otherwise. Thus, for example, the reference to “component surface” includes one or more such surfaces.

[0066] The terms “comprising” or “may include” refer to the presence of a corresponding disclosed function, operation, or component that may be used in the various embodiments of this disclosure, rather than limiting the presence of one or more additional functions, operations, or features. Furthermore, the terms “comprising” or “having” may be interpreted as indicating certain characteristics, numbers, steps, operations, constituent elements, components, or combinations thereof, but should not be construed as excluding the possibility of the presence of one or more other characteristics, numbers, steps, operations, constituent elements, components, or combinations thereof.

[0067] The term "or" as used in the various embodiments of this disclosure includes any of the listed terms and all combinations thereof. For example, "A or B" may include A, may include B, or may include both A and B.

[0068] Unless otherwise defined, all terms used in this disclosure (including technical or scientific terms) have the same meaning as understood by one of those skilled in the art as described herein. Common terms as defined in dictionaries are to be interpreted as having a meaning consistent with the context in the relevant technical field and should not be interpreted ideally or overly formally unless expressly defined in this disclosure.

[0069] The following discussion Figures 1 to 9 The various embodiments used to describe the principles of this disclosure in this patent document are for illustrative purposes only and should not be construed as limiting the scope of this disclosure in any way. Those skilled in the art will understand that the principles of this disclosure can be implemented in any suitably arranged system or device.

[0070] Figure 1This is an exemplary system architecture 1000 of System Architecture Evolution (SAE). User Equipment (UE) 1001 is the terminal equipment used to receive data. Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) 1002 is the radio access network, including macro base stations (eNodeB / NodeB) that provide the UE with an interface to access the wireless network. Mobility Management Entity (MME) 1003 is responsible for managing the UE's mobility context, session context, and security information. Services Gateway (SGW) 1004 primarily provides user plane functions; MME 1003 and SGW 1004 may reside in the same physical entity. Packet Data Network Gateway (PGW) 1005 is responsible for functions such as billing and lawful interception, and may also reside in the same physical entity as SGW 1004. The Policy and Charging Rule Function (PCRF) 1006 provides Quality of Service (QoS) policies and charging criteria. The Serving GPRS Support Node (SGSN) 1008 is a network node device in the Universal Mobile Telecommunications System (UMTS) that provides routing for data transmission. The Home Subscriber Server (HSS) 1009 is the UE's home subsystem, responsible for protecting user information including the UE's current location, the address of the serving node, user security information, and the UE's packet data context.

[0071] Figure 2This is an exemplary system architecture 2000 according to various embodiments of the present disclosure. Other embodiments of system architecture 2000 can be used without departing from the scope of the present disclosure. UE 2001 is a terminal device used to receive data. Next Generation-Radio Access Network (NG-RAN) 2002 is a radio access network that includes a base station (gNB or eNB connected to the 5th Generation (5G) core network 5GC, also called an ng-gNB) providing an access radio network interface for the UE. Access and Mobility Management Function (AMF) entity.

[0072] 2003 is responsible for managing the UE's mobility context and security information. The User Plane Function (UPF) 2004 primarily provides user plane functions. The Session Management Function (SMF) 2005 is responsible for session management. The Data Network (DN) 2006 includes services such as operator services, internet access, and third-party services.

[0073] For ease of description, the following description of the embodiments of this disclosure uses proper names and their explanations:

[0074] 1. LTM (L1 / L2 Triggered Mobility): Mobility triggered by layer 1 or layer 2.

[0075] 2. SCPAC (subsequent CPAC, Subsequent Conditional PSCellAddition or Change): Continuous (or subsequent) conditional primary / secondary cell additions or changes. After a primary / secondary cell (PSCell) is added (or added), a PSCell is changed (or changed), a primary cell (PCell) is changed, or a secondary cell group (SCG) is released, a conditional PSCell addition or change procedure is performed based on the pre-configured candidate PSCell subsequent CPAC configuration, without reconfiguring and restarting the conditional primary / secondary cell change (CPC) and / or conditional primary / secondary cell addition (CPA) procedure.

[0076] 3. CHO (Conditional Handover): Conditional handover, for example, the handover process is only executed when evaluation conditions are met. The network side pre-configures resources for multiple candidate cells (these candidate cells may be located at the same base station or different base stations) based on the UE's measurement report, and pre-sends the corresponding resources and measurement configurations for each candidate cell to the UE. The UE saves the corresponding resources for each candidate cell and performs measurements to evaluate the conditions. When a candidate cell is found to meet the conditions, the UE leaves the source cell and successfully accesses the candidate cell that meets the conditions (e.g., the target cell), applying the corresponding configuration. The UE then releases all configurations for the other candidate cells, and simultaneously, the base station (or node) to which the target cell belongs notifies the source base station (or node) which candidate cell has been selected. Then, the network side performs the operation of releasing all configurations for the other candidate cells.

[0077] 4. AMF (Access and Mobility Management Function): This is a network element in the 5G core network, responsible for 5G base station access and mobility management. The 5G base station and AMF are connected via the NG-C interface.

[0078] 5. NG-RAN (New Generation Radio Access Network) node: Next-generation radio access network node, such as 5G base stations, including gNB or ng-eNB.

[0079] 6. gNB (next generation node B): Next-generation base station node, such as 5G NR (New Radio) base station.

[0080] 7. gNB-DU (Distributed Unit): gNB distributed unit. gNB-DU has functions such as RadioLink Control (RLC) protocol, Medium Access Control (MAC) and Physical Layer (PHY) protocol.

[0081] 8. gNB-CU (Central Unit): The gNB-CU has functions such as Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and Packet Data Convergence Protocol (PDCP).

[0082] 9. NR-DC (NR-NR Dual Connectivity): New Radio-to-New Radio Dual Connectivity, or Next Generation Wireless Access Network Dual Connectivity.

[0083] 10. MN (Master Node): The master node.

[0084] 11.SN (Secondary Node): Secondary node.

[0085] 12. MCG (Master Cell Group): In MR-DC (Multi-Connectivity Radio Access Network), a group of serving cells associated with the Master Node, comprising the SpCell (PCell) and optionally one or more SCells.

[0086] 13. SCG (Secondary Cell Group): In MR-DC (Multi-Connectivity Radio Access Network), a group of serving cells associated with the Secondary Node, comprising the SpCell (PSCell) and optionally one or more SCells.

[0087] 14. SpCell: The primary cell of a master or secondary cell group.

[0088] 15. SpCell: Special cell, for example, the primary cell serving the UE, the primary cell in a primary cell group or a secondary cell group (Special Cell).

[0089] 16. PSCell: Primary and secondary cell, for example, the primary cell in a secondary cell group (SpCell of asecondary cellgroup).

[0090] 17. PCell: Master cell, for example, the master cell in a master cell group (SpCellof a master cellgroup).

[0091] 18. MR-DC (Multi-Radio Dual Connectivity): Dual connectivity between E-UTRA nodes and NR nodes, or between NR nodes.

[0092] It should be understood that the message names in this disclosure are merely examples and other names may be used. Information to be transmitted between interfaces can be defined as new messages, or existing interface specifications can be used to add new information elements (IEs) to existing messages.

[0093] Exemplary embodiments of this disclosure are further described below with reference to the accompanying drawings.

[0094] The text and accompanying drawings are provided by way of example only to aid in understanding this disclosure. They should not be construed as limiting the scope of this disclosure in any way. Although certain embodiments and examples have been provided, it will be apparent to those skilled in the art, based on the content disclosed herein, that changes may be made to the illustrated embodiments and examples without departing from the scope of this disclosure.

[0095] The entities and / or nodes in this disclosure may include: gNB, gNB Central Unit (gNB-CU) , gNB Distributed Unit (gNB-DU) , gNB Central Unit Control Plane (gNB-CU-CP) , gNB Central Unit User Plane (gNB-CU-UP) , en-gNB, eNB, ng-eNB, UE, Access and Mobility Management Function (AMF) , Session Management Function (SMF) , Mobility Management Entity (MME) and other network entities or network logical units.

[0096] The switching described in this disclosure may include one or more of the following: switching, adding a secondary node, changing a secondary node, changing the primary node, etc.

[0097] In this disclosure, the term "node" can refer to a single node or a cell managed by a single node.

[0098] In this disclosure, the term "cell" can refer to a single cell or the node to which a cell is located.

[0099] In this disclosure, the source node can refer to any source node in a switchover, such as the source node, source auxiliary node, or source master node.

[0100] In this disclosure, the target node may also refer to the candidate target auxiliary node.

[0101] In this disclosure, a target node can refer to any target node in the process of switching, such as a target node, a target auxiliary node, a target master node, a candidate (alternate) target node, a candidate target source node, or a candidate target master node.

[0102] In this disclosure, a target node may refer to one or more of the following: target gNB CU, target gNB DU, target gNB CU-CP, target gNB CU-UP, etc.

[0103] In this disclosure, a source node may refer to one or more of the following: source gNB CU, source gNB DU, source gNB CU-CP, source gNB CU-UP, etc.

[0104] In this disclosure, the master node and the master base station are equivalent, the auxiliary node and the auxiliary base station are equivalent, the source node and the source base station are equivalent, the target node and the target base station are equivalent, the candidate node and the candidate base station are equivalent, the source master node and the source master base station are equivalent, the target master node and the target master base station are equivalent, the candidate master node and the candidate master base station are equivalent, the source auxiliary node and the source auxiliary base station are equivalent, the target auxiliary node and the target auxiliary base station are equivalent, and the candidate auxiliary node and the candidate auxiliary base station are equivalent.

[0105] In this disclosure, the message names are merely examples, and other message names may also be used.

[0106] In this disclosure, the use of terms such as "first" and "second" in message names is only used to distinguish one message from another and does not represent the order of execution or transmission.

[0107] Detailed descriptions of steps that are not relevant to this disclosure have been omitted in this disclosure.

[0108] In this disclosure, the steps in each process can be executed in combination or individually. The execution steps of each process are merely examples, and other possible execution steps and / or sequences are not excluded.

[0109] In this disclosure, the base station can be a 6G base station, a 5G base station (such as a gNB, ng-eNB), a 4G base station (such as an eNB), a RAN node, or other types of access nodes.

[0110] The following describes different implementations of the above process based on a scenario of LTM between base station nodes, where secondary base stations may be added, released, or the same or different secondary base stations may be added. The nodes involved in this scenario include the following:

[0111] 1. Source Master Node: The base station of the PCell currently serving the user equipment.

[0112] 2. Source and auxiliary nodes: Base stations of the PSCell currently serving user equipment.

[0113] 3. Candidate Master Node (or Target Master Node): The serving base station of the candidate master cell (PCell) or the serving base station of the target master cell prepared for the user equipment.

[0114] 4. Candidate Secondary Node (or Target Secondary Node): The serving base station of the candidate primary / secondary cell (PSCell) or the target primary / secondary cell prepared for the user equipment. Furthermore, in the scenario of primary cell group LTM without changes in secondary nodes, because the secondary node serving the user equipment does not change during the preparation of the candidate or target cell (i.e., if the user equipment switches to a candidate cell, the aforementioned source secondary node remains the same as the serving user equipment's secondary node, meaning the candidate or target secondary node is the same as the source secondary node), the PSCell serving the user equipment may or may not change.

[0115] In the following implementation, since the candidate auxiliary node or target auxiliary node is the same as the source auxiliary node, the term "source auxiliary node" is used to represent the base station of the auxiliary cell group serving the user equipment.

[0116] To reduce handover latency, LTM (Local Time Management) handover methods utilize underlying signaling to trigger the handover. However, this method requires configuring multiple candidate cells and nodes for the UE. To minimize service interruptions during LTM handover, an early synchronization process can be performed before triggering LTM. This allows the UE to synchronize downlink with candidate cells in advance and triggers an early uplink synchronization process, obtaining the timing advance (TA) value with the candidate cells. This enables the UE to perform RACH-free access. This reduces access time to the target cell (the selected candidate cell is the target cell) and minimizes the impact of data transmission service interruptions.

[0117] For the early uplink synchronization process, it is necessary to use the random access resources of candidate cells to instruct the UE to utilize them. Since the random access resources of each cell are limited, how to achieve reasonable or maximized resource utilization is a technical direction worth studying.

[0118] In some embodiments, random access resources for early TA acquisition of candidate cells can be allocated based on base station, DU, or cell, thereby improving resource utilization. During resource allocation, if all LTM base stations (source and candidate base stations) have a CU-DU separated architecture, random access resources for early TA acquisition of candidate cells can be allocated based on the principles of different gNB-DUs. In this case, the source base station can determine which base station a candidate cell belonging to (e.g., based on the cell ID or CGI information in the L3 measurement report) is located under a non-source base station (i.e., candidate base station), but cannot determine which gNB-DU it belongs to.

[0119] Figure 3 This is an exemplary flowchart of an inter-base station mobility mechanism according to the present disclosure. This embodiment includes the following steps.

[0120] Step 301: The UE sends a measurement report message to the source NG-RAN node.

[0121] For example, if the source NG-RAN node has a separate architecture for gNB-CU and gNB-DU, the UE sends a measurement report message to the source gNB-DU, which includes L3 measurement results, including measurements from neighboring cells. The source gNB-DU then sends an uplink radio resource control message transfer (UL RRC MESSAGE TRANSFER) to forward the received measurement report message to the source gNB-CU.

[0122] Step 302: Determine whether to configure LTM resources for the source NG-RAN node or source gNB-CU.

[0123] For example, the source NG-RAN node or the source gNB-CU receives an L3 measurement report from the UE and decides to perform LTM configuration.

[0124] Step 303: The source NG-RAN node or the source gNB-CU sends a handover request message to the candidate NG-RAN node or the candidate gNB-CU.

[0125] For example, the source NG-RAN node or the source gNB-CU sends a handover request message to the candidate NG-RAN node or candidate gNB-CU to which the candidate cell belongs for each candidate cell.

[0126] Optionally, the handover request message may include one or more of the following information: LTM trigger indication information (LTMindication = initiation), candidate cell ID, and Early Sync Information Request information.

[0127] For example, a candidate cell ID can indicate a candidate cell for LTM handover. The candidate cell ID can be represented by a cell ID or an NR cell global ID (CGI).

[0128] For example, the early synchronization information request information may include: early synchronization configuration request indication information. For instance, an early synchronization configuration request indication information of "yes" (Early Sync Configuration Request = true) indicates a request to configure parameters related to early synchronization.

[0129] For example, the early synchronization information request information can be used to request random access resources for early TA acquisition in candidate cells based on a first rule.

[0130] Example 1: The first rule may include allocating random access resources for early TA acquisition of candidate cells based on the principle of the base station to which the candidate cell belongs. This first rule may be simply referred to as Per-gNB. Optionally, the early synchronization information request information may include: a list of gNB IDs or a list of early RACH resources, for example, including a global gNB ID of one (source gNB) or more gNBs (including source gNB and candidate gNB), indicating that the source NG-RAN node or source gNB-CU requests the candidate NG-RAN node or candidate gNB-CU to allocate random access resources for the early TA acquisition process of the candidate cell indicated by the candidate cell ID based on each LTM NG-RAN node. Optionally, after the LTM gNB obtains the early TA random access resources allocated to each candidate cell, if the LTM gNB is a CU-DU separated architecture base station, the DU can obtain the early TA random access resources of the candidate cell through the following optional Examples 1-1 to 1-2.

[0131] Example 1-1: The CU can proactively allocate appropriate resources to the DU or UE based on the implementation. Optionally, the specific usage of the allocated resources is as described in Examples 1-1-1 to 1-1-4 below.

[0132] Example 1-1-1 illustrates that the allocated resources are used as dedicated DU resources. This means the CU (using non-UE-associated signaling) allocates appropriate resources to this DU. Different DUs have different resources, and multiple UEs on a DU can share these resources, avoiding resource conflicts caused by multiple DUs using the same resources. The UE context modification request can carry the early TA random access resources allocated by the candidate cell to the DU, and can include an indication such as a dedicated resource indication to indicate that the resource type is dedicated DU resource.

[0133] Example 1-1-2 shows that the allocated resources are used as UE-dedicated resources. That is, the CU (which can use the signaling associated with the UE) allocates appropriate resources based on the UE, with different resources for different UEs. Dedicated resources are allocated to a single UE on the DU to avoid resource conflicts caused by multiple UEs using the same resources. Optionally, for a specific UE, the early TA random access resources allocated by the candidate cell can be carried to the DU through a UE context modification request. An indication (such as a dedicated resource indication) can be carried to indicate that this resource is a UE-dedicated resource.

[0134] Example 1-1-3 illustrates the specific usage of allocated resources as one-time DU resources. This means the CU (using non-UE-associated signaling) allocates appropriate resources for this DU. Different DUs have different resources, and multiple UEs on a DU can share these resources, avoiding resource conflicts caused by multiple DUs using the same resources. The UE context modification request can carry the early TA random access resources allocated by the candidate cell to the DU, possibly carrying an indication such as "one-time resource," indicating that this resource is a one-time resource for the DU. That is, after the random access resources of a candidate cell are used once for a specific UE (e.g., the DU successfully obtains the TA value for this candidate cell from the UE), the resources are automatically released and cannot be occupied. When the DU triggers the early TA acquisition process again for this candidate cell for the UE, if all resources are exhausted, it can reapply for the random access resources for early TA acquisition from this candidate cell. The DU application mechanism is similar to the scheme described in Example 1-2 below.

[0135] Example 1-1-4 illustrates the specific usage of allocated resources as one-time resources for the UE. The CU (which can use the signaling associated with the UE) allocates appropriate resources based on the UE, with different resources for different UEs. Allocating one-time resources to a single UE on the DU avoids resource conflicts caused by multiple UEs using the same resources. Optionally, for a specific UE, the UE context modification request carries the early TA random access resources allocated by the candidate cell to the DU. This request can include an indication, such as "one-time resource," indicating that this resource is a one-time resource for the UE. That is, after the random access resources of the candidate cell are used once for this UE (e.g., the DU successfully obtains the UE's TA value for this candidate cell), the resources are automatically released and cannot be occupied. When the DU triggers the early TA acquisition process again for this candidate cell for the UE, it can re-request the random access resources for early TA acquisition from this candidate cell. The DU's request mechanism is similar to the scheme described in Example 1-2 below.

[0136] In Example 1-2, the DU requests the CU to allocate appropriate resources based on the DU or UE. The DU obtains the resources through the CU's response information. For base stations with a CU-DU separation architecture, the DU decides to trigger early TA acquisition. Optionally, the specific usage of the allocated resources is as described in Examples 1-2-1 to 1-2-4 below. The messages involved in this process and the information they may contain can be referred to in steps 317-1 and 317-2, where the DU or DU is the early RACH resource type requested by a UE. This resource type can be a DU-specific resource type or a DU one-time resource type, or a UE-specific resource type or a UE one-time resource type. Optionally, an indication (such as a dedicated resource indication) can be carried to indicate the type of this resource.

[0137] Example 1-2-1 shows that the specific usage of the allocated resources is DU-dedicated resources. That is, the DU requests the CU (which can use non-UE associated signaling) to allocate appropriate resources for this DU. Different DUs have different resources, and multiple UEs on a DU can share and use the resources to avoid resource conflicts that occur when multiple DUs use the same resources.

[0138] Example 1-2-2 illustrates the specific usage of allocated resources as UE-dedicated resources. Specifically, the DU requests the CU (using signaling associated with the UE) to allocate appropriate resources based on the UE. Different UEs receive different resources. Allocating dedicated resources to a single UE on the DU avoids resource conflicts caused by multiple UEs using the same resources. The DU can reuse the dedicated resources allocated to the UE by the candidate cell. For the UE, the early TA acquisition process can be triggered multiple times for this candidate cell, improving resource utilization.

[0139] Example 1-2-3 illustrates the specific usage of allocated resources as one-time DU resources. That is, the DU requests the CU (using signaling not associated with the UE) to allocate appropriate resources for that DU. Different DUs have different resources, and multiple UEs on a DU can share these resources, avoiding resource conflicts that occur when multiple DUs use the same resources. However, once the random access resources of a candidate cell are used once for a specific UE (e.g., the DU successfully obtains the TA value for this candidate cell from the UE), the resources are automatically released and cannot be occupied. When the DU triggers the early TA acquisition process again for this candidate cell for the UE, if all resources are exhausted, it can re-apply for the random access resources for early TA acquisition of this candidate cell.

[0140] Example 1-2-4 illustrates the specific usage of allocated resources as one-time UE resources. That is, the DU requests the CU (using signaling associated with the UE) to allocate appropriate resources based on the UE. Different UEs receive different resources. Allocating one-time resources to a single UE on the DU avoids resource conflicts caused by multiple UEs using the same resources. Once the random access resources of a candidate cell are used once for this UE (e.g., the DU successfully obtains the TA value for this candidate cell from the UE), the resources are automatically released and cannot be occupied. When the DU triggers the early TA acquisition process again for this candidate cell for the UE, it can request the random access resources for early TA acquisition from this candidate cell again.

[0141] Example 2, the first rule may include: For the source base station, if the source gNB is a CU-DU separated architecture base station, different resources are allocated based on the principle of different DUs; if the source gNB is a non-CU-DU separated architecture base station, RACH resources are requested from candidate cells based on the principle of base station allocation. This situation is the same as in Example 1 and will not be repeated here. This first rule is abbreviated as Per-DUin S-gNB+per-C-gNB. Optionally, for the candidate LTM gNB, whether the candidate LTM gNB is a CU-DU separated architecture base station or a non-CU-DU separated architecture base station, different resources are allocated based on the principle of different base stations. After the candidate LTM gNB obtains the early TA random access resources for each candidate cell, if the candidate LTM gNB is a CU-DU separated architecture base station, it can redistribute resources through the optional schemes involving CU and DU mentioned in Example 1 above. The source base station can know which gNB-DU the cell under the source base station belongs to. Optionally, the early synchronization information request information may include an early RACH resource list, for example, the early RACH resource list may include the gNB ID, and may also include the early RACH resource requester ID information. The gNB ID can include a source gNB and / or a candidate gNB, and can be represented by a global gNB ID. There is a correspondence between the early RACH resource requester ID information and the gNB-DU ID; the early RACH resource requester ID information has the same value as the gNB-DU ID. The name of the early RACH resource requester ID information can be an ID with another name, which indicates the ID of an entity requesting early RACH resources; this disclosure is not limited in this respect. Not directly using the gNB-DU ID (e.g., the early RACH resource list does not directly include the gNB-DU ID) allows the Xn interface specification to avoid exposing the base station's architecture information. Optionally, this IE will only be presented when the source gNB pointed to by the gNB ID is a gNB with a CU-DU separated architecture. For example, if the early RACH resource list includes the early RACH resource requester ID information, this ID, which indicates the ID of an entity requesting early RACH resources, can implicitly indicate the gNB-DU ID.

[0142] Example 3: The first rule may include: if all LTM base stations (source base station and candidate base station) have a CU-DU separated architecture, then the random access resources for early TA acquisition of candidate cells are allocated based on the principle of different gNB-DUs; if all LTM base stations have a non-CU-DU separated architecture, then the random access resources for early TA acquisition of candidate cells are allocated based on the principle of different base stations; if both architectures exist (CU-DU separated architecture and non-CU-DU separated architecture), then the above combination method is used: for CU-DU separated architecture base stations, the random access resources for early TA acquisition of candidate cells are allocated based on the principle of different DUs; for non-CU-DU separated architecture base stations, the random access resources for early TA acquisition of candidate cells are allocated based on the principle of different base stations. This first rule can be simply referred to as Per-gNB-DU. Optionally, the early synchronization information request information may include an early RACH resource list. For example, the early RACH resource list may include the gNB ID and may also include early RACH resource requester ID information. The specific implementation of gNB ID and early RACH resource requester ID information can be found in Example 2 above, and will not be repeated here.

[0143] Based on the cell ID or CGI information in the L3 measurement report, the source base station can determine which base station a candidate cell belonging to is not from the source base station (i.e., the candidate base station), but it cannot determine which gNB-DU under that base station it belongs to. The gNB-DU under the base station can be determined based on the early RACH resource requester ID information. The method for obtaining the early RACH resource requester ID information can refer to steps 300-1 to 300-2 below, or steps 302-1 to 302-2 below.

[0144] Step 300-1: The source NG-RAN node or source gNB-CU sends an Xn establishment request message to the candidate NG-RAN node or candidate gNB-CU. Alternatively, the source NG-RAN node or source gNB-CU sends an NG-RAN node configuration update message to the candidate NG-RAN node or candidate gNB-CU.

[0145] Step 300-2: The candidate NG-RAN node or candidate gNB-CU sends an Xn setup response message to the source NG-RAN node or source gNB-CU. Alternatively, the source NG-RAN node or source gNB-CU sends an NG-RAN node configuration update confirmation message to the candidate NG-RAN node or candidate gNB-CU.

[0146] For example, two adjacent NG-RAN nodes or gNB-CUs can exchange the early RACH resource requester ID information of the cell during the Xn interface establishment process (Xn establishment request message and / or Xn establishment response message) or during NG-RAN node configuration update (NG-RAN node configuration update message and / or NG-RAN node configuration update confirmation message). Alternatively, during the Xn interface establishment process or NG-RAN node configuration update process, a query process can be triggered to the base station where the candidate cell is located to query whether the candidate cell on the candidate base station has its own gNB-DU ID information. For example, the Xn establishment request message and / or NG-RAN node configuration update message can be used to request the query for the early RACH resource requester ID or the gNB-DU ID information of the candidate cell. Accordingly, if the query is successful, the Xn establishment response message and / or NG-RAN node configuration update confirmation message contains the requested gNB-DU ID information of the candidate cell or an implicit mapping of gNB-DU ID information, such as the early RACH resource requester ID information. If the query fails, i.e., the candidate base station is not a CU-DU separated architecture base station, a failure message can be replied (Xn establishment failure message and / or NG-RAN node configuration update failure message), or the Xn establishment response message and / or NG-RAN node configuration update confirmation message may not contain the gNB-DUID information to which the requested candidate cell belongs, or information implicitly mapping the gNB-DUID. There is a correspondence between the early RACH resource requester ID information and the gNB-DU ID, and the value of the early RACH resource requester ID information is the same as the value of the gNB-DU ID. The name of the early RACH resource requester ID information can be an ID with other names, indicating the ID of an entity requesting early RACH resources, which may be a gNB-DU, or indicating the early RACH resource requester ID. It can also be other names, such as base station sub-level ID (gNB-Sub Level ID) or other names; this disclosure is not limited in this regard.

[0147] Optionally, the Xn setup response message may include the early RACH resource requester ID information. Alternatively, the NG-RAN node configuration update confirmation message may include the early RACH resource requester ID information. Explicitly or implicitly identifying the gNB-DU ID information of the candidate cell belonging to the non-source base station (i.e., candidate base station).

[0148] Optionally, the Xn establishment request message may include early RACH resource requester ID information. Alternatively, the NG-RAN node configuration update message may include early RACH resource requester ID information. Explicitly or implicitly, the message may identify the gNB-DUID information of the candidate cell under the base station that initiated the message.

[0149] For example, early RACH resource requester ID information may include one or more of the following: Served Cell Information (NR), NR Neighbour Information (NR), and E-UTRA Neighbour Information (E-UTRA). For instance, Served Cell Information includes early RACH resource requester ID information, NR Neighbour Information includes early RACH resource requester ID information, and E-UTRA Neighbour Information includes early RACH resource requester ID information.

[0150] The serving NR cell information may include the gNB-DUID information of the candidate cell under the non-source base station (i.e., candidate base station) or an ID information mapped to the gNB-DUID. The NR neighbor cell information may include the gNB-DUID information of the candidate cell under the non-source base station (i.e., candidate base station) or an ID information mapped to the gNB-DUID. The E-UTRA neighbor cell information may include the gNB-DUID information of the candidate cell under the non-source base station (i.e., candidate base station) or an ID information mapped to the gNB-DUID. Optionally, this ID information is the same as the value of the gNB-DU ID, i.e., it corresponds to the gNB-DU ID. Not directly using the gNB-DU ID allows the Xn interface specification to avoid exposing the base station's architecture information.

[0151] Thus, the early RACH resource requester ID information indicates the gNB-DUID to which it belongs or an ID information that maps to the gNB-DUID. Therefore, when the gNB node has a separate gNB-CU and gNB-DU architecture, the gNB-CU can know which gNB-DU a neighboring cell belongs to under the neighboring gNB.

[0152] Step 302-1: The source NG-RAN node or the source gNB-CU sends an identifier request message to the candidate NG-RAN node or the candidate gNB-CU.

[0153] Step 302-2: The candidate NG-RAN node or candidate gNB-CU sends an identification response message to the source NG-RAN node or source gNB-CU.

[0154] Optionally, steps 302-1 and 302-2 can be performed after step 301 and before step 302, or after step 302 and before step 303.

[0155] After the source gNB-CU receives the L3 measurement report from the UE, before or after triggering the LTM configuration decision and before sending the handover request message to the candidate base station, it first triggers a query process with the base station where the candidate cell is located to check whether the candidate cell on the candidate base station has its own gNB-DU ID information. When the candidate gNB-CU or candidate NG-RAN receives the identification request message, it sends an identification response message to the source gNB-CU or source NG-RAN.

[0156] Optionally, the identification request message can be used to request the query of the early RACH resource requester ID or the gNB-DU ID information of the candidate cell. The identification request message can be a non-UE associated message, a new message (e.g., named "Retrieve Early RACH ResourcesRequesterID Request"), or an existing message (e.g., using an NG-RAN node configuration update message).

[0157] For example, the identification request message may include one or more of the following information: a candidate cell list, a candidate cell ID, and an early RACH resource requester ID request indication. The candidate cell list may include one or more candidate cell IDs. The candidate cell ID can be represented by a cell ID or an NR CGI. The early RACH resource requester ID request indication indicates the gNB-DU ID information to which the candidate cell indicated by the candidate cell ID belongs, or an implicit mapping ID information of a gNB-DU ID, such as the early RACH resource requester ID information. This ID can also be another name; it indicates the ID of an entity requesting early RACH resources, which may be a gNB-DU or an early RACH resource requester ID.

[0158] For example, when a candidate gNB-CU or candidate NG-RAN receives an identification request message, it sends an identification response message to the source gNB-CU or source NG-RAN. If the candidate base station is a CU-DU separated architecture base station, the identification response message can indicate a successful query. It can be a new message, such as one named "RetrieveEarly RACH Resources Requester ID Response," or an existing message, such as an NG-RAN node configuration update confirmation message. Optionally, the identification response message can include one or more of the following information: a candidate cell list, candidate cell IDs, early RACH resource requester ID information, and gNB IDs. The candidate cell list can include one or more candidate cell IDs. The candidate cell ID can be represented by a cell ID or an NR CGI. The early RACH resource requester ID information can be used to implicitly indicate a mapped ID of the gNB-DU ID to which the candidate cell belongs, or it can be another name. This ID indicates the ID of an entity requesting early RACH resources; the entity can be a gNB-DU, or it can indicate the early RACH resource requester ID. gNBID can refer to the ID of the gNB to which an early RACH resource requester belongs. For example, an early RACH resource requester is a DU under the gNB indicated by the gNB ID.

[0159] If the candidate gNB is a CU-DU separated architecture base station, the candidate gNB-CU (via F1 establishment request or gNB-DU configuration update message sent from the gNB-DU to the gNB-CU) can determine which gNB-DU the candidate cell belongs to. The candidate gNB-CU can return the gNB-DU ID information of the candidate cell or an ID information mapped to the gNB-DU ID, which can be called the Early RACH Resource Requester ID, or base station sub-ID, etc. This ID has the same value as the gNB-DU ID and can correspond to the gNB-DU ID. Not directly using the gNB-DU ID can prevent the base station's architecture information from being exposed in the Xn interface specification. This ID indicates the ID of an entity requesting early RACH resources, which can be a gNB-DU or indicate the Early RACH Resource Requester ID.

[0160] If the candidate base station is not a CU-DU separated architecture base station, then the candidate cell does not have associated gNB-DU information. The identification response message can indicate query failure, returning a query failure indication message, or returning an indication that the candidate cell does not have an associated Early RACH Resources Requester ID (or using empty information to indicate non-existence), to indicate that the requested candidate cell does not have associated gNB-DU information. Optionally, the identification response message can be a new message, such as one named "Retrieve Early RACH Resources RequesterIDFailure," or an existing message, such as an Xn establishment failure message or an NG-RANNODE CONFIGURATION UPDATE FAILURE message.

[0161] Example 4: The first rule may include allocating random access resources for early TA acquisition in a candidate cell based on the principle of allocating random access resources for each candidate cell based on each of the other distinct candidate cells (excluding the candidate cell indicated by the candidate cell ID). This first rule may be simply referred to as Per-Cell. For example, the random access resources for early TA acquisition in one candidate cell may be allocated differently for each of the other candidate cells. Different resources for different cells allow multiple UEs on the same cell to share the resources, avoiding resource conflicts that occur when multiple cells use the same resources. To support subsequent LTM, the early synchronization information request information may optionally include: a list of Cell IDs or an early RACH resource list, for example, including the Cell IDs of one (source Cell) or multiple cells (including source Cells and candidate Cells), which can be represented by Cell ID or NR CGI, indicating that the source NG-RAN node or source gNB-CU requests the candidate NG-RAN node or candidate gNB-CU to allocate random access resources for the early TA acquisition process based on each of the other distinct candidate cells (excluding the candidate cell indicated by the candidate cell ID).

[0162] Example 5: The first rule may include random access resources for early TA acquisition based on the allocation of candidate cells to the UE. This first rule can be simply referred to as Per-UE. Signaling associated with the UE can be used. Thus, different UEs have different resources, avoiding resource conflicts that occur when multiple UEs use the same resources. Optionally, the requested resource allocation can indicate the resource type, such as UE-specific resources or UE-only resources. Specific usage is described in Example 5-1 or Example 5-2 below, and will not be repeated here.

[0163] Example 5-1 shows that the resource type is UE-dedicated resource. Appropriate dedicated resources can be allocated to candidate cells based on the UE's associated signaling request. Different UEs are allocated different dedicated resources, avoiding resource conflicts caused by multiple UEs using the same resources. The DU can reuse the dedicated resources allocated to the UE by the candidate cell, and the UE can trigger the early TA acquisition process multiple times for this candidate cell, improving resource utilization.

[0164] Example 5-2 shows a resource type of UE-only resource. Different UEs can request different UE-only resources from candidate cells using signaling associated with the UE, thus avoiding resource conflicts caused by multiple UEs using the same resource. Once the random access resource of a candidate cell is used once for this UE (e.g., the DU successfully obtains the TA value for this candidate cell), the resource is automatically released and cannot be occupied. When the DU triggers the early TA acquisition process again for this candidate cell for the UE, it needs to request the random access resource for early TA acquisition from this candidate cell again.

[0165] Thus, random access resources acquired in the early TA acquisition of candidate cells can be allocated based on base stations, DUs, or cells, or any combination of both. However, if the allocated resources are limited or insufficient—for example, if resources allocated to one base station need to be used by multiple subordinate DUs, there may be a situation where resources are insufficient, meaning that even one resource per DU is not enough—then it may be possible to consider supporting a request for more random access resources for early TA acquisition from candidate cells based on DUs, base stations, or cells. The F1 and Xn interface signaling involved, whether new messages or utilizing existing information, may contain at least one of the following: candidate cell ID, early synchronization information request, base station list, DU list, or cell list.

[0166] The candidate cell ID may include at least one candidate cell ID information, used to indicate that a request for an early TA to obtain random access resources has been made to the indicated candidate cell.

[0167] Early synchronization information requests may include triggering indicators, such as more resources, resource expansion, insufficient resources, fewer resources, reduced resources, and excessive resources.

[0168] The base station list contains at least one base station ID, the DU list contains at least one DU ID, and the cell list contains at least one cell ID information, which are used to indicate that the candidate cell indicated by the candidate cell ID requests that these base stations, DUs, or cells allocate the appropriate number of random access resources for early TA acquisition according to the trigger indication.

[0169] After receiving the message containing the above information, the node where the corresponding candidate cell is located performs the corresponding action. The candidate cell indicated by the candidate cell ID is one of these base stations, DUs or cells. The node allocates an appropriate number of random access resources for early TA acquisition according to the triggering instruction and replies to the final requesting node, such as the base station or DU.

[0170] The different allocation principles of random access resources for early TA acquisition in the aforementioned candidate cells correspond to the following: when the UE triggers the sending of a preamble to the corresponding candidate cell using the random access resources indicated by the DU, after the candidate DU calculates the TA information of the UE for the corresponding candidate cell, it needs to transmit the TA information to the source DU through the interface signaling between network nodes. Since the transmission of TA information may involve signaling not associated with the UE, it is necessary for the source DU to provide auxiliary information on how to identify which UE the received TA information of the candidate cell is for. The specific content is introduced in the implementation below.

[0171] Optionally, if the NG-RAN node is not an architecture where gNB-CU and gNB-DU are separate, the corresponding F1 interface messages and procedures will not be involved.

[0172] Step 304: The candidate gNB-CU sends a UE context establishment request message to the gNB-DU to which the candidate cell belongs.

[0173] For example, step 304 is optional. If the candidate NG-RAN node has a separate architecture of gNB-CU and gNB-DU, the candidate gNB-CU sends a UE context establishment request message to the gNB-DU to which the candidate cell belongs.

[0174] Optionally, the UE context establishment request message may include one or more of the following information: LTM trigger indication information, candidate cell ID, and early synchronization information request information. For example, the candidate cell ID may indicate a candidate cell for LTM handover. The candidate cell ID can be represented by a cell ID or an NR cell global ID (CGI).

[0175] For example, the early synchronization information request information may include early synchronization configuration request indication information. The early synchronization information request information can be used to request random access resources for early TA acquisition in candidate cells based on a first rule. The specific implementation methods of the early synchronization information request information and the early synchronization configuration request indication information can be referred to the corresponding description in step 303 above, and will not be repeated here.

[0176] Corresponding to Example 1 in step 303, the early synchronization information request information may include: a gNBID list or an early RACH resource list, for example, including a global gNB ID of one (source gNB) or more gNBs (including source gNB and candidate gNB), indicating that the candidate gNB-CU requests the candidate cell ID indicated by the candidate cell ID from the candidate gNB-DU to allocate random access resources for the early TA acquisition process of the candidate cell indicated by the candidate cell ID based on each LTM NG-RAN node.

[0177] Corresponding to Example 2 in step 303, the early synchronization information request information may include an early RACH resource list. For example, the early RACH resource list may include a gNB ID and a gNB-DU ID. The gNB ID may include a source gNB and / or a candidate gNB, and can be represented by a global gNBID. The gNB-DUID corresponds to the early RACH resource requester ID information in the Xn interface information, converting the early RACH resource requester ID information into the corresponding gNB-DUID. If the early RACH resource list includes a gNB-DUID, it indicates that early RACH resources are allocated based on the gNB-DU indicated by the gNB-DU ID. If the early RACH resource list does not include a gNB-DU ID, it indicates that early RACH resources are allocated based on the gNB indicated by the gNB ID.

[0178] Corresponding to Example 3 in step 303, the early synchronization information request information may include an early RACH resource list. For example, the early RACH resource list may include a gNB ID and a gNB-DU ID (if the requested gNB is a CU-DU separated architecture base station). The gNB ID may include a source gNB and / or a candidate gNB, and can be represented by a global gNB ID. The gNB-DU ID corresponds to the early RACH resource requester ID information in the Xn interface information. If the early RACH resource list includes a gNB-DU ID, it indicates that early RACH resources are allocated based on the gNB-DU indicated by the gNB-DU ID. If the early RACH resource list does not include a gNB-DU ID, it indicates that early RACH resources are allocated based on the gNB indicated by the gNB ID.

[0179] Corresponding to Example 4 in step 303, the early synchronization information request information may include: a list of gNB IDs or a list of early RACH resources, for example, a global gNB ID including one (source gNB) or multiple gNBs (including source gNB and candidate gNB), which can be represented by cell ID or NR CGI. This indicates that the candidate NG-RAN node or candidate gNB-CU requests the candidate gNB-DU to allocate random access resources for early TA acquisition from the candidate cell indicated by the candidate cell ID based on each of the other different candidate cells (candidate cells other than the candidate cell indicated by the candidate cell ID).

[0180] Corresponding to Example 5 in step 303, the early synchronization information request information can be used to request random access resources for early TA acquisition based on the allocation of candidate cells for the UE. The early synchronization information request information can also request the type of resource to be allocated, such as UE-specific resources or UE one-time resources, which can be explained in detail in Example 5 in step 303, and will not be repeated here.

[0181] Step 305: The candidate gNB-DU sends a UE context establishment response message to the candidate gNB-CU.

[0182] For example, if the candidate gNB-DU accepts the LTM configuration request, it can send a UE context establishment response message to the candidate gNB-CU in response.

[0183] The UE context establishment response message may include one or more of the following information: candidate cell ID and early synchronization information response information. The candidate cell ID can be represented by a cell ID or NR CGI. The early synchronization information response information may include early uplink synchronization configuration information, which may include one or more of the following: RACH configuration information and an early RACH resource list.

[0184] The RACH configuration information can be the Early UL-SyncConfig IE defined in TS 38.331, which represents the common part of the allocated early RACH resources. The different parts allocated to each node are indicated by the preamble index information.

[0185] Corresponding to Example 1 in step 303, when the first rule is Per-gNB, the early RACH resource list can also be an LTM gNB list. The early RACH resource list includes one or more LTM gNB IDs and the corresponding allocated PRACH resources, such as a preamble index list. Alternatively, the LTM gNB list includes one or more LTM gNB IDs and the corresponding allocated PRACH resources. The LTM gNB ID can be indicated by a global gNB ID, and the preamble index list can include one or more preamble indices representing different portions of the PRACH resources allocated to the gNB indicated by the LTM gNB ID.

[0186] Corresponding to Example 2 in step 303, when the first rule is Per-DU in S-gNB+per-C-gNB, the early RACH resource list may include one or more of the following information: preamble index list, gNB ID, and gNB-DU ID.

[0187] The preamble index list may include one or more preamble indices, representing different portions of the PRACH resources allocated for the indicated gNB ID or gNB-DUID. The gNB ID includes a source gNB ID and candidate gNB IDs, which can be represented by a global gNB ID. The gNB-DU ID is optional; it corresponds to the early RACH resource requester ID information in the Xn interface information, converting the early RACH resource requester ID into the corresponding gNB-DU ID. Optionally, if the early RACH resource list includes a gNB-DU ID, it indicates that early RACH resources are allocated based on the gNB-DU indicated by the gNB-DU ID; if the early RACH resource list does not include a gNB-DU ID, it indicates that early RACH resources are allocated based on the gNB indicated by the gNB ID.

[0188] Corresponding to Example 3 in step 303, when the first rule is Per-gNB-DU, the early RACH resource list may include one or more of the following information: a preamble index list, gNB ID, and gNB-DU ID.

[0189] Similarly, the preamble index list may include one or more preamble indices representing different portions of the PRACH resources allocated for the indicated gNBID or gNB-DU ID. The gNB ID includes a source gNBID and candidate gNB IDs, which can be represented by a global gNB ID. The gNB-DU ID is optional; it corresponds to the early RACH resource requester ID information in the Xn interface information, converting the early RACH resource requester ID into the corresponding gNB-DU ID. Optionally, if the early RACH resource list includes a gNB-DU ID, it indicates that early RACH resources are allocated based on the gNB-DU indicated by the gNB-DU ID; if the early RACH resource list does not include a gNB-DU ID, it indicates that early RACH resources are allocated based on the gNB indicated by the gNB ID.

[0190] Corresponding to Example 4 in step 303, when the first rule is Per-Cell, the early RACH resource list may include one or more of the following information: LTM cell ID and a preamble index list. The LTM cell ID can be indicated by a cell ID or NR CGI. The preamble index list may include one or more preamble indices representing different portions of the PRACH resources allocated for the indicated gNB ID.

[0191] Corresponding to Example 5 in step 303, when the first rule is Per-UE, the early RACH resource list may include LTM early RACH resource configuration information, which includes RACH-ConfigDedicated configuration. Alternatively, the early RACH resource list may include a preamble index, for example, by allocating a preamble index in conjunction with RACH configuration information.

[0192] Step 306: The candidate gNB or candidate gNB-CU sends a handover request confirmation message to the source gNB or source gNB-CU.

[0193] For example, the candidate gNB or candidate gNB-CU responds to the source gNB or source gNB-CU with a handover request confirmation message in response to the requested candidate cell. Optionally, the handover request confirmation message includes one or more of the following information: candidate cell ID and early synchronization information response information.

[0194] The early synchronization information response may include one or more of the following: RACH configuration information and an early RACH resource list. The specific implementation of the RACH configuration information can be found in step 305 above, and will not be repeated here.

[0195] Corresponding to Example 1 in step 303, when the first rule is Per-gNB, the specific implementation of the early RACH resource list can be referred to the corresponding description in step 305 above, and will not be repeated here.

[0196] Corresponding to Example 2 in step 305, when the first rule is Per-DU in S-gNB+per-C-gNB, the early RACH resource list may include one or more of the following information: a preamble index list, a gNB ID, and early RACH resource requester ID information. The specific implementation of the preamble index list and gNB ID can be found in the corresponding description in step 305 above, and will not be repeated here. The early RACH resource requester ID information corresponds to the early RACH resource requester ID information in the Xn interface switching request message. If the early RACH resource list includes the early RACH resource requester ID information, it indicates that early RACH resources are allocated based on the gNB-DU mapped by the early RACH resource requester ID information. If the early RACH resource list does not include the early RACH resource requester ID information, it indicates that early RACH resources are allocated based on the gNB indicated by the gNB ID.

[0197] Corresponding to Example 3 in step 303, when the first rule is Per-gNB-DU, the early RACH resource list may include one or more of the following information: a preamble index list, a gNB ID, and early RACH resource requester ID information. The specific implementation methods for the preamble index list and gNB ID can be referred to the corresponding description in step 305 above, and will not be repeated here. The specific implementation method for the early RACH resource requester ID information can be referred to the corresponding description in step 306 above (corresponding to Example 2 in step 303).

[0198] Corresponding to Example 4 in step 303, when the first rule is Per-Cell, the early RACH resource list may include one or more of the following information: LTM cell ID and preamble index list. The specific implementation method can be found in the corresponding description in step 305 above, and will not be repeated here.

[0199] Corresponding to Example 5 in step 303, when the first rule is Per-UE, the early RACH resource list may include LTM early RACH resource configuration information, which includes RACH-ConfigDedicated configuration. Alternatively, the early RACH resource list may include a preamble index, for example, by allocating a preamble index in conjunction with RACH configuration information.

[0200] Step 307: The source gNB-CU sends a context modification request message to the source gNB-DU.

[0201] Optionally, the context modification request message may include RACH configuration information, or the context modification request message may be used to request access to an earlier RACH resource.

[0202] For example, if the source gNB has a separate gNB-CU and gNB-DU architecture, the source gNB-CU can send a UE context modification request message based on the RACH configuration allocated to this gNB for each candidate cell, and continue to allocate the corresponding RACH configuration to the source gNB-DU or other candidate gNB-DUs under its jurisdiction. Alternatively, the gNB-DU can request early RACH resources from the gNB-CU; the specific implementation can be found in the schemes in Examples 1-2 above.

[0203] If the early RACH resources are based on DU, cell, or UE-allocated RACH resources, the source gNB can forward all candidate cells' RACH resources allocated to the corresponding DU, cell, or UE under the source gNB to the corresponding DU.

[0204] For the source cell, the source gNB-CU can send a UE context modification request message to the source gNB-DU to request the source cell to allocate early RACH resources to other gNBs, DUs, cells, or this UE. The UE context modification request message includes early synchronization information request information. The specific implementation of the early synchronization information request information can be referred to step 304 above, and will not be described again here.

[0205] Step 308: The source gNB-DU sends a UE context modification response message to the source gNB-CU.

[0206] For example, if the source gNB-DU accepts the LTM configuration request, it sends a UE context modification response message as a response. The UE context modification response message includes early synchronization information response information. The specific implementation of the early synchronization information response can be referred to step 305 above, and will not be described again here.

[0207] Step 309: The source gNB or source gNB-CU sends an LTM configuration update message to the candidate gNB or candidate gNB-CU.

[0208] For example, to support subsequent LTM, the source gNB or source gNB-CU collects the LTM configuration information of all candidate cells that have accepted the LTM request, as well as the early RACH resource information allocated to each candidate cell, and can convey this information to each other candidate gNB or candidate gNB-CU via the Xn interface message. The Xn interface message can be an LTM configuration update message.

[0209] Optionally, the LTM configuration update message includes one or more of the following information: Early Sync Candidate Cell Information List, candidate cell ID, transport channel indication status configuration list, and early uplink synchronization configuration information.

[0210] The early synchronization candidate cell information list includes early uplink synchronization configuration information allocated by one or more candidate cells to the corresponding gNB or DU under the gNB or cell or UE.

[0211] The Transmission Channel Indication (TCI) status configuration list can be the LTM-TCI-Info IE (LTM-TCI-Info IE) defined in TS38.331.

[0212] The specific implementation method of early uplink synchronization configuration information can be referred to step 305 above, and will not be described again here.

[0213] Step 310: The candidate gNB-CU sends a UE context modification request message to the candidate gNB-DU.

[0214] For example, if the candidate gNB has a separate gNB-CU and gNB-DU architecture, the candidate gNB-CU can send a UE context modification request message based on the RACH configuration allocated to this gNB for each candidate cell, and continue to allocate the corresponding RACH configuration to the candidate gNB-DU. Alternatively, the candidate gNB-DU can request early RACH resources from the candidate gNB-CU. For specific implementation methods, please refer to the schemes in Examples 1-2 above.

[0215] If the early RACH resources are based on DU, cell, or UE-allocated RACH resources, the candidate gNB can forward all RACH resources allocated by the candidate cells to the corresponding DU, cell, or UE under the candidate gNB to the corresponding DU.

[0216] Step 311: The candidate gNB-DU sends a UE context modification response message to the candidate gNB-CU.

[0217] Step 312: The candidate gNB or candidate gNB-CU sends an LTM configuration update confirmation message to the source gNB or source gNB-CU.

[0218] For example, a candidate gNB or candidate gNB-CU sends a response message, such as an LTM configuration update confirmation message, to the source gNB or source gNB-CU.

[0219] Step 313: The source gNB-CU sends a downlink RRC message to the source gNB-DU.

[0220] For example, after the network side completes the LTM-related configuration, the UE's RRC reconfiguration process is performed. The source gNB-CU sends a downlink RRC message transfer (DL RRC MESSAGE TRANSFER) to the source gNB-DU. Optionally, the downlink RRC message transfer includes an RRC reconfiguration message, which includes LTM configuration.

[0221] Step 314: The source gNB-DU sends an RRC reconfiguration message to the UE.

[0222] For example, the source gNB-DU forwards the received RRC reconfiguration message to the UE.

[0223] Step 315: The UE sends an RRC reconfiguration complete message to the source gNB-DU.

[0224] Step 316: The source gNB-DU sends an RRC reconfiguration complete message to the source gNB-CU.

[0225] For example, the source gNB-DU forwards the RRC reconfiguration complete message to the source gNB-CU via an uplink RRC message passing message.

[0226] Step 317-1: The source gNB-DU sends an early RACH resource request message to the source gNB-CU; the source gNB-CU sends an early RACH resource request message to the candidate gNB-CU or candidate gNB; and the candidate gNB-CU sends an early RACH resource request message to the candidate gNB-DU.

[0227] In some embodiments, for random access resources requested by the UE for early TA acquisition, in addition to those acquired and used during the LTM configuration preparation process as described above, for one-time resource types, the source gNB or source gNB-DU automatically releases the resource after it is used. It is possible that when the TA expires, the early TA acquisition process may be triggered again for the UE, or after the UE performs an LTM, a new source gNB or gNB-DU may need to trigger the early TA acquisition process for the UE. Optionally, the resource may be requested again using signaling associated with the UE.

[0228] As in step 317-1, the source gNB-DU sends a message to the source gNB-CU, such as a new message (e.g., the message name could be an early RACH resource request message) or an existing message (e.g., a UE context modification request message). Correspondingly, the source gNB-CU sends UE-related messages to the candidate gNB or candidate gNB-CU, such as new messages (e.g., the message name could be an early RACH resource request message) or an existing message (e.g., an LTM configuration update message). If... Figure 4 In the DC scenario, the source SN can utilize existing messages such as the SN Modification Request message (S-NODE MODIFICATIONREQUIRED), and the MN can utilize the SN Modification Request message (S-NODE MODIFICATION REQUEST). Correspondingly, the candidate gNB-CU sends UE-related messages to the candidate NB-DU, such as new messages, like the message name "Early RACH Resource Request Message," or the message can be an existing message, such as the UE Context Modification Request Message.

[0229] Optionally, the early RACH resource request message may include one or more of the following information: a list of candidate cells, candidate cell IDs, and early synchronization information request information. Similarly, UE context modification request messages, LTM configuration update messages, or UE context modification request messages may also include this information.

[0230] The candidate cell information list includes the IDs of one or more candidate cells. The early synchronization information request information may include early synchronization configuration request indication information. For example, an early synchronization configuration request indication of "yes" (Early SyncConfiguration Request = true) indicates a request to configure parameters related to early synchronization.

[0231] Step 317-2: The candidate gNB-DU sends an early RACH resource response message to the candidate gNB-CU, the candidate gNB-CU sends an early RACH resource response message to the source gNB-CU or the source gNB, and the source gNB-CU sends an early RACH resource response message to the source gNB-DU.

[0232] For example, the candidate gNB-DU allocates the corresponding early RACH resources for the UE for the requested candidate cell. As in step 317-2, the candidate gNB-DU sends a message to the candidate gNB-CU, such as a new message, such as an early RACH resource request confirmation message or an early RACH resource response message, or uses an existing message, such as a UE context modification response message.

[0233] Accordingly, the candidate gNB-CU sends UE-related messages to the source gNB-CU or source gNB, such as new messages, like "Early RACH Resource Request Confirmation Message" or "Early RACH Resource Response Message," or utilizes existing messages, such as "LTM Configuration Update Message Confirmation Message." If it is... Figure 4 For the DC scenario, the candidate SN can use existing messages such as the SN Modification Request Acknowledgment Message (S-NODE MODIFICATION REQUEST ACKNOWLEDGE), and the MN can use the SN Modification Acknowledgment Message (S-NODE MODIFICATION CONFIRM).

[0234] Accordingly, the source gNB-CU sends UE-related messages to the source gNB-DU, such as new messages, like the message name Early RACH Resource Request Confirmation Message or Early RACH Resource Response Message, or utilizes existing messages, such as UE Context Modification Confirmation Message.

[0235] Once a gNB-DU or gNB obtains early RACH resources allocated to a candidate cell for a UE, it may consider triggering an early TA acquisition process for that UE to the corresponding candidate cell.

[0236] Optionally, the early RACH resource response message may include one or more of the following information: a candidate cell information list, a candidate cell ID, and early uplink synchronization configuration information. The candidate cell information list includes early RACH resource configuration information allocated to one or more candidate cells. The early uplink synchronization configuration information can be indicated using LTM early RACH resource configuration information, or it can be represented by combining RACH configuration information and the allocation of at least one preamble index. Similarly, the UE context modification response message, LTM configuration update message confirmation message, or UE context modification confirmation message may also include this information, which will not be elaborated further.

[0237] Once a gNB-DU or gNB obtains early RACH resources allocated to a candidate cell for a UE, it may consider triggering an early TA acquisition process for that UE to the corresponding candidate cell.

[0238] Step 318-1: The source gNB-DU sends a PDCCH command to the UE.

[0239] Step 318-2: The UE sends a random access request message to the candidate cell.

[0240] For example, early synchronization is performed to obtain an early timing advance (TA) value. This process involves the UE receiving a PDCCH order from the serving UE's gNB-DU and then sending a random access request message to the candidate cell using the random access resource configuration indicated in the PDCCH order. The random access resource configuration indicated in the PDCCH order can be specified through parameters such as the Random Access Preamble Index, the Synchronization Signal / PBCH Block Index (SSB index), and the PRACH Occurrence Mask Index. Upon receiving the random access request message, the candidate cell calculates the timing advance (TA) value between the UE and the candidate cell.

[0241] Step 319: The candidate gNB-DU sends a TA information transfer message to the candidate gNB-CU.

[0242] For example, the candidate gNB-DU sends the TA value and associated information to the candidate gNB-CU through a non-UE associated DU-CU TA information transmission (DU-CU TAINFORMATION TRANSFER) message.

[0243] For example, a DU-CU TA information transmission message may include one or more of the following information: TA information list, candidate cell ID, TA value, preamble index, Random Access-Radio Network Temporary Indentifier (RA-RNTI), and resource indication information.

[0244] The TA information list may include the TA values ​​of one or more candidate cells and the RACH resource information used. The same UE may have different TA values ​​for different candidate cells, and different UEs may have different TA values ​​for the same candidate cell.

[0245] Resource indication information can indicate that the RACH resources utilized by the UE are information previously allocated to the corresponding node or cell for this candidate cell.

[0246] Depending on the different allocation principles, the resource indication information includes the following information.

[0247] When the first rule is Per-gNB, the resource indication information includes the LTM gNB ID, the source gNB, which can be indicated by the global gNB ID.

[0248] In the case of the first rule being Per-DU in S-gNB+per-C-gNB, the resource indication information includes the gNB ID. If the source gNB is a base station with a CU-DU separation architecture, the resource indication information may also include the gNB-DU ID. The gNB ID indicates the source gNB, and the gNB ID can be indicated by the global gNB ID.

[0249] In the case of the first rule being Per-gNB-DU, the resource indication information includes the gNB ID. If the source gNB is a CU-DU separated architecture base station, the resource indication information may also include the gNB-DU ID. The gNB ID indicates the source gNB, and the gNB ID can be indicated by the global gNB ID. If the gNB ID information is included in the F1AP DU-CU TA information transmission message, the gNB-CU will continue to forward this TA information to the gNB indicated by the gNB ID information.

[0250] When the first rule is Per-Cell, the resource indication information includes the LTM cell ID, which can be indicated by either a cell ID or an NR CGI.

[0251] When the first rule is Per-UE, the resource indication information includes the gNB-CU UE F1AP ID and / or gNB-DU UE F1AP ID, or the TA information of the candidate cell is transmitted in a message associated with a UE.

[0252] Step 320: The candidate gNB or candidate gNB-CU sends a TA information transmission message to the source gNB or source gNB-CU.

[0253] For example, a candidate gNB or candidate gNB-CU forwards TA-related information to the corresponding source gNB or source gNB-CU via newly defined Xnap information (e.g., TA information transmission message) not associated with the UE. The candidate gNB-CU can then determine which node to forward the information to based on the aforementioned resource indication information.

[0254] Optionally, the TA information transmission message may include one or more of the following information: TA information list, candidate cell ID, TA value, preamble index, random access radio network temporary identifier, and resource indication information. The resource indication information may indicate that the RACH resource utilized by the UE is information previously allocated to the corresponding node or cell for this candidate cell.

[0255] Depending on the different allocation principles, the resource indication information includes the following information.

[0256] When the first rule is Per-gNB, the TA information transmission message may not include resource indication information. For early RACH resources allocated based on gNB principles, if the base station has a CU-DU separated architecture, the gNB-CU knows which gNB-DU it will allocate the resources to (using the allocation schemes in Example 1-1 or Example 1-2 above). If the base station is not a CU-DU separated architecture, the gNB can determine which UE the TA value of the candidate cell is for by utilizing the RACH resources.

[0257] When the first rule is Per-DUin S-gNB+per-C-gNB, the resource indication information may include the early RACH resource requester ID information. The early RACH resource requester ID information corresponds to the early RACH resource requester ID information in the Xn interface handover request message.

[0258] When the first rule is Per-gNB-DU, the resource indication information may include the early RACH resource requester ID information. The early RACH resource requester ID information corresponds to the early RACH resource requester ID information in the Xn interface handover request message. If the gNB-DU ID or the early RACH resource requester ID information is included in the XnAP TA information delivery message, the gNB-CU will continue to forward this TA information to the gNB-DU indicated by the gNB-DU ID or the early RACH resource requester ID information.

[0259] When the first rule is Per-Cell, the resource indication information may include the LTM cell ID.

[0260] When the first rule is Per-UE, the resource indication information may include the source NG-RAN node UE XnAP ID and / or the target NG-RAN node UE XnAP ID, or the TA information of the candidate cell transmitted in a message associated with a UE.

[0261] Step 321: The source gNB-CU sends a TA information transfer message to the source gNB-DU.

[0262] For example, the source gNB-CU sends candidate cell and TA value information, as well as early RACH resource information, to the corresponding source gNB-DU through a CU-DU TA information transmission message not associated with the UE.

[0263] In some embodiments, the methods provided in this disclosure can be applied to various scenarios. For example, in scenarios that support inter-CU LTM with SN kept / release / addition, or inter-gNB continuity CHO, or inter-gNB continuity CHO with SN kept / released / addition, if an early TA acquisition process exists, the allocation principle of RACH resources for early uplink synchronization of candidate cells described in this disclosure is still applicable.

[0264] In one embodiment, regarding the principle of Example 3 above, that is, for a base station with a CU-DU separated architecture, candidate cells are allocated random access resources for early TA acquisition based on the principle of different DUs. The problem involved is that the source base station, based on the cell ID or CGI information in the L3 measurement report, can determine which base station a candidate cell under a non-source base station (i.e., candidate base station) belongs to, but cannot determine which gNB-DU under that base station it belongs to. Therefore, before triggering the handover request message, it is necessary to know which gNB-DU under the base station the candidate cell belongs to or the corresponding early RACH resource requester ID information. The method for obtaining the early RACH resource requester ID information can refer to steps 300-1 to 300-2 above, or steps 302-1 to 302-2 above. However, since the above scheme occurs before the handover request, it is aimed at performing early RACH resource requests for the DU and / or base station where the recommended other candidate cells are located during the candidate cell resource request process. However, the recommended other candidate cells may fail during the LTM resource request process and are not considered as candidate cells, i.e., they are not accepted by the candidate base station as accepted candidate cells. This could lead to unnecessary signaling and signaling waste, as well as wasted RACH resource allocation; that is, the candidate cell may not need to allocate early RACH resources for the DU obtained from the query, which may not be the DU's ID or the corresponding early RACH resource requester ID. To request early RACH resources only for the gNB-DU and / or base station of the accepted candidate cell, and to obtain the gNB-DU ID or the corresponding early RACH resource requester ID of the accepted candidate cell, the candidate base station can provide the gNB-DU ID or the corresponding early RACH resource requester ID of the accepted candidate cell during the handover request preparation process. The above solution can be implemented through the following process:

[0265] The handover request message in step 303 carries one or more of the following information: candidate cell ID (or target cell ID, which can be represented by cell ID or NR CGI), an explicit or implicit indication (such as requesting an IE through LTM information or other IEs related to LTM, or implicitly indicating a request), indicating the gNB-DU ID information to which the candidate cell indicated by the candidate cell ID belongs or the implicit mapping ID information corresponding to the gNB-DU ID, such as the early RACH resource requester ID information, or other names.

[0266] The handover request confirmation message in step 306 carries one or more of the following information: the accepted LTM candidate cell ID (or target cell ID, which can be represented by cell ID or NR CGI), the gNB-DU ID information to which the candidate cell belongs (if the candidate gNB is a CU-DU separated architecture base station), or the implicit mapping ID information corresponding to the gNB-DU ID, such as the early RACH resource requester ID information. Other names are also acceptable.

[0267] If the candidate base station is a non-CU-DU separated architecture base station, then the candidate cell does not have its own gNB-DU information. Therefore, the handover request confirmation message in step 306 carries an indication of query failure, or returns an indication that the candidate cell does not have its own gNB-DU or early RACH resource requester ID (or uses empty information to indicate non-existence, i.e., no reply was given regarding the candidate cell's own gNB-DU or early RACH resource requester ID), to indicate that the requested candidate cell does not have its own gNB-DU information.

[0268] If the gNB-DU ID or early RACH resource requester ID information of the candidate cell is included in the XnAP handover request confirmation message, the gNB-CU will consider using this information when making subsequent early RACH resource requests. Through the XnAP LTM configuration update message, the gNB-CU will request the candidate cell to allocate early RACH resources to the gNB-DU indicated by the gNB-DU ID or early RACH resource requester ID information of these accepted candidate cells.

[0269] After the source base station and each candidate base station go through the handover request process, they finally obtain the information of each accepted candidate cell, as well as the gNB-DU information of the candidate base station (if the candidate base station is a base station with a CU-DU separate architecture).

[0270] In this way, the LTM configuration update process can be used to request one or more candidate cells on the candidate base station to allocate early RACH resources for the gNB-DU (if the candidate base station is a CU-DU separate architecture) and / or the base station (if the candidate base station is not a CU-DU separate architecture) to which the accepted candidate cells belong. This LTM configuration update process can be based on candidate cells or on nodes. If it is based on candidate cells, that is, an LTM configuration update process requests that a candidate cell on a candidate base station allocate early RACH resources for the gNB-DU and / or base station to which other candidate cells belong. If it is based on nodes, that is, an LTM configuration update process requests that each candidate cell on a candidate base station allocate early RACH resources for the gNB-DU and / or base station to which other candidate cells belong.

[0271] Therefore, the LTM configuration update message in step 309 carries one or more of the following information: the accepted LTM candidate cell ID (optionally, a list of candidate LTM cells containing one or more candidate cell IDs, each candidate cell ID can be represented by NR CGI), and an Early Sync Information Request (IE). The Early Sync Information Request (IE) indicates that the LTM candidate cell is allocating early RACH resources to the gNB-DU (which can be represented by the gNB-DU ID or Early RACH Resource Requester ID information) and / or base station (which can be represented by the Global gNB ID) to which other candidate cells belong.

[0272] Correspondingly, if the candidate base station is a CU-DU separated architecture base station, the UE context modification request message in step 310 carries the information in the LTM configuration update message in step 309 above to the DU for early RACH resources.

[0273] Accordingly, the UE context modification response message in step 311 carries one or more of the following information: one or more candidate cell IDs (optionally, each candidate cell ID can be represented by NR CGI), and the early RACH resources allocated by each candidate cell to the gNB-DU and / or base station to which other candidate cells belong, which can be represented by an Early Sync Information Response (IE).

[0274] Accordingly, the LTM configuration update confirmation message in step 312 carries one or more of the following information: one or more candidate cell IDs (optionally, each candidate cell ID can be represented by NR CGI), and the early RACH resources allocated by each candidate cell to the gNB-DU and / or base station to which other candidate cells belong, which can be represented by Early Sync Information Response (IE) or Early UL Sync Configuration (IE).

[0275] The mechanism where the source base station requests early RACH resource allocation from a candidate cell after receiving an accepted candidate cell also applies to mechanisms where candidate cells allocate early RACH resources based on the base station or the cell itself. This can reduce unnecessary early RACH resource allocation for recommended candidate cells, or their associated DUs and / or base stations, when such recommended candidate cells are not accepted during the LTM request process. This reduces waste in early RACH resource allocation for candidate cells.

[0276] Figure 4 This is another exemplary flowchart of the inter-base station mobility mechanism according to the present disclosure, which includes the following steps. Figure 4 The principle of the illustrated embodiment and Figure 3 Similar to the implementation, the differences lie in the node names and corresponding message names. For UEs in dual-connectivity scenarios, configuring SN / MN-triggered inter-SN (conditional) LTM or other similar scenarios (such as S-CPAC with an early TA process), the allocation of RACH resources for early TA for candidate PSCells can be based on the aforementioned... Figure 3 The embodiments shown are carried out in the manner of Examples 1 to 5.

[0277] Step 401-1: The UE sends an L3 measurement report to the source S-NG-RAN (SN) node or MN.

[0278] For example, the UE sends an L3 measurement report to the source S-NG-RAN node or forwards the L3 measurement report sent by the UE to the source S-NG-RAN node via the MN. The L3 measurement report includes the cell ID or CGI of the adjacent primary and secondary cells PSCell, as well as measurement result information. For the MN-triggered scenario, the L3 measurement report is sent directly to the MN, and then the MN makes an LTM configuration decision, in which case step 402 is ignored.

[0279] Step 401-2: Determine the source S-NG-RAN node or MN to perform LTM configuration.

[0280] Step 402: The source S-NG-RAN node or the source SN gNB-CU sends a secondary node change request message to the MN.

[0281] For example, when the source S-NG-RAN node or the source SN's gNB-CU receives an L3 measurement report from the UE, it triggers an LTM configuration decision. The source S-NG-RAN node or the source SN's gNB-CU initiates an inter-SN LTM request to the MN, sending a secondary node change request (S-NODE CHANGE REQUIRED) message to the MN. If the candidate PSCell is allocated early RACH resources based on the gNB-DU, optionally, the secondary node change request message includes the source PSCell under the source SN and the gNB-DUID information corresponding to the candidate PSCell, or an implicit mapping of gNB-DUID information. The early RACH resource requester ID information corresponds to the gNB-DUID, and the value of the early RACH resource requester ID information is the same as that of the gNB-DUID. The name of the early RACH resource requester ID information can be an ID with other names, such as base station sub-level ID (gNB-Sub LevelID) or other names, which is not limited in this disclosure. This ID indicates the ID of an entity that requested an early RACH resource; the entity may be a gNB-DU, or it may indicate the ID of the early RACH resource requester.

[0282] Step 403: The M-NG-RAN node or the gNB-CU of the MN sends a secondary node addition request message to the candidate S-NG-RAN node.

[0283] For example, the M-NG-RAN node or the gNB-CU of the MN initiates a secondary node addition request (S-NODE ADDITION REQUEST) message for different candidate S-NG-RAN nodes or candidate SNs to which the candidate PSCell belongs. The information included in the secondary node addition request message can be referred to the above. Figure 3 The handover request message in the illustrated embodiment carries the following information. The corresponding candidate cell is the candidate PSCell, and the corresponding candidate base station is the candidate SN, which will not be elaborated further here.

[0284] The allocation of early RACH resources for candidate PSCells to SN-DUs is similar. The MN can know the candidate SN to which each candidate PSCell belongs, but it cannot determine which SN-DU under that candidate SN (if the SN is a CU-DU separated architecture base station). It can determine which SN-DU under the candidate SN a candidate PSCell belongs to based on the early RACH resource requester ID information. The method for obtaining the early RACH resource requester ID information is described above. Figure 3 In the illustrated embodiment, steps 300-1 to 300-2, or steps 302-1 to 302-2.

[0285] Similarly, refer to the above. Figure 3 In the illustrated embodiment, steps 300-1 to 300-2 involve exchanging early RACH resource requester ID information during the Xn interface establishment process (Xn establishment request message and / or Xn establishment response message) between the MN and each SN, or during NG-RAN node configuration updates (NG-RAN node configuration update message and / or NG-RAN node configuration update confirmation message). The early RACH resource requester ID information corresponds to the gNB-DU ID, and the value of the early RACH resource requester ID information is the same as the value of the gNB-DU ID. The name of the early RACH resource requester ID information can be an ID with other names, such as the base station sub-level ID (gNB-Sub Level ID) or other names; this disclosure does not limit this.

[0286] Optionally, the Xn setup response message may include the early RACH resource requester ID information. Alternatively, the NG-RAN node configuration update confirmation message may include the early RACH resource requester ID information. Explicitly or implicitly identifying the gNB-DU ID information of the candidate cell belonging to the non-source base station (i.e., candidate SN base station).

[0287] For example, early RACH resource requester ID information may include one or more of the following: serving NR cell information, NR neighboring cell information, and E-UTRA neighboring cell information. For specific implementation details, please refer to [link / reference needed]. Figure 3 The corresponding descriptions in the illustrated embodiments will not be repeated here.

[0288] Similarly, refer to the above. Figure 3 In the illustrated embodiment, steps 302-1 to 302-2 are described. Before triggering the SN addition request, the MN can initiate a query process to the candidate SN (optionally, including the source SN) corresponding to the candidate PSCell cell (optionally, including the source PSCell), for example, by sending an identifier request message, and the candidate SN replies with an identifier response message.

[0289] The identification request message can be a non-UE-associated message, a new message (e.g., a request message named "Query Early RACH Resource Requester ID"), or an existing message (e.g., a request message to modify the NG-RAN node configuration update message or the UE-associated signaling SN). The information carried in the identification request message includes... Figure 3 The steps described in step 302-1 are not repeated here.

[0290] The identification response message can indicate a successful query. It can be a new message, such as a response message named "Query Early RACH Resource Requester ID," or an existing message, such as an NG-RAN node configuration update confirmation message or a UE-associated signaling SN modification request confirmation message. The information carried in the identification request message includes... Figure 3 The steps described in step 302-2 are not repeated here.

[0291] If the candidate SN is a CU-DU separated architecture base station, the interaction process between the SN-CU and SN-DU can be referred to steps 304 and 305 in the above embodiments. This involves the early synchronization information request information in the UE context establishment request message, which may also carry the MN ID information. For example, in the scheme where the first rule in Example 1 is Per-gNB, the early synchronization information request information may include: a list of SNs, which includes the global gNBID of one (source SN) or more gNBs (including the source SN and candidate SNs), and an indication of the MNID information (represented by the global gNB ID).

[0292] For example, in the scheme where the first rule in Example 3 is Per-gNB-DU, an early RACH resource list is carried. Exemplarily, the early RACH resource list may include the SNID, and may also include the SN's gNB-DU ID and / or MN ID information. The SN ID includes the source SN and candidate SNs, and can be represented by a global gNBID. The SN's gNB-DUID corresponds to the early RACH resource requester ID information contained in the Xn interface information SN add request message. The early RACH resource requester ID information is converted into the corresponding gNB-DUID. If the early RACH resource list includes the SN's gNB-DU ID, it indicates that early RACH resources are allocated based on the SN's gNB-DU indicated by the SN's gNB-DU ID. If the early RACH resource list does not include the SN's gNB-DU ID, it indicates that early RACH resources are allocated based on the SN indicated by the SN ID. The MN ID information indicates the MNID information to which the candidate SN belongs, and can be represented by a global gNBID. This MNID can subsequently instruct the candidate SN to continue forwarding the TA information transmission message to the indicated MN during TA information transmission.

[0293] The SN ID and / or MN ID can be represented implicitly, for example, by mapping them to IDs with different names, but their values ​​are still represented by the global gNB ID, which can avoid introducing the concepts of SN and / or MN in the F1 interface specification.

[0294] Correspondingly, in resource allocation, the above information is also carried in the UE context establishment response message, along with the allocated RACH resource information.

[0295] Step 404: The gNB-CU of the candidate S-NG-RAN node or candidate SN sends a secondary node addition request confirmation message to the M-NG-RAN node or MN.

[0296] For example, if the candidate S-NG-RAN node or the gNB-CU of the candidate SN determines that one or more candidate PSCells accept the LTM configuration request, then the resources of the corresponding candidate cell PSCell are prepared, and a secondary node add request confirmation message is sent back to the gNB-CU of the M-NG-RAN node or the MN.

[0297] The information contained in the secondary node addition request confirmation message can be found in the above description. Figure 3 The handover request confirmation message shown in the implementation illustrates the information carried by the candidate cells. The corresponding candidate cells are candidate PSCells, and the corresponding candidate base stations are candidate SNs; these will not be described again here.

[0298] For each candidate S-NG-RAN node, through steps 403 and 404 above, the M-NG-RAN node collects the LTM configuration information and the assigned early UL synchronization configuration information for each candidate PSCell that has accepted the LTM request.

[0299] Step 405: The M-NG-RAN node sends a secondary node modification request message to the source S-NG-RAN node and each other candidate S-NG-RAN node.

[0300] For example, to support continuous LTM, an M-NG-RAN node can send the collected LTM configuration information for each candidate PSCell, along with early UL synchronization configuration information, to each other candidate S-NG-RAN node. It also needs to send this information to the source S-NG-RAN node, which can be done using an LTM configuration update message or an S-Node Modification Request message. The specific information contained in the LTM configuration update message or S-Node Modification Request message can be found above. Figure 3 Step 309 in the illustrated embodiment. The corresponding candidate cell is the candidate PSCell, and the corresponding candidate base station is the candidate SN, which will not be described again here. The LTM configuration update message or SN modification request message can also carry MN ID information. In this way, when transmitting TA information through a non-UE associated signaling TA information transmission message, the TA information can be transmitted from the candidate SN to the source SN through the MN. If there is no control plane connection between the source SN and the candidate SN, control plane messages cannot be transmitted directly and need to be forwarded through the MN.

[0301] Step 406: The candidate S-NG-RAN node sends a secondary node modification request confirmation message to the M-NG-RAN node, and the source SN sends a secondary node modification request confirmation message to the M-NG-RAN node.

[0302] For example, when a candidate S-NG-RAN node (including the source SN) receives this information, it stores it. Optionally, it replies to the M-NG-RAN node with a corresponding message, such as an LTM configuration update confirmation message or an SN modification request confirmation message.

[0303] For example, if the candidate S-NG-RAN node (including the source SN) is a node in a CU-DU separated architecture, the SN's gNB-CU can send a UE context modification request message based on the RACH configuration allocated to this gNB for each candidate PSCell cell, and continue to allocate the corresponding RACH configuration to the candidate gNB-DU. Alternatively, the gNB-DU can request early RACH resources from the gNB-CU. For specific implementation details, please refer to the above. Figure 3 The schemes in Examples 1-2 of the illustrated embodiments.

[0304] If the early RACH resources are based on DU, cell, or UE-allocated RACH resources, the gNB can forward all candidate cells' RACH resources allocated to the corresponding DU, cell, or UE under the SN to the corresponding DU.

[0305] Step 407: The M-NG-RAN node sends an MN RRC reconfiguration message to the UE.

[0306] For example, an M-NG-RAN node configures a UE by sending an MN RRC reconfiguration message, which may include a candidate SN RRC reconfiguration message.

[0307] Step 408: The UE sends an RRC reconfiguration complete message to the M-NG-RAN node.

[0308] Step 409: The M-NG-RAN node sends a secondary node change confirmation message to the source S-NG-RAN node.

[0309] Optionally, the M-NG-RAN node can send the collected LTM configuration information and early UL synchronization configuration information for each candidate PSCell to the source S-NG-RAN node. Specific details can be found above. Figure 3Step 309 in the illustrated embodiment. The corresponding candidate cell is the candidate PSCell, and the corresponding candidate base station is the candidate SN, which will not be described again here. MN ID information can also be carried. This way, when transmitting TA information via a non-UE-associated signaling TA information transmission message, the TA information can be transmitted from the candidate SN to the source SN through the MN. If there is no control plane connection between the source SN and the candidate SN, control plane messages cannot be transmitted directly and need to be forwarded through the MN.

[0310] Step 410: The source S-NG-RAN node determines that the UE triggers the early TA acquisition process to the candidate PSCell.

[0311] For example, before the UE triggers LTM, optionally, to allow the UE to obtain the TA value with the candidate PSCell cell in advance and thus perform a RACH-less fast access process during LTM execution, the network-side source SN needs to trigger the UE to perform an early TA acquisition process. The source SN or its gNB-DU triggers the UE to send a preamble to the candidate PSCell cell via PDCCH command. Then, the candidate PSCell cell calculates the TA information and sends a TA information transmission message from the candidate SN to the MN via inter-node signaling. The MN then sends a TA information transmission message to the source SN. (Optionally, if the candidate SN and source SN have a CU-DU separate architecture, on the candidate SN side, the candidate SN-DU sends a DU-CU TA information transmission message to the candidate SN-CU, and on the source SN side, the source SN-CU sends a CU-DU TA information transmission message to the source SN-DU.) When the source SN or source SN-DU receives the TA message from the candidate cell, it carries the TA of the target cell to the UE via the Cell Switch Command MAC Control Element (CE) when LTM is triggered.

[0312] The candidate SN-DU sends the TA value and associated information to the candidate SN-CU through the TA information transmission message of the DU-CU associated with the non-UE.

[0313] For example, a DU-CU TA information transmission message may include one or more of the following information: TA information list, candidate cell PSCell ID, TA value, preamble index, random access radio network temporary identifier, and resource indication information.

[0314] The TA information list may include the TA values ​​of one or more candidate cells and the RACH resource information used.

[0315] Depending on the different allocation principles, the resource indication information includes the following information.

[0316] When the first rule is Per-gNB, the resource indication information includes SNID and / or MN ID information, where SNID indicates the source gNB and can be indicated by the global gNBID. MNID information indicates the MN ID information to which the candidate SN belongs.

[0317] When the first rule is Per-DU in S-gNB+per-C-gNB, the resource indication information includes the SNID, and may also include the SN's gNB-DUID and / or MNID information. The SN ID indicates the source gNB, which can be indicated using the global gNB ID. If the source SN is a base station with a CU-DU separation architecture, the resource indication information includes the SN's gNB-DU ID. The MN ID information indicates the MN ID information to which the candidate SN belongs.

[0318] When the first rule is Per-gNB-DU, the resource indication information includes the SN ID, and may also include the SN's gNB-DU ID and / or MNID information. The SN ID indicates the source gNB and can be indicated using a global gNB ID. If the source SN is a base station with a CU-DU separation architecture, the resource indication information includes the SN's gNB-DU ID. The MN ID information indicates the MN ID information to which the candidate SN belongs. This MN ID can instruct the candidate SN to continue forwarding TA information transmission messages to the indicated MN.

[0319] When the first rule is Per-Cell, the resource indication information includes LTM PSCellID, where LTM PSCellID can be indicated by either the cell ID or NR CGI.

[0320] When the first rule is Per-UE, the resource indication information includes the gNB-CU UE F1AP ID and / or gNB-DU UE F1AP ID, or the TA information of the candidate cell is transmitted in a message associated with a UE.

[0321] The aforementioned SN ID and / or MN ID can be represented implicitly, for example, by mapping them to IDs with different names, but their values ​​are still represented by the global gNB ID, which avoids introducing the concepts of SN and / or MN into the F1 interface specification.

[0322] Step 411: The candidate SN or candidate SN-CU sends a TA information transmission message to the MN.

[0323] For example, a candidate SN or candidate SN-CU sends TA-related information to the corresponding MN through newly defined Xnap information (e.g., TA information transmission) that is not associated with the UE. The candidate SN can determine which MN node to forward information to using the MN ID information, because the same candidate SN may have different MNs for different UEs.

[0324] For example, a TA information transmission message may include one or more of the following information: a TA information list, a candidate cell ID, a TA value, a preamble index, a temporary identifier for random access radio networks, and resource indication information. The resource indication information may indicate that the RACH resources utilized by the UE are information previously allocated to the corresponding node or cell for this candidate cell.

[0325] Depending on the different allocation principles, the resource indication information includes the following information.

[0326] When the first rule is Per-gNB, the resource indication information can carry an LTM SN ID, which indicates the source SN and can be indicated by the global gNB ID.

[0327] In the case of the first rule being Per-DUin S-gNB+per-C-gNB, the resource indication information may include the SN ID and also the early RACH resource requester ID information. The SN ID indicates the source SN and can be indicated by the global gNBID. The early RACH resource requester ID information corresponds to the gNB-DUID, and the value of the early RACH resource requester ID information is the same as that of the gNB-DUID. The name of the early RACH resource requester ID information can be an ID with other names, and this disclosure does not limit this. Not directly using the gNB-DUID (e.g., the resource indication information does not directly include the gNB-DUID) can prevent the base station's architecture information from being exposed in the Xn interface specification. This IE will only be presented when the source SN pointed to by the SN ID is a CU-DU separated architecture. For example, if the early RACH resource list includes the early RACH resource requester ID information, it can implicitly indicate the gNB-DU ID under the SN.

[0328] In the case of the first rule being Per-gNB-DU, the resource indication information may include the SNID and the early RACH resource requester ID. The SN ID indicates the source SN and can be indicated by the global gNB ID. This SNID can instruct the MN to continue forwarding TA information transmission messages to the SN indicated by the SNID. The early RACH resource requester ID corresponds to the gNB-DU ID, and their values ​​are the same. The name of the early RACH resource requester ID can be an ID with other names; this disclosure is not limited in this regard. Not directly using the gNB-DU ID (e.g., the resource indication information does not directly include the gNB-DU ID) allows the Xn interface specification to avoid exposing the base station's architecture information. This IE is only presented when the source SN pointed to by the SN ID has a CU-DU separated architecture; for example, if the early RACH resource list includes the early RACH resource requester ID, it can implicitly indicate the gNB-DU ID under the SN. This ID indicates the ID of an entity requesting early RACH resources; the entity can be a gNB-DU or indicate the early RACH resource requester ID.

[0329] When the first rule is Per-Cell, the resource indication information includes LTM PSCellID, where LTM PSCellID can be indicated by either the cell ID or NR CGI.

[0330] When the first rule is Per-UE, the resource indication information includes the M-NG-RAN node UE XnAP and / or S-NG-RAN node UE XnAP ID, or the TA information of the candidate cell transmitted in a message associated with a UE.

[0331] Step 412: MN sends a TA information transmission message to the source SN or source SN-CU.

[0332] For example, the MN sends TA-related information to the source SN or source SN-CU via newly defined Xnap information (e.g., TA information transmission) that is not associated with the UE. The MN can determine which SN node to forward the information to using the SN ID indication information, because the same MN may have different SNs for different UEs.

[0333] The TA information transmission message includes one or more of the following: TA information list, candidate cell ID, TA value, preamble index, temporary identifier for random access radio network, and resource indication information. The resource indication information indicates that the RACH resources utilized by the UE are information previously allocated to the corresponding node or cell for this candidate cell.

[0334] In the case where the first rule is Per-gNB, the resource indication information may not be carried, or the TA information transmission message may not include the resource indication information.

[0335] In the case where the first rule is Per-DUin S-gNB+per-C-gNB, the resource indication information may include the early RACH resource requester ID information. The early RACH resource requester ID information corresponds to the gNB-DU ID, and their values ​​are the same. The name of the early RACH resource requester ID information can be an ID with other names; this disclosure does not limit this. Not directly using the gNB-DU ID (e.g., the resource indication information does not directly include the gNB-DU ID) allows the Xn interface specification to avoid exposing the base station's architecture information. This IE is only presented when the source SN pointed to by the SN ID has a CU-DU separated architecture; for example, if the early RACH resource list includes the early RACH resource requester ID information, it can implicitly indicate the gNB-DU ID under the SN.

[0336] In the case where the first rule is Per-gNB-DU, the resource indication information may include the early RACH resource requester ID information. This early RACH resource requester ID information can instruct the SN to continue forwarding TA information to the gNB-DU of the SN indicated by the early RACH resource requester ID. There is a correspondence between the early RACH resource requester ID information and the gNB-DU ID, and the value of the early RACH resource requester ID information and the gNB-DU ID are the same. The name of the early RACH resource requester ID information can be an ID with other names, which is not limited in this disclosure. Not directly using the gNB-DU ID (e.g., the resource indication information does not directly include the gNB-DU ID) can prevent the base station's architecture information from being exposed in the Xn interface specification. This IE is only presented when the source SN pointed to by the SNID has a CU-DU separated architecture. For example, if the early RACH resource list includes the early RACH resource requester ID information, it can implicitly indicate the gNB-DU ID under the SN. This ID indicates the ID of an entity requesting early RACH resources, which can be a gNB-DU or indicate the early RACH resource requester ID.

[0337] When the first rule is Per-Cell, the resource indication information includes LTM PSCellID, where LTM PSCellID can be indicated by either the cell ID or NR CGI.

[0338] When the first rule is Per-UE, the resource indication information includes the M-NG-RAN node UE XnAP and / or S-NG-RAN node UE XnAP ID, or the TA information of the candidate cell transmitted in a message associated with a UE.

[0339] Optionally, the source SN-CU can send candidate cell and TA value information, as well as early RACH resource information, to the corresponding source gNB-DU through the CU-DU TA information transmission message associated with the non-UE.

[0340] In one embodiment, regarding the principle of Example 3 above, that is, for a base station with a CU-DU separated architecture, the candidate cell PSCell allocates random access resources for early TA acquisition based on the principle of different DUs. The problem involved is that while the source SN or MN can determine which candidate SN a candidate cell belongs to based on the cell ID or CGI information in the L3 measurement report, it cannot determine which gNB-DU under that candidate SN it belongs to. Therefore, before triggering the SN add request message, it is necessary to know which gNB-DU under that candidate SN the candidate cell belongs to, or the corresponding early RACH resource requester ID information. The method for obtaining the early RACH resource requester ID information can refer to steps 300-1 to 300-2 (between MN and SN) above, or refer to steps 302-1 to 302-2 (between MN and SN) above. However, since the above scheme occurs before the SN adds the request, it targets the early RACH resource request for the DU and / or SN where the recommended other candidate cell PSCells reside during the candidate cell PSCell resource request process. However, the recommended other candidate cell PSCells may fail during the LTM resource request process and not be considered as candidate cells, i.e., they are not accepted by the candidate SN as accepted candidate cell PSCells. This may result in unnecessary signaling and signaling waste, as well as wasted RACH resource allocation; that is, the retrieved gNB-DUID information or corresponding early RACH resource requester ID information does not necessarily mean that the candidate cell PSCell needs to allocate early RACH resources for this DU. To perform early RACH resource requests only for the gNB-DU and / or base station under the SN to which the accepted candidate cell PSCell belongs, and to obtain the gNB-DU ID information or the corresponding early RACH resource requester ID information of the accepted candidate cell PSCell, the candidate SN can provide the gNB-DU ID information or the corresponding early RACH resource requester ID information of the accepted candidate cell PSCell during the SN add request preparation process. The above scheme can be reflected in the following process:

[0341] Step 403 The auxiliary node add request message carries one or more of the following information: candidate cell PSCellID (or target cell ID, which can be represented by cell ID or NR CGI), an explicit or implicit indication (such as requesting an IE through LTM information or other IEs related to LTM, or implicitly indicating a request), indicating that it is used to query the gNB-DU ID information to which the candidate cell PSCell indicated by the candidate cell PSCell ID belongs, or the implicit mapping ID information corresponding to the gNB-DU ID, such as the early RACH resource requester ID information, or other names.

[0342] Step 404, the secondary node addition request confirmation message carries one or more of the following information: the accepted LTM candidate cell PSCell ID (or target cell ID, which can be represented by cell ID or NR CGI), the gNB-DUID information to which the candidate cell PSCell belongs (if the candidate SN is a CU-DU separated architecture base station), or the implicit mapping ID information corresponding to the gNB-DUID, such as the early RACH resource requester ID information. Other names are also acceptable.

[0343] If the candidate SN is a base station with a non-CU-DU separation architecture, then the candidate cell PSCell does not have gNB-DU information. In step 404, the auxiliary node adds a request confirmation message carrying an indication of query failure, or returns an indication that the candidate cell PSCell does not have a gNB-DU or early RACH resource requester ID (or uses empty information to indicate that it does not exist, i.e., no reply was given regarding the gNB-DU or early RACH resource requester ID information of the candidate cell PSCell), to indicate that the requested candidate cell PSCell does not have gNB-DU information.

[0344] If the gNB-DU ID or early RACH resource requester ID information of the candidate cell PSCell is included in the XnAP secondary node add request confirmation message, the MN primary base station will consider using this information when making subsequent early RACH resource requests. It will modify the request message through the XnAP secondary node and request the candidate cell PSCell to allocate early RACH resources to the gNB-DU indicated by the gNB-DU ID or early RACH resource requester ID information of these accepted candidate cell PSCells.

[0345] After the MN main base station and each candidate SN base station respectively added the request through the auxiliary node, they finally obtained the information of each accepted candidate cell PSCell, as well as the gNB-DU information under the candidate SN (if the candidate SN is a base station with a CU-DU separation architecture).

[0346] In this way, a secondary node modification request procedure can be used to request one or more candidate cell PSCells on the candidate SN to allocate early RACH resources for the gNB-DU to which the accepted candidate cell PSCell belongs (if the candidate SN is a CU-DU separated architecture base station) and / or the SN base station to which the candidate cell belongs (if the candidate SN is not a CU-DU separated architecture base station). This secondary node modification request procedure can be based on candidate cells or on nodes. If it is based on candidate cells, that is, a secondary node modification request procedure requests a candidate cell PSCell on the candidate SN base station to allocate early RACH resources for the gNB-DU and / or SN base station to which other candidate cell PSCells belong. If it is based on nodes, that is, a secondary node modification request procedure requests multiple candidate cell PSCells on the candidate SN base station to allocate early RACH resources for the gNB-DU and / or SN base station to which other candidate cell PSCells belong.

[0347] Therefore, the secondary node modification request message in step 405 carries one or more of the following information: the accepted LTM candidate cell PSCell ID (optionally, a list of candidate LTM PSCell cells containing one or more candidate cell IDs, each candidate cell ID can be represented by NR CGI), and an Early Sync Information Request (IE). The Early Sync Information Request (IE) indicates that the LTM candidate cell PSCell is allocating early RACH resources to the gNB-DU (which can be represented by gNB-DUID or Early RACH Resource Requester ID information) and / or base station (which can be represented by Global gNB ID) to which other candidate cell PSCells belong.

[0348] Correspondingly, if the candidate SN base station is a CU-DU separated architecture base station, it can continue to send a UE context modification request message carrying the information in the secondary node modification request message in step 405 above to the DU for early RACH resources.

[0349] Accordingly, the DU replies to the UE context modification response message with one or more of the following information: one or more candidate cell PSCell IDs (optionally, each candidate cell ID can be represented by NR CGI), and the early RACH resources allocated by each candidate cell PSCell to the gNB-DU and / or base station to which other candidate cell PSCells belong, which can be represented by an Early Sync Information Response (IE).

[0350] Accordingly, the SN modification request confirmation message in step 406 carries one or more of the following information: one or more candidate cell PSCell IDs (optionally, each candidate cell ID can be represented by NR CGI), and the early RACH resources allocated by each candidate cell PSCell to the gNB-DU and / or base station to which other candidate cell PSCells belong. These can be represented by Early Sync Information Response (IE) or Early UL Sync Configuration (IE).

[0351] The mechanism described above, where the MN main base station requests early RACH resource allocation from a candidate cell PSCell after receiving an accepted candidate cell PSCell, also applies to mechanisms where early RACH resource allocation for candidate cell PSCells is based on SN base stations or PSCell cells. This can reduce unnecessary early RACH resource allocation for recommended candidate cell PSCells, or their associated DUs and / or base stations, when they are not accepted during the LTM request process. This reduces waste in early RACH resource allocation for candidate cell PSCells.

[0352] The following situations may occur when a UE switches between nodes:

[0353] - Switch from the source NG-RAN node to the destination NG-RAN node (each node may be a base station with a CU-DU separate architecture);

[0354] - The source NG-RAN node is switched to the standard MN+SN (each node may be a base station with a CU-DU separation architecture);

[0355] - Switch from source MN+SN to target MN+SN (SN remains unchanged) (each node may be a base station with a CU-DU separation architecture);

[0356] - Switch from source MN+SN to target MN+SN (SN change) (each node may be a base station with a CU-DU separation architecture);

[0357] - The source MN+SN is switched to the target NG-RAN node (each node may be a base station with a CU-DU separate architecture);

[0358] -MN+sourceSN switches to MN+targetSN (SN changes, MN remains unchanged, MN or SN triggers the switch)

[0359] (Each node may be a base station with a CU-DU separation architecture).

[0360] For the aforementioned handover scenarios, as well as conditional handover (CHO), continuous CHO, or LTM handover scenarios or conditional LTM handover scenarios, there may be corresponding early RACH resource allocation principles. The allocation principles and schemes described in this disclosure are still applicable to the aforementioned various handover scenarios, as well as conditional handover, continuous CHO, or LTM handover scenarios or conditional LTM handover scenarios.

[0361] Figure 5 A method performed by a first node in a wireless communication system according to an exemplary embodiment of the present disclosure is illustrated. This method can be adapted to be performed by… Figures 3 to 4 The specific implementation methods for each step of the execution of the source NG-RAN node, source gNB-CU, and MN described above can be referred to. Figures 3 to 4 The corresponding description is provided. According to an exemplary embodiment, the method performed by the first node in the wireless communication system includes:

[0362] Step 501: Send the first request message to the second node.

[0363] For example, the first request message can be used to request the identifier of the Early Random Access Channel (RACH) resource requester to which the candidate cell to which the LTM handover belongs.

[0364] For details on the implementation of step 501 and the first request message, please refer to the relevant explanation in step 302-1 above, which will not be repeated here.

[0365] Step 502: Receive the first response message from the second node.

[0366] For example, the first response message may include the identifier of the candidate cell and the identifier of the early RACH resource requester to which the candidate cell belongs. For instance, the identifier of the early RACH resource requester to which the candidate cell belongs refers to the identifier of the early RACH resource requester to which the candidate cell belongs, as indicated by the identifier of the candidate cell. Here, the first node is the centralized unit (CU) of the source node, and the second node is the CU of the candidate node; or, the first node is the primary node, and the second node is the secondary node.

[0367] The specific implementation of step 502 and the first response message can be found in the relevant description in step 302-2 above, and will not be repeated here. The specific implementation of the identifier of the early RACH resource requester can be found in the early RACH resource requester ID information in step 302-2. The early RACH resource requester ID information can be used to implicitly indicate a mapped ID information of the gNB-DUID to which the candidate cell belongs, or it can be other names. This ID indicates the ID of an entity requesting early RACH resources.

[0368] In some embodiments, the first request message may include an identifier of the candidate cell and indication information for requesting an early RACH resource requester. The identifier of the early RACH resource requester is an identifier indicating an entity requesting early RACH resources. The specific implementation of the first request message can refer to the identifier request message in step 302-2 above, and the specific implementation of the indication information for requesting the identifier of the early RACH resource requester can refer to the early RACH resource requester ID request indication information in the identifier request message above; these details will not be repeated here.

[0369] In some embodiments, the first response message may also include the identifier of the node to which the early RACH resource requester belongs. The specific implementation of the identifier of the node to which the early RACH resource requester belongs can be found in step 302-2 (gNB ID), and will not be repeated here.

[0370] In some embodiments, the first request message may include at least one of the following: an Xn establishment request message; an Xn application protocol AP query for early RACH resource requester identifier request message; and an Xn AP next-generation radio access network node configuration update message.

[0371] In some embodiments, the first response message may include at least one of the following: an Xn establishment response message; an Xn application protocol AP query early RACH resource requester identifier response message; and an Xn AP next-generation radio access network node configuration update confirmation message.

[0372] In some embodiments, the method may further include: receiving a second message from a second node, the second message including at least one of the following: information related to the TA of the candidate cell; the identifier of the early RACH resource requester; and the identifier of the node to which the early RACH resource requester belongs. When the candidate SN transmits the TA-related information to the MN, it may also send the identifier of the node to which the early RACH resource requester belongs, which may be the source SN ID. Specific implementation details can be found in steps 320 or 411 above, and will not be repeated here.

[0373] In some embodiments, the method may further include: sending TA-related information of the candidate cell to a node indicated by the identifier of the node to which the early RACH resource requester belongs, or to a node indicated by the identifier of the early RACH resource requester. For example, the second node sends the TA-related information of the candidate cell to the gNB-DU to which the candidate cell belongs. The second node also sends the TA-related information of the candidate cell to the source SN to which the gNB-DU belongs.

[0374] In some embodiments, the method may further include: receiving a second request message and sending a second response message. For specific implementation details, please refer to... Figure 3 or Figure 4 The methods described are illustrated below, for example, referring to Examples 1-2-1 to 1-2-4 and the specific implementations of steps 317-1 and 317-2 above, and will not be repeated here. The specific implementation of the second request message can be referred to the early RACH resource request message in step 317-1 above, and will not be repeated here. The specific implementation of the second response message can be referred to the early RACH resource response message in step 317-2 above, and will not be repeated here.

[0375] Optionally, the second request message may include information requesting early RACH resources allocated to a node by a candidate cell based on the UE or DU configuration; the second response message may include information related to the early RACH resources allocated to a node by a candidate cell based on the UE or DU configuration.

[0376] In some embodiments, the second request message may include: an identifier of the candidate cell; and indication information for requesting early RACH resources allocated to the node by the candidate cell based on the UE or DU configuration.

[0377] In some embodiments, the second response message may include: the identifier of the candidate cell; and early uplink synchronization configuration information.

[0378] In some embodiments, the second request message may include at least one of the following: an early RACH resource request message; a UE context modification request; a UE context modification requirement message; a secondary node SN modification requirement message; and an SN modification request message. For example, the DU sends a UE context modification requirement message to the CU, the source SN sends an SN modification requirement message to the MN, and the MN sends an SN modification confirmation message to the candidate SN. Specific implementation methods can be referred to the above. Figure 3 or Figure 4 The corresponding explanations in the methods shown will not be repeated here.

[0379] In some embodiments, the second response message may include at least one of the following: an early RACH resource request confirmation message; an early RACH resource response message; a UE context modification response message; a UE context modification confirmation message; an SN modification confirmation message; and an SN modification request confirmation message. For example, the CU sends a UE context modification confirmation message to the DU, the MN sends an SN modification confirmation message to the source SN, and the candidate SN sends an SN modification confirmation message to the MN. Specific implementation methods can be referred to the above. Figure 3 or Figure 4 The corresponding explanations in the methods shown will not be repeated here.

[0380] Figure 6 A method performed by a second node in a wireless communication system according to an exemplary embodiment of the present disclosure is illustrated. This method can be adapted to be performed by… Figures 3 to 4 The specific implementation methods for each step of the candidate gNB-CU, candidate NG-RAN node, and SN execution described above can be referred to the above. Figures 3 to 4 The corresponding description is provided. According to an exemplary embodiment, the method performed by a second node in a wireless communication system includes:

[0381] Step 601: Receive the first request message from the first node.

[0382] For example, the first request message is used to request the identifier of the Early Random Access Channel (RACH) resource requester to which the candidate cell to which the mobility LTM handover triggered by Layer 1 / Layer 2 belongs.

[0383] For details on the implementation of step 601 and the first request message, please refer to the relevant explanation in step 302-1 above, which will not be repeated here.

[0384] Step 602: Send the first response message to the first node.

[0385] For details on the implementation of step 602 and the first response message, please refer to the relevant explanation in step 302-2 above, which will not be repeated here.

[0386] For example, the first response message includes the identifier of the candidate cell and the identifier of the early RACH resource requester to which the candidate cell belongs. For instance, the identifier of the early RACH resource requester to which the candidate cell belongs refers to the identifier of the early RACH resource requester to which the candidate cell belongs, as indicated by the identifier of the candidate cell. Here, the first node is the centralized unit (CU) of the source node, and the second node is the CU of the candidate node; or, the first node is the primary node, and the second node is the secondary node.

[0387] In some embodiments, the method may further include sending a second message to the first node. Specific implementation details can be found in steps 320 or 411 above, and will not be repeated here.

[0388] For example, the second message may include at least one of the following: information about the TA of the candidate cell; the identifier of the early RACH resource requester; and the identifier of the node to which the early RACH resource requester belongs.

[0389] In some embodiments, the method may further include: sending a second request message, the second request message including information requesting early RACH resources allocated to a node by a candidate cell based on the UE or based on the DU; and receiving a second response message, the second response message including information relating to the early RACH resources allocated to a node by a candidate cell based on the UE or based on the DU.

[0390] According to an exemplary embodiment, the first response message may further include the identifier of the node to which the early RACH resource requester belongs. The specific implementation of the identifier of the node to which the early RACH resource requester belongs can be found in step 302-2 under the gNB ID, and will not be repeated here.

[0391] For example, the second message may include at least one of the following: information about the timing advance (TA) of the candidate cell; the identifier of the early RACH resource requester; and the identifier of the node to which the early RACH resource requester belongs.

[0392] According to an exemplary embodiment, the first request message may include an identifier of the candidate cell and indication information for an identifier of an early RACH resource requester. The identifier of the early RACH resource requester is an identifier indicating an entity requesting early RACH resources. The specific implementation of the first request message can refer to the identifier request message in step 302-2 above, and the specific implementation of the indication information for the identifier of the early RACH resource requester can refer to the early RACH resource requester ID request indication information in the identifier request message above; these details will not be repeated here.

[0393] According to an exemplary embodiment, the first response message may further include the identifier of the node to which the early RACH resource requester belongs. The specific implementation of the identifier of the node to which the early RACH resource requester belongs can be found in step 302-2, specifically in the gNB ID.

[0394] According to an exemplary embodiment, the first request message may include at least one of the following: an Xn establishment request message; an Xn application protocol AP query early RACH resource requester identifier request message; and an Xn AP next-generation radio access network node configuration update message.

[0395] According to an exemplary embodiment, the first response message may include at least one of the following: an Xn establishment response message; an Xn application protocol AP query early RACH resource requester identifier response message; and an Xn AP next-generation radio access network node configuration update confirmation message.

[0396] In some embodiments, the method may further include: sending TA-related information of the candidate cell to a node indicated by the identifier of the node to which the early RACH resource requester belongs, or to a node indicated by the identifier of the early RACH resource requester. For example, the second node sends the TA-related information of the candidate cell to the gNB-DU to which the candidate cell belongs. The second node also sends the TA-related information of the candidate cell to the source SN to which the gNB-DU belongs.

[0397] In some embodiments, the method may further include: sending a second request message and receiving a second response message. For specific implementation details, please refer to... Figure 3 or Figure 4 The methods described are illustrated below, for example, referring to Examples 1-2-1 to 1-2-4 and the specific implementations of steps 317-1 and 317-2 above, and will not be repeated here. The specific implementation of the second request message can be referred to the early RACH resource request message in step 317-1 above, and will not be repeated here. The specific implementation of the second response message can be referred to the early RACH resource response message in step 317-2 above, and will not be repeated here.

[0398] Optionally, the second request message may include information requesting early RACH resources allocated to the node by the candidate cell based on the UE or DU configuration. The second response message may include information related to the early RACH resources allocated to the node by the candidate cell based on the UE or DU configuration.

[0399] In some embodiments, the second request message may include: an identifier of the candidate cell; and indication information for requesting early RACH resources allocated to the node by the candidate cell based on the UE or DU configuration.

[0400] In some embodiments, the second response message may include: the identifier of the candidate cell and early uplink synchronization configuration information.

[0401] In some embodiments, the second request message may include at least one of the following: an early RACH resource request message; a UE context modification request; a UE context modification requirement message; a secondary node SN modification requirement message; and an SN modification request message. For example, the DU sends a UE context modification requirement message to the CU, the source SN sends an SN modification requirement message to the MN, and the MN sends an SN modification confirmation message to the candidate SN. Specific implementation methods can be referred to the above. Figure 3 or Figure 4 The corresponding explanations in the methods shown will not be repeated here.

[0402] In some embodiments, the second response message may include at least one of the following: an early RACH resource request confirmation message; an early RACH resource response message; a UE context modification response message; a UE context modification confirmation message; an SN modification confirmation message; and an SN modification request confirmation message. For example, the CU sends a UE context modification confirmation message to the DU, the MN sends an SN modification confirmation message to the source SN, and the candidate SN sends an SN modification confirmation message to the MN. Specific implementation methods can be referred to the above. Figure 3 or Figure 4 The corresponding explanations in the methods shown will not be repeated here.

[0403] Figure 7 A method performed by a DU (Dedicated Unit) of a source node in a wireless communication system is illustrated according to an exemplary embodiment of this disclosure. This method can be adapted by... Figures 3 to 4 The specific implementation methods for each step of the DU execution of the source node described above can be referred to. Figures 3 to 4 The corresponding description is provided below. According to an exemplary embodiment, the method performed by the DU of the source node in a wireless communication system includes:

[0404] Step 701: Send a second request message to the first node.

[0405] Step 702: Receive the second response message from the first node.

[0406] In some embodiments, the first node is the CU of the source node, the first node can receive a second request message from the DU of the source node, and the first node sends a second response message to the DU of the source node.

[0407] The specific implementation methods for steps 701-702 can be found in Examples 1-2-1 to 1-2-4 and steps 317-1 and 317-2 above, and will not be repeated here. The specific implementation method for the second request message can be found in the early RACH resource request message in step 317-1 above, and will not be repeated here. The specific implementation method for the second response message can be found in the early RACH resource response message in step 317-2 above, and will not be repeated here.

[0408] For example, the second request message may include information requesting early RACH resources allocated to a node by a candidate cell based on the UE or DU configuration. The second response message may include information related to the early RACH resources allocated to a node by a candidate cell based on the UE or DU configuration.

[0409] In some embodiments, the second request message may include: an identifier of the candidate cell; and indication information for requesting early RACH resources allocated to the node by the candidate cell based on the UE or DU configuration.

[0410] In some embodiments, the second response message may include: the identifier of the candidate cell; and early uplink synchronization configuration information.

[0411] In some embodiments, the second request message may include at least one of the following: an early RACH resource request message; a UE context modification request; a UE context modification requirement message; a secondary node SN modification requirement message; and an SN modification request message. For example, the DU sends a UE context modification requirement message to the CU, the source SN sends an SN modification requirement message to the MN, and the MN sends an SN modification confirmation message to the candidate SN. Specific implementation methods can be referred to the above. Figure 3 or Figure 4 The corresponding explanations in the methods shown will not be repeated here.

[0412] In some embodiments, the second response message may include at least one of the following: an early RACH resource request confirmation message; an early RACH resource response message; a UE context modification response message; a UE context modification confirmation message; an SN modification confirmation message; and an SN modification request confirmation message. For example, the CU sends a UE context modification confirmation message to the DU, the MN sends an SN modification confirmation message to the source SN, and the candidate SN sends an SN modification confirmation message to the MN. Specific implementation methods can be referred to the above. Figure 3 or Figure 4 The corresponding explanations in the methods shown will not be repeated here.

[0413] In some embodiments, the first request message is sent by the first node. This first request message can be used to request the identifier of the Early Random Access Channel (RACH) resource requester to which the candidate cell for a mobility LTM handover triggered by Layer 1 / Layer 2 belongs. For specific implementation details, please refer to the relevant description in step 302-1 above; it will not be repeated here.

[0414] The first response message is sent by the second node and includes the identifier of the candidate cell and the identifier of the early RACH resource requester to which the candidate cell belongs. For example, the identifier of the early RACH resource requester to which the candidate cell belongs refers to the identifier of the early RACH resource requester to which the candidate cell belongs, as indicated by the identifier of the candidate cell. Here, the first node is the centralized unit (CU) of the source node, and the second node is the CU of the candidate node; or, the first node is the master node, and the second node is the slave node. For specific implementation details, please refer to the above. Figure 3 or Figure 4 The relevant explanations in the methods shown, such as those in step 302-2, will not be repeated here.

[0415] The second message is sent by the second node and may include at least one of the following: information related to the TA of the candidate cell; the identifier of the early RACH resource requester; and the identifier of the node to which the early RACH resource requester belongs. For specific implementation details, please refer to the relevant descriptions in steps 320 or 411 above, which will not be repeated here.

[0416] In some embodiments, the first request message may include an identifier of the candidate cell and indication information for requesting an early RACH resource requester. The identifier of the early RACH resource requester is an identifier indicating an entity requesting early RACH resources. The specific implementation of the first request message can refer to the identifier request message in step 302-2 above, and the specific implementation of the indication information for requesting the identifier of the early RACH resource requester can refer to the early RACH resource requester ID request indication information in the identifier request message above; these details will not be repeated here.

[0417] In some embodiments, the first response message may also include the identifier of the node to which the early RACH resource requester belongs. The specific implementation of the identifier of the node to which the early RACH resource requester belongs can be found in step 302-2 (gNB ID), and will not be repeated here.

[0418] In some embodiments, the first request message may include at least one of the following: an Xn establishment request message; an Xn application protocol AP query for early RACH resource requester identifier request message; and an Xn AP next-generation radio access network node configuration update message.

[0419] In some embodiments, the first response message may include at least one of the following: an Xn establishment response message; an Xn application protocol AP query early RACH resource requester identifier response message; and an Xn AP next-generation radio access network node configuration update confirmation message.

[0420] Figure 8 A method performed by a user equipment (UE) in a wireless communication system according to an exemplary embodiment of the present disclosure is illustrated. This method can be adapted to be performed by… Figures 3 to 4 The specific implementation methods for each step of the UE execution described above can be referred to. Figures 3 to 4 The corresponding description is provided. According to an exemplary embodiment, a method performed by a user equipment in a wireless communication system includes:

[0421] Step 801: Receive RRC reconfiguration message.

[0422] Step 802: Send an RRC reconfiguration complete message.

[0423] The first request message is sent by the first node. This message can be used to request the identifier of the Early Random Access Channel (RACH) resource requester to which the candidate cell for a mobility LTM handover triggered by Layer 1 / Layer 2 belongs. For specific implementation details, please refer to [link / reference]. Figure 3 or Figure 4 The relevant explanations of the method shown are as described in step 302-1 above, and will not be repeated here.

[0424] The first response message is sent by the second node and includes the identifier of the candidate cell and the identifier of the early RACH resource requester to which the candidate cell belongs. For example, the identifier of the early RACH resource requester to which the candidate cell belongs refers to the identifier of the early RACH resource requester to which the candidate cell belongs, as indicated by the identifier of the candidate cell. Here, the first node is the centralized unit (CU) of the source node, and the second node is the CU of the candidate node; or, the first node is the master node, and the second node is the slave node. For specific implementation details, please refer to [reference needed]. Figure 3 or Figure 4 The relevant explanations of the method shown are as described in step 302-2 above, and will not be repeated here.

[0425] The second message is sent by the second node and includes at least one of the following: information related to the timing advance (TA) of the candidate cell; the identifier of the early RACH resource requester; and the identifier of the node to which the early RACH resource requester belongs. For specific implementation details, please refer to the relevant descriptions in steps 320 or 411 above; they will not be repeated here.

[0426] In some embodiments, the first request message may include an identifier of the candidate cell and indication information for requesting an early RACH resource requester. The identifier of the early RACH resource requester is an identifier indicating an entity requesting early RACH resources. The specific implementation of the first request message can refer to the identifier request message in step 302-2 above, and the specific implementation of the indication information for requesting the identifier of the early RACH resource requester can refer to the early RACH resource requester ID request indication information in the identifier request message above; these details will not be repeated here.

[0427] In some embodiments, the first response message may also include the identifier of the node to which the early RACH resource requester belongs. The specific implementation of the identifier of the node to which the early RACH resource requester belongs can be found in step 302-2 (gNB ID), and will not be repeated here.

[0428] In some embodiments, the first request message may include at least one of the following: an Xn establishment request message; an Xn application protocol AP query for early RACH resource requester identifier request message; and an Xn AP next-generation radio access network node configuration update message.

[0429] In some embodiments, the first response message may include at least one of the following: an Xn establishment response message; an Xn application protocol AP query early RACH resource requester identifier response message; and an Xn AP next-generation radio access network node configuration update confirmation message.

[0430] In some embodiments, the second request message is sent by the second node, and the second response message is sent by the first node. For specific implementation details, please refer to [reference needed]. Figure 3 or Figure 4 The methods described are illustrated below, for example, referring to Examples 1-2-1 to 1-2-4 and the specific implementations of steps 317-1 and 317-2 above, and will not be repeated here. The specific implementation of the second request message can be referred to the early RACH resource request message in step 317-1 above, and will not be repeated here. The specific implementation of the second response message can be referred to the early RACH resource response message in step 317-2 above, and will not be repeated here.

[0431] Optionally, the second request message may include information requesting early RACH resources allocated to a node by a candidate cell based on the UE or DU configuration; the second response message includes information related to the early RACH resources allocated to a node by a candidate cell based on the UE or DU configuration.

[0432] In some embodiments, the second request message may include: an identifier of the candidate cell; and indication information for requesting early RACH resources allocated to the node by the candidate cell based on the UE or DU configuration.

[0433] In some embodiments, the second response message may include: the identifier of the candidate cell; and early uplink synchronization configuration information.

[0434] In some embodiments, the second request message may include at least one of the following: an early RACH resource request message; a UE context modification request; a UE context modification requirement message; a secondary node SN modification requirement message; and an SN modification request message. For example, the DU sends a UE context modification requirement message to the CU, the source SN sends an SN modification requirement message to the MN, and the MN sends an SN modification confirmation message to the candidate SN. Specific implementation methods can be referred to the above. Figure 3 or Figure 4 The corresponding explanations in the methods shown will not be repeated here.

[0435] In some embodiments, the second response message may include at least one of the following: an early RACH resource request confirmation message; an early RACH resource response message; a UE context modification response message; a UE context modification confirmation message; an SN modification confirmation message; and an SN modification request confirmation message. For example, the CU sends a UE context modification confirmation message to the DU, the MN sends an SN modification confirmation message to the source SN, and the candidate SN sends an SN modification confirmation message to the MN. Specific implementation methods can be referred to the above. Figure 3 or Figure 4 The corresponding explanations in the methods shown will not be repeated here.

[0436] The technical features such as the name of the node, the name of the base station, the name of the message, and the name of the information described in this disclosure may also be replaced with names, and all changes to the names are covered within the scope of this disclosure.

[0437] The methods performed at each node according to the embodiments of this disclosure have been described above by way of example. It should be understood that... Figures 3 to 8 The respective steps shown and the information contained in each step are also included within the scope of this disclosure. Furthermore, the nodes that execute the corresponding methods are also included within the scope of this disclosure.

[0438] Figure 9 Exemplary structures applicable to the various nodes of this disclosure are shown. For example... Figure 9 The exemplary node shown includes a transceiver 910 and a processor 920 coupled to the transceiver 910. The transceiver 910 is configured to transmit and receive signals. The processor 920 is configured to perform the methods described herein. This disclosure can also be implemented as a computer storage medium. The computer storage medium stores computer-executable instructions that, when executed by a processor, perform the methods described herein.

[0439] The various illustrative logic blocks, modules, and circuits described in this disclosure may be implemented or performed using a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but in alternatives, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors cooperating with a DSP core, or any other such configuration.

[0440] The steps of the methods or algorithms described in this disclosure may be embodied directly in hardware, in a software module executed by a processor, or in a combination of both. The software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor such that the processor can read and write information to / from the storage medium. In an alternative, the storage medium may be integrated into the processor. The processor and storage medium may reside in an ASIC. The ASIC may reside in a user equipment terminal. In an alternative, the processor and storage medium may reside as discrete components in the user equipment terminal.

[0441] In one or more exemplary designs, the functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality may be stored or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include both computer storage media and communication media, the latter including any medium that facilitates the transfer of a computer program from one location to another. Storage media may be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0442] The description set forth herein, taken in conjunction with the accompanying drawings, describes exemplary methods and apparatuses and does not represent all examples that can be implemented or that fall within the scope of the claims. As used herein, the term "exemplary" means "serving as an example, instance, or illustration," and not "preferred" or "superior to other examples." The detailed description includes specific details intended to provide an understanding of the described techniques. However, these techniques may be practiced without these specific details. In some cases, well-known structures and devices are shown in block diagram form to avoid obscuring the concept of the described examples.

[0443] Although this specification contains details of various specific implementations, these should not be construed as limiting any invention or the scope of the claims, but rather as descriptions of specific features of particular embodiments of a particular invention. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually in multiple embodiments or in any suitable sub-combination. Furthermore, although features may be described above as functioning in certain combinations, and even initially claimed as such, in some cases one or more features from a claimed combination may be removed from that combination, and the claimed combination may be for sub-combinations or variations thereof.

[0444] It should be understood that the specific order or hierarchy of steps in the methods of this disclosure is an illustration of an exemplary process. Based on design preferences, it is understood that the specific order or hierarchy of steps in the method can be rearranged to achieve the functions and effects disclosed in this disclosure. The appended method claims present the elements of various steps in an exemplary order and are not intended to limit one to the specific order or hierarchy presented, unless otherwise specifically stated. Furthermore, although elements may be described or claimed in the singular, the plural is also contemplated unless a limitation on the singular is expressly stated. Therefore, this disclosure is not limited to the examples shown, and any means for performing the functions described herein are included in various aspects of this disclosure.

[0445] It is understood that “at least one of them / at least one” described in this disclosure includes any and / or all possible combinations of the listed items, the various embodiments described in this disclosure and the various examples in the embodiments can be changed and combined in any suitable form, and “ / ” described in this disclosure means “and / or”.

[0446] The text and accompanying drawings are provided by way of example only to aid the reader in understanding this disclosure. They are not intended and should not be construed as limiting the scope of this disclosure in any way. Although certain embodiments and examples have been provided, it will be apparent to those skilled in the art, based on the content disclosed herein, that changes may be made to the illustrated embodiments and examples without departing from the scope of this disclosure.

Claims

1. A method performed by a first node in a wireless communication system, comprising: Send a first request message to the second node. The first request message is used to request the identifier of the Early Random Access Channel (RACH) resource requester to which the candidate cell for the mobility LTM handover triggered by Layer 1 / Layer 2 belongs. Receive a first response message from the second node, the first response message including the identifier of the candidate cell and the identifier of the early RACH resource requester to which the candidate cell belongs; Wherein, the first node is the centralized unit (CU) of the source node, and the second node is the CU of the candidate node; or, the first node is the master node, and the second node is the auxiliary node.

2. The method as described in claim 1, wherein, The first response message also includes the identifier of the node to which the earlier RACH resource requester belongs.

3. The method as described in claim 1, wherein, The first request message includes the identifier of the candidate cell and indication information for requesting the identifier of the early RACH resource requester; The identifier of the early RACH resource requester is an identifier indicating an entity requesting an early RACH resource.

4. The method of claim 1, wherein, The first request message includes at least one of the following: Xn establishes a request message; Xn Application Protocol (AP) queries the early RACH resource requester identification request message; and XnAP Next-Generation Wireless Access Network Node Configuration Update Message.

5. The method of claim 1, wherein, The first response message includes at least one of the following: Xn establishes a response message; Xn Application Protocol (AP) queries the response message for the early RACH resource requester identifier; and XnAP Next-Generation Wireless Access Network Node Configuration Update Confirmation Message.

6. The method of claim 1, wherein, The method further includes: Receive a second message from the second node, the second message including at least one of the following: Information related to the timing advance (TA) of the candidate cells; The identifier of the early RACH resource requester; and The identifier of the node to which the early RACH resource requester belongs.

7. The method of claim 6, wherein, The method further includes: Information related to the TA of the candidate cell is sent to the node indicated by the identifier of the node to which the early RACH resource requester belongs or to the node indicated by the identifier of the early RACH resource requester.

8. A method performed by a second node in a wireless communication system, comprising: Receive a first request message from the first node, the first request message being used to request the identifier of the Early Random Access Channel (RACH) resource requester to which the candidate cell for the mobility LTM handover triggered by Layer 1 / Layer 2 belongs; Send a first response message to the first node. The first response message includes the identifier of the candidate cell and the identifier of the early RACH resource requester to which the candidate cell belongs. Wherein, the first node is the centralized unit (CU) of the source node, and the second node is the CU of the candidate node; or, the first node is the master node, and the second node is the auxiliary node.

9. The method of claim 8, wherein, The first response message also includes the identifier of the node to which the earlier RACH resource requester belongs.

10. The method of claim 8, wherein, The first request message includes the identifier of the candidate cell and indication information for requesting the identifier of the early RACH resource requester; The identifier of the early RACH resource requester is an identifier indicating an entity requesting an early RACH resource.

11. The method of claim 8, wherein, The method further includes: Send a second message to the first node, the second message including at least one of the following: Information related to the timing advance (TA) of the candidate cells; The identifier of the early RACH resource requester; and The identifier of the node to which the early RACH resource requester belongs.

12. A method performed by a user equipment (UE) in a wireless communication system, comprising: Receive Radio Resource Control (RRC) reconfiguration message. Send an RRC reconfiguration complete message; The first request message is sent by the first node, and the first request message is used to request the identifier of the Early Random Access Channel (RACH) resource requester to which the candidate cell of the mobility LTM handover triggered by Layer 1 / Layer 2 belongs; The first response message is sent by the second node, and the first response message includes the identifier of the candidate cell and the identifier of the early RACH resource requester to which the candidate cell belongs; Wherein, the first node is the centralized unit (CU) of the source node, and the second node is the CU of the candidate node; or, the first node is the master node, and the second node is the auxiliary node.

13. A node, comprising: A transceiver is configured to send and receive signals; and A processor, coupled to the transceiver, and configured to perform the method according to any one of claims 1 to 11.

14. A user equipment, comprising: A transceiver is configured to send and receive signals; and A processor, coupled to the transceiver, is configured to perform the method as described in claim 12.

15. A computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, perform the method of any one of claims 1 to 12.

Images