Methods, devices and medium for handover

Abstract

Embodiments of the present disclosure relate to methods, devices and computer readable storage medium for handover. In a method, the terminal device initiates a random access channel-less (RACH-less) handover; and determines usability of at least one pre-allocated grant occasion for an uplink transmission, the at least one pre-allocated grant occasion being configured for the RACH-less handover.

Description

METHODS, DEVICES AND MEDIUM FOR HANDOVER

[0001] FIELDS

[0002] Various embodiments of the present disclosure generally relate to the field of telecommunication and in particular, to methods, devices and computer readable storage medium for handover.BACKGROUND

[0003] There is an ongoing resurgence of satellite communications. Several plans for satellite networks have been announced in the past few years. Target services vary from backhaul and fixed wireless to transportation, to outdoor mobile, and / or to Internet of Things (IoT) . Satellite networks may complement mobile networks on the ground by providing connectivity to underserved areas and multicast / broadcast services. To benefit from mobile ecosystem and economy of scale, adaption of terrestrial wireless access technologies including Long Term Evolution (LTE) and New Radio (NR) for satellite networks is a growing concern, which has been reflected in the third-generation partnership project (3GPP) standardization work. In 3GPP release 15, the work to prepare NR for operation in a Non-Terrestrial Network (NTN) is started. The work was performed within the study item "NR to support Non-Terrestrial Networks" and resulted in 3GPP Technical Report (TR) 38.811, version 15.4.0. In 3GPP release 16, the work to prepare NR for operation in an NTN network continued with the study item "Solutions for NR to support Non-Terrestrial Network" , which has been captured in 3GPP TR 38.821, version 16.2.0. In parallel, the interest to adapt Narrowband Internet of Things (NB-IoT) and LTE-Machine-to-Machine (LTE-M) for operation in NTN is growing. As a consequence, 3GPP release 17 contains both a work item on NR NTN and a study item and work item on NB-IoT and LTE-M support for NTN. In the work on 3GPP release 18, there is a topic related to enhancements of NTN-NTN mobility, particularly random access channel-less (RACH-less) conditional handover.SUMMARY

[0004] As described above, RACH-less HO can be supported in an NTN in Rel-18. RACH-less HO is introduced for LTE. Furthermore, it has been agreed that during the RACH-less HO, the pre-allocated grant is provided with association to SSBs. User equipment (UE) selects a Synchronization Signal Block (SSB) associated to the pre-allocated grant with Reference Signal Received Power (RSRP) above a configured threshold, and then uses the selected SSB and the corresponding pre-allocated grant occasions for the initial uplink (UL) transmission of RRCReconfigurationComplete. If no SSB mapping to pre-allocated grant has RSRP above the threshold, fallback to RACH based HO (with new SSB selection) , while the  handover supervision timer, timer T304 (henceforth for convenience also referred to as just “T304” ) is running. As for handling of the pre-allocated UL grants with association to SSBs, the current agreement has ambiguity at least in the following aspects: How the UE determines that the no SSB mapping to a pre-allocated grant has an RSRP above the threshold (i.e. the condition for fallback to RACH based HO) ; Whether / when the UE shall / could return to (attempting to use) pre-allocated UL grants after fallback to RACH based HO; How to set the RSRP threshold.

[0005] To overcome or mitigate at least one of the above-mentioned problems or other problems or provide a useful solution, embodiments of the present disclosure propose methods, devices and storage medium for handover.

[0006] In a first aspect of the present disclosure, there is provided a method implemented at a terminal device. In the method, the terminal device initiates a RACH-less handover; and determines usability of at least one pre-allocated grant occasion for an uplink transmission, the at least one pre-allocated grant occasion being configured for the RACH-less handover.

[0007] In a second aspect of the present disclosure, there is provided a method implemented at a terminal device. In the method, the terminal device initiates a RACH-less handover; and determines that the RACH-less handover is to be ceased and a RACH-based handover is to be initiated.

[0008] In a third aspect of the present disclosure, there is provided a method implemented at a network device. In the method, the network device transmits, to a terminal device, configuration information indicating at least one of the following: at least one pre-allocated grant occasion for RACH-less handover, a maximum of the number of the at least one measurement result used for determining usability of at least one pre-allocated grant occasion, a first threshold number indicating a number of the at least one measurement result required for determining the usability of at least one pre-allocated grant occasion, a second threshold number, based on a determination of the number of continuous pre-allocated grant occasions of the at least one pre-allocated grant occasion being greater than or equal to a second threshold number, switching from a RACH-less handover to a RACH-based handover, the continuous pre-allocated grant occasions being determined to be unusable, a third threshold number, based on a determination of the number of continuous sets of pre-allocated grant occasions of the at least one pre-allocated grant occasion being greater than or equal to a third threshold number, switching from a RACH-less handover to a RACH-based handover, where all of the pre-allocated grant occasions in the continuous sets of pre-allocated grant occasions are determined to be unusable, a rule for determining the usability of the pre-allocated grant occasion, an indication indicating whether the terminal device is allowed to  re-initiate a RACH-less handover, a time window comprising a plurality of RS measurement periodicities, RACH-based handover being disabled within the time window, a first threshold for a RS measurement configured for selecting a pre-allocated grant occasion for an initial uplink transmission during the RACH-less handover, a second threshold for the RS measurement configured for selecting a pre-allocated grant occasion for a re-transmission uplink transmission during the RACH-less handover, the first threshold being higher than the second threshold.

[0009] In a fourth aspect of the present disclosure, there is provided a terminal device. The terminal device comprises a processor and a memory coupled to the processor, the memory containing instructions executable by the processor, whereby the terminal device is operative to perform the method according to the first or second aspect.

[0010] In a fifth aspect of the present disclosure, there is provided a network device. The terminal device comprises a processor and a memory coupled to the processor, the memory containing instructions executable by the processor, whereby the terminal device is operative to perform the method according to the third aspect.

[0011] In a sixth aspect of the present disclosure, there is provided an apparatus. The apparatus comprises means for performing the method according to the first or second or third aspect.

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

[0013] With the present disclosure, a terminal device may determine whether and / or how to perform a RACH-less or a RACH-based handover properly. As a result, a possibility of interruption caused by handover may be minimized.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] FIG. 1 is a diagram showing an example communication environment in which embodiments of the present disclosure can be implemented.

[0015] FIGS. 2A and 2B are diagrams showing example blocks of multiple SSB measurements between two pre-allocated grant occasion according to some embodiments.

[0016] FIG. 3 is a diagram showing an example block of not fallback to RACH based HO according to some embodiments.

[0017] FIG. 4A, FIG. 4B and FIG. 5 are block diagrams showing flowcharts of example handover methods according to some embodiments.

[0018] FIG. 6 is a block diagram showing a communication device according to some  embodiments.

[0019] FIG. 7 is a block diagram showing a computer readable storage medium according to some embodiments.

[0020] FIG. 8 is a block diagram showing an example of a communication system according to some embodiments.

[0021] FIG. 9 is a block diagram showing a UE according to some embodiments.

[0022] FIG. 10 is a block diagram showing a network node according to some embodiments.

[0023] FIG. 11 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized.DETAILED DESCRIPTION

[0024] As used herein, the terms "first" , "second" and so forth refer to different elements. The singular forms "a" and "an" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms "comprises" , "comprising" , "has" , "having" , "includes" and / or "including" as used herein, specify the presence of stated features, elements, and / or components and the like, but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof. The term "based on" is to be read as "based at least in part on" . The term "one embodiment" and "an embodiment" are to be read as "at least one embodiment" . The term "another embodiment" is to be read as "at least one other embodiment" . Other definitions, explicit and implicit, may be included below.

[0025] In the context of the present disclosure, the terms “beam” and “cell” may be used interchangeably. For Quasi-Earth-fixed beams / cells or earth-moving beams / cells, when the satellite serving the area is changed (which is referred to as satellite switch) , all user equipment (UEs) connected in an old cell need to be moved to a new cell. It is agreed to support RACH-less handover (HO) for an NTN in release 18 (Rel-18) .

[0026] In the work on 3GPP release 18, there is a topic related to enhancements of NTN-NTN mobility, particularly RACH-less conditional handover. A satellite radio access network includes the following components: a satellite that refers to a space-borne platform; an earth-based gateway (GW) that connects the satellite to a base station or a core network, depending on the choice of architecture; a feeder link that refers to the link between a gateway and a satellite; and an access link, or service link, that refers to the link between a satellite and a UE.

[0027] A communication satellite generates several beams over a given area. The footprint of a beam is usually in an elliptic shape, which has been traditionally considered as a cell  (but a cell consisting of multiple beams is not precluded) . The footprint of a beam is also often referred to as a spotbeam.

[0028] Three types of beams or cells are supported in NTNs. One type is Earth-fixed beams / cells, which are provisioned by beam (s) continuously covering the same geographical areas all the time, e.g., in the case of Geostationary Earth Orbit (GEO) satellites. Another type is Quasi-Earth-fixed beams / cells which are provisioned by beam (s) covering one geographic area for a limited period and a different geographic area during another period, e.g., in the case of Non-geostationary orbit (NGSO) satellites generating steerable beams. A further type is Earth-moving beams / cells, which are provisioned by beam (s) whose coverage area slides over the earth surface, e.g., in the case of NGSO satellites generating fixed or non-steerable beams. Throughout this present disclosure, the terms “beam” and “cell” are used interchangeably, unless explicitly noted otherwise.

[0029] With Quasi-Earth-fixed beams / cells or earth-moving beams / cells, when the satellite serving the area is changed (which is referred to as satellite switch) , all UEs connected in the old cell, e.g., UEs in Radio Resource Control (RRC) _CONNECTED state, have to be handed over (or otherwise moved, e.g. using RRC connection reestablishment) from the old cell to the new cell, and all UEs camping on the old cell, e.g., UEs in RRC_IDLE or RRC_INACTIVE state, have to perform cell reselection to the new cell. A consequence of a satellite switch is that both the service 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 switches, i.e., when the serving satellite remains the same, but its connection to the ground changes from one (old) GW / gNB to another (new) GW / gNB. Also, in this case, there is switch between an old cell and a new cell (i.e., the old cell is replaced by a new cell) . Satellite switches and feeder link switches can both be referred to as an umbrella term "cell switch" .

[0030] Due to the special operating conditions in a Non-Terrestrial Network, the system information broadcasted in an NTN cell includes NTN-specific information. For this purpose, a new System Information Block (SIB) (e.g. SIB19) is introduced in NR NTN which contains NTN-specific information. In IoT NTN, the new SIB31 may correspond to SIB19 in NR NTN. In 3GPP Technical Specification (TS) 38.331, version 17.4.0, SIB19 is defined as follows in Abstract Syntax Notation One (ASN. 1) code:

[0031] SIB19 field descriptions are shown in Table 1.

[0032] Table 1

[0033] NR introduced support of conditional handover (CHO) . A CHO is a handover that is executed by the UE when one or more conditional handover execution conditions are met. Such an execution condition is referred to as a CondEvent. The UE starts evaluating the execution condition (s) upon receiving the CHO configuration and stops evaluating the execution condition (s) once a handover is executed (i.e., applying a stored configuration for a target cell) . The CHO configuration contains the configuration of CHO candidate cell (s) generated by the candidate gNB (s) and execution condition (s) generated by the source gNB.

[0034] For a Terrestrial Network (TN) , the execution condition may comprise one or two trigger condition (s) (i.e., CondEvent (s) ) which may be A3 (Neighbor becomes offset better than SpCell) and / or A5 (SpCell becomes worse than threshold1 and neighbor becomes better than threshold2) , as defined in 38.331 version 17.4.0. For NTN, the execution condition may comprise one trigger condition which may be CondEvent A3 or A5 and another trigger condition which may be CondEvent D1 (Distance between UE and referenceLocation1 is  above threshold1 and distance between UE and referenceLocation2 is below threshold2) or CondEvent T1 (Time measured at UE is within a duration from a threshold) , as defined in 38.331 version 17.4.0. CondEvent D1 is used for location based CHO triggering in case of satellite switch with Earth-moving beams / cells. The referenceLocation1 is associated to a serving cell and referenceLocation2 is associated to a candidate target cell. CondEvent T1 is used for time based CHO triggering in case of feeder link switch or satellite switch with Quasi-Earth-fixed beams / cells. The threshold is often denoted T1 while the threshold plus the duration is often denoted T2. Time based CHO can only be triggered when CondEvent T1 is satisfied, i.e., time measured at a UE is between T1 and T2.

[0035] LTE introduced support of RACH-less handover (HO) . If RACH-less HO is configured (i.e., rach-Skip is configured according to the received RRCConnectionReconfiguration message) , the UE accesses the target cell via the pre-allocated uplink grant if the pre-allocated uplink grant is configured to the UE in rach-Skip, otherwise the UE monitors a Physical Downlink Control Channel (PDCCH) of the target cell to access the target cell via dynamic uplink grant. rach-Skip also indicates timing advance (TA) information of the target cell (i.e., targetTA) which the UE will apply when accessing the target cell using the pre-allocated or dynamic grant.

[0036] 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-less HO for NTN in release 18 (Rel-18) . Both dynamic grant and pre-allocated grant are supported for initial UL transmission of RRCReconfigurationComplete in the target cell. The RACH-less HO is completed upon receiving a network (NW) confirmation, e.g., the UE Contention Resolution Identity Medium Access Control (MAC) Control Element (CE) . RAN2 assumes that the UL sync handling in the target cell is the same in RACH-based HO and RACH-less HO, i.e., the UE itself pre-compensates the TA to be applied when accessing the target cell, and synchronization among source and target cells is not an issue in NTN RACH-less HO. Besides, in RAN2#121, it also was agreed that combining RACH-less HO with time-based CHO can be considered for NTN.

[0037] As described above, RACH-less HO can be supported in an NTN in Rel-18. RACH-less HO is introduced for LTE. Furthermore, it has been agreed that during the RACH-less HO, the pre-allocated grant is provided with association to SSBs. A UE selects a SSB associated to the pre-allocated grant with RSRP above a configured threshold, and then uses the selected SSB and the corresponding pre-allocated grant occasions for the initial uplink (UL) transmission of RRCReconfigurationComplete. If no SSB mapping to pre-allocated grant has RSRP above the threshold, fallback to RACH based HO (with new SSB selection) ,  while the handover supervision timer, timer T304 (henceforth for convenience also referred to as just “T304” ) is running. As for handling of the pre-allocated UL grants with association to SSBs, the current agreement has ambiguity at least in the following aspects: how the UE determines that the no SSB mapping to a pre-allocated grant has an RSRP above the threshold (i.e. the condition for fallback to RACH based HO) ; whether / when the UE shall / could return to (attempting to use) pre-allocated UL grants after fallback to RACH based HO; and how to set the RSRP threshold.

[0038] To overcome or mitigate at least one of the above-mentioned problems or other problems or provide a useful solution, embodiments of the present disclosure propose methods, devices and storage medium for handover. It is to be noted that although the issue is originating from NTN, the proposed scheme herein may be applied in general for various networks and scenarios. In the following, some example embodiments will be described using an NTN as an example scenario while the example embodiments herein can be applied in general for other networks and scenarios.

[0039] FIG. 1 illustrates an example communication environment 100 in which embodiments of the present disclosure can be implemented. As shown in FIG. 1, the communication environment 100 comprises a network device 110 such as a gNB which can provide services to a coverage area 115 together with a plurality of satellites including a first satellite 120 and a second satellite 125. The satellites 120 and 125 can be connected to the network device 110 via a gateway 127. The satellite 120 or 125 may generate several beams over a given area to provide an access network to a terminal device 130 such as a UE. The footprint of a beam is in an elliptic shape, which is referred to as a cell. It is also possible that a cell comprises a plurality of beams. Communications in the communication environment 100 may utilize any suitable communication technologies and follow any suitable communication protocols and standards. The scope of the present disclosure will not be limited in this regard.

[0040] It is to be understood that the deployment of devices and the numbers of devices are shown in FIG. 1 only for the purpose of illustration, without suggesting any limitations. The communication environment 100 may comprise more terminal devices, network nodes, satellites and gateways. Moreover, the communication environment 100 may comprise any other devices. It is also to be understood that an NTN scenario and an NTN cell as shown in FIG. 1 are only illustrative, but not limited. Various embodiments of the present disclosure can also be applied in a TN scenario and a TN cell.

[0041] In the communication environment 100, as the satellites 120 and 125 moves, the satellites 120 and 125 serving the coverage area 115 is changed. As shown in FIG. 1,  originally, the first satellite 120 serves the coverage area 115 by a cell. 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 case, all terminal devices including the terminal device 130, which are connected to the source cell provided by the first satellite 120 needs to be handed over to a target cell provided by the second satellite 125. The network device 110 may indicate to the terminal device 130 when to perform the handover and how to perform synchronization and have access to the target cell.

[0042] It is to be understood that the operations at the terminal device and the network device should be coordinated. In other words, the network device and the terminal device should have common understanding about configurations, parameters and so on. Such common understanding may be implemented by any suitable interactions between the network device and the terminal device or both the network device and the terminal device applying the same rule / policy. In the following, although some operations are described from a perspective of the terminal device, it is to be understood that the corresponding operations should be performed by the network device. Similarly, although some operations are described from a perspective of the network device, it is to be understood that the corresponding operations should be performed by the terminal device. Merely for brevity, some of the same or similar contents are omitted here.

[0043] Some embodiments of the present disclosure propose solutions to properly handle pre-allocated grants with association to SSBs during RACH-less handover. These mechanisms may provide some details related to fallback to RACH based handover, such as whether / when a UE (as an example of the terminal device 130) may return to RACH-less handover after fallback to RACH based handover, and setting of the RSRP threshold used in determining the fallback.

[0044] In some embodiments, a UE may determine usability of a pre-allocated grant occasion based on the latest one or multiple measured SSB bursts, where the UE may only consider the SSB measured since the last pre-allocated grant occasion. Usability of a pre-allocated grant occasion may be determined when none or no sufficient SSB bursts have been measured.

[0045] A UE may fall back to RACH based HO when: one pre-allocated grant occasion is (determined to be) not usable, or multiple consecutive pre-allocated grant occasions are (determined to be) not usable, or a SSB measurement timer expires, or a SSB measurement counter reaches a certain value, or fails to send the Handover Complete command using pre-allocated grant. A UE may revert its decision to fall back to RACH based HO when: a pre-allocated grant occasion is (determined to be) usable before the available RA occasion, or a  pre-allocated grant occasion is (determined to be) usable when measuring SSBs to select SSB for random access preamble transmission.

[0046] Once fallback to RACH based HO, the UE may perform any of the followings: not reverting to RACH-less HO, or reverting to RACH-less HO if access to target cell is not successful while an (unused) pre-allocated grant is usable and T304 is still running. Alternatively, or in addition, the UE may have made the maximum allowed number of RA attempts without success and T304 is still running. Different RSRP thresholds may be configured depending on whether the pre-allocated grant occasion is used for the first transmission or retransmission of the Handover Complete message. Different ways may be used to configure the RSRP thresholds in RRC.

[0047] With the proposed solutions, a UE may have no ambiguity in whether / when fallback to RACH based handover should be performed. Besides, by allowing a UE to return to RACH-less handover when appropriate after the fallback, the benefit of RACH-less handover can be maximized. A proper setting of the RSRP threshold used in determining the fallback can further exploit the benefit of pre-allocated grant. It is to be understood that the disclosed methods and solutions referring to the NR Radio Access Technology (RAT) can also be applied to LTE RAT and any other RAT enabling the direct transmission between two (or more) nearby devices without any loss of meaning.

[0048] It is to be noted that the term “NTN” may, depending on the context, refer to either or both of NR NTN and IoT NTN, but mostly the term is used to refer to only NR NTN. The embodiments outlined below are described mainly in terms of NR based NTNs, but they are also equally applicable in an NTN based on LTE technology (and in particular IoT NTN) .

[0049] It is to be noted that the term “network” is used to refer to a network node or network device, which may be a RAN node, such as a gNB (e.g. in a NR based NTN) or an eNB (e.g. in an LTE based NTN, such as an IoT NTN) , but which may also be a base station or an access point in another type of network, or any other network node with the ability to directly or indirectly communicate with a UE. Refinements with finer granularity are also conceivable. For instance, a gNB may be an en-gNB, and if a split gNB architecture is applied (dividing the gNB into multiple separate entities or notes) , the term “node” may refer to a part of the gNB, such as a gNB-CU (often referred to as just CU) , a gNB-DU (often referred to as just DU) , a gNB-CU-CP (control plane) or a gNB-CU-UP (user plane) . Similarly, an eNB may be an ng-eNB, and if a split eNB architecture is applied (dividing the eNB into multiple separate entities or notes) , the term “network” (and the network node it implies) may refer to a part of the eNB, such as an eNB-CU, an eNB-DU, an eNB-CU-CP or an eNB-CU-UP. Furthermore, the term “network” (and the network node it implies) may also refer  to an IAB-donor, IAB-donor-CU, IAB-donor-DU, IAB-donor-CU-CP, or an IAB-donor-CU-UP.

[0050] Herein, the terms “source node” , “target node” and “candidate target node” may sometimes be used. The “node” in these terms should be understood as typically being a RAN node in an NTN 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 an IoT NTN) , such a RAN node may be assumed to be an eNB. Alternatives to, or refinements of, these interpretations are however also conceivable. For instance, a gNB may be an en-gNB, and if a split gNB architecture is applied (dividing the gNB into multiple separate entities or notes) , the term “node” may refer to a part of the gNB, such as a gNB-CU (often referred to as just CU) , a gNB-DU (often referred to as just DU) , a gNB-CU-CP or a gNB-CU-UP. Similarly, an eNB may be an ng-eNB, and if a split eNB architecture is applied (dividing the eNB into multiple separate entities or notes) , the term “node” may refer to a part of the eNB, such as an eNB-CU, an eNB-DU, an eNB-CU-CP or an eNB-CU-UP. Furthermore, the “node” in the terms may also refer to an IAB-donor, IAB-donor-CU, IAB-donor-DU, IAB-donor-CU-CP, or an IAB-donor-CU-UP.

[0051] The terms “Handover Command” and “HandoverCommand” are used interchangeably herein. Both terms refer to a UE configuration the target node (of a regular handover) or candidate target node (of a conditional handover) , during the (conditional) handover preparation phase, compiles for the UE to be subject to the handover or conditional handover. This UE configuration is compiled in the form of an RRCReconfiguration message which is conveyed to the UE via the source node. The RRCReconfiguration is associated with a certain target cell or candidate target cell and the UE applies the RRCReconfiguration when / if it accesses the concerned (candidate) target cell controlled by the (candidate) target node. Formally, “HandoverCommand” is an RRC inter-node message which is conveyed from a target node or a candidate target node to a source node during the preparation of a handover or a conditional handover. It is carried by the HANDOVER REQUEST ACKNOWLEDGE Xn Application Protocol (XnAP) in the Target NG-RAN node To Source NG-RAN node Transparent Container IE. The “HandoverCommand” RRC inter-node message contains an RRCReconfiguration the UE should apply when accessing the target cell or candidate target cell. The source node forwards this RRCReconfiguration (i.e. the HandoverCommand) to the UE. In this solution description, the term “HandoverCommand” is also used to denote this RRCReconfiguration when it is stored in a UE as a part of a CHO configuration. This is also called the condRRCReconfig-r16 IE in the  CondReconfigToAddMod-r16 IE (which contains the CHO configuration) in the CondReconfigToAddModList-r16 IE in the ConditionalReconfiguration-r16 IE. In the context of CHO, the terms “Conditional Handover Command” , “ (Conditional) Handover Command” and “ (conditional) Handover Command” may also be used.

[0052] When CHO is configured for a UE, a cell which the UE potentially can connect to (i.e., if the CHO execution condition is fulfilled for the cell) is denoted as “candidate target cell” . Similarly, a RAN node controlling a candidate target cell is denoted as “candidate target node” or, in NR and NR NTN, “candidate target gNB” . However, once the UE has detected a fulfilled CHO execution condition for a candidate target cell, this terminology becomes a bit blurred. At this point, during the actual execution of the CHO and when the UE has connected to the new cell, the concerned cell may be referred to as either a “candidate target cell” or a “target cell” . Similarly, a RAN node controlling such a cell, may in this situation be referred to as either a “candidate target node” (or “candidate target gNB” ) or a “target node” (or a “target gNB” ) .

[0053] A condition included in a CHO configuration governing the execution of the conditionally configured procedure may be referred to as a CHO execution condition, a HO execution condition, a CHO trigger condition, a HO trigger condition or sometimes just a trigger condition. Furthermore, phases of the procedure may be referred to as the Handover Preparation phase, the Handover Execution and / or the Handover Completion phase, or may be referred to as the Conditional Handover Preparation phase (or the (conditional) Handover Preparation phase) , the Conditional Handover Execution phase and / or the Conditional Handover Completion phase.

[0054] The target cell configuration (the RRCReconfiguration for the UE to use in the candidate target cell) and the CHO execution condition for each candidate target cell provided by the network to the UE may collectively be referred to as a CHO configuration, or, alternatively, each combination of candidate target cell, target cell configuration and CHO execution condition may be referred to as a CHO configuration (i.e., the terminology is not consistent) .

[0055] When writing message names of a communication protocol, two equivalent principles are used in this document. The writing principle “<protocol name> <message name> message” , for example “XnAP HANDOVER CANCEL message” , and the writing principle “<message name> <protocol name> message” , for example “HANDOVER CANCEL XnAP message” are equivalent, both referring to a message (i.e., “<message name>” ) of a communication protocol (i.e., “<protocol name>” ) , e.g., the HANDOVER CANCEL message of the communication protocol XnAP. The same writing format  equivalence applies to other communication protocols, such as NG application protocol (NGAP) . NG is an interface between a network generation-random access network (NG-RAN) and a fifth generation core (5GC) .

[0056] When accessing a target cell during a HO or a CHO, the first message the UE sends to the target node in the target cell, after having sent a random access preamble and having received a Random Access Response message, is an RRCReconfigurationComplete message, indicating the successful completion of the HO or CHO. It should be noted that this RRCReconfigurationComplete message is often referred to as a Handover Complete message.

[0057] According to 3GPP agreements, as well as 3GPP TS 38.331 version 17.4.0, a time-based CHO execution condition will always be combined with a signal strength / quality CHO execution condition (both of which have to be fulfilled to trigger CHO execution) . However, all the embodiments in the proposed solution which do not assume that the UE monitors a signal strength / quality condition (i.e., an A3, A4 or A5 event) , are equally applicable if the UE is configured only with a time-based CHO execution condition. (Note that in embodiments describing lack of trigger of the CHO execution within the time window (i.e., between T1 and T2) assume that a signal strength / quality condition is configured but not fulfilled between T1 and T2) .

[0058] Herein, the terms “source node” , “target node” and “candidate target node” may be used. The “node” in these terms should be understood as typically being a RAN node in a NTN 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 an IoT NTN) , such a RAN node may be assumed to be an eNB. Alternatives to, or refinements of, these interpretations are however also conceivable. For instance, a gNB may be an en-gNB, and if a split gNB architecture is applied (dividing the gNB into multiple separate entities or notes) , the term “node” may refer to a part of the gNB, such as a gNB-CU (often referred to as just CU) , a gNB-DU (often referred to as just DU) , a gNB-CU-CP or a gNB-CU-UP. Similarly, an eNB may be an ng-eNB, and if a split eNB architecture is applied (dividing the gNB into multiple separate entities or notes) , the term “node” may refer to a part of the eNB, such as an eNB-CU, an eNB-DU, an eNB-CU-CP or an eNB-CU-UP. Furthermore, the “node” in the terms may also refer to an IAB-donor, IAB-donor-CU, IAB-donor-DU, IAB-donor-CU-CP, or an IAB-donor-CU-UP.

[0059] The embodiments are described in terms of normal handover (HO) , in particular RACH-less handover, but it is equally applicable to other RACH-less mobility procedures, e.g. RACH-less conditional handover, RACH-less conditional primary secondary cell (PSCell)  change (e.g. a dual connectivity scenario with a primary cell (PCell) in a terrestrial network and PSCell in a Non-Terrestrial Network) , or RACH-less conditional layer 1 (L1)  / layer 2 (L2) mobility procedures (e.g. time-based L1 / L2 mobility procedures) .

[0060] Some embodiments involve (RACH-less) handover procedures which primarily are described as Xn based handovers, i.e. inter-gNB (RACH-less) HOs where a Xn interface is established between the gNBs and the XnAP messages HANDOVER REQUEST and HANDOVER REQUEST ACKNOWLEDGE are used during the preparation of a (RACH-less) HO. However, the solution is also applicable when the (RACH-less) HO is prepared between gNBs which lack an established Xn interface, in which case the (RACH-less) HO preparation signaling is conveyed via the core network using NGAP messages (and possibly a protocol for messaging between two AMFs in the core network) . In this case, the HANDOVER REQUEST XnAP message is replaced by the HANDOVER REQUIRED NGAP message and the HANDOVER REQUEST NGAP message, where the HANDOVER REQUIRED NGAP message is sent from the source gNB to the core network and the core network sends the relevant information further to the target gNB in a HANDOVER REQUEST NGAP message. Similarly, the HANDOVER REQEUST ACKNOWLEDGE XnAP message is replaced by the HANDOVER REQUEST ACKNOWLEDGE NGAP message and the HANDOVER COMMAND NGAP message, where the HANDOVER REQUEST ACKNOWLEDGE NGAP message is sent from the target gNB to the core network and the core network sends the relevant information further to the source gNB in a HANDOVER COMMAND NGAP message. When the messaging is passed via the core network, this may involve one or more AMF (s) . If the source gNB and the target gNB are connected to the same AMF, this AMF handles all the above-described message receptions and transmissions. If the source gNB and the target gNB are connected to different AMFs, these AMFs forward the information between each other using a core network protocol.

[0061] Herein, the terms information element (IE) and field are used more or less interchangeably in this document. Also, the term parameter is sometimes used to denote the same concept. Parameters / IEs / fields used in ASN. 1 code as well as in procedural text in the 3GPP RRC specification for the fifth generation (5G)  / NR, i.e. 3GPP TS 38.331 version 17.4.0, are often named with a suffix indicating the number of the release of the 3GPP standard the parameter / IE / field was introduced in (e.g. the suffix “-r17” for a parameter / IE / field introduced in release 17 of the 3GPP standard) . Parameters / IEs / fields following this naming convention are typically referred to both with and without the suffix, where the name including the suffix is used in the ASN. 1 code (and thus defines the formal name from the ASN. 1 compiler’s perspective) , while the name without the suffix is used in  running text, e.g. in field descriptions and procedural text. Relevant examples in the context of this document include the parameters / IEs / fields t1-Threshold-r17  / t1-Threshold and t-Service-r17  / t-Service. In this document, both name variants may occur for various parameters / IEs / fields.

[0062] There are two main deployment principles for NTN: quasi-Earth-fixed cells and Earth-moving cells. These deployment principles are also referred to by other names. The quasi-Earth-fixed cells deployment principle is also referred to as quasi-Earth-fixed beams. The Earth-moving cells deployment principle is also referred to as Earth-moving beams, or shorter, moving or and moving beams.

[0063] In a time-based CHO configuration for a certain candidate target cell, a time window is defined within which the configured UE may execute the CHO, provided that the signal strength / quality CHO execution condition is fulfilled, and outside which the UE may not execute the CHO. Such a time window is herein sometimes referred to as a CHO execution time window or a CHO execution window. A CHO execution time window is said to last between the times 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 duration-r17 field are included in the condEventT1-r17 IE, which in turn is included in the CondTriggerConfig-r16 IE, which in turn is included in the ReportConfigNR IE. The t1-Threshold-r17 field is a Coordinated Universal Time (UTC) timestamp and the duration-r17 field represents a time period between 100 ms and 600 seconds (in steps of 100 ms) .

[0064] When a CHO has CondEvent T1 as one of its execution conditions, this is referred to as “time based CHO” . The terms “UL grant” and “grant” are used interchangeably herein. The terms / expressions “pre-allocated UL grant” , “pre-allocated grant” , “preallocated UL grant” , “preallocated grant” , “pre-configured UL grant” , “pre-configured grant” , “preconfigured UL grant” and “preconfigured grant” are used interchangeably herein. The terms “SSB set” and “SS burst” are used interchangeably herein.

[0065] Some embodiments on how to determine that no SSB with a mapped pre-allocated UL grant fulfills the RSRP threshold condition will be described below. Depending on the periodicity of the pre-allocated grant, the periodicity of SSB measurement, and how pre-allocated grant is associated to SSBs, a UE may have measured SSB in multiple SSB sets (commonly referred to as SS bursts) between two pre-allocated grant occasions associated with the same SSBs. FIG. 2A (which illustrates an example of block 200A of multiple SSB measurements between two pre-allocated grant occasion) and FIG. 2B (which illustrates an example of block 200B of multiple SSB measurements between two pre-allocated grant  occasion associated with the same SSBs) give two examples. In FIG. 2A, the UE measures SSBs in two SS bursts between the nth and (n+1) th pre-allocated grant occasion and also between the (n+3) th and (n+4) th pre-allocated grant occasion. In FIG. 2B, the nth, (n+2) th, (n+4) th and (n+6) th pre-allocated grant occasions are associated with one set of SSBs while the (n+1) th, (n+3) th, (n+5) th and (n+7) th pre-allocated grant occasions are associated with another different set of SSBs. In this case, the UE measures SSBs in two SS bursts between two adjacent pre-allocated grant occasions associated with the same SSBs.

[0066] In one embodiment, the UE determines whether a pre-allocated grant occasion associated with certain set of SSBs (i.e. one or multiple SSB (s) ) (denoted the concerned pre-allocated grant occasion hereafter) does not fulfill the RSRP condition (e.g. none of the associated SSB (s) has RSRP above the threshold) , according to SSB measurements in the latest measured SSB set, or the latest measured SSB sets (e.g. the latest N measured SSB sets if the UE uses N measurements to determine the RSRP of an SSB, e.g. using averaging over N measurements on the same SSB) , before the concerned pre-allocated grant occasion. The UE determines that the concerned pre-allocated grant occasion does not fulfill the RSRP condition if none of the associated SSBs has an RSRP above the threshold, and then the UE accordingly determines that the concerned pre-allocated grant occasion cannot be selected to transmit the Handover Complete message. Otherwise, if at least one of the SSB (s) associated with the concerned pre-allocated grant occasions has an RSRP determined to be above the threshold, the concerned pre-allocated grant occasion can be selected to transmit the Handover Complete message (or any other UL message or data) .

[0067] Alternatively, or in addition, the UE may make the determination according to SSB quality derived / updated based on SSB measurements in the latest min (m, n) SSB sets before the concerned pre-allocated grant occasion. m is hardcoded in the standards or configured by the gNB using dedicated or common control signaling or up to UE implementation. n is the total number of SSB sets that the UE measured before the concerned pre-allocated grant occasion or the total number of SSB sets that the UE measured between the concerned pre-allocated grant occasion and the last pre-allocated grant occasion preceding the latest SSB set measured prior to the concerned pre-allocated grant occasion, or the total number of SSB sets that the UE measured between the concerned pre-allocated grant occasion and the last pre-allocated grant occasion whose associated SSBs are the same as the SSBs associated with the concerned pre-allocated grant occasion that occurred before the latest SSB set measured prior to the concerned pre-allocated grant occasion.

[0068] In one option, the UE determines that the concerned pre-allocated grant occasion does not fulfill the RSRP condition if none of the associated SSB (s) has an RSRP above the  threshold, where the RSRP of the respective SSB (s) is derived based on SSB measurements on at least min (m, n, j) of the latest min (m, n) SSB sets before the concerned pre-allocated grant. Upon this determination, the UE determines that the concerned pre-allocated grant occasion cannot be selected to transmit the Handover Complete message (or any other UL message or data) . Otherwise, the concerned pre-allocated grant occasion can be selected to transmit the Handover Complete message (or any other UL message or data) .

[0069] In another option, the UE determines that the concerned pre-allocated grant occasion fulfills the RSRP condition if at least one of the associated SSBs have RSRP above the threshold where the RSRP of the respective SSB (s) is determined / derived / updated based on SSB measurements on at least min (m, n, k) of the latest min (m, n) SSB sets before the concerned pre-allocated grant. Upon this determination, the UE correspondingly determines that the concerned pre-allocated grant occasion can be selected to transmit the Handover Complete message (or any other UL message or data) . Otherwise, the concerned pre-allocated grant occasion cannot be selected to transmit the Handover Complete message (or any other UL message or data) . In the above options, j and k are hardcoded in the standards or configured by the gNB using dedicated or common control signaling or up to UE implementation.

[0070] As one option, the UE determines autonomously (based on UE implementation) how frequent SSB measurements it performs. The UE determines the RSRP of an SSB based on p measurements on the same SSB (e.g. by calculating an average, a weighted average or an exponential average of the SSB measurements) , where p may be specified (i.e. hardcoded in a standard) , configured by the network or left to the UE implementation to choose. If the UE has performed less than p measurements on SSB sets before the concerned pre-allocated grant occasion occurs, as one option, the UE determines that it cannot use the concerned pre-allocated grant occasion (e.g. the UE is not allowed to use the concerned pre-allocated grant occasion) . As another option, the UE is allowed to determine the SSB RSRP based on the SSB measurements it has performed (and to use the determined RSRP (s) to determine whether the UE can use the concerned pre-allocated grant occasion) , provided that the UE has measured on at least q SSB sets, where q fulfills p > q ≥ 1 and where q is hardcoded in a standard, configured by the network or determined by the UE implementation. As a further option, whether the UE considers the concerned pre-allocated grant occasion as unusable or evaluates the RSRP condition when less than p SSB sets have been measured on before the concerned pre-allocated grant occasion may be hardcoded in a standard, configured by the network, e.g. in the form of an indication in the RACH-less HO configuration or RACH-less HO command, or left to the UE implementation to choose.

[0071] In yet another alternative, the UE may make the determination according to SSB strength / quality derived / updated based on SSB measurements on the latest n SSB sets before the concerned pre-allocated grant occasion. If there is less than n SSB sets measured before the concerned pre-allocated grant occasion (e.g., in case the concerned pre-allocated grant occasion is the first pre-allocated grant occasion occurred after RACH-less HO is initiated) or since the last pre-allocated grant occasion or since the last pre-allocated grant occasion whose associated SSBs are the same as the SSBs associated with the concerned pre-allocated grant occasion, where the last pre-allocated grant occasion is the first pre-allocated grant occasion occurred after RACH-less HO is initiated or a pre-allocated grant occasion for which the UE has determined its usability based on SSB measurements, the UE may perform the following.

[0072] If the concerned pre-allocated grant occasion is the first pre-allocated grant occasion that occurred after the RACH-less HO is initiated, the concerned pre-allocated grant occasion may be determined as either can be used or cannot be used to transmit the Handover Complete message (or any other UL message or data) , which is hardcoded in the standard or configured by the gNB or up to UE implementation. Otherwise, whether or not the concerned pre-allocated grant occasion can be selected depends on the last pre-allocated grant occasion preceding the concerned pre-allocated grant occasion, e.g., if the last pre-allocated grant occasion can / cannot be used to transmit the Handover Complete message (or any other UL message or data) , the concerned pre-allocated grant occasion also can / cannot be used to transmit the Handover Complete message (or any other UL message or data) . This may be hardcoded in the standard or configured by the gNB. Otherwise (i.e., there is no less than n SSB sets measured before the concerned pre-allocated grant occasion) , the UE makes the determination similar as the previous alternative but without considering “m” . The gNB may enable this alternative by indicate an infinite “m” or an empty field for “m” .

[0073] In any of the above embodiments and options where the UE determines the RSRP of an SSB based on multiple measurements on the SSB, when evaluating whether an associated pre-allocated grant may be used, the UE may use averaging of the SSB measurements, weighted averaging of the SSB measurements, exponential averaging of the SSB measurements or L1 / L3 filtering of the SSB measurements to the determine the RSRP. The way in which the UE makes the determination may be hardcoded in the standard or configured by the gNB using dedicated or common control signaling or up to UE implementation. Embodiments related to fallback to RACH based HO.

[0074] In one embodiment, a UE falls back to RACH based HO once a pre-allocated grant occasion cannot be selected to transmit the Handover Complete message (or any other UL  message or data) . In another option, the fallback is performed only when u consecutive pre-allocated grant occasions cannot be selected to transmit the Handover Complete message (or any other UL message or data) , where u is hardcoded in the standard or configured by the gNB using dedicated or common control signaling or up to UE implementation. In yet another option, a UE falls back to RACH based HO once v consecutive groups of pre-allocated grant occasions cannot be selected to transmit the Handover Complete message (or any other UL message or data) . The pre-allocated grant occasions in each group are associated with different SSBs (e.g. such that for each of the SSBs which have associated pre-allocated grant (s) , the associated pre-allocated grant (s) appear (s) once and only once in each group) . The pre-allocated grant occasions associated with the same SSBs are put in different groups, and v is hardcoded in the standard or configured by the gNB using dedicated or common control signaling or up to UE implementation.

[0075] The UE may not fall back to RACH based HO if it performs a new SSB measurement before the available RA occasion and based on the SSB measurement it determines that the coming pre-allocated grant occasion after the SSB measurement is usable, e.g., can be selected to transmit the Handover Complete message. FIG. 3 (which illustrates an example block 300 of not fallback to RACH based HO if pre-allocated grant occasion can be selected again) below shows one such example as the (n+1) th pre-allocated grant occasion is not usable (e.g., cannot be selected to transmit the Handover Complete message) while according to the new SSB measurement before the available RA occasion the (n+2) th pre-allocated grant occasion is usable (e.g., can be selected to transmit the Handover Complete message) . In this case, the UE may not fall back to RACH based HO and continue to perform RACH-less HO using the (n+2) th pre-allocated grant occasion.

[0076] In another embodiment, if the UE, using any of the above-described criteria (or any other criterion) , has determined to fall back to RACH based HO, and while measuring on SSBs to evaluate the RSRP condition for SSB selection for random access preamble transmission (e.g. comparing the measured RSRP with the configured value of the rsrp-ThresholdSSB IE) , determines according to the measured SSBs that an (unused) pre-allocated grant occasion is usable, then the UE revokes its decision to fall back to RACH based HO and continue to perform RACH-less HO using the usable pre-allocated grant occasion.

[0077] In one of the embodiments, the UE is configured with a maximum time period (e.g., X ms) which allows the UE to attempt transmissions using pre-allocated grants. The UE may (re) start a timer with a value X ms when the UE initiates or returns to RACH-less HO configured with pre-allocated grants. While the timer is running, the UE may check if there is any SSB associated to a pre-allocated grant occasion with RSRP above the threshold and  restart the timer if that is the case. When the timer is expired and Handover Complete command is still not successfully delivered and T304 is still running, the UE falls back to RACH based HO. When the timer is running, the UE performs RACH-less HO using pre-allocated grant occasion (s) with at least one of the associated SSBs fulfilling the RSRP condition determined as described in the above embodiments. In another option, the UE may perform RACH-less HO using pre-allocated grant occasion (s) where none of the associated SSBs fulfilling the RSRP condition determined as described in the above embodiments when the timer is running.

[0078] In another one of the embodiments, the UE is configured with a SSB burst window (e.g., a window contains Y SS bursts) which allows the UE to attempt transmissions using pre-allocated grants. The UE (re) sets a counter to 0 when the UE initiates or returns to RACH-less HO configured with pre-allocated grants. The counter is increased by one when the UE measures a SS burst in the window. The UE (re) sets the counter to 0 when X (X<=Y) consecutive SS bursts within the window containing at least SSB which is associated to a pre-allocated grant occasion and has RSRP above the threshold. When the counter reaches Y and Handover Complete command is not successfully delivered and T304 is still running, UE falls back to RACH based HO. When the counter does not reach Y, the UE performs RACH-less HO using pre-allocated grant occasion (s) with at least one of the associated SSBs fulfilling the RSRP condition determined as described in the above embodiments. In another option, the UE may perform RACH-less HO using pre-allocated grant occasion (s) where none of the associated SSBs fulfilling the RSRP condition determined as described in the above embodiments when the counter does not reach Y.

[0079] In one of the embodiments, the UE first performs RACH-less HO using pre-allocated grant and falls back to RACH based HO if the UE fails to send the Handover Complete command using pre-allocated grant. The UE determines that delivery of the Handover Complete command using pre-allocated grant is failed if any one or more of the following conditions are met. In an example, the UE receives Radio Link Control (RLC) negative acknowledgement from the target gNB. For example, the UE may determine delivery of the Handover Complete command using pre-allocated grant is failed if there are Z1 RLC negative acknowledgements received. In another example, the UE receives hybrid automatic repeat request (HARQ) negative acknowledgement from the target gNB. For example, the UE may determine delivery of the Handover Complete command using pre-allocated grant is failed if there are Z2 HARQ negative acknowledgements received. In yet another example, the UE does not receive any acknowledgement after Z3 number of transmissions and retransmissions of the Handover Complete command using pre-allocated  grant. In another alternative example, the UE does not receive any acknowledgement in Z4 seconds / milliseconds since the UE transmitted the Handover Complete command using pre-allocated grant. In the above embodiments, X, Y, Z1, Z2, Z3 and Z4 may be hardcoded in the standard or configured by the gNB using dedicated or common control signaling or up to UE implementation.

[0080] In some embodiments, the UE is allowed to fall back to RACH based HO only if the RSRP threshold for SSB selection for RACH based HO (e.g. the configured value of the rsrp-ThresholdSSB IE) is lower than the RSRP threshold for usage of pre-allocated grant occasions, or, if the RSRP threshold for SSB selection for RACH based HO is lower than the RSRP threshold for usage of pre-allocated grant occasions and there is at least one SSB for which there is no associated pre-allocated grant (in which case the UE may fall back to RACH based HO to try the SSB (s) which do (does) not have any associated pre-allocated grant) . The way in which the UE performs fallback to RACH based HO may be hardcoded in the spec or configured by the gNB using dedicated or common control signaling or up to UE implementation.

[0081] Some embodiments on whether / when return to pre-allocated grant after fallback will be described below. It could happen that after fallback to RACH based handover, the UE does not successfully send the Handover Complete message using the random access procedure due to e.g., high collision in RA resources, while an (unused) pre-allocated grant occasion fulfills the RSRP condition and the handover supervision timer, e.g. timer T304, is still running. In one embodiment, once fallback to RACH based handover, the UE continues to perform RACH based handover even if an (unused) pre-allocated grant occasion fulfills the RSRP condition and T304 is still running. In another option, the UE returns to RACH-less handover if the Handover Complete message is not successfully delivered yet (e.g., the UE has not received a UE Contention Resolution Identity MAC CE or PDCCH / physical downlink shared channel (PDSCH) addressed to it) and an (unused) pre-allocated grant occasion fulfills the RSRP condition and T304 is still running, and the UE uses that (unused) pre-allocated grant occasion to deliver the Handover Complete message. In yet another option, the UE returns to RACH-less handover if an (unused) pre-allocated grant occasion fulfills the RSRP condition and T304 is still running, and the UE uses that (unused) pre-allocated grant occasion to deliver the Handover Complete message, without waiting for the potential UE Contention Resolution Identity MAC CE or PDCCH / PDSCH addressed to it from the gNB. This could reduce the handover interruption time. To support the above embodiment, one option is that the UE keeps measuring SSBs even after fallback to RACH based handover. In another alternative option, the UE may skip SSB measurements (or  perform relaxed SSB measurements) after fallback to RACH based handover, and resume (non-relaxed) SSBs measurement when RACH-based handover is not successful or when the Handover Complete message is sent out.

[0082] Whether or not return to RACH-less handover after fallback to RACH based HO when the relevant return conditions are met may be hardcoded in the standard or configured by the gNB using dedicated or common control signaling or up to UE implementation. When this is up to UE implementation, it may be hardcoded in the standard or indicated by the gNB using dedicated or common control signaling that return to RACH-less handover is allowed, then whether or not return to RACH-less handover when the relevant return conditions are met is up to UE implementation.

[0083] In one embodiment, if the UE, after fallback to RACH based HO, has made the maximum allowed number of RA attempts (e.g. as configured by the preambleTransMax IE) without success, the UE may revert to trying RACH-less access if there are still pre-allocated grant occasions available (e.g. if the handover supervision timer T304 has not yet expired) . As one option, a further condition for this reverting to RACH-less access is that at least one SSB with associated pre-allocated grant (s) fulfills the RSRP threshold condition. As another option, there is no further condition for the UE to revert to RACH-less access, e.g. the UE may do this in the above described situation regardless of the RSRP measured for the SSBs.

[0084] If, after fallback to RACH based HO and subsequent reverting to RACH-less access (due to e.g. the UE having made the maximum allowed number of RA attempts) , no SSB with associated pre-allocated grant (s) fulfills the RSRP condition (e.g. has an SSB RSRP above the threshold) , as one option, the UE is anyway allowed to select one of the pre-allocated grant occasions after the last SSB measurements it performs before the handover supervision timer, timer T304, expires. As another option, after falling back to RACH based HO and reverting to RACH-less access, the UE is allowed to use any pre-allocated grant occasion before expiration of T304, even if the RSRP condition is not fulfilled for the pre-allocated grant occasion.

[0085] Some embodiments on setting of the RSRP threshold will be described below. Soft combining can be performed when the Handover Complete message is transmitted using pre-allocated grant while this is not possible when the Handover Complete message is transmitted in RA manner. One way to further exploit the soft combining gain is to configure different RSRP threshold depending on whether the pre-allocated grant occasion is used for the first transmission or retransmission of the Handover Complete message. More specifically, a higher RSRP threshold may be configured if the pre-allocated grant occasion is used for the first transmission of the Handover Complete message while a lower RSRP  threshold may be configured if the pre-allocated grant occasion is used for retransmission (s) of the Handover Complete message. In this way, if the Handover Complete message has been already transmitted at least once using the pre-allocated grant, fallback to RACH based HO will be more restrictive and return to RACH-less HO will be easier. For example, the pre-allocated grant will be used more times especially for the retransmission, thus it could benefit more from soft combining and at the same time experience of collision in RACH based transmission could be reduced. Regarding the threshold configuration, either both of the two thresholds are explicitly configured or one of the thresholds is explicitly configured and the other one is configured as an offset to the explicitly configured threshold.

[0086] In some embodiments where a single RSRP threshold for usage of pre-allocated grant occasions is assumed (i.e. no two threshold levels as described above) , the RSRP threshold for usage of pre-allocated grant occasions (henceforth referred to as RSRPthres_grant) may be configured in different ways. As one option, no separate IE is specified for RSRPthres_grant, but instead RSRPSSB_RA (e.g. the rsrp-ThresholdSSB IE) is reused. As another option, a separate IE is specified for RSRPthres_grant, but it may be optional with a default value (when the new IE is absent) specified to be the value of RSRPSSB_RA that is used. As another option (which may be combined with the preceding option) , the RSRPthres_grant IE is specified as an offset to be added to RSRPSSB_RA (e.g. to the value of the rsrp-ThresholdSSB IE) .

[0087] If two or more levels are used for the threshold for usage of pre-allocated grant occasions, then the above options may apply to the highest threshold level, e.g. the one used for the first transmission of the Handover Complete message. And the option where the threshold for usage of pre-allocated grant occasions is specified as an offset to the RSRP threshold for SSB selection during random access (RSRPSSB_RA) may be applied to the specification of all levels of the multi-level threshold for usage of pre-allocated grant occasions.

[0088] FIG. 4A shows a flowchart of an example method 400A of handover in accordance with some embodiments of the present disclosure. The method 400A can be implemented at the terminal device 130 as shown in FIG. 1.

[0089] At block 410, the terminal device 130 initiates a RACH-less handover. At block 420, the terminal device 130 determines usability of at least one pre-allocated grant occasion for an uplink transmission, the at least one pre-allocated grant occasion being configured for the RACH-less handover. In an example, in accordance with a determination that a pre-allocated grant occasion of the at least one pre-allocated grant occasion is usable, the terminal device 130 transmits the uplink transmission on the pre-allocated grant occasion of  the at least one pre-allocated grant occasion. In an example, in accordance with a determination that the at least one pre-allocated grant occasion is unusable, the terminal device 130 initiates a RACH-based handover.

[0090] In an example, the terminal device 130 determines usability of a pre-allocated grant occasion of at least one pre-allocated grant occasion based on at least one measurement result of at least one RS transmitted prior to the pre-allocated grant occasion. In an example, the at least one measurement result comprises at least one measurement result immediately prior to the pre-allocated grant occasion. In an example, the at least one measurement result comprises available measurement results obtained before the pre-allocated grant occasion, or the at least one measurement result is obtained during a time period prior to the pre-allocated grant occasion, the time period comprising: a pre-determined period, a pre-determined time window, or a duration between the pre-allocated grant occasion and a further pre-allocated grant occasion, the further pre-allocated grant occasion being prior to the pre-allocated grant occasion. In an example, the further pre-allocated grant occasion is adjacent or non-adjacent to the pre-allocated grant occasion, or the pre-allocated grant occasion and the further pre-allocated grant occasion are both associated with a RS identifier or a beam.

[0091] In an example, in accordance with a determination that the number of the at least one measurement result is larger than one, the terminal device 130 determines the usability based on at least one of the following: a latest one of the at least one measurement result, the maximum measurement value of the at least one measurement result, or an average measurement value of the at least one measurement result. In an example, the terminal device 130 determines the pre-allocated grant occasion to be unusable in response to at least one of the following: none of the at least one measurement result meets a quality condition, or one or more of the least one measurement result fails to meet the quality condition. In an example, the terminal device 130 determines the pre-allocated grant occasion to be usable in response to at least one of the following: all of the at least one measurement result meet a quality condition, or one or more of the least one measurement result meets the quality condition. In an example, a maximum of the number of the at least one measurement result is predefined, configured by a network device, or set by the terminal device 130.

[0092] In an example, in accordance with a determination that the number of available measurement results is smaller than or equal to a first threshold number, the terminal device 130 determines the pre-allocated grant occasion to be unusable; or determines the usability based on the available measurement results, and where the first threshold number is predefined, configured by a network device, or set by the terminal device 130. In an example, the usability is determined based on a default rule or a rule configured by a network device.

[0093] In an example, in accordance with a determination that the number of available measurement results is smaller than or equal to a first threshold number and the pre-allocated grant occasion is a pre-allocated grant occasion immediately subsequent to the initiation of the RACH-less handover, the terminal device 130 determines the pre-allocated grant occasion is usable.

[0094] In an example, the terminal device 130 initiates a RACH-based handover in response to one of the following: a pre-allocated grant occasion of the at least one pre-allocated grant occasion being determined to be unusable, the number of continuous pre-allocated grant occasions of the at least one pre-allocated grant occasion being greater than or equal to a second threshold number, the continuous pre-allocated grant occasions being determined to be unusable, all of the pre-allocated grant occasions in a set of pre-allocated grant occasions of the at least one pre-allocated grant occasion being determined to be unusable, or the number of continuous sets of pre-allocated grant occasions of the at least one pre-allocated grant occasion being greater than or equal to a third threshold number, where all of the pre-allocated grant occasions in the continuous sets of pre-allocated grant occasions are determined to be unusable. In an example, different pre-allocated grant occasions comprised in the set of pre-allocated grant occasions are associated with different RS identifiers or different beams. In an example, the terminal device 130 is located in NTNs.

[0095] FIG. 4B shows a flowchart of an example method 400B of handover in accordance with some embodiments of the present disclosure. The method 400B can be implemented at the terminal device 130 as shown in FIG. 1.

[0096] At block 460, the terminal device 130 initiates a RACH-less handover. At block 470, the terminal device 130 determines that the RACH-less handover is to be ceased and a RACH-based handover is to be initiated. In an example, in response to a pre-allocated grant occasion configured for the RACH-less handover being determined to be usable, the terminal device 130 continues or re-initiates the RACH-less handover, where the pre-allocated grant occasion is prior to an available RA occasion of the RACH-based handover, or where a RS measurement associated with the pre-allocated grant occasion is prior to the RA occasion of the RACH-based handover.

[0097] In an example, the terminal device 130 starts a timer upon the initiation or re-initiation of the RACH-less handover; and during running of the timer: disables the initiation of the RACH-based handover, or continues or re-initiates the RACH-less handover based on at least one pre-allocated grant occasion configured for the RACH-less handover. In an example, in accordance with a determination that the timer is expired and the RACH-less handover is uncompleted, the terminal device 130 determines that the RACH-based handover  is to be initiated. In an example, the terminal device 130 disables the initiation of the RACH-based handover within a time window, the time window comprising a plurality of RS measurement periodicities. In an example, the terminal device 130 starts a counter upon the initiation or re-initiation of the RACH-less handover; and before a value of the counter exceeding a threshold value: disables the initiation of the RACH-based handover, or continues or re-initiates the RACH-less handover based on at least one pre-allocated grant occasion configured for the RACH-less handover. In an example, the terminal device 130 in accordance with a determination that the value of the counter exceeds the threshold value and the RACH-less handover is uncompleted, determines that the RACH-based handover is to be initiated. In an example, the RACH-less handover is prioritized over the RACH-based handover.

[0098] In an example, in response to a failure of a transmission of a handover complete message for the RACH-less handover, the terminal device 130 determines that the RACH-based handover to be initiated. In an example, based on a reception of a negative acknowledgement of the handover complete message, the terminal device 130 determines that the transmission of the handover complete message is failed. In an example, in accordance with a determination that a first quality level required for the RACH-less handover is lower than or equal to a second quality level required for the RACH-based handover, the terminal device 130 disables the RACH-based handover. In an example, in accordance with a determination that a first set of reference signals (RSs) associated with RACH-less handover is at least partially overlapped with a second set of RSs associated with RACH-based handover, the terminal device 130 disables the RACH-based handover.

[0099] In an example, the terminal device 130 initiates the RACH-based handover; and in response to a transmission of a handover complete message for the RACH-based handover being failed, disables re-initiation of the RACH-less handover, or re-initiates the RACH-less handover based on at least one trigger condition for the RACH-less handover being met. In an example, the at least one trigger condition comprises at least one of: a condition that the RACH-based handover is failed, a condition that the terminal device 130is allowed to re-initiate a RACH-less handover, a condition that a measurement result of a pre-allocated grant occasion configured for the RACH-less handover meets a quality condition of the RACH-less handover, a condition that a handover timer is not expired, or a condition that a TimeAlignmentTimer is not expired. In an example, the terminal device 130 determines whether the terminal device 130 is allowed to reinitiate the RACH-less handover, based on a default rule or a rule configured by a network device.

[0100] In an example, after reinitiating the RACH-less handover, the terminal device 130  performs an uplink transmission on a pre-allocated grant occasion configured for the RACH-less handover regardless of a measurement result of a RS measurement associated with pre-allocated grant occasion. In an example, a first threshold for a RS measurement is configured for selecting a pre-allocated grant occasion for an initial uplink transmission during the RACH-less handover, a second threshold for the RS measurement is configured for selecting a pre-allocated grant occasion for a re-transmission uplink transmission during the RACH-less handover, and the first threshold is higher than the second threshold. In an example, the terminal device 130 is located in NTNs.

[0101] FIG. 5 shows a flowchart of an example handover method 500 in accordance with some embodiments of the present disclosure. The method 500 can be implemented at the network device 110 as shown in FIG. 1.

[0102] At block 510, the network device 110 transmits, to the terminal device 130, configuration information indicating at least one of the following: at least one pre-allocated grant occasion for RACH-less handover, a maximum of the number of the at least one measurement result used for determining usability of at least one pre-allocated grant occasion, a first threshold number indicating a number of the at least one measurement result required for determining the usability of at least one pre-allocated grant occasion, a second threshold number, based on a determination of the number of continuous pre-allocated grant occasions of the at least one pre-allocated grant occasion being greater than or equal to a second threshold number, switching from a RACH-less handover to a RACH-based handover, the continuous pre-allocated grant occasions being determined to be unusable, a third threshold number, based on a determination of the number of continuous sets of pre-allocated grant occasions of the at least one pre-allocated grant occasion being greater than or equal to a third threshold number, switching from a RACH-less handover to a RACH-based handover, where all of the pre-allocated grant occasions in the continuous sets of pre-allocated grant occasions are determined to be unusable, a rule for determining the usability of the pre-allocated grant occasion, an indication indicating whether the terminal device is allowed to re-initiate a RACH-less handover, a time window comprising a plurality of reference signal (RS) measurement periodicities, RACH-based handover being disabled within the time window, a first threshold for a reference signal (RS) measurement configured for selecting a pre-allocated grant occasion for an initial uplink transmission during the RACH-less handover, a second threshold for the RS measurement configured for selecting a pre-allocated grant occasion for a re-transmission uplink transmission during the RACH-less handover, the first threshold being higher than the second threshold.

[0103] All operations and features related to the terminal device 130 such as the UE and  the network device 110 such as the eNB or gNB as described above with reference to FIGS. 1 to 3 are likewise applicable to the methods 400A, 400B and 500 and have similar effects. For the purpose of simplification, the details will be omitted.

[0104] FIG. 6 shows a communication device 600 in accordance with some embodiments. As shown in FIG. 6, the communication device 600 may comprise a processor 605 and a memory 610. The memory 610 may contain instructions 615 executable by the processor 605, whereby the communication device 600 may be operative to implement actions or operations according to any of the above-mentioned embodiments described with reference to FIGS. 1 to 5. In some embodiments, the communication 600 may operate as a terminal device and be operative to carry out the method 400A or 400B. In some embodiments, the communication 600 may operate as a network device and be operative to carry out the method 500.

[0105] The processor 605 may be any kind of processing component, such as one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs) , special-purpose digital logic, and the like. The memory 610 may be any kind of storage component, such as read-only memory (ROM) , random-access memory, cache memory, flash memory devices, optical storage devices, etc.

[0106] FIG. 7 shows a computer readable storage medium 700 in accordance with some embodiments. As shown in FIG. 7, the computer readable storage medium 700 comprising instructions 415 which when executed by a processor of a device, cause the device to perform any above-mentioned embodiments described with reference to FIGS. 1 to 5. The computer readable storage medium 700 may be configured to include memory such as RAM, ROM, programmable read-only memory (PROM) , erasable programmable read-only memory (EPROM) , electrically erasable programmable read-only memory (EEPROM) , magnetic disks, optical disks, floppy disks, hard disks, removable cartridges, or flash drives.

[0107] In some embodiments, an apparatus capable of performing the method 400A, 400B or 500 may comprise means for performing the respective operations of the method 400A, 400B or 500. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[0108] FIG. 8 shows an example of a communication system 800 in accordance with some embodiments.

[0109] In the example, the communication system 800 includes a telecommunication network 802 that includes an access network 804, such as a radio access network (RAN) , and a core network 806, which 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 be generally referred to as network nodes 810) , or any other similar  3rd Generation Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 802 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 802 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 802, including one or more network nodes 810 and / or core network nodes 808.

[0110] Examples of an ORAN network node include an open radio unit (O-RU) , an open distributed unit (O-DU) , an open central unit (O-CU) , including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP) , a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp) , or any combination thereof (the adjective “open” designating support of an ORAN specification) . The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1, F1, W1, E1, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. X2 is an interface between two eNBs in LTE. Xn is an interface between two gNBs in NR.

[0111] Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the O-RAN Alliance or comparable technologies. The network nodes 810 facilitate direct or indirect connection of user equipment (UE) , such as by connecting UEs 812a, 812b, 812c, and 812d (one or more of which may be generally referred to as UEs 812) to the core network 806 over one or more wireless connections.

[0112] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the  communication system 800 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 800 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0113] The UEs 812 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 810 and other communication devices. Similarly, the network nodes 810 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 812 and / or with other network nodes or equipment in the telecommunication network 802 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 802.

[0114] In the depicted example, the core network 806 connects the network nodes 810 to one or more host computing systems, such as host 816. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 806 includes one more core network nodes (e.g., core network node 808) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 808. Example core network nodes include functions of one or more of a 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 De-concealing function (SIDF) , Unified Data Management (UDM) , Security Edge Protection Proxy (SEPP) , Network Exposure Function (NEF) , and / or a User Plane Function (UPF) .

[0115] The host 816 may be under the ownership or control of a service provider other than an operator or provider of the access network 804 and / or the telecommunication network 802. The host 816 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0116] As a whole, the communication system 800 of FIG. 8 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are 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 standards (WiFi) ; and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (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, the telecommunication network 802 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 802 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 802. For example, the telecommunications network 802 may 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 further UEs.

[0118] In some examples, the UEs 812 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 804 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 804. Additionally, a UE may be configured for operating in single-or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being 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 the example, the hub 814 communicates with the 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, the hub 814 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 814 may be a broadband router enabling access to the core network 806 for the UEs. As another example, the hub 814 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or  instructions may be received from the UEs, network nodes 810, or by executable code, script, process, or other instructions in the hub 814. As another example, the hub 814 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 814 may be a content source. For example, for a UE that is a VR device, display, loudspeaker, or other media delivery device, the hub 814 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 814 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 814 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy IoT devices.

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

[0121] FIG. 9 shows a UE 900 in accordance with some embodiments. The UE 900 presents additional details of some embodiments of the UE 812 of FIG. 8. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA) , wireless cameras, gaming console or device, music storage / playback device, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , an Augmented Reality (AR) or Virtual Reality (VR) device, wireless customer-premise equipment (CPE) , vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the  3rd Generation Partnership Project (3GPP) , including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0122] A UE may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC) , vehicle-to-vehicle (V2V) , vehicle-to-infrastructure (V2I) , or vehicle-to-everything (V2X) . In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller) . Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter) .

[0123] The UE 900 includes processing circuitry 902 that is operatively coupled via a bus 904 to an input / output interface 906, a power source 908, a memory 910, a communication interface 912, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in FIG. 9. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0124] The processing circuitry 902 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 910. The processing circuitry 902 may 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 together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP) , together with appropriate software; or any combination of the above. For example, the processing circuitry 902 may include multiple central processing units (CPUs) .

[0125] In the example, the input / output interface 906 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 900. Examples of an input device include a touch-sensitive or presence-sensitive display, a  camera (e.g., a digital camera, a digital video camera, a web camera, etc. ) , a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0126] In some embodiments, the power source 908 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet) , photovoltaic device, or power cell, may be used. The power source 908 may further include power circuitry for delivering power from the power source 908 itself, and / or an external power source, to the various parts of the UE 900 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 908. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 908 to make the power suitable for the respective components of the UE 900 to which power is supplied.

[0127] The 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) , magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 910 includes one or more application programs 914, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 916. The memory 910 may store, for use by the UE 900, any of a variety of various operating systems or combinations of operating systems.

[0128] The memory 910 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID) , flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM) , synchronous dynamic random access memory (SDRAM) , external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs) , such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC  may for example be an embedded UICC (eUICC) , integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card. ’ The memory 910 may allow the UE 900 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 910, which may be or comprise a device-readable storage medium.

[0129] The processing circuitry 902 may be configured to communicate with an access network or other network using the communication interface 912. The communication interface 912 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 922. The communication interface 912 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network) . Each transceiver may include a transmitter 918 and / or a receiver 920 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth) . Moreover, the transmitter 918 and receiver 920 may be coupled to one or more antennas (e.g., antenna 922) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0130] In the illustrated embodiment, communication functions of the communication interface 912 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing 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 networking (SONET) , Asynchronous Transfer Mode (ATM) , QUIC, Hypertext Transfer Protocol (HTTP) , and so forth.

[0131] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 912, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature) , random (e.g., to even out the load from reporting from several sensors) , in response to a triggering event (e.g., when moisture is detected an alert is  sent) , in response to a request (e.g., a user initiated request) , or a continuous stream (e.g., a live video feed of a patient) .

[0132] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0133] A UE, when in the form of an Internet of Things (IoT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an IoT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal-or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV) , and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an IoT device comprises circuitry and / or software in dependence of the intended application of the IoT device in addition to other components as described in relation to the UE 900 shown in FIG. 9.

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

[0135] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote  controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0136] FIG. 10 shows a network node 1000 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication 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 NodeBs (gNBs) ) , O-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O-CU) .

[0137] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) 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 an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS) .

[0138] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs) , base transceiver stations (BTSs) , transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs) , Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs) ) , and / or Minimization of Drive Tests (MDTs) .

[0139] The network node 1000 includes a processing circuitry 1002, a memory 1004, a communication interface 1006, and a power source 1008. The network node 1000 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc. ) , which may each have their own respective components. In certain scenarios in which the network node 1000 comprises  multiple separate components (e.g., BTS and BSC components) , one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the 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., a same antenna 1010 may be shared by different RATs) . The network node 1000 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1000, for example 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 chip or set of chips and other components within network node 1000.

[0140] The processing circuitry 1002 may comprise 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, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 1000 components, such as the memory 1004, to provide network node 1000 functionality.

[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 radio frequency (RF) transceiver circuitry 1012 and baseband processing circuitry 1014. In some embodiments, the radio frequency (RF) transceiver circuitry 1012 and the baseband processing circuitry 1014 may be on separate chips (or sets of chips) , boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 1012 and baseband processing circuitry 1014 may be on the same chip or set of chips, boards, or units.

[0142] The memory 1004 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM) , read-only memory (ROM) , mass storage media (for example, a hard disk) , removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD) ) , and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 1002. The memory 1004 may store any suitable instructions, data,  or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 1002 and utilized by the network node 1000. The memory 1004 may be used to store any calculations made by the processing circuitry 1002 and / or any data received via the communication interface 1006. In some embodiments, the processing circuitry 1002 and memory 1004 is integrated.

[0143] The communication interface 1006 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface 1006 comprises port (s)  / terminal (s) 1016 to send and receive data, for example to and from a network over a wired connection. The communication interface 1006 also includes radio front-end circuitry 1018 that may be coupled to, or in certain embodiments a part of, the antenna 1010. Radio front-end circuitry 1018 comprises filters 1020 and amplifiers 1022. The radio front-end circuitry 1018 may be connected to an antenna 1010 and processing circuitry 1002. The radio front-end circuitry may be configured to condition signals communicated between antenna 1010 and processing circuitry 1002. The radio front-end circuitry 1018 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 1018 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 1020 and / or amplifiers 1022. The radio signal may then be transmitted via the antenna 1010. Similarly, when receiving data, the antenna 1010 may collect radio signals which are then converted into digital data by the radio front-end circuitry 1018. The digital data may be passed to the processing circuitry 1002. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

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

[0145] The antenna 1010 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 1010 may be coupled to the radio front-end circuitry 1018 and may be any type of antenna capable of transmitting and receiving data  and / or signals wirelessly. In certain embodiments, the antenna 1010 is separate from the network node 1000 and connectable to the network node 1000 through an interface or port.

[0146] The antenna 1010, communication interface 1006, and / or the processing circuitry 1002 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 1010, the communication interface 1006, and / or the processing circuitry 1002 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0147] The power source 1008 provides power to the various components of network node 1000 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component) . The power source 1008 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 1000 with power for performing the functionality described herein. For example, the network node 1000 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 1008. As a further example, the power source 1008 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0148] Embodiments of the network node 1000 may include additional components beyond those shown in FIG. 10 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 1000 may include user interface equipment to allow input of information into the network node 1000 and to allow output of information from the network node 1000. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 1000. In some embodiments providing a core network node, such as core network node 108 of FIG. 8, some components, such as the radio front-end circuitry 1018 and the RF transceiver circuitry 1012 may be omitted.

[0149] FIG. 11 is a block diagram illustrating a virtualization environment 1100 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include  virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1100 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host) , then the node may be entirely virtualized. In some embodiments, the virtualization environment 1100 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface. Virtualization may facilitate distributed implementations of a network node, UE, core network node, or host.

[0150] Applications 1102 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc. ) are run in the virtualization environment 1100 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0151] Hardware 1104 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. 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 be generally referred to as VMs 1108) , and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1106 may present a virtual operating platform that appears like networking hardware to the VMs 1108.

[0152] The VMs 1108 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1106. Different embodiments of the instance of a virtual appliance 1102 may be implemented on one or more of VMs 1108, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV) . NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0153] In the context of NFV, a VM 1108 may be a software implementation of a physical  machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1108, and that part of hardware 1104 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1108 on top of the hardware 1104 and corresponds to the application 1102.

[0154] Hardware 1104 may be implemented in a standalone network node with generic or specific components. Hardware 1104 may implement some functions via virtualization. Alternatively, hardware 1104 may be part of a larger cluster of hardware (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, among others, oversees lifecycle management of applications 1102. In some embodiments, hardware 1104 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 1112 which may alternatively be used for communication between hardware nodes and radio units.

[0155] Although the computing devices described herein (e.g., UEs, network nodes) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the  components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0156] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain 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 functionality may be provided by the 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, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

Claims

1.A method (400A) at a terminal device (130) , the method (400A) comprising:initiating (410) a random access channel-less, RACH-less, handover; anddetermining (420) usability of at least one pre-allocated grant occasion for an uplink transmission, the at least one pre-allocated grant occasion being configured for the RACH-less handover.2.The method (400A) of claim 1, further comprising:in accordance with a determination that a pre-allocated grant occasion of the at least one pre-allocated grant occasion is usable, transmitting the uplink transmission on the pre-allocated grant occasion of the at least one pre-allocated grant occasion.3.The method (400A) of claim 1 or 2, further comprising:in accordance with a determination that the at least one pre-allocated grant occasion is unusable, initiating a random access channel-based, RACH-based, handover.4.The method (400A) of any of claims 1 to 3, wherein determining (420) the usability comprises:determining usability of a pre-allocated grant occasion of at least one pre-allocated grant occasion based on at least one measurement result of at least one reference signal, RS, transmitted prior to the pre-allocated grant occasion.5.The method (400A) of claim 4, wherein the at least one measurement result comprises at least one measurement result immediately prior to the pre-allocated grant occasion.6.The method (400A) of claim 4 or 5, wherein,the at least one measurement result comprises available measurement results obtained before the pre-allocated grant occasion, orthe at least one measurement result is obtained during a time period prior to the pre-allocated grant occasion, the time period comprising:a pre-determined period,a pre-determined time window, ora duration between the pre-allocated grant occasion and a further pre-allocated grant occasion, the further pre-allocated grant occasion being prior to the pre-allocated grant occasion.7.The method (400A) of claim 6, wherein,the further pre-allocated grant occasion is adjacent or non-adjacent to the pre-allocated grant occasion, orthe pre-allocated grant occasion and the further pre-allocated grant occasion are both associated with a RS identifier or a beam.8.The method (400A) of any of claims 4 to 7, wherein determining the usability of the pre-allocated grant occasion comprises:in accordance with a determination that the number of the at least one measurement result is larger than one, determining the usability based on at least one of the following:a latest one of the at least one measurement result,the maximum measurement value of the at least one measurement result, oran average measurement value of the at least one measurement result; and / ordetermining the pre-allocated grant occasion to be unusable in response to at least one of the following:none of the at least one measurement result meets a quality condition, orone or more of the least one measurement result fails to meet the quality condition; and / ordetermining the pre-allocated grant occasion to be usable in response to at least one of the following:all of the at least one measurement result meet a quality condition, orone or more of the least one measurement result meets the quality condition.9.The method (400A) of any of claims 4 to 8, wherein a maximum of the number of the at least one measurement result is predefined, configured by a network device, or set by the terminal device (130) .10.The method (400A) of any of claims 4 to 9, wherein determining the usability of the pre-allocated grant occasion comprises:in accordance with a determination that the number of available measurement results is smaller than or equal to a first threshold number,determining the pre-allocated grant occasion to be unusable; ordetermining the usability based on the available measurement results,and wherein the first threshold number is predefined, configured by a network device, or set by the terminal device (130) .11.The method (400A) of claim 10, wherein the usability is determined based on a default rule or a rule configured by a network device.12.The method (400A) of any of claims 4 to 11, wherein determining the usability of the pre-allocated grant occasion comprises:in accordance with a determination that the number of available measurement results is smaller than or equal to a first threshold number and the pre-allocated grant occasion is a pre-allocated grant occasion immediately subsequent to the initiation of the RACH-less handover, determining the pre-allocated grant occasion is usable.13.The method (400A) of any of claims 1 to 12, further comprising:initiating a RACH-based handover in response to one of the following:a pre-allocated grant occasion of the at least one pre-allocated grant occasion being determined to be unusable,the number of continuous pre-allocated grant occasions of the at least one pre-allocated grant occasion being greater than or equal to a second threshold number, the continuous pre-allocated grant occasions being determined to be unusable,all of the pre-allocated grant occasions in a set of pre-allocated grant occasions of the at least one pre-allocated grant occasion being determined to be unusable, orthe number of continuous sets of pre-allocated grant occasions of the at least one pre-allocated grant occasion being greater than or equal to a third threshold number, wherein all of the pre-allocated grant occasions in the continuous sets of pre-allocated grant occasions are determined to be unusable.14.The method (400A) of claim 13, wherein,different pre-allocated grant occasions comprised in the set of pre-allocated grant occasions are associated with different reference signal, RS, identifiers or different beams.15.The method (400A) of any of claims 1 to 14, wherein the terminal device (130) is located in non-terrestrial networks, NTNs.16.A method (400B) at a terminal device (130) , the method comprising:initiating (460) a random access channel-less, RACH-less, handover; anddetermining (470) that the RACH-less handover is to be ceased and a random access channel-based, RACH-based, handover is to be initiated.17.The method (400B) of claim 16, further comprising:in response to a pre-allocated grant occasion configured for the RACH-less handover being determined to be usable, continuing or re-initiating the RACH-less handover,wherein the pre-allocated grant occasion is prior to an available random access, RA, occasion of the RACH-based handover, orwherein a reference signal, RS measurement associated with the pre-allocated grant occasion is prior to the RA occasion of the RACH-based handover.18.The method of (400B) claim 16 or 17, further comprising:starting a timer upon the initiation or re-initiation of the RACH-less handover; andduring running of the timer:disabling the initiation of the RACH-based handover, orcontinuing or re-initiating the RACH-less handover based on at least one pre-allocated grant occasion configured for the RACH-less handover.19.The method of (400B) claim 18, wherein determining that the RACH-based handover is to be initiated comprises:in accordance with a determination that the timer is expired and the RACH-less handover is uncompleted, determining that the RACH-based handover is to be initiated.20.The method of (400B) claim 19, further comprising:disabling the initiation of the RACH-based handover within a time window, the time window comprising a plurality of reference signal, RS, measurement periodicities.21.The method of (400B) claim 19, further comprising:starting a counter upon the initiation or re-initiation of the RACH-less handover; andbefore a value of the counter exceeding a threshold value:disabling the initiation of the RACH-based handover, orcontinuing or re-initiating the RACH-less handover based on at least one pre-allocated grant occasion configured for the RACH-less handover.22.The method of (400B) claim 21, wherein determining that the RACH-based handover is initiated comprises:in accordance with a determination that the value of the counter exceeds the threshold value and the RACH-less handover is uncompleted, determining that the RACH-based handover is to be initiated.23.The method of (400B) any of claims 16 to 22, wherein the RACH-less handover is prioritized over the RACH-based handover.24.The method of (400B) any of claims 16 to 23, wherein determining that the RACH-based handover is to be initiated comprises:in response to a failure of a transmission of a handover complete message for the RACH-less handover, determining that the RACH-based handover to be initiated.25.The method of (400B) claim 24, further comprising:based on a reception of a negative acknowledgement of the handover complete message, determining that the transmission of the handover complete message is failed.26.The method of (400B) any of claims 16 to 25, further comprising:in accordance with a determination that a first quality level required for the RACH-less handover is lower than or equal to a second quality level required for the RACH-based handover, disabling the RACH-based handover.27.The method of (400B) any of claims 16 to 26, further comprising:in accordance with a determination that a first set of reference signals, RSs, associated with RACH-less handover is at least partially overlapped with a second set of RSs associated with RACH-based handover, disabling the RACH-based handover.28.The method of (400B) any of claims 16 to 27, further comprising:initiating the RACH-based handover; andin response to a transmission of a handover complete message for the RACH-based handover being failed,disabling re-initiation of the RACH-less handover, orre-initiating the RACH-less handover based on at least one trigger condition for the RACH-less handover being met.29.The method of (400B) claim 28, wherein the at least one trigger condition comprises at least one of:a condition that the RACH-based handover is failed,a condition that the terminal device (130) is allowed to re-initiate a RACH-less handover,a condition that a measurement result of a pre-allocated grant occasion configured for the RACH-less handover meets a quality condition of the RACH-less handover,a condition that a handover timer is not expired, ora condition that a TimeAlignmentTimer is not expired.30.The method of (400B) claim 29, further comprising:determining whether the terminal device (130) is allowed to re-initiate the RACH-less handover, based on a default rule or a rule configured by a network device.31.The method of (400B) claim 29 or 30, further comprising:after reinitiating the RACH-less handover, performing an uplink transmission on a pre-allocated grant occasion configured for the RACH-less handover regardless of a measurement result of a reference signal, RS, measurement associated with pre-allocated grant occasion.32.The method of (400B) any of claims 29 to 31, wherein,a first threshold for a reference signal, RS, measurement is configured for selecting a pre-allocated grant occasion for an initial uplink transmission during the RACH-less handover, a second threshold for the RS measurement is configured for selecting a pre-allocated grant occasion for a re-transmission uplink transmission during the RACH-less handover, and the first threshold is higher than the second threshold.33.The method of (400B) any of claims 16-32, wherein the terminal device (130) is located in non-terrestrial networks, NTNs.34.A method (500) at a network device (110) , the method (500) comprising:transmitting (510) , to a terminal device, configuration information indicating at least one of the following:at least one pre-allocated grant occasion for random access channel-less, RACH-less, handover,a maximum of the number of the at least one measurement result used for determining usability of at least one pre-allocated grant occasion,a first threshold number indicating a number of the at least one measurement result required for determining the usability of the at least one pre-allocated grant occasion,a second threshold number, based on a determination of the number of continuous pre-allocated grant occasions of the at least one pre-allocated grant occasion being greater than or equal to a second threshold number, switching from a RACH-less handover to a random access channel-based, RACH-based, handover, the continuous pre-allocated grant occasions being determined to be unusable,a third threshold number, based on a determination of the number of continuous sets of pre-allocated grant occasions of the at least one pre-allocated grant occasion being greater than or equal to a third threshold number, switching from a RACH-less handover to a RACH-based handover, wherein all of the pre-allocated grant occasions in the continuous sets of pre-allocated grant occasions are determined to be unusable,a rule for determining the usability of the pre-allocated grant occasion,an indication indicating whether the terminal device is allowed to re-initiate a RACH-less handover, ora first threshold for a reference signal, RS, measurement configured for selecting a pre-allocated grant occasion for an initial uplink transmission during the RACH-less handover, a second threshold for the RS measurement configured for selecting a pre-allocated grant occasion for a re-transmission uplink transmission during the RACH-less handover, the first threshold being higher than the second threshold.35.A terminal device (600) , comprising:a processor (605) ; anda memory (610) , the memory (610) containing instructions (615) executable by the processor (615) , whereby the communication device (600) is operative to:initiate (410) a random access channel-less, RACH-less, handover; anddetermine (420) usability of at least one pre-allocated grant occasion for an uplink transmission, the at least one pre-allocated grant occasion being configured for the RACH-less handover.36.The terminal device (600) of claim 35, wherein the communication device (600) is  further operative to implement the method (400A) according to any of claims 2-15.37.A terminal device (600) , comprising:a processor (605) ; anda memory (610) , the memory (610) containing instructions (615) executable by the processor (615) , whereby the communication device (600) is operative to:initiate (460) a random access channel-less, RACH-less, handover; andbased on at least condition being met, determine (470) that a random access channel-based, RACH-based, handover is to be initiated.38.The terminal device of claim 37, wherein the communication device is further operative to implement the method (400B) according to any of claims 16-33.39.A network device (600) , comprising:a processor (605) ; anda memory (610) , the memory (610) containing instructions (615) executable by the processor (615) , whereby the communication device (600) is operative to:transmit (510) , to a terminal device, configuration information indicating at least one of the following:at least one pre-allocated grant occasion for random access channel-less, RACH-less, handover,a maximum of the number of the at least one measurement result used for determining usability of at least one pre-allocated grant occasion,a first threshold number indicating a number of the at least one measurement result required for determining the usability of at least one pre-allocated grant occasion,a second threshold number, based on a determination of the number of continuous pre-allocated grant occasions of the at least one pre-allocated grant occasion being greater than or equal to a second threshold number, switching from a RACH-less handover to a random access channel-based, RACH-based, handover, the continuous pre-allocated grant occasions being determined to be unusable,a third threshold number, based on a determination of the number of continuous sets of pre-allocated grant occasions of the at least one pre-allocated grant occasion being greater than or equal to a third threshold number, switching from a RACH-less handover to a RACH-based handover, wherein all of the pre-allocated grant occasions in the continuous sets of pre-allocated grant occasions are determined to be unusable,a rule for determining the usability of the pre-allocated grant occasion,an indication indicating whether the terminal device is allowed to re-initiate a RACH-less handover,a time window comprising a plurality of reference signal (RS) measurement periodicities, RACH-based handover being disabled within the time window, ora first threshold for a reference signal (RS) measurement configured for selecting a pre-allocated grant occasion for an initial uplink transmission during the RACH-less handover, a second threshold for the RS measurement configured for selecting a pre-allocated grant occasion for a re-transmission uplink transmission during the RACH-less handover, the first threshold being higher than the second threshold.40.A computer-readable storage medium (700) having instructions (615) stored thereon, the instructions (615) , which, when executed by at least one processor of a device, causes the device to perform the method (400A) according to any of claims 1-15, any the method (400B) according to any of claims 16-33, or the method (500) according to claim 34.