Apparatus and method for handover in a network

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. A method for a second base station in a network including a user equipment (UE), a first base station, and the second base station is disclosed. The method is used for performing random access channel-less (RACH-less) handover of the UE from a first base station to a second base station. The method includes obtaining a Condition Switching (CHO) configuration (e.g., an execution condition); determining an uplink (UL) grant configuration of the RACH-less; transmitting a UL grant of RACH-less to the first base station (e.g., in a handover request ACK message); and, on the basis of the CHO configuration, monitoring for a UL RACH-less transmission (e.g., an RRC Configuration Complex Message) from the UE or scheduling for a physical downlink control channel (PDCCH) allocation for the UE.

Description

TECHNICAL FIELD

[0001] Certain examples of the present disclosure provide one or more techniques for performing handover in a network. For example, certain embodiments of the present disclosure provide one or more techniques for performing random access channel-less (RACH-less) conditional handover (CHO) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) New Radio (NR) non-terrestrial network (NTN). BACKGROUND

[0002] 5G mobile communication technologies define wide frequency bands so that high transmission rates and new services are possible, and are implemented not only in "Sub 6GHz" such as 3.5GHz, but also in "Above 6GHz" including mmWave such as 28GHz and 39GHz, and even Terahertz bands. In addition, 6G mobile communication technologies are considered to be implemented not only in terrestrial networks but also in non-terrestrial networks (NTN) such as air planes, satellites, and the like.

[0003] At the early stage of developing 5G mobile communication technologies, in order to support services and to meet the requirements related to enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine- Type Communications (mMTC), standardization has been made on technologies such as: beamforming and massive MIMO for mitigating radio wave path loss and increasing radio wave transmission distance in mmWave; parameter sets (numerologies) for supporting dynamic operations for efficiently using mmWave resources and time slot formats; initial access techniques for supporting multi-beam transmission and wideband; definition and operation of BWP (BandWidth Part); new channel coding methods such as LDPC (Low Density Parity Check) code for large amount of data transmission and polar code for highly reliable transmission of control information; L2 pre-processing; and network slicing for providing a dedicated network dedicated to a specific service.

[0004] Currently, there are ongoing discussions on improving and enhancing the initial 5G mobile communication technologies supported by 5G mobile communication technologies, considering services to be supported by the 5G mobile communication technologies, and there has been physical layer standardization on technologies such as: V2X (Vehicle-to-Everything) for assisting driving determination based on information about the position and status of the vehicle transmitted by the vehicle by autonomous vehicles and enhancing user convenience; NR-U (New Radio Unlicensed) targeting system operation conforming to requirements related to regulations in unlicensed bands; NR UE power saving; non-terrestrial networks (NTN) that are UE-satellite direct communications for providing coverage in an area where communication with a terrestrial network is unavailable; and positioning.

[0005] Furthermore, standardization has been implemented for the following air interface architectures / protocols: Industrial Internet of Things (IIoT) for supporting new services through interaction and integration with other industries; IAB (Integrated Access and Backhaul) for nodes providing network service area extension by supporting wireless backhaul and access links in an integrated manner; mobile enhancements including conditional handover and DAPS (Dual Activation Protocol Stack) handover; and two-step random access (2-step RACH for NR) for simplifying the random access process. Standardization is also underway in system architectures / services for: 5G baseline architectures (e.g., service-based architectures or service-based interfaces) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies; and mobile edge computing (MEC) for receiving services based on UE location.

[0006] With the commercialization of 5G mobile communication systems, the number of connected devices will increase exponentially, thus it is anticipated that enhanced functionality and performance of 5G mobile communication systems, as well as the integrated operation of connected devices, will be necessary. To this end, new research is planned related to: Extended Reality (XR) for efficient support of AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality), etc.; 5G performance improvements and complexity reductions through the utilization of Artificial Intelligence (AI) and Machine Learning (ML); AI service support; Metaverse service support; and drone communication.

[0007] Furthermore, this development of 5G mobile communication systems will serve as a foundation for developing not only: new waveforms for providing coverage in the terahertz band of 6G mobile communication technology, such as multi-antenna transmission technology, array antennas, and large antennas for full-dimensional MIMO (FD-MIMO); metamaterial-based lenses and antennas for improving the coverage of terahertz band signals; high-dimensional spatial multiplexing technology using OAM (orbital angular momentum); and RIS (reconfigurable smart surfaces); but also: full-duplex technology for improving the frequency efficiency of 6G mobile communication technology and improving system networks; AI-based communication technology for system optimization by leveraging satellites and AI (artificial intelligence) from the design stage and internalizing end-to-end AI support capabilities; and next-generation distributed computing technology for providing services at complexity levels exceeding the limitations of UE operating capabilities by utilizing ultra-high-performance communication and computing resources. Summary of the Invention

[0008] Technical issues One aspect of the disclosure is to provide one or more techniques to perform a random access channel (RACH-less) conditional handover (CHO) in a 3rd Generation Partnership Project (3GPP) Fifth Generation (5G) New Radio (NR) non-terrestrial network (NTN).

[0009] Solution to the problem It is a purpose of certain examples of the disclosure to at least partially address, solve and / or mitigate at least one of the problems and / or disadvantages associated with the related art, e.g., at least one of the problems and / or disadvantages described herein. It is a purpose of certain examples of the disclosure to provide at least one advantage over the related art, e.g., at least one of the advantages described herein.

[0010] The disclosure is defined in the independent claims. Advantageous features are defined in the dependent claims. Embodiments or examples disclosed in the specification and / or the drawings that fall outside the scope of the claims are to be understood as examples useful for understanding the disclosure.

[0011] Other aspects, advantages, and salient features of the disclosure will become apparent to those skilled in the art from the following detailed description, taken in conjunction with the accompanying drawings.

[0012] Before undertaking the detailed description below, it can be advantageous to set forth definitions of certain terms and phrases used throughout this patent document: The terms “include” and “comprise,” and variations thereof, mean “including but not limited to”; the term “or” is inclusive, meaning and / or; the phrases “associated with” and “associated therewith” and variations thereof can mean includes, is included in, interconnect with, contains, is contained within, connected to or with, couples to or with, is communicable with, cooperates with, interleave, co-located with, is bound to or with, has, has a property of, or the like; and the term “controller” means any device, system or part thereof that controls at least one operation, such a device can be implemented in hardware, firmware or software, or some combination of at least two of the same. It should be noted that the functionality associated with any particular controller can be centralized or distributed, whether locally or remotely.

[0013] Moreover, various functions described below can be implemented or supported by one or more computer programs, each of which is formed from computer readable program code. The terms "application" and "program" refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof. The phrase "computer readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer readable medium" includes any type of media capable of being accessed by a computer, such as read only memory (ROM), random access memory (RAM), a hard disk drive, a compact disc (CD), a digital video disc (DVD), or any other type of memory. A "non-transitory" computer readable medium excludes wired, wireless, optical, or other communication links. Non-transitory computer readable media include media where data is permanently stored and media where data is stored and later overwritten, such as a rewritable optical disc or an erasable memory device.

[0014] Definitions for certain words and phrases are provided throughout this patent document, and include the following terms and phrases, which must be interpreted in light of this disclosure:

[0015] Advantages of the Invention According to embodiments of the disclosure, a terminal can efficiently perform communication. BRIEF DESCRIPTION OF DRAWINGS

[0016] For a more complete understanding of the present disclosure and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings in which like parts are marked with like numerals:

[0017] Figure 1 An NTN Release 17 architecture and scenarios are shown.

[0018] Figure 2 A simplified conditional handover procedure is shown.

[0019] Figure 3 A CHO handover using CondeventT1 is shown.

[0020] Figure 4a A type of RACH-less handover in which the UE is configured with uplink grant is shown, and Figure 4b A type of RACH-less handover in which the UE is configured to monitor the PDCCH of the target cell is shown.

[0021] Figure 5aA normal handover (HO) that performs RACH-less is shown, and Figure 5b A conditional handover (CHO) that performs RACH-less is shown, and the issue of when the target eNB should start listening for UL transmissions is highlighted.

[0022] Figure 6 Exemplary techniques for sending a CHO configuration from a source cell to a target cell are shown.

[0023] Figure 7 Exemplary techniques for sending a request for a target eNB to configure a CHO trigger are shown, which request is later received by the source eNB in a Handover Request Acknowledge (HANDOVER REQUEST ACKNOWLEDGE) message.

[0024] Figure 8 The validity duration of RACH-less is shown in an example where the UE cannot perform RACH-less but must complete the CHO using a random access procedure instead of RACH-less.

[0025] Figure 9 Exemplary techniques for collecting configuration (RRCReconfiguration) elements from different eNBs that represent configurations for different cells are shown.

[0026] Figure 10 Exemplary techniques for reducing the number of SIB31 elements using ephemeris identification (ID) are shown.

[0027] Figure 11 Exemplary techniques for including SIB31 elements outside of RRCReconfiguration in HandoverCommand so that the source eNB can create a separate list are shown.

[0028] Figure 12 A block diagram of an exemplary network entity that can be used in certain examples of the present disclosure is shown. DETAILED DESCRIPTION

[0029] NTN Overview One of the areas currently being developed in 3GPP 5G wireless technology is support for NTN. An NTN is a network in which one or more nodes (e.g., next generation (NG) radio access network (RAN) nodes) are provided by non-terrestrial infrastructure (e.g., satellites or high-altitude platform stations (HAPS)). Advantages of using an NTN include: (i) extending coverage to areas where traditional terrestrial networks have limited or no coverage (such as remote areas), (ii) providing continuous coverage in situations where traditional terrestrial networks cannot operate (such as during natural disasters), and (iii) enhancing overall reliability, resilience, and capacity when used in conjunction with existing terrestrial networks.

[0030] Satellite networks implementing network nodes provide coverage by forming one or more radio beams that define a coverage area or cell on the surface of the Earth in a “footprint.” An NTN cell can be earth-moving (i.e., moving over the surface of the Earth according to the motion of the satellite, such as in the case of lower earth orbit (LEO) satellites), earth-fixed (i.e., a fixed area of the Earth’s surface, such as in the case of geosynchronous equatorial orbit (GEO) satellites), or quasi-earth-fixed (i.e., a fixed area of the Earth’s surface, but only for a limited time as the satellite passes).

[0031] Overview of IoT NTN and NR NTN IoT NTN is a 3GPP study and work item in 3GPP Release 17 (RP-202689, RAN#90, December 2020) to provide NTN access for evolved universal terrestrial radio access network (E-UTRAN) IoT devices (e.g., narrowband (NB) IoT and long term evolution machine type communications (LTE-M) including enhanced machine type communications (eMTC)). As described in 3GPP RP-202689, for many different industries, IoT operation is critical in remote areas with low / no cellular connectivity. The capabilities of NB-IoT and eMTC are well suited for many applications, but some applications can require satellite connectivity to provide coverage beyond terrestrial deployments. NR NTN is a work item in Release 17 to specify adaptations to allow NR to operate over NTN (RP-211557, RAN#91-e, March 2021).

[0032] Following the work item in Release 17, there are work items in Release 18 for enhancing NR NTN (RP-220953, RAN#95-e, March 2022) and IoT NTN (RP-220979, RAN#95-e, March 2022).

[0033] Overview of NB-IoT and LTE-M NB-IoT is a 3GPP defined network based on 4th Generation (4G) E-UTRAN that supports ultra-low complexity devices with very narrow bandwidth introduced in 3GPP Release 13. Use cases for NB-IoT are to serve massive IoT applications, e.g., requiring support for enhanced coverage, low power operation, and large number of devices access. Some of the features introduced are: • Support for enhanced coverage by low bandwidth and very large number of repetitions.

[0034] • Power efficient operation by allowing the user equipment (UE) to sleep very long times, relaxed requirements, and more efficient signaling for cell establishment.

[0035] LTE-M or eMTC is a 3GPP defined network that is an extension of 4G E-UTRAN that supports low complexity devices with narrower bandwidth than normal LTE and further simplification of procedures. Similar to NB-IoT, use cases are to serve massive IoT, but with more capabilities. Unlike NB-IoT, which is a brand new device type with major changes in the air interface, LTE-M inherits most of the features of regular LTE devices, but with several adjustments for low complexity considerations.

[0036] Overview of NTN system information As NTN has multiple NTN specific information elements that are needed only at access to the NTN cell, and also due to the quite large information elements, it was agreed that a new system information block (SIB) is needed.

[0037] In NR NTN, SIB19 contains the information needed to access the NTN cell: • 3GPP TS 38.331 V17.3.0 o SIB19 ■ SIB19 Contains satellite assistance information for NTN access.

[0038] ■ SIB19 The information elements are shown in Table 1 below.

[0039] [Table 1]

[0040] • Descriptions of the various fields set forth in Table 1 are provided in Table 2 below.

[0041] [Table 2]

[0042] In IoT NTN, SIB31 contains the information needed to access the IoT NTN cell: • 3GPP TS 36.331 V17.3.0 SystemInformationBlockType31 ■ The IE SystemInformationBlockType31 contains satellite assistance information for the serving cell. SystemInformationBlockType31 is only signalled in NTN cells.

[0043] SystemInformationBlockType31 The information elements are shown in Table 3 below.

[0044] [Table 3]

[0045]

[0046] The description of the various fields set out in Table 1 is provided in Table 4 below.

[0047] [Table 4]

[0048]

[0049] The system information contains the following: • Serving cell ephemeris elements. This allows the UE to compute the satellite position for Doppler and time pre-compensation. This information can be provided in two formats: o PVT format. This describes the (X, Y, Z) position as well as the velocity vector (vX, vY, vZ).

[0050] o Orbital parameters. This describes the orbital motion of the satellite which is then used to infer the satellite position.

[0051] • TA common parameters. This provides a common timing advance parameter which is introduced to compensate for the feeder link delay. The signalling includes the following (occupying 57 bits in total): o Absolute TA common (23 bits).

[0052] o Drift of TA common, defining how TA common drifts, i.e. the first derivative of TA common (19 bits).

[0053] o Variation of TA common, defining how TA common varies, i.e. the second derivative of TA common (15 bits).

[0054] • Synchronization validity duration. This is used to define the validity time length of the ephemeris and TA common.

[0055] • Epoch time. This defines when the synchronization validity duration should start.​​

[0056] • K-Offset. This is the scheduling offset of the timing relationship in NTN.

[0057] • K-Mac. This is the scheduling offset used when the downlink and uplink frame timing are not aligned.

[0058] • NR NTN specific information also includes (as part of 3GPP TS 38.331): • T-Service (signaled in SIB3 in IoT NTN).

[0059] • Reference location and distance threshold. This is used for location based measurement initiation in RRC IDLE and RRC CONNECTED mode.

[0060] • Neighbor cell ephemeris. This is used for idle mode measurements.

[0061] Overview of acquisition of NTN system information When ephemeris information is constantly changing due to the movement of NTN payload (e.g., satellites), it can be necessary to ensure that the UE is properly synchronized. Therefore, every time the UE connects to an eNB, the UE can need to read system information (e.g., SIB19 or SIB31).

[0062] In IoT NTN, every time SIB31 is read, a timer (T317) associated with ephemeris elements is started. Upon expiry of T317, the UE is no longer considered synchronized and should reacquire SIB31 in order to remain synchronized.

[0063] In IoT NTN, since IoT UEs (LTE-M and NB-IoT UEs) are not expected to be able to acquire system information in connected mode, the UE tunes away and can be unreachable when reading SIB31.

[0064] If an IoT NTN UE cannot read SIB31 within a timer (T318) with a configured duration, the UE performs a radio link failure (RLF), similar to other cases where RLF is performed.

[0065] In NR NTN, the UE ensures that it has the most recent ephemeris by the UE implementation reading SIB in time (SIB19 in NR).

[0066] Overview of NTN handover NTN handover in IoT NTN is similar to normal handover. The handover is typically triggered by a measurement report sent by the UE, triggered by conditions configured by the eNB.

[0067] The handover command sent to the UE is an RRC mobilityControlInfo message. RRCReconfiguration Element. mobilityControlInfo Contains information like target cell physicalCellld, target cell carrier and bandwidth, and timers how long the handover can take and RACH configuration for performing the handover.

[0068] Since the handover command for the UE should provide everything needed to perform basic operations in the cell, in NTN it is agreed that SIB31 needs to be provided in RRCReconfiguration messages when performing mobility.

[0069] The whole RRCReconfiguration message is configured by the target eNB and provided in the RRC HandoverCommand message (which is included in the X2 message HANDOVER REQUEST). To allow UE capability compatible configuration, the target cell includes the UE capabilities in the HandoverPreparationInformation message (included in the HANDOVER REQUEST ACKNOWLEDGE X2 message) sent by the source eNB to the target eNB when requesting to perform the handover.

[0070] Overview of conditional handover Conditional handover is introduced in Release 16 for both E-UTRAN and NR. Conditional handover is a way to achieve more reliable handover. The complete conditional handover procedure can be seen in Figure 2 .

[0071] The steps involved in conditional handover can include: • 1. The source eNB decides to configure conditional handover for the UE.

[0072] • 2. Send handover request to the target eNB. Normally one handover request needs to be sent to the eNB per cell. This means that the source eNB can have to send multiple HANDOVER REQUEST messages to each eNB. The source eNB includes the RRC message HandoverPreparationInformation (handover preparation information) in the handover request message. This contains UE capabilities, access stratum configuration, etc.

[0073] • 3. Similar to the above, the target eNB sends an answer (HANDOVER REQUEST ACKNOWLEDGE) per cell. This message contains the complete RRCConnectionReconfiguration (or RRCReconfiguration) message to be used in the target cell.

[0074] • 4. The source eNB uses all the responses received from the eNBs to decide the conditional handover configuration. This includes deciding the CHO execution condition.

[0075] • 5. The RRCConnectionReconfiguration includes the CHO configuration.

[0076] • 6. RRCConnectionReconfigurationComplete (or RRCReconfigurationComplete) that acknowledges the reception of the CHO configuration (no error or success). For normal handover, this would be sent to the target cell only after the handover is completed.

[0077] • 7. Here, the UE evaluates the CHO condition. This can take very long time until the CHO condition for a cell is met. As an example, the UE can be configured with CHO configuration while connected to a gNB and maintain these configurations for a long time.

[0078] • 8. When the CHO condition is met for a given cell, the UE synchronizes and connects with that cell through random access and sends the RRCConnectionReconfigurationComplete to the target cell (i.e., target eNB or gNB).

[0079] The initially introduced conditional handover events are as follows: • Conditional handover event A3 (CondEventA3): Based on event A3 (unconditional handover event). This is defined as [3GPP TS 38.331, V17.3.0] “Neighbour becomes offset better than SpCell” • Conditional handover event A5 (CondEventA5): Based on event A5 (unconditional handover event). This is defined as [3GPP TS 38.331, V17.3.0] “SpCell becomes worse than threshold1 and neighbour becomes better than threshold2”

[0080] Overview of NR NTN conditional handover enhancements For NR NTN, a new set of conditional handover conditions is introduced specifically for NTN. These are as follows: • Conditional handover event T1 (CondEvent T1): o This is defined as (3GPP TS 38.331, V17.3.0) “CondEvent T1 : The time measured at the UE becomes greater than a configured threshold t1-Threshold but less than t1-Threshold + duration” o The conditional handover event is considered fulfilled when the time at the UE is greater than t1-Threshold but less than t1-Threshold + duration. After t1-Threshold + duration, the UE no longer considers the condition fulfilled.

[0081] o This is useful because the movement of satellite cells has a strong predictability as they travel along their orbit. This means that if the UE position is known, there is a strong predictability when it should be necessary to perform a handover. Therefore, the network can pre-configure when a conditional handover should be performed, saving signaling when the coverage can be less good and ensuring that a handover is performed even when there is a momentary interruption when the UE is at the cell edge. This can be seen in Figure 3 .

[0082] o The conditional event T1 cannot be configured alone but can need to be paired with a radio frequency (RF) based conditional event, such as conditional events A3-A5. This is to avoid any accidental handover to a cell with low signal strength.

[0083] • Conditional handover event D1 (CondEvent D1): o This is defined as: “CondEvent D1 : The distance between the UE and the reference location referenceLocation1 becomes greater than a configured threshold distanceThreshFromRefece1 and the distance between the UE and the reference location of the conditional reconfiguration candidate referenceLocation2 becomes shorter than a configured threshold distanceThreshFromRefece2 ;” o This is related to the fact that due to long-term RF characteristics tend to be flat on satellite cells (e.g., similar RF characteristics), the UE position can be more advantageous for mobility purposes compared to (only) using RF characteristics.

[0084] o This event allows triggering a measurement report when the UE is outside a certain area, and this area can be, for example, the same area as the area of the satellite cell.

[0085] o The conditional event D1 cannot be configured alone but can need to be paired with an RF based conditional event, such as conditional events A3-A5. This is to ensure that a handover to a cell with low signal strength is not performed.

[0086] Overview of RACH-less RACH-less is a handover method introduced in E-UTRAN Release 14. RACH-less enables the UE to skip performing random access during handover. In certain cases, this is to improve the latency of handover.

[0087] In certain cases related to timing advance (TA), RACH-less can be performed: • When the TA to the target cell is equal to zero.

[0088] • When the TA to the target cell is equal to the TA of the source cell.

[0089] It can be said that RACH-less has two different approaches: • A continuous uplink grant is configured to be used by the UE to send the first message after handover, which is RRCReconfigurationComplete and optionally any data. For this case, the UE is configured with an uplink grant ( ul-Grant ), a scheduling interval ( ul-SchedInterval ), and how many occasions are configured ( numberOfConfUL- Processes ).

[0090] • The UE is scheduled to be synchronized with the cell without sending any message to the target cell. Instead, the UE starts listening to the physical downlink control channel (PDCCH) to get an assignment from the target cell. The assignment can be for a downlink physical downlink shared channel (PDSCH) transmission or an UL grant for the UE to send a physical uplink shared channel (PUSCH).

[0091] The following fields configure RACH-less: • targetTA • numberOfConfUL-Processes • ul-SchedInterval • ul-StartSubframe • ul-Grant The above information is presented as background information only to assist with an understanding of the present disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as prior art with regard to the present disclosure.

[0092] The detailed description set forth below Figures 1 to 12 and the various embodiments described therein are presented only by way of illustration and should not be construed as limiting the scope of the disclosure. Those skilled in the art will understand that the principles of the disclosure can be implemented in any suitably arranged system or device.

[0093] The following description of examples of the disclosure, with reference to the accompanying drawings, is provided to assist in a comprehensive understanding of the disclosure as defined by the claims. The description includes various specific details to assist in that understanding but these are to be considered in the context of the disclosure. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the examples described herein can be made without departing from the scope of the disclosure.

[0094] The same or similar components can be denoted by the same or similar reference numerals, although they can be shown in different drawings.

[0095] For the sake of brevity and clarity, detailed descriptions of techniques, structures, functions, operations or processes known in the art can be omitted, as they can be considered as too familiar to one skilled in the art.

[0096] The terms and words used herein are not limited to the bibliographical or standard definitions, but are used only to enable a clear and consistent understanding of the disclosure.

[0097] Throughout the description and claims of this specification, the words "comprise", "contain", and "include", and variations such as "comprises", "comprising", "contains", "containing", "includes" and "including", mean "including but not limited to", and do not exclude other features, elements, components, integers, steps, processes, operations, functions, characteristics, properties or combinations thereof.

[0098] Throughout the description and claims of this specification, the singular forms "a", "an" and "the" include plural referents unless the context requires otherwise. For example, reference to "the object" includes a reference to one or more objects.

[0099] Throughout the description and claims of this specification, the general meaning of the language "X for Y" (where Y is some action, process, operation, function, activity or step, and X is some means for performing that action, process, operation, function, activity or step) includes means adapted, configured or arranged specifically, but not necessarily exclusively, to perform Y.

[0100] Features, elements, components, integers, steps, processes, operations, functions, characteristics, properties, and / or combinations thereof described in connection with a particular aspect, embodiment, example or claim are, unless otherwise stated, applicable to all other aspects, embodiments, examples or claims, mutatis mutandis.

[0101] Those skilled in the art will understand that the techniques described herein can be used in any suitable combination.

[0102] Certain examples of the present disclosure provide one or more techniques for performing handover in a network. For example, certain examples of the present disclosure provide one or more techniques for performing RACH-less CHO in a 3GPP 5G NR NTN. However, those skilled in the art will appreciate that the present disclosure is not limited to these examples and can be applied to any suitable system or standard, e.g., one or more existing and / or future generation wireless communication systems or standards, including any existing or future version of the same standards specification, e.g., 3GPP 5G.

[0103] The functions of the various network entities and other features disclosed herein can be applied to corresponding or equivalent entities or features in the same or any other suitable communication system or standard. A corresponding or equivalent entity or feature can be regarded as an entity or feature that performs the same or similar role, function, or purpose within a network. For example, the functions of a base station, etc. (e.g., eNB, gNB, NB, RAN node, access point, wireless point, transmission / reception point, central unit, distributed unit, radio unit, remote radio head, etc.) in the following examples can be applied to any other suitable type of entity that performs RAN functions, and the functions of a UE, etc. (e.g., electronic device, user equipment, mobile station, subscriber station, customer premises equipment, terminal, remote terminal, wireless terminal, vehicle terminal, etc.) in the following examples can be applied to any other suitable type of device.

[0104] A particular network entity can be implemented as a network element on a dedicated hardware, a software instance running on a dedicated hardware, and / or a virtualized function instantiated on a suitable platform, e.g., on a cloud infrastructure.

[0105] Those skilled in the art will appreciate that the present disclosure is not limited to the specific examples disclosed herein. For example: • The techniques disclosed herein are not limited to 3GPP 5G.

[0106] • One or more entities in the examples disclosed herein can be replaced with one or more alternative entities that perform equivalent or corresponding functions, procedures, or operations.

[0107] • One or more pieces of information in the examples disclosed herein can be replaced with one or more alternative messages, signals, or other types of information carriers that convey equivalent or corresponding information.

[0108] • One or more additional elements or entities can be added to the examples disclosed herein.

[0109] • In certain examples, one or more non-essential elements or entities can be omitted.

[0110] • In an example, a function, process, or operation of a particular entity can be divided among two or more separate entities in alternative examples.

[0111] • In an example, a function, process, or operation of two or more separate entities can be performed by a single entity in alternative examples.

[0112] • In an example, information carried by a particular message can be carried by two or more separate messages in alternative examples.

[0113] • In an example, information carried by two or more separate messages can be carried by a single message in alternative examples.

[0114] • In alternative examples, the order of performing operations and / or the order of sending messages can be modified, if possible.

[0115] Certain examples of the disclosure can be provided in the form of apparatuses / devices / network entities configured to perform one or more defined network functions and / or methods thereof. Certain examples of the disclosure can be provided in the form of systems (e.g., networks or wireless communication systems) including one or more such apparatuses / devices / network entities and / or methods thereof.

[0116] In Release 18 IoT NTN, 3GPP is working on introducing conditional handover for IoT NTN, as seen from WID [RP-220979, RAN#95-e, March 2022], which is incorporated herein by reference: • 4.1.2 Mobility Enhancements o The following mobility enhancement objectives are listed.

[0117] ■ Use Rel-17 (TN) NB-IoT, eMTC as baseline, support neighbor cell measurements and corresponding measurement triggering prior to RLF. [RAN2] ■ Re-use solutions introduced in Rel-17 NR NTN for mobility enhancements for eMTC with minimum necessary changes to adapt them for eMTC [RAN2] Define UE RRM core requirements for the above mobility enhancement features [RAN4]. ■ For scenario (1), from RAN1 perspective, RACH-less handover is feasible when it is possible to maintain UE UL transmission synchronization by applying pre-compensation using assistance information (e.g., epoch time, ephemeris, common TA) of the target cell, assuming the following notes can be fulfilled.

[0118] Conditional handover is enhanced in NR NTN by introducing time-based conditional handover execution, where the conditional handover event is based in part on the time having exceeded a given time point.

[0119] RACH-less and NTN have been discussed several times, mainly due to the fact that timing advance can have some special properties in NTN. First, since both cells are from the same satellite, the timing advance to the target cell can be exactly equal to the source cell timing advance. In fact, in many scenarios, the most common type of handover will be an intra-satellite handover. Second, the timing advance is calculated by the UE using the satellite ephemeris and the UE position. This means that if the UE has an accurate UE position and satellite ephemeris, it can perform RACH-less handover well.

[0120] RACH-less handover has been recently discussed in 3GPP, with a positive reply for using RACH-less handover in NR NTN. As a reply to a Liaison (LS R2-2300020) from RAN2 to RAN1, the following is stated: ● For scenarios (2) - (4), from RAN1 perspective, RACH-less handover is feasible when it is possible to maintain UE UL transmission synchronization by applying pre-compensation using assistance information (e.g., epoch time, ephemeris, common TA) of the target cell, assuming the following notes can be fulfilled. NOTE 1: RAN1 assumes that the RAN4 UL synchronization requirements specified in Table 7.1C.2-1 of TS 38.133 apply for the first UL transmission in the target cell. NOTE 2: It is expected that the gNB provides the UE with valid assistance information of the target cell.

[0121] ● NOTE 3: It is expected that the gNB ensures that the UE can perform UL transmission while respecting the common TA and UE processing time. Intra-satellite handover with same feeder link. I.e., same gateway / gNB ​

[0122] ● ​ ​

[0123] ● ​

[0124] ● ​ ​

[0125] Where scenarios 1-4 are: ● (1) ​ ● (2) Intra-satellite handover with different feeder link, i.e. with gateway / gNB handover ● (3) Inter-satellite handover with gateway / gNB handover ● (4) Inter-satellite handover with same gateway / gNB If RACH-less and CHO are configured together (which is very useful to reduce RACH congestion), there can be some problems. In CHO, the source eNB decides the conditions of the CHO (3GPP TS 36.300, V17.3.0): ● 7. The source eNB sends to the UE an RRCConnectionReconfiguration message containing the configuration of CHO candidate cells and CHO execution conditions. The source eNB decides the conditions for performing CHO and adds these conditions to the RRC message sent to the UE. Figure 5a CHO configuration sent by the source cell (source eNB, NG RAN or gNB)

[0126] The problem is that, for CHO and RACH-less, the source eNB will determine the execution conditions of CHO, but the target eNB decides whether to use RACH-less. The target eNB must know when to perform RACH-less handover to begin blind decoding of UL services or to use PDCCH to schedule the UE to perform RACH-less handover.

[0127] Figure 6 and 5b Two types of HOs are illustrated: (a) a normal HO with RACH-less capabilities, and (b) a CHO with RACH-less capabilities. In (a), the UE uses RACH-less resources that can always be listened to, and the target eNB can directly begin listening to UL transmissions or schedule the UE to perform a RACH-less handover. However, in (b), the target eNB does not know when it should begin listening to UL RACH-less transmissions from the UE. Without the ability to know when to begin listening to UL RACH-less authorizations, the target eNB may have to listen for a very long time.

[0128] The problem is similar for RACH-less scenarios where the UE listens to PDCCH allocations (i.e., no UL authorization is configured for RACH-less). In this case, the target eNB must blindly transmit PDCCH allocations for an extended period.

[0129] Signal notification for CHO ephemeris One issue related to signaling ephemeris for CHO (Conditional Handover) is that in IoT NTN, the current method for signaling ephemeris for handover involves including the ephemeris via a dedicated SIB31. For CHO, this means each cell has its own associated ephemeris element. This implies that if eight cells are included in a CHO configuration, eight ephemeris elements might need to be signaled. This can make the conditional handover command excessively large.

[0130] Some examples in this disclosure provide various techniques for implementing RACH-less and CHO.

[0131] Many examples in this disclosure involve the use of conditional switching event T1, as this is the most likely candidate for use with RACH-less. However, those skilled in the art will understand that the techniques disclosed herein are not limited to this. For example, future events may utilize time-based and other RF and / or location-based conditional switching events that can be taken into account.

[0132] Some of the examples in this disclosure can also be applied to other cases where time-sensitive switching configurations are given together with CHOs.

[0133] Various examples of the present disclosure relate to RACH-less using UL grant. However, those skilled in the art will appreciate that other ways of configuring the UE to listen to PDCCH and then the target eNB sending PDCCH containing UL grant are also applicable.

[0134] Various examples of the present disclosure relate to using eNB (4G E-UTRAN). However, those skilled in the art will appreciate that the techniques disclosed herein can be equally applicable to gNB or 5G RAN (5G NR). The techniques can also be applicable to eMTC / LTE-M UE, or 5G NR UE, or E-UTRAN UE. Furthermore, while the techniques are described in the context of NTN, they can also be applicable outside of NTN, e.g., in terrestrial networks (e.g., regular 5G networks).

[0135] Certain examples of the present disclosure provide a method for a second base station in a network comprising a user equipment (UE), a first base station, and the second base station, the method for performing a random access channel (RACH-less) handover of the UE from the first base station to the second base station, the method comprising: obtaining a conditional handover (CHO) configuration (e.g., a conditional execution); determining an uplink (UL) grant configuration for RACH-less; sending the UL grant for RACH-less to the first base station (e.g., in a HANDOVR REQUEST ACK (handover request acknowledgement) message); and listening for an UL RACH-less transmission from the UE (e.g., a RRCConnectionReconfigurationComplete message) or scheduling an allocation of a physical downlink control channel (PDCCH) to the UE based on the CHO configuration.

[0136] In certain examples, obtaining the CHO configuration can comprise one or more of: generating a new CHO configuration; identifying an existing CHO configuration; modifying an existing CHO configuration; and updating an existing CHO configuration.

[0137] In certain examples, obtaining the CHO configuration can comprise receiving a CHO execution condition from the first base station (e.g., in a handover request (HANDOVER REQUEST) message).

[0138] In certain examples, obtaining the CHO configuration can comprise: receiving a request from the first base station to determine a CHO execution condition (e.g., in a HANDOVR REQUEST message); determining the CHO execution condition in response to the request; and sending the CHO execution condition to the first base station (e.g., in a HANDOVR REQUEST ACK message).

[0139] In certain examples, the CHO configuration can include an execution condition according to a time-based conditional event (e.g., CHO event T1), the method can include obtaining a time threshold (e.g., t1-Threshold), and can perform the listening for the UL RACH-less transmission based on the time threshold.

[0140] In certain examples, the method can further include determining, based on the CHO configuration, whether a RACH-less handover and / or a conditional handover should be used; and transmitting, to the first base station, an indication of a result of the determination.

[0141] In certain examples, the method can further include determining, based on the received CHO configuration, whether to obtain a different CHO configuration.

[0142] In certain examples, the network can include a non-terrestrial network (NTN), and the second base station can be associated with an NTN cell.

[0143] Certain examples of the present disclosure provide a base station configured to perform a method according to any of the examples, aspects, embodiments, and / or claims disclosed herein.

[0144] Certain examples of the present disclosure provide a network (or wireless communication system) including a first base station, a second base station, and a UE according to any of the examples, aspects, embodiments, and / or claims disclosed herein.

[0145] Certain examples of the present disclosure provide a computer program comprising instructions which, when the program is executed by a computer or processor, cause the computer or processor to carry out a method according to any of the examples, aspects, embodiments, and / or claims disclosed herein.

[0146] Certain examples of the present disclosure provide a computer or processor readable data carrier having stored thereon a computer program according to any of the examples, aspects, embodiments, and / or claims disclosed herein.

[0147] RACH-less and CHO ○ CHO execution conditions In certain examples, the CHO execution condition is sent from the source to the target eNB (or NG RAN, gNB) over X2 (or Xn), as shown in HandoverPreparationInformation , for example, as a new information element (IE) included in the Handover Request message (and / or any other suitable newly defined or existing Xn / X2 message) No CHO and RACH-less supported, CHO conditions not suitable, , or any other suitable naming. In Figure 2 one example of including a new IE can be seen in the following specification example #1.

[0148] Upon reception of the new IE, the target eNB (or NG RAN, gNB) can use this information for multiple reasons, e.g.: • If RACH-less is configured, use this information to listen for future RACH-less UL transmissions, or to schedule future PDCCH allocations for the UE.

[0149] • Configure a suitable RACH-less HO configuration.

[0150] o For example, consider CHO triggering conditions, the target eNB (or NG-RAN, gNB) configures UL grants for RACH-less.

[0151] • Configure (or modify or update) suitable CHO execution conditions.

[0152] o For example, consider RACH-less HO configuration and / or other information available at the target eNB (or NG RAN or gNB). For example, information related to the UE (mobility, speed, etc.).

[0153] • Confirm (or decide) whether RACH-less HO should be used.

[0154] o This decision is reported (or indicated) to the source eNB (or NG RAN, gNB). For example, included in the HANDOVER REQUEST ACKNOWLEDGE message (and / or any other suitable newly defined or existing Xn / X2 message).

[0155] • Confirm (or decide) whether the conditional handover configuration is suitable or another configuration is more suitable.

[0156] • Send recommendations to the source eNB (or NG RAN, gNB) when modifying (or updating) the configured (or used) CHO execution conditions.

[0157] o For example, consider adjusting CHO execution conditions with the UL grants for RACH-less configured by the target eNB (or NG RAN, gNB).

[0158] • Reject conditional handover.

[0159] o For example, include a suitable cause value in the HANDOVER REQUEST FAILURE. (New cause: Figure 3 or any other suitable naming).

[0160] The steps are as follows: • 1. The source eNB decides to configure conditional handover for the UE.

[0161] • 2. The handover request is sent to the target eNB containing the CHO execution conditions. This can be the full set of execution conditions (up to 2 execution conditions), or just one execution condition, i.e. the most important execution condition.

[0162] • 3. The target eNB decides whether to use the RACH-less configuration or not, as explained in the example above. The target eNB uses the CHO execution conditions to determine when to listen for UL RACH-less transmissions or schedule PDCCH assignments to the UE.

[0163] Steps 5-9 can be performed similarly to the corresponding steps of t1 - threshold and / or Duration .

[0164] The source eNB requests whether RACH-less can be used over X2 (or Xn). The target eNB can respond whether RACH-less is suitable or not, depending on the conditions.

[0165] In some examples, CHO and RACH-less can only be used together with a timer-based handover using the condition event T1. The source eNB sends condEventT1 , CondEventT1 or the full configuration CondEventT1 (if used), or as described above, Figure 7 configuration. Then, the source eNB has to use Duration . This can be seen in the specification example #2 below. Another wording for this is that when the network (set of eNBs) configures RACH-less and CHO, condEventT1 is to be included.

[0166] In some examples, the CHO execution conditions are included in the access stratum configuration in the HandoverPreparationInformation as if the UE is currently configured with the conditions (this message shall typically reflect the current configuration of the UE). In order for the UE to know that the current configuration has not been configured, but just to try to communicate the suggested configuration, the HandoverPreparationInformation message can contain a flag to indicate that the included CHO execution conditions have not been configured, but are suggested CHO execution conditions.

[0167] The CHO configuration sent by the target cell In certain examples, the CHO execution condition is sent from the target cell to the source cell over X2 (or Xn). The execution condition or part of the execution condition is configured by the target eNB. As a special example, the target eNB only determines condEventT1. This can be, for example, if the target eNB has determined that RACH-less should be used with CHO, then the target eNB will include condEventT1 that the source eNB should configure. If the source eNB continues to configure CHO, the source eNB must utilize the target eNB condEventT1 as one of the condition events (up to 2 events can be configured to be fulfilled for a single cell CHO condition to be fulfilled). This makes the target eNB fully aware of when to start listening for UL transmissions or when to start scheduling UEs with PDCCH transmissions.

[0168] As a specific example, if RACH-less is used, CondEventT1 can be configured by the target eNB. The target eNB first determines that RACH-less will be beneficial and that the UE is capable of RACH-less. Then, the target eNB determines the time at which the event should be completed.

[0169] The source eNB can optionally request the CHO configuration to be configured by the target cell. This can be seen in the following specification example #2 and Duration The conditional handover event trigger is only sent if the target cell determines that a conditional handover event trigger can be needed. Otherwise, the source cell configures CHO as needed.

[0170] In certain examples, the eNB (gNB, NG RAN) configures the above behavior in the X2 (Xn) setup (using X2 / XN SETUP REQUEST and X2 / XN SETUP RESPONSE) when CHO is executed. This means that the eNB can indicate that the eNB wants the CHO execution condition to be sent to the eNB or that the eNB wants to determine the CHO condition when another eNB wants to execute CHO. This can include the above conditions.

[0171] Further examples when combining CHO and RACH-less If the Figure 8 expiration of condEventT1 and the UE is configured with RACH-less, the UE can use RACH to perform handover to the selected target eNB. In other words, if the numberOfConfUL-Processes expiration of condEventT1, RACH-less will not be used. This can also be considered that the RACH-less configuration is valid during the conditional handover event T1.

[0172] In certain examples, a validity duration for RACH-less is included for the UE. Outside the duration of RACH-less, normal handover is used. This can be used to limit how long RACH-less can be used in order for the target eNB to save resources. This technique is shown in ul-SchedInterval RACH-less validity duration can be defined in the following ways: • A single point in time (defined by a specific time, a specific system frame number (SFN) or subframe) at which RACH-less cannot be used / the RACH-less configuration is removed / an indication is issued to the medium access control (MAC) that no RACH-less handover is to be performed.

[0173] • A single point in time at which RACH-less configuration can be used. This can be used by the current RACH-less configuration with fields such as applyTA- and NTN which give the number of UL procedures that can be transmitted.

[0174] • A time window defined by a start point and a duration (defined via a specific time or a specific SFN, subframe and duration or number of subframes) during which RACH-less can be performed. This can be seen in the following specification example #5.

[0175] The above can be used to make RACH-less consume an appropriate amount of resources. For example, the RACH-less validity duration can be in the middle of the duration of the CondEventTl and only used in this time window as a way to optimize the resources used. If the conditional handover event is met before the RACH-less validity duration, the UE performs normal handover using random access.

[0176] The above can also be valid for the case where the UE is not configured with UL grant for RACH-less but is configured to listen to PDCCH. In this case, the UE can be configured to listen to PDCCH for a specific duration and if nothing is received, the UE continues to perform random access.

[0177] Due to the above reasons, the validity duration of RACH-less can be quite long during which the signal quality can change significantly such that the RACH-less scheme is less suitable. Therefore, in certain examples, a threshold is introduced to configure the UE to perform conditional handover of normal random access procedure. The threshold can be based on a reference signal received power (RSRP) threshold, where if the RSRP with the target cell is below the threshold, RACH-less handover is not performed and a normal random access procedure is used.

[0178] The validity duration can be configured by the target eNB and / or source eNB using the techniques described above under the heading "RACH-less and CHO".

[0179] In addition, certain fields of RACH-Skip (RACH-Skip) can be extended when used with CHO, as further seen in the following specification example #6: • numberofConfUL-Processes - this is the number of UL grants provided.

[0180] o Value: integer (1..16) o In an alternative example, if the validity duration of RACH-less is defined, this field is not included. Thus, the UE assumes that the UE can send as many UL grants as allowed by the validity duration.

[0181] • Different types of ul-Grant are included o Currently, the uplink grant only uses a specific uplink grant that only contains a limited amount of possibilities for the target eNB to configure the UE.

[0182] • Repetition configuration o This allows for repetition during RACH-less, which can be essential for many IoT use cases.

[0183] o This can include repetition for PDCCH monitoring, or repetition of UL transmissions contained in the UL grant.

[0184] o It can also configure whether the UE should be in coverage enhancement (CE) mode A or CE mode B, which controls the maximum number of repetitions of the configured repetitions.

[0185] • TargetTA o For NTN UEs, it can be indicated that the NTN UE should apply a timing advance calculated by the UE from the UE's position and ephemeris, as done for normal handover when performing random access. This can be a separate flag, such as Figure 9 Figure 10 In another case, when these fields are not present, it can indicate that the UE should follow the timing advance described above.

[0186] One issue with CHO compared to normal handover is that CHO requests are typically sent to too many cells / eNBs, since there are typically multiple potential cells that the UE will evaluate to perform handover to. In case RACH-less with CHO is used, this means that it is not certain that the UE will select one cell and handover to that cell. This means that RACH-less resources that have been reserved in the target eNB can be wasted. Therefore, the target eNB can need to have assistance information sent to the target eNB to take into account whether RACH-less is suitable, e.g.: • How many cells the source eNB is sending CHO requests to.

[0187] • For example, if the source eNB sends a handover request indicating that requests are sent to 6 cells, the target eNB can estimate the likelihood (or chance or probability) of performing CHO as 1 / 6, which can be used to determine whether RACH-less is suitable. As an example, the target eNB can consider that the chance that the RACH-less resource is valuable is too low and therefore will decide not to configure RACH-less resources.

[0188] • For example, this can be a flag indicating that a particular target cell is the only cell requested to be configured for CHO.

[0189] • The likelihood that the UE will perform handover to a particular target cell.

[0190] • Whether the UE is likely to remain in RRC connected mode in order to perform CHO.

[0191] • This can be important in some cases where the traffic sent is not very high and there is a likelihood that the UE will not remain in RRC connected mode and not perform any CHO.

[0192] • This can be signaled implicitly by including the buffer status of the UE or traffic characteristics.

[0193] • In case a location dependent conditional handover event (CondEventD1) is configured: • The location of the UE and additionally the speed and direction of the UE.

[0194] In some examples, when RACH-less with CHO is configured, there can be requirements related to the signaled ephemeris. For example, this can be that the validity duration of the ephemeris is smaller compared to normal operation. If the ephemeris is not valid for long enough, RACH-less can not be performed, but normal handover using random access can be performed.

[0195] In certain examples, the UE indicates to the source cell (or source eNB) whether the ephemeris in the CHO configuration has expired. This can allow the source cell (or source eNB) to retransmit the ephemeris, e.g. by reconfiguring the CHO configuration for that particular cell. Similarly, if the ephemeris for a cell associated with a CHO configuration has expired, the UE will attempt to reacquire the ephemeris, e.g. from an element (or information) broadcast from the source or target cell, or provided by other types of signalling (e.g. dedicated signalling (RRC signalling)) by the source and / or target eNB.

[0196] Signalling ephemeris in CHO In certain examples, only the required ephemeris elements are signalled, i.e. only the ephemeris elements for the associated satellite or eNB are included, and not for every cell.

[0197] One problem with implementing the above is that the SIB31 element included in the CHO configuration for each cell is generated by the relevant target eNB, and the RRCReconfiguration is generated by the target eNB for each target cell. This can be seen in ephemerisId

[0198] Therefore, to solve this problem, the target eNB would need to only include the ephemeris for one of the target eNBs.

[0199] One way to achieve this is to introduce a mapping, e.g. by indicating which ephemeris the UE should apply using an ephemeris Id. This can be done in the following way: • The network can signal the associated ephemeris Id in the CHO configuration.

[0200] • For the UE: o If SIB31 is present and the ephemeris Id is present, this defines the specific Id. If a CHO handover is triggered, the UE uses the ephemeris.

[0201] o If SIB31 is not present and the ephemeris Id is present, use the ephemeris Id to find the configured ephemeris.

[0202] • The target eNB will generate the RRCReconfiguration with SIB31 as follows: o For the first received handover request (HANDOVER REQUEST) for a specific UE and a specific cell, generate SIB31 and ephemeris Id.

[0203] o For the next received handover request for the specific UE and another cell, include only the ephemeris Id of the first cell.

[0204] ​• The source eNB can include the ephemerisId number in the HandoverPreparationlnformation in the handover request sent to the target eNB requesting the handover.

[0205] This example can be seen in Figure 11 The benefit of the above approach is that the already introduced handover mechanism (i.e. non-CHO handover mechanism) can largely remain as is without requiring significant changes.

[0206] In certain examples, when ephemeris is signaled in CHO configuration, if ephemeris of target cells / eNBs is not included, the UE assumes that the cells are associated with the same satellite as the satellite of the source cell / eNB. This can be done for example by a flag in the configuration. This is important for CHO because the CHO configuration can become very large. Similarly, if there are multiple cells associated with a single target eNB / satellite, there can be signaling such as a specific ID identifying the satellite ephemeris so that only a single ephemeris element can need to be signaled. For example, this can be HandoverPreparationInformation .

[0207] In an alternative example, the target cells do not include ephemeris or dedicated SIB31 in the RRCReconfiguration sent to the source cell but include the SIB31 in a separate information element of the HandoverCommand. The source eNB can then compare the different received ephemeris or dedicated SIB31 elements and decide how to collect the information based on whether the SIB31 are the same or very similar. The ephemeris or dedicated SIB31 can then not be configured in the conditional configuration separate from the per-cell RRCReconfiguration within the conditional handover. This example can be seen in HandoverPreparationInformation The benefit of this approach is that it is more flexible but requires more signaling changes.

[0208] In certain examples, the target eNB is configured to not include any ephemeris or any dedicated SIB31 but the source eNB will include a dedicated SIB (new SIB expected to be introduced by 3GPP containing only neighboring cell ephemeris) containing the neighboring cell ephemeris elements. The conditional handover configuration can then include a mapping by e.g. ephemeris ID.

[0209] The concept of ephemerisId can be similar to SIB-id, in particular referring to SystemInformationBlockType31, i.e. not only the ephemeris is the same between different cells but also the SIB31 is the same between cells. In addition to the ephemeris, also the common TA, uplink synchronization validity duration, epoch time, and timing related aspects such as k-Offset and k-Mac are included.

[0210] Similarly, in some of the examples above, SIB31 is signaled to the source cell via the target cell. This can also be signaled via the ephemeris element instead of SIB31. The ephemeris is important, but the common TA is important for the access cell as well. For the purpose of reducing CHO signaling, this means that both the ephemeris and the common TA can be included in the information element.

[0211] Description Examples Example 1 • RRC 36.331 17.3.0 example ○ HandoverPreparationInformation ■ This message is used to transfer E-UTRA RRC information used by the target eNB or target ng-eNB, including UE capability information, during handover preparation or UE context retrieval (e.g. in case of resume or re-establishment).

[0212] • Direction: source eNB / source RAN to target eNB or target ng-eNB ■ HandoverPreparationInformation The message is shown in Table 5 below.

[0213] [Table 5]

[0214]

[0215] A description of the various fields set forth in Table 5 is provided in Table 6 below.

[0216] [Table 6]

[0217]

[0218] Example 2 • RRC 36.331 17.3.0 example ○ HandoverPreparationInformation ■ This message is used to transfer E-UTRA RRC information used by the target eNB or target ng-eNB, including UE capability information, during handover preparation or UE context retrieval (e.g. in case of resume or re-establishment).

[0219] • Direction: source eNB / source RAN to target eNB or target ng-eNB ■ HandoverPreparationInformation The message is shown in Table 7 below.

[0220] [Table 7]

[0221]

[0222] The following Table 8 provides a description of the various fields set forth in Table 7.

[0223] [Table 8]

[0224]

[0225] Example 3 • RRC 38.423 17.3.0 example o 9.1.1.1 Handover Request o This message is sent by the source NG RAN node to the target NG RAN node to request preparation of resources for handover (see Table 9 below).

[0226] o Direction: Source NG-RAN node -> Target NG-RAN node.

[0227] [Table 9]

[0228] Example 4 • RRC 36.331 17.3.0 example o HandoverCommand ■ This message is used to transfer E-UTRA RRC information used by the target eNB or target ng-eNB, including UE capability information, during handover preparation or UE context retrieval (e.g., in case of resumption or re-establishment).

[0229] • Direction: Source eNB / Source RAN to target eNB or target ng-eNB HandoverCommand The message is shown in Table 10 below.

[0230] [Table 10]

[0231]

[0232] The following Table 11 provides a description of the various fields set forth in Table 10.

[0233] [Table 11]

[0234]

[0235] • <Omitted> oMobilityControlInfo ■ The message is used to convey the handover command generated by the target eNB.

[0236] • Direction: Target eNB to Source eNB / Source RAN IE MobilityControlInfo The message is shown in Table 12 below.

[0237] [Table 12]

[0238]

[0239] A description of the various fields set forth in Table 12 is provided in Table 13 below.

[0240] [Table 13]

[0241] Example 5 • RRC 36.331 17.3.0 example MobilityControlInfo MobilityControlInfo Includes parameters related to network controlled mobility to / in E-UTRA.

[0242] MobilityControlInfo The information element is shown in Table 14 below.

[0243] [Table 14]

[0244]

[0245]

[0246] A description of the various fields set forth in Table 14 is provided in Table 15 below.

[0247] [Table 15]

[0248] Example 6 • RRC 36.331 17.3.0 example ■ IE RRCConnectionReconfiguration Includes parameters related to network controlled mobility to / in E-UTRA.

[0249] RRCConnectionReconfiguration The information element is shown in Table 16 below.

[0250] ​​​​​​[Table 16]

[0251]

[0252]

[0253]

[0254] The description of the various fields set forth in Table 16 is provided in Table 17 below.

[0255] [Table 17]

[0256] Example 7 • RRCConnectionReconfiguration • sk-Counter The message is a command to modify the RRC connection. It can transfer information for measurement configuration, mobility control, conditional reconfiguration (conditional handover, conditional PSCell addition, or inter-SN conditional PSCell change), radio resource configuration (including RBs, MAC main configuration, and physical channel configuration), including any associated dedicated NAS information and security configuration.

[0257] • Signaling Radio Bearers: SRB1 • RLC-SAP: AM • Logical Channels: DCCH • Direction: E-UTRAN to UE • nr-RadioBearerConfig1 / 2 The message is as shown in Table 18 below.

[0258] [Table 18]

[0259]

[0260] The description of the various fields set forth in Table 18 is provided in Table 19 below.

[0261] [Table 19]

[0262] NOTE 1: Fields nr-Config and sl-SSB-PriorityEUTRA are placed outside of Figure 12 as these can be configured when the UE is not configured with (NG)EN-DC.

[0263] NOTE 2: In case of NR PSCell addition or SN change happens at the same time as handover, it is not specified whether the timing reference for SMTC configuration is the source SMTC PCell or the target SMTC PCell. Therefore, only explicit SMTC configuration is supported when the source and target EUTRA PCell of handover are SFN / subframe synchronized.

[0264] NOTE 3: For UEs in RRC_IDLE, RRC_INACTIVE or out-of-coverage, and for cases where Figures 1 to 11 there is no , the priority of LTE PSSS / SSSS / PSBCH transmission and reception is up to UE implementation.

[0265] Figure 12 is a block diagram of an example network entity that can be used in examples of the present disclosure. For example, a UE and / or eNB / gNB in examples of ​ may include an entity of ​ Those skilled in the art will appreciate that a network entity can be implemented as, for example, a network element on a dedicated hardware, a software instance running on a dedicated hardware, and / or a virtualized function instantiated on an appropriate platform (e.g., on a cloud infrastructure).

[0266] The entity 1200 comprises a processor (or controller) 1201, a transmitter 1203, and a receiver 1205. The receiver 1205 is configured for receiving one or more messages from one or more other network entities, e.g., as described above. The transmitter 1203 is configured for transmitting one or more messages to one or more other network entities, e.g., as described above. The processor 1201 is configured for performing one or more operations, e.g., in accordance with operations as described above.

[0267] The techniques described herein can be implemented using any suitably configured apparatus and / or system. Such apparatus and / or system can be configured to perform a method according to any aspect, embodiment, example, or claim disclosed herein. Such apparatus can comprise one or more elements, e.g., one or more of a receiver, a transmitter, a transceiver, a processor, a controller, a module, a unit, etc., each configured to perform one or more corresponding process, operation, and / or method step for implementing the techniques described herein. For example, the operations / functions of X can be performed by a module configured to perform X (or X module). One or more elements can be implemented in the form of hardware, software, or any combination of hardware and software.

[0268] It should be appreciated that examples of the present disclosure can be implemented in the form of hardware, software, or any combination of hardware and software. Any such software can be stored in the form of volatile or non-volatile storage, for example, storage devices like ROM, whether erasable or rewritable or memory chips, devices or integrated circuits, either volatile or non-volatile, such as RAM, memory chips, device or integrated circuits or stored in the form of storage on an optical, magnetic or waveguide medium, such as a CD, DVD, tape or magnetic disk, etc.

[0269] It should be appreciated that storage devices and storage media are embodiments of machine-readable storage media suitable for storing one or more programs comprising instructions that, when executed, implement certain examples of the present disclosure. Accordingly, certain examples provide a program comprising code for implementing a method, apparatus, or system according to any of the examples, embodiments, aspects, and / or claims disclosed herein, and / or a machine-readable storage device storing such a program. Further, such programs can be electronically transferred across any media, e.g., carrying digital or analog signals via wired or wireless connections.

[0270] While the present disclosure has been illustrated and described with reference to certain examples, it will be understood by those skilled in the art that various changes and modifications can be made therein without departing from the scope of the present disclosure as defined by the appended claims.

[0271] Abbreviations / definitions In the present disclosure, the following abbreviations / definitions from Table 20 are used.

[0272] [Table 20]

[0273]

[0274] While the present disclosure has been described with reference to various examples, it will be understood by those skilled in the art that various changes and modifications can be made therein without departing from the scope of the present disclosure as defined by the appended claims.

Claims

1. A method performed by a first base station, the method comprising: obtaining, from a second base station, a conditional handover, CHO, configuration associated with a time-based triggering condition; determining an uplink, UL, grant for a time-based CHO; transmitting, to a terminal, the UL grant for the time-based CHO, wherein the time-based CHO is performed based on RACH-less, i.e., random access channel-less. 2.The method of claim 1, wherein the CHO configuration associated with the time-based triggering condition comprises at least one information on a time-based conditional event or information on a time threshold.

3. The method of claim 1, wherein, at least one of the first base station or the second base station is associated with a non-terrestrial network, NTN. 4.The method of claim 1, the method further comprising: listening, based on the CHO configuration associated with the time-based triggering condition, for an UL RACH-less transmission from the UE. 5.A method performed by a terminal, the method comprising: in a case where a conditional handover, CHO, configuration associated with a time-based triggering condition is obtained, from a first base station, from a second base station, receiving, from the first base station, an uplink, UL, grant for a time-based CHO; receiving, from the second base station, a control message including information for configuring an UL transmission; and performing the time-based CHO based on the UL grant and the information for configuring the UL transmission, wherein the time-based CHO is performed based on RACH-less, i.e., random access channel-less. 6.The method of claim 5, the CHO configuration associated with the time-based triggering condition comprises at least one information on a time-based conditional event or information on a time threshold. wherein the information for configuring the UL transmission further comprises at least one of: first information on a number of configured HARQ processes, second information on a number of repetitions for the UL transmission, or third information associated with a RACH-less configuration, and 7. The method of claim 5, wherein, wherein at least one of the first base station or the second base station is associated with a non-terrestrial network, NTN. 8.A first base station, the first base station comprising: a transceiver; and at least one processor configured to: obtain, from a second base station, a conditional handover, CHO, configuration associated with a time-based triggering condition, determine an uplink, UL, grant for a time-based CHO, transmit, to a terminal via the transceiver, the UL grant for the time-based CHO, wherein the time-based CHO is performed based on RACH-less, i.e., random access channel-less. 9.The first base station of claim 8, the CHO configuration associated with the time-based triggering condition comprises at least one information on a time-based conditional event or information on a time threshold. wherein 10.The first base station of claim 8, ​ wherein, At least one of the first base station or the second base station is associated with a non-terrestrial network, NTN.

11. The first base station of claim 8, wherein, The at least one processor is further configured to: monitor for an UL RACH-less transmission from the UE based on the CHO configuration associated with the time-based trigger condition.

12. A terminal, the terminal comprising: a transceiver; and at least one processor configured to: in case a conditional handover, CHO, configuration associated with a time-based trigger condition is obtained by a first base station from a second base station, receive, via the transceiver, an uplink, UL, grant for a time-based CHO from the first base station, receive, via the transceiver, a control message from the second base station comprising information for configuring an UL transmission, and perform the time-based CHO based on the UL grant and the information for configuring the UL transmission, wherein the time-based CHO is performed based on RACH-less, i.e. without random access channel.

13. The terminal of claim 12, wherein the CHO configuration associated with the time-based trigger condition comprises at least one information on a time-based conditional event or information on a time threshold.

14. The terminal of claim 12, wherein, At least one of the first base station or the second base station is associated with a non-terrestrial network, NTN.

15. The terminal of claim 12, wherein, The information for configuring the UL transmission further comprises at least one of: a first information on a number of configured HARQ processes, a second information on a number of repetitions for the UL transmission, or a third information associated with a RACH-less configuration.

Images