Connection mode mobility enhancements for hierarchical radio resource management

Abstract

Various solutions for layered radio resource management (RRM) for enhanced mobility in connection modes are described. The device can perform a first measurement based on a first downlink (DL) reference signal (RS) received from each of the source and target network nodes. This first DL RS includes identification information for a single-frequency network (SFN) area, but not identification information for any network node. Furthermore, the device can perform a second measurement based on a second DL RS received from each of the source and target network nodes. This second DL RS includes identification information for either the source or target network node. The device can then send a handover request containing target network node information to the source network node based on the first and second measurements, and receive a handover command from the source network node.

Description

[0001] Cross-references

[0002] This disclosure is part of a non-provisional application claiming priority to U.S. Patent Application No. 63 / 573,559 (filed April 3, 2024), the contents of which are incorporated herein by reference in their entirety. Technical Field

[0003] This disclosure generally relates to mobile communications, and more specifically, to connectivity mode mobility enhancement under layered radio resource management (RRM) for user equipment (UE) and network nodes in mobile communications. Background Technology

[0004] Unless otherwise stated, the methods described in this section are not prior art as claimed in the following claims, and are not considered prior art because they are included in this section.

[0005] In current network implementations, a base station (BS) can operate to provide radio coverage for a specific geographic area using one or more cells, thus forming a radio access network. The base station supports the operation of the cell, and each cell can operate to provide service to at least one user equipment (UE) within its radio coverage area. To reduce inter-cell interference, 5G New Radio (NR) supports a multiple transmission reception point (TRP) architecture, enabling joint scheduling and transmission / reception by allowing dynamic coordination among multiple TRPs. Therefore, when a UE is, for example, at the cell edge, it can be served by multiple TRPs to improve its signal transmission and reception, which helps increase throughput.

[0006] However, the current 5G NR radio resource management (RRM) and mobility management framework has some problems. For example, the current synchronization signal block (SSB) design is node- and beam-aware, where each TRP sends its corresponding SSB in a beam-scanning manner, and the UE needs to perform beam scanning to monitor the SSB from each TRP. This SSB design not only leads to increased power consumption for both the UE and the network (NW) (e.g., due to beamforming operations), but also results in low radio resource utilization efficiency (e.g., different SSBs are mostly identical except for the physical broadcast channel (PBCH) portion). Furthermore, this SSB design may lead to more frequent cell handovers for connected-mode UEs in dense network deployments, and the RRM latency of connected-mode UEs in dense network deployments may cause slow cell handovers, further reducing throughput at the cell edge.

[0007] Therefore, improving the framework of RRM and mobility management has become an important issue for modern wireless communication systems. Consequently, it is necessary to provide appropriate solutions to address these problems. Summary of the Invention

[0008] The following abstract is for illustrative purposes only and is not intended to be limiting in any way. That is, the following abstract aims to introduce the concepts, key points, benefits, and advantages of the novel and non-obvious techniques described herein. Some embodiments will be further elaborated in the detailed description below. Therefore, the following abstract is not intended to identify the essential features of the claimed subject matter, nor is it intended to define the scope of the claimed subject matter.

[0009] One objective of this disclosure is to provide schemes, concepts, designs, systems, methods, and apparatus related to layered RRM for connectivity mode mobility management in mobile communications. It is believed that by implementing one or more of the schemes described herein, the aforementioned problems can be avoided or mitigated.

[0010] In one aspect, a method may involve an apparatus (e.g., a connected-mode UE) performing a first measurement based on a first DL RS received from each of a source network node and a target network node, wherein the first DL RS includes identification information of an SFN area but does not include identification information of any network node. The method may also involve the apparatus performing a second measurement based on a second DL RS received from each of the source network node and the target network node, wherein the second DL RS includes identification information of either the source network node or the target network node. The method may further involve the apparatus sending a handover request to the source network node based on the first measurement and the second measurement, wherein the handover request includes information about the target network node. The method may also involve the apparatus receiving a handover command from the source network node, wherein the handover command instructs the apparatus to hand over from the source network node to the target network node.

[0011] In one aspect, a method may involve a source network node (e.g., a TRP or RU) sending a first DL RS to a device, wherein the first DL RS includes identification information of an SFN area but does not include identification information of any network node. The method may also involve the source network node sending a second DL RS to the device, wherein the second DL RS includes identification information of the source network node. The method may further involve the source network node receiving a handover request from the device, wherein the handover request includes information of a target network node. The method may also involve the source network node sending a handover command to the device, wherein the handover command instructs the device to hand over from the source network node to the target network node.

[0012] In one aspect, a method may involve a target network node (e.g., a TRP or RU) sending a first DLRS to a device, wherein the first DLRS includes identification information of an SFN area but does not include identification information of any network node. The method may also involve the target network node sending a second DLRS to the device, wherein the second DLRS includes identification information of the target network node. The method may further involve the target network node receiving a mobility request for the device from a source network node and sending a mobility acknowledgment to the source network node. The method may also involve the target network node receiving a completion message from the device, wherein the completion message indicates that the device has switched from the source network node to the target network node.

[0013] It is worth noting that although the content described herein may be presented in the context of certain wireless access technologies, networks, and network topologies, such as Long-Term Evolution (LTE), LTE-Advanced, LTE-Advanced Pro, 5G, NR, Internet of Things (IoT), Narrow Band Internet of Things (NB-IoT), Industrial Internet of Things (IIoT), Beyond 5G (B5G), and 6G, the proposed concepts, schemes, and any variations / derivatives thereof can be implemented, used, and implemented by other types of wireless access technologies, networks, and network topologies. Therefore, the scope of this disclosure is not limited to the examples described herein. Attached Figure Description

[0014] The accompanying drawings are included in this specification to further understand this disclosure and form part of this disclosure. The drawings illustrate embodiments of this disclosure and, together with the specification, serve to explain the principles of this disclosure. It will be understood that the drawings are not necessarily drawn to scale, as some components may be shown out of proportion to actual dimensions for clarity of the concepts of this disclosure.

[0015] Figure 1 This is a schematic diagram illustrating an example scenario of the existing RRM and mobility management framework in 5G NR.

[0016] Figure 2 This is a schematic diagram illustrating an example scenario of a layered RRM framework according to an embodiment of the present disclosure.

[0017] Figure 3 This is a schematic diagram illustrating an example scenario of connectivity mode mobility under a layered RRM framework according to an embodiment of the present disclosure.

[0018] Figure 4 This is a schematic diagram illustrating an example scenario of a movement process within an SFN according to an embodiment of the present disclosure.

[0019] Figure 5 This is a schematic diagram illustrating an example scenario of PRACH transmission characteristics according to an embodiment of the present disclosure.

[0020] Figure 6 This is a schematic diagram illustrating an example scenario of an inter-SFN movement process according to an embodiment of the present disclosure.

[0021] Figure 7This is a schematic diagram illustrating an example scenario of another SFN movement process according to an embodiment of the present disclosure.

[0022] Figure 8 This is a block diagram illustrating an example communication system according to an embodiment of the present disclosure.

[0023] Figure 9 A flowchart illustrating an example process according to an embodiment of this disclosure.

[0024] Figure 10 This is a flowchart illustrating another example process according to an embodiment of the present disclosure.

[0025] Figure 11 This is a flowchart illustrating yet another example process according to an embodiment of the present disclosure. Detailed Implementation

[0026] Detailed embodiments and implementations of the subject matter of the claims are disclosed herein. However, it should be understood that the disclosed embodiments and implementations are merely illustrative of the subject matter of the claims and may be implemented in various forms. This disclosure may take many different forms and should not be construed as limited to the exemplary embodiments and implementations listed herein. Rather, these exemplary embodiments and implementations are provided to make the description of this disclosure exhaustive and complete, and to fully communicate the scope of this disclosure to those skilled in the art. In the following description, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations.

[0027] Overview

[0028] According to embodiments of this disclosure, various technologies, methods, schemes, and / or solutions relate to hierarchical radio resource management (RRM) related to mobility management in connection modes in mobile communications. According to this disclosure, multiple possible solutions can be implemented individually or in combination. That is, although these possible solutions are described separately below, two or more solutions can be implemented in some combination.

[0029] In 5G NR, the current RRM and mobility management framework is based on a node- and beam-aware synchronization signal block (SSB) design. Figure 1 Example scenario 100 of the current RRM and mobility management framework in 5G NR is shown. Figure 1Part (A) describes multiple transmission reception points (TRPs) 121-127 within cell 120, where each TRP 121-127 transmits a corresponding SSB (denoted as SSB 1 to SSB 7) in a beam scan manner. Figure 1 Part (B) describes the time and frequency resource allocation for SSB transmissions of all TRPs within cell 120, where SSBs of different TRPs are transmitted in different time domain resources within the SSB period. Figure 1 Part (C) describes the SSB structure, which includes a primary synchronization signal (PSS) and a secondary synchronization signal (SSS) for synchronization purposes, and a PBCH containing a demodulation reference signal (DMRS) and data. For example, the PSS and / or SSS may carry the cell identifier (ID) of cell 120, and the PBCH may carry master information block (MIB) information and an SSB index. For a UE (not shown) within the cell coverage area, it can detect the following information from the SSB: (i) the cell ID for identifying cell 120, (ii) the SSB index for identifying the TRP, (iii) the PBCH content other than the SSB index information, which has been repeatedly transmitted and cannot be omitted due to the beam scanning architecture in frequency range 2 (FR2), and (iv) the L1 / L3 measurement reference signal (RS) as part of the SSB combination. However, as mentioned earlier, this SSB design not only leads to increased power consumption for both the UE and the network (NW) (e.g., due to beamforming operations), but also results in low radio resource utilization efficiency (e.g., different SSBs are mostly identical except for the PBCH portion). Furthermore, in dense network deployments, this SSB design may lead to more frequent cell handovers for connected-mode UEs, and the RRM latency of connected-mode UEs may cause slow cell handovers, further reducing throughput at the cell edge.

[0030] In view of the above, this disclosure proposes several schemes for connectivity mode mobility enhancement related to hierarchical RRM, aiming to solve the above problems. According to the scheme of this disclosure, a hierarchical RRM framework is provided, having a first-layer downlink (DL) RS (or cell-specific DL RS) and a second-layer DL RS (or TRP-specific DL RS), wherein the second-layer DL RS and the first-layer DL RS are time-division multiplexed (TDM) to achieve parallelization of cell-level and TRP-level measurements. Furthermore, within the hierarchical RRM framework, connectivity-mode mobility enhancements are provided to support the following: (i) fast single-frequency network (SFN) / intra-cell mobility and SFN / inter-cell mobility based on cell-level and TRP-level measurements; (ii) UE determining advance synchronization with the TRP; (iii) the UE sending (cell and) TRP handover requests to multiple TRPs based on the time reference of the anchor TRP (or source TRP); and (iv) to obtain timing advance (TA), the UE sending a physical random access channel (PRACH) signal to the target TRP based on the time reference of the target TRP. Thus, by applying the scheme disclosed herein, the overall system performance of UE and network operations in connectivity mode (e.g., RRC_CONNECTED mode) can be improved.

[0031] Figure 2 Example scenario 200 of a layered RRM framework according to an embodiment of this disclosure is shown. Figure 2 Part (A) describes a communication environment involving wireless communication between UE 210 and one or more TRPs (or radio units (RUs)) 221-227 within an SFN area (e.g., a cell) 220. All TRPs 221-227 transmit the same Layer 1 DL RS (i.e., SFN SSB), without beamforming or using beamforming transparent to the UE. Specifically, the SFN SSB contains identification information for the SFN area 220, but not identification information for any TRP. That is, the SFN SSB can be used for cell identification (e.g., for cell reselection), but not for TRP identification within the cell coverage area. In addition to the SFN SSB, each TRP 221-227 also transmits a corresponding Layer 2 DL RS, i.e., a TRP RS. Specifically, the TRP RS contains identification information for the corresponding TRP (e.g., a TRP ID). That is, this TRP-specific signal can be used for TRP identification (e.g., for TRP selection), but not for TRP identification between different SFN areas. Figure 2Part (B) describes the time and frequency resource allocation for SFN SSB and TRP RS transmissions of all TRPs within SFN area 220, where SFN SSB and TRP RS are transmitted in different time domain resources (e.g., TRP RS is transmitted after SFN SSB) to avoid resource contention between L1 and L3 measurements. UE 210 can perform (and report) L3 measurements based on SFN SSB for coarse time-frequency tracking and L1 measurements based on TRP RS for fine time-frequency tracking. Therefore, SFN control nodes (e.g., distributed units (DUs) or base stations (BSs)) and / or UE 210 can perform idle-mode mobility management based on SFN SSB and connected-mode mobility management (e.g., SFN / intra-cell mobility and SFN / inter-cell mobility) based on TRPRS.

[0032] In some implementations, the SFN SSB may occupy a narrower bandwidth. For example, similar to the concepts of synchronization signals and PBCH in a 5G NR system, the SFN SSB may include synchronization signals (or DU-dedicated RS) (e.g., both synchronization signals PSS and SSS, or only one of PSS and SSS) and PBCH.

[0033] In some implementations, the SFN SSB can be sent periodically. For example, the SFN SSB can be sent periodically or semi-periodically.

[0034] In some implementations, the TRP RS can occupy narrowband or wideband. For example, similar to the synchronization signal concept in a 5G NR system, the TRP RS can contain a synchronization signal (e.g., SSS). The TRP RS can serve as a multi-port RS for spatial domain parameter estimation / acquisition. The TRP RS can be configured via broadcast information (or system information) in the form of a channel state information-reference signal (CSI-RS), thereby making the TRP RS's mode, resource element occupancy, and bandwidth more flexible. Furthermore, or optionally, the TRP RS can be associated with multiple timings for each TRP, each timing corresponding to different spatial domain attributes.

[0035] Compared to traditional beam-scanning SSB, Figure 2The SFN SSB in the signal is transmitted in a non-beam-scanning manner, which may have several advantages, including better spectral efficiency (e.g., lower code rate due to SFN diversity gain and multiple redundant versions (RV) of the PBCH), network energy savings through reduced transmission (Tx) time or a reduced number of active TRPs, and simplified UE back-end mode complexity (e.g., reduced reception (Rx) time due to early termination of repeated receptions and higher spectral efficiency). As for the TRP RS, there may be some design features to achieve fast TRP / beam tracking, including (i) its discoverability (e.g., the TRP RS consists of a low cross-correlation sequence), (ii) multiple TDM ports (or beams) for the mixed beamforming analog portion (e.g., frequency-division multiplexed (FDM) for an all-digital architecture), and (iii) its suitability for compressed sensing.

[0036] Figure 3 An example scenario 300 of connectivity mode mobility under a hierarchical RRM framework according to an embodiment of this disclosure is illustrated. Scenario 300 describes two connectivity mode mobility modes under the proposed hierarchical RRM framework, including SFN / inter-cell mobility and SFN / intra-cell mobility. Figure 3 As shown, UE 1 experienced SFN / cell inter-mobility from SFN area 1 (e.g., cell 1) to SFN area 2 (e.g., cell 2), more specifically, from TRP 2 in SFN area 1 to TRP 3 in SFN area 2. Furthermore, UE 2 experienced SFN / intra-cell mobility within SFN area 1 (i.e., from TRP 6 in SFN area 1 to TRP 2 in SFN area 1), while UE 3 experienced SFN / intra-cell mobility within SFN area 2 (i.e., from TRP 7 in SFN area 2 to TRP 1 in SFN area 2).

[0037] Figure 4An example scenario 400 of an in-SFN mobility procedure according to an embodiment of this disclosure is illustrated. First, the UE connects to one or more TRPs, including a source TRP, to operate in connected mode. In step 401, the UE receives the same SFN SSB from multiple TRPs (including the source TRP and the target TRP) within the same SFN area. The UE can perform L3 measurements based on the SFN SSB for cell search (CS) or connection management (CM). In step 402, the UE receives different TRP RSs from multiple TRPs (including the source TRP and the target TRP) within the same SFN area. The UE can perform L3 and L1 measurements based on the SFN SSB and / or the TRP RS for TRP selection / update. In step 403, the UE receives a UE-specific Radio Resource Control (RRC) configuration (e.g., a UE-specific RACH configuration). In one example, the UE can select a target TRP with better signal quality than the source TRP based on measurement results (e.g., signal quality indicators of the source TRP and target TRP, such as reference signal received power (RSRP), reference signal received quality (RSRQ), received signal strength indicator (RSSI), signal-to-noise ratio (SNR), or RF characteristics), and perform advance synchronization with the selected target TRP according to the UE's dedicated RRC configuration.

[0038] Subsequently, in step 404, the UE triggers the transmission of a TRP handover request based on the measurement results. The TRP handover request can be transmitted on the physical uplink shared channel (PUSCH), where PUSCH resources can be authorized through a scheduling request (SR) procedure or through (group) configuration. In one example, the TRP handover request can be transmitted in a random access preamble (e.g., MsgA of a 2-step RACH), based on the reference time of the source TRP (e.g., assuming the source TRP and target TRP are synchronized at the cyclic prefix (CP) level). In another example, PUSCH resources can be shared by the source TRP and the target TRP, allowing the preamble transmission (i.e., the TRP handover request transmission) to be received simultaneously by both the source and target TRPs. More specifically, the TRP handover request can include a TRP selection result, such as information about the target TRP selected by the UE. The TRP selection result may include information about the list of TRPs that the UE has pre-synchronized (e.g., TRP IDs and corresponding signal quality indicators), and optionally the reception time difference (or round-trip delay; RTD) between the source TRP and the target TRP. Additionally, or optionally, the TRP handover request may include the UE ID (e.g., a cell-radio network temporary identifier (C-RNTI) used for contention-based random access (CBRA) procedures).

[0039] Next, in step 405, the source TRP sends a mobility request for the UE to the target TRP, for example, to notify the UE of a request to hand over from the source TRP to the target TRP. In step 406, the target TRP sends a mobility confirmation to the source TRP. In step 407, the source TRP sends a TRP handover command to the UE. In one example, the TRP handover command may be sent in a random access response (e.g., MsgB of a 2-step RACH). The TRP handover command may include DL and / or uplink (UL) resources associated with the target TRP and optionally include the TA value of the target TRP. In one example, if UE-based TA acquisition is used (i.e., the UE can calculate the TA value of the target TRP itself), the TA value of the target TRP is not provided in the TRP handover command. In another example, if NW-based TA acquisition is used (i.e., the source TRP and the target TRP can cooperate to derive the TA value of the target TRP based on the RTD reported by the UE), the network-derived TA value of the target TRP is provided in the TRP handover command. After receiving the TRP handover command, the UE can apply the target TRP's settings (e.g., downlink / uplink resources and TA value) to achieve the handover from the source TRP to the target TRP. In step 408, the UE sends an RRC completion message to the target TRP to complete the intra-SFN mobility procedure.

[0040] Figure 5 An example scenario 500 illustrating the PRACH transmission features according to an embodiment of this disclosure is shown. Figure 5 Part (A) describes a mobility scenario triggered by L1 / L2 in 5G NR, where time synchronization between the source TRP and the target TRP is poor. In this scenario, UL pre-synchronization to the target TRP is performed based on a dedicated PRACH, which is triggered by a physical downlink control channel (PDCCH) command sent by the NW. The time reference and path loss reference are both the target TRP. Figure 5 Section (B) describes an intra-SFN mobility procedure scenario in this disclosure, where time synchronization between the source TRP and candidate TRPs is good (e.g., clock errors between TRPs can be calibrated by the UE, and the UE can report the reception time difference between TRPs). In this scenario, uplink pre-synchronization to multiple candidate TRPs is based on a shared PRACH, with PRACH transmission triggered by the UE itself (e.g., under certain conditions), and both the time reference and path loss reference are the source TRP.

[0041] Figure 6An example scenario 600 of the inter-SFN mobility procedure according to an embodiment of this disclosure is illustrated. First, the UE connects to one or more TRPs, including a source TRP, to operate in connected mode. In step 601, the UE receives the same SFN SSB from multiple TRPs (including a source TRP and a target TRP) located in different SFN areas. The UE can perform L3 measurements based on the SFN SSB for CS / CM. In step 602, the UE receives different TRP RSs from multiple TRPs (including a source TRP and a target TRP) located in different SFN areas. The UE can perform L3 and L1 measurements based on the SFN SSB and / or TRP RS for TRP selection / update. In step 603, the UE receives a UE-specific RRC configuration containing candidate TRP configurations. In one example, the UE can select a target TRP with better signal quality than the source TRP based on the measurement results and perform pre-synchronization with the selected target TRP based on the UE-specific RRC configuration. Then, in step 604, the UE triggers the transmission of a cell-and-TRP handover request based on the measurement results. Detailed description of cell and TRP handover request and Figure 4 The TRP handover request in Scenario 400 is similar to that described above, except that the cell and TRP handover request includes the cell and TRP selection results (for example, the TRP list information may further include the cell ID of each selected TRP).

[0042] Next, in step 605, the source TRP sends a mobility request for the UE to the target TRP, for example, to notify the UE of a request to hand over from the source TRP to the target TRP. In step 606, the target TRP sends a mobility confirmation to the source TRP. In step 607, the source TRP sends a cell and TRP handover command to the UE. A detailed description of the cell and TRP handover command is provided below. Figure 4 The TRP handover command in scenario 400 is similar to the one described above, except that the cell and TRP handover command further includes a PRACH trigger indication, which instructs the UE to send a PRACH signal to the target TRP. In step 608, after receiving the cell and TRP handover command, the UE sends a PRACH signal to the target TRP. In step 609, the target TRP calculates the TA value between the UE and the target TRP based on the PRACH signal, and sets this TA value (denoted as TA) as... t The message is sent to the UE. In step 610, the UE sends an RRC completion message to the target TRP to complete the inter-SFN mobility procedure.

[0043] Figure 7An example scenario 700 of the inter-SFN mobility procedure according to an embodiment of this disclosure is illustrated. Scenario 700 is similar to scenario 600, except that the PRACH transmission is triggered before the cell and TRP handover commands. Specifically, steps 701-706 are similar to steps 601-606 in scenario 600, and then in step 707, after receiving the mobility acknowledgment from the target TRP, the source TRP sends a PRACH trigger indication to the UE (e.g., a PDCCH command, a medium access control (MAC) control element (CE), or RRC-based signaling). In step 708, after receiving the PRACH trigger indication, the UE sends a PRACH signal to the target TRP. In step 709, the target TRP calculates the TA value between the UE and the target TRP based on the PRACH signal and assigns this TA value (denoted as TA). t The source TRP sends a cell and TRP handover command (excluding PRACH trigger indication) to the UE. After receiving the cell and TRP handover command, the UE can apply the settings of the target cell and the target TRP (e.g., downlink / uplink resources and TA value) to complete the handover from the source TRP to the target TRP. In step 711, the UE sends an RRC completion message to the target TRP to complete the inter-SFN mobility procedure.

[0044] Exemplary Implementation

[0045] Figure 8 An example communication system 800 is shown, comprising an example communication device 810 and an example network device 820, according to embodiments of this disclosure. Both the communication device 810 and the network device 820 can perform various functions to implement the schemes, techniques, processes, and methods related to hierarchical RRM and connectivity mode mobility management described herein, including the scenarios / schemes described above and the processes 900, 1000, and 1100 described below.

[0046] The communication device 810 may be part of an electronic device, which may be a UE (User Equipment), such as a portable or mobile device, a wearable device, a wireless communication device, or a computing device. For example, the communication device 810 may be implemented in a smartphone, smartwatch, personal digital assistant, electronic control unit (ECU) in a vehicle, digital camera, or computing device such as a tablet, laptop, or mobile phone. The communication device 810 may also be part of a machine-type device, such as a ReCap UE, IoT, NB-IoT, eMTC, or IIoT UE, such as a non-movable or fixed device, a home device, a roadside unit (RSU), a wired communication device, or a computing device. For example, the communication device 810 may be implemented in a smart thermostat, a smart refrigerator, a smart door lock, a wireless speaker, or a home control center. Alternatively, the communication device 810 may be implemented as one or more integrated circuit (IC) chips, such as, but not limited to, one or more single-core processors, one or more multi-core processors, one or more reduced-instruction-set-computing (RISC) processors, or one or more complex-instruction-set-computing (CISC) processors. The communication device 810 may include... Figure 8 The communication device 810 may include at least some of the components shown, such as processor 812. It may also include one or more other components unrelated to this disclosure (e.g., internal power supply, display device, and / or user interface device), and therefore, these components of the communication device 810 are not included in... Figure 8 This is shown in the text and not described below, in order to simplify and refine the content.

[0047] Network device 820 may be part of an electronic device, which may be a network node, such as a TRP, RU, small cell, router, or gateway for a wireless network. For example, network device 820 may be implemented in a TRP / RU in a 4G / 5G / 6G, IoT, NB-IoT, or IIoT network. Alternatively, network device 820 may be implemented as one or more IC chips, such as, but not limited to, one or more single-core processors, one or more multi-core processors, one or more RISC or CISC processors. Network device 820 may include... Figure 8 The network device 820 may include at least some of the components shown, such as processor 822. It may also include one or more other components unrelated to this disclosure (e.g., internal power supply, display device, and / or user interface device), and therefore, these components of the network device 820 are not included in... Figure 8 This is shown in the text and not described below, in order to simplify and refine the content.

[0048] In one aspect, both processor 812 and processor 822 may be implemented as one or more single-core processors, one or more multi-core processors, or one or more CISC processors. That is, although the singular term "processor" is used herein to refer to processor 812 and processor 822, according to embodiments of this disclosure, processor 812 and processor 822 may include multiple processors in some embodiments and a single processor in other embodiments. In another aspect, both processor 812 and processor 822 may be implemented in hardware (and optionally firmware) and include, for example, but not limited to, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors, and / or one or more varactor diodes, these electronic components being configured and arranged to achieve a specific purpose according to the requirements of this disclosure. In other words, in at least some embodiments, processor 812 and processor 822 are dedicated machines specifically designed, arranged, and configured to perform specific tasks in devices (e.g., represented by communication device 810) and network nodes (e.g., represented by network device 820), including connectivity mode mobility enhancement for hierarchical RRM, according to various embodiments of this disclosure.

[0049] In some embodiments, the communication device 810 may further include a transceiver 816 connected to the processor 812, capable of wirelessly transmitting and receiving data. In some embodiments, the transceiver 816 is capable of wireless communication with different types of UEs and / or different radio access technologies (RATs) such as 4G / 5G / B5G / 6G. In some embodiments, the transceiver 816 may be equipped with multiple antenna ports (not shown), for example, four antenna ports. That is, the transceiver 816 may be equipped with multiple transmit antennas and multiple receive antennas for beamforming and multiple-input multiple-output (MIMO) wireless communication. In some embodiments, the network device 820 may further include a transceiver 826 connected to the processor 822. The transceiver 826 may include a transceiver capable of wirelessly transmitting and receiving data. In some embodiments, the transceiver 826 is capable of wireless communication with different types of UEs using different RATs. In some embodiments, the transceiver 826 may be equipped with multiple antenna ports (not shown), for example, four antenna ports. In other words, transceiver 826 can be equipped with multiple transmit antennas and multiple receive antennas for beamforming and MIMO wireless communication.

[0050] In some embodiments, the communication device 810 may further include a memory 814 connected to the processor 812, which can access and store data therein. In some embodiments, the network device 820 may further include a memory 824 connected to the processor 822, which can access and store data therein. Both memory 814 and memory 824 may include a random-access memory (RAM), such as dynamic RAM (DRAM), static RAM (SRAM), thyristor RAM (T-RAM), and / or zero-capacitor RAM (Z-RAM). Alternatively, or additionally, both memory 814 and memory 824 may include a read-only memory (ROM), such as a mask ROM, a programmable ROM (PROM), an erasable programmable ROM (EPROM), and / or an electrically erasable programmable ROM (EEPROM). Alternatively, or additionally, both memory 814 and memory 824 may include a non-volatile random-access memory (NVRAM), such as flash memory, solid-state memory, ferroelectric RAM (FeRAM), magnetoresistive RAM (MRAM), and / or phase-change memory.

[0051] Both communication device 810 and network device 820 can be communication entities capable of communicating with each other according to various proposed schemes of this disclosure. For illustrative purposes and without limitation, the following describes the capabilities of communication device 810 as a UE and network device 820 as a source network node or target network node (e.g., TRP or RU) in conjunction with procedures 900, 1000 and 1100.

[0052] Explanatory process

[0053] Figure 9An example flow 900 according to an embodiment of this disclosure is illustrated. Flow 900 may be (whether partially or entirely) an example implementation of the above-described scenario / solution for mobility enhancement in a connection mode with hierarchical RRM. Flow 900 may represent one aspect of the functionality of communication device 810. Flow 900 may include one or more operations, actions, or functions, as shown in flow blocks 910 to 940. Although shown as independent flow blocks, the flow blocks of flow 900 may be split into more flow blocks, merged into fewer flow blocks, or omitted depending on the desired implementation. Furthermore, the flow blocks of flow 900 may be arranged according to... Figure 9 The process can be executed in the order shown, or in a different order. Process 900 can be implemented by communication device 810 or any applicable user equipment or machine type device. For illustrative purposes only and without limitation, process 900 is described below with reference to communication device 810 (as the UE). Process 900 may begin with process block 910.

[0054] In process block 910, process 900 may involve the processor 812 of communication device 810 performing a first measurement via transceiver 816 based on a first DL RS received from each of the source network node and the target network node, wherein the first DL RS includes identification information of the SFN area but does not include identification information of any network node. Process 900 may proceed from process block 910 to process block 920.

[0055] In process block 920, process 900 may involve processor 812 performing a second measurement via transceiver 816 based on a second DL RS received from each of the source network node and the target network node, wherein the second DL RS includes identification information of the source network node or the target network node. Process 900 may proceed from process block 920 to process block 930.

[0056] In process block 930, process 900 may involve processor 812 sending a handover request to the source network node via transceiver 816 based on a first measurement and a second measurement, wherein the handover request includes information about the target network node. Process 900 can proceed from process block 930 to process block 940.

[0057] In process block 940, process 900 may involve processor 812 receiving a switching command from a source network node via transceiver 816, wherein the switching command instructs communication device 810 to switch from the source network node to the target network node.

[0058] In some implementations, the handover request may be sent based on the reference time of the source network node.

[0059] In some implementations, the switching request can also be sent to the target network node via a UL resource shared by both the source and target network nodes.

[0060] In some implementations, process 900 may also involve processor 812 synchronizing with the target network node in advance via transceiver 816 before the switch request is sent.

[0061] In some implementations, the handover request can be sent using PUSCH resources authorized via the SR procedure or PUSCH resources configured via RRC signaling.

[0062] In some implementations, the handover request may be sent in a random access preamble, and the handover command may be received in a random access response.

[0063] In some implementations, the information of the target network node may include at least one of the following: (i) the ID of the target network node; (ii) the signal quality indicator of the target network node; (iii) the reception time difference between the source network node and the target network node; and (iv) the ID of the communication device 810.

[0064] In some implementations, the switching command may include at least one of the following: (i) a TA value associated with the target network node; (ii) a PRACH trigger indication for instructing the communication device 810 to send a PRACH signal to the target network node; and (iii) at least one of a DL resource and a UL resource associated with the target network node.

[0065] In some implementations, process 900 may also involve processor 812, via transceiver 816, sending a PRACH signal to a target network node in response to a handover command or PRACH trigger indication received from a source network node, wherein the PRACH signal is sent based on the target network node's reference time. Furthermore, process 900 may also involve processor 812, via transceiver 816, receiving a TA value associated with the target network node, wherein the TA value is received from the target network node or received in a handover command.

[0066] In some implementations, process 900 may also involve processor 812 switching from a source network node to a target network node in response to a switching command via transceiver 816, and sending a completion message to the target network node via transceiver 816, wherein the completion message indicates that communication device 810 has switched from the source network node to the target network node.

[0067] Figure 10An example flow 1000 according to an embodiment of this disclosure is illustrated. Flow 1000 may be (whether partially or entirely) an example implementation of the above-described scenario / solution for mobility enhancement in a connectivity mode with hierarchical RRM. Flow 1000 may represent one aspect of the functionality of network device 820. Flow 1000 may include one or more operations, actions, or functions, as shown in flow blocks 1010 to 1040. Although shown as independent flow blocks, the flow blocks of flow 1000 may be split into more flow blocks, merged into fewer flow blocks, or omitted depending on the desired implementation. Furthermore, the flow blocks of flow 1000 may be arranged according to... Figure 10 The process can be executed in the order shown, or in a different order. Process 1000 can be implemented by network device 820 or any applicable network node. For illustrative purposes only and without limitation, process 1000 is described below with communication device 810 as the UE and network device 820 as the source network node (e.g., TRP / RU). Process 1000 may begin with process block 1010.

[0068] In process block 1010, process 1000 may involve the processor 822 of network device 820 sending a first DL RS to communication device 810 via transceiver 826, wherein the first DL RS includes identification information of the SFN area but does not include identification information of any network node. Process 1000 can enter process block 1020 from process block 1010.

[0069] In process block 1020, process 1000 may involve processor 822 sending a second DL RS to communication device 810 via transceiver 826, wherein the second DL RS includes identification information of network device 820. Process 1000 can proceed from process block 1020 to process block 1030.

[0070] In process block 1030, process 1000 may involve processor 822 receiving a handover request from communication device 810 via transceiver 826, wherein the handover request includes information about the target network node. Process 1000 may proceed from process block 1030 to process block 1040.

[0071] In process block 1040, process 1000 may include processor 822 sending a switching command to communication device 810 via transceiver 826, wherein the switching command instructs communication device 810 to switch from network device 820 to target network node.

[0072] In some implementations, process 1000 may further include processor 822 sending a mobility request for communication device 810 to a target network node in response to a handover request via transceiver 826, and receiving mobility confirmation from the target network node via transceiver 826.

[0073] In some implementations, the switching command may be in response to the mobility confirmation sent.

[0074] In some embodiments, process 1000 may further include processor 822 sending a PRACH trigger indication to communication device 810 via transceiver 826 in response to the mobility confirmation, wherein the PRACH trigger indication is used to instruct communication device 810 to send a PRACH signal to a target network node. Furthermore, process 1000 may also include processor 822 receiving a TA value determined based on the PRACH signal from the target network node via transceiver 826, wherein the handover command is sent in response to the TA value.

[0075] In some implementations, the handover request can be received using PUSCH resources authorized via the SR procedure or PUSCH resources configured via RRC signaling.

[0076] In some implementations, the handover request may be received in a random access preamble, and the handover command may be sent in a random access response.

[0077] In some implementations, the handover request may indicate that advance synchronization with the target network node has been completed, and the information of the target network node may include at least one of the following: (i) the ID of the target network node; (ii) the signal quality indicator of the target network node; (iii) the reception time difference between the network device 820 and the target network node; and (iv) the ID of the communication device 810.

[0078] In some implementations, the switching command may include at least one of the following: (i) a TA value associated with the target network node; (ii) a PRACH trigger indication for instructing the communication device 810 to send a PRACH signal to the target network node; and (iii) at least one of a DL resource and a UL resource associated with the target network node.

[0079] Figure 11 An example flow 1100 according to an embodiment of this disclosure is illustrated. Flow 1100 may be (whether partially or entirely) an example implementation of the above-described scenario / scheme for mobility enhancement in a connectivity mode with hierarchical RRM. Flow 1100 may represent one aspect of an implementation of the functionality of network device 820. Flow 1100 may include one or more operations, actions, or functions as shown in flow blocks 1110 to 1150. Although shown as discrete flow blocks, the individual flow blocks of flow 1100 may be divided into more flow blocks, merged into fewer flow blocks, or omitted, depending on the desired implementation. Furthermore, the flow blocks of flow 1100 may be arranged according to... Figure 11The process can be executed in the order shown, or in a different order. Process 1100 can be implemented by network device 820 or any suitable network node. For illustrative purposes only and without limitation, the following process 1100 is described in the context of communication device 810 as the UE and network device 820 as the target network node (e.g., TRP / RU). Process 1100 may begin with process block 1110.

[0080] In process block 1110, process 1100 may include the processor 822 of network device 820 sending a first DL RS to communication device 810 via transceiver 826, wherein the first DL RS includes identification information of the SFN area but does not include identification information of any network node. Process 1100 can enter process block 1120 from process block 1110.

[0081] In process block 1120, process 1100 may include processor 822 sending a second DL RS to communication device 810 via transceiver 826, wherein the second DL RS includes identification information of network device 820. Process 1100 may proceed from process block 1120 to process block 1130.

[0082] In process block 1130, process 1100 may include processor 822 receiving a mobility request for communication device 810 from a source network node via transceiver 826. Process 1100 may proceed from process block 1130 to process block 1140.

[0083] In process block 1140, process 1100 may include processor 822 sending a mobility confirmation to the source network node via transceiver 826. Process 1100 may proceed from process block 1140 to process block 1150.

[0084] In process block 1150, process 1100 may include processor 822 receiving a completion message from communication device 810 via transceiver 826, wherein the completion message indicates that the device has switched from the source network node to network device 820.

[0085] In some implementations, process 1100 may further include processor 822 receiving a PRACH signal from communication device 810 via transceiver 826, and sending a TA value associated with network device 820 to communication device 810 or source network node via transceiver 826 before receiving an RRC completion message, wherein the TA value is determined based on the PRACH signal.

[0086] Additional notes

[0087] The topics described herein sometimes demonstrate that different components are contained within or connected to other components. It should be understood that the architectures shown are merely examples, and many other architectures can actually be implemented to achieve the same functionality. Conceptually, any arrangement of components that achieves the same function is considered "associated" in order to achieve the desired functionality. Therefore, any two components combined in this document to achieve a specific function can be considered "associated" with each other in order to achieve the desired functionality, regardless of the architecture or intermediate components. Similarly, any two such associated components can also be considered "operably connected" or "operably coupled" to achieve the desired functionality, and any two components that can be suchly associated can also be considered "operably coupled" to achieve the desired functionality. Specific examples of operable coupling include, but are not limited to, physically matable and / or physically interactive components, wirelessly interactive and / or wirelessly interactive components, and logically interactive and / or logically interactive components.

[0088] Furthermore, regarding the use of almost all plural and / or singular terms in this document, those skilled in the art can convert from plural to singular and / or from singular to plural depending on the context and / or application. For clarity, various singular / plural permutations and combinations may be explicitly listed herein.

[0089] Furthermore, those skilled in the art will understand that terms commonly used herein, particularly in appended claims, such as the body portion of appended claims, are generally considered "open-ended" terms. For example, the word "comprising" should be interpreted as "including but not limited to," the word "having" should be interpreted as "having at least," and the word "including" should be interpreted as "including but not limited to," etc. Those skilled in the art will also further understand that if a particular quantity introduced in a claim is intentional, that intention will be explicitly stated in the claim; if no such statement is made, then that intention does not exist. For example, for ease of understanding, the appended claims described below may contain the use of the introductory phrases "at least one" and "one or more" to introduce the content of the claim. However, the use of such phrases should not be interpreted as meaning that when the content of a claim is introduced by the indefinite article "a" or "an," any specific claim containing that content is limited to containing only one instance of that content, even if the same claim contains the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an," for example, "a" and / or "an" should be interpreted as "at least one" or "one or more"; the same applies to the use of definite articles used to introduce the content of a claim. Furthermore, even if a specific number of the introduced content is explicitly stated in the claims, those skilled in the art will recognize that such a statement should be interpreted as at least the number stated. For example, stating "two contents" alone, without other modifications, means at least two contents, or two or more contents. Additionally, in cases where conventions such as "at least one of A, B, and C" are used, such structures are generally intended for those skilled in the art to understand the meaning of the convention. For example, "a system having at least one of A, B, and C" includes, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and systems having both A, B, and C. In cases where conventions such as "at least one of A, B, and C" are used, such structures are generally intended for those skilled in the art to understand the meaning of the convention. For example, "a system having at least one of A, B, and C" includes, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and systems having both A, B, and C. Those skilled in the art will further understand that virtually any extractive word and / or phrase presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to include the possibility of containing one, any, or both terms. For example, the phrase “A or B” should be understood to include the possibility of “A” or “B” or “A and B”.

[0090] As can be seen from the foregoing, this document describes various embodiments of the present disclosure for illustrative purposes, and various modifications can be made without departing from the scope and spirit of the present disclosure. Therefore, the various embodiments disclosed herein are not intended to be limiting, and the true scope and spirit are defined by the following claims.

Claims

1. A method comprising: The processor of the device performs a first measurement based on a first downlink reference signal received from each of the source network node and the target network node, wherein the first downlink reference signal includes identification information of a single-frequency network area but does not include identification information of any network node; The processor performs a second measurement based on a second downlink reference signal received from each of the source network node and the target network node, wherein the second downlink reference signal includes identification information of the source network node or the target network node; The processor sends a handover request to the source network node based on the first measurement and the second measurement, wherein the handover request includes information about the target network node; as well as The processor receives a switching command from the source network node, wherein the switching command instructs the device to switch from the source network node to the target network node.

2. The method of claim 1, wherein, The switchover request is sent based on the reference time of the source network node.

3. The method as described in claim 1, wherein, The handover request is also sent to the target network node via uplink resources shared by both the source and target network nodes.

4. The method of claim 1, wherein, Also includes: The processor synchronizes with the target network node in advance before the switch request is sent.

5. The method of claim 1, wherein, The handover request is sent using physical uplink shared channel resources authorized through the scheduling request procedure or physical uplink shared channel resources configured through radio resource control signaling.

6. The method of claim 1, wherein, The handover request is sent in the random access preamble, and the handover command is received in the random access response.

7. The method of claim 1, wherein, This information about the target network node includes at least one of the following: The identifier of the target network node; The signal quality indicator of the target network node; The reception time difference between the source network node and the target network node; and The identifier of the device.

8. The method of claim 1, wherein, The switching command includes at least one of the following: The time advance value associated with the target network node; Physical random access channel triggering indication used to instruct the device to send physical random access channel signals to the target network node; and At least one of the downlink and uplink resources associated with the target network node.

9. The method of claim 1, wherein, Also includes: In response to the handover command or physical random access channel trigger indication received from the source network node, the processor sends a physical random access channel signal to the target network node, wherein the physical random access channel signal is sent based on the reference time of the target network node; as well as The processor receives a timing advance value associated with the target network node, wherein the timing advance value is received from the target network node or in the handover command.

10. The method of claim 1, wherein, Also includes: In response to the switching command, the processor switches from the source network node to the target network node; as well as The processor sends a completion message to the target network node, wherein the completion message indicates that the device has switched from the source network node to the target network node.

11. A method comprising: The processor of the source network node sends a first downlink reference signal to the device, wherein the first downlink reference signal includes identification information of a single-frequency network area, but does not include identification information of any network node; The processor sends a second downlink reference signal to the device, wherein the second downlink reference signal includes the identification information of the source network node; The processor receives a handover request from the device, wherein the handover request includes information about the target network node; as well as The processor sends a switching command to the device, wherein the switching command instructs the device to switch from the source network node to the target network node.

12. The method of claim 11, wherein, Also includes: In response to the handover request, the processor sends a mobility request for the device to the target network node; as well as The processor receives mobility confirmation from the target network node.

13. The method of claim 12, wherein, The switching command is sent in response to the mobility confirmation.

14. The method of claim 12, wherein, Also includes: In response to the mobility confirmation, the processor sends a Physical Random Access Channel Trigger Instruction to the device, wherein the Physical Random Access Channel Trigger Instruction Instruction is used to instruct the device to send a Physical Random Access Channel signal to the target network node; as well as The processor receives a timing advance value determined based on the physical random access channel signal from the target network node, wherein the handover command is sent in response to the timing advance value.

15. The method of claim 11, wherein, The handover request is received using physical uplink shared channel resources authorized through the scheduling request procedure or physical uplink shared channel resources configured through radio resource control signaling.

16. The method of claim 11, wherein, The handover request is received in the random access preamble, and the handover command is sent in the random access response.

17. The method of claim 11, wherein, The handover request indicates that prior synchronization with the target network node has been completed, and the information of the target network node includes at least one of the following: The identifier of the target network node; The signal quality indicator of the target network node; The reception time difference between the source network node and the target network node; and The identifier of the device.

18. The method of claim 11, wherein, The switching command includes at least one of the following: The time advance value associated with the target network node; Physical random access channel triggering indication used to instruct the device to send physical random access channel signals to the target network node; and At least one of the downlink and uplink resources associated with the target network node.

19. A method comprising: The processor of the target network node sends a first downlink reference signal to the device, wherein the first downlink reference signal includes identification information of a single-frequency network area, but does not include identification information of any network node; The processor sends a second downlink reference signal to the device, wherein the second downlink reference signal includes the identification information of the target network node; The processor receives a mobility request for the device from the source network node; The processor sends a mobility confirmation to the source network node; as well as The processor receives a completion message from the device, wherein the completion message indicates that the device has switched from the source network node to the target network node.

20. The method of claim 19, wherein, Also includes: The processor receives the physical random access channel signal from the device; as well as Before receiving the RRC completion message, the processor sends a timing advance value associated with the target network node to the device or the source network node, wherein the timing advance value is determined based on the physical random access channel signal.

Images