Distinguishing and identification of random access channel (RACH) procedures

By introducing a 1-bit indicator and a dedicated RACH preamble into the RACH preamble and request message, the problem of indistinguishable RACH processes in the decomposed gNB architecture is solved, achieving accurate acquisition of TA and improved switching efficiency.

CN121666818APending Publication Date: 2026-03-13RAKUTEN SYMPHONY INC
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-08-29
Publication Date
2026-03-13

AI Technical Summary

Technical Problem

In the decomposed gNB architecture, existing technologies cannot effectively distinguish and identify the Random Access Channel (RACH) process, resulting in the inability to accurately obtain timing advance (TA), which affects the efficiency of mobility management and handover latency.

Method used

By introducing a 1-bit indicator in the RACH preamble format and request message, the purpose of the RACH process can be distinguished, such as for TA acquisition or LTM cell handover, and a dedicated RACH preamble can be assigned to each candidate/target gNB-DU, ensuring that the gNB-DU can perform handover operations autonomously without upper-layer interaction.

Benefits of technology

It enables effective identification and TA acquisition of the RACH process in a decomposed gNB architecture, reducing mobility management latency and improving handover efficiency and accuracy.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121666818A_ABST
    Figure CN121666818A_ABST
Patent Text Reader

Abstract

Embodiments disclosed herein provide a method and system for receiving, at a first network entity, a configuration message from a second network entity to perform a random access channel (RACH) procedure with a fourth network entity to perform a network function, the configuration message including a random access channel (RACH) preamble. Further, a command to perform the network function is received at the first network entity from at least one of the second network entities. Further, the RACH procedure is performed at the first network entity by sending a RACH request message comprising a RACH preamble to a fourth network entity, the RACH preamble comprising the indicator. The indicator indicates a network function. Further, a network function is performed at the first network entity based on the received command.
Need to check novelty before this filing date? Find Prior Art

Description

Cross-reference to related applications

[0001] This application claims the benefit of Indian Provisional Patent Application No. 202341065273, filed on 28 September 2023, and Indian Patent Application No. 202341065273, filed on 3 July 2024, the entire disclosure of which is incorporated herein by reference in its entirety for all purposes. Technical Field

[0002] This disclosure generally relates to the field of wireless communications, and more specifically to the distinction and identification of random access channel (RACH) procedures for achieving timing advance (TA) purposes. Background Technology

[0003] A cellular network is a telecommunications interconnection between user equipment and cellular base stations (BSs) (such as cell towers). A BS comprises a service area divided into multiple cells. A cell defines a geographical area served by a transceiver antenna associated with the BS. Multiple user equipment existing in a particular cell (also called a serving cell) communicate with the transceiver antenna associated with the BS on multiple frequencies and frequency channels.

[0004] The Radio Access Network (RAN) is part of a cellular network and is responsible for implementing radio access technologies. The RAN provides user equipment (such as mobile phones / devices, computers, or any remotely controlled devices present in the network) with connectivity to the Core Network (CN). User equipment can be referred to as User Equipment (UE), terminal equipment, mobile station (MS), etc.

[0005] When a mobile device (such as a UE) connects to a serving cell, the mobile device performs measurements of channel and signal parameters related to the serving cell and neighboring cells within a predefined time period. Furthermore, when multiple UEs connect to the serving cell, because the UE is not always stationary relative to the base station, changes in the distance between the UE and the gNB will be reflected in the UL transmission time (i.e., the message received at the gNB). Due to this variation, the gNB experiences interference because UL transmissions from different UEs may overlap. Therefore, based on the distance between the serving BS and the UE, a time offset, called timing advance (TA), is derived by measuring the time it takes for radio waves to travel from the UE to the serving BS. Moreover, the value of TA can be affected by changes in the distance between the UE and the serving BS caused by UE movement. Mobility management techniques can be employed to allocate, control, and manage mobile communication-related devices, services, and infrastructure to provide service continuity to mobile UEs.

[0006] When a UE moves from the coverage area of ​​one cell to the coverage area of ​​another, a handover (HO) procedure is initiated to change the serving cell for the UE. This mobility management is already handled based on Layer 3 Radio Resource Channel (RRC). The extension of mobility to lower layers (L1 / L2) is a key development in 3GPP. Layer 1 / L2 triggered mobility (LTM) has been adopted to enable UEs to change their serving cell via Layer 1 / L2 signaling. For example, if a UE is moving from the coverage area of ​​the serving cell to the coverage area of ​​one of the neighboring cells (also known as the target cell), an HO procedure is performed, where the UE needs to connect to the neighboring cell and disconnect from the serving cell.

[0007] However, it should be understood that UE mobility can also be implemented using an alternative to LTM, which will not be discussed here for the sake of brevity. In LTM, based on UE mobility and in order to perform a handover from the serving cell to the target cell, the UE needs to acquire knowledge of the TA (Technical Context) associated with the target cell to perform the handover and continue communication with the target cell. Knowledge of the TA is necessary for the UE to perform proper synchronization (also known as UL synchronization) and connection with the target cell.

[0008] For example, 5G advanced technologies are configured with a decomposed BS (or gNodeB (gNB)) architecture defined for cellular networks (such as... Figure 1 (As shown). For example, the 3rd Generation Partnership Project (3GPP) defines a decomposed next-generation node B (gNB) architecture, which decomposes the gNB into multiple logical entities. For example, a gNB may include a gNB Control Unit-Control Plane (CU-CP), a gNB Control Unit-User Plane (CU-UP), and a gNB Distributed Unit (DU). Similarly, a single DU can be responsible for hosting multiple cells. As an example, in the current 3GPP specification, a single DU can be responsible for hosting up to 512 cells. The gNB-CU-CP can host the Packet Data Convergence Protocol (PDCP-c) and Radio Resource Control (RRC) layers, the gNB-CU-UP can host the Packet Data Convergence Protocol (PDCP-u) and Service Data Adaptation Protocol (SDAP), while the gNB-DU hosts the Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) layers. Here, scheduling operations are performed at the gNB-DU. Effectively supporting L1 / L2-centric inter-cell changes (i.e., changes in serving cells) is a key requirement in the decomposed gNB architecture.

[0009] The information disclosed in the Background section of this disclosure is intended only to enhance the understanding of the general background of this disclosure and should not be construed as an admission of prior art known to those skilled in the art or any form of implication. Summary of the Invention

[0010] This disclosure relates to an apparatus configured to receive a configuration message at a first network entity from one of a second and a third network entity to perform a RACH procedure with a fourth network entity to execute network functions. The configuration message includes a Random Access Channel (RACH) preamble. Furthermore, the apparatus receives a command at the first network entity from the second network entity to execute network functions. Additionally, the apparatus is configured to perform the RACH procedure at the first network entity by sending a RACH request message including a RACH preamble. At least one of the RACH preamble format and the RACH request message may include an indicator for the fourth network entity. Furthermore, the indicator may indicate network functions. The apparatus is also configured to execute network functions at the first network entity based on the received command.

[0011] This disclosure also relates to a method comprising the steps of: receiving, at a first network entity, a configuration message from one of a second and a third network entity to perform a RACH procedure with a fourth network entity to perform a network function, the configuration message including a Random Access Channel (RACH) preamble. Furthermore, the method includes receiving, at the first network entity, a command from the second network entity to perform the network function. Additionally, the method includes performing the RACH procedure at the first network entity by sending a RACH request message including a RACH preamble. At least one of the RACH preamble format and the RACH request message includes an indicator to the fourth network entity. Furthermore, the indicator may indicate a network function. The method also includes performing the network function at the first network entity based on the received command.

[0012] Furthermore, this disclosure relates to an apparatus configured to receive an LTM candidate cell configuration preparation request message from a third network entity at a first network entity. The apparatus is further configured to transmit an LTM candidate cell configuration from the first network entity to at least one of a second and a fourth network entity. This LTM candidate cell configuration includes a separate dedicated RACH preamble assigned for each network function, for random access procedures to be performed by the second and first network entities based on the dedicated RACH preambles assigned corresponding to the network functions. The apparatus is also configured to determine, at the first network entity, a network function to be performed by the second network entity based on the dedicated RACH preambles. The apparatus is further configured to send a response from the first network entity to at least one of the second and fourth network entities regarding the performance of the determined network function.

[0013] The foregoing description of the invention is merely illustrative and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments, and features described above, other aspects, embodiments, and features will become apparent from the accompanying drawings and the following detailed description. Attached Figure Description

[0014] The novel features and characteristics of this disclosure are set forth in the appended claims. However, the disclosure itself, as well as preferred uses, further objects and advantages, will be best understood by referring to the following detailed description of illustrative embodiments when read in conjunction with the accompanying drawings. One or more embodiments will now be described by way of example only, with reference to the accompanying drawings, wherein like reference numerals denote like elements, and in the drawings:

[0015] Figure 1 This illustrates the existing decomposed gNB architecture;

[0016] Figure 2 A schematic representation 200 of a RAR configuration for UE 202 according to an embodiment disclosed herein is shown;

[0017] Figure 3 This is a sequence diagram illustrating a method for implementing RACH process identification in a first embodiment according to the embodiments disclosed herein;

[0018] Figure 4 This is a sequence diagram illustrating a method for implementing RACH process identification in a second embodiment according to the embodiments disclosed herein;

[0019] Figure 5 A flowchart illustrating a method for implementing RACH process identification at candidate / target gNB-DU according to embodiments disclosed herein; and

[0020] Figure 6 A detailed block diagram of an apparatus for implementing a method of identifying the RACH process at a candidate / target gNB-DU according to embodiments disclosed herein is shown.

[0021] Those skilled in the art will understand that any block diagram herein represents a conceptual view of an illustrative system embodying the principles of the subject matter. Similarly, it will be understood that any flowchart, diagram, state transition diagram, pseudocode, etc., represents various processes that can be substantially represented in a computer-readable medium and executed by a computer or processor, whether or not such computer or processor is explicitly shown. Detailed Implementation

[0022] It should be understood that this disclosure may assume various alternative variations and sequences of steps unless explicitly specified otherwise. It should also be understood that the specific devices and processes shown in the accompanying drawings and described in the following specification are merely exemplary and non-limiting embodiments or aspects. Therefore, specific dimensions and other physical characteristics relating to the embodiments or aspects disclosed herein should not be considered limiting.

[0023] In this document, the word "exemplary" is used to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

[0024] While this disclosure is readily adaptable to various modifications and alternatives, specific embodiments thereof have been illustrated by way of example in the accompanying drawings and will be described in detail below. However, it should be understood that this disclosure is not intended to limit it to the specific forms disclosed; rather, it is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of this disclosure.

[0025] The terms “comprising,” “including,” or any other variations thereof are intended to cover non-exclusive inclusion, such that a setup, device, or method that includes a list of components or steps may include not only those components or steps but also other components or steps not expressly listed or inherent to such setup, device, or method. In other words, one or more elements in a device, system, or apparatus that begin with “comprising…” do not exclude the presence of other elements or additional elements in the device, system, or apparatus without further constraints.

[0026] The terms “an embodiment,” “an embodiment,” “multiple embodiments,” “the embodiment,” “these embodiments,” “one or more embodiments,” “some embodiments,” and “an embodiment” mean “one or more (but not all) embodiments of this disclosure”, unless otherwise expressly stated.

[0027] The terms “including,” “comprising,” “having,” and their variations mean “including but not limited to,” unless otherwise expressly stated.

[0028] In the following detailed description of embodiments of the present disclosure, reference is made to the accompanying drawings, which form a part therein, and specific embodiments in which the present disclosure may be practiced are illustrated by way of illustration. These embodiments have been described in sufficient detail to enable those skilled in the art to practice the present disclosure, and it should be understood that other embodiments may be utilized and changes may be made without departing from the scope of the present disclosure. Therefore, the following description should not be considered limiting.

[0029] Generally, the goals of mobility management are defined, with reducing mobility latency and quickly applying configurations for L1 / L2 triggered mobility (LTM) being critical. In existing handover (HO) techniques, the UE waits for a Physical Random Access Channel (PRACH) opportunity and performs a RACH to synchronize with the uplink (UL) of the target cell. This is necessary because the timing advance (TA) of the target cell (configured for HO) may differ from the TA of the serving cell. During the RACH process, the UE acquires its timing advance at the target cell. Those skilled in the art will understand that the timing advance is UE-specific and may differ for different UEs within the cell.

[0030] For LTM, to reduce user plane outage time during HO (House Opening) phases, the UE can be commanded by the serving gNB-DU (before the LTM serving cell change) using PDCCH commands to perform UL synchronization with the candidate / target gNB-DU. During this UL synchronization, the UE can send a reserved non-contention-free random access (CFRA) preamble to the candidate / target gNB-DU during LTM candidate / target cell preparation and obtain the UE's timing advance in the candidate / target cell. This timing advance (TA) in the candidate / target cell can be directly passed from the candidate / target DU to the UE, or passed to the gNB-CU, and from the gNB-CU to the serving gNB-DU via the F1 interface. The serving gNB-DU can use the obtained TA during LTM cell handover to determine whether to perform a RACH-free cell handover. This helps the UE reduce handover latency because it avoids performing RACH during the actual LTM serving cell change, since the target cell's TA is already available.

[0031] Traditionally, based on the techniques used for LTM in the radio layers (RAN1 and RAN2), the RACH procedure can be used to obtain the TA of a candidate / target cell before LTM cell handover, while the UE remains connected to the serving cell. However, the RACH procedure performed by the UE to obtain the TA is the same as the RACH procedure used during RACH-based LTM cell handover or other use cases. Therefore, the purpose of identifying the RACH procedure at the candidate / target gNB-DU is not feasible, meaning that appropriate actions cannot be performed.

[0032] The methods and systems disclosed herein address the technical problem of implementing L1 / L2-centric inter-cell changes (i.e., changes in serving cells) in a decomposed gNB architecture. Here, a technology or mechanism may be required that allows configuration to be performed at the gNB-CU-CP, while being autonomously executed by the gNB-DU without further interaction with upper layers. This disclosure addresses this technical problem as described in the following embodiments.

[0033] The embodiments disclosed herein provide a method and system for identifying the RACH procedure at a candidate / target gNB-DU. For example, this disclosure discloses a method for distinguishing between a Random Access Channel (RACH) procedure performed for Timing Advance (TA) acquisition and a Random Access Channel (RACH) procedure performed for serving cell change, and a method for identifying the Random Access Channel (RACH) used to acquire Timing Advance (TA) at a candidate / target gNB-DU. In embodiments, the method of this disclosure includes modifying the RACH preamble format or the random access request message to indicate the intent of the RACH procedure. For example, a 1-bit indicator can be defined for use in the RACH preamble of the random access request message to indicate whether the RACH is for acquiring a TA or for performing an LTM cell handover using a conventional RACH procedure. When the serving gNB-DU sends a PDCCH command to the UE to acquire a TA from a candidate / target cell, the UE can use the defined 1-bit indicator to indicate TA acquisition. In addition, when the serving gNB-DU sends a downlink (DL) MAC control element (CE) requesting the UE to perform a RACH-based LTM cell handover, a 1-bit indicator is used to indicate an LTM cell handover using the normal RACH procedure. This RACH-based LTM cell handover can be sent due to various conditions, such as, but not limited to, TA acquisition failure or TA timer expiration.

[0034] In another embodiment, the method of this disclosure includes allocating a separate dedicated RACH preamble pool in each candidate / target gNB-DU for acquiring a TA and performing a conventional RACH procedure. During LTM candidate cell preparation, based on a request from the serving gNB-CU-CP, the method includes allocating separate RACH preambles for TA acquisition and RACH-based LTM cell handover. Therefore, the allocated dedicated preambles should also be transmitted to the UE in the LTM candidate cell configuration, indicating that a RACH preamble for one UE cannot be used for another UE. Thus, depending on the RACH preamble being used, the candidate / target gNB-DU can determine whether the UE is performing a TA acquisition or a RACH-based LTM cell handover procedure (e.g., due to TA acquisition failure or TA timer expiration).

[0035] Therefore, this disclosure enables candidate / target gNB-DUs to determine the purpose of the RACH process and take appropriate actions.

[0036] Figure 1The existing decomposed gNB architecture is illustrated. In the existing (or traditional) decomposed gNB architecture, as defined in 3GPP, the traditional gNB 100 can be decomposed into multiple logical entities. For example, the traditional gNB 100 may include a gNB Control Unit-Control Plane (CU-CP) 101 (gNB Control Unit-Control Plane (CU-CP)) and a gNB Control Unit-User Plane (CU-UP) 103 (gNB Control Unit-User Plane (CU-UP), for simplicity, CU-CP and CU-UP are also referred to hereinafter as gNB Central Unit (CU)) and a gNB DU 102. Similarly, a single DU 102 can be responsible for hosting multiple cells (not shown). As an example, in the current 3GPP specification, a single DU 102 can be responsible for hosting up to 512 cells. gNB-CU-CP 101 can host the Packet Data Convergence Protocol (PDCP-c) and Radio Resource Control (RRC) layers, while gNB-DU 102 hosts the Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) layers. Scheduling operations are performed at gNB-DU 102. To support L1 / L2-centric inter-cell changes related to changes in the serving cell (not shown) in a decomposed gNB architecture, a mechanism is implemented where scheduling operations / configuration are performed at gNB-CU-CP 101, but autonomously executed by gNB-DU 102 without any further interaction with upper layers. For example, this mechanism involves handover preparation being performed by gNB-CU-CP 101, but the handover being performed autonomously by gNB-DU 102 without further interaction with upper layers (such as PDCP and RRC layers).

[0037] Traditionally, a decomposed gNB architecture may also include logical nodes, such as gNB-CU-User Plane (gNB-CU-UP) 103, to host the user plane portion of the PDCP-u protocol and / or the Service Data Adaptation Protocol (SDAP) protocol of gNB-CU 101. gNB-CU-UP 103 terminates at an E1 interface connected to gNB-CU-CP 101 and an F1-U interface connected to gNB-DU 102.

[0038] Generally speaking, the objectives of mobility management have been defined in 3GPP Release 18 based on the following principles: (a) Specification of L1 / L2-based inter-cell mobility mechanisms and processes for mobility latency reduction: The configuration and maintenance of multiple candidate cells allow for the rapid application of configurations for candidate cells [RAN2, RAN3]. A dynamic handover mechanism between candidate serving cells (including SpCell and SCell) based on L1 / L2 signaling is proposed for potential applicable scenarios [RAN2, RAN1]. (b) L1 enhancement for inter-cell beam management, including L1 measurement and reporting and beam indication [RAN1, RAN2]. Scheduled advance management [RAN1, RAN2]. If needed, support L1 / L2 mobility CU-DU interface signaling [RAN3]. For example, if applicable, FR2-specific enhancements may not be excluded.

[0039] The process based on L1 / L2 inter-cell mobility can be applied to the following scenarios: • Standalone, CA, and NR-DC scenarios, where the serving cell changes within a CG. • Intra-DU and intra-CU DU scenarios (applicable to standalone and CA: no new RAN interface expected). • Both within and between frequencies. • Both FR1 and FR2. • The source cell and the target cell can be synchronous or asynchronous.

[0040] L1 / L2 triggered mobility is a mobility feature that can be considered a basic UE capability. Therefore, the features mentioned above, especially points (a) and (b), indicate that reducing mobility latency and quickly applying configurations for low-level mobility (LLM) are critical.

[0041] According to existing technology, the principles previously agreed upon / adopted in Radio Access Networks 1 and 2 (RAN1 and RAN2) are defined as follows:

[0042] For RACH of PDCCH commands for candidate cells, RAR reception can be configured / instructed. Without configuring / indicating Random Access Response (RAR) reception (no RAR): The TA value of a candidate cell is indicated in the cell handover command. From a future perspective: When RAR reception is not configured / indicated, should the UE retransmit PRACH, and how should the UE determine the transmission power of subsequent PRACHs triggered by the PDCCH command? In the case of configuring / instructing RAR reception (with RAR): Is the RAR received from the serving cell or from the candidate cell? If the RAR is received from a candidate cell, should the Type 1-PDCCH CSS of the candidate cell be configured in the U content E of the RAR? From a future perspective, this is used for signaling configuration / instructions regarding whether or not RAR needs to be received. The UE can report a combination of support for RAR only and support for no RAR only, where support for a default scheme is the baseline UE method for LTM. Send LS to RAN2 and RAN3 to check the feasibility of the agreement.

[0043] Based on the technology employed, if RAR reception is configured / instructed, the RAR must contain at least the TAs of the candidate cells. The maximum number of TA values ​​that the UE can remember is the UE's capability.

[0044] Therefore, based on the technology used for LTM in the radio layers (RAN1 and RAN2), the RACH procedure can be used to obtain the TA of the candidate / target cell before LTM cell handover, while the UE remains connected to the serving cell. However, the RACH procedure performed by the UE to obtain the TA of the candidate cell is the same as the RACH procedure used during traditional handover scenarios or other use cases. Therefore, the purpose of identifying the RACH procedure at the candidate / target gNB-DU is not feasible, meaning that appropriate actions cannot be performed.

[0045] Figure 2 A schematic diagram 200 illustrates a RAR configuration for UE 202 according to an embodiment disclosed herein. UE 202 can communicate with serving cell 204 (hereinafter also referred to as serving base station 204 or serving gNB distributed element (DU) 204, since serving gNB-DU 204 may include one or more serving cells (not shown)). RAR reception is configured / instructed for RACH of PDCCH commands against candidate cells 206A, 206B (hereinafter also referred to as candidate / target base stations 206A, 206B or target / candidate gNB-DU 206A, 206B, since target / candidate gNB-DU 206A, 206B may include one or more target / candidate cells 206A, 206B).

[0046] In one embodiment, at link 208, UE 202 can send the target cell RSRP to serving cell 204 via link 208 using an L1 measurement report. In another embodiment, at link 210, serving cell 204 can use a PDCCH command to configure UE 202 to perform UL synchronization by sending a PRACH preamble, enabling UE 202 to acquire the target cell TA.

[0047] In operation, in this embodiment, UE 202 can receive a message including a Random Access Channel (RACH) preamble from serving base station 204 or serving base station central unit (gNB-CU) to perform a RACH procedure with a target base station distributed unit (target gNB-DU) or a candidate base station distributed unit (candidate gNB-DU) to perform network functions. In the example, UE 202 can receive a message including a RACH preamble from candidate / target base stations 206A and 206B. In this embodiment, UE 202 can be a first network entity, the serving base station distributed unit (or serving gNB-DU or serving base station 204) can be a second network entity, the serving base station central unit can be a third network entity, and one of the target base station distributed unit (also referred to as the target gNB-DU) and the candidate base station distributed unit (also referred to as the candidate gNB-DU) can be a fourth network entity. In another example, one of the candidate / target base stations 206A and 206B can be a fourth network entity. In this example, UE 202 can receive a command from the serving base station distributed unit to perform network functions. In one embodiment, the command may be a PDCCH command for performing TA acquisition functions. In another embodiment, the command may be a MAC CE command for performing normal RACH functions for LTM serving cell handover.

[0048] Furthermore, UE 202 can perform the RACH procedure by sending a RACH request message including a RACH preamble to candidate / target base stations 206A and 206B (functions implemented / on candidate / target base stations 206A and 206B can also be implemented / on the target base station distributed element or candidate base station distributed element; however, for brevity, this will not be described further below). In the example, at least one of the RACH preamble format and the RACH request message may include an indicator. In the example, the indicator may be a 1-bit indicator. For example, the indicator may indicate a network function. In an embodiment, UE 202 may be configured to encode the value of the indicator based on the network function indicated in the configuration message. In an embodiment, the indicator may indicate that the network function is a RACH procedure performed during an LTM serving cell handover function. For example, the serving cell handover function may include performing a cell handover associated with UE 202 from serving base station 204 to candidate / target base stations 206A and 206B.

[0049] In an embodiment, the indicator may indicate that the network function is a timing advance (TA) acquisition function. Furthermore, the TA acquisition function may include receiving a TA at UE 202 to perform the network function. For example, the TA may be a corresponding TA associated with an LTM candidate cell of candidate / target base stations 206A and 206B.

[0050] In one embodiment, the indicator may include allocation information indicating the type of the RACH preamble, meaning that a given network function or RACH preamble indicates the purpose of the RACH procedure to the candidate / target gNB-DU. In another embodiment, the RACH preamble may indicate a RACH preamble allocated for a TA acquisition operation. In yet another embodiment, the RACH preamble may indicate a RACH preamble allocated for a RACH-based LTM cell handover operation. For example, the RACH preamble type may indicate to candidate / target base stations 206A, 206B that UE 202 is configured to perform a TA acquisition operation or a RACH-based LTM cell handover operation. In yet another embodiment, the indicator may include non-allocation information. For example, if the indicator includes non-allocation information, the RACH preamble type may not indicate the RACH preamble type for both the TA acquisition operation and the RACH preamble type for the RACH-based LTM cell handover operation.

[0051] In an embodiment, UE 202 may be configured to send measurement reports (MRs) to a first distributed element (DU) of serving base station 204, which are associated with one or more signal and channel parameters of a plurality of LTM candidate cells 206A, 206B associated with one or more serving base stations and neighboring base stations. In an example, UE 202 may be configured to send L1 MRs to the first DU, which are associated with a plurality of candidate cells 206A, 206B associated with the first DU and with one or more signal and channel parameters of a plurality of DUs associated with one or more neighboring base stations. In an embodiment, UE 202 may send Layer 1 (L1) MRs for the plurality of candidate cells 206A, 206B to serving gNB-DU 204. In an example, the plurality of candidate cells may include a plurality of non-serving cells.

[0052] Furthermore, after receiving the L1 MR at the serving base station 204, the first DU of the serving base station 204 can determine the candidate cells of the target base stations 206A and 206B from one or more DUs of one or more candidate base stations. Note: The candidate cells may also belong to the same base station as the serving cell. In this embodiment, the target base station may be the serving base station. In another embodiment, the determination of the candidate cells may be based on one or more signal and channel parameters of multiple candidate cells from one or more neighboring base stations. Based on the determination of the target base stations 206A and 206B, the first DU may send a request to the UE 202 to perform uplink synchronization to obtain the TA of the determined candidate cells.

[0053] Accordingly, UE 202 can receive a request from the first DU of serving base station 204 to perform uplink synchronization with the candidate cells of the second DU associated with candidate / target base stations 206A and 206B, based on the RACH configuration indicated in the LTM candidate cell configuration sent to the UE in the RRC reconfiguration message during LTM candidate cell preparation. Alternatively, UE 202 can perform uplink synchronization by sending a Random Access Channel (RACH) request message to the second DU.

[0054] In this embodiment, from the perspective of candidate / target base stations 206A and 206B, candidate / target base stations 206A and 206B can receive a Random Access Channel (RACH) request message including a RACH preamble from the UE. In this example, the RACH preamble format may include an indicator indicating a network function. For example, the indicator may indicate that the network function is one of an LTM serving cell handover function and a timing advance (TA) acquisition function. In this embodiment, the indicator may indicate that the network function is one of an LTM serving cell handover function and a timing advance (TA) acquisition function.

[0055] During LTM candidate cell preparation, at the request of the serving gNB-CU-CP, candidate base stations 206A and 206B can send an LTM candidate cell configuration, including a common RACH preamble for network functions, timing acquisition, and RACH-based LTM cell handover, to the UE via the serving gNB-CU. Subsequently, when the serving gNB-DU issues a PDCCH command to the UE to perform UL synchronization and acquire timing advance from the candidate gNB-DU cell, the UE encodes an indicator in the RACH preamble format of the RACH request message to indicate that the network function is timing acquisition. When the serving gNB-DU sends a DL MAC CE to perform RACH-based LTM cell handover, the UE encodes an indicator in the RACH preamble format of the RACH request message to indicate that the network function is RACH-based LTM cell handover. In an alternative embodiment, candidate / target base stations 206A and 206B can send an LTM candidate cell configuration, including separate dedicated RACH preambles for timing acquisition and RACH-based LTM cell handover, to the UE via the serving gNB-CU. In this embodiment, candidate / target base stations 206A and 206B can send LTM candidate cell configurations to UE 202 and instruct to perform a random access procedure based on the type of RACH preamble corresponding to the network function. In this embodiment, the type of RACH preamble indicates one of the RACH preamble used for TA acquisition operations and the RACH preamble used for RACH-based LTM cell handover operations. When the serving gNB-DU commands the UE to perform a timing acquisition or LTM cell handover, the UE uses the corresponding RACH preamble allocated for the given network function.

[0056] In another embodiment, in relation to the candidate / target base stations 206A and 206B, the target base station distributed unit and the candidate base station distributed unit (hereinafter also referred to as candidate / target base station distributed unit or candidate / target base station 206A and 206B) can be a first network entity, the UE 202 can be a second network entity, the serving base station central unit can be a third network entity, and the serving base station distributed unit (or serving base station 204) can be a fourth network entity.

[0057] In operation, according to embodiments from the perspective of candidate / target base stations 206A and 206B, the candidate / target base station distributed unit can receive an LTM candidate cell configuration preparation request message from the serving base station central unit entity. Furthermore, the candidate / target base station distributed unit can send LTM candidate cell configuration to at least one of the UE 202 and the serving base station distributed unit. The LTM candidate cell configuration may include a separate dedicated RACH preamble allocated for each network function, for the UE 202 and the candidate / target base station distributed unit to perform a random access procedure based on the dedicated RACH preamble allocated corresponding to the network function. Additionally, the candidate / target base station distributed unit can determine the network function to be performed by a second network entity based on the dedicated RACH preamble. The candidate / target base station distributed unit can then send a response to at least one of the UE 202 and the serving base station distributed unit to perform the determined network function.

[0058] Figure 3 This is a sequence diagram illustrating a method for implementing RACH process identification in a first embodiment according to the embodiments disclosed herein.

[0059] Sequence diagrams can be described within the general context of computer-executable instructions. Typically, computer-executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions that perform specific functions or implement specific abstract data types.

[0060] The order of steps described in the sequence diagram is not intended to be construed as limiting, and any number of described boxes in the sequence diagram can be combined in any order to implement the method shown in the sequence diagram. Furthermore, individual boxes can be removed from the method without departing from the scope of the subject matter described herein. Moreover, the method shown in the sequence diagram can be implemented in any suitable hardware, software, firmware, or a combination thereof.

[0061] For ease of description, one or more steps of LTM are described below using candidate cells. It can be understood that one or more steps can also be performed together with one or more candidate cells.

[0062] Figure 3The interaction between UE 202, serving gNB-DU 204 (hereinafter also referred to as serving base station 204), target / candidate gNB-DU (hereinafter also referred to as candidate / target base stations 206A, 206B) and gNB central unit (CU) 101 is shown.

[0063] refer to Figure 3 At S301, UE 202 is configured with LTM in a gNB-DU (e.g., serving base station 204).

[0064] At step S302, UE 202 uses the RRC connection with gNB-CU 101 and sends L3 RRC measurements to gNB-CU 101 on layer 3.

[0065] In step S303, gNB-CU 101 determines to prepare candidate / target base stations 206A and 206B. In this example, candidate / target base stations 206A and 206B can be inter-gNB DU LTM candidate cells.

[0066] In step S304, gNB-CU 101 initiates a UE context establishment request message to candidate / target base stations 206A and 206B through the F1 interface to prepare candidate / target base stations 206A and 206B.

[0067] In step S305, candidate / target base stations 206A and 206B confirm the information using the UE context establishment response message through the F1 interface and provide candidate / target cell configuration.

[0068] In step S306, gNB-CU 101 sends a DL RRC message forwarding (RRC reconfiguration (LTM target cell configuration)) to the serving base station 204 through the F1 interface.

[0069] At step S307, an RRC reconfiguration message is passed to UE 202. The serving base station 204 check is set to trigger the transmission of a set of RRM criteria (e.g., predefined RSRP thresholds) for L1 measurements to candidate / target base stations 206A and 206B.

[0070] At step S308, UE 202 is instructed to perform uplink synchronization with the cells of candidate / target base stations 206A and 206B. In the above context, UE 202 is configured to use a 1-bit indicator in the random access request message to indicate whether RACH is used to obtain TA or to perform a conventional RACH procedure.

[0071] In step S309, the serving base station 204 may send a PDCCH command to the UE 202 to obtain TA from the candidate / target base stations 206A and 206B.

[0072] At step S310, UE 202 can use a 1-bit indicator to indicate TA acquisition.

[0073] In step S311, based on the RACH process, candidate / target base stations 206A and 206B can determine that the RACH is performed for TA acquisition.

[0074] In step S312, candidate / target base stations 206A and 206B can send the TA of UE 202 to the serving base station 204.

[0075] At step S313, candidate / target base stations 206A and 206B can indicate to gNB-CU 101 that a UE context modification (or TA) is required.

[0076] At step S314, correspondingly, based on step 313, gNB-CU 101 can send a UE context modification confirmation message to candidate / target base stations 206A and 206B.

[0077] In step S315, gNB-CU 101 may send a UE context modification request to the serving base station 204.

[0078] In step S316, the serving base station 204 may send a UE context modification response to gNB-CU 101 based on the UE context modification request.

[0079] In step S317, the serving base station 204 may store the TAs of the candidate / target base stations 206A and 206B.

[0080] At step S318, UE 202 can perform measurement configuration on layer 1.

[0081] In step S319, based on the measurement configuration on layer 1, the serving base station 204 can make a decision to perform LTM cell handover function.

[0082] At step S320, the serving base station 204 may send a DL MAC CE to instruct the UE 202 to perform a RACH-based LTM cell handover (e.g., due to TA acquisition failure or TA timer expiration).

[0083] At step S321, UE 202 may use a 1-bit indicator and send a preamble including the indicator to candidate / target base stations 206A and 206B to indicate normal RACH.

[0084] At step S322, candidate / target base stations 206A and 206B can determine that RACH is being performed for LTM cell handover and perform appropriate handover actions accordingly.

[0085] Figure 4 This is a sequence diagram illustrating a method for implementing RACH process identification in a second embodiment according to the embodiments disclosed herein.

[0086] Sequence diagrams can be described within the general context of computer-executable instructions. Typically, computer-executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions that perform specific functions or implement specific abstract data types.

[0087] The order of steps described in the sequence diagram is not intended to be construed as limiting, and any number of described boxes in the sequence diagram can be combined in any order to implement the method shown in the sequence diagram. Furthermore, individual boxes can be removed from the method without departing from the scope of the subject matter described herein. Moreover, the method shown in the sequence diagram can be implemented in any suitable hardware, software, firmware, or a combination thereof.

[0088] Figure 4 The interaction between UE 202, serving gNB-DU 204 (hereinafter also referred to as serving base station 204), target / candidate gNB-DU (hereinafter also referred to as candidate / target base stations 206A, 206B) and gNB central unit (CU) 101 is shown.

[0089] refer to Figure 4 At S401, UE 202 is configured with LTM in a gNB-DU (e.g., serving base station 204).

[0090] At step S402, UE 202 uses the RRC connection with gNB-CU 101 and sends L3 RRC measurements to gNB-CU 101 on layer 3.

[0091] In step S403, gNB-CU 101 determines to prepare candidate / target base stations 206A and 206B. In this example, candidate / target base stations 206A and 206B can be inter-gNB DU LTM candidate cells.

[0092] In step S404, gNB-CU 101 initiates a UE context establishment request message to candidate / target base stations 206A and 206B through the F1 interface to prepare inter-DU LTM candidate cells.

[0093] In step S405, candidate / target base stations 206A and 206B confirm the information using the UE context establishment response message through the F1 interface and provide candidate / target cell configuration.

[0094] In step S406, gNB-CU 101 sends a DL RRC message forwarding (RRC reconfiguration (LTM target cell configuration)) to the serving base station 204 through the F1 interface.

[0095] At step S407, an RRC reconfiguration message is passed to UE 202 by providing LTM cell configuration details (RACH preamble for TA acquisition and / or RACH-based LTM cell handover).

[0096] At step S408, UE 202 is instructed to perform uplink synchronization with the cells of candidate / target base stations 206A and 206B. In the above context, based on a request from gNB-CU 101, serving base station 204 can be configured to allocate separate RACH preambles for TA acquisition and RACH-based LTM cell handover. In another example, candidate / target base stations 206A and 206B can be configured to allocate separate RACH preambles for TA acquisition and RACH-based LTM cell handover.

[0097] In step S409, the serving base station 204 may send a PDCCH command to the UE 202 to obtain the TA from the candidate / target base stations 206A and 206B, using preamble type 1 as an indication.

[0098] At step S410, UE 202 can initiate a RACH procedure using a preamble type 1 indicating TA acquisition. In this context, depending on the RACH preamble being used, candidate / target base stations 206A and 206B can determine whether UE 202 is performing a TA acquisition or a RACH-based LTM cell handover procedure (e.g., due to TA acquisition failure or TA timer expiration).

[0099] At step S411, based on the RACH process, candidate / target base stations 206A and 206B can determine that the RACH is performed for TA acquisition based on preamble type 1.

[0100] In step S412, candidate / target base stations 206A and 206B can send the TA of UE 202 to the serving base station 204.

[0101] At step S413, candidate / target base stations 206A and 206B can indicate to gNB-CU 101 that a UE context modification (or TA) is required.

[0102] At step S414, correspondingly, based on step 313, gNB-CU 101 can send a UE context modification confirmation message to candidate / target base stations 206A and 206B.

[0103] In step S415, gNB-CU 101 may send a UE context modification request to the serving base station 204.

[0104] In step S416, the serving base station 204 may send a UE context modification response to gNB-CU 101 based on the UE context modification request.

[0105] In step S417, the serving base station 204 may store the TAs of candidate / target base stations 206A and 206B.

[0106] At step S418, UE 202 can perform measurement configuration on layer 1.

[0107] At step S419, based on the measurement configuration on Layer 1, the serving base station 204 can make a decision to perform LTM cell handover. For example, if the TA is valid, the serving base station 204 can make a decision to perform LTM cell handover without RACH, and if the TA timer has expired, it can perform LTM cell handover based on RACH.

[0108] In step S420, the serving base station 204 may send a DL MAC CE to instruct the UE 202 to perform an LTM cell handover.

[0109] At step S421, UE 202 can use preamble type 2, which indicates normal RACH function, to perform LTM cell handover to candidate / target base stations 206A and 206B.

[0110] At step S422, candidate / target base stations 206A and 206B can determine that RACH is being performed for LTM cell handover and perform appropriate handover actions accordingly.

[0111] Figure 5 A flowchart is shown of a method for implementing RACH process identification at a candidate / target gNB-DU according to embodiments disclosed herein.

[0112] like Figure 5 As shown, method 500 may include one or more steps. Method 500 may be described in the general context of computer-executable instructions. Typically, computer-executable instructions may include routines, programs, objects, components, data structures, procedures, modules, and functions that perform a particular function or implement a particular abstract data type.

[0113] The order in which method 500 is described is not intended to be construed as limiting, and any number of described method blocks can be combined in any order to implement the method. Furthermore, individual blocks can be removed from the method without departing from the scope of the subject matter described herein. Moreover, the method can be implemented in any suitable hardware, software, firmware, or a combination thereof.

[0114] At step 502, UE 202 may receive a configuration message including a Random Access Channel (RACH) preamble from the serving base station distributed unit (or serving gNB-DU) 204 or from the serving base station central unit (gNB-CU) to perform a RACH procedure with candidate / target base stations 206A, 206B (or distributed unit (target gNB-DU) or candidate base station distributed unit (candidate gNB-DU)) to perform network functions. In the embodiment described, UE 202 may be a first network entity, serving base station 204 (or serving base station distributed unit) may be a second network entity, serving base station central unit may be a third network entity, and one of the target base station distributed unit and candidate base station distributed unit (or candidate / target base stations 206A, 206B) may be a fourth network entity.

[0115] At step 504, UE 202 may receive a command from the serving base station distributed element (or serving gNB-DU or serving base station 204) to perform network functions. In one embodiment, the command may be a PDCCH command for performing TA acquisition functions. In another embodiment, the command may be a MAC CE command for performing normal RACH functions for LTM serving cell handover.

[0116] At step 506, UE 202 may perform a RACH procedure by sending a RACH request message including a RACH preamble to the target base station distributed element (target gNB-DU) or candidate base station distributed element (candidate gNB-DU) (or candidate / target base stations 206A, 206B). In an example, at least one of the RACH preamble format and the RACH request message may include an indicator. In an example, the indicator may indicate a network function. In an embodiment, UE 202 may be configured to encode the value of the indicator based on the network function indicated in the configuration message. In an embodiment, the indicator may indicate that the network function is a RACH procedure performed during an LTM serving cell handover function. For example, the serving cell handover function may include performing a cell handover associated with UE 202 from serving base station 204 to the target base station distributed element (target gNB-DU) or candidate base station distributed element (candidate gNB-DU) (or candidate / target base stations 206A, 206B).

[0117] In an embodiment, the indicator may indicate that the network function is a timing advance (TA) acquisition function. Furthermore, the TA acquisition function may include applying the TA at UE 202 based on a command to execute the network function. For example, the TA may be a corresponding TA associated with an LTM candidate cell of a target base station distributed element (target gNB-DU) or a candidate base station distributed element (candidate gNB-DU) (or candidate / target base station 206A, 206B).

[0118] In an embodiment, the indicator may include allocation information indicating the type of RACH preamble. In this embodiment, the allocation information may indicate the type of RACH preamble. In one example, the type of RACH preamble includes a RACH preamble used for TA acquisition operations. In another example, the type of RACH preamble includes a RACH preamble used for RACH-based LTM cell handover operations.

[0119] In this embodiment, the RACH preamble type used for the TA acquisition operation can indicate to the target base station distributed element (target gNB-DU) or candidate base station distributed element (candidate gNB-DU) (or candidate / target base stations 206A, 206B) that UE 202 is configured to perform the TA acquisition operation. In this example, the RACH preamble type used for the RACH-based LTM cell handover operation indicates to the target base station distributed element (target gNB-DU) or candidate base station distributed element (candidate gNB-DU) (or candidate / target base stations 206A, 206B) that UE 202 is configured to perform the RACH-based LTM cell handover operation.

[0120] At step 508, UE 202 can perform network functions based on the received command.

[0121] Figure 6A detailed block diagram of an apparatus 600 for implementing a method for identifying the RACH procedure at candidate / target gNB-DU 206A, 206B is shown. In one embodiment, it will be understood that apparatus 600 is associated with UE 202. In another embodiment, it will be understood that apparatus 600 is associated with serving base station 204. In yet another embodiment, it will be understood that apparatus 600 is associated with candidate / target base station 206A, 206B or target / candidate gNB-DU 206A, 206B. Apparatus 600 may include at least one transmitter 602, at least one receiver 604, at least one processor 608, at least one memory 610, at least one interface 612, and at least one antenna 614. At least one transmitter 602 may be configured to transmit data / information to one or more nodes / devices using antenna 614, and at least one receiver 604 may be configured to receive data / information from one or more nodes / devices using antenna 614. At least one transmitter 602 and receiver 604 may be uniformly implemented as a single transceiver module 606. In a non-limiting embodiment, at least one processor 608 may be communicatively coupled to transceiver module 606, memory 610, interface 612 and antenna 614 to implement the above-described techniques for processing wireless communication, particularly the identification of performing the RACH process.

[0122] At least one processor 608 may include, but is not limited to, one or more microprocessors, microcomputers, microcontrollers, central processing units, state machines, logic circuit systems, and any device that manipulates signals based on operating instructions. The processor may also be implemented as a combination of computing devices, such as a combination of multiple microprocessors or any other such configuration. At least one memory 610 may be communicatively coupled to at least one processor 608 and may include various instructions, UE signal strength data, initial bandwidth portions, one or more dedicated bandwidth portions, predefined intervals, etc. At least one memory 610 may include one or more random access memory (RAM) cells and non-volatile memory cells such as read-only memory (ROM), optical disc drives, disk drives, flash memory, electrically erasable read-only memory (EEPROM), storage space on servers or in the cloud, etc. At least one processor 608 may be configured to execute one or more instructions stored in memory 610.

[0123] Interface 612 may include various software and hardware interfaces, such as network interfaces, graphical user interfaces, input / output (I / O) interfaces, and network interfaces. The I / O interface allows device 600 to communicate directly with one or more nodes / devices or through other devices. The network interface allows device 600 to interact directly with one or more networks or via any other network.

[0124] The device 600 may also include a RACH process identification module 616 to identify the RACH process.

[0125] In embodiment [1], the apparatus is configured to: receive a configuration message at a first network entity from one of a second network entity and a third network entity to perform a RACH procedure with a fourth network entity to perform a network function, the configuration message including a random access channel (RACH) preamble; receive a command at the first network entity from the second network entity to perform a network function; perform a RACH procedure at the first network entity by sending a RACH request message including a RACH preamble to the fourth network entity, wherein at least one of the RACH preamble format and the RACH request message includes an indicator, wherein the indicator indicates a network function; and perform a network function at the first network entity based on the received command.

[0126] In embodiment [2], in the apparatus described in embodiment [1], the first network entity is configured to encode the value of an indicator based on the network function indicated in the configuration message.

[0127] In embodiment [3], in the apparatus described in embodiment [1], the indicator indicates that the network function is a RACH process performed during the LTM serving cell handover function, wherein the LTM serving cell handover function includes performing a cell handover associated with a first network entity from a second network entity to a fourth network entity.

[0128] In embodiment [4], in the apparatus described in embodiment [1], the indicator indicates that the network function is a timing advance (TA) acquisition function, wherein the TA acquisition function includes receiving a TA at a first network entity to perform the network function, and wherein the TA is a corresponding TA associated with an LTM candidate cell of a fourth network entity.

[0129] In embodiment [5], in the apparatus described in embodiment [1], the indicator includes allocation information indicating the type of RACH preamble, wherein the type of RACH preamble includes one of the RACH preamble types for TA acquisition operation and RACH preamble types for RACH-based LTM cell handover operation, and wherein: the RACH preamble type indicates to the fourth network entity that the first network entity is configured to perform one of the TA acquisition operation and the RACH-based LTM cell handover operation.

[0130] In embodiment [6], in the apparatus described in embodiment [1], the indicator includes non-assigned information related to the RACH preamble, and the type of the RACH preamble does not indicate the type of the RACH preamble used for TA acquisition operation and the type of the RACH preamble used for RACH-based LTM cell handover operation.

[0131] In embodiment [7], in the apparatus described in embodiment [1], the command is one of the following: a physical downlink control channel (PDCCH) command for performing a timing advance (TA) acquisition function, or a media access control (MAC) control element (CE) command for performing a normal RACH function for triggering a mobility (LTM) serving cell handover at layer 1 / layer 2.

[0132] In embodiment [8], in the apparatus described in embodiment [1], the first network entity is a user equipment, the second network entity is a serving base station distributed unit (serving gNB-DU), the third network entity is a serving base station central unit (gNB-CU), and the fourth network entity is a base station distributed unit among the target base station distributed unit (target gNB-DU) and the candidate base station distributed unit (candidate gNB-DU).

[0133] In embodiment [9], a method includes: receiving a configuration message at a first network entity from one of a second network entity and a third network entity to perform a RACH procedure with a fourth network entity to perform a network function, the configuration message including a random access channel (RACH) preamble; receiving a command at the first network entity from the second network entity to perform the network function; performing the RACH procedure at the first network entity by sending a RACH request message including a RACH preamble to the fourth network entity, wherein at least one of the RACH preamble format and the RACH request message includes an indicator, wherein the indicator indicates a network function; and performing the network function at the first network entity based on the received command.

[0134] In embodiment

[10] , in the method described in embodiment [9], the first network entity is configured to encode the value of an indicator based on the network function indicated in the configuration message.

[0135] In embodiment

[11] , in the method described in embodiment [9], the indicator indicates that the network function is a RACH process performed during the LTM serving cell handover function, wherein the serving cell handover function includes performing a cell handover associated with a first network entity from a second network entity to a fourth network entity.

[0136] In embodiment

[12] , in the method described in embodiment [9], the indicator indicates that the network function is a timing advance (TA) acquisition function, wherein the TA acquisition function includes receiving a TA at a first network entity to perform the network function, and wherein the TA is a corresponding TA associated with an LTM candidate cell of a fourth network entity.

[0137] In embodiment

[13] , in the method described in embodiment [9], the indicator includes allocation information indicating the type of RACH preamble, wherein the type of RACH preamble includes one of the RACH preamble types for TA acquisition operation and RACH preamble types for RACH-based LTM cell handover operation, and wherein: the RACH preamble type indicates to the fourth network entity that the first network entity is configured to perform one of the TA acquisition operation and the RACH-based LTM cell handover operation.

[0138] In embodiment

[14] , in the method described in embodiment

[13] , the indicator includes non-assigned information related to the RACH preamble.

[0139] In embodiment

[15] , in the method described in embodiment [9], the command is one of the following: a physical downlink control channel (PDCCH) command for performing a timing advance (TA) acquisition function, or a media access control (MAC) control element (CE) command for performing a normal RACH function for triggering a mobility (LTM) serving cell handover at layer 1 / layer 2.

[0140] In embodiment

[16] , in the apparatus described in embodiment [9], the first network entity is a user equipment, the second network entity is a serving base station distributed unit (serving gNB-DU), the third network entity is a serving base station central unit (gNB-CU), and the fourth network entity is a base station distributed unit among the target base station distributed unit (target gNB-DU) and the candidate base station distributed unit (candidate gNB-DU).

[0141] In embodiment

[17] , an apparatus is configured to: receive an LTM candidate cell configuration preparation request message from a third network entity at a first network entity; send an LTM candidate cell configuration from the first network entity to at least one of a second network entity and a fourth network entity, the LTM candidate cell configuration including a separate dedicated RACH preamble allocated for each network function, so that a random access procedure can be performed by the second network entity and the first network entity based on the dedicated RACH preamble allocated corresponding to the network function; at the first network entity, determine a network function to be performed by the second network entity based on the dedicated RACH preamble; and send a response from the first network entity to at least one of the second network entity and the fourth network entity for performing the determined network function.

[0142] In embodiment

[18] , in the apparatus described in embodiment

[17] , a dedicated RACH preamble indicates one of the RACH preambles used for TA acquisition operations and for RACH-based LTM cell handover operations.

[0143] In embodiment

[19] , in the apparatus described in embodiment

[17] , the network function is one of the functions of LTM serving cell handover function and timed advance (TA) acquisition function.

[0144] In embodiment

[20] , in the apparatus described in embodiment

[17] , the first network entity is a base station distributed unit among the target base station distributed unit and the candidate base station distributed unit, the second network entity is a user equipment, the fourth network entity is a serving base station distributed unit, and the third network entity is a serving base station central unit.

[0145] In embodiment

[21] , a non-transient computer-readable medium is disclosed having program instructions stored thereon, which are executed by means for wireless communication at UE 202. The program instructions may include: receiving a configuration message at a first network entity from one of a second and a third network entity to perform a RACH procedure with a fourth network entity to perform a network function, the configuration message including a random access channel (RACH) preamble; receiving a command at the first network entity from the second network entity to perform the network function; performing the RACH procedure at the first network entity by sending a RACH request message including a RACH preamble to the fourth network entity, wherein at least one of the RACH preamble format and the RACH request message includes an indicator indicating a network function; and performing the network function at the first network entity based on the received command.

[0146] In embodiment

[22] , a non-transient computer-readable medium is disclosed, on which program instructions are stored, which are executed by means of means for wireless communication at candidate / target base stations 206A, 206B. The program instructions may include: receiving an LTM candidate cell configuration preparation request message from a third network entity at a first network entity; sending an LTM candidate cell configuration from the first network entity to at least one of a second network entity and a fourth network entity, the LTM candidate cell configuration including a separate dedicated RACH preamble allocated for each network function, so that a random access procedure is performed by the second network entity and the first network entity based on the dedicated RACH preamble allocated corresponding to the network function; determining, at the first network entity, a network function to be performed by the second network entity based on the dedicated RACH preamble; and sending a response from the first network entity to at least one of the second network entity and the fourth network entity for performing the determined network function.

[0147] In non-limiting embodiments of this disclosure, embodiments consistent with this disclosure may be implemented using one or more non-transient computer-readable media. A computer-readable medium refers to any type of physical memory (such as memory 610) on which information or data readable by a processor may be stored. Thus, a computer-readable medium may store one or more instructions for execution by at least one processor 608, including instructions for causing at least one processor 608 to perform steps or phases consistent with the embodiments described herein. The term "computer-readable medium" should be understood to include tangible items and exclude carrier waves and transient signals. By way of example and not limitation, such a computer-readable medium may include random access memory (RAM), read-only memory (ROM), volatile memory, non-volatile memory, hard disk drive, optical disc (CD) ROM, digital video disc (DVD), flash drive, magnetic disk, and any other known physical storage medium.

[0148] Therefore, certain aspects may include a computer program product for performing the operations presented herein. For example, such a computer program product may include a computer-readable medium having instructions stored thereon (and / or encoded thereon, which can be executed by one or more processors to perform the operations described herein. In some aspects, the computer program product may include packaging material.

[0149] The various illustrative logic blocks, modules, and operations described in connection with this disclosure may be implemented or performed using a general-purpose processor, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may include a microprocessor, but alternatively, a processor may include any commercially available processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, such as multiple microprocessors or any other such configuration.

[0150] The foregoing description of specific embodiments will fully reveal the general nature of the embodiments, enabling others to readily modify or adapt such specific embodiments for various applications without departing from the general concept by applying present knowledge, and therefore, such adaptations and modifications should and are intended to be understood as being within the meaning and scope of equivalents of the disclosed embodiments. It should be understood that the wording or terminology used herein is for descriptive purposes and not for limitation. Therefore, although embodiments herein have been described according to preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modifications within the scope of the embodiments described herein.

Claims

1. An apparatus configured as follows: At the first network entity, a configuration message is received from one of the second and third network entities to perform a RACH procedure with a fourth network entity to perform network functions. The configuration message includes a random access channel (RACH) preamble. Receive commands from the second network entity at the first network entity to perform the network functions; At the first network entity, the RACH process is performed by sending a RACH request message including the RACH preamble to the fourth network entity, wherein at least one of the RACH preamble format and the RACH request message includes an indicator, wherein the indicator indicates the network function. as well as At the first network entity, the network function is executed based on the received command.

2. The apparatus of claim 1, wherein the first network entity is configured to encode the value of the indicator based on the network function indicated in the configuration message.

3. The apparatus of claim 1, wherein the indicator indicates that the network function is a RACH process performed during a Layer 1 / Layer 2 triggered mobility (LTM) serving cell handover function, wherein the LTM serving cell handover function includes performing a cell handover associated with the first network entity from the second network entity to the fourth network entity.

4. The apparatus of claim 1, wherein the indicator indicates that the network function is a timing advance (TA) acquisition function, wherein the TA acquisition function includes receiving a TA at the first network entity to perform the network function, and wherein the TA is a corresponding TA associated with an LTM candidate cell of the fourth network entity.

5. The apparatus of claim 1, wherein the indicator includes allocation information indicating the type of RACH preamble, wherein the type of RACH preamble includes one of a RACH preamble type for TA acquisition operations and a RACH preamble type for RACH-based LTM cell handover operations, and wherein: The RACH preamble type indicates to the fourth network entity that the first network entity is configured to perform one of the TA acquisition operation and the RACH-based LTM cell handover operation.

6. The apparatus of claim 1, wherein the indicator includes non-assigned information relating to the RACH preamble, and the type of the RACH preamble does not indicate the type of RACH preamble for TA acquisition operation and the type of RACH preamble for RACH-based LTM cell handover operation.

7. The apparatus of claim 1, wherein the command is one of the following: a physical downlink control channel (PDCCH) command for performing the advance timing (TA) acquisition function, or a media access control (MAC) control element (CE) command for performing normal RACH function for triggering mobility (LTM) serving cell handover at layer 1 / layer 2.

8. The apparatus of claim 1, wherein the first network entity is a user equipment, the second network entity is a serving base station distributed unit, the third network entity is a serving base station central unit, and the fourth network entity is a base station distributed unit among a target base station distributed unit and a candidate base station distributed unit.

9. A method comprising: At the first network entity, a configuration message is received from one of the second and third network entities to perform a RACH procedure with a fourth network entity to perform network functions. The configuration message includes a random access channel (RACH) preamble. Receive commands from the second network entity at the first network entity to perform the network functions; At the first network entity, the RACH process is performed by sending a RACH request message including the RACH preamble to the fourth network entity, wherein at least one of the RACH preamble format and the RACH request message includes an indicator, wherein the indicator indicates the network function. as well as At the first network entity, the network function is executed based on the received command.

10. The method of claim 9, wherein the first network entity is configured to encode the value of the indicator based on the network function indicated in the configuration message.

11. The method of claim 9, wherein the indicator indicates that the network function is a RACH procedure performed during an LTM serving cell handover function, wherein the serving cell handover function includes performing a cell handover associated with the first network entity from the second network entity to the fourth network entity.

12. The method of claim 9, wherein the indicator indicates that the network function is a timing advance (TA) acquisition function, wherein the TA acquisition function includes receiving a TA at the first network entity to perform the network function, and wherein the TA is a corresponding TA associated with an LTM candidate cell of the fourth network entity.

13. The method of claim 9, wherein the indicator includes allocation information indicating the type of the RACH preamble, wherein the type of the RACH preamble includes one of a RACH preamble type for TA acquisition operations and a RACH preamble type for RACH-based LTM cell handover operations, and wherein: The RACH preamble type indicates to the fourth network entity that the first network entity is configured to perform one of the TA acquisition operation and the RACH-based LTM cell handover operation.

14. The method of claim 13, wherein the indicator includes non-assigned information relating to the RACH preamble.

15. The method of claim 9, wherein the command is one of the following: a physical downlink control channel (PDCCH) command for performing the advance timing (TA) acquisition function, or a media access control (MAC) control element (CE) command for performing normal RACH function for triggering mobility (LTM) serving cell handover at layer 1 / layer 2.

16. The method of claim 9, wherein the first network entity is a user equipment, the second network entity is a serving base station distributed unit, the third network entity is a serving base station central unit, and the fourth network entity is a base station distributed unit among a target base station distributed unit and a candidate base station distributed unit.

17. An apparatus configured as follows: Receive the LTM candidate cell configuration preparation request message from the third network entity at the first network entity; The first network entity sends an LTM candidate cell configuration, including a separate dedicated RACH preamble assigned for each network function, to at least one of the second and fourth network entities, so that the second network entity and the first network entity can perform a random access procedure based on the dedicated RACH preamble assigned corresponding to the network function. At the first network entity, the network function to be performed by the second network entity is determined based on the dedicated RACH preamble; as well as The first network entity sends a response to at least one of the second and fourth network entities to perform the determined network function.

18. The apparatus of claim 17, wherein the dedicated RACH preamble indicates one of the RACH preamble for TA acquisition operation and the RACH preamble for RACH-based LTM cell handover operation.

19. The apparatus of claim 17, wherein the network function is one of the LTM serving cell handover function and the timing advance (TA) acquisition function.

20. The apparatus of claim 17, wherein the first network entity is a base station distributed unit among a target base station distributed unit and a candidate base station distributed unit, the second network entity is a user equipment, the third network entity is a serving base station central unit, and the fourth network entity is a serving base station distributed unit.