Method, device and medium for switching

Abstract

The embodiment of the invention relates to a switching method and device and a computer readable storage medium. In one method, a terminal device initiates a random access channel (RACH-free) handover; and determining availability of at least one pre-allocated grant opportunity for uplink transmission, the at least one pre-allocated grant opportunity configured for RACH-free handover.

Description

Technical Field

[0001] Various embodiments of this disclosure generally relate to the telecommunications field, and more particularly to methods, apparatus and computer-readable storage media for switching. Background Technology

[0002] Satellite communications are experiencing a sustained resurgence. Several initiatives for satellite networks have been announced in the past few years. Target services cover backhaul and fixed radio, transport, outdoor mobile, and / or the Internet of Things (IoT). Satellite networks can complement terrestrial mobile networks by providing connectivity to underserved areas and multicast / broadcast services. To benefit from the mobile ecosystem and economies of scale, there is increasing focus on adapting terrestrial radio access technologies, including Long Term Evolution (LTE) and New Radio (NR), for satellite networks, which is reflected in the 3rd Generation Partnership Project (3GPP) standardization work. In 3GPP Release 15, work was initiated to prepare NR for operation in non-terrestrial networks (NTNs). This work was carried out within the research project “Supporting NR for Non-Terrestrial Networks” and resulted in 3GPP Technical Report (TR) 38.811, Release 15.4.0. In 3GPP Release 16, work on preparing NR for operation in NTN networks continued using the research project "Solutions for NR-Supported Non-Terrestrial Networks," which was included in 3GPP TR 38.821 Release 16.2.0. In parallel, interest is growing in adapting Narrowband Internet of Things (NB-IoT) and LTE-Machine-to-Machine (LTE-M) for operation in NTN. Therefore, 3GPP Release 17 includes work items on NR NTN as well as research projects and work items on NB-IoT and LTE-M support for NTN. In the work of 3GPP Release 18, there are topics related to enhancements to NTN-NTN mobility, particularly conditional handover without random access channels (RACH-free). Summary of the Invention

[0003] As mentioned above, in Rel-18, RACH-free HO can be supported in NTN. RACH-free HO has been introduced for LTE. Furthermore, it has been agreed that during RACH-free HO, pre-allocation grants associated with SSBs will be provided. The User Equipment (UE) selects a Synchronization Signal Block (SSB) associated with a pre-allocation scheduling grant that has a Reference Signal Received Power (RSRP) higher than the configuration threshold, and then uses the selected SSB and the corresponding pre-allocation grant timing for the initial uplink (UL) transmission upon RRC Reconfiguration Complete. During the handover supervision timer, timer T304 (hereinafter also referred to as "T304" for simplicity), if no SSB mapped to the pre-allocation grant has an RSRP higher than the threshold, a fallback to RACH-based HO (with a new SSB selection) is performed. Regarding the handling of pre-assigned UL authorizations associated with SSBs, the current protocol is ambiguous in at least the following aspects: how the UE determines that an SSB not mapped to a pre-assigned authorization has an RSRP higher than a threshold (i.e., for conditions of fallback to a RACH-based HO); whether / when the UE should / can return to (attempt to) the pre-assigned UL authorization after falling back to a RACH-based HO; and how to set the RSRP threshold.

[0004] In order to overcome or mitigate at least one of the above problems or other problems, or to provide a useful solution, embodiments of this disclosure provide methods, apparatus and storage media for switching.

[0005] In a first aspect of this disclosure, a method implemented at a terminal device is provided. In this method, the terminal device initiates a RACH-free handover and determines the availability of at least one pre-allocated grant opportunity for uplink transmission, the at least one pre-allocated grant opportunity being configured for the RACH-free handover.

[0006] In a second aspect of this disclosure, a method implemented at a terminal device is provided. In this method, the terminal device initiates a RACH-free handover; and determines that the RACH-free handover should be stopped and that a RACH-based handover should be initiated.

[0007] In a third aspect of this disclosure, a method implemented at a network device is provided. In this method, the network device sends configuration information to an end device indicating at least one of the following: at least one pre-allocated grant timing for RACH-free handover; a maximum value of the number of at least one measurement result used to determine the availability of the at least one pre-allocated grant timing; a first threshold number indicating the number of said at least one measurement result required to determine the availability of the at least one pre-allocated grant timing; a second threshold number, based on the determination that the number of consecutive pre-allocated grant timings in the at least one pre-allocated grant timing is greater than or equal to the second threshold number, indicating that a transition from RACH-free handover to RACH-based handover occurs, and consecutive pre-allocated grant timings are determined to be unavailable; a third threshold number, based on the determination that the number of consecutive pre-allocated grant timings in the at least one pre-allocated grant timing is greater than or equal to the third threshold number. For a third threshold number, the handover transitions from RACH-free to RACH-based handover, wherein all pre-allocated grant opportunities in the consecutive pre-allocated grant opportunity set are determined to be unavailable; rules for determining the availability of pre-allocated grant opportunities; an indication indicating whether the terminal device is allowed to re-initiate a RACH-free handover; a time window including multiple RS measurement periods, within which RACH-based handover is disabled; a first threshold for RS measurement configured to select a pre-allocated grant opportunity for initial uplink transmission during RACH-free handover; and a second threshold for RS measurement configured to select a pre-allocated grant opportunity for retransmission uplink transmission during RACH-free handover, wherein the first threshold is higher than the second threshold.

[0008] In a fourth aspect of this disclosure, a terminal device is provided. The terminal device includes a processor and a memory coupled to the processor, the memory containing instructions executable by the processor, thereby enabling the terminal device to perform a method according to the first or second aspect.

[0009] In a fifth aspect of this disclosure, a network device is provided. The terminal device includes a processor and a memory coupled to the processor, the memory containing instructions executable by the processor, thereby enabling the terminal device to perform the method according to the third aspect.

[0010] In a sixth aspect of this disclosure, an apparatus is provided. The apparatus includes components for performing the method according to the first, second, or third aspect.

[0011] In a seventh aspect of this disclosure, a computer-readable storage medium is provided having instructions stored thereon that, when executed by at least one processor of a device, cause the device to perform the method according to the first, second, or third aspect.

[0012] Using this disclosure, terminal devices can determine whether and / or how to correctly perform RACH-free or RACH-based handover. As a result, the possibility of interruptions caused by handover can be minimized. Attached Figure Description

[0013] Figure 1 This is a diagram illustrating an example communication environment in which embodiments of the present disclosure can be implemented.

[0014] Figure 2A and Figure 2B This is a diagram illustrating example boxes of multiple SSB measurements between two pre-allocated authorization times according to some embodiments.

[0015] Figure 3 This is a diagram illustrating example boxes that do not fall back to a RACH-based HO according to some embodiments.

[0016] Figure 4A , Figure 4B and Figure 5 This is a block diagram illustrating an example switching method according to some embodiments.

[0017] Figure 6 This is a block diagram illustrating a communication device according to some embodiments.

[0018] Figure 7 This is a block diagram illustrating a computer-readable storage medium according to some embodiments.

[0019] Figure 8 This is a block diagram illustrating an example of a communication system according to some embodiments.

[0020] Figure 9 This is a block diagram illustrating a UE according to some embodiments.

[0021] Figure 10 This is a block diagram illustrating a network node according to some embodiments.

[0022] Figure 11 This is a block diagram illustrating a virtualized environment in which the functionality implemented by some embodiments can be virtualized. Detailed Implementation

[0023] As used herein, the terms “first,” “second,” etc., refer to distinct elements. Unless the context clearly indicates otherwise, the singular forms “a” and “an” are also intended to include the plural forms. The terms “comprising,” “having,” and / or “including,” as used herein, specify the presence of the stated features, elements, and / or components, but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof. The term “based on” should be understood as “at least partially based on.” The terms “one embodiment” and “embodiment” will be understood as “at least one embodiment.” The term “another embodiment” should be understood as “at least one other embodiment.” Other explicit and implicit definitions may be included below.

[0024] In the context of this disclosure, the terms "beam" and "cell" are used interchangeably. For quasi-Earth fixed beam / cell or Earth mobile beam / cell, when the satellite serving the area changes (this is called satellite switching), all user equipment (UEs) connected to the old cell need to move to the new cell. In Release 18 (Rel-18), support for RACH-free handover (HO) for NTN is agreed upon.

[0025] In 3GPP Release 18, there are topics related to enhancements in NTN-NTN mobility, particularly RACH-free conditional handover. Satellite radio access networks include the following components: satellites, referring to the space-based bearer platform; terrestrial gateways (GWs) that connect the satellites to base stations or the core network, depending on the architecture chosen; feeder links, referring to the links between the gateways and the satellites; and access links or serving links, referring to the links between the satellites and the UEs.

[0026] Communication satellites generate several beams over a given area. The coverage area of ​​a beam is typically elliptical and is traditionally considered a cell (though a cell consisting of multiple beams is not excluded). The coverage area of ​​a beam is also often referred to as a spot beam.

[0027] NTN supports three types of beams or cells. One type is a fixed geostationary beam / cell, which is equipped with (multiple) beams that continuously cover the same geographic area, for example, in the case of geostationary orbit (GEO) satellites. Another type is a quasi-fixed geostationary beam / cell, which is equipped with (multiple) beams that cover one geographic area for a limited time period and a different geographic area for another time period, for example, in the case of non-geostationary orbit (NGSO) satellites generating steerable beams. A third type is a moving geostationary beam / cell, which is equipped with (multiple) beams whose coverage area slides across the Earth's surface, for example, in the case of NGSO satellites generating fixed or non-steerable beams. Throughout this disclosure, unless explicitly stated otherwise, the terms "beam" and "cell" are used interchangeably.

[0028] When using quasi-Earth fixed beam / cell or Earth mobile beam / cell, if the satellite serving the area changes (referred to as satellite switching), all UEs connected to the old cell (e.g., UEs in Radio Resource Control (RRC)_connected state) must be switched from the old cell (or otherwise moved, e.g., using RRC connection rebuild) to the new cell, and all UEs camped on the old cell (e.g., UEs in RRC_IDLE or RRC_INACTIVE state) must perform cell reselection to the new cell. The result of satellite switching is that both the serving link (i.e., the link between the UE and the satellite) and the feeder link (i.e., the link between the satellite and the GW / gNB) are switched, and the serving cell is also switched. A similar situation occurs for feeder link switching, where the serving satellite remains the same, but its connection to the ground changes from one (old) GW / gNB to another (new) GW / gNB. Furthermore, in this case, there is a transition between the old and new cells (i.e., the old cell is replaced by the new cell). Both satellite switching and feeder link switching can be referred to as the general term "cell switch".

[0029] Due to the special operating conditions in non-terrestrial networks, the system information broadcast in NTN cells includes NTN-specific information. Therefore, a new System Information Block (SIB) (e.g., SIB19) containing NTN-specific information was introduced in NR NTN. In IoT NTN, the new SIB31 can correspond to SIB19 in NR NTN. In 3GPP Technical Specification (TS) 38.331 version 17.4.0, SIB19 is defined in the Abstract Syntax Notation 1 (ASN.1) code as follows:

[0030] Table 1 shows the descriptions of the SIB19 fields.

[0031] Table 1

[0032] NR introduced support for Conditional Handover (CHO). A CHO is a handover performed by the UE when one or more conditional handover execution conditions are met. Such execution conditions are called CondEvents. The UE begins evaluating the execution conditions(s) upon receiving the CHO configuration and stops evaluating the execution conditions(s) once the handover is performed (i.e., the stored configuration is applied to the target cell). The CHO configuration contains the configurations of the CHO candidate cells(s) generated by the candidate gNB(s) and the execution conditions(s) generated by the source gNB(s).

[0033] For terrestrial networks (TN), the execution conditions may include one or two triggering conditions (i.e., (multiple) CondEvents), which may be A3 (the offset of a neighboring cell becomes better than SpCell) and / or A5 (SpCell becomes worse than threshold 1, and the neighboring cell becomes better than threshold 2), as defined in version 17.4.0 of 38.331. For NTN, the execution conditions may include one triggering condition (which may be CondEvent A3 or A5) and another triggering condition, which may be CondEvent D1 (the distance between the UE and reference location 1 is higher than threshold 1 and the distance between the UE and reference location 2 is lower than threshold 2) or CondEvent T1 (the time measured at the UE is within a duration starting from a threshold), as defined in version 17.4.0 of 38.331. In the case of satellite switching with Earth-moving beams / cells, CondEvent D1 is used for location-based CHO triggering. Reference location 1 is associated with the serving cell, and reference location 2 is associated with the candidate target cell. In the case of feeder link handover or satellite switching with quasi-earth fixed beam / cell, CondEvent T1 is used for time-based CHO triggering. The threshold is typically denoted as T1, while the threshold plus the duration is typically denoted as T2. Time-based CHO can only be triggered when CondEvent T1 is satisfied, i.e., the time measured at the UE is between T1 and T2.

[0034] LTE introduced support for RACH-free handover (HO). If RACH-free HO is configured (i.e., configured based on the received RRC connection reconfiguration message), then... rach-Skip (Skip random access), then if in rach-Skip If the UE is configured with a pre-allocated uplink grant, the UE can access the target cell via the pre-allocated uplink grant; otherwise, the UE monitors the physical downlink control channel (PDCCH) of the target cell to access the target cell via a dynamic uplink grant. rach- Skip It also instructs the UE to apply the target cell's timing advance (TA) information (i.e., targetTA) when using pre-allocated or dynamically authorized access target cells.

[0035] In 3GPP Technical Specification Group Random Access Network Working Group 2#121 (3GPP TSG-RAN WG2#121 or RAN2#121), it was agreed to support RACH-free HO for NTN in Release 18 (Rel-18). Dynamic granting and pre-allocated granting are supported for the initial UL transmission following RRC reconfiguration in the target cell. The RACH-free HO is completed upon receipt of a network (NW) acknowledgment (e.g., UE contention resolution identifying Media Access Control (MAC) control element (CE)). RAN2 assumes that UL synchronization processing in the target cell is identical in both RACH-based and RACH-free HOs; that is, the UE itself pre-compensates for the TA to be applied upon accessing the target cell, and synchronization between the source and target cells is not an issue in NTN RACH-free HOs. Furthermore, RAN2#121 also agreed that the combination of RACH-free HOs with time-based CHOs can be considered for NTN.

[0036] As mentioned above, RACH-free HO can be supported in Rel-18 NTN. RACH-free HO has been introduced for LTE. Furthermore, it has been agreed that pre-allocation grants associated with SSBs will be provided during RACH-free HO. The UE selects an SSB associated with the pre-allocation grant that has an RSRP higher than the configured threshold, and then uses the selected SSB and the corresponding pre-allocation grant timing for the initial uplink (UL) transmission after RRC reconfiguration is completed. When the handover supervision timer, timer T304 (hereinafter also referred to as "T304" for simplicity), is running, if no SSB mapped to the pre-allocation grant has an RSRP higher than the threshold, it falls back to RACH-based HO (with a new SSB selection). Regarding the handling of pre-assigned UL grants associated with SSBs, the current protocol is ambiguous in at least the following aspects: how the UE determines that an SSB not mapped to a pre-assigned grant has an RSRP higher than a threshold (i.e., for the condition of falling back to a RACH-based HO); whether / when the UE should / can return to (attempt to) the pre-assigned UL grant after falling back to a RACH-based HO; and how to set the RSRP threshold.

[0037] To overcome or mitigate at least one of the aforementioned problems or other issues, or to provide a useful solution, embodiments of this disclosure propose methods, devices, and storage media for switching. It should be noted that although the problem originates from NTN, the solutions proposed herein are generally applicable to a variety of networks and scenarios. In the following descriptions, NTN will be used as an example scenario to illustrate some exemplary embodiments, while the exemplary embodiments herein are generally applicable to other networks and scenarios.

[0038] Figure 1An example communication environment 100 in which embodiments of the present disclosure can be implemented is shown. For example... Figure 1 As shown, the communication environment 100 includes a network device 110, such as a gNB, which can provide services to a coverage area 115 together with multiple satellites, including a first satellite 120 and a second satellite 125. Satellites 120 and 125 can be connected to the network device 110 via a gateway 127. Satellite 120 or 125 can generate several beams over a given area to provide network access to a terminal device 130 (such as a UE). The coverage area of ​​the beams is elliptical in shape, referred to as a cell. A cell may also include multiple beams. Communication in the communication environment 100 can utilize any suitable communication technology and follow any suitable communication protocols and standards. The scope of this disclosure is not limited in this respect.

[0039] It should be understood that the deployment and number of devices are for illustrative purposes only. Figure 1 The information is shown but does not imply any limitations. The communication environment 100 may include more terminal devices, network nodes, satellites, and gateways. Furthermore, the communication environment 100 may include any other devices. It should also be understood that, as Figure 1 The NTN scenarios and NTN cells shown are merely illustrative and are not limited thereto. Various embodiments of this disclosure can also be applied to TN scenarios and TN cells.

[0040] In communication environment 100, as satellites 120 and 125 move, the satellites 120 and 125 serving coverage area 115 change. For example... Figure 1 As shown, initially, the first satellite 120 serves the coverage area 115. As the first satellite 120 moves away and the second satellite 125 becomes closer, the satellite serving the coverage area 115 is changed to the second satellite 120. In this situation, all terminal devices, including terminal device 130, connected to the source cell provided by the first satellite 120 need to be handed over to the target cell provided by the second satellite 125. The network device 110 can instruct the terminal device 130 when to perform the handover and how to perform synchronization and access the target cell.

[0041] It should be understood that operations at the terminal device and network device should be coordinated. In other words, the network device and the terminal device should have a common understanding regarding configurations, parameters, etc. This common understanding can be achieved through any appropriate interaction between the network device and the terminal device, or by both applying the same rules / policies. Although some operations are described below from the perspective of the terminal device, it should be understood that the corresponding operations should be performed by the network device. Similarly, although some operations are described from the perspective of the network device, it should be understood that the corresponding operations should be performed by the terminal device. For the sake of brevity, some identical or similar content has been omitted here.

[0042] Some embodiments of this disclosure propose solutions for properly handling pre-allocated authorization associated with the SSB during RACH-free handover. These mechanisms can provide some details related to the fallback to RACH-based handover, such as whether / when the UE (as an example of terminal device 130) can return to a RACH-free handover after a fallback to a RACH-based handover, and setting RSRP thresholds for determining the fallback.

[0043] In some embodiments, the UE may determine the availability of pre-allocation grant opportunities based on one or more of the most recent measured SSB bursts, wherein the UE may only consider SSBs measured since the last pre-allocation grant opportunity. The availability of pre-allocation grant opportunities can be determined when no SSB bursts are measured, or when not enough SSB bursts are measured.

[0044] The UE may fall back to RACH-based HO when: a pre-allocation grant opportunity is determined to be unavailable, or multiple consecutive pre-allocation grant opportunities are determined to be unavailable, or the SSB measurement timer expires, or the SSB measurement counter reaches a certain value, or the pre-allocation grant is not used to send a handover completion command. The UE may revoke its decision to fall back to RACH-based HO when: the pre-allocation grant opportunity was determined to be available before an available RA opportunity, or the pre-allocation grant opportunity was determined to be available when measuring the SSB to select the SSB for random access preamble transmission.

[0045] Once back to a RACH-based HO, the UE can do either of the following: not revert to a RACH-free HO, or revert to a RACH-free HO if access to the target cell fails while (unused) pre-allocated grants are available and T304 is still running. Alternatively, or additionally, the UE may have made the maximum allowed number of RA attempts without success, and T304 is still running. Different RSRP thresholds can be configured depending on whether the pre-allocated grant is used for the first transmission of the handover completion message or a retransmission. RSRP thresholds in RRC can be configured in different ways.

[0046] Using the proposed solution, the UE will not be ambiguous regarding whether / when to perform a fallback to a RACH-based handover. Furthermore, the benefits of RACH-free handover can be maximized by allowing the UE to return to a RACH-free handover when appropriate after a fallback. Appropriate settings of the RSRP threshold used to determine the fallback can also leverage the benefits of pre-allocated authorization. It should be understood that the disclosed methods and solutions involving NR Radio Access Technology (RAT) can also be applied to LTE RAT and any other RAT, enabling direct transmission between two (or more) nearby devices without altering the intended meaning.

[0047] It should be noted that, depending on the context, the term "NTN" can refer to either or both of NR NTN and IoT NTN, but the term is primarily used to refer to NR NTN only. The embodiments outlined below are primarily described based on NR-based NTN, but they are equally applicable to LTE-based NTN (and especially IoT NTN).

[0048] It should be noted that the term "network" is used to refer to a network node or network device, which can be a RAN node, such as a gNB (e.g., in an NR-based NTN) or an eNB (e.g., in an LTE-based NTN, such as an IoT NTN), but it can also be a base station or access point in another type of network, or any other network node with the ability to communicate directly or indirectly with a UE. More granular refinement is also conceivable. For example, a gNB can be an en-gNB, and if a split gNB architecture is applied (dividing the gNB into multiple separate entities or nodes), the term "node" can refer to a portion of the gNB, such as gNB-CU (usually simply called CU), gNB-DU (usually simply called DU), gNB-CU-CP (control plane), or gNB-CU-UP (user plane). Similarly, an eNB can be an ng-eNB, and if a split eNB architecture is applied (dividing the eNB into multiple separate entities or nodes), the term "network" (and its implied network nodes) can refer to a portion of the eNB, such as eNB-CU, eNB-DU, eNB-CU-CP, or eNB-CU-UP. Furthermore, the term "network" (and its implied network nodes) can also refer to an IAB donor, IAB donor-CU, IAB donor-DU, IAB donor-CU-CP, or IAB donor-CU-UP.

[0049] In this document, the terms “source node,” “target node,” and “candidate target node” may be used at times. The term “node” in these terms should be understood as a RAN node in an NTN that is typically based on NR technology, LTE technology, or any other RAT in which handover, conditional handover, or another mobility or conditional mobility concept is defined. In an NR-based NTN, such a RAN node may be assumed to be a gNB. In an LTE-based NTN (including IoT NTN), such a RAN node may be assumed to be an eNB. However, alternatives or improvements to these interpretations are also conceivable. For example, a gNB may be an en-gNB, and if a split gNB architecture (dividing the gNB into multiple separate entities or nodes) is applied, the term “node” may refer to a portion of the gNB, such as gNB-CU (usually simply called CU), gNB-DU (usually simply called DU), gNB-CU-CP, or gNB-CU-UP. Similarly, an eNB can be an ng-eNB, and if a split eNB architecture is applied (dividing the eNB into multiple separate entities or nodes), the term "node" can refer to a portion of the eNB, such as eNB-CU, eNB-DU, eNB-CU-CP, or eNB-CU-UP. Furthermore, the term "node" can also refer to IAB-donor, IAB-donor-CU, IAB-donor-DU, IAB-donor-CU-CP, or IAB-donor-CU-UP.

[0050] The terms "Handover Command" and "HandoverCommand" are used interchangeably in this document. Both terms refer to the UE configuration, compiled by the target node (for regular handover) or candidate target node (for conditional handover) during the (conditional) handover preparation phase to prepare the UE for handover or conditional handover. This UE configuration is compiled in the form of an RRC reconfiguration message, which is transmitted to the UE via the source node. The RRC reconfiguration is associated with a target cell or candidate target cell, and the UE applies the RRC reconfiguration when / if it accesses a relevant (candidate) target cell controlled by the (candidate) target node. Formally, a "Handover Command" is an RRC inter-node message transmitted from the target node or candidate target node to the source node during the handover or conditional handover preparation phase. It is carried by the Xn Application Protocol (XnAP) handover request acknowledgment in the transparent container IE from the target NG RAN node to the source NG RAN node. The "Handover Command" RRC inter-node message contains the RRC reconfiguration that the UE should apply when accessing the target cell or candidate target cell. The source node forwards this RRC reconfiguration (i.e., the handover command) to the UE. In this solution description, the term "handover command" is also used to refer to this RRC reconfiguration when it is stored in the UE as part of a CHO configuration. This is also referred to as condRRCReconfig-r16 IE in the ConditionalReconfiguration-r16 IE, CondReconfigToAddMod-r16 IE (which contains the CHO configuration). Within the context of a CHO, the terms "conditional handover command," "(conditional) handover command," and "(conditional) handover command" may also be used.

[0051] When a Chokepoint Activation (CHO) is configured for a UE, the cells that the UE may connect to (i.e., if the CHO execution conditions are met for the cell) are referred to as "candidate target cells". Similarly, the RAN node controlling the candidate target cell is referred to as the "candidate target node", or in NR and NR NTN as the "candidate target gNB". However, the terminology becomes somewhat ambiguous once the UE has detected that the CHO execution conditions for the candidate target cell have been met. At this point, during the actual execution of the CHO and when the UE has connected to a new cell, the relevant cell can be referred to as either the "candidate target cell" or the "target cell". Similarly, the RAN node controlling such a cell can be referred to as either the "candidate target node" (or "candidate target gNB") or the "target node" (or "target gNB") in this case.

[0052] The conditions included in the CHO configuration that control the execution of the conditional configuration process can be referred to as CHO execution conditions, HO execution conditions, CHO trigger conditions, HO trigger conditions, or sometimes simply trigger conditions. Furthermore, the phases of this process can be referred to as the switch preparation phase, switch execution and / or switch completion phase, or as the conditional switch preparation phase (or (conditional) switch preparation phase), conditional switch execution phase, and / or conditional switch completion phase.

[0053] The target cell configuration (for the UE to use in candidate target cells) and the CHO execution conditions provided by the network to the UE for each candidate target cell can be collectively referred to as CHO configuration, or alternatively, each combination of candidate target cells, target cell configuration and CHO execution conditions can be referred to as CHO configuration (i.e., the terminology is inconsistent).

[0054] When writing message names for communication protocols, this document uses two equivalent principles. The principle “<protocol name><message name> message” (e.g., “XnAP handover cancellation message”) and the principle “<message name><protocol name> message” (e.g., “handover cancellation XnAP message”) are equivalent; both refer to messages of the communication protocol (i.e., “<protocol name>”), such as the handover cancellation message for the XnAP communication protocol. The same formatting equivalence applies to other communication protocols, such as the NG Application Protocol (NGAP). NG is the interface between the Network Generation Random Access Network (NG-RAN) and the Generation 5 Core (5GC).

[0055] When accessing a target cell during a HO or CHO, the first message the UE sends to the target node in the target cell after sending the random access preamble and receiving the random access response message is an RRC reconfiguration complete message, indicating the successful completion of the HO or CHO. It should be noted that this RRC reconfiguration complete message is often referred to as the handover complete message.

[0056] According to the 3GPP protocol and 3GPP TS 38.331 version 17.4.0, time-based CHO execution conditions will always be combined with signal strength / quality CHO execution conditions (both of which must be met to trigger CHO execution). However, all embodiments in the proposed solution that do not assume the UE monitors signal strength / quality conditions (i.e., events A3, A4, or A5) also apply when the UE is only configured with time-based CHO execution conditions. (Note that in embodiments describing the lack of CHO execution triggering within a time window (i.e., between T1 and T2), it is assumed that signal strength / quality conditions are configured but not met between T1 and T2.)

[0057] In this document, the terms “source node,” “target node,” and “candidate target node” may be used. The term “node” in these terms should be understood as a RAN node in an NTN that is typically based on NR technology, LTE technology, or any other RAT in which conditional handover or another conditional mobility concept is defined. In an NR-based NTN, such a RAN node may be assumed to be a gNB. In an LTE-based NTN (including IoT NTN), such a RAN node may be assumed to be an eNB. However, alternatives or improvements to these interpretations are also conceivable. For example, a gNB may be an en-gNB, and if a split gNB architecture (dividing the gNB into multiple separate entities or nodes) is applied, the term “node” may refer to a portion of the gNB, such as gNB-CU (usually simply called CU), gNB-DU (usually simply called DU), gNB-CU-CP, or gNB-CU-UP. Similarly, an eNB can be an ng-eNB, and if a split eNB architecture is applied (dividing the gNB into multiple separate entities or nodes), the term "node" can refer to a portion of the eNB, such as eNB-CU, eNB-DU, eNB-CU-CP, or eNB-CU-UP. Furthermore, the term "node" can also refer to an IAB donor, IAB donor-CU, IAB donor-DU, IAB donor-CU-CP, or IAB donor-CU-UP.

[0058] The embodiments are described in terms of normal handover (HO), particularly RACH-free handover, but they are equally applicable to other RACH-free mobility procedures, such as RACH-free conditional handover, RACH-free conditional primary / secondary cell (PSCell) change (e.g., dual connectivity scenarios of primary cell (PCell) in terrestrial networks and PSCell in non-terrestrial networks), or RACH-free conditional Layer 1 (L1) / Layer 2 (L2) mobility procedures (e.g., time-based L1 / L2 mobility procedures).

[0059] Some embodiments involve a (RACH-free) handover process primarily described as Xn-based, i.e., an inter-gNB (RACH-free) HO, where an Xn interface is established between the gNBs, and XnAP messages are used to request and confirm the handover during HO preparation. However, this solution also applies when preparing a (RACH-free) HO between gNBs lacking an established Xn interface. In this case, HO preparation signaling is transmitted via the core network using NGAP messages (and possibly a protocol for messaging between two AMFs in the core network). In this scenario, the handover request XnAP message is replaced by a handover-required NGAP message and a handover request NGAP message, where the handover request NGAP message is sent from the source gNB to the core network, and the core network further sends relevant information to the target gNB in ​​the handover request NGAP message. Similarly, the handover request confirmation XnAP message is replaced by a handover request confirmation NGAP message and a handover command NGAP message, where the handover request confirmation NGAP message is sent from the target gNB to the core network, and the core network further sends relevant information to the source gNB in ​​the handover command NGAP message. When messages are transmitted via the core network, this may involve one or more AMFs. If the source gNB and destination gNB are connected to the same AMF, that AMF handles all the aforementioned message reception and transmission. If the source gNB and destination gNB are connected to different AMFs, these AMFs forward information to each other using the core network protocol.

[0060] In this document, the terms Information Elements (IEs) and fields are used more or less interchangeably. Furthermore, the term Parameter is sometimes used to refer to the same concept. In the 3GPP RRC specification for 5G / NR (i.e., 3GPP TS 38.331 version 17.4.0), Parameter / IE / fields used in ASN.1 codes and procedural texts are typically named with a suffix indicating the version number of the 3GPP standard that introduced the Parameter / IE / field (e.g., the suffix "-r17" for Parameter / IE / fields introduced in version 17 of the 3GPP standard). Parameter / IE / fields following this naming convention are generally referred to with and without the suffix, with the suffixed name used in the ASN.1 code (and thus defining the formal name from the perspective of the ASN.1 compiler), and the name without the suffix used in the procedural text, such as in field descriptions and procedural texts. Relevant examples in the context of this document include the Parameter / IE / fields t1-threshold-r17 / t1-threshold and t-service-r17 / t-service. In this document, two name variations may appear for various parameters / IE / fields.

[0061] There are two main deployment principles for NTN: quasi-earth fixed cells and earth mobile cells. These deployment principles are also known by other names. The quasi-earth fixed cell deployment principle is also known as quasi-earth fixed beam. The earth mobile cell deployment principle is also known as earth mobile beam, or simply mobile or mobile beam.

[0062] In a time-based CHO configuration for a candidate target cell, a time window is defined within which the configured UE can execute the CHO if the signal strength / quality CHO execution conditions are met; outside this time window, the UE may not execute the CHO. This time window is sometimes referred to as the CHO execution time window or CHO execution window in this document. The CHO execution time window is considered to last between time T1 and T2, where T1 is represented by the t1-threshold-r17 field, and T2 is derived from the t1-threshold-r17 field combined with the duration-r17 field, such that T2 = t1-threshold-r17 + duration-r17. Both the t1-threshold-r17 field and the duration-r17 field are included in the condEventT1-r17 IE, which is in turn included in the CondTriggerConfig-r16 IE, which is in turn included in the ReportConfigNR IE. The t1-threshold-r17 field is a Coordinated Universal Time (UTC) timestamp, and the duration-r17 field represents the time period between 100ms and 600 seconds (in 100ms increments).

[0063] When a CHO uses CondEvent T1 as one of its execution conditions, this is referred to as a "time-based CHO". The terms "UL authorization" and "authorization" are used interchangeably herein. The terms / expressions "pre-assigned UL authorization", "pre-assigned authorization", "pre-configured UL authorization", "pre-configured authorization", "pre-configured UL authorization", and "pre-configured authorization" are used interchangeably herein. The terms "SSB set" and "SS burst" are used interchangeably herein.

[0064] The following describes some embodiments of how to determine that no pre-allocated UL grant with mapping satisfies the RSRP threshold condition for an SSB. Depending on the periodicity of the pre-allocation grant, the periodicity of the SSB measurement, and how the pre-allocation grant is associated with the SSB, the UE may have measured the SSB in multiple SSB sets (often referred to as SS bursts) between two pre-allocation grant times associated with the same SSB. Figure 2A (It shows an example of box 200 A for multiple SSB measurements between two pre-assigned authorization times) and Figure 2B(It shows an example of box 200 B of multiple SSB measurements between two pre-assignment authorization times associated with the same SSB.) Two examples are given. Figure 2A In this context, the UE measures SSB in two SS bursts between the nth and (n+1th)th pre-allocation grant times and also between the (n+3rd)th and (n+4th)th pre-allocation grant times. Figure 2B In this scenario, the nth, (n+2), (n+4), and (n+6)th pre-allocation grant opportunities are associated with one set of SSBs, while the (n+1), (n+3), (n+5), and (n+7)th pre-allocation grant opportunities are associated with a different set of SSBs. In this case, the UE measures the SSB in two SS bursts between two adjacent pre-allocation grant opportunities associated with the same SSB.

[0065] In one embodiment, the UE determines whether a pre-allocation grant timing (hereinafter referred to as the pre-allocation grant timing) associated with a certain set of SSBs (i.e., one or more SSBs) does not meet the RSRP condition (e.g., none of the associated SSBs has an RSRP higher than a threshold) based on the SSB measurements in the latest measured set of SSBs or multiple latest measured sets of SSBs prior to the pre-allocation grant timing of interest (e.g., if the UE uses N measurements to determine the RSRP of an SSB, such as the average of N measurements for the same SSB, then it is the set of the latest N measurements of SSBs). If none of the associated SSBs has an RSRP higher than the threshold, the UE determines that the pre-allocation grant timing of interest does not meet the RSRP condition, and then the UE accordingly determines that the pre-allocation grant timing of interest cannot be selected to transmit the handover completion message. Otherwise, if at least one of the SSBs associated with the pre-allocation grant timing of interest has an RSRP determined to be higher than the threshold, the pre-allocation grant timing of interest can be selected to transmit the handover completion message (or any other UL message or data).

[0066] Alternatively or additionally, the UE can determine the SSB quality based on SSB measurements derived / updated from the latest min(m, n) SSB sets prior to the pre-configuration grant timing of interest. m is hard-coded in the standard, configured by the gNB via dedicated or common control signaling, or determined by the UE implementation. n is the total number of SSB sets measured by the UE prior to the pre-configuration grant timing of interest, or the total number of SSB sets measured by the UE between the pre-configuration grant timing of interest and the previous pre-configuration grant timing prior to the latest SSB set measured before the pre-configuration grant timing of interest, or the total number of SSB sets measured by the UE between the pre-configuration grant timing of interest and the previous pre-configuration grant timing, where the SSBs associated with the previous pre-configuration grant timing are the same as those associated with the pre-configuration grant timing of interest, which occurred before the latest SSB set measured prior to the pre-configuration grant timing of interest.

[0067] In one option, if none of the associated SSBs has an RSRP higher than a threshold, the UE determines that the pre-allocation grant timing of interest does not meet the RSRP condition, wherein the RSRP of the corresponding SSB(s) is derived based on SSB measurements on at least the min(m,n,j) sets of the latest min(m,n) SSB sets prior to the pre-allocation grant of interest. Based on this determination, the UE determines that the pre-allocation grant timing of interest cannot be selected to transmit a handover completion message (or any other UL message or data). Otherwise, the pre-allocation grant timing of interest can be selected to transmit a handover completion message (or any other UL message or data).

[0068] In another option, if at least one of the associated SSBs has an RSRP higher than a threshold, the UE determines that the pre-allocation grant timing of interest satisfies the RSRP condition. This is determined / derived / updated based on SSB measurements on at least the min(m,n,k) SSB sets out of the latest min(m,n) SSB sets prior to the pre-allocation grant of interest. Based on this determination, the UE accordingly determines which pre-allocation grant timing of interest can be selected to transmit the handover completion message (or any other UL message or data). Otherwise, no pre-allocation grant timing of interest can be selected to transmit the handover completion message (or any other UL message or data). In the above options, j and k are either hard-coded in the standard, configured by the gNB using dedicated or common control signaling, or determined by the UE implementation.

[0069] As an option, the UE autonomously (based on its implementation) determines the frequency at which it performs SSB measurements. The UE determines the RSRP of the SSB based on p measurements on the same SSB (e.g., by calculating the average, weighted average, or exponential average of the SSB measurements), where p can be specified (i.e., hard-coded in the standard), configured by the network, or left to the UE implementation to choose. If the UE has performed fewer than p measurements on the SSB set before the desired pre-configured grant timing occurs, the UE, as an option, determines that it cannot use the desired pre-configured grant timing (e.g., the UE is not allowed to use the desired pre-configured grant timing). Alternatively, the UE is allowed to determine the RSRP of the SSB based on the SSB measurements already performed (and use the determined RSRP(s) to determine whether the UE can use the desired pre-configured grant timing), provided that the UE has performed measurements on at least q SSB sets, where q satisfies p > q ≥ 1, and where q is hard-coded in the standard, configured by the network, or determined by the UE implementation. As another option, when the number of SSBs measured before the pre-configured authorization time of interest is less than p, the UE may consider the pre-configured authorization time of interest unavailable, or the evaluation of RSRP conditions may be hardcoded in the standard, configured by the network (e.g., in the form of an indication in a RACH-free HO configuration or a RACH-free HO command), or left to the UE implementation to choose.

[0070] In another alternative, the UE can make a determination based on the SSB strength / quality derived / updated from SSB measurements of the latest n SSB sets prior to the pre-allocation grant timing of interest. If fewer than n SSB sets were measured prior to the pre-allocation grant timing of interest (e.g., the first pre-allocation grant timing after RACH-free HO initiation), or fewer than n SSB sets have been measured since the previous pre-allocation grant timing, or fewer than n SSB sets have been measured since the previous pre-allocation grant timing where the SSB associated with that previous pre-allocation grant timing is the same as the SSB associated with the pre-allocation grant timing of interest, and that previous pre-allocation grant timing is the first pre-allocation grant timing after RACH-free HO initiation or a pre-allocation grant timing where the UE has determined its availability based on SSB measurements, then the UE can perform the following actions.

[0071] If the desired pre-configuration grant timing is the first pre-allocated grant timing occurring after the RACH-free HO initiation, then the desired pre-configuration grant timing can be determined as either usable or unusable for transmitting a handover completion message (or any other UL message or data). This determination is hardcoded in the standard, configured by the gNB, or determined by the UE implementation. Otherwise, whether the desired pre-configuration grant timing can be selected depends on the previous pre-configuration grant timing preceding it. For example, if the previous pre-configuration grant timing could / could not be used for transmitting a handover completion message (or any other UL message or data), then the desired pre-configuration grant timing can also / could not be used for transmitting a handover completion message (or any other UL message or data). This can be hardcoded in the standard or configured by the gNB. Otherwise (i.e., the set of SSBs measured before the desired pre-configuration grant timing is not less than n), the UE makes a determination similar to the aforementioned alternative, but without considering "m". The gNB can enable this alternative by indicating an infinite "m" or an empty field for "m".

[0072] In any of the above embodiments and options where the UE determines the RSRP of an SSB based on multiple measurements of the SSB, when assessing whether the associated pre-allocated grant can be used, the UE may use the average of the SSB measurements, the weighted average of the SSB measurements, the exponential average of the SSB measurements, or the L1 / L3 filtering of the SSB measurements to determine the RSRP.

[0073] The method by which the UE makes a decision can be hard-coded in the standard, configured by the gNB using dedicated or common control signaling, or determined by the UE implementation. Examples involve falling back to a RACH-based HO.

[0074] In one embodiment, the UE falls back to RACH-based HO once a pre-allocated grant timing cannot be selected to transmit the handover completion message (or any other UL message or data). In another option, the fallback is performed only if u consecutive pre-allocated grant timings cannot be selected to transmit the handover completion message (or any other UL message or data), where u is hard-coded in the standard or configured by the gNB using dedicated or common control signaling, or determined by the UE implementation. In yet another option, the UE falls back to RACH-based HO once v consecutive groups of pre-allocated grant timings cannot be selected to transmit the handover completion message (or any other UL message or data). The pre-allocated grant timings in each group are associated with different SSBs (e.g., such that for each SSB with associated pre-allocated grant(s), the associated pre-allocated grant(s) appear once and only once in each group). Pre-allocated grant timings associated with the same SSB are placed in different groups, and v is hard-coded in the standard or configured by the gNB using dedicated or common control signaling, or determined by the UE implementation.

[0075] If the UE performs a new SSB measurement before the available RA timing and, based on that SSB measurement, the UE determines that an upcoming pre-configured authorization timing following that SSB measurement is available (e.g., can be selected to transmit a handover completion message), the UE may not fall back to a RACH-based HO. The following... Figure 3 (Example box 300 shows an example where, if a pre-allocation grant timing can be selected again, there is no fallback to a RACH-based HO.) An example is shown where the (n+1)th pre-allocation grant timing is unavailable (e.g., cannot be selected to transmit a handover completion message), while the (n+2)th pre-allocation grant timing is available (e.g., can be selected to transmit a handover completion message) based on a new SSB measurement prior to the available RA timing. In this case, the UE may not fall back to a RACH-based HO and will continue with a RACH-free HO using the (n+2)th pre-allocation grant timing.

[0076] In another embodiment, if the UE has determined to fall back to RACH-based HO using any of the above criteria (or any other criteria), and when the RSRP condition for SSB selection for random access preamble transmission is evaluated by measuring the SSB (e.g., comparing the measured RSRP with the configured value of rsrp-ThresholdSSB IE), and it is determined that an (unused) pre-allocated grant opportunity is available based on the measured SSB, then the UE rescinds its decision to fall back to RACH-based HO and continues to perform RACH-free HO using the available pre-allocated grant opportunity.

[0077] In one embodiment, the UE is configured with a maximum time period (e.g., X ms) that allows the UE to attempt a transmission using pre-allocated grants. When the UE initiates or returns to a RACH-free HO configured with pre-allocated grants, the UE can (re)start a timer with a value of X ms. While the timer is running, the UE can check for any SSB associated with a pre-allocated grant timing where the RSRP is above a threshold, and if so, restart the timer. When the timer expires and the handover completion command has not been successfully transmitted and T304 is still running, the UE falls back to a RACH-based HO. While the timer is running, the UE performs a RACH-free HO using pre-allocated grant timings where at least one associated SSB satisfies the RSRP condition as determined in the embodiments described above. In another option, the UE can use pre-allocated grant timings to perform a RACH-free HO where, while the timer is running, no associated SSB satisfies the RSRP condition as determined in the embodiments described above.

[0078] In another embodiment, the UE is configured with an SSB burst window (e.g., a window containing Y SS bursts), which allows the UE to attempt a transmission using pre-allocated grants. When the UE initiates or returns to a RACH-free HO configured with pre-allocated grants, the UE resets a counter to 0. When the UE measures an SS burst within the window, the counter increments by 1. When X (X<=Y) consecutive SS bursts within the window contain at least one SSB associated with a pre-allocated grant timing and having an RSRP above a threshold, the UE resets the counter to 0. When the counter reaches Y and the handover completion command is not successfully delivered and T304 is still running, the UE falls back to a RACH-based HO. When the counter does not reach Y, the UE performs a RACH-free HO using (multiple) pre-allocated grant timings, where at least one associated SSB satisfies the RSRP condition as determined in the above embodiments. In another option, the UE can perform a RACH-free HO using (multiple) pre-allocated grant timings, where no associated SSB satisfies the RSRP condition as determined in the above embodiments when the counter does not reach Y.

[0079] In one embodiment, the UE first performs a RACH-free handover completion command using pre-allocated grants, and if the UE fails to send a handover completion command using pre-allocated grants, it falls back to a RACH-based handover completion command. The UE determines that the delivery of the handover completion command using pre-allocated grants has failed if any one or more of the following conditions are met: In an example, the UE receives a Radio Link Control (RLC) negative acknowledgment from the target gNB. For example, if Z1 RLC negative acknowledgments are received, the UE can determine that the delivery of the handover completion command using pre-allocated grants has failed. In another example, the UE receives a Hybrid Automatic Repeat Request (HARQ) negative acknowledgment from the target gNB. For example, if Z2 HARQ negative acknowledgments are received, the UE can determine that the delivery of the handover completion command using pre-allocated grants has failed. In yet another example, the UE does not receive any acknowledgment after Z3 transmissions and retransmissions of the handover completion command using pre-allocated grants. In another alternative example, the UE does not receive any acknowledgment within Z4 seconds / milliseconds since it began transmitting the handover completion command using pre-allocated grants. In the above embodiments, X, Y, Z1, Z2, Z3 and Z4 can be hardcoded in the standard, configured by the gNB through dedicated or common control signaling, or determined by the UE.

[0080] In some embodiments, a UE is allowed to fall back to a RACH-based HO only if the RSRP threshold for SSB selection for a RACH-based HO (e.g., the configured value of rsrp-ThresholdSSB IE) is lower than the RSRP threshold for using a pre-allocated grant timing, or if the RSRP threshold for SSB selection for a RACH-based HO is lower than the RSRP threshold for using a pre-allocated grant timing and there exists at least one SSB for which there is no associated pre-allocated grant (in which case the UE may fall back to a RACH-based HO to try an SSB without any associated pre-allocated grant). The manner in which the UE performs a fallback to a RACH-based HO can be hardcoded in the specification, configured by the gNB via dedicated or public control signaling, or determined by the UE implementation.

[0081] The following describes some embodiments regarding whether / when to return to pre-allocated grant after a fallback. It is possible that after a fallback to a RACH-based handover, due to, for example, high congestion in the RA resource, the UE fails to successfully send a handover completion message using the random access procedure, while the (unused) pre-allocated grant opportunity satisfies the RSRP condition and the handover supervision timer (e.g., timer T304) is still running. In one embodiment, once a fallback to a RACH-based handover is implemented, the UE continues to perform the RACH-based handover even if the (unused) pre-allocated grant opportunity satisfies the RSRP condition and T304 is still running. In another option, if the handover completion message has not yet been successfully delivered (e.g., the UE has not yet received the UE contention resolution identifier MAC CE or PDCCH / Physical Downlink Shared Channel (PDSCH) addressed to it) and the (unused) pre-allocated grant opportunity satisfies the RSRP condition and T304 is still running, the UE returns to a RACH-free handover, and the UE uses the (unused) pre-allocated grant opportunity to deliver the handover completion message. In another option, if the (unused) pre-allocated grant time satisfies the RSRP condition and T304 is still operational, the UE returns to a RACH-free handover, and the UE uses the (unused) pre-allocated grant time to deliver a handover completion message without waiting for a possible UE contention resolution identifier MAC CE or PDCCH / PDSCH from the gNB. This can reduce handover interruption time. To support the above embodiments, one option is that the UE continues to measure SSB even after falling back to a RACH-based handover. In another alternative, the UE can skip SSB measurement (or perform lenient SSB measurement) after falling back to a RACH-based handover, and resume (non-lenient) SSB measurement when the RACH-based handover fails or when a handover completion message is sent.

[0082] When the relevant return conditions are met, whether to return to a RACH-free handover after falling back to a RACH-based HO can be hardcoded in the standard, configured by the gNB via dedicated or common control signaling, or determined by the UE implementation. When this is determined by the UE implementation, it can be hardcoded in the standard, or the gNB can indicate whether to allow a return to a RACH-free handover using dedicated or common control signaling. In this case, whether to return to a RACH-free handover when the relevant return conditions are met is determined by the UE implementation.

[0083] In one embodiment, if the UE has made the maximum allowed number of RA attempts (e.g., configured by preambleTransMax IE) after falling back to a RACH-based HO but has failed, the UE can revert to attempting RACH-free access if there are still available pre-allocated grant opportunities (e.g., if the handover supervision timer T304 has not expired). As an option, a further condition for such revert to RACH-free access is that at least one SSB with associated pre-allocated grants satisfies an RSRP threshold condition. Alternatively, no further conditions exist for the UE to revert to RACH-free access; for example, the UE can perform this operation in the scenario described above, regardless of the RSRP measured for the SSB.

[0084] If, after falling back to a RACH-based HO and subsequently restoring to RACH-free access (e.g., because the UE has already made the maximum allowed number of RA attempts), no SSB with associated pre-allocated grants satisfies the RSRP condition (e.g., an SSB RSRP above a threshold), then, as an option, the UE is still allowed to select one of the pre-allocated grant timings after the last SSB measurement performed before the handover supervision timer (timer T304) expires. Alternatively, after falling back to a RACH-based HO and restoring to RACH-free access, the UE is allowed to use any pre-allocated grant timing before T304 expires, even if the RSRP condition for that pre-allocated grant timing is not met.

[0085] The following describes some embodiments regarding setting RSRP thresholds. Soft combination can be performed when using pre-allocated grants to transmit handover completion messages, which is not possible when transmitting handover completion messages in RA mode. One way to further utilize the gains of soft combination is to configure different RSRP thresholds based on whether the pre-allocated grant timing is for the first transmission or a retransmission of the handover completion message. More specifically, a higher RSRP threshold can be configured if the pre-allocated grant timing is for the first transmission of the handover completion message, and a lower RSRP threshold can be configured if the pre-allocated grant timing is for multiple retransmissions of the handover completion message. In this way, if the handover completion message has been transmitted at least once using pre-allocated grants, falling back to a RACH-based HO will be more restrictive, and falling back to a RACH-free HO will be easier. For example, pre-allocated grants will be used more often, especially for retransmissions, so it can benefit more from soft combination and simultaneously reduce the collision experience in RACH-based transmissions. Regarding threshold configuration, either both thresholds are explicitly configured, or one threshold is explicitly configured while the other is configured as an offset relative to the explicitly configured threshold.

[0086] In some embodiments assuming a single RSRP threshold using pre-allocated grant timing (i.e., there are no two threshold levels as described above), the RSRP threshold using pre-allocated grant timing (hereinafter referred to as RSRP) thres_grant It can be configured in different ways. As an option, there is no option for RSRP. thres_grant Instead of specifying a separate IE, reuse RSRPSSB_RA (e.g., rsrp-ThresholdSSB IE). As another option, for RSRP... thres_grant Specify a separate IE, but this can be optional, where the default value (if the new IE does not exist) is specified as the RSRP used. SSB_RA The value of . As another option (which can be combined with the aforementioned options), RSRP thres_grant IE is specified to be added to RSRP SSB_RA The offset (e.g., added to the value of rsrp-ThresholdSSB IE).

[0087] If two or more levels are used for a threshold targeting the use of pre-allocated grant timing, the above options can be applied to the highest threshold level, such as the level used for the first transmission of the switch completion message. And the threshold for using pre-allocated grant timing is specified relative to the RSRP threshold used for SSB selection during random access (RSRP...). SSB_RA The offset option can be applied to specify all levels of the multi-level threshold for using pre-assigned authorization timing.

[0088] Figure 4A A flowchart of an example method 400A for switching according to some embodiments of the present disclosure is shown. Method 400A can be implemented as follows: Figure 1 The terminal device shown is implemented at 130 locations.

[0089] At block 410, terminal device 130 initiates a RACH-free handover. At block 420, terminal device 130 determines the availability of at least one pre-allocated grant opportunity for uplink transmission, which is configured for RACH-free handover. In the example, based on the determination that one of the at least one pre-allocated grant opportunities is available, terminal device 130 transmits uplink transmissions on that pre-allocated grant opportunity. In the example, based on the determination that the at least one pre-allocated grant opportunity is unavailable, terminal device 130 initiates a RACH-based handover.

[0090] In the example, terminal device 130 determines the availability of a pre-allocated grant time based on at least one measurement result of at least one RS transmitted prior to the pre-allocated grant time in at least one pre-allocated grant time. In the example, the at least one measurement result includes at least one measurement result immediately preceding the pre-allocated grant time. In the example, the at least one measurement result includes available measurement results obtained before the pre-allocated grant time, or the at least one measurement result is obtained during a time period prior to the pre-allocated grant time, which time period includes: a predetermined time period, a predetermined time window, or the duration between the pre-allocated grant time and another pre-allocated grant time preceding the pre-allocated grant time. In the example, the other pre-allocated grant time is adjacent to or not adjacent to the pre-allocated grant time, or both the pre-allocated grant time and the other pre-allocated grant time are associated with an RS identifier or beam.

[0091] In the example, based on determining that the number of the at least one measurement result is greater than one, terminal device 130 determines availability based on at least one of the following: the most recent of the at least one measurement result, the maximum measurement value of the at least one measurement result, or the average measurement value of the at least one measurement result. In the example, terminal device 130 determines that a pre-allocation authorization opportunity is unavailable in response to at least one of the following: none of the at least one measurement result meets the quality conditions, or one or more of the at least one measurement result fails to meet the quality conditions. In the example, terminal device 130 determines that a pre-allocation authorization opportunity is available in response to at least one of the following: all of the at least one measurement result meets the quality conditions, or one or more of the at least one measurement result meets the quality conditions. In the example, the maximum number of the at least one measurement result is predefined, configured by the network device, or set by terminal device 130.

[0092] In the example, terminal device 130 determines that a pre-allocated authorization opportunity is unavailable if the number of available measurement results is less than or equal to a first threshold number; or it determines availability based on available measurement results, wherein the first threshold number is predefined, configured by the network device, or set by terminal device 130. In the example, availability is determined based on default rules or rules configured by the network device.

[0093] In the example, the terminal device 130 determines that the pre-allocation authorization opportunity is available based on the fact that the number of available measurement results is less than or equal to a first threshold number and the pre-allocation authorization opportunity is a pre-allocation authorization opportunity immediately following the RACH-free handover initiation.

[0094] In the example, terminal device 130 initiates a RACH-based handover in response to one of the following: a pre-allocated grant time in the at least one pre-allocated grant time is determined to be unavailable; the number of consecutive pre-allocated grant time in the at least one pre-allocated grant time is greater than or equal to a second threshold number; consecutive pre-allocated grant time is determined to be unavailable; all pre-allocated grant time in the set of pre-allocated grant time in the at least one pre-allocated grant time is determined to be unavailable; or the number of consecutive pre-allocated grant time in the set of at least one pre-allocated grant time is greater than or equal to a third threshold number, wherein all pre-allocated grant time in the set of consecutive pre-allocated grant time is determined to be unavailable. In one example, different pre-allocated grant time periods included in the set of pre-allocated grant time periods are associated with different RS identifiers or different beams. In the example, terminal device 130 is located in an NTN.

[0095] Figure 4B A flowchart of an example method 400B for switching according to some embodiments of the present disclosure is shown. Method 400B can be implemented as follows: Figure 1 The terminal device shown is implemented at 130 locations.

[0096] At block 460, terminal device 130 initiates a RACH-free handover. At block 470, terminal device 130 determines that the RACH-free handover should be stopped and a RACH-based handover should be initiated. In the example, in response to the pre-allocation grant timing configured for the RACH-free handover being determined to be available, terminal device 130 continues or re-initiates the RACH-free handover, wherein the pre-allocation grant timing precedes the available RA timing for the RACH-based handover, or wherein the RS measurement associated with the pre-allocation grant timing precedes the RA timing for the RACH-based handover.

[0097] In the example, terminal device 130 starts a timer after the initiation or re-initiation of a RACH-free handover; and during the timer's operation: disables the initiation of a RACH-based handover, or continues or re-initiates the RACH-free handover based on at least one pre-allocated authorization timing configured for RACH-free handover. In the example, terminal device 130 determines that a RACH-based handover should be initiated based on the determination that the timer has expired and the RACH-free handover is not yet complete. In the example, terminal device 130 disables the initiation of a RACH-based handover within a time window that includes multiple RS measurement cycles. In the example, terminal device 130 starts a counter after the initiation or re-initiation of a RACH-free handover; and before the counter value exceeds a threshold: disables the initiation of a RACH-based handover, or continues or re-initiates the RACH-free handover based on at least one pre-allocated authorization timing configured for RACH-free handover. In the example, terminal device 130 determines that a RACH-based handover should be initiated based on the determination that the counter value exceeds a threshold and the RACH-free handover is not yet complete. In the example, RACH-free handover takes precedence over RACH-based handover.

[0098] In the example, in response to the failure to transmit a handover completion message for a RACH-free handover, terminal device 130 determines that a RACH-based handover is to be initiated. In the example, based on the receipt of a negative acknowledgment of the handover completion message, terminal device 130 determines that the transmission of the handover completion message has failed. In the example, based on the determination that a first quality level required for a RACH-free handover is lower than or equal to a second quality level required for a RACH-based handover, terminal device 130 disables the RACH-based handover. In the example, based on the determination that a first set of reference signals (RS) associated with a RACH-free handover and a second set of RSs associated with a RACH-based handover at least partially overlap, terminal device 130 disables the RACH-based handover.

[0099] In the example, terminal device 130 initiates a RACH-based handover; and in response to the failure to transmit the handover completion message for the RACH-based handover, it disables the re-initiation of a RACH-free handover, or re-initiates a RACH-free handover based on at least one trigger condition for the RACH-free handover being met. In the example, the at least one trigger condition includes at least one of the following: a RACH-based handover failure condition, a condition that terminal device 130 is allowed to re-initiate a RACH-free handover, a condition that the measurement result of the pre-allocated authorization timing configured for the RACH-free handover meets the quality conditions for the RACH-free handover, a condition that the handover timer has not expired, or a condition that the time alignment timer has not expired. In the example, terminal device 130 determines whether it is allowed to re-initiate a RACH-free handover based on default rules or rules configured by the network device.

[0100] In the example, after re-initiating a RACH-free handover, terminal device 130 performs uplink transmissions at a pre-allocated grant timing configured for RACH-free handover, regardless of the measurement results of the RS measurement associated with the pre-allocated grant timing. In the example, a first threshold for RS measurement is configured to select a pre-allocated grant timing for the initial uplink transmission during RACH-free handover, and a second threshold for RS measurement is configured to select a pre-allocated grant timing for retransmission uplink transmissions during RACH-free handover, with the first threshold being higher than the second threshold. In the example, terminal device 130 is located in an NTN.

[0101] Figure 5 A flowchart of an example switching method 500 according to some embodiments of the present disclosure is shown. Method 500 can be implemented as follows: Figure 1 The network device shown is implemented at 110 locations.

[0102] At block 510, network device 110 transmits configuration information to terminal device 130 indicating at least one of the following: at least one pre-allocated grant timing for RACH-free handover; a maximum value of the number of the at least one measurement result used to determine the availability of the at least one pre-allocated grant timing; a first threshold number indicating the number of the at least one measurement result required to determine the availability of the at least one pre-allocated grant timing; a second threshold number, based on the determination that the number of consecutive pre-allocated grant timings in the at least one pre-allocated grant timing is greater than or equal to the second threshold number, when transitioning from RACH-free handover to RACH-based handover, consecutive pre-allocated grant timings are determined to be unavailable; a third threshold number, based on the determination that the number of consecutive pre-allocated grant timing sets of the at least one pre-allocated grant timing is greater than or equal to the second threshold number. For a third threshold number, the handover transitions from RACH-free to RACH-based handover, wherein all pre-allocated grant opportunities in the consecutive pre-allocated grant opportunity set are determined to be unavailable; rules for determining the availability of pre-allocated grant opportunities; an indication indicating whether the terminal device is allowed to re-initiate a RACH-free handover; a time window including multiple reference signal (RS) measurement periods, within which RACH-based handover is disabled; a first threshold for reference signal (RS) measurement, configured to select a pre-allocated grant opportunity for initial uplink transmission during RACH-free handover; and a second threshold for RS measurement, configured to select a pre-allocated grant opportunity for retransmission uplink transmission during RACH-free handover, wherein the first threshold is higher than the second threshold.

[0103] As referenced above Figures 1 to 3 All operations and features related to terminal device 130 (such as UE) and network device 110 (such as eNB or gNB) are equally applicable to method 400 A, method 400 B, and method 500 and have similar effects. For the sake of simplicity, details will be omitted.

[0104] Figure 6 A communication device 600 according to some embodiments is shown. For example... Figure 6 As shown, the communication device 600 may include a processor 605 and a memory 610. The memory 610 may contain instructions 615 executable by the processor 605, thereby enabling the communication device 600 to operate to implement the instructions according to the reference. Figures 1 to 5 Any actions or operations described in the above embodiments. In some embodiments, communication 600 may operate as a terminal device and is operable to perform method 400 A or method 400 B. In some embodiments, communication 600 may operate as a network device and is operable to perform method 500.

[0105] Processor 605 can be any type of processing component, such as one or more microprocessors or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), application-specific digital logic, etc. Memory 610 can be any type of storage component, such as read-only memory (ROM), random access memory, cache memory, flash memory, optical storage, etc.

[0106] Figure 7 A computer-readable storage medium 700 according to some embodiments is shown. For example... Figure 7 As shown, the computer-readable storage medium 700 includes instructions 415, which, when executed by the device's processor, cause the device to perform a reference... Figures 1 to 5 Any of the above embodiments described. The computer-readable storage medium 700 may be configured to include a memory such as RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disk, optical disk, floppy disk, hard disk, removable magnetic tape, or flash drive.

[0107] In some embodiments, the apparatus capable of performing method 400 A, method 400 B, or method 500 may include components for performing the corresponding operations of method 400 A, method 400 B, or method 500. These components may be implemented in any suitable form. For example, the components may be implemented in a circuit or software module.

[0108] Figure 8 An example of a communication system 800 according to some embodiments is shown.

[0109] In this example, the communication system 800 includes a telecommunications network 802 and a core network 806. The telecommunications network 802 includes an access network 804, such as a radio access network (RAN), and the core network 806 includes one or more core network nodes 808. The access network 804 includes one or more access network nodes, such as network nodes 810a and 810b (one or more of which may generally be referred to as network node 810), or any other similar 3GPP access node or non-3GPP access point. Furthermore, as those skilled in the art will understand, network nodes are not necessarily limited to implementations that are provided and integrated by a single vendor for the radio and baseband portions. Therefore, it should be understood that network nodes include decoupled implementations or portions thereof. For example, in some embodiments, the telecommunications network 802 includes one or more Open RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunications network 802 that supports ORAN specifications (e.g., specifications published by the O-RAN Alliance or any similar organization) and can operate alone or together with other nodes to perform one or more functions of any node in the telecommunications network 802 (including one or more network nodes 810 and / or core network nodes 808).

[0110] Examples of ORAN network nodes include Open Radio Units (O-RUs), Open Distributed Units (O-DUs), Open Central Units (O-CUs) (including O-CU Control Plane (O-CU-CP) or O-CU User Plane (O-CU-UP)), RAN Intelligent Controller (near real-time or non-real-time) managed software or software plug-ins, such as near real-time control applications (e.g., xApps) or non-real-time control applications (e.g., rApps), or any combination thereof (the adjective "open" indicates support for the ORAN specification). Network nodes can support the specification by, for example, supporting interfaces defined by the ORAN specification (such as A1, F1, W1, E1, E2, X2, Xn interfaces, Open Fronthaul User Plane Interface, or Open Fronthaul Management Plane Interface). Furthermore, an ORAN access node can be a logical node within a physical node. X2 is the interface between two eNBs in LTE. Xn is the interface between two gNBs in NR.

[0111] Furthermore, ORAN network nodes can be implemented in a virtualized environment (described further below), where one or more network functions are virtualized. For example, the virtualized environment may include an O-cloud platform orchestrated by a service management and orchestration framework via an O-2 interface defined by the O-RAN Alliance or similar technologies. Network node 810 facilitates direct or indirect connections for user equipment (UEs), such as connecting UEs 812a, 812b, 812c, and 812d (one or more of which may generally be referred to as UE 812) to the core network 806 over one or more radio connections.

[0112] Examples of wireless communication via wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information without the use of wires, cables, or other conductors. Furthermore, in various embodiments, communication system 800 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that can facilitate or participate in the communication of data and / or signals, whether via wired or wireless connections. Communication system 800 may include and interface with any type of communication, telecommunications, data, cellular, radio network, and / or other similar type of system.

[0113] UE 812 can be any of a variety of communication devices, including wireless devices that are arranged, configured, and / or operable to communicate wirelessly with network node 810 and other communication devices. Similarly, network node 810 is arranged, capable of, configured, and / or operable to communicate directly or indirectly with UE 812 and / or with other network nodes or devices in telecommunication network 802 to achieve and / or provide network access, such as wireless network access, and / or perform other functions, such as management in telecommunication network 802.

[0114] In the depicted example, core network 806 connects network node 810 to one or more host computing systems, such as host 816. These connections can be direct or indirect via one or more intermediate networks or devices. In other examples, network nodes can be directly coupled to hosts. Core network 806 includes one or more core network nodes (e.g., core network node 808) constructed with hardware and software components. The characteristics of these components can be substantially similar to those described with respect to UE, network nodes, and / or hosts, such that the description generally applies to the corresponding components of core network node 808. Example core network nodes include functions of one or more of the following: Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier Dehiding Function (SIDF), Unified Data Management (UDM), Secure Edge Protection Agent (SEPP), Network Open Function (NEF), and / or User Plane Function (UPF).

[0115] Host 816 may be owned or controlled by a service provider other than the operator or provider of access network 804 and / or telecommunications network 802. Host 816 may host various applications to provide one or more services. Examples of such applications include live and pre-recorded audio / video content, data collection services (such as retrieving and compiling data about various environmental conditions detected by multiple UEs), analytics functions, social media, functions for controlling or otherwise interacting with remote devices, functions for alarms and monitoring centers, or any other such functions performed by the server.

[0116] As a whole, Figure 8 The communication system 800 enables connections between the UE, network nodes, and hosts. In this sense, the communication system can be configured to operate according to predefined rules or procedures, such as specific standards, including but not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE) and / or other suitable 2G, 3G, 4G, 5G standards or any applicable future generation standard (e.g., 6G); Wireless Local Area Network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi); and / or any other suitable wireless communication standards, such as Global Microwave Access Interoperability (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any Low Power Wide Area Network (LPWAN) standards, such as LoRa and Sigfox.

[0117] In some examples, telecommunications network 802 is a cellular network implementing 3GPP standardized features. Therefore, telecommunications network 802 can support network slicing to provide different logical networks to different devices connected to it. For example, telecommunications network 802 can provide ultra-reliable low-latency communication (URLLC) services to some UEs while providing enhanced mobile broadband (eMBB) services to other UEs, and / or massive machine-type communication (mMTC) / massive IoT services to yet another UE.

[0118] In some examples, UE 812 is configured to transmit and / or receive information without direct human interaction. For example, the UE may be designed to transmit information to access network 804 in a predetermined schedule when triggered by an internal or external event, or in response to a request from access network 804. Additionally, the UE may be configured to operate in single RAT, multi-RAT, or multi-standard modes. For example, the UE may operate with any one or a combination of Wi-Fi, NR (New Radio), and LTE, i.e., configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) New Radio Dual Connectivity (EN-DC).

[0119] In this example, hub 814 communicates with access network 804 to facilitate indirect communication between one or more UEs (e.g., UE 812c and / or 812d) and network nodes (e.g., network node 810b). In some examples, hub 814 may be a controller, router, content source and analytics component, or any other communication device described herein relating to the UE. For example, hub 814 may be a broadband router that enables the UE to access core network 806. As another example, hub 814 may be a controller that sends commands or instructions to one or more actuators in the UE. Commands or instructions may be received from the UE, network node 810, or via executable code, scripts, procedures, or other instructions in hub 814. As another example, hub 814 may be a data collector that acts as temporary storage for UE data, and in some embodiments, may perform data analysis or other processing. As another example, hub 814 may be a content source. For example, for a UE acting as a VR device, display, speaker, or other media delivery device, hub 814 can acquire VR assets, video, audio, or other media or data related to sensory information via network nodes, and then hub 814 provides the media or data to the UE directly, after performing local processing, and / or after adding additional local content. In yet another example, hub 814 acts as a proxy server or orchestrator for the UE, particularly if one or more UEs are low-energy IoT devices.

[0120] Hub 814 may have a constant / persistent or intermittent connection to network node 810b. Hub 814 may also allow different communication schemes and / or scheduling between hub 814 and UEs (e.g., UEs 812c and / or 812d) and between hub 814 and core network 806. In other examples, hub 814 is connected to core network 806 and / or one or more UEs via a wired connection. Furthermore, hub 814 may be configured to connect to an M2M service provider via access network 804 and / or to another UE via a direct connection. In some scenarios, a UE may establish a wireless connection with network node 810 while still being connected via hub 814 via a wired or wireless connection. In some embodiments, hub 814 may be a dedicated hub, i.e., a hub whose primary function is to route communication to / from UEs from / to network node 810b. In other embodiments, hub 814 may be a non-dedicated hub, i.e., a device capable of operating to route communication between the UE and network node 810b, but also capable of operating as a communication start and / or end point for certain data channels.

[0121] Figure 9 A UE 900 according to some embodiments is shown. The UE 900 presents... Figure 8 Additional details regarding some embodiments of UE 812. As used herein, UE refers to a device capable of, configured to, positioned and / or operable to wirelessly communicate with network nodes and / or other UEs. Examples of UEs include, but are not limited to, smartphones, mobile phones, cellular phones, Voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage / playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablets, laptops, laptop embedded devices (LEEs), laptop mounted devices (LMEs), augmented reality (AR) or virtual reality (VR) devices, wireless customer premises equipment (CPEs), vehicles, in-vehicle or vehicle-embedded / integrated wireless devices, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including narrowband Internet of Things (NB-IoT) UEs, machine-type communication (MTC) UEs and / or enhanced MTC (eMTC) UEs.

[0122] The UE may support device-to-device (D2D) communication, for example, by implementing 3GPP standards for sidelink communication, Dedicated Short Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, the UE may not necessarily be a user in the sense of a human user who owns and / or operates the associated equipment. Instead, the UE may represent a device intended to be sold to or operated by a human user, but which may not be associated with a particular human user or may not initially be associated with a particular human user (e.g., a smart sprinkler controller). Alternatively, the UE may represent a device not intended to be sold to or operated by an end user but which may be associated with or operated in the user's interest (e.g., a smart power meter).

[0123] UE 900 includes processing circuitry 902, which is operatively coupled via bus 904 to input / output interface 906, power supply 908, memory 910, communication interface 912, and / or any other component or any combination thereof. Some UEs may utilize... Figure 9 The components shown may be all or a subset of the components. The level of integration between components may vary from UE to UE. Furthermore, some UEs may contain multiple instances of components, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0124] Processing circuitry 902 is configured to process instructions and data and can be configured to implement any sequential state machine operable to execute instructions stored in memory 910 as a machine-readable computer program. Processing circuitry 902 can be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.); programmable logic and appropriate firmware; one or more stored computer programs, general-purpose processors (such as microprocessors or digital signal processors (DSPs)) and appropriate software; or any combination thereof. For example, processing circuitry 902 may include multiple central processing units (CPUs).

[0125] In this example, the input / output interface 906 can be configured to provide one or more interfaces to input devices, output devices, or one or more input and / or output devices. Examples of output devices include speakers, sound cards, video cards, displays, monitors, printers, actuators, transmitters, smart cards, other output devices, or any combination thereof. Input devices can allow users to capture information into the UE 900. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital video cameras, webcams, etc.), microphones, sensors, mice, trackballs, steering wheels, touchpads, scroll wheels, smart cards, etc. Presence-sensitive displays may include capacitive or resistive touch sensors to sense input from the user. Sensors may be, for example, accelerometers, gyroscopes, tilt sensors, force sensors, magnetometers, optical sensors, proximity sensors, biometric sensors, etc., or any combination thereof. Output devices can use the same type of interface port as input devices. For example, a Universal Serial Bus (USB) port can be used to provide both input and output devices.

[0126] In some embodiments, power supply 908 is configured as a battery or battery pack. Other types of power sources may be used, such as external power sources (e.g., power outlets), photovoltaic devices, or battery cells. Power supply 908 may also include power circuitry for delivering power from power supply 908 itself and / or external power sources to various parts of UE 900 via input circuitry or an interface such as a power cable. The delivery of power may, for example, be used to charge power supply 908. The power circuitry may perform any formatting, conversion, or other modifications on the power from power supply 908 to suit the power for the respective components of UE 900 to which it supplies power.

[0127] Memory 910 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), disk, optical disk, hard disk, removable cassette tape, flash drive, etc. In the example, memory 910 includes one or more applications 914 (such as an operating system, web browser application, widget, widget engine, or other application) and corresponding data 916. Memory 910 can store any one or a combination of various operating systems for use by UE 900.

[0128] The memory 910 can be configured to include a number of physical drive units, such as a redundant array of independent disks (RAID), flash memory, USB flash drive, external hard drive, thumb drive, pen drive, key drive, high-density digital universal optical disc (HD-DVD) drive, internal hard drive, Blu-ray disc drive, holographic digital data storage (HDDS) disc drive, external small dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro DIMM SDRAM, smart card memory (such as a tamper-proof module in the form of a universal integrated circuit card (UICC) including one or more user identity modules (SIMs) (such as USIM and / or ISIM), other memory, or any combination thereof. The UICC can be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly known as a "SIM card". The memory 910 can allow the UE 900 to access instructions, applications, etc., stored on transient or non-transient storage media to offload or upload data. Articles of manufacture (such as articles of manufacture utilizing communication systems) may be tangibly embodied in or contained in memory 910, which may be or include a device-readable storage medium.

[0129] Processing circuitry 902 can be configured to communicate with an access network or other network using communication interface 912. Communication interface 912 may include one or more communication subsystems and may include or be communicatively coupled to antenna 922. Communication interface 912 may include one or more transceivers for communication, such as through one or more remote transceivers communicating with another device capable of wireless communication (e.g., another UE or a network node in the access network). Each transceiver may include a transmitter 918 and / or a receiver 920 adapted to provide network communication (e.g., optical, electrical, frequency allocation, etc.). Furthermore, transmitter 918 and receiver 920 may be coupled to one or more antennas (e.g., antenna 922) and may share circuitry, software, or firmware, or alternatively, may be implemented separately.

[0130] In the illustrated embodiment, the communication functions of the communication interface 912 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication such as using a Global Positioning System (GPS) to determine location, another similar communication function, or any combination thereof. Communication may be implemented according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Optical Network (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), etc.

[0131] Regardless of the type of sensor, the UE can provide the output of data captured by its sensors via its communication interface 912 through a wireless connection to the network node. Data captured by the UE's sensors can be transmitted to the network node via another UE through a wireless connection. The output can be periodic (e.g., every 15 minutes if a sensed temperature is reported), random (e.g., to balance the reporting load from multiple sensors), responsive to a triggered event (e.g., sending an alarm when moisture is detected), responsive to a request (e.g., a user-initiated request), or a continuous stream (e.g., a real-time video feed of a patient).

[0132] As another example, the UE includes an actuator, motor, or switch associated with a communication interface configured to receive wireless input from a network node via a wireless connection. The state of the actuator, motor, or switch can change in response to the received wireless input. For example, the UE may include a motor that adjusts the control surfaces or rotors of a flying drone based on the received input, or adjusts a robotic arm performing a medical procedure based on the received input.

[0133] When in the form of an Internet of Things (IoT) device, the UE can be a device for one or more application areas, including but not limited to urban wearable technology, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices include devices or devices embedded in the following: connected refrigerators or freezers, TVs, connected lighting fixtures, electricity meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door / window sensors, flood / humidity sensors, ignition locks, connected doorbells, air conditioning systems (such as heat pumps), autonomous vehicles, monitoring systems, weather monitoring devices, vehicle parking monitoring devices, electric vehicle charging stations, smartwatches, fitness trackers, wearable devices for haptic or sensory enhancement, sprinklers, animal or object tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any type of medical device (such as heart rate monitors or remotely controlled surgical robots). The UE in the form of an IoT device includes circuitry and / or software depending on the intended application of the IoT device, and as per [reference to...]. Figure 9 Other components described in UE 900.

[0134] As another concrete example, in IoT scenarios, a UE can represent a machine or other device that performs monitoring and / or measurement and transmits the results of such monitoring and / or measurement to another UE and / or network node. In this case, the UE can be an M2M device, which can be referred to as an MTC device in the 3GPP context. As a specific example, the UE can implement the 3GPP NB-IoT standard. In other scenarios, a UE can represent a vehicle, such as a car, bus, truck, ship, or aircraft, or other device capable of monitoring and / or reporting its operational status or other functions associated with its operation.

[0135] In practice, any number of UEs can be used together for a single use case. For example, the first UE can be a drone or integrated into a drone, providing the drone's speed information (obtained via a speed sensor) to a second UE, which is a remote controller operating the drone. When a user makes a change from the remote controller, the first UE can adjust the throttle on the drone (e.g., by controlling the actuator) to increase or decrease the drone's speed. The first and / or second UEs can also include more than one of the above-described functions. For example, a UE can include sensors and actuators, and handle data communication for both the speed sensor and the actuator.

[0136] Figure 10A network node 1000 according to some embodiments is illustrated. As used herein, a network node refers to a device that is capable of, configured, arranged, and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or devices in a telecommunications network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs)), O-RAN nodes, or components of O-RAN nodes (e.g., O-RUs, O-DUs, O-CUs).

[0137] Base stations can be classified based on the coverage they provide (or in other words, their transmit power levels), and therefore, depending on the coverage provided, they can be called femtocells, picocells, microcells, or macrocells. A base station can be a relay node or a relay donor node controlling a relay. Network nodes can also include one or more (or all) portions of a distributed radio base station, such as centralized digital units, distributed units (e.g., in O-RAN access nodes), and / or remote radio units (RRUs), sometimes referred to as remote radio heads (RRHs). Such remote radio units may or may not be integrated with an antenna as antenna-integrated radios. A portion of a distributed radio base station can also be referred to as a node in a distributed antenna system (DAS).

[0138] Other examples of network nodes include multi-TRP 5G access nodes, multi-standard radio (MSR) equipment (such as MSR BS), network controllers (such as Radio Network Controller (RNC) or Base Station Controller (BSC)), base transceiver stations (BTS), transport points, transport nodes, multi-cell / multicast coordination entities (MCE), operations and maintenance (O&M) nodes, operations support system (OSS) nodes, self-organizing network (SON) nodes, location nodes (e.g., evolved serving mobile location center (E-SMLC)), and / or minimized drive test (MDT).

[0139] Network node 1000 includes processing circuitry 1002, memory 1004, communication interface 1006, and power supply 1008. Network node 1000 may consist of multiple physically separate components (e.g., NodeB components and RNC components, or BTS components and BSC components, etc.), each component may have its own corresponding components. In some scenarios where network node 1000 includes multiple individual components (e.g., BTS and BSC components), one or more individual components may be shared among several network nodes. For example, a single RNC can control multiple NodeBs. In such scenarios, each unique NodeB and RNC pair may be considered a single separate network node in some instances. In some embodiments, network node 1000 may be configured to support multiple Radio Access Technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 1004 for different RATs), and some components may be reused (e.g., the same antenna 1010 may be shared by different RATs). Network node 1000 may also include multiple sets of various illustrated components for integrating different wireless technologies into network node 1000, such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-Wave, LoRaWAN, radio frequency identification (RFID), or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chips or chipsets and other components within network node 1000.

[0140] The processing circuitry 1002 may include a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field-programmable gate array or any other suitable computing device or resource, or may include a combination of hardware, software and / or coding logic operable to provide network node 1000 functionality alone or in combination with other network node 1000 components (such as memory 1004).

[0141] In some embodiments, the processing circuitry 1002 includes a system-on-a-chip (SOC). In some embodiments, the processing circuitry 1002 includes one or more of a radio frequency (RF) transceiver circuitry 1012 and a baseband processing circuitry 1014. In some embodiments, the RF transceiver circuitry 1012 and the baseband processing circuitry 1014 may be on separate chips (or chipsets), boards, or units, such as radio units and digital units. In alternative embodiments, some or all of the RF transceiver circuitry 1012 and the baseband processing circuitry 1014 may be on the same chip or chipset, board, or unit.

[0142] Memory 1004 may include any form of volatile or non-volatile computer-readable memory, including but not limited to persistent storage devices, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drive, optical disc (CD), or digital video disc (DVD)) and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions usable by processing circuitry 1002. Memory 1004 may store any suitable instructions, data, or information, including computer programs, software, applications including one or more of logic, rules, codes, tables, and / or other instructions executable by processing circuitry 1002 and utilized by network node 1000. Memory 1004 may be used to store any calculations performed by processing circuitry 1002 and / or any data received via communication interface 1006. In some embodiments, processing circuitry 1002 and memory 1004 are integrated.

[0143] Communication interface 1006 is used for wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As shown, communication interface 1006 includes multiple ports / terminals 1016 for transmitting and receiving data to and from the network, for example, via a wired connection. Communication interface 1006 also includes radio front-end circuitry 1018, which may be coupled to antenna 1010 or, in some embodiments, is part of antenna 1010. Radio front-end circuitry 1018 includes filter 1020 and amplifier 1022. Radio front-end circuitry 1018 may be connected to antenna 1010 and processing circuitry 1002. Radio front-end circuitry 1018 may be configured to modulate the signal transmitted between antenna 1010 and processing circuitry 1002. Radio front-end circuitry 1018 may receive digital data to be transmitted to other network nodes or UEs via a wireless connection. Radio front-end circuitry 1018 may use a combination of filter 1020 and / or amplifier 1022 to convert the digital data into a radio signal with appropriate channel and bandwidth parameters. The radio signal may then be transmitted via antenna 1010. Similarly, when receiving data, antenna 1010 can collect radio signals, which are then converted into digital data by radio front-end circuitry 1018. The digital data can then be passed to processing circuitry 1002. In other embodiments, the communication interface may include different components and / or different combinations of components.

[0144] In some alternative embodiments, network node 1000 does not include a separate radio front-end circuitry 1018; instead, processing circuitry 1002 includes radio front-end circuitry and is connected to antenna 1010. Similarly, in some embodiments, all or some of the RF transceiver circuitry 1012 is part of communication interface 1006. In other embodiments, communication interface 1006 includes one or more ports or terminals 1016, radio front-end circuitry 1018, and RF transceiver circuitry 1012 as part of a radio unit (not shown), and communication interface 1006 communicates with baseband processing circuitry 1014, which is part of a digital unit (not shown).

[0145] Antenna 1010 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals. Antenna 1010 may be coupled to radio front-end circuitry 1018 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna 1010 is decoupled from network node 1000 and may be connected to network node 1000 via an interface or port.

[0146] Antenna 1010, communication interface 1006, and / or processing circuitry 1002 can be configured to perform any receive operation and / or certain acquire operation described herein as being performed by a network node. Any information, data, and / or signals can be received from the UE, another network node, and / or any other network device. Similarly, antenna 1010, communication interface 1006, and / or processing circuitry 1002 can be configured to perform any transmission operation described herein as being performed by a network node. Any information, data, and / or signals can be transmitted to the UE, another network node, and / or any other network device.

[0147] Power supply 1008 provides power to the various components of network node 1000 in a form suitable for the respective components (e.g., with the voltage and current levels required for each respective component). Power supply 1008 may also include or be coupled to power management circuitry to supply power to the components of network node 1000 for performing the functions described herein. For example, network node 1000 may be connected to an external power source (e.g., the mains, a power outlet) via input circuitry or an interface such as a cable, thereby supplying power to the electrical circuitry of power supply 1008. As another example, power supply 1008 may include a power source in the form of a battery or battery pack, which is connected to or integrated into the electrical circuitry. The battery can provide backup power if the external power source fails.

[0148] Embodiments of network node 1000 may include, except Figure 10Additional components, other than those shown, are used to provide certain aspects of the functionality of the network node, including any functionality described herein and / or any functionality required to support the topics described herein. For example, network node 1000 may include a user interface device to allow information to be input into and output from network node 1000. This allows users to perform diagnostic, maintenance, repair, and other management functions for network node 1000. In providing core network nodes (such as...) Figure 8 In some embodiments of the core network node 108, some components, such as the radio front-end circuit 1018 and the RF transceiver circuit 1012, may be omitted.

[0149] Figure 11 This is a block diagram illustrating a virtualized environment 1100 in which functionality implemented by some embodiments can be virtualized. In this context, virtualization means creating virtual versions of devices or equipment, which may include virtualized hardware platforms, storage devices, and network resources. As used herein, virtualization can be applied to any device or component thereof described herein, and involves at least a portion of its functionality being implemented as an implementation of one or more virtual components. Some or all of the functionality described herein can be implemented as virtual components executed by one or more virtual machines (VMs) in one or more virtual environments 1100 hosted by one or more hardware nodes, such as hardware computing devices operating as network nodes, UEs, core network nodes, or hosts. Furthermore, in embodiments where virtual nodes do not require radio connectivity (e.g., core network nodes or hosts), the nodes can be fully virtualized. In some embodiments, the virtualized environment 1100 includes components defined by the O-RAN Alliance, such as an O-cloud environment orchestrated via an O-2 interface by a service management and orchestration framework. Virtualization can facilitate the distributed implementation of network nodes, UEs, core network nodes, or hosts.

[0150] Application 1102 (which may alternatively be referred to as a software instance, virtual device, network function, virtual node, virtual network function, etc.) runs in virtualization environment 1100 to implement some of the features, functions, and / or benefits of some embodiments disclosed herein.

[0151] Hardware 1104 includes processing circuitry, memory storing software and / or instructions executable by the hardware processing circuitry, and / or other hardware devices as described herein, such as network interfaces, input / output interfaces, etc. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1106 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1108a and 1108b (one or more of which may generally be referred to as VM 1108), and / or perform any functionality, features, and / or benefits described with respect to some embodiments described herein. Virtualization layer 1106 may present a virtual operating platform to VM 1108 that appears to be networked hardware.

[0152] VM 1108 includes virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and can be run by a corresponding virtualization layer 1106. Different embodiments of instances of virtual appliance 1102 can be implemented on one or more VMs 1108, and can be implemented in different ways. Hardware virtualization is referred to in some contexts as Network Functions Virtualization (NFV). NFV can be used to consolidate many types of network devices onto industry-standard high-capacity server hardware, physical switches, and physical storage devices, which can reside in data centers and customer premises.

[0153] In the context of NFV, VM 1108 can be a software implementation of the physical machine running the program as if it were running on a physical, non-virtualized machine. Each of VM 1108 and the portion of the hardware 1104 that executes the VM (whether dedicated to that VM and / or shared by that VM with other VMs within it) form a separate virtual network element. Still within the context of NFV, the virtual network function is responsible for handling the specific network function running on one or more VMs 1108 above hardware 1104 and corresponding to application 1102.

[0154] Hardware 1104 can be implemented in a standalone network node with general or specific components. Hardware 1104 may implement some functions via virtualization. Alternatively, hardware 1104 may be part of a larger hardware cluster (e.g., such as in a data center or CPE), where many hardware nodes work together and are managed via management and orchestration 1110, which in particular oversees the lifecycle management of application 1102. In some embodiments, hardware 1104 is coupled to one or more radio units, each radio unit including one or more transmitters and one or more receivers that can be coupled to one or more antennas. The radio units can communicate directly with other hardware nodes via one or more suitable network interfaces and can be used in conjunction with virtual components to provide radio capabilities to virtual nodes (such as radio access nodes or base stations). In some embodiments, a control system 1112 may be used to provide some signaling, and the control system 1112 may alternatively be used for communication between hardware nodes and radio units.

[0155] While the computing devices (e.g., UE, network node) described herein may include combinations of the hardware components shown, other embodiments may include computing devices with different combinations of components. It should be understood that these computing devices may include any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determination, calculation, acquisition, or similar operations described herein may be performed by processing circuitry that processes information by, for example, converting acquired information into other information, comparing the acquired or converted information with information stored in the network node, and / or performing one or more operations based on the acquired or converted information, and making a determined result as a result of said processing. Furthermore, although components are depicted as single boxes located within larger boxes or nested within multiple boxes, in practice, a computing device may include multiple different physical components constituting a single illustrated component, and functionality may be partitioned between individual components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of a component may be partitioned between processing circuitry and the communication interface. In another example, the non-computationally intensive functions of any such component may be implemented in software or firmware, and the computationally intensive functions may be implemented in hardware.

[0156] In some embodiments, some or all of the functions described herein may be provided by processing circuitry that executes instructions stored in memory, which in some embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functions may be provided by processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, the processing circuitry may be configured to perform the described functions regardless of whether instructions stored on a non-transitory computer-readable storage medium are executed. The benefits provided by such functions are not limited to individual processing circuitry or other components of the computing device, but are enjoyed by the computing device as a whole and / or generally by end users and wireless networks.

Claims

1. A method (400A) at a terminal device (130), the method (400A) comprising: Initiate (410) handover without random access channel and without RACH; as well as Determine (420) the availability of at least one pre-allocated grant timing for uplink transmission, the at least one pre-allocated grant timing being configured for the RACH-free handover.

2. The method (400A) according to claim 1, further comprising: Based on the determination that a pre-allocation authorization opportunity is available in the at least one pre-allocation authorization opportunity, the uplink transmission is transmitted on the pre-allocation authorization opportunity in the at least one pre-allocation authorization opportunity.

3. The method (400A) according to claim 1 or 2, further comprising: Based on the determination that at least one pre-allocated authorization opportunity is unavailable, a RACH-based handover based on the random access channel is initiated.

4. The method (400A) according to any one of claims 1 to 3, wherein determining (420) the availability comprises: The availability of the pre-allocated authorization time is determined based on at least one measurement of at least one reference signal RS transmitted prior to the pre-allocated authorization time in at least one pre-allocated authorization time.

5. The method (400A) of claim 4, wherein the at least one measurement result includes at least one measurement result immediately preceding the pre-allocation authorization timing.

6. The method (400A) according to claim 4 or 5, wherein, The at least one measurement result includes available measurement results obtained before the pre-allocated authorization time, or The at least one measurement result was obtained during a time period prior to the pre-allocation authorization timing, the time period including: Scheduled time slot Schedule a time window, or The duration between the pre-allocation authorization timing and another pre-allocation authorization timing, the other pre-allocation authorization timing preceding the pre-allocation authorization timing.

7. The method (400A) according to claim 6, wherein, The additional pre-allocation authorization timing may be adjacent to or not adjacent to the pre-allocation authorization timing, or Both the pre-allocation authorization timing and the additional pre-allocation authorization timing are associated with an RS identifier or beam.

8. The method (400A) according to any one of claims 4 to 7, wherein determining the availability of the pre-allocation authorization timing comprises: The availability is determined based on at least one of the following, provided that the number of the at least one measurement result is greater than one: The latest of the at least one measurement result, The maximum measured value of the at least one measurement result, or The average measurement value of at least one measurement result; and / or The pre-allocation authorization timing is determined to be unavailable in response to at least one of the following: None of the at least one measurement result meets the quality condition, or One or more of the at least one measurement result failed to meet the quality condition; And / or The availability of the pre-allocation authorization timing is determined in response to at least one of the following: All of the at least one measurement result meets the quality condition, or One or more of the at least one measurement result satisfies the quality condition.

9. The method (400A) according to any one of claims 4 to 8, wherein the maximum value of the number of the at least one measurement result is predefined, configured by the network device, or set by the terminal device (130).

10. The method (400A) according to any one of claims 4 to 9, wherein determining the availability of the pre-allocation authorization timing comprises: Based on the determination that the number of available measurement results is less than or equal to the first threshold number, It has been determined that the pre-allocation authorization timing is unavailable; or The availability is determined based on the available measurement results. And the number of the first threshold is predefined, configured by the network device, or set by the terminal device (130).

11. The method (400A) of claim 10, wherein the availability is determined based on default rules or rules configured by the network device.

12. The method (400A) according to any one of claims 4 to 11, wherein determining the availability of the pre-allocation authorization timing comprises: The pre-allocation authorization timing is determined to be available based on the fact that the number of available measurement results is less than or equal to a first threshold number and the pre-allocation authorization timing is a pre-allocation authorization timing that immediately follows the initiation of the RACH-free switch.

13. The method (400A) according to any one of claims 1 to 12, further comprising: A RACH-based handover is initiated in response to one of the following: The pre-allocation authorization opportunity in at least one of the pre-allocation authorization opportunities is determined to be unavailable. If the number of consecutive pre-allocation authorization opportunities in the at least one pre-allocation authorization opportunity is greater than or equal to a second threshold number, the consecutive pre-allocation authorization opportunities are determined to be unavailable. All of the pre-allocated authorization opportunities in the set of at least one pre-allocated authorization opportunity are determined to be unavailable, or The number of consecutive pre-allocated authorization time sets of the at least one pre-allocated authorization time is greater than or equal to a third threshold number, wherein all of the pre-allocated authorization time sets in the consecutive pre-allocated authorization time sets are determined to be unavailable.

14. The method (400A) according to claim 13, wherein, Different pre-allocated authorization times included in the set of pre-allocated authorization times are associated with different reference signals, RS identifiers, or different beams.

15. The method (400A) according to any one of claims 1 to 14, wherein the terminal device (130) is located in a non-terrestrial network (NTN).

16. A method (400B) at a terminal device (130), the method comprising: Initiate a (460) handover without random access channel and without RACH; as well as It is determined that (470) the RACH-free handover is to be stopped and the RACH-based handover based on the random access channel is to be initiated.

17. The method of claim 16 (400B), further comprising: In response to the pre-allocated authorization timing configured for the RACH-free handover being determined to be available, the RACH-free handover can be continued or re-initiated. The pre-allocation authorization timing refers to the period before the available random access RA timing for the RACH-based handover, or The reference signal RS associated with the pre-allocated authorization timing is measured prior to the RA timing of the RACH-based switching.

18. The method (400B) according to claim 16 or 17, further comprising: A timer is started after the initiation or re-initiation of the RACH-free switch; as well as During the operation of the timer: Disable the initiation of the RACH-based handover, or The RACH-free handover can be continued or re-initiated based on at least one pre-allocated authorization timing configured for the RACH-free handover.

19. The method of claim 18 (400B), wherein determining that the RACH-based handover is to be initiated comprises: Based on the determination that the timer has expired and the RACH-free handover has not been completed, it is determined that the RACH-based handover should be initiated.

20. The method of claim 19 (400B), further comprising: The initiation of the RACH-based handover is disabled within a time window, which includes multiple reference signal RS measurement cycles.

21. The method of claim 19 (400B), further comprising: The counter is started after the initiation or re-initiation of the RACH-free switch; as well as Before the value of the counter exceeds the threshold: Disable the initiation of the RACH-based handover, or The RACH-free handover can be continued or re-initiated based on at least one pre-allocated authorization timing configured for the RACH-free handover.

22. The method of claim 21 (400B), wherein determining that the RACH-based handover is initiated comprises: Based on the determination that the value of the counter exceeds the threshold and the RACH-free handover has not been completed, it is determined that the RACH-based handover should be initiated.

23. The method (400B) according to any one of claims 16 to 22, wherein the RACH-free handover takes precedence over the RACH-based handover.

24. The method (400B) according to any one of claims 16 to 23, wherein determining that the RACH-based handover is to be initiated comprises: In response to the failure to transmit the handover completion message for the RACH-free handover, it is determined that the RACH-based handover is to be initiated.

25. The method of claim 24 (400B), further comprising: Based on the receipt of the negative acknowledgment of the handover completion message, it is determined that the transmission of the handover completion message failed.

26. The method (400B) according to any one of claims 16 to 25, further comprising: The RACH-based handover is disabled if a first quality level required for the RACH-free handover is determined to be lower than or equal to a second quality level required for the RACH-based handover.

27. The method (400B) according to any one of claims 16 to 26, further comprising: The RACH-based handover is disabled if a first set of reference signals RS associated with RACH-free handover and a second set of RS associated with RACH-based handover overlap at least partially.

28. The method (400B) according to any one of claims 16 to 27, further comprising: Initiate the RACH-based handover; as well as In response to the failure to transmit the handover completion message for the RACH-based handover, Disable the re-initiation of the RACH-free handover, or The RACH-free handover is re-initiated based on the fulfillment of at least one triggering condition for the RACH-free handover.

29. The method (400B) of claim 28, wherein the at least one triggering condition comprises at least one of the following: The conditions for RACH-based handover failure, The conditions under which the terminal device (130) is allowed to re-initiate a RACH-free handover are as follows: The measurement results configured for the pre-allocated authorization timing of the RACH-free handover meet the quality conditions of the RACH-free handover. Switch the condition for the timer not to expire, or The time alignment timer has not expired.

30. The method of claim 29 (400B), further comprising: Based on default rules or rules configured by the network device, determine whether the terminal device (130) is allowed to re-initiate the RACH-free handover.

31. The method (400B) according to claim 29 or 30, further comprising: After the RACH-free handover is re-initiated, uplink transmission is performed at the pre-allocated grant timing configured for the RACH-free handover, regardless of the measurement results of the reference signal RS measurement associated with the pre-allocated grant timing.

32. The method (400B) according to any one of claims 29 to 31, wherein, A first threshold for the reference signal RS measurement is configured to select a pre-allocation grant timing for the initial uplink transmission during the RACH-free handover, and a second threshold for the RS measurement is configured to select a pre-allocation grant timing for the retransmission uplink transmission during the RACH-free handover, wherein the first threshold is higher than the second threshold.

33. The method (400B) according to any one of claims 16 to 32, wherein the terminal device (130) is located in a non-terrestrial network (NTN).

34. A method (500) at a network device (110), the method (500) comprising: Transmit configuration information to the terminal device indicating at least one of the following: At least one pre-allocated grant opportunity for handover without random access channel and without RACH. The maximum value of the number of the at least one measurement result used to determine the availability of at least one pre-allocated authorization opportunity. The first threshold number indicates the number of at least one measurement result required to determine the availability of the at least one pre-allocated authorization timing. A second threshold number is used to determine that if the number of consecutive pre-allocated grant opportunities in the at least one pre-allocated grant opportunity is greater than or equal to the second threshold number, the handover transitions from RACH-free to RACH-based handover using a random access channel. In this case, the consecutive pre-allocated grant opportunities are determined to be unavailable. A third threshold number is set based on the condition that the number of consecutive pre-allocated grant opportunities in the at least one pre-allocated grant opportunity set is greater than or equal to the third threshold number, indicating a transition from RACH-free handover to RACH-based handover, wherein all pre-allocated grant opportunities in the consecutive pre-allocated grant opportunity set are determined to be unavailable. The rules used to determine the availability of the pre-allocated authorization timing, An indication of whether the terminal device is permitted to re-initiate a RACH-free handover, or A first threshold for measuring the reference signal RS, configured to select a pre-allocation grant timing for initial uplink transmissions during the RACH-free handover, and a second threshold for measuring the RS, configured to select a pre-allocation grant timing for retransmission uplink transmissions during the RACH-free handover, wherein the first threshold is higher than the second threshold.

35. A terminal device (600), comprising: Processor (605); as well as A memory (610) containing instructions (615) executable by the processor (615), thereby enabling the communication device (600) to operate as follows: Initiating (410) handover without random access channel and without RACH; and Determine the availability of at least one pre-allocated grant timing for uplink transmission, the at least one pre-allocated grant timing being configured for the RACH-free handover.

36. The terminal device (600) according to claim 35, wherein the communication device (600) further operates to implement the method (400A) according to any one of claims 2 to 15.

37. A terminal device (600), comprising: Processor (605); as well as A memory (610) containing instructions (615) executable by the processor (615), thereby enabling the communication device (600) to operate as follows: Initiate (460) handover without random access channel and without RACH; and Based at least on the condition that the condition is met, it is determined (470) that a handover based on the random access channel and RACH must be initiated.

38. The terminal device of claim 37, wherein the communication device is further operated to implement the method (400B) of any one of claims 16 to 33.

39. A network device (600), comprising: Processor (605); as well as A memory (610) containing instructions (615) executable by the processor (615), thereby enabling the communication device (600) to operate as follows: Transmit (510) configuration information to the terminal device indicating at least one of the following: At least one pre-allocated grant opportunity for handover without random access channel and without RACH. The maximum value of the number of the at least one measurement result used to determine the availability of at least one pre-allocated authorization opportunity. The first threshold number indicates the number of the at least one measurement result required to determine the availability of at least one pre-allocated authorization timing. A second threshold number is used to determine that if the number of consecutive pre-allocated grant opportunities in the at least one pre-allocated grant opportunity is greater than or equal to the second threshold number, the handover transitions from RACH-free to RACH-based handover using a random access channel. In this case, the consecutive pre-allocated grant opportunities are determined to be unavailable. A third threshold number is set based on the condition that the number of consecutive pre-allocated grant opportunities in the at least one pre-allocated grant opportunity set is greater than or equal to the third threshold number, indicating a transition from RACH-free handover to RACH-based handover, wherein all pre-allocated grant opportunities in the consecutive pre-allocated grant opportunity set are determined to be unavailable. The rules used to determine the availability of the pre-allocated authorization timing, An indication of whether the terminal device is permitted to re-initiate a RACH-free handover. A time window comprising multiple reference signal (RS) measurement periods, during which RACH-based switching is disabled, or A first threshold for reference signal (RS) measurement, configured to select a pre-allocation grant timing for initial uplink transmissions during the RACH-free handover, and a second threshold for RS measurement, configured to select a pre-allocation grant timing for retransmission uplink transmissions during the RACH-free handover, wherein the first threshold is higher than the second threshold.

40. A computer-readable storage medium (700) having instructions (615) stored thereon, the instructions (615) causing the device to perform the method (400A) according to any one of claims 1 to 15, the method (400B) according to any one of claims 16 to 33, or the method (500) according to claim 34 when executed by at least one processor of the device.

Images